美团点评基于 Flink 的实时数仓平台实践

数据仓库的建设是“数据智能”必不可少的一环，也是大规模数据应用中必然面临的挑战，而 Flink 实时数仓在数据链路中扮演着极为重要的角色。本文中，美团点评高级技术专家鲁昊为你们分享了美团点评基于 Apache Flink 的实时数仓平台实践。

做者：鲁昊@美团点评

点击查看本场直播>>>

更多2019 Flink Forward 大会视频>>>

1、美团点评实时计算演进

美团点评实时计算演进历程

在 2016 年，美团点评就已经基于 Storm 实时计算引擎实现了初步的平台化。2017 年初，咱们引入了 Spark Streaming 用于特定场景的支持，主要是在数据同步场景方面的尝试。在 2017 年末，美团点评实时计算平台引入了 Flink。相比于 Storm 和 Spark Streaming，Flink 在不少方面都具备优点。这个阶段咱们进行了深度的平台化，主要关注点是安全、稳定和易用。从 19 年开始，咱们致力于建设包括实时数仓、机器学习等特定场景的解决方案来为业务提供更好的支持。

实时计算平台

目前，美团点评的实时计算平台日活跃做业数量为万级，高峰时做业处理的消息量达到每秒 1.5 亿条，而机器规模也已经达到了几千台，而且有几千位用户正在使用实时计算服务。

实时计算平台架构

以下图所示的是美团点评实时计算平台的架构。

• 最底层是收集层，这一层负责收集用户的实时数据，包括 Binlog、后端服务日志以及 IoT 数据，通过日志收集团队和 DB 收集团队的处理，数据将会被收集到 Kafka 中。这些数据不仅是参与实时计算，也会参与离线计算。
• 收集层之上是存储层，这一层除了使用 Kafka 作消息通道以外，还会基于 HDFS 作状态数据存储以及基于 HBase 作维度数据的存储。
• 存储层之上是引擎层，包括 Storm 和 Flink。实时计算平台会在引擎层为用户提供一些框架的封装以及公共包和组件的支持。
• 在引擎层之上就是平台层了，平台层从数据、任务和资源三个视角去管理。
• 架构的最上层是应用层，包括了实时数仓、机器学习、数据同步以及事件驱动应用等。

本次分享主要介绍实时数仓方面的建设状况。

从功能角度来看，美团点评的实时计算平台主要包括做业和资源管理两个方面的功能。其中，做业部分包括做业配置、做业发布以及做业状态三个方面的功能。

• 在做业配置方面，则包括做业设置、运行时设置以及拓扑结构设置；
• 在做业发布方面，则包括版本管理、编译/发布/回滚等；
• 做业状态则包括运行时状态、自定义指标和报警以及命令/运行时日志等。

在资源管理方面，则为用户提供了多租户资源隔离以及资源交付和部署的能力。

业务数仓实践

流量

前面提到，如今的美团点评实时计算平台更多地会关注在安全、易用和稳定方面，而应用上很大的一个场景就是业务数仓。接下来会为你们分享几个业务数仓的例子。

第一个例子是流量，流量数仓是流量类业务的基础服务，从业务通道而言，会有不一样通道的埋点和不一样页面的埋点数据，经过日志收集通道会进行基础明细层的拆分，按照业务维度划分不一样的业务通道，如美团通道、外卖通道等。

基于业务通道还会进行一次更加细粒度的拆分，好比曝光日志、猜你喜欢、推荐等。以上这些包括两种使用方式，一种是以流的方式提供下游其余业务方使用，另一方面就是作一些流量方面的实时分析。

下图中右边是流量数仓的架构图，自下向上分为四层，分别是 SDK 层，包括了前端、小程序以及 APP 的埋点；其上是收集层，埋点日志落地到 Nginx，经过日志收集通道收到 Kafka 中。在计算层，流量团队基于 Storm 能力实现了上层的 SQL 封装，并实现了 SQL 动态更新的特性，在 SQL 变动时没必要重启做业。

广告实时效果

这里再举一个基于流量数仓的例子-广告实时效果验证。下图中左侧是广告实时效果的对比图。广告的打点通常分为请求（PV）打点、SPV（Server PV）打点、CPV（Client PV）曝光打点和 CPV 点击打点，在全部打点中都会包含一个流量的 requestID 和命中的实验路径。根据 requestID 和命中的实验路径能够将全部的日志进行 join，获得一个 request 中须要的全部数据，而后将数据存入 Durid 中进行分析，支持实际 CTR、预估 CTR 等效果验证。

即时配送

这里列举的另一个业务数仓实践的例子是即时配送。实时数据在即时配送的运营策略上发挥了重要做用。以送达时间预估为例，交付时间衡量的是骑手送餐的交付难度，整个履约时间分为了多个时间段，配送数仓会基于 Storm 作特征数据的清洗、提取，供算法团队进行训练并获得时间预估的结果。这个过程涉及到商家、骑手以及用户的多方参与，数据的特征会很是多，数据量也会很是大。

总结

业务实时数仓大体分为三类场景：流量类、业务类和特征类，这三种场景各有不一样。

• 在数据模型上，流量类是扁平化的宽表，业务数仓更可能是基于范式的建模，特征数据是 KV 存储。
• 从数据来源区分，流量数仓的数据来源通常是日志数据；业务数仓的数据来源是业务 binlog 数据；特征数仓的数据来源则多种多样。
• 从数据量而言，流量和特征数仓都是海量数据，天天百亿级以上，而业务数仓的数据量通常天天百万到千万级。
• 从数据更新频率而言，流量数据极少更新，则业务和特征数据更新较多。流量数据通常关注时序和趋势，业务数据和特征数据关注状态变动。
• 在数据准确性上，流量数据要求较低，而业务数据和特征数据要求较高。
• 在模型调整频率上，业务数据调整频率较高，流量数据和特征数据调整频率较低。

2、基于 Flink 的实时数仓平台

上面为你们介绍了实时数仓的业务场景，接下来为你们介绍实时数仓的演进过程和美团点评的实时数仓平台建设思路。

传统数仓模型

为了更有效地组织和管理数据，数仓建设每每会进行数据分层，通常自下而上分为四层：ODS（操做数据层）、DWD（数据明细层）、DWS（汇总层）和应用层。即时查询主要经过 Presto、Hive 和 Spark 实现。

实时数仓模型

实时数仓的分层方式通常也遵照传统数据仓库模型，也分为了 ODS 操做数据集、DWD 明细层和 DWS 汇总层以及应用层。但实时数仓模型的处理的方式却和传统数仓有所差异，如明细层和汇总层的数据通常会放在 Kafka 上，维度数据通常考虑到性能问题则会放在 HBase 或者 Tair 等 KV 存储上，即席查询则可使用 Flink 完成。

准实时数仓模型

在以上两种数仓模型以外，咱们发现业务方在实践过程当中还有一种准实时数仓模型，其特色是不彻底基于流去作，而是将明细层数据导入到 OLAP 存储中，基于 OLAP 的计算能力去作汇总并进行进一步的加工。

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

实时数仓和传统数仓的对比主要能够从四个方面考虑：

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

实时数仓建设方案对比

下图中对于实时数仓的两种建设方式，即准实时数仓和实时数仓两种方式进行了对比。它们的实现方式分别是基于 OLAP 引擎和流计算引擎，实时度则分别是分钟和秒级。

• 在调度开销方面，准实时数仓是批处理过程，所以仍然须要调度系统支持，虽然调度开销比离线数仓少一些，可是依然存在，而实时数仓却没有调度开销。
• 在业务灵活性方面，由于准实时数仓基于 OLAP 引擎实现，灵活性优于基于流计算的方式。
• 在对数据晚到的容忍度方面，由于准实时数仓能够基于一个周期内的数据进行全量计算，所以对于数据晚到的容忍度也是比较高的，而实时数仓使用的是增量计算，对于数据晚到的容忍度更低一些。
• 在扩展性方面，由于准实时数仓的计算和存储是一体的，所以相比于实时数仓，扩展性更弱一些。
• 在适用场景方面，准实时数仓主要用于有实时性要求但不过高、数据量不大以及多表关联复杂和业务变动频繁的场景，如交易类型的实时分析，实时数仓则更适用于实时性要求高、数据量大的场景，如实时特征、流量分发以及流量类型实时分析。

总结一下，基于 OLAP 引擎的建设方式是数据量不太大，业务流量不过高状况下为了提升时效性和开发效率的一个折中方案，从将来的发展趋势来看，基于流计算的实时数仓更具备发展前景。

一站式解决方案

从业务实践过程当中，咱们看到了业务建设实时数仓的共同需求，包括发现不一样业务的元数据是割裂的，业务开发也倾向于使用 SQL 方式同时开发离线数仓和实时数仓，须要更多的运维工具支持。所以咱们规划了一站式解决方案，但愿可以将整个流程贯通。

这里的一站式解决方案主要为用户提供了数据开发工做平台、元数据管理。同时咱们考虑到业务从生产到应用过程当中的问题，咱们 OLAP 生产平台，从建模方式、生产任务管理和资源方面解决 OLAP 生产问题。左侧是咱们已经具有数据安全体系、资源体系和数据治理，这些是离线数仓和实时数仓能够共用的。

为什么选择 Flink？

实时数仓平台建设之因此选择 Flink 是基于如下四个方面的考虑，这也是实时数仓方面关注的比较核心的问题。

• 第一个是状态管理，实时数仓里面会进行不少的聚合计算，这些都须要对于状态进行访问和管理，Flink 在这方面比较成熟。
• 第二个是表义能力，Flink 提供极为丰富的多层次 API，包括 Stream API、Table API 以及 Flink SQL。
• 第三个是生态完善，实时数仓的用途普遍，用户对于多种存储有访问需求，Flink 对于这方面的支持也比较完善。
• 最后一点就是 Flink 提供了流批统一的可能性。

实时数仓平台

建设思路

实时数仓平台的建设思路从外到内分为了四个层次，咱们认为平台应该作的事情是为用户提供抽象的表达能力，分别是消息表达、数据表达、计算表达以及流和批统一。

实时数仓平台架构

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

消息表达-数据接入

在消息表达层面，由于 Binlog、埋点日志、后端日志以及 IoT 数据等的数据格式是不一致的，所以美团点评的实时数仓平台提供数据接入的流程，可以帮助你们把数据同步到 ODS 层。这里主要实现了两件事情，分别是统一消息协议和屏蔽处理细节。

以下图左侧是接入过程的一个例子，对于 Binlog 类型数据，实时数仓平台还为你们提供了分库分表的支持，可以将属于同一个业务的不一样的分库分表数据根据业务规则收集到同一个 ODS 表中去。

计算表达-扩展 DDL

美团点评实时数仓平台基于 Flink 扩展了 DDL，这部分工做的主要目的是建设元数据体系，打通内部的主流实时存储，包括 KV 数据、OLAP 数据等。因为开发工做台和元数据体系是打通的，所以不少数据的细节并不须要你们在 DDL 中明确地声明出来，只须要在声明中写上数据的名字，和运行时的一些设置，好比 MQ 从最新消费仍是最旧消费或者从某个时间戳消费便可，其余的数据访问方式是一致的。

计算表达-UDF 平台

对于 UDF 平台而言，须要从三个层面考虑：

• 首先是数据安全性。以前的数仓建设过程当中，用户能够上传 Jar 包去直接引用 UDF，这样作是有危险性存在的，而且咱们没法知道数据的流向。从数据安全的角度来考虑，平台会进行代码审计和血缘关系分析，对于历史风险组件或者存在问题的组件能够进行组件收敛。
• 第二个层面，在数据安全基础上咱们还会关注 UDF 的运行质量，平台将会为用户提供模板、用例以及测试的管理，为用户屏蔽编译打包、Jar 包管理的过程，而且会在 UDF 模板中进行指标日志的埋点和异常处理。
• 第三个层面是 UDF 的复用能力，由于一个业务方开发的 UDF，其余业务方极可能也会使用，可是升级过程当中可能会带来不兼容的问题，所以，平台为业务提供了项目管理、函数管理和版本管理的能力。

UDF 的应用其实很是普遍，UDF 平台并非只支持实时数仓，也会同时支持离线数仓、机器学习以及查询服务等应用场景。下图中右侧展现的是 UDF 的使用案例，左图是 UDF 的开发流程，用户只须要关心注册流程，接下来的编译打包、测试以及上传等都由平台完成；右图是 UDF 的使用流程中，用户只须要声明 UDF，平台会进行解析校验、路径获取以及在做业提交的时候进行集成。

实时数仓平台-Web IDE

最后介绍一下实时数仓平台的开发工做台，以 Web IDE 的形式集成了模型、做业以及 UDF 的管理，用户能够在 Web IDE 上以 SQL 方式开发。平台会对 SQL 作一些版本的管理，而且支持用户回退到已部署成功的版本上去。

3、将来发展与思考

资源自动调优

从整个实时计算角度来考虑，目前美团点评的实时计算平台的节点数已经达到了几千台，将来极可能会达到上万台，所以资源优化这件事情很快就会被提上日程。因为业务自己的流量存在高峰和低谷，对于一个实时任务来讲，可能在高峰时须要不少资源，可是在低谷时并不须要那么多资源。

另一方面，波峰自己也是会发生变化的，有可能随着业务的上涨使得原来分配的资源数量不够用。所以，资源自动调优有两个含义，一个是指可以适配做业的高峰流量上涨，自动适配 Max 值；另一个含义是指使得做业可以在高峰过去以后自动适应流量减小，可以快速缩容。咱们能够经过每一个任务甚至是算子的历史运行状况，拟合获得算子、流量与资源的关系函数，在流量变化时同步调整资源量。

以上是资源优化的思路，除此以外还须要考虑当资源完成优化以后应该如何利用。为了保证可用性，实时和离线任务通常会分开部署，不然带宽、IO 均可能被离线计算打满致使实时任务延迟。而从资源使用率角度出发，则须要考虑实时和离线的混合部署，或者以流的方式来处理一些实时性要求并非很是高的任务。这就要求更细粒度的资源隔离和更快的资源释放。

推进实时数仓建设方式升级

实时数仓的建设通常分为几个步骤：

• 首先，业务提出需求，后续会进行设计建模、业务逻辑开发和底层技术实现。美团点评的实时数仓建设思路是将技术实现统一表达，让业务关注逻辑开发，而逻辑开发也能够基于配置化手段实现自动构建。
• 再上一层是能够根据业务需求实现智能建模，将设计建模过程实现自动化。

目前，美团点评的实时数仓平台建设工做还集中在统一表达的层次，距离理想状态仍然有比较长的一段路要走。