2.3 数据仓库 vs 数据湖
经过前面对数据仓库和数据湖的比较，我们可以看到，两者在设计上的根本分歧点是对包括存储系统访问、权限管理、建模要求等方面的把控：
- 数据仓库，更加关注的是数据使用效率、大规模下的数据管理、安全/合规这样的企业级需求；
- 数据仓库中，数据经过统一但开放的服务接口进入数据仓库，数据通常预先定义 schema，用户通过数据服务接口或者计算引擎访问分布式存储系统中的文件；
- 数据仓库中，通过抽象数据访问接口/权限管理/数据本身，换取了更高的性能（无论是存储还是计算）、闭环的安全体系、数据治理的能力等，这些能力对于企业长远的大数据使用都至关重要；
- 数据湖，通过开放底层文件存储，给数据入湖带来了最大的灵活性：进入数据湖的数据可以是结构化的，也可以是半结构化的，甚至可以是完全非结构化的原始日志。
- 数据湖，通过开放底层文件存储，给上层的引擎也带来了更多的灵活度：各种引擎可以根据自己针对的场景随意读写数据湖中存储的数据，而只需要遵循相当宽松的兼容性约定；
- 数据湖，开放底层文件存储允许文件系统直接访问，使得很多更高阶的功能很难实现：例如细粒度（小于文件粒度）的权限管理、统一化的文件管理，ACID事务管理等，读写接口升级也十分困难（需要完成每一个访问文件的引擎升级，才算升级完毕）；
- 由于数据湖的上述特点，数据湖虽然容易落地，但随着湖中数据量的增多，一旦数据治理措施不善，数据湖容易退化为数据沼泽，数据质量低下，用户无法访问数据或不易找到需要的数据，整个数据湖的价值也就退化了；
数据仓库和数据湖，各有自己的优缺点，前者主要支撑BI场景，后者主要支撑AI场景，两者并不是互斥的关系：「企业搭建数据平台时，既有BI需求也有AI需求，所以现阶段，很多数据平台是融合了数据仓库和数据湖的：使用数据湖泊作为底座，在数据湖基础上组建多个数据仓库，数据仓库支撑各种BI业务场景，数据湖泊的底座除了支撑各个数据仓库，也可以直接支撑机器学习和深度学习等AI场景；」
2.4 数据湖仓
上文讲到，企业搭建数据平台时，由于既有BI需求也有AI需求，所以现阶段，很多数据平台中融合搭建数据湖和数据仓库以应对BI和AI两大类数据分析场景，但是这样势必会造成资源的浪费，增加了数据成本。 为解决数据平台中融合搭建数据仓库和数据湖造成的资源浪费问题，数据仓库和数据湖厂商都做了自己的尝试，给出了相应的解决方案：
- 数据仓库厂商，推出的方案是，在自身已有功能的基础上，开发各种连接器connector，然后以外表形式访问外部数据湖底层存储系统中的数据，从而扩展自己的功能；（如 GP/Doris 等都推出了访问HDFS数据湖的connector）
- 而数据湖厂商，推出的方案是，补齐短板，改进和增强自身功能，包括支持ACID事务，加强数据治理能力等，这种方案本质是数据湖2.0，业界倾向叫它湖仓一体或数据湖仓 lake house，以强调其整合了传统的data lake 和 data warehouse的能力；
笔者尝试使用如下一句话概括总结下数据湖仓：「数据湖仓是在数据湖的基本架构上，通过一系列以表格式 Table Format 为代表的新技术解决了数据湖泊的各种传统痛点，将数据仓库和数据湖泊功能融合在一起，使其具有了数据仓库在数据管理方面的各种优点，并直接支持 BI和AI的各种数据分析场景的新型架构」
数据湖仓最大的技术创新是，通过一系列以表格式 Table Format 为代表的新技术，为数据湖的基本架构带来了ACID事务支持，提供了对记录级别的增删改的支持，对多作业并发读写同一个表或同一个分区的的支持，从而支持了以下特性：
- 数据湖仓在数据湖的架构基础上融合了数仓式的数据管理能力：A lakehouse uses similar data structures and data management features as those in a data warehouse but instead runs them directly on data lakes，
- 数据湖仓同时直接支持BI和AI:A lakehouse allows traditional analytics, data science, and machine learning to coexist in the same system, all in an open format;
- 在数据湖仓lake house这个概念下，目前有 delta lake/hudi/iceberg 甚至 hive orc事务表这些框架来支持；
数据湖仓一般具有以下基本特征：
- 使用统一的存储引擎和开放的格式(文件格式和表格式)；
- 对象存储优先；
- 支持多种分析引擎；
- 支持并发读写和事务的acid特性；
- 支持记录级别的增删改；
- 支持增量更新数据； 数据湖仓通常也支持以下高级特性:
- 模式演化模式约束: schema evolution,schema enforecement
- 历史版本回溯: history
- 流式增量导入(流批一体存储)
3 数据湖仓典型框架的特性与架构
数据湖厂商，改进和增强了自身功能，包括支持ACID事务和加强数据治理能力等，融合了传统的data lake 和 data warehouse的特点，推出了数据湖2.0方案，该方案即湖仓一体或数据湖仓 lake house，在数据湖仓lake house这个概念下，目前最主流的是数据湖三剑客： delta lake/apache hudi/apache iceberg;
- Delta lake: Delta Lake是由 Apache Spark 背后的商业公司 Databricks 推出的一个致力于在数据湖之上构建湖仓一体架构的开源项目，Delta Lake 支持ACID事务，可扩展的元数据存储，在现有的数据湖（S3、ADLS、GCS、HDFS）之上实现流批数据处理的统一；
- Apache Hudi：Hudi 最初是由 Uber 的工程师为满足其内部数据分析的需求而设计的数据湖项目， 其设计目标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），在开源的文件系统之上引入了数据库的表和事务的概念，支持高效的更新/删除、索引、流式写服务、数据合并、并发控制等功能特性。
- Apache Iceberg： Iceberg 最初是由 Netflix 为解决使用 HIVE 构建数据湖仓时的诸多缺陷而研发的，最终演化成 Apache 下一个高度抽象通用的开源数据湖方案，用于处理海量分析数据集的开放表格式，支持 Spark, Trino, PrestoDB, Flink and Hive等计算引擎，它具有高度的抽象和优雅的设计；
三大数据湖仓框架在官网对自身的介绍如下：
- Delta Lake is an open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs for Scala, Java, Rust, Ruby, and Python.
- Apahce Hudi: Hudi is a rich platform to build streaming data lakes with incremental data pipelines on a self-managing database layer, while being optimized for lake engines and regular batch processing. brings transactions, record-level updates/deletes and change streams to data lakes!
- Apache Iceberg: Iceberg is a high-performance format for huge analytic tables. Iceberg brings the reliability and simplicity of SQL tables to big data, while making it possible for engines like Spark, Trino, Flink, Presto, Hive and Impala to safely work with the same tables, at the same time.
三者均为 Data Lake 的数据存储中间层，是文件格式 file format之上的表格式 table format，其数据管理的功能均是基于一系列的 meta 文件：
- 文件格式：文件格式描述的是单个文件中数据的组织和管理格式，如ORC/PARQUET/AVRO等；
- 表格式：表格式表述的是由一系列文件构成的逻辑集合，即表，其底层的文件与数据的组织和管理格式；
- meta 文件类似于数据库的 catalog/wal，起到 schema 管理、事务管理和数据管理的功能：
- 与数据库不同的是，这些 meta 文件是与数据文件是一起存放在存储引擎中的，用户可以直接看到；
- meta 文件通常使用行存 json/avro格式，数据文件通常使用列存 parquet/orc格式；
- Meta 文件包含有表的 schema 信息: 因此系统可以自己掌握 Schema 的变动，提供 Schema 演化的支持；
- Meta 文件包含有事务日志 transaction log: meta 文件中记录了 transaction log，所以可以提供 ACID 事务支持；
- 所有对表的变更操作都会生成一份新的 meta 文件：于是系统就有了多版本的支持，可以提供访问历史版本的能力；
三者的相似点如下：
- 三者都是 Data Lake 的数据存储中间层，在技术实现上都是基于一系列的 meta 文件构建了file format 之上的table format；
- 三者都使用了统一的存储引擎和开放的格式(文件格式和表格式)；
- 三者都能支持主流的高可用存储如 HDFS、S3，对象存储优先；
- 三者都支持记录级别的 update/delete，以增量更新数据；
- 三者都支持并发读写和事务ACID特性：即原子性、一致性、隔离性、持久性，通过避免垃圾数据的产生保证了数据质量；
- 三者都 (努力）支持流批一体存储，以流式增量导入数据；
- 三者都提供了对多查询引擎的支持：如 Spark/Hive/Presto；
- 三者都支持历史版本回溯；
- 三者都支持模式约束和演化 schema evolution,schema enforecement；
三者最初的设计初衷和对应场景并不完全相同，尤其是Hudi，其设计与另外两个相比差别更为明显，但数据湖仓要解决的问题是共同的，随着时间的发展，三者都在不断补齐自己缺失的能力，在将来会彼此趋同，成为功能相似却又各有特点的主流数据湖仓框架，目前三者的差异点主要如下：
- Hudi 为了高效的 incremental 的 upserts，设计了类似于主键的HoodieKey 的概念，表也分为 Copy On write和Merge On Read，分别为读和写进行了优化；
- Iceberg 定位于高性能的分析与可靠的数据管理，专门针对HIVE的诸多痛点进行了设计；（如 HIVE 只有目录级别而没有文件级别的统计信息，元数据分散在 MySQL 和 HDFS中写入操作原子性差，等等）
- Delta 定位于流批一体的数据处理，与SPARK的兼容性最好；
以下重点看下Iceberg的架构特点：
- 整体分为三层：Catalog层，元数据层和数据层；
- 元数据层本身又是多层级的体系，包括：metadata file, manifest list, manifest file;
- Metadata file: Table state is maintained in metadata files. All changes to table state create a new metadata file and replace the old metadata with an atomic swap. The table metadata file tracks the table schema, partitioning config, custom properties, and snapshots of the table contents. A snapshot represents the state of a table at some time and is used to access the complete set of data files in the table.
- Manifest file: Data files in snapshots are tracked by one or more manifest files that contain a row for each data file in the table, the file’s partition data, and its metrics. The data in a snapshot is the union of all files in its manifests. Manifest files are reused across snapshots to avoid rewriting metadata that is slow-changing. Manifests can track data files with any subset of a table and are not associated with partitions.
- Manifest list/snapshot: The manifests that make up a snapshot are stored in a manifest list file. Each manifest list stores metadata about manifests, including partition stats and data file counts. These stats are used to avoid reading manifests that are not required for an operation.
- 通过表格式在文件而不是目录级别进行管理（显著区别与HIVE的地方）：This table format tracks individual data files in a table instead of directories. This allows writers to create data files in-place and only adds files to the table in an explicit commit.
4. 数据湖仓的应用现状与发展建议
对大多数尚未大规模引进数据湖仓技术的公司，笔者有如下几点建议：
- 随着数字化转型的进一步推进，BI和AI等各类数据分析需求日益递增，为更好地支撑各种数据需求，应尽早调研尝试引入数据湖仓作为企业级数据平台；（选择合适的产品/项目/场景，可以先从公司自身的数据平台着手）；
- 随着数字化转型的进一步推进，大数据与云计算的结合越来越紧密，数据湖仓平台底层的存储系统更倾向于使用S3/MINIO/OZONE等对象存储，应尽早调研尝试使用对象存储（公有云私有云行业云甚至数据中心等场景，都有相应的对象存储解决方案，存算分离架构下可以通过Alluxio 等缓存框架加速分析性能）；
- 随着数字化转型的进一步推进，企业愈加重视资源和应用的弹性/可扩展性以及成本，应尽早调研尝试在K8S上搭建数据湖仓平台；（大数据计算引擎如 spark/flink 等在 ON K8S 上部署方案已经成熟，AI的 tensorflow 等引擎在K8S上的部署方案也已成熟）；
- 加强公司内部AI和大数据部门之间的交流合作，尝试通过数据湖仓平台满足两个部门日常各种BI/AI类数据分析需求；
