如何进行湖仓一体架构设计
*本文为「码上观世界」原创内容
今日奇想：火星的现状被认为是未来地球的模样，目前世界主要国家相继探测火星生命存在的可能性，但是仍没有重要进展。假如火星在漫长的历史变迁的某一段时期存在高等生物，并相继发展到了一定高度的文明，那么在火星变得温度极端不适合星球表面生存的时候，一定会尝试往底层深处挖掘洞穴的方式延缓灭亡，类似地球早期原始人洞穴生活那样。此外，文明生活也会留下历史古迹，这些都是考古学家和民间盗墓人士的绝活，因此有必要在人类到达火星前，加快培训这类高手上岗。
数仓与数据湖
数据仓库之父Bill Inmon指出：“数据仓库是一个面向主题的、集成的、反映历史变化的、非易变的数据集合，用于支持管理决策过程。”而数据湖，AWS给出的定义是“一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。”
AWS列出了数仓和数据湖两者各自的特性：
有微软的分析师对比数据湖和数据仓库各自的优缺点，并列举如下：
湖仓一体具有以下五个关键特性：
支持分析结构化和非结构化数据；
适用于分析师和数据科学家，不仅支持报表，而且支持机器学习和人工智能相关用例；
数据可治理，避免产生沼泽；
架构鲁棒安全，确保利益相关者能正确访问以数据为中心的安全架构；
以合理代价实现有效扩展
数仓平台架构演进
第一代数仓平台计算与存储耦合，扩容和运维成本过高，且不支持非结构化数据。
第二代数仓平台基于数据湖+数仓的双层架构虽然解决了计算和存储耦合的问题，但是相比一代数仓平台，又多了从运营系统到数据湖的ETL以及从数仓到湖的ETL过程，增加了系统的复杂度和脆弱性，数据的重复存储和计算引入了额外的成本。同时基于数据湖的数据应用失去了数据仓库的丰富管理功能，以及缺乏必要的事务管理功能和跟数据仓库相适应的性能优化能力。
第三代数仓平台结合数据仓库和数据湖各自的优点，将数据仓库的丰富管理功能和跟数据仓库相适应的性能优化能力与支持多种数据格式的低成本存储的数据湖的灵活性结合起来，并引入统一元数据层，不仅统一了基于表的数据访问和基于文件的数据访问方式，还实现了事务管理功能和其他诸如访问控制、版本控制等管理功能，形成lakehouse架构。
Lakehouse 是一种结合了数据湖和数据仓库优势的新范式，解决了数据湖的局限性。Lakehouse 使用新的系统设计：直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据架构和数据管理功能。Lakehouse首先基于标准文件格式（如Apache Parquet、ORC等）将数据存储在独立部署的低成本对象存储（例如Amazon S3、Aliyun OSS）中，并允许客户端使用标准文件格式直接从该存储中读取对象，这样许多ML库（例如TensorFlow和Spark MLlib）就可以读取数据湖文件格式（如Parquet）。其次，为了做到事务管理和版本控制，Lakehouse提供了公共元数据层，数据访问通过逻辑表的形式对外暴露，比如lakehouse框架实现之一的Apache Iceberg的表由一系列快照文件组成，每个快照文件（snapshot）存储一个清单列表文件（manifest list），清单列表文件记录1至多个清单文件（manifest file）的路径和相关文件的统计数量信息等，而清单文件记录了组成某个快照的数据文件（data file）列表。每行都是每个数据文件的详细描述，包括数据文件的状态、文件路径、分区信息、列级别的统计信息（比如每列的最大最小值、空值数等）、文件的大小以及文件里面数据的行数等信息。数据文件是 Apache Iceberg 表真实存储数据的文件，可以采用parquet、avro等格式。它们之间的关系如下图所示：
有了公共元数据层，高级数据处理库（ML等）就可以查询表所属的文件列表，然后直接读取并处理文件。另外，为了解决在实时数据同步和离线数据同步场景中一份数据被两次ETL（一次增量传给实时处理，一份全量传给批量处理）带来的数据处理链路复杂和数据重复存储带来的问题，lakehouse引入了增量更新、事务管理功能和版本控制等高级特性，不仅将ETL过程大大缩短而且将原本的离线日T+1时间缩短到分钟级别。
最后，lakehouse面临的最大技术问题是在受限于网络带宽且独立存储的外部开放数据格式的情境下，如何优化SQL性能，相比之下经典数仓对SQL进行更彻底的优化（包括使用专有存储格式）。Lakehouse除了需要探讨是否存在不同于现有的标准格式（例如Parquet和ORC）的存储文件格式，还需要探讨在与格式无关的优化技巧。目前lakehouse常用的优化方式包括使用高性能的存储设备（如SSD、RAM缓存等），使用Parquet/ORC数据格式中的辅助数据结构（如BloomFilter、统计信息等）以及在这些现有格式内优化数据布局（如数据聚集和排序等）。
经过优化改进后的lakehouse架构如下所示：
实际上，Lakehouse代表了湖仓融合的一种方向：基于Hadoop体系的数据湖向数据仓库能力扩展，湖中建仓，从DataLake进化到LakeHouse。LakeHouse结合了数据湖和数据仓库特点，直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。目前业界已经涌现了一些LakeHouse产品，如Netflix开源Iceberg、Uber开源Hudi、Databricks的 DeltaLake。
阿里云基于Hudi构建的OLAP数据湖产品便是这种融合方向的一个案例，它强化数据贴源层端的数据入湖功能，并在此基础上通过统一元数据和统一调度实现一定程度的数据聚合和应用。
另一个融合方向是数据湖和数据仓库协同起来向湖仓一体的融合分析架构发展，随着企业数据量快速增长，不仅是结构化数据，也有非结构化数据，同时提出了对搜索/机器学习更多的能力要求，使得原来数仓技术不能够有效的处理复杂场景，为此需扩展原有系统，引入Hadoop大数据平台实现新类型数据、新业务场景的支持。在这个背景下由Gartner在2011年提出逻辑数据仓库的概念，预测企业数据分析倾向于转向一种更加逻辑化的架构，利用分布式处理、数据虚拟化以及元数据管理等技术，实现逻辑统一物理分开的协同体系。
如下图的逻辑数仓采用与经典数仓类似的分层数据架构，区别在于在数据贴源层引入数据虚拟化技术，通过表视图的方式建立数据虚拟层，直接使用源库的数据进行过滤，清洗等功能，然后基于虚拟层再构建上层数据架构。数据虚拟层的引入避免了数据在不同系统之间集成的复杂度，有助于降低数据重复和提升数据质量。
基于逻辑数仓的设计理念来构建数据湖，首要问题是实现统一的元数据，打通不同数据系统，使其具备数据共享和跨库分析能力，支持互联互通、计算下推、协同计算，实现数据多平台之间透明流动。采用这种架构的首次尝试产品是AWS的RedShift，为了支持访问S3的数据，RedShift通过Spectrum创建外表的形式将外部数据映射到RedShift：
create external schema s3_external_schema
from data catalog
database 'spectrumdb' iam_role 'arn:aws:iam:::role/aod-redshift-role'create external database if not exists;
CREATE external table s3_external_schema.LINEITEM_CSV (
L_ORDERKEY BIGINT,
L_PARTKEY INT,
L_SUPPKEY INT,
L_LINENUMBER INT,
L_QUANTITY DECIMAL(12,2),
L_EXTENDEDPRICE DECIMAL(12,2),
L_COMMENT VARCHAR(128))row format delimitedfields terminated by '|'stored as textfile
location 's3:////lineitem_csv/';
创建的外部表跟内部表一样，注册到全局的元数据系统Glue Data Catalog 中，有了公共元数据，其他产品如RDS、Athena、EMR都可以基于元数据访问同样的一份数据（shared data）。值得一提的是Glue不仅负责管理元数据，还负责数据的爬网ETL任务运行和调度等。
对Redshift Spectrum来说，访问外部数据需要人工创建外部表并导入外部数据，相对全自动导入外部元数据来讲，还不够彻底。阿里云的MaxCompute作为同样的云数仓产品，在解决无法访问EMR Hadoop集群的元数据问题时，使用数据自动映射的方式，全部导入元数据，在一个平台访问两个系统的数据。下图是阿里云为微博大数据平台提供的解决方案：将EMR Hadoop元数据映射到MaxCompute，然后基于统一的数据开发平台DataWorks进行数据开发和查询：
为了避免热数据访问性能问题，MaxCompute通过智能调度技术，将面向生产的高频数据和任务，无缝调度到数据仓库中，以得到更好的性能和成本。相比Redshift，这一做法相对彻底，但是相对于AWS的整个数据产品体系来讲，该做法更显得是一种事后补救措施，并没有将其他存储产品的元数据打通。
通过上述案例可知，两种融合方向并不是完全排斥的，比如Redshift Spectrum通过外表访问S3数据，可以看做第二种逻辑数仓的融合方案，但Redshift Spectrum本身又可看做构建于数据湖之上的数仓产品，这属于第一种融合方向。当然Redshift也可看做独立的数仓产品。
湖仓一体参考架构
湖仓一体架构除了满足以上提到的关键特性，在实现中还需要解决以下几个关键问题：
1. 支持丰富、便捷、可靠的数据入湖接入，比如支持ACID事务控制，缩短数据入湖链路
2. 支持统一的元数据，打通不同数据系统，使其具备数据共享和跨库分析能力，支持互联互通、计算下推、协同计算
3. 支持统一数据开发，在一个平台访问多种数据源，支持低门槛的SQL开发方式
4. 支持统一任务智能调度和运维监控
5. 支持统一查询，通过联邦查询访问不同数据源
上述架构的主链路是数据源入湖并进行Data lake Catalog元数据注册，然后基于统一元数据进行数据湖上的计算分析和数仓建模。该链路建立在存储和计算分离和共享元数据前提下，存储和计算分离保证了各自独立部署和扩容，共享元数据保证了计算引擎的独立和数据的共享。
在数据接入层，支持Hive、S3、RDS、Kafka等不同数据源的接入，数据源接入既可以直接入湖再分析，也可以先分析再入湖，避免数据的重复存储和复杂集成问题。
在元数据层，统一元数据既支持通过lakehouse架构统一管理的元数据，也支持通过映射外部数据源系统的元数据。
数据集成与开发、数据治理与服务和运维监控、权限管理作为架构补充，提供了用户易于操作的管理界面和运维界面。
在上层计算和查询层，基于统一元数据层，同时支持数据仓库建模和高级数据处理应用。多种独立的EMR计算引擎基于多版本的lakehouse架构既支持实时数据处理也支持历史全量数据处理。联邦查询基于元数据打通不同数据源的互联互通。
建立真实有效湖仓一体架构，应遵循如下五个关键原则：
计算和存储的解耦：首要原则是加入解耦和存储。存储便宜且持久，计算昂贵且短暂。计算和存储的解耦，可使系统灵活地按需升级并扩展计算服务。
目标驱动的存储层：数据以多种形态和形式呈现，因此数据的存储方式应具灵活性，以适应数据的不同形态和用途。灵活性包括根据数据的种类及提供方式不同，提供关系层、图数据层、文档层以及 Blob 等多模态存储层。
模块化的体系架构：该原则源自于 SOA，确保数据处于核心地位，以围绕数据开展所需服务为关键。基于数据开展数据抽取、处理、编目和分析等不同类型的服务，而不是借助流水线将数据提供给服务。
聚焦于功能，而非技术：该原则体现了灵活性。功能的变化缓慢，但技术的变革日新月异。因此一定要聚焦于组件所完成的功能，进而可轻易追随技术的发展而替换旧技术。
活动编目（Active cataloging）：该项基本原则是避免数据湖沦为数据沼泽的关键。编目上需具有明确的治理原则，有助于确保数据充分记录到数据湖中。
特别是数据编目尤其值得重视，AWS指出，“数据湖架构的主要挑战是存储原始数据而不监督内容。对于使数据可用的数据湖，它需要有定义的机制来编目和保护数据。没有这些元素，就无法找到或信任数据，从而导致“数据沼泽”的出现。满足更广泛受众的需求需要数据湖具有管理、语义一致性和访问控制。”
参考链接：
http://docs.media.bitpipe.com/io_12x/io_128955/item_1271002/r20-logical-data-warehouse-analyst-paper.pdf
http://cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf
https://www.eckerson.com/articles/an-architect-s-view-of-the-data-lakehouse-perplexity-and-perspective
https://aws.amazon.com/cn/big-data/datalakes-and-analytics/what-is-a-data-lake/
https://mp.weixin.qq.com/s/XNcyPHPsqAhEFWEuxtafCg
https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html
https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html