一、美团点评实时计算演进
美团点评实时计算演进历程
在 2016 年，美团点评就已经基于 Storm 实时计算引擎实现了初步的平台化。2017 年初，我们引入了 Spark Streaming 用于特定场景的支持，主要是在数据同步场景方面的尝试。在 2017 年底，美团点评实时计算平台引入了 Flink。相比于 Storm 和 Spark Streaming，Flink 在很多方面都具有优势。这个阶段我们进行了深度的平台化，主要关注点是安全、稳定和易用。从 19 年开始，我们致力于建设包括实时数仓、机器学习等特定场景的解决方案来为业务提供更好的支持。
实时计算平台
目前，美团点评的实时计算平台日活跃作业数量为万级，高峰时作业处理的消息量达到每秒 1.5 亿条，而机器规模也已经达到了几千台，并且有几千位用户正在使用实时计算服务。
实时计算平台架构
如下图所示的是美团点评实时计算平台的架构。
本次分享主要介绍实时数仓方面的建设情况。
从功能角度来看 ，美团点评的实时计算平台主要包括作业和资源管理两个方面的功能。其中，作业部分包括作业配置、作业发布以及作业状态三个方面的功能。
在资源管理方面 ，则为用户提供了多租户资源隔离以及资源交付和部署的能力。
业务数仓实践
前面提到，现在的美团点评实时计算平台更多地会关注在安全、易用和稳定方面，而应用上很大的一个场景就是业务数仓。接下来会为大家分享几个业务数仓的例子。
第一个例子是流量 ，流量数仓是流量类业务的基础服务，从业务通道而言，会有不同通道的埋点和不同页面的埋点数据，通过日志收集通道会进行基础明细层的拆分，按照业务维度划分不同的业务通道，如美团通道、外卖通道等。
基于业务通道还会进行一次更加细粒度的拆分，比如曝光日志、猜你喜欢、推荐等。以上这些包括两种使用方式，一种是以流的方式提供下游其他业务方使用，另外一方面就是做一些流量方面的实时分析。
下图中右边是流量数仓的架构图，自下向上分为四层，分别是 SDK 层，包括了前端、小程序以及 APP 的埋点；其上是收集层，埋点日志落地到 Nginx，通过日志收集通道收到 Kafka 中。在计算层，流量团队基于 Storm 能力实现了上层的 SQL 封装，并实现了 SQL 动态更新的特性，在 SQL 变更时不必重启作业。
广告实时效果
这里再举一个基于流量数仓的例子-广告实时效果验证。下图中左侧是广告实时效果的对比图。广告的打点一般分为请求（PV）打点、SPV（Server PV）打点、CPV（Client PV）曝光打点和 CPV 点击打点，在所有打点中都会包含一个流量的 requestID 和命中的实验路径。根据 requestID 和命中的实验路径可以将所有的日志进行 join，得到一个 request 中需要的所有数据，然后将数据存入 Durid 中进行分析，支持实际 CTR、预估 CTR 等效果验证。
这里列举的另外一个业务数仓实践的例子是即时配送。实时数据在即时配送的运营策略上发挥了重要作用。以送达时间预估为例，交付时间衡量的是骑手送餐的交付难度，整个履约时间分为了多个时间段，配送数仓会基于 Storm 做特征数据的清洗、提取，供算法团队进行训练并得到时间预估的结果。这个过程涉及到商家、骑手以及用户的多方参与，数据的特征会非常多，数据量也会非常大。
业务实时数仓大致分为三类场景：流量类、业务类和特征类，这三种场景各有不同。
二、基于 Flink 的实时数仓平台
上面为大家介绍了实时数仓的业务场景，接下来为大家介绍实时数仓的演进过程和美团点评的实时数仓平台建设思路。
传统数仓模型
为了更有效地组织和管理数据，数仓建设往往会进行数据分层，一般自下而上分为四层：ODS（操作数据层）、DWD（数据明细层）、DWS（汇总层）和应用层。即时查询主要通过 Presto、Hive 和 Spark 实现。
实时数仓模型
实时数仓的分层方式一般也遵守传统数据仓库模型，也分为了 ODS 操作数据集、DWD 明细层和 DWS 汇总层以及应用层。但实时数仓模型的处理的方式却和传统数仓有所差别，如明细层和汇总层的数据一般会放在 Kafka 上，维度数据一般考虑到性能问题则会放在 HBase 或者 Tair 等 KV 存储上，即席查询则可以使用 Flink 完成。
准实时数仓模型
在以上两种数仓模型之外，我们发现业务方在实践过程中还有一种准实时数仓模型，其特点是不完全基于流去做，而是将明细层数据导入到 OLAP 存储中，基于 OLAP 的计算能力去做汇总并进行进一步的加工。
实时数仓和传统数仓的对比
实时数仓和传统数仓的对比主要可以从四个方面考虑：
实时数仓建设方案对比
下图中对于实时数仓的两种建设方式，即准实时数仓和实时数仓两种方式进行了对比。它们的实现方式分别是基于 OLAP 引擎和流计算引擎，实时度则分别是分钟和秒级。
总结一下，基于 OLAP 引擎的建设方式是数据量不太大，业务流量不太高情况下为了提高时效性和开发效率的一个折中方案，从未来的发展趋势来看，基于流计算的实时数仓更具有发展前景。
一站式解决方案
从业务实践过程中，我们看到了业务建设实时数仓的共同需求，包括发现不同业务的元数据是割裂的，业务开发也倾向于使用 SQL 方式同时开发离线数仓和实时数仓，需要更多的运维工具支持。因此我们规划了一站式解决方案，希望能够将整个流程贯通。
这里的一站式解决方案主要为用户提供了数据开发工作平台、元数据管理。同时我们考虑到业务从生产到应用过程中的问题，我们 OLAP 生产平台，从建模方式、生产任务管理和资源方面解决 OLAP 生产问题。左侧是我们已经具备数据安全体系、资源体系和数据治理，这些是离线数仓和实时数仓可以共用的。
为何选择 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 平台而言，需要从三个层面考虑：
UDF 的应用其实非常广泛，UDF 平台并不是只支持实时数仓，也会同时支持离线数仓、机器学习以及查询服务等应用场景。下图中右侧展示的是 UDF 的使用案例，左图是 UDF 的开发流程，用户只需要关心注册流程，接下来的编译打包、测试以及上传等都由平台完成；右图是 UDF 的使用流程中，用户只需要声明 UDF，平台会进行解析校验、路径获取以及在作业提交的时候进行集成。
实时数仓平台-Web IDE
最后介绍一下实时数仓平台的开发工作台，以 Web IDE 的形式集成了模型、作业以及 UDF 的管理，用户可以在 Web IDE 上以 SQL 方式开发。平台会对 SQL 做一些版本的管理，并且支持用户回退到已部署成功的版本上去。
三、未来发展与思考
资源自动调优
从整个实时计算角度来考虑，目前美团点评的实时计算平台的节点数已经达到了几千台，未来很可能会达到上万台，因此资源优化这件事情很快就会被提上日程。由于业务本身的流量存在高峰和低谷，对于一个实时任务来说，可能在高峰时需要很多资源，但是在低谷时并不需要那么多资源。
另外一方面，波峰本身也是会发生变化的，有可能随着业务的上涨使得原来分配的资源数量不够用。因此，资源自动调优有两个含义，一个是指能够适配作业的高峰流量上涨，自动适配 Max 值；另外一个含义是指使得作业能够在高峰过去之后自动适应流量减少，能够快速缩容。我们可以通过每个任务甚至是算子的历史运行情况，拟合得到算子、流量与资源的关系函数，在流量变化时同步调整资源量。
以上是资源优化的思路，除此之外还需要考虑当资源完成优化之后应该如何利用。为了保证可用性，实时和离线任务一般会分开部署，否则带宽、IO 都可能被离线计算打满导致实时任务延迟。而从资源使用率角度出发，则需要考虑实时和离线的混合部署，或者以流的方式来处理一些实时性要求并不是非常高的任务。这就要求更细粒度的资源隔离和更快的资源释放。
推动实时数仓建设方式升级
实时数仓的建设一般分为几个步骤：
目前，美团点评的实时数仓平台建设工作还集中在统一表达的层次，距离理想状态仍然有比较长的一段路要走。