一 数据湖技术产生的背景国内的大型互联网公司，每天都会生成几十、几百TB，甚至几PB的原始数据。这些公司通常采用开源的大数据组件来搭建大数据平台。大数据平台经历过“以Hadoop为代表的离线数据平台”、“Lambda架构平台”、“Kappa架构平台”三个阶段。 可以把数据湖认为是最新一代大数据技术平台，为了更好地理解数据湖的基本架构，我们先来看看大数据平台的演进过程，从而理解为什么要学习数据湖技术。 1.1 离线大数据平台-第一代 第一阶段：以Hadoop为代表的离线数据处理组件。Hadoop是以HDFS为核心存储，以MapReduce为基本计算模型的批量数据处理基础组件。围绕HDFS和MR，为不断完善大数据平台的数据处理能力，先后诞生了一系列大数据组件，例如面向实时KV操作的HBase、面向SQL的Hive、面向工作流的Pig等。同时，随着大家对于批处理的性能要求越来越高，新的计算模型不断被提出，产生了Tez、Spark、Presto等计算引擎，MR模型也逐渐进化成DAG模型。 为减少数据处理过程中的中间结果写文件操作，Spark、Presto等计算引擎尽量使用计算节点的内存对数据进行缓存，从而提高整个数据过程的效率和系统吞吐能力。 1.2 Lambda架构随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。 然而，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求，对实时性要求高的场景，就会使用Flink+Kafka的方式构建实时流处理平台，来满足用户的实时需求。于是Lambda架构被提出，如下图所示。  Lambda架构的核心理念是“流批分离”，如上图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过服务层对应用提供，确保访问的一致性。 这种数据架构包含非常多的大数据组件，很大程度上增强了整体架构的复杂性和维护成本。 1.3 Lambda架构的痛点经过多年的发展，Lambda架构比较稳定，能满足过去的应用场景。但是它有很多致命的弱点：  1、数据治理成本高 实时计算流程无法复用离线数仓的数据血缘、数据质量管理体系。需要重新实现一套针对实时计算的数据血缘、数据质量管理体系。 2、开发维护成本高 需要同时维护离线和实时两套数据仓库系统，同一套计算逻辑要存储两份数据。例如，某一条或几条原式数据的更新，就需要重新跑一遍离线数据仓库，数据更新成本非常大。 3、数据口径不一致 因为离线和实时计算走的是两个完全不同的代码，由于数据数据的延迟到达和两类代码运行的时间不一样，导致计算结果不一致。 那么有没有一种架构能解决Lambda架构的问题呢？ 1.4 Kappa架构Lambda架构的“流批分离”处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。接下来我们介绍一下Kappa架构，通过Flink+Kafka将整个链路串联起来。Kappa架构解决了Lambda架构中离线处理层和实时处理层之间计算引擎不一致，开发、运维成本成本高，计算结果不一致等问题。  Kappa架构的方案也被称为“批流一体化”方案。我们借用Flink+Kafka来构建流批一体化场景，当需要对ODS层数据做进一步的分析时，将Flink计算结果的DWD层写入到Kafka，同样也会将一部分DWS层的计算结果Kafka。Kappa架构也不是完美的，它也有很多痛点。 1.5 Kappa架构的痛点 1、数据回溯能力弱 但是Kafka对复杂的需求分析支持能力弱，在面对更复杂的数据分析时，又要将DWD和DWS层的数据写入到ClickHouse、ES、MySQL或者是Hive里做进一步分析，这无疑带来了链路的复杂性。更大的问题是在做数据回溯时，由于链路的复杂性导致数据回溯能力非常弱。 2、OLAP分析能力弱 由于Kafka是一个顺序存储的系统，顺序存储系统是没有办法直接在其上进行OLAP分析的，例如谓词下推这类的优化策略，在顺序存储平台（Kafka）上实现是比较困难的事情。 3、数据时序性受到挑战 Kappa架构是严重依赖于消息队列的，我们知道消息队列本身的准确性严格依赖它上游数据的顺序，但是，消息队列的数据分层越多，发生乱序的可能性越大。通常情况下，ODS层的数据是绝对准确的，把ODS层数据经过计算之后写入到DWD层时就会产生乱序，DWD到DWS更容易产生乱序，这样的数据不一致性问题非常大。 1.6 大数据架构痛点总结从传统的hadoop架构往Lambda架构，从Lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，但是这些平台仍然存在很多痛点。  是否存在一种存储技术，既能够支持数据高效的回溯能力，支持数据的更新，又能够实现数据的批流读写，并且还能够实现分钟级到秒级的数据接入？ 1.7 实时数仓建设需求这也是实时数仓建设的迫切需求。实际上是可以通过对Kappa架构进行升级，以解决Kappa架构中遇到的一些问题，接下来主要分享当前比较火的数据湖技术。  那么有没有这样一个架构，既能够满足实时性的需求，又能够满足离线计算的要求，而且还能够减轻开发运维的成本，解决通过消息队列方式构建的Kappa架构中遇到的痛点？答案是肯定的，在文章的后面会详细论述。 二 数据湖助力于解决数据仓库痛点问题2.1 不断完善的数据湖理念数据湖是一个集中式存储库，可以存储结构化和非结构化数据。可以按业务数据的原样存储（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。  2.1.1 存储原式数据
2.1.2 灵活的底层存储功能在实际的使用过程中，数据湖中的数据通常并不会被高频访问，为了达到可接受的性价比，数据湖建设通常会选择性价比高的存储引擎（如S3/OSS/HDFS）。
2.1.3 丰富的计算引擎从数据的批量计算、流式计算，交互式查询分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。随着大数据与人工智能技术的结合，各类机器学习/深度学习算法也被不断引入进来，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行机器学习训练。因此，对于一个合格的数据湖项目而言，计算存储引擎的可插拔性，是数据湖必须具备的基础能力。 2.1.4 完善的数据管理
2.2 开源数据湖的架构LakeHouse架构成为当下架构演进最热的趋势，可直接访问存储的数据管理系统，它结合了数据仓库的主要优势。LakeHouse是基于存算分离的架构来构建的。存算分离最大的问题在于网络，特别是对于高频访问的数仓数据，网络性能至关重要。实现Lakehouse的可选方案很多，比如Delta，Hudi，Iceberg。虽然三者侧重点有所不同，但都具备数据湖的一般功能，比如：统一元数据管理、支持多种计算分析引擎、支持高阶分析和计算存储分离。 那么开源数据湖架构一般是啥样的呢？这里我画了一个架构图，主要分为四层：  2.2.1 分布式文件系统第一层是分布式文件系统，对于选择云上技术的用户，通常会选择S3和阿里云存储数据；喜欢开源技术的用户一般采用自己维护的HDFS存储数据。 2.2.2 数据加速层第二层是数据加速层。数据湖架构是一个典型的存储计算分离架构，远程读写的性能损耗非常大。我们常见的做法是，把经常访问的数据（热点数据）缓存在计算节点本地，从而实现数据的冷热分离。这样做的好处是，提高数据的读写性能，节省网络带宽。我们可以选择开源的Alluxio，或者阿里云的Jindofs。 2.2.3 Table format 层第三层是Table format层，把数据文件封装成具有业务含义的表，数据本身提供ACID、snapshot、schema、partition等表级别的语义。这一层可以选择开源数据湖三剑客Delta、Iceberg、Hudi之一。Delta、Iceberg、Hudi是构建数据湖的一种技术，它们本身并不是数据湖。 2.2.4 计算引擎第四层是各种数据计算引擎。包括Spark、Flink、Hive、Presto等，这些计算引擎都可以访问数据湖中的同一张表。 三 数据湖和数据仓库理念的对比3.1 数据湖和数据仓库对比下面跟大家聊聊我所理解的数据湖的本质，对于一种新事物不了解本质，你就很难驾驭它，下面这张图道尽了一切。  对数据湖的概念有了基本的认知之后，我们需要进一步明确数据湖需要具备哪些基本特征，特别是与数据仓库相比，数据湖具有哪些特点。我们引用一下AWS数据仓库和数据湖对比官方对比表格。 每个公司需要数据仓库和数据湖，因为它们分别满足不同的需要和使用案例：
 上表介绍了数据湖与传统数据仓库的区别，下面我们将从数据存储和计算两个层面进一步分析数据湖应该具备哪些特征。 3.2 写时模式和读时模式3.2.1 写时模式数据仓库的“写入型Schema”背后隐藏的逻辑就是在数据写入之前，必须确认好数据的Schema，然后进行数据导入，这样做的好处是：可以把业务和数据很好的结合在一起；不足就是在业务模式不清晰，还处于探索阶段时，数仓的灵活性不够。 3.2.2 读时模式数据湖强调的是“读取型Schema”，背后潜在的逻辑是，认为业务的不确定性是常态：既然我们无法预测业务的发展变化，那么我们就保持一定的灵活性。将结构化设计延后，让整个基础设施具备使数据“按需”贴合业务的能力。因此，数据湖更适合发展、创新型企业。 3.3 数据仓库开发流程数据湖采用的是灵活，快速的“读时模式” ，在数字化转型的浪潮下真正帮助企业完成技术转型，完成数据沉淀，应对企业快速发展下层出不穷的数据需求问题。 3.4 数据湖的架构方案数据湖可以认为是新一代的大数据基础设施。在这套架构中，无论是数据的流式处理，还是批处理，数据存储都统一到数据湖-Iceberg上。很明显，这套架构可以解决Lambda架构和Kappa架构的痛点问题： 3.4.1 解决Kafka存储数据量少的问题目前所有数据湖基本思路都是基于HDFS之上实现的一个文件管理系统，所以数据体量可以很大。 3.4.2 支持OLAP查询同样数据湖基于HDFS之上实现，只需要当前的OLAP查询引擎做一些适配，就可以对中间层数据进行OLAP查询。 3.4.3 数据治理一体化批流的数据在HDFS、S3等介质上存储之后，就完全可以复用一套相同的数据血缘、数据质量管理体系。 3.4.4 流批架构统一数据湖架构相比Lambad架构来说，schema统一，数据处理逻辑统一，用户不再需要维护两份数据。 3.4.5 数据统计口径一致由于采用统一的流批一体化计算和存储方案，因此数据一致性得到了保证。 3.5 孰优孰劣数据湖和数据仓库，不能说谁更好谁更差，大家都有可取之处，可以实现双方的优势互补，我这里画一张图，方便你的理解：
四 数据湖助力数据仓库架构升级4.1 构建数据湖的目标数据湖技术-Iceberg目前支持三种文件格式：Parquet，Avro，ORC。如下图所示，Iceberg本身具备的能力总结如下，这些能力对于构建湖仓一体化是至关重要的。
4.2 准实时数据接入数据湖技术-Iceberg既支持读写分离，又支持并发读、增量读、小文件合并，还可以支持秒级到分钟级的延迟，基于这些优势我们尝试采用Iceberg这些功能来构建基于Flink的实时全链路批流一体化的实时数仓架构。 如下图所示，Iceberg每次的commit操作，都是对数据的可见性的改变，比如说让数据从不可见变成可见，在这个过程中，就可以实现近实时的数据记录。 4.3 实时数仓 - 数据湖分析系统在建设离线数据仓库时，首先要进行数据接入操作，比如用离线调度系统定时抽取数据，再经过一系列的ETL操作，最后将数据写入到Hive表里面，这个过程的延时比较大。因此，借助于Iceberg的表结构，可以使用Flink，或者Spark Streaming，实现近实时的数据接入，以降低数据延迟性。 基于上面的功能，我们回顾一下前面讨论的Kappa架构，我们已经知道Kappa架构的痛点，Iceberg既然能够作为一个优秀的表格式，又可以支持Streaming reader和Streaming sink。那么，是否可以考虑将Kafka替换成Iceberg？ Iceberg底层依赖的存储是像HDFS或S3这样的廉价存储，并且支持parquet、orc、Avro等存储结构。可以对中间层的结果数据进行OLAP分析。基于Iceberg snapshot的Streaming reader功能，可以把离线任务天级别到小时级别的延迟大大的降低，改造成一个近实时的数据湖分析系统。 在中间处理层，可以用Presto进行一些简单的SQL查询，因为Iceberg支持Streaming Read，所以在系统的中间层也可以直接接入Flink，直接在中间层用Flink做一些批处理或者流式计算的任务，把中间结果做进一步计算后输出到下游。 4.4 Iceberg替换Kafka的劣势总的来说，Iceberg替换Kafka的优势主要包括：
当然，也存在一定的缺陷，如：
4.5 通过Flink CDC解决MySQL数据同步问题Iceberg提供统一的数据湖存储表格式，支持多种计算引擎（包括 Spark、Presto、hive）进行数据分析；可以产生纯列存的数据文件，而列式文件非常适合用来做OLAP操作；Iceberg基于Snapshot的设计模式，支持增量读取数据；Iceberg的接口抽象程度高，兼容性好，既独立于上层的计算引擎又独立于下层的存储引擎，这就方便用户自行定义业务逻辑。 将数据连同CDC flag直接append到Iceberg当中，在merge的时候，把这些增量的数据按照一定的组织格式、一定高效的计算方式与全量的上一次数据进行一次merge。这样的好处是支持近实时的导入和实时数据读取；这套计算方案的Flink SQL原生支持CDC的摄入，不需要额外的业务字段设计。 五 数据湖技术的发展前景数据湖可能是在下一场大数据技术变革中的亮点，我们需要抓住机遇、抢占先机，一起来学习数据湖。但是我的建议仍然是“学而不用”，为什么这么说呢？例如：在2018年开始的时候，我们一窝蜂的上线Flink，然后一个月一个版本的升级。简直是吃尽了苦头。所以，我们就等互联网大厂把坑填完了，我们再直接短平快的上马数据湖，但是我们一定要学习。 六 总结通过这篇文章，我们基本了解了什么是数据湖，以及为什么要学习数据湖，它能解决哪些实际问题。后面我们将继续重点讲解为什么要选择Iceberg作为数据湖的解决方案。 |
|
|
