2 DataLake — 批流一体化的追风者 _达美航空

一、Delta Lake
1.Delta Lake基础概述
接上文，我们全面地讲解了Data Lake相关的概念、对比区别以及实际发展历程等。那么这篇首章开篇我们来讲历史最为悠久的Delta Lake 。它的定位是流批一体的存储中间层，支持 //merge 。由于出自， spark的所有数据写入方式，包括基于的批、流，以及 SQL的、等都是支持的（开源版本SQL写暂不支持）。与类似， Delta不强调主键，因此其//merge的实现均是基于spark的join功能。在数据写入方面， Delta与Spark是强绑定的，这一点Hudi是不同的：Hudi的数据写入不绑定Spark（可以用 Spark ，也可以使用Hudi自己的写入工具写入）。
在查询方面，开源Delta目前支持Spark与，但是Spark模块是不可或缺的，因为delta log的处理需要用到Spark 。这意味着如果要用查询时还要跑一个Spark作业。在查询前要运行Spark作业生成文件。如果表数据是实时更新的，意味着每次在查询之前先要跑一个，再跑。这样以来，查询显得特别鸡肋。所以完全脱离的话，需要去抽象一个接口，这样用户可以直接使用查询Delta数据，而不必事先启动一个 Spark 任务。所以开源思想在这确实没有怎么体现~ ~ ~
在查询性能方面，开源的Delta几乎没有任何优化。的且不说，普通的的统计信息也没有。Delta在数据merge方面性能不如 Hudi ，在查询方面性能不如，是不是意味着Delta一无是处了呢？其实不然。Delta的一大优点就是与Spark的整合能力，尤其是其流批一体的设计，配合multi-hop的data ，可以支持分析、、CDC等多种场景。使用灵活、场景支持完善是它相比Hudi和的最大优点。另外， Delta号称是和Kappa架构的改进版，无需关心流批，无需关心架构。这一点上Hudi和是力所不及的。
2.核心原理解析
所以我们可以从以上的内容看出是砖厂为了扩大Spark体系版图而设计的一个数据存储中间层，它的建立是为了更好得服务Spark生态，对于其他开源组件的支持短期内可能是个幻像。对它来说我们需要去了解的是它的设计思路以及实现方式。做到知己知彼，百战不殆。下来，我们开始从几个核心要素来展开。
2.1 支持 ACID 事务
Delta Lake支持MVVC（多版本并发控制），并且在多并发写入之间提供ACID事务保证。每次写入都是一个事务，并且在事务日志中记录了写入的序列顺序。事务日志跟踪文件级别的写入并使用乐观并发控制，这点非常适合数据湖，因为在多次写入/修改相同的文件在数据湖里很少发生。在有且存在冲突的情况下，这时Delta Lake会抛出并发修改异常以便用户能够处理它们并且这时也会重试该作业，将冲突的文件在前一个进程处理之后会将最终生成的文件与后一个写入进行下一次合并修改，这样两个同时进来的并发间的矛盾便会被合理处理掉。Delta Lake还提供强大的可序列化隔离级别，允许持续写入目录或表，并允许消费者继续从同一目录或表中读取。读者将看到阅读开始时存在的最新快照。
2.2 模式管理（）
Delta Lake会去自动验证正在被写入的表的是否与表的兼容。一旦表中存在中不存在的列时，此操作则会引发写入异常；表中不存在但存在的列会设置为null 。Delta Lake支持向后兼容（），因而这里的还是对数据有一定的规范和限制作用的。Delta Lake 具有显式添加新列的 DDL 以及自动更新模式的能力。