亚马逊AWS官方博客
数据分析的技术源流
Table of Contents
引子
数据的价值与数字化转型
传统的数据仓库 – Inmon vs Kimbal
数据仓库中的常见概念 – OLAP、MDA、cube
传统的大数据架构
新一代大数据架构
新一代的企业级数据存储 ： 数据湖（DataLake）
下一代的数据存储+分析架构：LakeHouse
Dalta Lake vs Apache Hudi vs Apache Iceberg
引子
如同娱乐圈热衷炒CP，IT圈的最爱莫过于炒概念。CP从自媒体博客主的随手拍开始，加以无数大V互转，饭圈男孩女孩一键三连，大概只需一夜就能获得热搜青睐。同理在IT圈，先要取一个堂皇的名字，包装上高深的理论，请大咖站台背书，一众小弟摇旗呐喊、软文铺天盖地。基本上这个概念已经成功了一半。接下来，还会有著书立说、战略规划、解决方案、咨询服务以及项目开发等一揽子生财之道。于是精英们屡试不爽的概念营销大获成功，而光鲜背后的一地鸡毛却留给了我们这些凡夫俗子。身处于这个大神遍地，架构师、咨询顾问参差不齐的行业就免不得有“入鲍鱼之肆”的窘境，但辨识一个概念的真正价值还是有一定的方法可循，溯其源头、有独立之见解，不敢说人间清醒，至少不会人云亦云。
数据技术在过去的几十年间始终是发展最为活跃的领域，也是新概念层出不穷的让人迷失之地。从二十多年前的“数据仓库”，十多年前的“大数据”以及最近流行起来的“数据湖”等概念，前浪们炒的火热，逐浪的人们不断颠覆、否定，不断地进行架构“演进”。熙熙攘攘的热闹过后，让我深感有必要将其技术源流做一梳理，借以从概念看到本质，让喧嚣回复平静，让技术归其本源。
数据的价值与数字化转型
刚刚结束的两会审议通过了「十四五」规划纲要草案。对于制造业、科技行业而言，最关注的依旧是前沿科技、数字经济以及数字化转型部分。通过数字化转型提速、赋能传统行业已经成为共识。以我的理解来看，数字化转型的本质就是应用大规模数据处理技术来提升企业的运营效率。这就涉及到了这个概念之下的一个关键技术 – 数据处理。
随着社会的不断进步，就需从海量的数据中提取有价值、有意义的信息，以改进企业决策的合理性，进而提升效率。围绕这个目标就涉及到解决各种挑战，例如合规性、数据安全、快速决策、遗留系统整合、多样化的数据源等。为此，研究人员抽象出了一个围绕数据处理的概念模型。
在这个抽象模型中，最重要的设计思想就是实现由“数据”到“洞察力”的提升。这个变化是由业务发展以及数据处理技术交互作用的必然结果，数据挖掘、数据分析、机器学习等专有名词已经由概念转化成了具体的需求。事实上，数据技术、数据仓库、商业智能（BI）以及大数据等已经经历了相当长的发展，并且已经有了非常成熟稳定的技术方案和生态系统。
啤酒和尿布的传说
关于数据分析，有一个流传甚广的“啤酒和尿布”的故事。说的是沃尔玛公司通过数据分析发现了在某一时间段啤酒和尿片的销量大增，原因就是爸爸给孩子购买尿片的同时还会给自己买上几罐啤酒。于是沃尔玛将啤酒和尿片摆放在一起，在商品的销量上获得了巨大成功。
故事的真相与沃尔玛无关，却是与1992年6月进行的一项研究有关。当时的NCR（现为Teradata）的工业咨询副总裁Thomas Blischok针对Osco Drug（北美的一家连锁超市）进行了分析。他们检查了25家商店中的120万个购物记录，确定了20多种不同的产品组合，其中包括啤酒和尿布，果汁和止咳糖浆等。
虽然关于Osco如何将啤酒转移到尿布旁边，并且两者都取得了更大的销量的传说是不真实的。但Osco接受了NCR研究的结果，并在其库存中确定了大约5,000个销售缓慢的商品。从货架上移走这些商品后，消费者现在发现他们可以更轻松地找到需要的物品，而且有了Osco的商品选择增加了的感觉。
Osco和NCR的研究建立了一个基本的认识，即购买习惯可以用来提高整个购买体验。二十年后，数据挖掘已经升级为商业智能（BI）和预测分析。企业现在可以思考人们如何购买和购买什么，并更有效地布局门店。他们可以为一起购买的物品提供更好的优惠，当需求增加时增加商品的库存。
Blischok对此说过:“Osco以及整个零售行业开始明白，通过对数据的检查，可以在正确的时间将正确数量的正确商品放到货架上。”
传统的数据仓库 – Inmon vs Kimbal
20年前兴起的数据仓库简单的可分为两大流派，Inmon方法和Kimball方法，分别由 Ralph Kimbal和Bill Inmon所提出。在十多年前，这两个流派的数据仓库曾经是最为热门的技术话题。这两种方法都将数据仓库看作是企业的中心数据存储。主要应用场景就是各类业务报表的需求。两者都建议使用ETL来加载数据到数据仓库。区别的关键在于如何在数据仓库中建模、加载和存储数据的方式。而由此出发的不同架构影响到了数据仓库的建设成本和到适应用户不断变化的ETL逻辑的能力。
Inmon 方法
 |
 |
Inmon建立数据仓库的方法是自顶向下的，即从企业的数据模型开始。这个模型确定了关键的主题域，最重要的是确定了企业经营和关心的关键实体，例如客户、产品、供应商等。在这个数据模型中，为每个主要实体创建一个详细的逻辑模型。这里的关键点是，实体结构是以规范化的形式建立的。尽量避免数据冗余。这样的做法可以清晰的识别业务概念，避免数据更新而产生的异常。
下一步是构建物理模型。数据仓库的物理实现同样也是要求标准化的。在这个设计原则下，规范化是非常重要的一点。第三范式（3NF，就是指表中的所有数据元素不但要能唯一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系）则是非常重要的设计原则。这种规范化的模型使得数据的加载较为容易实现，但是使用这种结构进行高效的查询却是很具挑战，因为它遇到到多表和多连接导致的查询效率的问题。所以，Inmon建议建立专门针对业务部门建立有针对性的“数据集市”（DataMart），而数据仓库则作为数据集市的唯一的数据来源。这确保了数据的完整性和一致性。下图显示了Inmon数据仓库的典型架构 –
Inmon方法的主要优势表现为：
- 数据仓库真正成为企业的单一数据源，而且数据仓库中的所有数据都是一体化的。
- 由于冗余度极低，避免了数据更新异常。ETL过程更加简单，不易出现故障。
- 业务流程可以很容易理解，因为逻辑模型代表了详细的业务实体。
- 非常灵活–随着业务需求的变化或源数据的变化，数据仓库较为容易更新，因为一个“事实”只保存在一处。
- 可以处理整个企业的各种报表需求。
与此同时，Inmon方法也被发现存在一些不足：
- 随着时间的推移，模型和实现会变得复杂，因为它涉及更多的表和连接。
- 需要有数据建模和业务本身的专家资源。这些类型的资源通常昂贵且难于找到。
- 数据仓库的设计和交付会花费更多的时间，这一点非常重要。
- 随着数据仓库的建立和完善，需要更多的ETL工作。
- 需要有一个相当大的专家团队来管理和维护。
Kimball 方法
 |
 |
Kimball方法在流程上与Inmon方法相反，是自底向上的。我们可以将其视为一种敏捷的建模与开发方法。在数据仓库建设中Kimball强调首先要确定数据仓库需要解决的关键业务流程和关键业务问题,即聚焦关键的业务数据，围绕它提供分析能力，从而解决关键业务问题或改善业务流程。也就意味着数据的消费者在满足企业报表需求的同时需要更多向上/向下钻取数据的能力。Kimball提出，在ETL处理后的数据加载到暂存区之后，数据被加载到一个维度模型里。与Inmon不同的是，这里的维度模型是去规范化的，便于分析时的上下钻取。这个维度模型的基本概念是“星型模式”
在星型模式中，通常有一个“事实表”，围绕有多个“维度表”。事实表存有所有与主题域相关的度量，它也有来自围绕事实的不同维度的外键。这些维度是完全去规范化的，这样在用户多维度探索数据时不需要每次都建立新的模型来满足，而是可以通过向上/向下钻取来实现。针对不同的报表需求，只需建立多个星型模式来满足需求。那么，在维度模型中如何实现集成呢？在这里，Kimball提出了 “符合维度 “的概念。这确保了一件事或一个概念在不同的事实中使用的方式是一样的。下图显示了Kimball数据仓库的典型架构 –
对于Kimball方法，我们认为其优势为 –
- 快速启动和敏捷构建，数据仓库项目的第一阶段成果将快速交付。
- 星型模式容易被业务部门理解，便于报表的使用。大多数的BI/报表工具都能很好的配合星型模式。
- 数据仓库环境的开销不大，数据库中占用的空间相比较小，使系统管理较为容易。
- 星型模式的性能非常好。数据库引擎将执行一个 “星型连接”，使用所有的维度值产生一个笛卡尔乘积，最后通过查询事实表来选择性所需的数据行。众所周知，这是一种非常有效的数据库操作。
- 一个由开发人员和架构师组成的小团队就足以保证数据仓库的有效建设。
- 对于业务部门的指标和KPI跟踪的效果非常好，因为数据仓库是面向业务部门或业务流程方面的查询报告。
- 横向钻取(Drill-across)即一个BI工具跨越多个星型结构来生成一个报表，使用符合需要的维度数据即可完成。
对于Kimball方法，我们也看到了的一些不足-
- 失去了 “真相来源只有一个 “的本质。重心在服务于报表需求，但数据没有完全整合。具体来说，星型模式的数据冗余容易造成同一个分析需求在不同分析路径产生的结果可能有偏差。这个方法的重心是服务于报表需求，但任一个星型模式的数据没有被完全整合
- 冗余的数据会导致数据更新的复杂且数据可能异常。
- 在事实表中增加新的列，会造成性能问题。这是因为事实表被设计得很宽。如果要增加新的列，事实表的大小就会变得更大，而且性能也不会很好。这使得维度模型很难随着业务需求的变化而改变。
- 一个星型模式的数据集不能满足所有业务报告需求，而多星型模式的数据集中冗余数据越来越多，此时数据更新窗口不同都会造成不同数据集的数据偏差。
- 将遗留数据集成到数据仓库可能是一个复杂的过程。
归纳起来，Inmon 方法的强调的是“数据集市”， Kimball 提倡的“集中式的数据仓库”。数据集市是将数据分为各类主题，对应到各个业务部门，以提供信息查询、报表生成。集中式数据仓库则是将所有主题融合到一起，做出更多联合性的分析。而在分析之前，通过操作型数据存储（ODS，Operational Data Store）并采用雪花模型将各个业务系统数据加载到缓冲层，业务系统可以在这里采集到聚合后的信息。
事实证明，Inmon和Kimball两种方法对数据仓库的建设来说都是行之有效的。甚至有的项目已经实施了两者的结合，即“混合模式的数据仓库”。在混合模式中，使用Inmon模型建立数据仓库，在集成的数据仓库的基础上，再去使用星型模式建立面向业务流程的数据仓库/集市进行报表及查询分析。我们不能一概而论的说一种方法比另一种方法好，如上所述它们都有各自的优缺点。在一个数据仓库实施的时候，需要根据不同的因素为数据仓库选择适合的方法。需要针对业务、技术经过仔细的思考，并设计成满足企业的报表、商业智能分析的需求，还应该与企业的文化相融合。
数据仓库中的常见概念 – OLAP、MDA、cube
联机分析处理 – OLAP
我们经常提到的OLAP 是 On-Line Analytical Processing（联机分析处理）的缩写。广义的 OLAP 泛指数据查询分析，像报表、即席查询、多维分析都属于 OLAP 的范畴。OLTP 和 OLAP 最大区别在于前者会产生数据，而后者只利用前者生产的数据进行数据分析为企业经营提供决策支持。
OLAP是更广泛的商业智能类别的一部分，它还包括关系数据库、报告编写和数据挖掘。OLAP的典型应用包括用于销售的业务报告、市场营销、管理报告、业务流程管理(BPM)、预算和预测、财务报告等领域。
OLAP的工具使用户能够从多个角度交互地分析多维数据。OLAP由三种基本的分析操作组成:整合(roll-up)、钻取（drill-down）和切片（slicing 和dicing）。整合涉及到可以在一个或多个维度中累积和计算的数据的聚合。相比之下，钻取是一种允许用户浏览细节的技术。切片是一种分析功能，用户可以从中提取OLAP多维数据集的特定数据集，并从不同的视角查看切片。
多维分析 – MDA
多维分析(Multidimensional Analysis)是是一种数据分析过程，将数据分为两类：数据维和度量。在分析型系统中，用户可以通过拖拽维度（Dimension）来汇总度量（Measure）以方便使用者可以从不同角度观察数据。如果从报表的角度来看，多维分析类似于自助报表，业务人员基于一个事先准备的结果集进行动态报表查询，可以进行切片、钻取、旋转（行列变换）等操作。狭义上，BI、OLAP 和多维分析经常被视为同一类，其实是特指实现了多维分析的工具和产品。
数据立方体 – cube
在数据仓库兴起之时，Jim Gray等人将数据立方（DataCube）的概念应用于描述时变（time-varying）的业务数据。这种方法在业务表现以及实现的性能的强大优势，迅速成为了数据仓库技术中最重要的一环。
cube 也叫数据立方体，名字源自数据可以有任意数量的维度。但cube并不是严格数学意义上的 “立方体”，可以有超过三个以上的维度。我们可以将这个概念理解成是一个数据集，在多维分析中使用者需要基于一个结果集进行拖拽分析，这个结果集就是 cube 了，多维分析针对 cube 进行查询、切片、钻取等操作。
在数据仓库系统中，cube通常指的是一个多维的数据阵列，也可以理解为一个更高层次的业务模型抽象。传统的数据分析大多是基于关系型数据库的。关系型数据库使用SQL语句进行操作，但SQL在多维度操作和分析方面的能力相对较弱。所以cube有自己独特的查询语言MDX，它的表达式比较丰富，并具有强大的多维处理能力，所以以cube为核心的分析系统成为了数据分析主要的选项。通过采用cube，OLAP分析系统可以轻松地得以构建。
ETL – 抽取、转换、加载
在数据处理的过程中，我经常需要进行计算、提取、转换、加载这一类将数据从一个或多个源复制到目标系统的过程。这个操作被统称为ETL（Extract、transform、load）ETL在20世纪70年代成为一个流行的概念，广泛应用于数据仓库系统。
数据提取包括从同构或异构源提取数据；数据转换通过数据清洗处理数据，并将数据转换为适当的存储格式/结构，以便查询和分析；最后，数据加载描述了将数据插入到最终的目标数据库，如操作数据存储、数据集市、数据湖或数据仓库
一个设计良好的ETL系统从源系统中提取数据，强制执行数据质量和一致性标准，使得数据保持一致，以便可以将单独的数据源一起使用，并最终以准备好的格式交付数据，以便应用开发人员可以构建应用程序和帮助数据的使用者进行分析。
ETL的流程可以用任何工具/程序语言进行定制开发。由于ETL是极为复杂的过程，而定制开发的ETL往往不易管理，有愈来愈多的企业采用特定的工具协助ETL的开发，并运用其内置的元数据（metadata）管理的功能来存储来源与目的的对应以及转换规则。
传统的大数据架构
但是，随着数据量的指数级别的增长，传统的数据仓库以及Cube技术的不足逐渐显现出来。这些不足之处主要有-
- 传统的数据分析更注重对高密度、高价值的结构化数据的业务数据分析，对非结构化、半结构化数据的处理，如图像、文本、音频的存储和分析非常薄弱。
- 由于传统数据仓库采用结构化存储，当数据从其他系统导入数据仓库时，我们通常会引入ETL过程。ETL与具体的业务有很强的绑定性，通常需要一个专门的人或者团队与业务部门进行连接，并决定如何进行数据清洗、转换以及加载。
- 随着异构数据源的增加，例如，如果有视频、文本、图片，要分析数据内容并进入数据仓库，就需要非常复杂的ETL，这导致了ETL过于庞大且臃肿。
- 数据库范式等约束规则重点解决数据冗余问题，以确保数据的一致性。原则上，数据仓库原始数据是只读的，所以这些约束条件将成为影响性能的因素。
- ETL操作对数据的预置和处理，例如轻度的聚合等，会导致机器学习得到的数据并非完整的真实数据，有时候的训练效果并不理想。
- 更麻烦的是，当数据量过大时性能就会成为瓶颈。很多系统在迈入TB、PB级别的规模时就会表现出明显的力不从心。
在上述一系列问题的困扰下，2004年出现的Map/Reduce技术为我们展示出了处理大数据的一种新的选择。具体说来，Map/Reduce是一种计算框架，通过在集群基础设施上应用并行和分布式算法处理大数据集。其中，Map负责数据的过滤和分类；Reduce负责数据的操作。
在此后，基于Map/Reduce的Apache Hadoop系统的生态系统不断壮大，让我们看到了解决了传统数据仓库的瓶颈的可能。从技术的角度来看，这种大数据架构主要从以下几个维度解决传统数据仓库在数据分析中面临的瓶颈问题 –
- 分布式计算。分布式计算的思想是让多个节点并行计算，强调数据的局部性，并尽量减少节点间的数据传输。例如Spark用RDD(弹性分布式数据集, Resilient Distributed Dataset)来表达数据的计算逻辑，可以在RDD上进行列优化以减少数据传输。
- 分布式存储。所谓分布式存储，是指将一个大文件分成若干份，每份独立地放在一台节点上。这里涉及到文件拷贝、碎片化、管理等操作。分布式存储的主要优化都集中在在这几个方面。
- 检索与存储的结合。在早期的大数据系统中，存储和计算是比较单一的，但目前的方向是在存储上赋予更强大的能力，目的是要快速地找到数据并读取数据。所以目前的存储不仅是存储数据内容自身，还增加了很多元数据。
- 计算与存储的分离。从历史上看，数据库系统主要采用 “计算和存储紧耦合”的架构。之所以采用这种设计主要是出于性能的考虑。现代数据分析应用需求在过去十年中发生了显著的变化，要处理更大量级的数据，并且用于分析这些数据的方法也是多种多样的，并且预计会相互影响以获得最终结果。例如，一个简单而常见的分析应用是通过消息流传输日志数据，然后通过管道传送到计算引擎进行进一步分析。在这种情况下，单个计算引擎无法完全控制数据布局和文件系统。因此，这些现代分析应用就要求计算与存储解耦。
但是，也要看到这种大数据架构相对于传统的数据仓库来说优点巨大，但仍存有不足 –
- 从传统数据仓库升级到大数据架构，并不是无缝迁移的，基本等于推翻重做。
- 大数据下的分布式存储强调数据的只读性，例如HDFS的存储方式不支持更新、HDFS的写操作不支持并行等。这些特点导致了在应用上一定的局限性。
- 存储的耦合，副本等机制造成了扩展和容灾发生时的成本压力和运维压力。
以Apache Hadoop 为代表的大数据架构之所以被称为传统的大数据架构，是因为它的定位是解决传统数据仓库的问题。简单来说，就是数据分析没有发生任何变化，但是由于数据量和性能的问题，传统的数据仓库无能为力，需要升级替代。例如，在这个架构中仍然保留了ETL操作，数据通过ETL加载进入数据存储。
传统大数据架构的优势。从已有的实践来看，这个架构简单易行，针对数据处理的方法论没基本有改变，唯一改变的是基础技术平台的选择，用大数据架构代替传统的数据仓库。
传统大数据架构的不足。对于大数据架构，尚缺乏完整的Cube工具。虽然目前有部分开源或者商业化的产品，但仍存在局限性。例如：缺乏Cube的灵活性和稳定性，所以对于业务支持的灵活度略显不足。对于报表数量多或者复杂的场景，就需要过多的人工定制。同时，这个架构上还是以批处理为主，缺乏数据实时性的支持。
传统大数据架构的适用场景。架构针对的是传统数据仓库由于数据量和性能等问题无法满足需要的场景，这些场景主要就是数据分析的需求以及商业智能（BI）等。
新一代大数据架构
着眼于解决传统大数据架构的不足，从2011年开始，一些列新的大数据架构不断涌现出来。其中数据流架构、Kappa架构与Lambda 架构为其中最为流行的架构。
数据流架构
相对于传统的大数据架构，数据流架构是一种更为激进架构的设计。在这个架构中直接去掉了批处理的部分，整个处理的过程都是以流的形式处理数据。其建立的目的是摄取和处理来自多个来源的大量流式数据。传统的数据解决方案侧重于批量写入和读取数据，而流式数据架构则在数据生成时立即消耗数据，将其持久化到存储中，并可能包括各种额外的组件，例如用于实时处理、数据操作和分析的工具。
数据流架构需要考虑到数据流的独特特性，首先数据流针对的是海量数据（TB或 PB级别）；其次，数据往往是半结构化的，需要大量的预处理数据才能变得有用。最后，数据的时效性，即同一窗口下的数据进行分析的价值。
架构优势：没有臃肿的ETL流程，数据处理的时效性非常高。
架构缺点： 对于数据流架构，缺少批处理，所以不能很好的支持数据回放和历史数据统计。对于离线分析，只支持有限的“数据窗口”内的数据的分析。
Lambda 架构
Lambda架构是新一代大数据系统中举足轻重的架构。新一代的架构大多都是Lambda架构或基于其变种的架构。Lambda架构描述了一个由三层组成的系统：批处理、速度（或实时）处理和用于响应查询的服务层。这种范式最早是由Nathan Marz在一篇题为 “How to beat the CAP theorem” 文章中描述的，他最初将其称为 “批处理/实时架构” 。在2016年出版的《大数据系统构建：可扩展实时数据系统构建原理与最佳实践》一书，对这个架构有深入的阐释。
 |
 |
在Lambda架构中，实时流基本上是依靠很多的流式架构来保证其实时性，而离线数据主要是通过批处理来保证最后的一致性。为了保证数据流通道处理的有效性，增量计算是主要的数据操作方式，而批处理层则对数据进行充分的计算，以保证其最终的一致性。合并的动作是Lambda中非常重要的操作，合并的总体思路如下。
Lambda 架构依赖于一个特定的数据模型。该模型具有一个只可附加的、不可改变的数据源作为数据的记录系统。这个数据模型被用于摄取和处理有时间戳的事件，这些事件被附加到现有的事件上，而不是覆盖它们。状态是由数据的自然时间排序决定的。
总体看来，Lambda架构的设计目标是通过利用批处理和流处理方法来处理海量数据。这种架构方法试图平衡延迟、吞吐量和容错性，利用批处理提供批数据的全面和准确视图，同时利用实时流处理提供在线数据的视图。Lambda架构的兴起与大数据、实时分析的发展以及缓解Map/Rreduce延迟的驱动力有关。
架构的优点：同时支持实时和离线处理，很好的覆盖了多种数据分析场景。
架构的缺点： 对于Lambda架构的批评集中在其固有的复杂性及其限制性影响上。批量和流数据处理各自需要不同的代码库，必须维护并保持同步，以便处理后的数据从两个路径产生相同的结果。然而试图将这些代码库抽象成一个单一的框架，目前看来还没有完美的方案。
适用场景：实时和离线处理两种场景。
Unifield架构
Unifield架构可是看作是Lambda架构的变体。不同于专注于海量数据处理为主的架构，Unifield架构则更为激进，将机器学习和数据处理相结合。在核心上，Unifield仍然基于Lambda，但它已经转变为流处理。在层中加入了新的机器学习层。数据通过数据通道进入数据湖。架构中新增加了一个模型训练部分，并在流式层中使用。这个流处理层使用这个模型并不断训练模型。
架构优势：Unifield架构提供了一套数据分析和机器学习相结合的架构方案，很好的解决了如何将机器学习与数据平台相结合的问题。
架构缺点：架构显著缺点是架构的实现比较复杂。对于机器学习架构来说，从软件包到硬件部署，都与通常的数据分析平台有非常大的区别，所以在实施过程中难度系数较高。
适用场景：有大量的数据需要分析，特别对机器学习的便利性有非常大的需求的场景。
Kappa 架构
Kappa架构的出现要归功于Confluent公司的首席执行官和Apache Kafka的共同创建者Jay Kreps。他提出使用不可改变的数据流作为主要的记录源，而不是使用数据库或文件的时间点来表示。换句话说，如果一个包含所有企业数据的数据流可以无限期地持久化，那么对代码的更改可以根据需要重放过去的事件。这样就可以实现lambda架构不支持的单元测试和流计算的修改。Kappa架构还消除了对基于批处理的入口过程的需求，因为所有数据都作为事件写入到持久化的流中。Kappa架构是一种新颖的分布式系统架构方法，背后的设计理念非常值得学习。
与Lambda 架构相比，Kappa 架构是在Lambda的基础上进行了优化，结合了实时处理和流处理的部分，用消息队列替换了数据通道。Kappa架构使用流处理作为支柱，但数据存储在数据湖中。当需要进行大量的离线分析和各种其他多种计算时，数据湖的数据可以再次通过消息队列进行上载。
架构优点 ：Kappa体系结构解决了Lambda架构中较为冗余的部分。它的设计具有支持数据重放的理念。并且，整个架构非常简洁。
架构缺点：虽然Kappa体系结构看起来很简洁，但实现起来相对比较困难，尤其是数据重放部分。
适用场景：支持与Lambda架构相同的场景。
新一代的企业级数据存储 ： 数据湖（DataLake）
在上述架构的介绍当中出现了“数据湖”的字样。如果没有厘清这个概念，恐怕还是要就要陷入概念的陷阱之中。所谓的“数据湖”是一个以自然/原始格式存储的数据系统或仓库，通常是采用的存储对象是blobs或文件。一个数据湖通常是一个单一的数据存储，包括多种数据来源，例如生产数据、日志、传感器数据、社交媒体数据等。数据湖在企业中被用来支持各类报表、数据可视化、高级分析和机器学习等任务。从数据格式来看，数据湖可以包括来自关系数据库的结构化数据、半结构化数据（CSV、日志、XML、JSON）、非结构化数据（电子邮件、文档、PDF）和二进制数据（图像、音频、视频）。数据湖可以建立在企业的数据中心，越来越多的企业开始将数据湖构建于云端。
2011年，时任Pentaho公司首席技术官的James Dixon创造了“数据湖”这个概念，并将其与数据集市（Data Mart）进行对比。与之相比，数据集市则是一个较小的、由原始数据衍生出的有特定属性的数据存储库。 在推广数据湖时，James Dixon认为数据集市存在固有的不足，比如信息孤岛。而数据湖可以 解决”数据孤岛”这个企业信息化中的顽症。
在建设数据湖的过程中，一定要避免产生大数据坟场。也就是将所有的东西都倾倒到诸如分布式文件系统(HDFS)中，但随后就失去了对数据的有效管理。对于这个结果也有了一个专门的定义，“数据沼泽”( Data Swamp)。这个概念特指变质且无人管理的数据湖，它要么无法被其目标用户访问，要么提供的价值很小。解决这个问题的关键就是企业需要弄清楚哪些数据和元数据是业务真正需要的。
对数据湖还存在一些批评的意见。他们认为数据湖这个概念是模糊和随意的，涵盖了任何不符合传统数据仓库架构的工具或数据管理实践。数据湖的概念已经被赋予了过多的含义，这使得这个术语的实用性受到了质疑。同样的批评也存在于许多年前对于“数据仓库”的看法，认为概念存在着定义不透明和不断变化的问题。但随着工具的丰富以及实践的积累，解决现有的质疑仅仅是时间的问题。我比较认同麦肯锡的一个研究结论，数据湖应该被视为在企业内部提供商业价值的服务模式，而不仅仅是一个技术成果。
数据湖 vs 大数据平台
大数据和数据湖是两个相互关联的名词，但是却有着完全不同的含义，这也是人们经常将这两个名词混淆的主要原因。所以我们来简单了解一下两者之间的区别。
“大数据”正如名字本身所表现那样，简单来说就是规模庞大的数据。以PB为单位的数据，甚至更多的数据被认为是大数据。不仅仅是数据的规模，还有一些参数可以定义大数据，例如产生这些数据的来源、不同格式的数据以及数据产生的速度，所有这些因素综合起来就定义了大数据。大数据用最简单的话来说就是海量的数据。
“数据湖”则是大数据的存储库。它存储了所有类型的数据，即结构化、非结构化和半结构化的数据，这些数据是由不同的数据来源所产生的。它以最原始的形式存储数据。数据湖与数据仓库不同。数据仓库以结构化的形式存储数据。数据湖中的数据在未来可能会被利用，也可能不会被利用，但数据仓库中的数据是为了利用，因为所有不相关的数据都已经被清理掉了。
简单归纳一下，大数据是海量的数据，数据湖是大数据的仓库。
数据湖vs 数据仓库
另一对需要区别的概念就是数据湖与数据仓库。归纳起来两者的差异如下：
- 数据湖保留所有数据
在开发数据仓库的过程中，需要花费大量的时间来分析数据源、了解业务流程和分析数据。其结果是为报告而设计的高度结构化的数据模型。这个过程的很大一部分包括决定在仓库中包含哪些数据和不包含哪些数据。一般来说，如果数据不用于回答特定的问题或在定义的报告中，它可能会被从仓库中排除。这样做通常是为了简化数据模型，同时也是为了节省昂贵的磁盘存储空间，而这些空间是用来让数据仓库发挥性能的。
相比之下，数据湖保留了所有数据。不仅仅是今天正在使用的数据，还有今后可能使用到的数据，甚至可能永远不会使用的数据，只是因为有一天可能会使用。数据湖中的数据将会一直保留，所以我们可以回到任何一个时间点去做分析。
- 数据湖支持所有数据类型
数据仓库一般由从事务系统中提取的数据组成，由定量指标和描述这些指标的属性组成。非传统的数据源，如网络服务器日志、传感器数据、社交网络、文本和图像在很大程度上被选择性忽略。但今天这些数据类型的新用途不断被发现，但处理和存储它们可能是昂贵和困难的。
数据湖方法包含了这些非传统的数据类型。在数据湖中，我们保留所有的数据，无论其来源和结构如何。我们保留它的原始形式，只有当我们准备好使用它时，我们才会对它进行转换。这种方法被称为 “Schema on Read “，与之相对的则是数据仓库中使用的 “Schema on Write “方法。
- 数据湖支持所有用户
在大多数企业中，80%以上的数据的使用者都是 “操作型 “的。他们希望获得所需报表，查看关键业务指标，或者在Excel中对一组数据进行加工。数据仓库通常是这类用户的理想选择，因为它结构合理，易于使用和理解，而且它是为回答这一类问题而专门设计的。至于其余的10%左右的人，会对数据做更多的分析。他们把数据仓库作为一个源头，但经常需要回到数据源头的系统中去获取仓库中没有包含的数据，有时还会从企业/部门外部引入数据。这一类用户的工具是Excel以及BI分析工具，他们会创建新的报告，服务于特定的业务决策者。数据仓库是这些用户常用的数据来源，但他们经常超越数据仓库的范围。最后，最后百分之几的数据用户需要做深度的分析。他们可能会根据研究创建全新的数据源。他们将许多不同类型的数据混在一起，并提出全新的问题来回答。这些用户可能会使用数据仓库，但通常会忽略它，因为他们的所需已经超出了数据仓库的能力。这类用户包括日益增多的数据科学家、人工智能科学家。这一类用户会使用高级分析工具和能力，如统计分析、预测建模以及机器学习的模型和算法。数据湖的方法同样可以支持所有这些用户。数据科学家、人工智能科学家可以到数据湖中找到并处理他们所需要的非常庞大和多样的数据集，而其他用户则利用提供给他们使用的更加结构化的数据视图。
- 数据湖很容易适应变化
关于数据仓库的主要抱怨之一是一旦需要改变数据仓库就要花费许多的时间。在开发过程中，前期需要花费大量的时间来设计好搞好仓库的模型。一个好的仓库设计可以适应变化，但由于数据加载过程的复杂性，以及为了方便分析和报告所做的工作，这些变化必然会消耗大量开发资源，并花费许多时间。
而许多业务问题不能等待数据仓库团队调整系统后解决问题。对需要更快响应的需求不断增加，就出现了自助式商业智能的概念。另一方面，在数据湖中由于所有的数据都以原始形式存储，并且随时可以被需要使用数据的人所访问，因此用户被授权超越仓库的结构，以全新的方式探索数据，并按照自己的节奏响应、解决新的问题。如果对于数据的探索的结果被证明是有效的，并且有重复探索的需求，那么就可以采用一个正式的模式，并开发自动化和可重用的方案，以帮助将结果扩展到更广泛的受众。如果确定结果无用，则可将其丢弃，不需要改变数据结构，不消耗开发的资源。
- 数据湖提供更快的洞察力
最后的这个区别其实是其他四个方面的必然结果。因为数据湖包含了所有的数据和数据类型，因为它能让用户在数据被转化、清洗和结构化之前就能够访问数据，所以它能让用户比传统的数据仓库方式更快地获得结果。然而，这种对数据的早期访问是有代价的。通常由数据仓库开发团队所做的工作可能无法完成做分析所需的部分或全部数据源。这使得用户可以根据自己的需要探索和使用数据，但上文描述的第一层业务用户可能不想做这些工作。他们仍然只是想要他们的报告和KPI汇总。
而在数据湖中，这些业务报表的使用者会利用数据湖中的结构化的数据视图，这些视图类似于他们之前在数据仓库中一直拥有的视图。不同的是，这些视图主要以元数据的形式存在，这些元数据位于湖中的数据之上，需要开发人员进行定制开发。
下一代的数据存储+分析架构：LakeHouse
数据仓库在决策支持和商业智能应用中有着悠久的历史。自20世纪80年代末出现以来，数据仓库技术不断发展，MPP架构导致系统能够处理更大规模的数据。但是虽然仓库对于结构化数据有很好的支持，但很多现代企业需要处理非结构化数据、半结构化数据以及种类多、速度快、数量大的大数据。显然数据仓库并不适合这样的场景。
随着企业开始从许多不同的来源收集大量数据，开始设想用一个单一的系统来存放许多不同分析产品和工作负载的数据。随之而来“数据湖”的概念应运而生，也就是各种格式的原始数据的统一的存储库。这个方案虽然适合存储数据，但数据湖缺乏一些企业所需的关键功能，例如不支持事务，不强制执行数据质量的控制，并且缺乏一致性/隔离的机制，使得几乎不可能数据的混合追加和读取，以及批处理和流作业等等。由于这些原因，数据湖的许多承诺并没有被真实实现，在许多情况下导致传统数据仓库的许多优势在这个概念之下无法得以实现。
真实世界中，企业需要使用多种数据应用的系统，包括基于SQL的分析、实时监控、数据科学和机器学习应用等。近年来在人工智能方面的大部分进展都是在处理非结构化数据（文本、图像、视频、音频）所取得的，但这些正是传统数据仓库没有展现优势的数据类型。目前常见的解决思路是使用建设系统，一个企业数据湖、多个数据仓库以及其他专用的处理系统，如流式数据、时间序列、图和图数据库等。可以想见，拥有多个系统会带来更大的复杂性。更重要的是会带来业务处理的延迟，因为数据分析/处理人员不得不在多种不同的系统之间移动或复制数据。
解决数据湖局限性的新的概念已经出现，这就是LakeHouse架构。2020年1月Databrick公发表的一篇博客文章介绍了这个全新的架构，这也是Databrick 继2019年推出Delta Lake之后在数据处理架构与方案的新的发展。LakeHouse架构是一种全新的开放架构，结合了数据湖和数据仓库的最佳要素，构建在低成本云计算对象存储上的数据湖的灵活性与通常与数据仓库相关联的ACID(原子性、一致性、隔离性、持久性)事务、模式实施和性能结合起来。LakeHouse为数据湖实现了数据仓库的数据结构和管理功能，数据湖的数据存储通常更具成本效益。LakeHouse对数据科学家很有用，因为它们可以实现机器学习和商业智能的分析。
关于 Delta Lake
上文提到的Delta Lake是一个开放格式存储层，通过以Apache Spark 作为基础环境，在分布式存储上支持ACID的方法，实现了为数据湖提供可靠性、安全性和更好的性能，并且支持流式处理以及批处理操作。通过将“数据筒仓”（data silos
）替换为结构化、半结构化和非结构化数据的单一存储，并作为LakeHouse的基础。
Databrick 发表的“Delta Lake: High-Performance ACID Storage over Cloud Object Stores”一文对此有深入介绍。
Dalta Lake vs Apache Hudi vs Apache Iceberg
提到了Delta Lake就难免涉及到与Apache Hudi和Apache Iceberg的对比。关于Hudi与Iceberg 之间的异同可以在社区可以搜寻到大量资料。从事物的机制上我们可以看到Hudi基于时间线，Iceberg基于快照，而Delta Lake基于日志。从解决问题的角度我们又可以看到，Hudi意在利用增量自动化的方式解决流式数据的更新与读取的平衡。Iceberg利用去索引去键的方式提升查询高效性，为全方位扩展时刻准备着。Delta Lake则在利用好Spark社区资源的同时跳出框架兼容并蓄。
LakeHouse架构的特点
作为数据仓库和数据湖的结合体，LakeHouse架构具有两种数据平台的一些重要的特性，即：
- 数据的并发读写
- 具有数据治理机制的模式支持
- 可直接获取源数据
- 存储和计算资源的分离
- 标准化存储格式
- 支持结构化和半结构化数据类型
- 端到端流数据
LakeHouse架构的优势
从非结构化数据（文本、图像、视频、音频）中进行分析处理以获取智能的能力使得处理这些类型的数据对企业来说至关重要。但传统上，数据仓库并没有针对这些非结构化数据类型进行优化，因此需要同时管理多个系统，维护各种系统的成本很高，甚至会影响企业获取数据洞察力的时效性。与多个解决方案相比，LakeHouse架构有以下几个优势，包括：
- 更少的管理时间和精力
- 简化模式和数据治理
- 减少数据移动和冗余
- 为分析工具直接获取数据
- 具有成本效益的数据存储
LakeHouse vs数据仓库 vs 数据湖
许多企业将他们的数据仓库独立于他们的数据湖来运作，利用数据仓库来获取有价值的业务洞察力，并利用数据湖进行存储和进行数据科学处理。一些企业将他们的数据湖与数据仓库结合在一个单一的数据平台中 – 可以是与数据湖并行工作的数据仓库，也可以是嵌入数据湖中的数据仓库。用来为商业智能和数据科学提供数据服务。还有些企业甚至将数据仓库也添加到他们的数据存储之中。 至于LakeHouse，则被视为数据仓库和数据湖的单一平台。我不喜欢将LakeHouse简单的译作“湖仓一体”，因为这个说法掩盖了这个架构需要强调的超越传统的数据仓库的分析与处理的能力。
可以说LakeHouse的概念还处于早期阶段，在完全依赖LakeHouse架构之前我们还需要考虑一些局限，例如：查询的兼容性、数据清理复杂性等。当然，Lakehouse不仅仅是为大数据分析提供可靠、权威的数据存储，以及统一实时流数据和批量数据的数据工程基础设施。Lakehouse还涉及如何利用存储在数据湖中的结构化和非结构化数据。易于应用机器学习算法、执行数据科学和在Lakehouse上使用人工智能(AI)的能力是该架构的一个重要特征。
结语
从数据的价值出发，我们看到不同时期人们对数据分析处理能力的渴望。早期企业中的报表需求简单且固定，但并不能很好的做到潜在关联价值的洞察。于是探求更灵活的数据模型成为了主线。随着互联网的爆发，这些模型都受到了海量数据的挑战，模型的灵活性在数据量的瓶颈下被重新定义。流式数据意在解决批量处理的追溯能力和时效性，新的数据范式意在解决海量数据下的取用效率，数据湖意在包容新时代下人们对新媒体形式的探寻。他们的出现丰富了数据处理的可能性，同时也增加了处理的复杂度。
一切伟大的变化或许才刚刚开始，期待新的技术的不断迭代为数据实践者提供更强大的工具。随着越来越多的企业、开发者采用新的数据处理的架构模式，就让我们一起开启解决世界上最棘手的问题的旅程吧。