湖仓架构的演进

1.数据仓库架构的历史演进

起初，业界数据处理首选方式是数仓架构。通常数据处理的流程是把一些业务数据库，通过ETL的方式加载到Data Warehouse中，再在前端接入一些报表或者BI的工具去展示。

数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。

后来随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是 Lambda 架构。

再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的 Kappa 架构。

2.Lambda架构

传统的数仓架构

随着大数据的兴起，越来越多的公司开始面临海量数据的处理问题。传统的批处理系统无法满足实时数据处理的需求，而简单的流式处理系统又无法进行复杂的历史数据分析。这就需要一种混合架构，能够兼顾实时性和复杂分析。Lambda架构应运而生。

从底层的数据源开始，经过Kafka、Flume等数据组件进⾏收集，然后分成两条线进⾏计算：⼀条线是进⼊流式计算平台（例如 Storm、Flink或者SparkStreaming），去计算实时的⼀些指标；另⼀条线进⼊批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔⽇才能看见。

在这种架构下，流处理和批处理同时存在，以实现不同的业务场景数据需求。

批处理：批处理层存储管理主数据集（不可变的数据集）和预先批处理计算好的视图：批处理层使⽤可处理⼤量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。
流处理：流处理层通过提供最新数据的实时视图来最⼩化延迟。流处理层所⽣成的数据视图可能不如批处理层最终⽣成的视图那样准确或完整，但它们⼏乎在收到数据后⽴即可⽤。⽽当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。

Lambda架构经历多年的发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以⽤晚上的时间来整体批量计算，这样把实时计算和离线计算⾼峰分开，这种架构⽀撑了数据⾏业的早期发展，但是它也有⼀些致命缺点，并在⼤数据3.0时代越来越不适应数据分析业务的需求。Lambda架构存在问题：

同时维护实时平台和离线平台两套引擎，运维成本高
实时离线两个平台需要维护两套框架不同但业务逻辑相同代码，开发成本高
数据有两条不同链路，容易造成数据的不一致性
数据更新成本大，需要重跑链路
随着业务数据量的增大，批量计算在计算窗⼝内⽆法完成。

3.Kappa架构

Kafka的创始⼈Jay Kreps认为在很多场景下，维护⼀套Lambda架构的⼤数据处理平台耗时耗⼒，于是提出在某些场景下，没有必要维护⼀个批处理层，直接使⽤⼀个流处理层即可满⾜需求，即下图所⽰的Kappa架构：

这种架构只关注流式计算，数据以流的⽅式被采集过来，实时计算引擎将计算结果放⼊数据服务层以供查询。可以认为Kappa架构是Lambda架构的⼀个简化版本，只是去除掉了Lambda架构中的离线批处理部分。

Kappa架构的兴起主要有两个原因：Kafka不仅起到消息队列的作⽤，也可以保存更长时间的历史数据，以替代Lambda架构中批处理层数据仓库部分。流处理引擎以⼀个更早的时间作为起点开始消费，起到了批处理的作⽤。

Flink流处理引擎解决了事件乱序下计算结果的准确性问题。Kappa架构相对更简单，实时性更好，所需的计算资源远⼩于Lambda架构。但是，Kappa架构不能完全取代Lambda架构，Kappa架构也有其缺点：

对消息队列存储要求高，消息队列的回溯能力不及离线存储
消息队列本身对数据存储有时效性，且当前无法使用 OLAP 引擎直接分析消息队列中的数据
全链路依赖消息队列的实时计算可能因为数据的时序性导致结果不正确

4.Lambda架构 VS Kappa架构

两种架构的区别如下：

Lambda架构通过批处理层和速度层的组合，兼顾了低延迟和复杂分析，但系统较复杂，存在数据冗余和延迟不一致问题。

Kappa架构只通过流式系统实现所有处理，简化了架构，但历史数据分析相对复杂，需要流式系统保证精确一次语义。

Lambda和kappa架构两者都有各自的优缺点，需要根据具体场景进行技术选型和设计权衡。他们都有各⾃的适⽤领域；例如流处理与批处理分析流程⽐较统⼀，且允许⼀定的容错，⽤Kappa⽐较合适，少量关键指标（例如交易⾦额、业绩统计等）使⽤Lambda架构进⾏批量计算，增加⼀次校对过程。还有⼀些⽐较复杂的场景，批处理与流处理产⽣不同的结果（使⽤不同的机器学习模型，专家系统，或者实时计算难以处理的复杂计算，可能更适合Lambda架构。

5.湖仓一体架构

随着企业数据量的爆炸式增长，以及越来越多的企业上云，数据平台面临的数据存储、数据处理的挑战越来越大，采用什么样的技术来构建和迭代这个平台一直是业界研究的热点，新技术和新思路不断涌现。这些技术归纳下来以数据仓库 (Data Warehouse) 和数据湖 (Data Lake) 为两类典型的路线。近年来这两个路线在演进过程中边界日趋模糊，逐渐走向融合，开始形成所谓的现代数据架构 (Modern Data Architecture)，又称湖仓一体 (Data Lakehouse)。

针对传统意义的数据湖，若在对象存储或者Hadoop上能够构建出具备数仓语义的一个格式，使得我们在湖上的格式有更强的能力去做数仓，则需要具备几个条件：

湖上可靠的数据管理：即需要一种开放的高性能的数据组织方式。采用传统方式定义表时，缺乏一种高效的表的组织方式。我们通常用 Hive表，它就是一个目录，没有特殊的能力。我们需要一种更高效的组织能力，兼顾一些仓的特性。
支持机器学习和数据科学：湖仓一体的技术需要有一套开放的标准或者开放的接口。大家在用数仓的时候，会发现它是存算一体的数仓，存储就是为了计算所定制。虽然性能很好，但不开放，也就是所有的生态都要建立在上面，但数据湖则是天然开放，Flink和Spark等其他引擎都能使用这些数据。
最先进的SQL性能：若湖仓一体只是湖，那么很轻易就能办到，但是它的性能会比较差。如果要使表具备仓的性能，比如能够匹敌类似Snowflake或者Redshift这样的性能，则需要一个高性能的SQL引擎，这也是Databricks做了Photon引擎的原因，有了这些，我们就可以真正在湖上构建出一个高性能的数仓，也就是“湖仓一体”。

如今在开源领域主要有四种技术拥有这些特性，分别是：Hudi、Iceberg、Delta Lake和Paimon。它们的功能整体上比较接近，都是一种数据的组织方式，即定义了一种表的格式，这个格式主要是定义数据的组织方式，而不是确定一种数据的存储格式。与一些纯粹的数据格式或Hive表（Hive 3.0版本前）相比，它提供了ACID事务能力，这样就具备了仓的能力，它可以提供一些事务的特性和并发能力，还可以做行级数据的修改、表结构的修改和进化，这些都是传统大数据格式难以完成的事项。

湖仓一体的技术优势：