美团实时数仓架构的演进史.docx

《美团实时数仓架构的演进史.docx》由会员分享，可在线阅读，更多相关《美团实时数仓架构的演进史.docx（24页珍藏版）》请在第一文库网上搜索。

1、美团实时数仓架构的演进史，千亿级数据导读：今天和大家分享一下实时数据在美团的典型应用场景，实时数仓建设中的挑战和解决方案，包括一些关键的设计细节。主要介绍以下几方面内容：建设背景平台架构设计平台建设实践未来计划01建设背景1、实时数据在美团的典型应用场景I业务背景业务形态多：超30条独立业务线场景丰富：Bk算法、调度、事件处理各业务成熟度不同实时数据依赖度高DataFunSummit美团作为本地生活领域的头部公司，在内部孵化了许多独立业务，可以看到有大家所熟悉的美团外卖、酒店、美团优选等，这些业务通过实时数据来支撑其内部各种各样的数据应用场景，比如BI、算法、骑手调度等等。|典型业务场景指标监

2、控：商品库存监控、商家经营报表实时特征：骑手调度、搜索、推荐、广告CTR预估事件处理：客服判责、运营发券、反爬风控数据对账：跨业务数据核对梳理业务场景（做什么）件驱动场业务鼻常波动剜,行为越控活动条件触发敷据分析场量 实时编场沙盘 铜目标修测 交互式分析（即需置询） B有分析散排交换场景-HSL根界、豆败骞算法时间窗口触发条件数据处理的本质/（）=算法X =数据数据最新状态数据查询条件业务数据E11DataFunSummit我们对业务场景做了 个简单的分类:指标监控：比如有实时大盘，用来即时反馈业务当日运转的健康度等场景;实时特征：比如搜索、广告CTR预估、骑手调度等，对算法特征数据新鲜度要求

3、较高的场景;事件处理：比如一些风控类、运营活动发券等事件驱动型场景;数据对账：比如金融的支付业务，支付部门与业务部门各自独立，当业务部门的支付单据与支付部门不一致时，会造成资损，这时数据的实时对账就非常关键。I平台现状支撑业务数任务总数集群节点数QPS峰值DataFunSummit上图可以看到，截至目前，实时计算平台所支撑的实时数据处理场景的整体规模，说明实时数据在美团己经影响到了业务的方方面面。I发展历程作业托管平台上线OneSQL化开发平台上线平台化OOo计算引擎201420172019Storm 上线Flink 1.6 上线升级 Flink 1.9Spark Streaming 上线Fl

4、ink SQL 上线Flink HA 改造Spark Streaming 下线统一数仓建模方式O2021升级 Flink 1.12数仓增量化生产流批语义层统一DataFunSummit实时计算平台从成立以来，经历了上图中的几个关键发展阶段。平台正式成立于2014年，我们引入Storm和Spark Streaming作为美团的第一代实时计算引擎，并且发布了第一版作业托管平台。接下来在2017年，平台正式引进了 Flink,并开始初步探索以Flink SQL为主的实时数仓开发方式。并于2019年，正式将Flink SQL作为主要编程接口暴露给业务，将以任务为中心的开发模式，升级为以数据为中心的开发

5、模式。当前，计算平台紧跟业界发展潮流，将工作内容都聚焦在数仓增量化生产、流批语义统一、统一实时离线数仓建模方式等几个方向上。|建设初期问题回顾实时收据建设视角以任务为中心,实时微掘作为离线般仓的加速层而存生2、实时数仓建设过程中的问题及痛点问题开发、运维成本高 Java/Scaia 计H框架API的学习门施,影响迭代效率. 代码本地开发，堆调试，正式环境数据Case遭覆盖. 生产杨路横跨多业务，数据协议出现不统一,会引入颔外的成本.理成本高- 数仓建设流程无规范，鳄业务合作缺少一致性语境，沟通成本高.- 数据建设无抽象、分屉,数据选复用，大烟囱,造成资源浪费.- 元数据缺失，管理者雄以整体把控

6、数嵬的建设质8LDataFunSummit在正式开始介绍数仓平台的建设实践之前，先来回顾下平台初期所遇到的问题。实时数据开始建设之初，是没有离线数仓那样成熟的建设方法论的，而且也没有离线数仓领域那样成熟的开发工具，所以带来了以下儿点问题:首先就是高昂的开发运维成本，每次计算框架的升级，业务都需要学习一遍计算框架的APT。代码本地开发，再去线上调试，本地的case难以覆盖线上的数据问题。业务各自的数据协议不统一，相互之间进行数据交换，沟通协作的成本也是比较高昂的。数仓的建设方式没有统一规范，导致数据的冗余和重复建设，给后期的资源治理带来了非常大的麻烦。I建设路线数仓开发迭代效率作业平滑升18动卷

7、里新作业配ttamraConnectorDataFunSummit从上面的问题出发，我们制定了平台的建设路线。主要集中在两个层面，首先是降低业务的开发运维门槛，让实时数仓开发可以像离线数仓开发那样简单高效。比如我们提供了标准的ETL作业模板，web集成开发环境，并且扩展了 SQL的能力，使业务可以尽量以符合其认知的形式去进行代码开发。还有数仓建设中业务最关心的数据质量问题，我们也提供了相应的配套工具，帮助业务以尽可能低的成本将可靠的数据交付应用方。可用性在离线数仓建设过程中可能大多体现在数据是否按时就绪，那么实时数仓对数据的时延要求更高，所以可用性的保障也非常关键。前面提到的都是在开发运维效率

8、方面我们所做的一些建设规划，在大数据领域，一个底层算子性能的小小改进，都会使执行效率成倍的放大，所以我们也会花费一些精力在底层算子的优化上。两横三纵，其中两横包括开发迭代效率，而向人的优化，重点在于对工作流。三纵包括能做（看得见、摸得着的问题）、做好和最优化。02平台架构设计接下来开始着重介绍我们是如何解决上面所提到的问题的。首先从整体上来介绍下平价解决上面问题的思路。I平台整体架构应用服务 H 三 日 h 曰 rrTDataFunSummit上图是平台整体架构。从下向上来看，存储、计算、调度加上口志服务构成了我们的基础服务层。基础服务层之上是平台对业务提供的一些中间件。上层是平台抽象出的一些

9、可自行组合的微服务集合，比如作业模板服务、UDF托管服务、元数据服务、指标采集监控、数据质量管理等，这些服务业务可以按自身的场景需要来在自己的业务内部自行组合，也可以直接使用平台包装好的大而全的集成开发平台。I计算框架选型无理论上用prestoOOMySQLSctwmaSQL/DSLTableFormat在“时效性”的基就之上,业务希望的是使用尽可能低的成本来交付正确的数据.有明旗的献力核分析维度关键项目Apache RinkSpark StreamingApache StormStorm Trident计算畏型话靛模式.Stream|b4ircoBatchStreamMircoBatch状态

10、量理有$无有语义保证Exactly Oncexactly OnceAt Least OnceExactly One运程Bi型编程模型;SQL/DSL/命令式令式命令式命令式性能吞吐虱高F低中到高（取次于分布式事为存标的吞吐延迟.非常低非常低低（事务延迟）可用性容错开销低离取决于分布式册务存储的吞吐量流控制i自然有问题自然DataFunSummit上图展示了平台基础服务中最关键的计算服务的选型过程。实时数仓场景的最根木业务诉求是数据的时效性，这里的时效性通常指的是秒级的延迟，所以这里Flink和Storm胜出。其次是数据的正确性,Fl ink是这里唯一能够保证Exectly-Once计算语义的框

11、架,所以Fl ink要优stornu之后我们有做了 benchmark测试，通过实验证明了，在绝大多数场景下Flink任务的吞吐要优于Storm,而且Fl ink还提供了更加成熟的SQL编程接口，所以我们最终确认选择Flink作为实时数仓的核心计算框架。I对齐数仓概念DataFunSummit解决了计算框架的问题，接下来我们要从上层概念入手，让熟悉离线数仓开发的同学能够更快的上手实时数仓的开发。从下向上看,我们先统一了离线和实时数仓的数据模型,无论是HiveTable、KafkaTopic,Redis的一个域，在上层暴露给业务的都是一张Table,这样业务没有过多认知上的负担了,可以在不同开发

12、场景的概念之间轻松切换。从上向下看，我们又统一了编程接口，使用SQL作为数仓开发的首选，这样实时和离线数仓的ETL逻辑甚至可以完全共用一套，对开发效率上也有显著的提升。I统一编程接口业务只需关心正确的裳达计宜逻辑,如何实现交由平台负责.SOL ServiceStage-2原始SQL指定Runner可执行脚本DataFunSummit有同学可能会问，实时和离线场景的计算语义不完全相同，实时计算场景需要包含大量跟时态相关的语法，比如window, interval等，离线场景上没有，那么怎么统一呢？的确如此，所以我们独立出一套SQL服务，短期用户也可以在SQL中加入HINT提升或者是直接提供一些参

13、数，来告诉我们这是什么离线还是实时场景的ETL,未来我们会自动根据业务的输入、输出表的存储类型，ETL的模式，自动判断使用哪种类型的执行模式更有效。跟社区如果对不齐怎么办：先对内解问题，如果效果真的不错，可以推回社区，如果社区有更好的方案，我们可以判断是否能够morgc进来，如果不行，说明我们的架构设计本身就是有问题的。03平台建设实践1、实时数仓开发解决方案I平台定位集”需求准备 开发测试一发布。运维监控”需求准备OOS懵入模型接入接入或新RD帼关创建模型订阅模型引用或订阅模型ODSRI已 HI能力的一站式数仓开发解决方案.DataFunSummit我们对数仓平台的定位是：集需求准备、开发测

14、试、发布和运维监控能力的一站式实时数仓生产解决方案。下面简单来介绍一下用户在平台上的工作流程。在需求准备阶段，用户可以结合业务需求先来检索是否有满足需求的数据模型，如果没有找到，那么可以选择从源头开始接入，或者新建模型。模型接入或创建好之后，进入ETL开发阶段，开发过程可能会伴随着一些简单的任务调试，这些工作也全部都可以在平台上完成。在开发完成准备上线之前，用户可以创建一条发布流水线，这块内容后面还有详细的介绍,待流水线执行通过后，就可以正式发布作业了，作业上线后，平台会自动收集作.业的运行时指标，用来监控作业的运行状态。I数仓接入流程标准化实时数仓离线数仓对比离线入仓流程，实时入仓过程突出了一个“乱”字.问题- 没有分层规范，项目组成员后续建模不知从何入手.- 入仓流程无系统化管理，同Tm据可能反复被接入多次.- 接入任务通常没有业务逻揖，可系统化化，标准化，业务不应投入过多精力去维护.DataFunSummit下面介绍下，平台是如何规范业务的数仓接