Flink 助力美团数仓增量生产

知乎 · · 1493 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

一、美团数仓架构图



如上图,是美团最新的数仓架构图。

整个架构图分为三层,从下往上看,最下面一层是数据安全,包括受限域认证系统、加工层权限系统,应用层权限系统,安全审计系统,来保证最上层数据集成与处理的安全;

中间一层是统一的元数据中心和全链路血缘,覆盖了全链路的加工过程;

最上层根据数据的流向,分成数据集成,数据处理,数据消费,数据应用,四个阶段;

在数据集成阶段,对于不同的数据来源(包括用户行为数据,日志数据,DB 数据,文件数据),都有相对应的数据集成系统,把数据收集到统一的存储之中,包括 Kafka 和 Hive 等。

在数据处理阶段,有一个面向用户的数据开发平台(万象平台),可以使用两条数据处理链路来加工数据,一个是流式处理链路,一个是离线处理链路。

数据加工好了之后,使用内部自研的 DeltaLink 同步数据到其他的应用中,例如即席分析,即席查询,报表等应用。

上图中标红的地方,Kafka -> HDFS,Flink,DeltaLink 是本次重点分享的内容。

二、美团当前 Flink 应用场景和规模

美团 Flink 应用场景包括:

  • 实时数仓、经营分析、运营分析、实时营销
  • 推荐、搜索
  • 风控、系统监控
  • 安全审计

Flink 集群规模如下(高峰流量是每天最高峰的流量):


三、基于 Flink 的流式数据集成

数据集成经历了多个版本的迭代

1. 数据集成 V1.0

V1.0 版本很简单,是完全批量同步的架构。

在数据量比较少的情况下,这样的批同步的架构,优势很明显,架构简单,非常简单易于维护。

但是缺点也很明显,光是数据传输就 1 - 2 个小时。

2. 数据集成 V2.0

在 V2.0 中,增加了流式传输的链路(下面的链路),把数据实时传输到 ODS 中(批量传输的链路仍然是必须的,作为第一次全量的导入)。

流式传输系统,使用 canal (阿里开源) 采集 Mysql 的 binlog 日志到 kafka。后边有一个 Kafka2Hive 系统,这个系统经过了多个版本的迭代。

Kafka2Hive 模块,最开始是使用 Camus ,每一个小时拉一次数据,跑在 Spark 上。后面改成使用 SparkStreaming ,但是 Spark Streaming 在资源的利用方面有一些问题的,所以最终弄全部迁移到了 Flink 框架上来。

这样的架构,优势是非常明显的:把数据传输放在了 T+0 的时间去做,T + 1 的时间只需要经过一次 Merge 即可,花费的时间可能就从 2 - 3 个小时减少到 1 个小时了,提升是非常明显的。


3. 数据集成 V3.0

数据集成 V3.0 的架构,前面的部分和 V2.0 一样,关键的是后面这一部分。

在 V2.0 架构中,凌晨需要对数据做一次 Merge,这个操作对于 Hdfs 的压力非常大,要把几十 T 的数据读过来,清洗一遍,再把几十 T 的数据写入到 Hdfs。

所以,在 V3.0 架构中,引用了 Hidi 架构(Hidi 是美团内部基于 Hdfs 开发的类似 Hudi 或者 Iceberg 的文件格式)。


4. 美团自研的 Hidi

要做到增量生产,最关键的特性在于

  • 支持增量读取,也就是读取当前时间到前一段时间的数据, 才能做到增量;
  • 支持基于主键的 Upsert/Delete。

Hidi 是美团在 2,3 年前,在内部自研的架构,此架构的特性在于:

  • 支持 Flink 引擎读写;
  • 通过 MOR 模式支持基于主键的 upsert/Delete;
  • 小文件管理 Compaction;
  • Table Schema

可以对比 Hidi、Hudi、Iceberg,如下:


Hudi 最亮眼的特性是支持基于主键的 Upsert/Delete,但劣势是深度和 Spark 绑定,和 Flink 的集成尚未完善。

Iceberg 不依赖于执行引擎,可以深度和 Flink 集成。

美团自研的 Hidi 则根据自己的需求实现了诸多的特性,目前仍然在完善中。

四、基于 Flink 的增量生产

1、传统离线数仓特性分析

一般我们说数仓,都是指离线数仓。离线数仓有三个重要的指标,一是时效性,二是质量,三是成本。

首先是时效性,有两个更深层次的含义,一个是实时,一个是准时。

实时就是实时流式处理,来一条处理一条,实时处理消耗的资源很多。

准时,就是按时处理。比如广告需求,可能只需要在每个整点,统计过去一小时或者在每个整点统计当天的数据即可,没有必要做到实时,只需要到点能产出数据就行。

所以,总结下来,离线数仓和实时数仓各有利弊,离线数仓在质量和成本上会有优势,但是时效性不足;实时数仓,在时效性上很有优势,但是质量和成本都略逊色。


2. 增量生产

如下图,是离线数仓、实时数仓和增量计算的对比

所谓增量计算,就是企业在时效性、质量、成本上做一个权衡,时效性需要高一点,但是不用做到 RealTime,OnTime 也可以接受( 8 点看报表,提前到 3 点计算好也没有很大的意义),但是质量要高,成本也需要尽量少。

3. 增量计算的优点

增量计算最大的优点,就是可以尽快的发现问题。

一般我们会在第二天花 8 个小时到 12 个小时,把前一天的数据生产出来。但是如果第二天发现数据错了,可能要花一天的时间去修复数据,这个时候,准时性和质量都被打破了。

如下图,横坐标是时间(T 表示当天,T+1 表示第二天),黑色线表示离线生产,大概利用 T + 1 一半资源去生产。红色线是实时生产,在当天就生产数据,占用的资源比离线计算高。


下图是增量生产的示意图。

绿色线是增量计算,在当天就计算好。

黑色线是离线计算,在第二天的前半天计算。


增量计算,是在当天计算,在当天就能提前发现问题,避免 T + 1 修复数据。并且还可以充分利用资源,提前产出数据的时间,并且占用资源更少。

4. 增量生产架构图

下图是美团增量生产的架构图(目前的架构正在逐步完善中,还没有完全实现)

如图,最上面是实时处理的链路,Flink 消费 Kafka 数据 到 下游的 kafka,输出结果给下游使用或者供 OLAP 分析。

下面的链路是批处理,首先 kafka 数据经过 Flink 集成到 HDFS,再通过 Spark 做离线的生产,最终经过 Flink 导出到 OLAP 应用里面去。

上文提到的增量生产,就是图中标绿色的部分,希望可以用增量生产来替换掉 Spark 离线计算,做到计算引擎的统一。

要能支持增量生产,需要具备几个核心的能力:

  • Flink SQL 能力能够对齐 Spark SQL;
  • Hidi 支持 Upsert/Delete 特性(Hidi 已支持);
  • Hidi 支持全量和增量的读取,全量读取用于查询和修复数据,增量读取用来增量生产;

五、实时数仓模型与架构

如下图是实时数仓的模型,基本上都见过

下图是实时数仓平台的架构图


整个架构,分为资源层、存储层、引擎层、SQL 层、平台层和应用层。


六、流式导出与 OLAP 应用

1. 异构数据源的同步


如上图,是异构数据源的同步。数据会在不同的存储系统中交换,所以我们做了一个 Deltalink 的平台,把数据 N 对 N 的交换过程,抽象成 N 对 1 的交换过程。

我们也迭代改进了很多版本。

2. 第一版实现

第一版是基于 DataX (阿里开源)来做同步,包含工具平台层,调度层,执行层。

  • 工具平台层,对接用户,用来配置同步任务,配置调度,运维任务;
  • 调度层,负责任务的调度,管理任务状态管理,以及执行机的管理,这其中有非常多的额外工作都需要自己做;
  • 执行层,通过 DataX 进程,以及 Task 线程从源存储同步到目标存储。

但劣势也很明显,开源版的 DataX 是一个单机多线程的模型,当数据量非常大的时候,单机多线程是成为了瓶颈,限制了可扩展性;

然后在调度层,需要管理机器,管理同步的任务和状态,非常繁琐;

当调度执行机发生故障的时候,整个灾备都需要单独去做。

3. 第二版实现

在第二版中,改成了基于 Flink 同步的架构,看起来就清爽了很多。

工具平台层没有变,调度层的任务调度和执行机管理都交给 Yarn 去做。

调度层的任务状态管理,可以迁移到 Client 中去做。


基于 Flink 的 DeltaLink 的架构,解决了可扩展性问题,而且架构非常简单。

当把同步的任务拆细之后,可以分布式的分布到不同的 TaskManager 里去执行。


并且离线和实时的同步,都可以统一到 Flink 框架中去,这样离线和实时同步的 Source 和 Sink 组件都可以共用一套。


4. 基于 Flink 的同步架构关键设计

  1. 避免跨 TaskManager 的 Shuffle,避免不必要的序列化成本;

Source 和 Sink 尽量在同一个 TaskManager;

2. 务必设计脏数据收集旁路和失败反馈机制;

数据同步遇到脏数据的时候,比如失败了 1% 的时候,直接停下来;

3. 利用 Flink 的 Accumulators 对批任务设计优雅退出机制;

数据传输完之后,通知下游数据同步完了;

4. 利用 S3 统一管理 Reader/Writer 插件,分布式热加载,提升部署效率;

很多传输任务都是小任务,而作业部署时间又非常长,所以需要要提前部署插件;


5. 基于 Flink 的 OLAP 生产平台


基于 Flink 做了 Deltalink ,数据导出的平台;

基于数据导出的平台,做了 OLAP 平台,对于资源,模型,任务和权限都做了管理。

七、 未来规划

经过多次迭代,把 Flink 用到了数据集成、数据处理、离线数据导出、OLAP 等场景,但事情还没有结束,

未来的目标,是要做到流批一体,把离线作业都迁移到 Flink 上来;

同时数据也要做到批流一体,这个很重要。如果数据仍然是两份,是两套 Schema 定义,那么不管如何处理,都需要去对数据,就不是真正的流批统一。

所以不管是计算还是存储,都使用 Flink,达到真正的流批一体。

本文来自:知乎

感谢作者:知乎

查看原文:Flink 助力美团数仓增量生产

1493 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传