13518219792
这期内容当中小编将会给大家带来有关Flink+Iceberg 数据湖探索与实践是怎样的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
成都创新互联是一家集网站建设,滨江企业网站建设,滨江品牌网站建设,网站定制,滨江网站建设报价,网络营销,网络优化,滨江网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
我们凌晨一些大的离线任务经常会因为一些原因出现延迟，这种延迟会导致核心报表的产出时间不稳定，有些时候会产出比较早，但是有时候就可能会产出比较晚，业务很难接受。
为什么会出现这种现象的发生呢？目前来看大致有这么几点要素：
任务本身要请求的数据量会特别大。通常来说一天原始的数据量可能在几十TB。几百个分区，甚至上千个分区，五万+的文件数这样子。如果说全量读取这些文件的话，几百个分区就会向 NameNode 发送几百次请求，我们知道离线任务在凌晨运行的时候，NameNode 的压力是非常大的。所以就很有可能出现 Namenode 响应很慢的情况，如果请求响应很慢就会导致任务初始化时间很长。
任务本身的 ETL 效率是相对低效的，这个低效并不是说 Spark 引擎低效，而是说我们的存储在这块支持的不是特别的好。比如目前我们查一个分区的话是需要将所有文件都扫描一遍然后进行分析，而实际上我可能只对某些文件感兴趣。所以相对而言这个方案本身来说就是相对低效的。
这种大的离线任务一旦遇到磁盘坏盘或者机器宕机，就需要重试，重试一次需要耗费很长的时间比如几十分钟。如果说重试一两次的话这个延迟就会比较大了。
针对一些细琐的一些问题而言的。这里简单列举了三个场景来分析：
不可靠的更新操作。我们经常在 ETL 过程中执行一些 insert overwrite 之类的操作，这类操作会先把相应分区的数据删除，再把生成的文件加载到分区中去。在我们移除文件的时候，很多正在读取这些文件的任务就会发生异常，这就是不可靠的更新操作。
表 Schema 变更低效。目前我们在对表做一些加字段、更改分区的操作其实是非常低效的操作，我们需要把所有的原始数据读出来，然后在重新写回去。这样就会非常耗时，并且低效。
数据可靠性缺乏保障。主要是我们对于分区的操作，我们会把分区的信息分为两个地方，HDFS 和 Metastore，分别存储一份。在这种情况下，如果进行更新操作，就可能会出现一个更新成功而另一个更新失败，会导致数据不可靠。
基于 Lambda 架构建设的实时数仓存在较多的问题。如上图的这个架构图，第一条链路是基于 kafka 中转的一条实时链路（延迟要求小于5分钟），另一条是离线链路（延迟大于1小时），甚至有些公司会有第三条准实时链路（延迟要求5分钟～一小时），甚至更复杂的场景。
两条链路对应两份数据，很多时候实时链路的处理结果和离线链路的处理结果对不上。
Kafka 无法存储海量数据， 无法基于当前的 OLAP 分析引擎高效查询 Kafka 中的数据。
Lambda 维护成本高。代码、数据血缘、Schema 等都需要两套。运维、监控等成本都非常高。
不能友好地支持高效更新场景。大数据的更新场景一般有两种，一种是 CDC ( Change Data Capture) 的更新，尤其在电商的场景下，将 binlog 中的更新删除同步到 HDFS 上。另一种是延迟数据带来的聚合后结果的更新。目前 HDFS 只支持追加写，不支持更新。因此业界很多公司引入了 Kudu。但是 Kudu 本身是有一些局限的，比如计算存储没有做到分离。这样整个数仓系统中引入了 HDFS、Kafka 以及 Kudu，运维成本不可谓不大。
上面就是针对目前数仓所涉及到的四个痛点的大致介绍，因此我们也是通过对数据湖的调研和实践，希望能在这四个方面对数仓建设有所帮助。接下来重点讲解下对数据湖的一些思考。
数据湖大致是从19年开始慢慢火起来的，目前市面上核心的数据湖开源产品大致有这么几个：
DELTA LAKE，在17年的时候 DataBricks 就做了 DELTA LAKE 的商业版。主要想解决的也是基于 Lambda 架构带来的存储问题，它的初衷是希望通过一种存储来把 Lambda 架构做成 kappa 架构。
Hudi ( Uber 开源 ) 可以支持快速的更新以及增量的拉取操作。这是它最大的卖点之一。
Iceberg 的初衷是想做标准的 Table Format 以及高效的 ETL。
上图是来自 Flink 团体针对数据湖方案的一些调研对比，总体来看这些方案的基础功能相对都还是比较完善的。我说的基础功能主要包括：
高效 Table Schema 的变更，比如针对增减分区，增减字段等功能
ACID 语义保证
同时支持流批读写，不会出现脏读等现象
支持 OSS 这类廉价存储
Hudi 的特性主要是支持快速的更新删除和增量拉取。
Iceberg 的特性主要是代码抽象程度高，不绑定任何的 Engine。它暴露出来了非常核心的表层面的接口，可以非常方便的与 Spark/Flink 对接。然而 Delta 和 Hudi 基本上和 Spark 的耦合很重。如果想接入 Flink，相对比较难。
现在国内的实时数仓建设围绕 Flink 的情况会多一点。所以能够基于 Flink 扩展生态，是我们选择 Iceberg 一个比较重要的点。
国内也有很多基于 Iceberg 开发的重要力量，比如腾讯团队、Flink 官方团队，他们的数据湖选型也是 Iceberg。目前他们在社区分别主导 update 以及 Flink 的生态对接。
Iceberg 是一个开源的基于表格式的数据湖。关于 table format 再给大家详细介绍下：
左侧图是一个抽象的数据处理系统，分别由 SQL 引擎、table format、文件集合以及分布式文件系统构成。右侧是对应的现实中的组件，SQL 引擎比如 HiveServer、Impala、Spark 等等，table format 比如 Metastore 或者 Iceberg，文件集合主要有 Parquet 文件等，而分布式文件系统就是 HDFS。
对于 table format，我认为主要包含4个层面的含义，分别是表 schema 定义（是否支持复杂数据类型），表中文件的组织形式，表相关统计信息、表索引信息以及表的读写 API 实现。详述如下：
表 schema 定义了一个表支持字段类型，比如 int、string、long 以及复杂数据类型等。
表中文件组织形式最典型的是 Partition 模式，是 Range Partition 还是 Hash Partition。
Metadata 数据统计信息。
封装了表的读写 API。上层引擎通过对应的API读取或者写入表中的数据。
和 Iceberg 差不多相当的一个组件是 Metastore。不过 Metastore 是一个服务，而 Iceberg 就是一个 jar 包。这里就 Metastore 和 Iceberg 在表格式的4个方面分别进行一下对比介绍：
都支持 int、string、bigint 等类型。
两者在 partition 上有很大的不同：
metastore 中 partition 字段不能是表字段，因为 partition 字段本质上是一个目录结构，不是用户表中的一列数据。基于 metastore，用户想定位到一个 partition 下的所有数据，首先需要在 metastore 中定位出该 partition 对应的所在目录位置信息，然后再到 HDFS 上执行list命令获取到这个分区下的所有文件，对这些文件进行扫描得到这个 partition 下的所有数据。
Iceberg 中 partition 字段就是表中的一个字段。Iceberg 中每一张表都有一个对应的文件元数据表，文件元数据表中每条记录表示一个文件的相关信息，这些信息中有一个字段是 partition 字段，表示这个文件所在的 partition。
很明显，Iceberg 表根据 partition 定位文件相比 metastore 少了一个步骤，就是根据目录信息去 HDFS 上执行 list 命令获取分区下的文件。
试想，对于一个二级分区的大表来说，一级分区是小时时间分区，二级分区是一个枚举字段分区，假如每个一级分区下有30个二级分区，那么这个表每天就会有24 * 30 = 720个分区。基于 Metastore 的 partition 方案，如果一个 SQL 想基于这个表扫描昨天一天的数据的话，就需要向 Namenode 下发720次 list 请求，如果扫描一周数据或者一个月数据，请求数就更是相当夸张。这样，一方面会导致 Namenode 压力很大，一方面也会导致 SQL 请求响应延迟很大。而基于 Iceberg 的 partition 方案，就完全没有这个问题。
Metastore 中一张表的统计信息是表/分区级别粒度的统计信息，比如记录一张表中某一列的记录数量、平均长度、为 null 的记录数量、最大值最小值等。
Iceberg 中统计信息精确到文件粒度，即每个数据文件都会记录所有列的记录数量、平均长度、最大值最小值等。
很明显，文件粒度的统计信息对于查询中谓词（即 where 条件）的过滤会更有效果。
metastore 模式下上层引擎写好一批文件，调用 metastore 的 add partition 接口将这些文件添加到某个分区下。
Iceberg 模式下上层业务写好一批文件，调用 iceberg 的 commit 接口提交本次写入形成一个新的 snapshot 快照。这种提交方式保证了表的 ACID 语义。同时基于 snapshot 快照提交可以实现增量拉取实现。
总结下 Iceberg 相对于 Metastore 的优势：
新 partition 模式：避免了查询时n次调用 namenode 的 list 方法，降低 namenode 压力，提升查询性能
新 metadata 模式：文件级别列统计信息可以用来根据 where 字段进行文件过滤，很多场景下可以大大减少扫描文件数，提升查询性能
新 API 模式：存储批流一体
流式写入-增量拉取（基于 Iceberg 统一存储模式可以同时满足业务批量读取以及增量订阅需求）
支持批流同时读写同一张表，统一表schema，任务执行过程中不会出现 FileNotFoundException
Iceberg 的提升体现在：
目前 Iceberg 主要支持的计算引擎包括 Spark 2.4.5、Spark 3.x、Flink 1.11 以及 Presto。同时，一些运维工作比如 snapshot 过期、小文件合并、增量订阅消费等功能都可以实现。
对于 Apache Flink 来说，Apache Iceberg 是 delta、iceberg、hudi 三个开源项目中最先完成 Flink 接入的开源项目。通过 Flink 来完成实时导入数据到 Iceberg 数据湖、通过 Flink batch 作业来读取 Iceberg 数据，这两个核心功能将在 Apache Iceberg 0.10.0 版本发布（预计将在10月底发布）。对 Flink+iceberg 集成工作感兴趣的同学，可以参考 Apache Iceberg 社区的使用文档。
https://github.com/apache/iceberg/blob/master/site/docs/flink.md
按照目前的研发进度，我们预计实时写入和读取 CDC 数据这个功能，将在 Iceberg 的0.11.0版本发布。
Iceberg 针对目前的大数量的情况下，可以大大提升 ETL 任务执行的效率，这主要得益于新 Partition 模式下不再需要请求 NameNode 分区信息，同时得益于文件级别统计信息模式下可以过滤很多不满足条件的数据文件。
当前 Iceberg 社区仅支持 Spark 2.4.5，我们在这个基础上做了更多计算引擎的适配工作。主要包括如下：
集成 Hive。可以通过 Hive 创建和删除 iceberg 表，通过 HiveSQL 查询 Iceberg 表中的数据。
集成 Impala。用户可以通过 Impala 新建 iceberg 内表外表，并通过 Impala 查询 Iceberg 表中的数据。目前该功能已经贡献给 Impala 社区。
集成 Flink。已经实现了 Flink 到 Iceberg 的 sink 实现，业务可以消费 kafka 中的数据将结果写入到 Iceberg 中。同时我们基于 Flink 引擎实现了小文件异步合并的功能，这样可以实现 Flink 一边写数据文件，一边执行小文件的合并。基于 Iceberg 的小文件合并通过 commit 的方式提交，不需要删除合并前的小文件，也就不会引起读取任务的任何异常。
上述就是小编为大家分享的Flink+Iceberg 数据湖探索与实践是怎样的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
