怎样在外贸网站做业务,瑜伽网站设计,常见的网站推广方法有哪些,广州网站建设 骏域简介#xff1a; 4.17 上海站 Meetup 胡争老师分享内容#xff1a;数据入湖的挑战有哪些#xff0c;以及如何用 Flink Iceberg 解决此类问题。
一、数据入湖的核心挑战
数据实时入湖可以分成三个部分#xff0c;分别是数据源、数据管道和数据湖#xff08;数仓#xf…简介 4.17 上海站 Meetup 胡争老师分享内容数据入湖的挑战有哪些以及如何用 Flink Iceberg 解决此类问题。
一、数据入湖的核心挑战
数据实时入湖可以分成三个部分分别是数据源、数据管道和数据湖数仓本文的内容将围绕这三部分展开。 1. Case #1程序 BUG 导致数据传输中断 首先当数据源通过数据管道传到数据湖数仓时很有可能会遇到作业有 BUG 的情况导致数据传到一半对业务造成影响第二个问题是当遇到这种情况的时候如何重起作业并保证数据不重复也不缺失完整地同步到数据湖数仓中。
2. Case #2数据变更太痛苦
数据变更 当发生数据变更的情况时会给整条链路带来较大的压力和挑战。以下图为例原先是一个表定义了两个字段分别是 ID 和 NAME。此时业务方面的同学表示需要将地址加上以方便更好地挖掘用户的价值。 首先我们需要把 Source 表加上一个列 Address然后再把到 Kafka 中间的链路加上链然后修改作业并重启。接着整条链路得一路改过去添加新列修改作业并重启最后把数据湖数仓里的所有数据全部更新从而实现新增列。这个过程的操作不仅耗时而且会引入一个问题就是如何保证数据的隔离性在变更的过程中不会对分析作业的读取造成影响。
分区变更 如下图所示数仓里面的表是以 “月” 为单位进行分区现在希望改成以 “天” 为单位做分区这可能就需要将很多系统的数据全部更新一遍然后再用新的策略进行分区这个过程十分耗时。
3. Case #3越来越慢的近实时报表
当业务需要更加近实时的报表时需要将数据的导入周期从 “天” 改到 “小时”甚至 “分钟” 级别这可能会带来一系列问题。 如上图所示首先带来的第一个问题是文件数以肉眼可见的速度增长这将对外面的系统造成越来越大的压力。压力主要体现在两个方面 第一个压力是启动分析作业越来越慢Hive Metastore 面临扩展难题如下图所示。 随着小文件越来越多使用中心化的 Metastore 的瓶颈会越来越严重这会造成启动分析作业越来越慢因为启动作业的时候会把所有的小文件原数据都扫一遍。第二是因为 Metastore 是中心化的系统很容易碰到 Metastore 扩展难题。例如 Hive可能就要想办法扩后面的 MySQL造成较大的维护成本和开销。第二个压力是扫描分析作业越来越慢。 随着小文件增加在分析作业起来之后会发现扫描的过程越来越慢。本质是因为小文件大量增加导致扫描作业在很多个 Datanode 之间频繁切换。
4. Case #4实时地分析 CDC 数据很困难
大家调研 Hadoop 里各种各样的系统发现整个链路需要跑得又快又好又稳定并且有好的并发这并不容易。
首先从源端来看比如要将 MySQL 的数据同步到数据湖进行分析可能会面临一个问题就是 MySQL 里面有存量数据后面如果不断产生增量数据如何完美地同步全量和增量数据到数据湖中保证数据不多也不少。
此外假设解决了源头的全量跟增量切换如果在同步过程中遇到异常如上游的 Schema 变更导致作业中断如何保证 CDC 数据一行不少地同步到下游。
整条链路的搭建需要涉及源头全量跟同步的切换包括中间数据流的串通还有写入到数据湖数仓的流程搭建整个链路需要写很多代码开发门槛较高。
最后一个问题也是关键的一个问题就是我们发现在开源的生态和系统中很难找到高效、高并发分析 CDC 这种变更性质的数据。
5. 数据入湖面临的核心挑战 数据同步任务中断 无法有效隔离写入对分析的影响同步任务不保证 exactly-once 语义。 端到端数据变更 DDL 导致全链路更新升级复杂修改湖/仓中存量数据困难。 越来越慢的近实时报表 频繁写入产生大量小文件Metadata 系统压力大, 启动作业慢大量小文件导致数据扫描慢。 无法近实时分析 CDC 数据 难以完成全量到增量同步的切换涉及端到端的代码开发门槛高开源界缺乏高效的存储系统。
二、Apache Iceberg 介绍
1. NetflixHive 上云痛点总结
Netflix 做 Iceberg 最关键的原因是想解决 Hive 上云的痛点痛点主要分为以下三个方面
1.1 痛点一数据变更和回溯困难
不提供 ACID 语义。在发生数据改动时很难隔离对分析任务的影响。典型操作如INSERT OVERWRITE修改数据分区修改 Schema无法处理多个数据改动造成冲突问题无法有效回溯历史版本。
1.2 痛点二替换 HDFS 为 S3 困难
数据访问接口直接依赖 HDFS API依赖 RENAME 接口的原子性这在类似 S3 这样的对象存储上很难实现同样的语义大量依赖文件目录的 list 接口这在对象存储系统上很低效。
1.3 痛点三太多细节问题
Schema 变更时不同文件格式行为不一致。不同 FileFormat 甚至连数据类型的支持都不一致Metastore 仅维护 partition 级别的统计信息造成不 task plan 开销 Hive Metastore 难以扩展非 partition 字段不能做 partition prune。
2. Apache Iceberg 核心特性 通用化标准设计 完美解耦计算引擎Schema 标准化开放的数据格式支持 Java 和 Python 完善的 Table 语义 Schema 定义与变更灵活的 Partition 策略ACID 语义Snapshot 语义 丰富的数据管理 存储的流批统一可扩展的 META 设计支持批更新和 CDC支持文件加密 性价比 计算下推设计低成本的元数据管理向量化计算轻量级索引
3. Apache Iceberg File Layout 上方为一个标准的 Iceberg 的 TableFormat 结构核心分为两部分一部分是 Data一部分是 Metadata无论哪部分都是维护在 S3 或者是 HDFS 之上的。
4. Apache Iceberg Snapshot View 上图为 Iceberg 的写入跟读取的大致流程。
可以看到这里面分三层
最上面黄色的是快照中间蓝色的是 Manifest最下面是文件。
每次写入都会产生一批文件一个或多个 Manifest还有快照。
比如第一次形成了快照 Snap-0第二次形成快照 Snap-1以此类推。但是在维护原数据的时候都是增量一步一步做追加维护的。
这样的话可以帮助用户在一个统一的存储上做批量的数据分析也可以基于存储之上去做快照之间的增量分析这也是 Iceberg 在流跟批的读写上能够做到一些支持的原因。
5. 选择 Apache Iceberg 的公司 上图为目前在使用 Apache Iceberg 的部分公司国内的例子大家都较为熟悉这里大致介绍一下国外公司的使用情况。
NetFlix 现在是有数百PB的数据规模放到 Apache Iceberg 之上Flink 每天的数据增量是上百T的数据规模。Adobe 每天的数据新增量规模为数T数据总规模在几十PB左右。AWS 把 Iceberg 作为数据湖的底座。Cloudera 基于 Iceberg 构建自己整个公有云平台像 Hadoop 这种 HDFS 私有化部署的趋势在减弱上云的趋势逐步上升Iceberg 在 Cloudera 数据架构上云的阶段中起到关键作用。 苹果有两个团队在使用 一是整个 iCloud 数据平台基于 Iceberg 构建二是人工智能语音服务 Siri也是基于 Flink 跟 Iceberg 来构建整个数据库的生态。
三、Flink 和 Iceberg 如何解决问题
回到最关键的内容下面阐述 Flink 和 Iceberg 如何解决第一部分所遇到的一系列问题。
1. Case #1程序 BUG 导致数据传输中断 首先同步链路用 Flink可以保证 exactly once 的语义当作业出现故障时能够做严格的恢复保证数据的一致性。 第二个是 Iceberg它提供严谨的 ACID 语义可以帮用户轻松隔离写入对分析任务的不利影响。
2. Case #2数据变更太痛苦 如上所示当发生数据变更时用 Flink 和 Iceberg 可以解决这个问题。
Flink 可以捕捉到上游 Schema 变更的事件然后把这个事件同步到下游同步之后下游的 Flink 直接把数据往下转发转发之后到存储Iceberg 可以瞬间把 Schema 给变更掉。
当做 Schema 这种 DDL 的时候Iceberg 直接维护了多个版本的 Schema然后老的数据源完全不动新的数据写新的 Schema实现一键 Schema 隔离。 另外一个例子是分区变更的问题Iceberg 做法如上图所示。
之前按 “月” 做分区上方黄色数据块如果希望改成按 “天” 做分区可以直接一键把 Partition 变更原来的数据不变新的数据全部按 “天” 进行分区语义做到 ACID 隔离。
3. Case #3越来越慢的近实时报表 第三个问题是小文件对 Metastore 造成的压力。
首先对于 Metastore 而言Iceberg 是把原数据统一存到文件系统里然后用 metadata 的方式维护。整个过程其实是去掉了中心化的 Metastore只依赖文件系统扩展所以扩展性较好。 另一个问题是小文件越来越多导致数据扫描会越来越慢。在这个问题上Flink 和 Iceberg 提供了一系列解决方案
第一个方案是在写入的时候优化小文件的问题按照 Bucket 来 Shuffle 方式写入因为 Shuffle 这个小文件写入的文件就自然而然的小。第二个方案是批作业定期合并小文件。第三个方案相对智能就是自动增量地合并小文件。
4. Case #4实时地分析CDC数据很困难 首先是是全量跟增量数据同步的问题社区其实已有 Flink CDC Connected 方案就是说 Connected 能够自动做全量跟增量的无缝衔接。第二个问题是在同步过程中如何保证 Binlog 一行不少地同步到湖中 即使中间碰到异常。 对于这个问题Flink 在 Engine 层面能够很好地识别不同类型的事件然后借助 Flink 的 exactly once 的语义即使碰到故障它也能自动做恢复跟处理。 第三个问题是搭建整条链路需要做不少代码开发门槛太高。 在用了 Flink 和 Data Lake 方案后只需要写一个 source 表和 sink 表然后一条 INSERT INTO整个链路就可以打通无需写任何业务代码。 最后是存储层面如何支持近实时的 CDC 数据分析。
四、社区 Roadmap 上图为 Iceberg 的 Roadmap可以看到 Iceberg 在 2019 年只发了一个版本 却在 2020 年直接发了三个版本并在 0.9.0 版本就成为顶级项目。 上图为 Flink 与 Iceberg 的 Roadmap可以分为 4 个阶段。
第一个阶段是 Flink 与 Iceberg 建立连接。第二阶段是 Iceberg 替换 Hive 场景。在这个场景下有很多公司已经开始上线落地自己的场景。第三个阶段是通过 Flink 与 Iceberg 解决更复杂的技术问题。第四个阶段是把这一套从单纯的技术方案到面向更完善的产品方案角度去做。
原文链接
本文为阿里云原创内容未经允许不得转载。
