本由社区志愿者苗文婷整理，内容源顺丰科技大数据平台研发工程师龙逸尘在FlinkForwardAsia分享的《Flink在顺丰的应用实践》，主要分享内容为：顺丰基于Flink建设实时数仓的思路，引入HudiOnFlink加速数仓宽表，以及实时数仓平台化建设的实践。分为以下5个部分：
1.建设背景
2.建设思路
3.落地实践
4.应用案例
5.未来规划
一、建设背景
顺丰是国内领先的快递物流综合服务商，经过多年的发展，顺丰使用大数据技术支持高质量的物流服务。以下是一票快件的流转过程，可以看到从客户下单到最终客户收件的整个过程是非常长的，其中涉及的一些处理逻辑也比较复杂。为了应对复杂业务的挑战，顺丰进行了数据仓库的探索。
传统数仓主要分为离线和实时两个部分。
离线部分以固定的计算逻辑，通过定时调度，完成数据抽取，清洗，计算，最后产出报表；而实时部分则是需求驱动的，用户需要什么，就马上着手开发。
这种数仓架构在数据量小、对实时性要求不高的情况下运行得很好。然而随着业务的发展，数据规模的扩大和实时需求的不断增长，传统数仓的缺点也被放大了。
从业务指标的开发效率来看
实时指标采用的是需求驱动的、纵向烟囱式的开发模式，需要用户手写Flink任务进行开发，这种开发方式效率低门槛高，输出的指标很难统一管理与复用。
从技术架构方面来看
离线和实时两套架构是不统一的，开发方式、运维方式、元数据方面都存在差异。传统架构整体还是以离线为主，实时为辅，依赖离线T+1调度导出报表，这些调度任务通常都运行在凌晨，导致凌晨时集群压力激增，可能会导致报表的产出不稳定；如果重要的报表产出有延迟，相应的下游的报表产出也会出现延迟。这种以离线为主的架构无法满足精细化、实时化运营的需要。
从平台管理的角度来看
传统数仓的实时指标开发是比较粗放的，没有Schma的规范，没有元数据的管理，也没有打通实时和离线数据之间的联系。
为了解决传统数仓的问题，顺丰开始了实时数仓的探索。实时数仓和离线数仓实际上解决的都是相同的业务问题，最大的区别就在于时效性。
离线数仓有小时级或天级的延迟；而实时数仓则是秒级或分钟级的延迟。
其他特性，比如数据源、数据存储以及开发方式都是比较相近的。因此，我们希望：
用户能从传统数仓平滑迁移到实时数仓，保持良好的体验；同时统一实时和离线架构，加快数据产出，减少开发的撕裂感；加强平台治理，降低用户使用门槛，提高开发效率也是我们的目标。
二、建设思路
经过总结，我们提炼出以下3个实时数仓的建设思路。首先是通过统一数仓标准、元数据以及开发流程，使得用户达到开发体验上的批流统一。随后，引入Hudi加速数仓宽表，基于FlinkSQL建设我们的实时数仓。最后是加强平台治理，进行数仓平台化建设，实现数据统一接入、统一开发、以及统一的元数据管理。
1.批流统一的实时数仓
建设批流统一的实时数仓可以分为以下3个阶段：
1.1统一数仓规范
首先，无规矩不成方圆，建设数仓必须有统一的数仓规范。统一的数仓规范包括以下几个部分：
设计规范命名规范模型规范开发规范存储规范流程规范
统一好数仓规范之后，开始数仓层级的划分，将实时和离线统一规划数仓层级，分为ODS、DWD、DWS、ADS层。
1.2统一元数据
基于以上统一的数仓规范和层级划分模型，可以将实时和离线的元数据进行统一管理。下游的数据治理过程，比如数据字典、数据血缘、数据质量、权限管理等都可以达到统一。这种统一可以沉淀实时数仓的建设成果，使数仓能更好的落地实施。
1.3基于SQL统一开发流程
开发人员都知道，使用DataStramAPI开发Flink任务是比较复杂的。在数据量比较大的情况下，如果用户使用API不规范或者开发能力不足，可能会导致性能和稳定性的问题。如果我们能将实时开发的过程统一到SQL上，就可以达到减少用户开发成本、学习成本以及运维成本的目的。
之前提到过我们已经统一了实时和离线的元数据，那么就可以将上图左边的异构数据源和数据存储抽象成统一的Tabl，然后使用SQL进行统一的数仓开发，也就是将离线批处理、实时流处理以及OLAP查询统一SQL化。
1.4实时数仓方案对比
完成了数仓规范、元数据、开发流程的统一之后，我们开始探索数仓架构的具体架构方案。业界目前的主流是Lambda架构和Kappa架构。
Lambda架构
Lambda架构是在原有离线数仓的基础上，将对实时性要求比较高的部分剥离出来，增加了一个实时速度层。Lambda架构的缺点是需要维护实时和离线两套架构和两套开发逻辑，维护成本比较高，另外两套架构带来的资源消耗也是比较大的。
Kappa架构
为了应对Lambda架构的缺陷，JayKrps提出了Kappa架构，Kappa架构移除了原有的离线部分，使用纯流式引擎开发。Kappa架构的最大问题是，流数据重放处理时的吞吐能力达不到批处理的级别，导致重放时产生一定的延时。
实时数仓方案对比与实际需求
在真实的生产实践中，并不是一定要严格遵循规范的Lambda架构或Kappa架构，可以是两者的混合。比如大部分指标使用流式引擎开发，少部分重要的指标使用批处理开发，并增加数据校对的过程。
在顺丰的业务场景中，并非所有用户都需要纯实时的表，许多用户的报表还是依赖离线T+1调度产出的宽表，如果我们能够加速宽表的产出，那么其他报表的时效性也能相应地得到提高。
另外，这个离线T+1调度产出的宽表，需要聚合45天内多个数据源的全量数据，不管是Lambda架构还是Kappa架构，都需要对数据进行全量聚合，如果能够直接更新宽表，就可以避免全量重新计算，大大降低资源消耗和延时。
2.引入Hudi加速宽表
之前说过，维护Lambda架构的复杂性在于需要同时维护实时和离线两套系统架构。而对于这个缺点，我们可以通过批流统一来克服。
经过权衡，我们决定改造原有Lambda架构，通过加速它的离线部分来建设数仓宽表。此时，就需要一个工具来实时快速的更新和删除Hiv表，支持ACID特性，支持历史数据的重放。基于这样的需求，我们调研了市面上的三款开源组件：DltaLak、Icbrg、Hudi，最后选择Hudi来加速宽表。
2.1Hudi关键特性
Hudi的关键特性包括：可回溯历史数据，支持在大规模数据集中根据主键更新删除数据；支持数据增量消费；支持HDFS小文件压缩。这些特性恰好能满足我们的需求。
2.2引入Hudi加速宽表
引入Hudi有两种方式加速数仓。首先，在ODS层引入Hudi实现实时数据接入，将ODS层T+1的全量数据抽取改成T+0的实时接入，从数据源头实现Hiv表的加速。
另外，使用Flink消费Kafka中接入的数据，进行清洗聚合，通过Hudi增量更新DWD层的Hiv宽表，将宽表从离线加速成准实时。
2.3构建实时数仓宽表示例
这里通过一个例子介绍如何构建实时数仓宽表。
假设运单宽表由运单表，订单表和用户表组成，分别包含运单号、运单状态、订单号、订单状态、用户ID、用户名等字段。
首先将运单表数据插入宽表，运单号作为宽表主键，并且将运单号和订单号的映射存入临时表。当订单表数据更新后，首先关联用户维表，获取用户名，再从临时表中获取对应运单号。最后根据运单号将订单表数据增量插入宽表，以更新宽表状态。
3.最终架构
引入Hudi后，基于Lambda架构，我们定制化的实时数仓最终架构如下图所示。实时速度层通过CDC接入数据到Kafka，采用FlinkSQL处理Kafka中的数据，并将ODS层Kafka数据清洗计算后通过Hudi准实时更新DWD层的宽表，以加速宽表的产出。离线层采用Hiv存储及处理。最后由ADS层提供统一的数据存储与服务。
除了制定数仓标准和构建数仓架构，我们还需要构建数仓平台来约束开发规范和流程，提升开发效率，提高用户体验。
站在数据开发人员的角度，我们不仅要提供快速的数据接入能力，还需要