Flink 在顺丰的应用实践

阿里云云栖号

于 2021-09-02 14:36:55 发布

阅读量1k

点赞数 2

本文链接：https://blog.csdn.net/yunqiinsight/article/details/120060097

版权

简介： 顺丰基于 Flink 建设实时数仓的思路，引入 Hudi On Flink 加速数仓宽表，以及实时数仓平台化建设的实践。

本⽂由社区志愿者苗文婷整理，内容源⾃顺丰科技大数据平台研发工程师龙逸尘在 Flink Forward Asia 2020 分享的《Flink 在顺丰的应用实践》，主要分享内容为：顺丰基于 Flink 建设实时数仓的思路，引入 Hudi On Flink 加速数仓宽表，以及实时数仓平台化建设的实践。分为以下 5 个部分：

建设背景

建设思路

落地实践

应用案例

未来规划

一、建设背景

顺丰是国内领先的快递物流综合服务商，经过多年的发展，顺丰使用大数据技术支持高质量的物流服务。以下是一票快件的流转过程，可以看到从客户下单到最终客户收件的整个过程是非常长的，其中涉及的一些处理逻辑也比较复杂。为了应对复杂业务的挑战，顺丰进行了数据仓库的探索。

传统数仓主要分为离线和实时两个部分。

离线部分以固定的计算逻辑，通过定时调度，完成数据抽取，清洗，计算，最后产出报表；
而实时部分则是需求驱动的，用户需要什么，就马上着手开发。

这种数仓架构在数据量小、对实时性要求不高的情况下运行得很好。然而随着业务的发展，数据规模的扩大和实时需求的不断增长，传统数仓的缺点也被放大了。

从业务指标的开发效率来看

实时指标采用的是需求驱动的、纵向烟囱式的开发模式，需要用户手写 Flink 任务进行开发，这种开发方式效率低门槛高，输出的指标很难统一管理与复用。

从技术架构方面来看

离线和实时两套架构是不统一的，开发方式、运维方式、元数据方面都存在差异。传统架构整体还是以离线为主，实时为辅，依赖离线 T+1 调度导出报表，这些调度任务通常都运行在凌晨，导致凌晨时集群压力激增，可能会导致报表的产出不稳定；如果重要的报表产出有延迟，相应的下游的报表产出也会出现延迟。这种以离线为主的架构无法满足精细化、实时化运营的需要。

从平台管理的角度来看

传统数仓的实时指标开发是比较粗放的，没有 Schema 的规范，没有元数据的管理，也没有打通实时和离线数据之间的联系。

为了解决传统数仓的问题，顺丰开始了实时数仓的探索。实时数仓和离线数仓实际上解决的都是相同的业务问题，最大的区别就在于时效性。

离线数仓有小时级或天级的延迟；
而实时数仓则是秒级或分钟级的延迟。

其他特性，比如数据源、数据存储以及开发方式都是比较相近的。因此，我们希望：

用户能从传统数仓平滑迁移到实时数仓，保持良好的体验；
同时统一实时和离线架构，加快数据产出，减少开发的撕裂感；
加强平台治理，降低用户使用门槛，提高开发效率也是我们的目标。

二、建设思路

经过总结，我们提炼出以下 3 个实时数仓的建设思路。首先是通过统一数仓标准、元数据以及开发流程，使得用户达到开发体验上的批流统一。随后，引入 Hudi 加速数仓宽表，基于 Flink SQL 建设我们的实时数仓。最后是加强平台治理，进行数仓平台化建设，实现数据统一接入、统一开发、以及统一的元数据管理。