实时数仓架构(OLAP)方案

引言：

目前使用的是 离线数据仓库主要基于sqoop、hive等技术来构建T+1的离线数据，通过定时任务每天拉取增量数据；

虽然采用的这个模式以及框架，但是时间的跨度是两个小时的时间，也就是小时级别的数据处理，非常牺牲性能，t+1的模式是以24小时为周期每天计算一次，而现在是两个小时为周期(目前大概有几十个指标运算)，t+1的模式运行这几十个任务很轻松，但是二个小时为一周期，在离线模式(Hive)下，使用的资源成本代价是非常高昂的。

也因此引入了大数据的实时计算系统

1. 大数据演化

大数据分析现在演化出一条新的流处理链路，这个链路和之前的批处理分别处理，然后在服务层面利用大数据的计算能力进行合并，向外提供离线+实时数据服务，这也是著名的lambda架构。

1. 即席式查询（工具）

还有一个模式是即席实时查询 ==> 多维分析OLAP 就是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表，但是数据并不跟业务数据库同步，是在原有的数据基础上(昨日以及历史的数据)进行一个自定义随机查询，目前的工具有Druid Presto Phoenix Kylin Impala

开源的有 Presto (Hive) 和 Phoenix(Habase支持一个实时的查询) 都是基于内存的运算

支持sql语言编写的

也是阿里EMR大数据集群产品中仅支持的自带的工具

数据中台和实时数仓的区别

目前有数据中台和数据仓库两个方向但是具体的实现以及使用的框架是互相浸透的，个人理解为主要的不同就是思维理念不同，数据仓库是“管理数据”，数据中台是“经营数据”，数据中台是为了提供服务而生（也有说是为了前台而生）。

大数据实时网络架构图

补充：Phoenix也能实现OLAP

目前能够使用的数仓架构图

实时计算框架

根据目前的需求：

实时数仓的框架有三种实时框架其中Spark和Flink是Java编写的

Storm 是最早的一个实时计算框架

Spark 准实时的实时计算框架

Flink 流式实时的计算框架

美团技术博客发布过一篇文章

《流计算框架 Flink 、Spark与 Storm 的性能对比》

项目/引擎	Storm	Flink	spark-treaming
API	灵活的底层 API 和具有事务保证的 Trident API	流 API 和更加适合数据开发的 Table API 和 Flink SQL 支持	流 API 和 Structured-Streaming API 同时也可以使用更适合数据开发的 Spark SQL
容错机制	ACK 机制	State 分布式快照保存点	RDD 保存点
状态管理	Trident State状态管理	Key State 和 Operator State两种 State 可以使用，支持多种持久化方案	有 UpdateStateByKey 等 API 进行带状态的变更，支持多种持久化方案
处理模式	单条流式处理	单条流式处理	Mic batch处理
延迟	毫秒级	毫秒级	秒级也能达到毫秒级别牺牲性能
语义保障	At Least Once，Exactly Once	Exactly Once，At Least Once	At Least Once

从调研结果来看，Flink 和 Spark Streaming 的 API 、容错机制与状态持久化机制都可以解决一部分我们目前使用 Storm 中遇到的问题。但 Flink 在数据延迟上和 Storm 更接近，对现有应用影响最小。而且在公司内部的测试中 Flink 的吞吐性能对比 Storm 有十倍左右提升。综合考量我们选定 Flink 引擎作为实时数仓的开发引擎。

这里没有不选择Spark的原因，个人理解：API 虽然丰富，但是Spark的延迟较高。

这是FlinkSql运行的机制

Spark 和 Flink之间的区别

Spark具有丰富的API 比较成熟既能够处理离线数据也能够保证exctly-once
Flink 是专门为了流式计算而开发的，并且能够保证Exctly-once 特别是提供了Spark不曾有的窗口函数 (滑动窗口、滚动窗口、会话窗口) 。这个我比较喜欢，但是如果数据在业务库中真的有，因为网络原因Canal没监控到或者延迟了好几旧，超过了

注：最近刚刚更新的Spark3.0版本的不知道有没有提供类似的时间窗口函数，这个没研究

好像更好的兼容了Python 加入了更多的 API

实时查询怎么才能爽？

只要内存够保你爽翻天

数据仓库建设方法论
1. 面向主题

从公司业务出发，是分析的宏观领域，比如供应商主题、订单主题、商品主题、客户主题和仓库主题

1. 提供多维数据分析服务 这里就是OLAP了

数据报表；数据立方体，上卷、下钻、切片、旋转等分析功能。

1. 数据分层

不管是从计算成本，还是从易用性，还是从复用性，还是从一致性等等，我们都必须避免烟囱式的开发模式，而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致，我们将实时中间层分为两层。

第一层 DWD 公共实时明细层

实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源 join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。这部分数据有两个分支，一部分直接落地到 ADS，供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用；

第二层 DWS 公共实时汇总层

以数据域+业务域的理念建设公共汇总层，与离线数仓不同的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出，轻度汇总层写入 ADS，用于前端产品复杂的 olap 查询场景，满足自助分析和产出报表的需求；高度汇总层写入 Hbase，用于前端比较简单的 kv 查询场景，提升查询性能，比如实时大屏等；

1. 范式数据模型

以事实表和维度表组成的星型数据模型

另外还有雪花模型

一般都是用星型模型

实时数仓架构(OLAP)方案

实时数仓架构(OLAP)方案

猜你喜欢