美团实时数仓建设

实时数仓和传统数仓的对比

实时数仓和传统数仓的对比主要可以从四个方面考虑：
●第一个是分层方式，离线数仓为了考虑到效率问题，一般会采取空间换时间
的方式，层级划分会比较多；则实时数仓考虑到实时性问题，一般分层会比较
少，另外也减少了中间流程出错的可能性。
●第二个是事实数据存储方面，离线数仓会基于 HDFS，实时数仓则会基于消息
队列（如 Kafka） 。
●第三个是维度数据存储，实时数仓会将数据放在 KV 存储上面。
●第四个是数据加工过程，离线数仓一般以 Hive、Spark 等批处理为主，而实
时数仓则是基于实时计算引擎如 Storm、Flink 等，以流处理为主。

实时数仓建设方案对比

下图中对于实时数仓的两种建设方式，即准实时数仓和实时数仓两种方式进行了
对比。它们的实现方式分别是基于 OLAP 引擎和流计算引擎，实时度则分别是分钟
和秒级。
●在调度开销方面，准实时数仓是批处理过程，因此仍然需要调度系统支持，虽
然调度开销比离线数仓少一些，但是依然存在，而实时数仓却没有调度开销。
●在业务灵活性方面，因为准实时数仓基于 OLAP 引擎实现，灵活性优于基于
流计算的方式。
●在对数据晚到的容忍度方面，因为准实时数仓可以基于一个周期内的数据进行
全量计算，因此对于数据晚到的容忍度也是比较高的，而实时数仓使用的是增
量计算，对于数据晚到的容忍度更低一些。
●在扩展性方面，因为准实时数仓的计算和存储是一体的，因此相比于实时数
仓，扩展性更弱一些。
●在适用场景方面，准实时数仓主要用于有实时性要求但不太高、数据量不大以
及多表关联复杂和业务变更频繁的场景，如交易类型的实时分析，实时数仓则
更适用于实时性要求高、数据量大的场景，如实时特征、流量分发以及流量类
型实时分析。
总结一下，基于 OLAP 引擎的建设方式是数据量不太大，业务流量不太高情况
下为了提高时效性和开发效率的一个折中方案，从未来的发展趋势来看，基于流计算
的实时数仓更具有发展前景

image.png

image.png

● 实时数仓平台架构
如下图所示的是美团点评的实时数仓平台架构，从下往上看，资源层和存储层
复用了实时计算平台的能力，在引擎层则会基于 Flink Streaming 实现一些扩展能
力，包括对 UDF 的集成和 Connector 的集成。再往上是基于 Flink SQL 独立出来
的 SQL 层，主要负责解析、校验和优化。在这之上是平台层，包括开发工作台、元
数据、UDF 平台以及 OLAP 平台。最上层则是平台所支持的实时数仓的应用，包括
实时报表、实时 OLAP、实时 Dashboard 和实时特征等。

image.png

image.png

● 消息表达 - 数据接入
在消息表达层面，因为 Binlog、埋点日志、后端日志以及 IoT 数据等的数据格
式是不一致的，因此美团点评的实时数仓平台提供数据接入的流程，能够帮助大家
把数据同步到 ODS 层。这里主要实现了两件事情，分别是统一消息协议和屏蔽处
理细节。
如下图左侧是接入过程的一个例子，对于 Binlog 类型数据，实时数仓平台还为
大家提供了分库分表的支持，能够将属于同一个业务的不同的分库分表数据根据业务
规则收集到同一个 ODS 表中去。

image.png

● 计算表达 - 扩展 DDL
美团点评实时数仓平台基于 Flink 扩展了 DDL，这部分工作的主要目的是建设
元数据体系，打通内部的主流实时存储，包括 KV 数据、OLAP 数据等。由于开发工
作台和元数据体系是打通的，因此很多数据的细节并不需要大家在 DDL 中明确地声
明出来，只需要在声明中写上数据的名字，和运行时的一些设置，比如 MQ 从最新消
费还是最旧消费或者从某个时间戳消费即可，其他的数据访问方式是一致的。

image.png

image.png