wordpress 网站底部美化,天津seo排名扣费,青岛做网站建设哪家好,菠菜网站建设简介#xff1a; 本文由美团研究员、实时计算负责人鞠大升分享#xff0c;主要介绍 Flink 助力美团数仓增量生产的应用实践。内容包括#xff1a;1、数仓增量生产#xff1b;2、流式数据集成#xff1b;3、流式数据处理#xff1b;4、流式 OLAP 应用#xff1b;5、未来规… 简介 本文由美团研究员、实时计算负责人鞠大升分享主要介绍 Flink 助力美团数仓增量生产的应用实践。内容包括1、数仓增量生产2、流式数据集成3、流式数据处理4、流式 OLAP 应用5、未来规划。 一、数仓增量生产
1.美团数仓架构
先介绍一下美团数仓的架构以及增量生产。如下图所示这是美团数仓的简单架构我把它叫做三横四纵。所谓三横第一是贯穿全链路的元数据以及血缘贯穿数据集成、数据处理、数据消费、以及数据应用的全过程链路。另外一块贯穿全链路的是数据安全包括受限域的认证系统、权限系统、整体的审计系统。根据数据的流向我们把数据处理的过程分为数据集成、数据处理、数据消费、以及数据应用这 4 个阶段。
在数据集成阶段我们对于公司内部的比如说用户行为数据、日志数据、DB 数据、还有文件数据都有相应的集成的系统把数据统一到我们的数据处理的存储中比如说 Kafka 中。 在数据处理阶段分为流式处理链路、批处理链路以及基于这套链路的数仓工作平台万象平台。生产出来的数据经过 Datalink 导入到消费的存储中最终通过应用以不同的形式呈现出来。
我们目前在 Flink 上面应用比较广泛的地方包括从 Kafka 把数据导到 Hive包括实时的处理数据导出的过程。今天的分享就集中在这些方面。 2.美团 Flink 应用概况
美团的 Flink 目前大概有 6000 台左右的物理机支撑了 3 万左右的作业。我们消费的 Topic 数在 5 万左右每天的高峰流量在 1.8 亿条每秒这样的水平上。 3.美团 Flink 应用场景
美团 Flink 主要应用的场景包括四大块。
第一实时数仓、经营分析、运营分析、实时营销。第二推荐、搜索。第三风控、系统监控。第四安全审计。4.实时数仓 vs 数仓增量生产
接下来我要引入增量生产的概念。离线数仓关注的三块需求第一个就是时效性。第二个就是质量产出的数据的质量。第三个就是成本。
关于时效性有两个更深层次的含义第一个叫做实时第二个叫准时。并不是所有的业务需求都是实时的很多时候我们的需求是准时。比如做经营分析每天拿到相应的昨天的经营数据情况即可。实时数仓更多的是解决实时方面的需求。但是在准时这一块作为一个企业更希望在准时跟成本之间做一个权衡。所以我把数仓的增量生产定义为对离线数仓的一个关于准时跟成本的权衡。另外数仓增量生产解决比较好的一个方面是质量问题能够及时发现。 5.数仓增量生产的优势
数仓增量生产的优势有两点。
能够及时发现数据质量问题避免 T1 修复数据。充分利用资源提前数据产出时间。
如下图所示我们期望做的实际上是第二幅图。我们期望把离线的生产占用的资源降低但同时希望它的产出时间能够提前一步。 二、流式数据集成
1.数据集成 V1.0
我们来看一下流式数据集成的第一代。当数据量非常小以及库非常少的时候直接做一个批的传输系统。在每天凌晨的时候把相应的 DB 数据全部 load 一遍导到数仓里面。这个架构优势是非常简单易于维护但是它的缺点也非常明显对于一些大的 DB 或者大的数据load 数据的时间可能需要 2~3 个小时非常影响离线数仓的产出时间。 2.数据集成 V2.0
基于这个架构我们增加了流式传递的链路我们会有经过流式传输的采集系统把相应的 Binlog 采集到 Kafka同时会经过一个 Kafka 2 Hive 的程序把它导入到原始数据再经过一层 Merge产出下游需要的 ODS 数据。
数据集成 V2.0 的优势是非常明显的我们把数据传输的时间放到了 T0 这一天去做在第二天的时候只需要去做一次 merge 就可以了。这个时间可能就从 2~3 个小时减少到一个小时了节省出来的时间是非常可观的。 3.数据集成 V3.0
在形式上数据集成的第三代架构前面是没什么变化的因为它本身已经做到了流式的传输。关键是后面 merge 的流程。每天凌晨 merge 一个小时仍然是非常浪费时间资源的甚至对于 HDFS 的压力都会非常大。所以在这块我们就迭代了 HIDI 架构。
这是我们内部基于 HDFS 做的。 4.HIDI
我们设计 HIDI核心的诉求有四点。第一支持 Flink 引擎读写。第二通过 MOR 模式支持基于主键的 Upsert/Delete。第三小文件管理 Compaction。第四支持 Table Schema。 基于这些考虑我们来对比一下 HIDIHudi 和 Iceberg。
HIDI 的优势包括
支持基于主键的 Upsert/Delete支持和 Flink 集成小文件管理 Compaction
劣势包括不支持增量读。
Hudi 的优势包括
支持基于主键的 Upsert/Delete小文件管理 Compaction
劣势包括
写入限定 Spark/DeltaStreamer流读写支持 SparkStreaming
Iceberg 的优势包括 支持和 Flink 集成。
劣势包括
支持基于 Join 的 Upsert/Delete流式读取未支持。5.流式数据集成效果
如下图所示我们有数据产生数据集成ETL 生产三个阶段。把流式数据集成做到 T0ETL 的生产就可以提前了节省了我们的成本。 三、流式数据处理
1.ETL 增量生产
我们来讲一下 ETL 的增量生产过程。我们的数据从前面进来到 Kafka 之后有 Flink 实时然后到 Kafka再到事件的服务甚至到分析的场景中这是我们自己做的分析链路。
下面是批处理的一个链路我们通过 Flink 的集成集成到 HDFS然后通过 Spark 去做离线生产再经过 Flink 把它导出到 OLAP 的应用中。在这样的架构中增量的生产实际上就是下图标记为绿色的部分我们期望用 Flink 的增量生产的结构去替换掉 Spark。 2.SQL 化是 ETL 增量生产的第一步
这样的一个架构有三个核心的能力。
第一 Flink 的 SQL 的能力要对齐 Spark。第二 我们的 Table Format 这一层需要能够支持 Upsert/Delete 这样的主键更新的实时操作。第三 我们的 Table Format 能够支持全量和增量的读取。
我们的全量用于查询和修复数据而我们的增量是用来进行增量的生产。SQL 化是 ETL 增量生产的第一步今天分享的主要是说我们基于 Flink SQL 做的实时数仓平台对这一块的支持。 3.实时数仓模型
如下图所示这是实时数仓的模型。业界应该都看过这样的一个模型。 4.实时数仓平台架构
实时数仓的平台架构分为资源层、存储层、引擎层、SQL 层、平台层、还有应用层。在这里重点强调两点。
第一是对于 UDF 的支持。因为 UDF 是弥补算子能力中的非常重要的一环我们希望在这里面做的 UDF 能够加大对于 SQL 能力的支持。第二是在这个架构里面只支持了 Flink Streaming 的能力我们并没有去做 Flink 的批处理的能力因为我们设想未来所有的架构都是基于 streaming 去做的这跟社区的发展方向也是一致的。5.实时数仓平台 Web IDE
这是我们数仓平台的一个 Web IDE。在这样的一个 IDE我们支持了一个 SQL 的建模的过程支持了 ETL 的开发的能力。 四、流式 OLAP 应用
1.异构数据源同步
下面看关于流式的导出跟 OLAP 的应用这一块。如下图所示是异构数据源的同步图。业界有很多开源的产品做这一块。比如说不同的存储里面数据总是在其中进行交换。我们的想法是做一个 Datalink 这样的一个中间件或者是中间的平台。然后我们把 N 对 N 的数据交换的过程抽象成一个 N 对 1 的交换过程。 2.基于 DataX 的同步架构
异构数据源的第一版是基于 DataX 来做同步的架构。在这套架构里面包含了工具平台层、调度层、执行层。
工具平台层的任务非常简单主要是对接用户配置同步任务配置调度运维。调度层负责的是任务的调度当然对于任务的状态管理以及执行机的管理很多的工作都需要我们自己去做。 在真正的执行层通过 DataX 的进程以及 Task 多线程的一个形式真正执行把数据从源同步到目的地。在这样的一个架构里面发现两个核心的问题。第一个问题就是扩展性的问题。开源的单机版的 DataX 是一个单机多线程的模型当我们需要传输的数据量非常大的时候单机多线程模型的可扩展性是很大的问题。第二个问题在调度层我们需要去管理机器、同步的状态、同步的任务这个工作非常繁琐。当我们的调度执行机发生故障的时候整个灾备都需要我们单独去做这块的事情。3.基于 Flink 的同步架构
基于这样的架构我们把它改成了一个 Flink 的同步的架构。前面不变还是工具平台层。在原有的架构里面我们把调度层里面关于任务调度和执行机的管理这一块都交给了 Yarn 去做这样我们就从中解脱出来了。第二个我们在调度层里面的任务状态管理可以直接迁移到 cluster 里面去。
基于 Flink 的 Datalink 的架构优势非常明显。
第一 可扩展性问题得到解决了同时架构也非常简单。现在当我们把一个同步的任务拆细之后它在 TaskManager 里面可以扩散到分布式的集群中。第二 离线跟实时的同步任务都统一到了 Flink 框架。我们所有同步的 Source 和 Sink 的主键都可以进行共用这是非常大的一个优势。3.基于 Flink 的同步架构关键设计
我们看一下基于 Flink 的同步架构的关键设计这里总结的经验有四点。
第一避免跨 TaskManager 的 Shuffle避免不必要的序列化成本第二务必设计脏数据收集旁路和失败反馈机制第三利用 Flink 的 Accumulators 对批任务设计优雅退出机制第四利用 S3 统一管理 Reader/Writer 插件分布式热加载提升部署效率。4.基于 Flink 的 OLAP 生产平台
基于 Flink 我们做了 Datalink 这样的一个数据导出的平台基于 Datalink 的导出平台做了 OLAP 的生产平台在这边除了底层的引擎层之外我们做了平台层。在这上面我们对于资源、模型、任务、权限都做了相应的管理使得我们进行 OLAP 的生产非常快捷。 这是我们的 OLAP 生产的两个截图。一个是对于 OLAP 中的模型的管理一个是对于 OLAP 中的任务配置的管理。 五、未来规划
经过相应的迭代我们把 Flink 用到了数据集成、数据处理、离线数据的导出以及 OLAP 生产的过程中。我们期望未来对于流批的处理能够是统一的希望数据也是流批统一的。我们希望不管是实时的链路还是增量处理的链路在未来数据统一之后统一用 Flink 处理达到真正的流批一体。 作者阿里云实时计算Flink
原文链接
本文为阿里云原创内容未经允许不得转载
