4.2 惟客数据湖仓一体的演进

1.惟客大数据技术的历史状况

最初，惟客数据的中台产品——惟数云的架构是基于Hadoop生态体系构建而成的，在存储方面使用了分布式文件系统HDFS（Hadoop Distributed File System），首先利用自研的数据同步工具 Data-in 定时同步业务系统的数据到数据中台，然后利用不同的数据处理引擎分别进行离线和实时计算的加工。

离线数仓（数仓为数据仓库的简称）的加工采用 Hive 作为离线数仓工具，以Tez 为数据计算引擎的架构方案，每天定时对数据进行加工和处理并给到业务方，如图4-1所示。离线数仓的数据采集、计算任务的调度周期大多数都以天为颗粒度。为了能够在第二天上班前计算好报表数据，数据采集任务都集中设置在凌晨执行，因此凌晨成为资源消耗的高峰期。针对需要实时处理的场景，需要再投入大量资源建设一个实时数仓；由于离线与实时使用的技术栈不统一，因此系统需要投入更多的资源来维护。这种数仓架构存在诸多弊端：首先，每天将数据全量同步给数据库，给数据库造成非常大的压力，增加了业务系统的不稳定因素，同时也给集群的存储带来较大的成本压力。其次，集群的资源利用率不均，主要体现为凌晨高峰期资源紧张，经常出现作业排队的情况，但在白天资源大部分都处于闲置状态。这种高度集中的调度作业会使资源高度负载，作业的失败概率也会上升，如果出现关键作业失败，则会直接导致当天的数据报表无法使用。因此，为了保障数据能够被正常计算出来，需要安排专人值班，加重了相关人员的工作负担。

惟数云在实时数仓上采用的是 Lambda 架构，设计之初是为了在处理大规模的数据时，同时发挥流处理和批处理的优势。通过批处理提供全面、准确的数据；通过流处理提供低延迟的数据，从而达到平衡延迟、吞吐量和容错性的目的。Lambda架构有实时链路和批处理链路两条数据链路，数据采集使用流式同步工具，数据流实时地流向两条链路，Lambda架构如图4-2所示，实时数仓使用Canal、Debezium等CDC（Change Data Capture）工具。批处理链路的数据会落地到Hive数仓；实时链路为了提升数据使用的可重复性，将数据写入 Kafka 消息队列。在实际的业务场景中，一般企业的做法是同时利用 Lambda 和离线数仓两种方式搭建架构。这种架构的缺点是引入的组件多、架构复杂，维护成本高；实时计算和批处理的计算结果不一致会导致数据质量等问题；存在两个编程接口，需要开发两套程序，增加了开发人员的工作量与代码的维护难度。

2.惟客大数据技术遇到的挑战

随着惟客数据所服务客户业务的复杂度不断提升，数据计算任务随之不断增加，这在应用层面上对惟数云的技术提出了新的挑战。

（1）离线和实时的任务分离。数据开发人员需要维护两套不同的技术代码和任务：基于Flink的实时采集运算和基于Hive的离线任务调度，使数仓的开发、使用、运维都有诸多不便。同时，也会导致数据计算冗余。Flink处理当天的实时数据，每日凌晨离线的Hive又将业务系统白天产生的数据重新加载一遍进行批量计算，这样同一份数据在实时计算与离线计算中分别被存储起来，增加了额外的存储成本，而且因为离线计算需要在每日新增数据全部被重新采集后才能进行数仓模型的运算，所以就使得前端数据指标的计算时间被压缩。

（2）历史数据更新困难。在传统企业中，由于交易性数据业务的特殊性，需要更新历史订单数据，Hadoop并不支持对行级数据的单独更新和删除操作，因此需要将历史数据与变动数据进行全量匹配才能找出更改的部分，需要将历史数据与变动数据进行重新合并才能实现数仓中的数据与业务系统中的数据的一致性，这样通常会因为对一小部分历史数据的更新而把上千万条历史数据进行重算，大大浪费了服务器的资源。

惟数云团队秉承技术适配业务优先的原则，需要寻找更优的技术方案来解决这些问题。

3.数据架构技术发展阶段

随着企业业务与技术的发展，大数据架构也经历了数据仓库、数据湖、湖仓一体三个发展阶段。

数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的 Building the Data Warehouse 一书中提出了数据仓库的概念，这一概念被广泛接受并发展成为行业标准。数据仓库主要满足了企业内部业务部门对经营数据局部数字化分析的需求，让结构化数据能够被标准化加工处理和分析应用。

2011年，伴随着大数据技术的发展，衍生出基于“数据湖”的大数据架构技术，典型的开源技术是以 Hadoop 提供分布式存储和分布式计算为基础的大数据架构中的“数据湖”技术。数据湖的特点：数据存储的格式灵活多样，针对结构化、非结构化的原始数据都能进行很好的兼容，强调存储与使用的灵活性和兼容性，方便使用者随取随用。

湖仓一体的概念于2020年被首次提出，指将数据湖与数据仓库的架构进行融合，是一种将数据湖的灵活性和数据仓库的易用性、规范性、高性能结合起来的新型融合技术，这项技术既满足了数据仓库的规范化建设，也体现了数据湖使用的便捷性。

4.2.1 湖仓一体技术趋势

湖仓一体技术的核心思想是将数据仓库和数据湖之间进行联通，实现数据存储和计算架构的统一化与标准化。同时，数仓一体技术还能够支持多种数据类型的存储和访问，并通过提供统一封装的接口实现数据之间的共享。湖仓一体技术的最大优势在于，它兼具了数据仓库的高性能和标准化管理能力及数据湖的灵活性与扩展性。它能够充分利用现有的数据资源降低数据管理的成本，同时提高数据分析与挖掘的效率和精度。通过湖仓一体技术的应用，企业可以更加高效地管理数据资源，优化数据应用的质量和效果，进而实现更高的数据价值。同时，随着数据的不断增加和多样化，传统的数据管理方式已经不能满足企业的需求，采用湖仓一体技术可以更好地应对这些挑战，拓展数据应用的领域和范围。

通过将数据仓库构建在数据湖上，让存储变得更为廉价，降低了企业的存储成本。湖仓一体架构能充分发挥数据湖的灵活性与生态的丰富性，也能兼顾数据仓库的成长性，以构建企业级的数据管理能力。湖仓一体架构能够帮助企业建立数据资产，实现数据业务化，进而推进全线业务智能化，实现企业在数据驱动下的数据智能创新，全面支撑企业未来大规模的业务智能落地。

提到湖仓一体的架构，就不得不提到业界流行的“数据湖三剑客”：Delta Lake、Apache Iceberg和Apache Hudi，这三项技术的设计初衷都是为了解决企业在实际业务场景中遇到的数据处理问题，但是由于设计思想不同，它们有各自的优劣和不同应用场景下的定位。

Delta Lake：它的设计定位于流批一体的数据处理，是Databricks公司基于Spark推出的数据湖方案，增强Spark在流批处理场景下支持数据库事务的ACID［ACID是指数据库事务正确执行四要素的首字母缩写，原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）］能力。早期，客户在建设实时数仓时通常采用 Lambda 架构，该架构的实时场景使用Kafka作为存储层，流批处理任务都从Kafka获取数据进行分析处理。这种情况存在一些问题：Lambda架构方案需要的组件多、架构复杂，Kafka存储能力有限；缺失全局的 Schema 规范，上下游处理时导致 Schema 不一致；数据操作过程没有ACID保障，可能会读到中间状态的数据；不支持历史数据更新。为此，Databricks公司推出了Delta Lake方案来解决由Lambda架构维护实时、批量两套数据处理逻辑带来的重复开发、数据口径不一致、架构复杂等问题。

Apache Iceberg：Apache Iceberg 技术定位于高性能的分析与可靠的数据管理，其设计目标是一种开放通用的表格式实现方案，可以认为是介于上层计算引擎和底层存储格式之间的一个中间层，通过定义数据的元数据组织方式向计算引擎提供统一的类似于传统数据库中“数据表”的语义。Netflix公司早期基于Hive构建数据湖方案，但发现Hive在设计上存在诸多不足，如Hive分区颗粒度太大，分区的数据文件多；在执行简单查询时，分区裁剪阶段耗时长；依赖外部数据库存储信息；处理流程烦琐，先要通过数据库获取分区信息，再通过HDFS在每个分区上按目录遍历所有文件。当文件很大时，这种遍历非常耗时。因此，Netflix设计了自己的轻量级Apache Iceberg数据湖方案。在设计之初，Apache Iceberg的定位是一个通用的数据湖方案，因此在架构上做了高度抽象的设计。

Apache Hudi：Apache Hudi是Uber基于自身的业务特点发明的一个增量处理框架，以低延迟和高效率为业务关键数据管道提供动力，目的是解决HDFS增量的更新能力。Hudi通过对文件的插入更新和增量拉取两种方式来实现流式入湖和增量更新的功能。Uber的核心业务场景是将线上业务库的数据实时同步到数据中心，供上层业务做分析处理。Uber的早期方案也是基于Kafka做数据处理，这种设计最大的问题是无法快速Upsert存量数据。为了解决数据的更新问题，Uber团队在设计Hudi时，提供了COW（Copy On Write）和MOR（Merge On Read）两种数据格式。其中，MOR表是为快速更新而设计的；COW表在写入时将新数据和旧数据合并后再写入全量数据，写入延迟高。

上述三种数据湖技术均通过不同的方式实现了支持事务的 ACID 特性、多种存储类型（HDFS、对象存储），适配多种主流计算引擎（Spark、Flink）、模式演化、开放数据格式（Parquet、Arvo），历史数据回溯等。三种技术的实现逻辑均是数据湖和数据存储的中间层，核心管理能力都是基于Meta的元数据文件，通过统一的处理语言来实现处理和更新底层不同类型的数据文件。Meta文件的作用类似于数据库中的Catalog和WAL，能够管理Schema、事务等。Meta文件包含大量的元数据信息，基于这些元数据信息，数据湖技术可以实现数据表的Schema演化、事务ACID的支持等核心特性。由于Meta文件的内容每次发生变更都会生成一份全新的Meta文件，因此存在多个版本的 Meta 文件，这样系统在上层功能就可以实现数据的多版本控制。数据湖技术通常都会强依赖这些Meta文件来管理表信息，若Meta文件被删除或者存放的目录被更改，数据就会受到永久破坏。

4.2.2 湖仓一体实践案例

湖仓一体采用经典的分层架构模式，这是运用最为广泛的一种架构模式，具有高内聚、低耦合的特点，可以降低数据存储的耦合，各层承担各自的职责，结构清晰、可扩展性高。惟客数据基于Hudi的湖仓一体顶层架构设计分为三层：数据存储、资源计算和数据应用，如图4-3所示。每一层都专注于各自的领域，实现最佳技术组合与实践；由于技术栈的高度标准化，每一层都覆盖了前沿的创新技术，从技术产生的作用这一维度，每一层又可细分为多层。综合以上湖仓一体架构设计思想所遵循的标准化、规范化、精细化、敏捷等特点，企业可以灵活选择最优的方案。但是，由于湖仓架构设计覆盖面广、技术栈众多、技术细节复杂，因此企业在推动建设“湖仓一体”数据中心之前，需要充分考虑当前的业务场景、发展规模、企业的中远期战略规划等综合因素。

在引入Hudi之后，惟客数据湖仓一体不仅可以统一对接各种格式的数据（包括结构化数据和半结构化数据）存储，并且支持 OSS、S3、HDFS 等存储系统，而且还可以提供对 ACID、表结构的变更。另外，基于对 Snapshot 读取不同历史版本数据等功能的支持，惟客数据湖仓一体不仅可以管理数据湖的存储，而且还可以做到对原有数据仓库进行统一管理，在表结构层做到统一入口，图4-4所示为基于Hudi架构的数据文件合并原理图。

惟客数据中台的湖仓一体架构基于Flink CDC、Hudi、Hive、Presto等技术实现数据实时、增量入湖的能力，同步方式支持单表、多表、整库多种模式。数据源类型支持行业主流的数据库，如典型的 MySQL、Oracle、MongoDB 等数据库。通过Flink CDC技术监听数据库的归档日志，在上层业务增加、更新数据库之后，同步任务会先接收到数据变更事件，再通过数据管道流向Hudi并最终落地形成文件。Hudi内核支持 ACID 特性，为了提高 Hudi 的整体读/写吞吐量，使用缓冲、增量日志追加等方式写入文件系统。Hudi写入时会先写入固定大小的instant文件块，Hudi内部会维护一个 Timeline（时间线），并记录 instant 在时间轴上的操作。在 Hudi 接收到Compaction合并事件后，Hudi会启动独立作业执行合并动作，将instant文件中记录的更新、删除等操作合并到列式存储格式的数据文件中，供上游查询和分析使用。Hudi整库同步能力可以将大量任务合并成一个任务，简化了任务配置。所需的资源用量有所下降，集群的资源利用率得到整体提升，为企业的数字化建设降本增效。 RNnp9pqwcpHxEWk1TN1/BDpkiXmOrQ6thISa5GDwPjwRke0PLriFXINflssdjPwo