文章目录
本文讨论大数据技术演进的过程、数据湖架构、数据湖能够解决那些问题，它本身又有哪些问题。
关键词：
- Lamba和kappa的解决的问题和痛点
- 数据湖架构：读时模式、存算分离
- flink cdc + 数据湖 merge
- Iceberg是一种开放数据表格式。计算与存储的中间层，通过Spark，Flink，Presto等读取表。
- 湖仓互补：湖发掘的表格式，可以补充到数仓，数仓建立的表格式也可以补充到湖。 湖处理数据速度秒级
- 湖面对巨大的数据建模问题，数据模型不可枚举。
- AI理解底层的数据模型规则，简化数据湖产品。
一. 大数据发展过程
1. 离线大数据平台
第一阶段：以Hadoop为代表的离线数据处理组件。Hadoop是以HDFS为核心存储，以MapReduce为基本计算模型的批量数据处理基础组件。围绕HDFS和MR，为不断完善大数据平台的数据处理能力，先后诞生了一系列大数据组件，例如面向实时KV操作的HBase、面向SQL的Hive、面向工作流的Pig等。
同时，随着大家对于批处理的性能要求越来越高，新的计算模型不断被提出，产生了Tez、Spark、Presto等计算引擎，MR模型也逐渐进化成DAG模型。
为减少数据处理过程中的中间结果写文件操作，Spark、Presto等计算引擎尽量使用计算节点的内存对数据进行缓存，从而提高整个数据过程的效率和系统吞吐能力。
2. Lambda架构：速度层+批层
Lambda架构的核心理念是“流批分离”。数据进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过服务层对应用提供，确保访问的一致性。
Lambda架构包含了非常多的大数据组件，增加了整体架构的复杂性和维护成本。
Lambda架构的问题
1. 数据治理成本高
实时计算流程无法复用离线数仓的数据血缘、数据质量管理体系。需要重新实现一套针对实时计算的数据血缘、数据质量管理体系。
2. 开发维护成本高
需要同时维护离线和实时两套数据仓库系统，同一套计算逻辑要存储两份数据。例如，某一条或几条原式数据的更新，就需要重新跑一遍离线数据仓库，数据更新成本非常大。
3. 数据口径不一致
因为离线和实时计算走的是两个完全不同的代码，由于数据数据的延迟到达和两类代码运行的时间不一样，导致计算结果不一致。
3. Kappa架构：流批一体
Kappa架构中，通过Flink+Kafka将整个实时、离线链路串接到一起。Kappa架构解决了Lambda架构中离线处理层和实时处理层之间计算引擎不一致，开发、运维成本成本高，计算结果不一致等问题。
Kappa架构的方案也被称为“批流一体化”方案。借用Flink+Kafka来构建流批一体化场景，当需要对ODS层数据做进一步的分析时，将Flink计算结果的DWD层写入到Kafka，同样也会将一部分DWS层的计算结果Kafka。
Kappa架构的痛点
数据回溯能力弱
但是Kafka对复杂的需求分析支持能力弱，在面对更复杂的数据分析时，又要将DWD和DWS层的数据写入到ClickHouse、ES、MySQL或者是Hive里做进一步分析，这无疑带来了链路的复杂性。更大的问题是在做数据回溯时，由于链路的复杂性导致数据回溯能力非常弱。
OLAP分析能力弱
由于Kafka是一个顺序存储的系统，顺序存储系统是没有办法直接在其上进行OLAP分析的，例如谓词下推这类的优化策略，在顺序存储平台（Kafka）上实现是比较困难的事情。
- 数据时序性受到挑战
Kappa架构是严重依赖于消息队列的，我们知道消息队列本身的准确性严格依赖它上游数据的顺序，但是，消息队列的数据分层越多，发生乱序的可能性越大。
通常情况下，ODS层的数据是绝对准确的，把ODS层数据经过计算之后写入到DWD层时就会产生乱序，DWD到DWS更容易产生乱序，这样的数据不一致性问题非常大。
4. 大数据架构痛点总结
从传统的hadoop架构到Lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，但是这些平台仍然存在很多痛点。
那么
- 是否存在一种存储技术
既能够支持数据高效的回溯能力，支持数据的更新，又能够实现数据的批流读写，并且还能够实现分钟级到秒级的数据接入？
- 有没有这样一个架构
既能够满足实时性的需求，又能够满足离线计算的要求，而且还能够减轻开发运维的成本，解决通过消息队列方式构建的Kappa架构中遇到的痛点？
二. 数据湖助力于解决数据仓库痛点问题
1. 数据湖特点
数据湖是一个集中式存储库，可以存储结构化和非结构化数据。以下是它的一些特点
A. 存储原式数据
- 数据湖需要有足够的存储能力，能够存储公司的全部数据。
- 数据湖可以存储各种类型的数据，包括结构化、
半结构化（XML、Json等）和非结构化数据（图片、视频、音频）。- 数据湖中的数据是原始业务数据的完整副本，这些数据保持了他们在业务系统中原来的样子。
B. 灵活的底层存储功能
在实际的使用过程中，数据湖中的数据通常并不会被高频访问，为了达到可接受的性价比，数据湖建设通常会选择性价比高的存储引擎（如S3/OSS/HDFS）。
- 对大数据提供超大规模存储，以及可扩展的大规模数据处理能力。
- 可以采用S3/HDFS/OSS等分布式存储平台作为存储引擎。
- 支持Parquet、Avro、ORC等数据结构格式。
- 能够提供
数据缓存加速功能。
C. 丰富的计算引擎
- 从数据的批量计算、流式计算，
交互式查询分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。随着大数据与人工智能技术的结合，各类机器学习/深度学习算法也被不断引入进来，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行机器学习训练。- 因此，对于一个合格的数据湖项目而言，计算存储引擎的
可插拔性，是数据湖必须具备的基础能力。
D. 完善的数据管理
- 元数据管理能力：包括对数据源、数据格式、连接信息、数据schema、权限管理等能力。
数据生命周期管理能力：不仅能够存储原始数据，还需要能够保存各类分析处理的中间结果数据，并完整的记录数据的分析处理过程，帮助用户能够完整追溯任意一条数据的产生过程。- 数据获取和数据发布能力：数据湖需要能支撑各种各样的数据源，并能从相关的数据源中
获取全量/增量数据（依靠CDC）并规范存储。数据湖能将数据推送到合适的存储引擎中，以满足不同的应用访问需求。
2. 开源数据湖的架构
LakeHouse是基于存算分离的架构来构建的。
存算分离最大的问题在于网络，特别是对于高频访问的数仓数据，
网络性能至关重要。实现Lakehouse的可选方案很多，比如Delta，Hudi，Iceberg。虽然三者侧重点有所不同，但都具备数据湖的一般功能，比如：统一元数据管理、支持多种计算分析引擎、支持高阶分析和计算存储分离。
数据湖架构主要分为四层：
分布式文件系统
第一层是分布式文件系统，对于选择云上技术的用户，通常会选择S3和阿里云存储数据；喜欢开源技术的用户一般采用自己维护的HDFS存储数据。
数据加速层
第二层是数据加速层。数据湖架构是一个典型的
存储计算分离架构，远程读写的性能损耗非常大。我们常见的做法是，把经常访问的数据（热点数据）缓存在计算节点本地，从而实现数据的冷热分离。这样做的好处是，提高数据的读写性能，节省网络带宽。我们可以选择 开源的Alluxio ，或者阿里云的Jindofs。
Table format 层
第三层是Table format层，
把数据文件封装成具有业务含义的表，数据本身提供ACID、snapshot、schema、partition等表级别的语义。这一层可以选择开源数据湖三剑客Delta、Iceberg、Hudi之一。Delta、Iceberg、Hudi是构建数据湖的一种技术，它们本身并不是数据湖。
计算引擎
第四层是各种数据计算引擎。包括Spark、Flink、Hive、Presto等，这些计算引擎都可以访问数据湖中的同一张表。
小结：
- Iceberg提供统一的数据湖存储表格式，支持多种计算引擎（包括Spark、Presto、hive）进行数据分析；
- 可以产生纯列存的数据文件（
HOW ing），而列式文件非常适合用来做OLAP操作；- Iceberg基于Snapshot的设计模式（
HOW ing），支持增量读取数据；- Iceberg的接口抽象程度高，兼容性好，既独立于上层的计算引擎又独立于下层的存储引擎，这就方便用户自行定义业务逻辑（
HOW ing）。
三. 数据湖和数据仓库理念的对比
1. 数据湖和数据仓库对比
- 数据仓库是计划经济，原始信息耗损大，标准化程度高，适合高度结构化的报表和BI
- 数据湖是市场经济，原始信息损耗低，个性化强，创新性强，适合挖掘、探索和预测。
每个公司需要数据仓库和数据湖，因为它们分别满足不同的需要和使用案例：
- 数据仓库是一个优化后的数据库，用于分析来自事务系统和业务线应用系统的关系型数据。事先定义好数据结构和Schema，以便提供快速的SQL查询。
- 数据湖有所不同，它不但存储来自业务线应用系统的关系型数据，还要存储来自移动应用程序、IoT设备和社交媒体的非关系型数据。捕获数据时，不用预先定义好数据结构或Schema。这意味着数据湖可以存储所有类型的数据，而不需要精心设计数据结构。
2. 写时模式和读时模式
- 写时模式
数据仓库在数据写入之前，必须确认好数据的Schema，然后进行数据导入，这样做的好处是：可以把业务和数据很好的结合在一起；不足是数仓的灵活性不够。- 读时模式
数据湖强调的是“读取型Schema”，背后潜在的逻辑是，认为业务的不确定性是常态。先完成数据沉淀，然后根据需要再设计结构化，让整个基础设施具备使数据“按需”贴合业务的能力。因此，数据湖更适合发展、创新型企业。
3. 数据湖的架构方案
在数据湖中，无论是数据的流式处理、还是批处理，数据存储都统一到数据湖Iceberg上。很明显，这套架构可以解决Lambda架构和Kappa架构的痛点问题：
- 解决Kafka存储数据量少的问题
目前所有数据湖基本思路都是基于HDFS之上实现的一个文件管理系统，所以数据体量可以很大。- 支持OLAP查询
同样数据湖基于HDFS之上实现，只需要当前的OLAP查询引擎做一些适配（ing什么适配），就可以对中间层数据进行OLAP查询。- 数据治理一体化
批流的数据在HDFS、S3等介质上存储之后，就完全可以复用一套相同的数据血缘、数据质量管理体系。 怎么实现呢？- 流批架构统一
数据湖架构相比Lamda架构来说，schema统一，数据处理逻辑统一，用户不再需要维护两份数据。- 数据统计口径一致
由于采用统一的流批一体化计算和存储方案，因此数据一致性得到了保证。
4. 孰优孰劣
- 湖和仓的元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖（成为原始数据一部分），湖的结构化应用沉淀到数据仓库。
- 统一开发湖和仓，存储在不同系统的数据，可以通过平台进行统一管理。
- 数据湖与数据仓库的数据，根据业务的发展需要决定
哪些数据放在数仓，哪些放在数据湖，进而形成湖仓一体化。数据在湖，模型在仓，反复演练转换。
四. 数据湖助力数据仓库架构升级
1. 构建数据湖的目标
数据湖技术-Iceberg目前支持三种文件格式：Parquet，Avro，ORC。
如下图所示，Iceberg本身具备的能力总结如下，这些能力对于构建湖仓一体化是至关重要的。
数据存储层采用标准统一的数据存储模型。- 构建准实时数据建设，去T+1，保证数据时效性。
数据追溯更加方便(HOW ing)，运维成本更低。
2. 准实时数据接入
数据湖技术-Iceberg既支持读写分离，又支持并发读、增量读、小文件合并，还可以支持秒级到分钟级的延迟，基于这些优势我们尝试采用Iceberg这些功能来构建基于Flink的实时全链路批流一体化的实时数仓架构。
如下图所示，Iceberg每次的commit操作，都是对数据的可见性的改变。
3. 实时数仓 - 数据湖分析系统
加速离线数仓的建设
- 之前要进行数据接入操作，需要使用离线调度系统定时抽取数据，再经过一系列的ETL操作，最后将数据写入到Hive表里面，这个过程的延时比较大。
- 现在可以借助于Iceberg的表结构，使用Flink，或者Spark Streaming，实现近实时的数据接入（
数据持续接入ing），以降低数据延迟性。
接着讨论Kappa架构的痛点，数据湖是否可以考虑将Kafka替换成Iceberg？
- 存储方面：Iceberg底层依赖的存储是像HDFS或S3这样的廉价存储，并且支持parquet、orc、Avro等存储结构。
- 速度方面：可以对中间层的结果数据进行OLAP分析。基于
Iceberg snapshot的Streaming reader功能（ing），可以把离线任务天级别到小时级别的延迟大大的降低，改造成一个近实时的数据湖分析系统。
在中间处理层，可以用Presto进行一些简单的SQL查询，因为Iceberg支持Streaming Read，所以在系统的中间层也可以直接接入Flink，直接在中间层用Flink做一些批处理或者流式计算的任务，把中间结果做进一步计算后输出到下游。
4. Iceberg替换Kafka的优劣
总的来说，Iceberg替换Kafka的优势主要包括：
- 实现存储层的流批统一、存储成本降低
中间层支持OLAP分析（之前不支持吗？）- 完美支持高效回溯（统一由iceberg管理了？）
当然，也存在一定的缺陷，如：
- 数据延迟从实时变成近实时（存储kafka到HDFS）
- 对接其他数据系统需要额外的开发工作
五. 小结与下一步探索
我们基本了解了什么是数据湖，以及为什么要学习数据湖，它能解决哪些实际问题。后续继续探索数据湖建设的相关实践，来探索数据湖提到的能力，比如：
- 数据湖的架构搭建方案：如何使用数据存储到iceberg、如何对接flink、iceberg的表管理怎么用；
- 湖仓一体的建设方案；
- 具体iceberg是如何进行数据的commit、merge等数据湖操作、什么是Snapshot的设计模式，如何支持增量读取数据；
- 架构层面：如何在数据湖中做数据追溯；
- 读时模式的实践；
- 。。。
参考:
https://www.toutiao.com/article/7099724190609539591
