建立一个网站需要多少钱,中石化第四建设公司 网站,网页游戏代理平台,建站网站是什么一、美团数仓架构图 如上图#xff0c;是美团最新的数仓架构图。
整个架构图分为三层#xff0c;从下往上看#xff0c;最下面一层是数据安全#xff0c;包括受限域认证系统、加工层权限系统#xff0c;应用层权限系统#xff0c;安全审计系统#xff0c;来保证最上层数…一、美团数仓架构图 如上图是美团最新的数仓架构图。
整个架构图分为三层从下往上看最下面一层是数据安全包括受限域认证系统、加工层权限系统应用层权限系统安全审计系统来保证最上层数据集成与处理的安全
中间一层是统一的元数据中心和全链路血缘覆盖了全链路的加工过程
最上层根据数据的流向分成数据集成数据处理数据消费数据应用四个阶段
在数据集成阶段对于不同的数据来源包括用户行为数据日志数据DB 数据文件数据都有相对应的数据集成系统把数据收集到统一的存储之中包括 Kafka 和 Hive 等。
在数据处理阶段有一个面向用户的数据开发平台万象平台可以使用两条数据处理链路来加工数据一个是流式处理链路一个是离线处理链路。
数据加工好了之后使用内部自研的 DeltaLink 同步数据到其他的应用中例如即席分析即席查询报表等应用。
上图中标红的地方Kafka - HDFSFlinkDeltaLink 是本次重点分享的内容。
二、美团当前 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 框架上来。
这样的架构优势是非常明显的把数据传输放在了 T0 的时间去做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 是美团在 23 年前在内部自研的架构此架构的特性在于
支持 Flink 引擎读写通过 MOR 模式支持基于主键的 upsert/Delete小文件管理 CompactionTable Schema 可以对比 Hidi、Hudi、Iceberg如下 Hudi 最亮眼的特性是支持基于主键的 Upsert/Delete但劣势是深度和 Spark 绑定但在国内 Flink 框架这么火热的情况下难免会有点美中不足。
Iceberg 不依赖于执行引擎可以深度和 Flink 集成。
美团自研的 Hidi 则根据自己的需求实现了诸多的特性目前仍然在完善中。
四、基于 Flink 的增量生产
1、传统离线数仓特性分析 一般我们说数仓都是指离线数仓。离线数仓有三个重要的指标一是时效性二是质量三是成本。 首先是时效性有两个更深层次的含义一个是实时一个是准时。
实时就是实时流式处理来一条处理一条实时处理消耗的资源很多。
准时就是按时处理。比如广告需求可能只需要在每个整点统计过去一小时或者在每个整点统计当天的数据即可没有必要做到实时只需要到点能产出数据就行。
所以总结下来离线数仓和实时数仓各有利弊离线数仓在质量和成本上会有优势但是时效性不足实时数仓在时效性上很有优势但是质量和成本都略逊色。
2. 增量生产
如下图是离线数仓、实时数仓和增量计算的对比 所谓增量计算就是企业在时效性、质量、成本上做一个权衡时效性需要高一点但是不用做到 RealTimeOnTime 也可以接受 8 点看报表提前到 3 点计算好也没有很大的意义但是质量要高成本也需要尽量少。
3. 增量计算的优点
增量计算最大的优点就是可以尽快的发现问题。
一般我们会在第二天花 8 个小时到 12 个小时把前一天的数据生产出来。但是如果第二天发现数据错了可能要花一天的时间去修复数据这个时候准时性和质量都被打破了。
如下图横坐标是时间T 表示当天T1 表示第二天黑色线表示离线生产大概利用 T 1 一半资源去生产。红色线是实时生产在当天就生产数据占用的资源比离线计算高。 下图是增量生产的示意图。 绿色线是增量计算在当天就计算好。 黑色线是离线计算在第二天的前半天计算。 增量计算是在当天计算在当天就能提前发现问题避免 T 1 修复数据。并且还可以充分利用资源提前产出数据的时间并且占用资源更少。
4. 增量生产架构图
下图是美团增量生产的架构图目前的架构正在逐步完善中还没有完全实现 如图最上面是实时处理的链路Flink 消费 Kafka 数据 到 下游的 kafka输出结果给下游使用或者供 OLAP 分析。
下面的链路是批处理首先 kafka 数据经过 Flink 集成到 HDFS再通过 Spark 做离线的生产最终经过 Flink 导出到 OLAP 应用里面去。
上文提到的增量生产就是图中标绿色的部分希望可以用增量生产来替换掉 Spark 离线计算做到计算引擎的统一。
要能支持增量生产需要具备几个核心的能力
Flink SQL 能力能够对齐 Spark SQLHidi 支持 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 的同步架构关键设计
避免跨 TaskManager 的 Shuffle避免不必要的序列化成本 Source 和 Sink 尽量在同一个 TaskManager务必设计脏数据收集旁路和失败反馈机制 数据同步遇到脏数据的时候比如失败了 1% 的时候直接停下来利用 Flink 的 Accumulators 对批任务设计优雅退出机制 数据传输完之后通知下游数据同步完了利用 S3 统一管理 Reader/Writer 插件分布式热加载提升部署效率 很多传输任务都是小任务而作业部署时间又非常长所以需要要提前部署插件
5. 基于 Flink 的 OLAP 生产平台 基于 Flink 做了 Deltalink 数据导出的平台 基于数据导出的平台做了 OLAP 平台对于资源模型任务和权限都做了管理。
七、 未来规划
经过多次迭代把 Flink 用到了数据集成、数据处理、离线数据导出、OLAP 等场景但事情还没有结束。
未来的目标是要做到流批一体把离线作业都迁移到 Flink 上来
同时数据也要做到批流一体这个很重要。如果数据仍然是两份是两套 Schema 定义那么不管如何处理都需要去对数据就不是真正的流批统一。
所以不管是计算还是存储都使用 Flink达到真正的流批一体。
本文整理自2020年 Flink Forward Asia 大会分享者鞠大升
关注公众号KK架构师获取更多数据湖最新实战
