从 Storm 迁移到 Flink,美团外卖实时数仓建设实践

来源:Flink中文社区
地址:
本文主要介绍一种通用的实时数仓构建的方法与实践 。 实时数仓以端到端低延迟、SQL 标准化、快速响应变化、数据统一为目标 。
在实践中 , 我们总结的最佳实践是:一个通用的实时生产平台 + 一个通用交互式实时分析引擎相互配合同时满足实时和准实时业务场景 。 两者合理分工 , 互相补充 , 形成易于开发、易于维护、效率最高的流水线 , 兼顾开发效率与生产成本 , 以较好的投入产出比满足业务多样需求 。
01 实时场景
从 Storm 迁移到 Flink,美团外卖实时数仓建设实践文章插图
实时数据在美团外卖的场景是非常多的 , 主要有以下几点:

  • 运营层面:比如实时业务变化 , 实时营销效果 , 当日营业情况以及当日实时业务趋势分析等 。
  • 生产层面:比如实时系统是否可靠 , 系统是否稳定 , 实时监控系统的健康状况等 。
  • C 端用户:比如搜索推荐排序 , 需要实时了解用户的想法 , 行为、特点 , 给用户推荐更加关注的内容 。
  • 风控侧:在外卖以及金融科技用的是非常多的 , 实时风险识别 , 反欺诈 , 异常交易等 , 都是大量应用实时数据的场景
02 实时技术及架构1. 实时计算技术选型
从 Storm 迁移到 Flink,美团外卖实时数仓建设实践文章插图
目前开源的实时技术比较多 , 比较通用的是 Storm、Spark Streaming 以及 Flink , 具体要根据不同公司的业务情况进行选型 。
美团外卖是依托美团整体的基础数据体系建设 , 从技术成熟度来讲 , 前几年用的是 Storm , Storm 当时在性能稳定性、可靠性以及扩展性上是无可替代的 , 随着 Flink 越来越成熟 , 从技术性能上以及框架设计优势上已经超越Storm , 从趋势来讲就像 Spark 替代 MR 一样 , Storm 也会慢慢被 Flink 替代 , 当然从 Storm 迁移到 Flink 会有一个过程 , 我们目前有一些老的任务仍然在 Storm 上 , 也在不断推进任务迁移 。
具体 Storm 和 Flink 的对比可以参考上图表格 。
2. 实时架构① Lambda 架构
从 Storm 迁移到 Flink,美团外卖实时数仓建设实践文章插图
【从 Storm 迁移到 Flink,美团外卖实时数仓建设实践】Lambda 架构是比较经典的架构 , 以前实时的场景不是很多 , 以离线为主 , 当附加了实时场景后 , 由于离线和实时的时效性不同 , 导致技术生态是不一样的 。 Lambda 架构相当于附加了一条实时生产链路 , 在应用层面进行一个整合 , 双路生产 , 各自独立 。 这在业务应用中也是顺理成章采用的一种方式 。
双路生产会存在一些问题 , 比如加工逻辑 double , 开发运维也会 double , 资源同样会变成两个资源链路 。 因为存在以上问题 , 所以又演进了一个 Kappa 架构 。
② Kappa 架构
从 Storm 迁移到 Flink,美团外卖实时数仓建设实践文章插图
Kappa 架构从架构设计来讲比较简单 , 生产统一 , 一套逻辑同时生产离线和实时 。 但是在实际应用场景有比较大的局限性 , 在业内直接用 Kappa 架构生产落地的案例不多见 , 且场景比较单一 。 这些问题在我们这边同样会遇到 , 我们也会有自己的一些思考 , 在后面会讲到 。
03 业务痛点
从 Storm 迁移到 Flink,美团外卖实时数仓建设实践文章插图
在外卖业务上 , 我们也遇到了一些问题 。
业务早期 , 为了满足业务需要 , 一般是拿到需求后 case by case 的先把需求完成 , 业务对于实时性要求是很高的 , 从时效性来说 , 没有进行中间层沉淀的机会 , 在这种场景下 , 一般是拿到业务逻辑直接嵌入 , 这是能想到的简单有效的方法 , 在业务发展初期这种开发模式比较常见 。