作为一名数据工程师,您期望构建大规划的数据、机器学习、数据科学和人工智能处理方案,以供给最先进的功用。您经过吸取很多源数据,然后进行清洗、规范化和数据兼并,终究经过易于运用的数据模型将这些数据出现给下流应用程序。
跟着您需求吸取和处理的数据量不断增加,您需求具有横向扩展存储的才干。此外,您需求动态扩展核算资源,以应对处理和消费的顶峰。因为您将数据源兼并到一个数据模型中,您不仅需求将数据追加到表中,还经常需求依据杂乱的业务逻辑插入、更新或删去(即MERGE或UPSERT)记录。您期望能够在具有业务性保证的情况下履行这些操作,而无需不断重写大数据文件。
曩昔,上述一系列要求由两套不同的东西集处理。云端数据湖供给了水平可扩展性和存储与核算的解耦,而联系型数据库房供给了业务性保证。但是,传统数据库房将存储和核算紧密耦合到本地设备上,并不具有与数据湖相关的横向扩展性。
Delta Lake将具有业务性可靠性以及支撑UPSERT和MERGE操作的功用引进了数据湖,一同坚持了数据湖的动态水平可扩展性和存储与核算的分离。Delta Lake是构建数据湖库房的处理方案之一,它是一种敞开数据架构,结合了数据库房和数据湖的长处。
在本介绍中,咱们将简要了解联系型数据库以及它们是怎么演化为数据库房的。接下来,咱们将研讨数据湖出现背面的要害驱动要素。咱们将评论每种架构的长处和缺陷,终究展现Delta Lake存储层怎么结合每种架构的长处,然后完成数据湖库房处理方案的创立。
联系数据库的简要前史
在他1970年的前史性论文中,E.F. Codd引进了将数据视为逻辑联系的概念,独立于物理数据存储。这种数据实体之间的逻辑联系被称为数据库模型或架构。Codd的著作导致了联系数据库的诞生。第一个联系数据库体系是在20世纪70年代中期由IBM和UBC引进的。
在20世纪80年代和90年代,联系数据库及其底层的SQL言语成为企业应用的规范存储技能。其间一个首要原因是联系数据库供给了一个称为”业务”的概念。数据库业务是对数据库履行的一系列操作,满足四个特点:原子性(Atomicity)、一同性(Consistency)、阻隔性(Isolation)和耐久性(Durability),一般用它们的首字母缩写ACID表示。
原子性保证对数据库的一切更改作为单个操作履行。这意味着只要在一切更改都成功履行时,业务才会成功。例如,当在线银行体系用于从储蓄账户转账到支票账户时,原子性特点将保证操作仅在从储蓄账户中扣除资金并加入到支票账户时才会成功。整个操作要么成功,要么作为一个完好的单元失利。
一同性特点保证数据库在业务开端时从一个一同状况过渡到业务结束时的另一个一同状况。在咱们之前的比方中,只要储蓄账户有满足的资金时,资金搬运才会产生。否则,业务将失利,余额将坚持在其原始一同状况。
阻隔性保证数据库中一同进行的操作不会互相影响。这个特点保证当多个业务一同履行时,它们的操作不会彼此干扰。
耐久性指的是已提交业务的耐久性。它保证一旦业务成功完成,即便在体系故障的情况下,也会产生永久状况。在咱们的资金搬运示例中,耐久性将保证对我的储蓄和支票账户所做的更新是耐久的,并能够在或许的体系故障情况下存活。
数据库体系在20世纪90年代持续老练开展,而20世纪90年代中期互联网的出现导致数据爆炸性增长和数据存储的需求。企业应用程序十分有用地运用了联系数据库办理体系(RDBMS)技能。旗舰产品如SAP和Salesforce会收集和保护很多数据。
但是,这一开展也伴跟着一些缺陷。企业应用程序会以它们自己的专有格局存储数据,导致数据孤立的出现。这些数据孤立由一个部分或业务单位具有和操控。跟着时刻的推移,安排认识到需求跨不同的数据孤立开发企业视图,然后导致数据库房的兴起。
数据库房
尽管每个企业应用程序都内置了某种类型的陈述功用,但因为缺乏全面的安排视图,一些商机被忽视了。与此一同,安排们认识到剖析长时刻段内的数据的价值。此外,他们期望能够在多个穿插主题上对数据进行切分和剖析,如客户、产品和其他业务实体等。
这导致了数据库房的引进,它是来自多个数据源的集成前史数据的中心联系库,供给了企业的单一集成前史视图,运用一致的架构,覆盖了企业的各个方面。
数据库房架构
典型数据库房架构的简略示意图如图1-1所示。

当咱们看图1-1中的图表时,咱们从左侧的数据源层开端。安排需求从一组异构数据源中获取数据。尽管来自安排的企业资源规划(ERP)体系构成了安排模型的主干,但咱们需求用日常运营的操作体系(如人力资源(HR)体系和作业流办理软件)的数据来补充这些数据。此外,安排或许期望运用其客户联系办理(CRM)和出售点(POS)体系包含的客户互动数据。除了这儿列出的中心数据源外,还需求从各种外部数据源吸取数据,以各种格局,如电子表格、CSV文件等。
这些不同的源体系或许具有各自的数据格局。因而,数据库房包含一个分级区域,用于将来自不同源的数据兼并为一个通用格局。为了做到这一点,体系必须吸取来自原始数据源的数据。实际的吸取进程因数据源类型而异。一些体系答应直接拜访数据库,而其他体系答应经过API吸取数据,而许多数据源仍依赖文件提取。
接下来,数据库房需求将数据转化为规范化格局,以便下流流程轻松拜访数据。终究,转化后的数据加载到分级区域。在联系型数据库房中,这个分级区域一般是一组没有主键或外键或简略数据类型的扁平联系分级表。
这个从提取数据、转化成规范格局、加载到数据库房的进程一般被称为ETL(提取、转化和加载)。ETL东西能够在终究加载数据到数据库房之前对吸取的数据履行多项使命。这些使命包含消除重复记录。因为数据库房将是仅有的真实数据源,咱们不期望它包含相同数据的多个副本。此外,重复记录会阻挠生成每个记录的仅有键。
ETL东西还答应咱们将数据从多个数据源兼并。例如,咱们的客户的一个视图或许在CRM体系中捕获,而其他特点在ERP体系中找到。安排需求将这些不同方面兼并成一个客户的全面视图。这是咱们开端向数据库房引进办法的当地。在咱们的客户示例中,办法将界说客户表的不同列,每个列需求哪些列,每个列的数据类型和约束等等。
具有规范化的列表示,如日期和时刻,是重要的。ETL东西能够保证数据库房中的一切时刻列都运用相同的规范进行格局化。
终究,安排期望依照其数据办理规范对数据进行质量检查。这或许包含删去不符合最低规范的低质量数据行。
数据库房在一个单块物理架构上进行物理施行,由一个单一的大节点组成,结合了内存、核算和存储。这种单块架构迫使安排在笔直方向上扩展其根底架构,导致贵重的、一般超维度的根底架构,为峰值用户负载而装备,一同在其他时刻挨近空闲。
数据库房一般包含以下分类的数据:
- 元数据:关于数据的上下文信息。这些数据一般存储在数据目录中。它使数据剖析师能够描绘、分类和轻松定位存储在数据库房中的数据。
- 原始数据:以原始格局保护,没有经过任何处理。拜访原始数据使数据库房体系能够在负载失利的情况下重新处理数据。
- 摘要数据:由底层数据办理体系主动创立。跟着新数据加载到数据库房中,摘要数据将主动更新。它包含跨多个符合维度的聚合。摘要数据的首要意图是加快查询功用。
数据库房中的数据在出现层中被耗费。这是顾客能够与数据库房中存储的数据互动的当地。咱们能够广泛地辨认出两大顾客集体:
- 人类顾客:这是安排内需求运用数据的人员。这些顾客能够是需求拜访数据作为其作业的重要部分的知识作业者,也能够是一般运用高度摘要数据的高管,一般以仪表板和要害绩效方针(KPI)的办法运用数据。
- 内部或外部体系:数据库房中的数据能够被各种内部或外部体系耗费。这能够包含机器学习和人工智能东西集,或需求运用库房数据的内部应用程序。一些体系能够直接拜访数据,而其他体系能够运用数据提取,还有一些体系或许以发布-订阅办法直接耗费数据。
人类顾客将运用各种剖析东西和技能来从数据中取得可操作的见解,包含:
- 陈述东西:这些东西运用户经过比方表格陈述和各种图形表示等可视化手法开发对数据的见解。
- 联机剖析处理(OLAP)东西:顾客需求以各种办法切分和剖析数据。OLAP东西以多维格局出现数据,答应从多个角度查询数据。它们运用预存的聚合数据,一般存储在内存中,以供给高功用的数据。
- 数据发掘:这些东西答应数据剖析师经过数学相关性和分类来发现数据中的办法。它们协助剖析师辨认不同数据源之间以前躲藏的联系。从某种意义上说,数据发掘东西能够看作是现代数据科学东西的前身。
维度建模
数据库房引进了跨企业各个主题范畴的综合数据模型的需求。用于创立这些模型的技能被称为维度建模。
在相似Bill Inmon和Ralph Kimball等先知的著作和思维的推进下,维度建模初次在Kimball的重要著作《数据库房东西包:维度建模彻底攻略》中引进。Kimball界说了一种办法论,侧重于自下而上的办法,保证团队尽快为数据库房供给真正的价值。
维度模型由星型办法(Star Schema)描绘。星型办法将特定业务流程的数据(例如出售)安排成一种有利于进行轻松剖析的结构。它由两种类型的表组成:
- 现实表,它是办法的首要或中心表。现实表捕获业务流程的首要测量、方针或“现实”。以出售业务流程为例,出售现实表将包含出售数量和出售金额。 现实表具有清晰界说的粒度。粒度是由表中所表示的维度(列)的组合决定的。如果出售现实表只是出售的年度总结,那么它的粒度就很低;如果它包含日期、商店和客户标识的出售,那么它的粒度就很高。
- 与现实表相关的多维表。维度供给了所选业务流程周围的上下文。以出售场景为例,维度列表能够包含产品、客户、出售人员和商店。
维度表“包围”着现实表,这就是为什么这些类型的办法被称为“星型办法”的原因。星型办法由现实表组成,经过主键和外键联系与其关联的维度表相连。咱们的出售主题范畴的星型办法如图1-2所示。

数据库房的优点和应战
数据库房具有固有的优势,为业务社区供给了杰出的服务。它们以常见的格局供给来自不同数据源的高质量、清洁和规范化数据。因为来自不同部分的数据以常见格局出现,因而每个部分都会依照其他部分的结果进行检查。具有及时精确的数据是做出强有力的业务决议计划的根底。
因为它们存储很多的前史数据,它们答应前史洞察,运用户能够剖析不一同期和趋势。
数据库房往往十分可靠,依据底层的联系数据库技能,履行ACID业务。
数据库房选用规范的星型办法建模技能,创立现实表和维度。越来越多的预建模板模型适用于各种主题范畴,如出售和CRM,进一步加快了这些模型的开展。
数据库房十分适用于商业智能和陈述,基本上是在数据老练度曲线上回答“产生了什么?”问题。数据库房结合商业智能(BI)东西可认为营销、财政、运营和出售生成可行的见解。
互联网和交际媒体的快速兴起以及智能手机等多媒体设备的可用性打破了传统的数据景象,引发了“大数据”这一术语。大数据被界说为数据的体积不断增加,速度更快,格局更多样,精确性更高。这些被称为数据的四个“V”:
- 体积:全球创造、捕获、仿制和消费的数据体积迅速增加。依据Statista的描绘,未来两年,全球数据的创立估计将增长到超越200泽字节(1泽字节等于2的70次方字节)。
- 速度:在今天的现代商业环境中,及时决议计划至关重要。为了做出这些决议计划,安排需求信息能够快速活动,最好是尽或许挨近实时。例如,股票交易应用程序需求拜访挨近实时的数据,以便高档交易算法能够做出毫秒级决议计划,并将这些决议计划传达给利益相关者。取得及时数据能够使安排取得竞争优势。
- 多样性:多样性指现在可用的不同“类型”数据的数量。传统的数据类型都是结构化的,一般以联系数据库或其提取办法供给。跟着大数据的兴起,数据现在以新的非结构化类型抵达。非结构化和半结构化的数据类型,如物联网(IoT)设备消息、文本、音频和视频,需求额定的预处理来提取业务意义。多样性还经过不同类型的吸取办法表达。一些数据源最合适批处理办法,而其他数据源适用于增量吸取,或实时的、依据事情的吸取,如IoT数据流。
- 精确性:精确性界说了数据的可信度。在这儿,咱们期望保证数据精确且质量高。数据能够从多个来历吸取;重要的是了解数据的职责链,保证咱们具有丰厚的元数据,并了解数据收集的上下文。此外,咱们期望保证咱们对数据的视图是完好的,没有缺失的组成部分或迟到的现实。
传统数据库房的架构难以处理这四个“V”。
传统数据库房架构在处理指数增长的数据量方面面对困难。它们既存在存储问题,也存在可弹性性问题。跟着数据量到达了百千字节等级,要在不花费很多资金的情况下扩展存储才干变得具有应战性。传统数据库房架构不运用内存和并行处理技能,然后阻挠它们在笔直方向上扩展数据库房。 数据库房架构也不合适处理大数据的速度。数据库房不支撑支撑挨近实时数据的所需流式架构类型。ETL数据加载窗口只能缩短到必定程度,直到根底架构开端溃散。
尽管数据库房十分拿手存储结构化数据,但不合适存储和查询半结构化或非结构化数据的多样性。 数据库房没有内置支撑盯梢数据的可信度。数据库房元数据首要侧重于办法,而较少重视血统、数据质量和其他精确性变量。 此外,数据库房依据关闭的专有格局,一般只支撑依据SQL的查询东西。因为其专有格局,数据库房不供给很好的支撑数据科学和机器学习东西。 因为这些约束,树立数据库房本钱昂扬。
因而,项目往往在上线之前就失利了,而那些上线的项目在跟上现代商业环境和四个“V”的不断改变要求方面面对困难。 传统数据库房架构的约束催生了一种更现代的架构,依据数据湖(data lake)的概念。
介绍数据湖
数据湖是一个本钱效益的中心存储库,用于以文件和二进制大方针(blobs)的办法存储任何规划的结构化、半结构化或非结构化数据。术语“数据湖”来自于与真实的河流或湖泊的类比,它保存着水,或在这种情况下是数据,具有几条支流,实时将水(也就是“数据”)流入湖中。一个典型数据湖的规范表示如图1-3所示。

开端的数据湖和大数据处理方案是树立在本地集群上的,依据Apache Hadoop开源结构。Hadoop用于高效地存储和处理各种大小的数据集,从几千兆字节到几百千字节不等。Hadoop不运用一台大型核算机来存储和处理数据,而是运用多个一般核算节点的集群,以更快的速度并行剖析很多数据集。
Hadoop会运用MapReduce结构来并行化多个核算节点上的核算使命。Hadoop分布式文件体系(HDFS)是一种规划用于规范或低端硬件的文件体系。HDFS十分忍受故障,支撑大型数据集。
从2015年开端,云数据湖(如Amazon Simple Storage Service(Amazon S3),Azure Data Lake Storage Gen 2(ADLS)和Google Cloud Storage(GCS))开端替代HDFS。这些依据云的存储体系具有卓越的服务等级协议(SLA)(一般大于10个九),供给地理仿制,最重要的是供给极低的本钱,以及运用更低本钱的冷存储进行存档的选项。
在数据湖中,存储的最低等级是数据块。数据块天然生成对错结构化的,能够存储半结构化和非结构化数据,如大型音频和视频文件。在更高的层次上,云存储体系在数据块存储之上供给了文件语义和文件级安全性,然后能够存储高度结构化的数据。因为其高带宽的进口和出口通道,数据湖还能够支撑流式运用事例,如持续吸取很多IoT数据或流媒体。
核算引擎使很多数据能够以相似ETL的办法进行处理,并交付给顾客,如传统数据库房和机器学习和人工智能东西集。流式数据能够存储在实时数据库中,能够运用传统的BI和陈述东西创立陈述。
数据湖经过一系列组件完成:
- 存储:数据湖需求十分大、可扩展的存储体系,一般在云环境中供给。存储需求具有耐用性和可扩展性,并应该支撑与各种第三方东西、库和驱动程序的互操作性。请注意,数据湖将存储和核算的概念分隔,答应二者独立扩展。存储和核算的独立扩展答应按需、弹性地微调资源,使处理方案架构更加灵活。存储体系的进口和出口通道应支撑高带宽,以便吸取或耗费大批量数据,或接连流入很多流媒体数据(如IoT和流媒体)。
- 核算:处理存储层中存储的很多数据需求很多核算才干。不同云渠道上供给了几种核算引擎。数据湖的首选核算引擎是Apache Spark。Spark是一个开源的一致剖析引擎,能够经过各种处理方案(如Databricks或其他云供给商开发的处理方案)布置。大数据核算引擎将运用核算集群。核算集群聚集核算节点以处理完好的数据收集和处理使命。
- 格局:数据在磁盘上的形状界说了格局。供给了各种存储格局。数据湖首要运用规范的开源格局,如Parquet、Avro JSON或CSV。
- 元数据:现代的依据云的存储体系保护元数据(即关于数据的上下文信息)。这包含描绘数据何时被写入或拜访的各种时刻戳、数据办法以及包含有关数据的运用和一切者信息的各种标签。
数据湖具有一些十分强大的优势。数据湖架构使安排的数据财物能够整合到一个中心方位。数据湖是格局不可知的,依赖于Parquet和Avro等开源格局。这些格局被各种东西、驱动程序和库充沛了解,然后完成滑润的互操作性。
数据湖布置在老练的云存储子体系上,能够获益于这些体系的可扩展性、监控、布置快捷性和低存储本钱。主动化的DevOps东西,如Terraform,具有老练的驱动程序,完成了主动布置和保护。
与数据库房不同,数据湖支撑一切数据类型,包含半结构化和非结构化数据,然后完成了媒体处理等作业负载。因为其高吞吐量的进口通道,它十分合适流式运用事例,如吸取IoT传感器数据、媒体流和Web点击流。
但是,跟着数据湖变得越来越盛行和广泛运用,安排开端认识到传统数据湖存在一些应战。尽管底层的云存储相对廉价,但构建和保护有用的数据湖需求专业技能,然后导致高端职工本钱或增加的咨询服务本钱。
尽管很简单吸取原始数据,但将数据转化为能够供给业务价值的办法或许十分贵重。传统数据湖具有较差的查询功用,因而无法用于交互式查询。因而,安排的数据团队依然需求将数据转化并加载到相似数据库房的体系中,然后延长了价值完成的时刻。这导致了数据湖 库房架构。这种架构在适当长的一段时刻内一向占主导地位(咱们个人施行了几十种这类体系),但现在因为湖仓架构的兴起而有所下降。
数据湖一般运用“按读取时的办法”策略,其间数据能够以任何格局吸取,而不需求强制履行办法。只要在读取数据时才干应用某种类型的办法。这种办法强制履行的缺乏或许会导致数据质量问题,然后使原始的数据湖变成“数据沼泽”。
数据湖不供给任何办法的业务性保证。数据文件只能追加,这会导致以昂扬的本钱重写先前编写的数据以进行简略的更新。这会导致“小文件问题”,即为单个实体创立多个小文件。如果这个问题办理不当,这些小文件会减慢整个数据湖的读取功用,导致数据过时和存储浪费。数据湖办理员需求运行重复的操作,以将这些较小的文件兼并到针对高效读取操作进行了优化的较大文件中。
现在咱们现已评论了数据库房和数据湖的优势和劣势,接下来咱们将介绍数据湖仓(Lakehouse),它结合了两种技能的优势并处理了它们的弱点。
数据湖仓
Armbrust、Ghodsi、Xin 和 Zaharia在2021年初次提出了数据湖仓(data lakehouse)的概念。这些作者将湖仓界说为“一种依据低本钱和直接可拜访存储的数据办理体系,还供给了像ACID业务、数据版别操控、审计、索引、缓存和查询优化等功用特征的剖析数据库办理体系(DBMS)办理。”
当咱们解读这个陈述时,咱们能够将湖仓界说为一种体系,它将数据湖的灵活性、低本钱和可扩展性与数据库房的数据办理和ACID业务相结合,处理了两者的约束。与数据湖相似,湖仓架构运用低本钱的云存储体系,一同具有这些体系固有的灵活性和水平可扩展性。湖仓的方针是运用现有的高功用数据格局,如Parquet,一同支撑ACID业务(和其他功用)。为了增加这些功用,湖仓运用了一种敞开表格格局,其间包含ACID业务、记录级操作、索引和要害元数据等功用,以增强现有数据格局。这使得存储在低本钱存储体系上的数据财物具有了曩昔只要联系数据库办理体系(RDBMS)范畴才具有的可靠性。Delta Lake是支撑这些功用的敞开表格格局的一个示例。
湖仓特别适用于大多数云环境,如果不是一切,都具有独立的核算和存储资源。不同的核算应用程序能够按需在彻底独立的核算节点上运行,比方Spark集群,一同直接拜访相同的存储数据。但是,理论上也能够在本地存储体系上完成湖仓,比方前面说到的HDFS。
数据湖仓的优点
湖仓架构的概览如图1-4所示。

有了湖仓架构,咱们不再需求在数据湖和某种数据库房存储中都保存一份数据副本。现实上,咱们能够经过Delta Lake存储格局和协议从数据湖中获取数据,其功用可与传统数据库房相媲美。
因为咱们能够持续运用低本钱的依据云的存储技能,而无需将数据从数据湖仿制到数据库房,因而咱们能够完成大幅下降根底设施、职工和咨询开支的本钱节约。
因为数据移动较少,ETL进程得以简化,数据质量问题的机会明显减少,终究,因为湖仓结合了存储大数据量和精细的维度模型的才干,开发周期缩短,价值完成时刻大幅缩短。
从数据库房到数据湖再到湖仓架构的演化如图1-5所示。

施行湖仓架构
正如咱们前面说到的,湖仓架构运用低本钱的方针存储,比方Amazon S3、ADLS或GCS,将数据存储在开源表格局中,比方Apache Parquet。但是,因为湖仓施行需求对这些数据运行ACID业务,咱们需求在云存储之上构建一个业务性元数据层,界说哪些方针属于表版别。
这将答应湖仓施行功用,比方ACID业务和版别操控,在元数据层内,一同坚持大部分数据存储在低本钱的方针存储中。湖仓客户端能够持续运用他们现已了解的开源格局的数据。
接下来,咱们需求处理体系功用的问题。正如咱们前面说到的,湖仓施行需求完成超卓的SQL功用才干有用。数据库房十分拿手优化功用,因为它们运用关闭的存储格局和众所周知的办法。这使它们能够保护统计信息、构建聚簇索引、将热点数据移到快速的SSD设备上等。
在湖仓中,依据开源规范格局,咱们没有这种奢侈,因为咱们不能更改存储格局。但是,湖仓能够运用很多其他优化,而不改变数据文件。这包含缓存、辅佐数据结构,如索引和统计信息,以及数据布局优化。
加快剖析作业负载的终究一个东西是开发规范的DataFrame API。许多盛行的机器学习东西,比方TensorFlow和Spark MLlib,都支撑DataFrames。DataFrames最早由R和pandas引进,供给了对数据的简略表笼统,具有多种改换操作,大多数源自联系代数。
在Spark中,DataFrame API是声明性的,运用慵懒评价来构建履行DAG(有向无环图)。在DataFrame耗费底层数据之前,能够优化此图。这为湖仓供给了许多新的优化特性,比方缓存和辅佐数据。图1-6展现了这些要求怎么习惯湖仓体系规划的全体结构。
因为Delta Lake是本书的重点,咱们将阐明Delta Lake怎么满足施行湖仓的要求。

Delta Lake
正如前一节中说到的,一个潜在的湖仓处理方案能够构建在Delta Lake之上。Delta Lake是一种敞开表格局,将元数据、缓存和索引与数据湖存储格局相结合。这些功用一同供给了一种笼统等级,以供给ACID业务和其他办理功用。
Delta Lake的敞开表格局和开源元数据层终究完成了湖仓的施行。Delta Lake供给ACID业务、可扩展的元数据处理、跨批处理和流式处理的一致进程模型、完好的审计前史记录以及对SQL数据操作言语(DML)句子的支撑。它能够运行在现有的数据湖上,并与多个处理引擎彻底兼容,包含Apache Spark。
Delta Lake是一个开源结构,其规范能够在delta.io上找到。Armbrust等人的作业具体描绘了Delta Lake怎么供给ACID业务。
Delta Lake供给以下功用:
- 业务性ACID保证
Delta Lake将保证一切运用Spark或任何其他处理引擎的数据湖业务都以原子办法提交以确坚耐久性,并对其他读取器揭露。这是经过Delta业务日志完成的。在第2章中,咱们将具体介绍业务日志。
- 完好的DML支撑
传统的数据湖不支撑对数据的业务性、原子更新。Delta Lake彻底支撑一切DML操作,包含删去和更新,以及杂乱的数据兼并或更新场景。这种支撑大大简化了构建现代数据库房(MDW)时维度和现实表的创立。
- 审计前史
Delta Lake业务日志记录了对数据所做的每一项更改,依照更改的次序记录。因而,业务日志成为对数据所做的任何更改的完好审计盯梢。这使办理员和开发人员能够在意外删去和编辑后回滚到数据的早期版别。这个功用被称为时刻游览,将在第6章中具体介绍。
- 批处理和流处理的一致处理模型
Delta Lake能够处理批处理和流处理的接收或源。它能够对数据流履行MERGE操作,这是在将IoT数据与设备参阅数据兼并时的常见要求。它还支撑从外部数据源接收CDC数据的用例。咱们将在第8章中具体介绍流处理。
- 办法强制和演进
Delta Lake在从湖中写入或读取数据时强制履行办法。但是,当为数据实体清晰启用时,它答应安全的办法演进,然后支撑数据需求演进的用例。办法强制和演进将在第7章中介绍。
- 丰厚的元数据支撑和可弹性性
具有支撑大容量数据的才干是很重要的,但如果元数据不能相应扩展,处理方案将会受到约束。Delta Lake经过运用Spark或其他核算引擎来扩展一切元数据处理操作,使其能够有用处理PB级数据的元数据。
湖仓架构由三个层组成,如图1-7所示。湖仓存储层树立在规范的云存储技能上,如ADLS、GCS或Amazon S3存储。这为湖仓供给了高度可扩展且低本钱的存储层。

湖仓的业务层由Delta Lake供给。这为湖仓带来了ACID保证,使原始数据能够高效地转化为经过精心策划的可操作数据。除了ACID支撑,Delta Lake还供给了一套丰厚的附加功用,如DML支撑、可扩展的元数据处理、流式支撑以及丰厚的审计日志。湖仓堆栈的顶层由高功用的查询和处理引擎组成,这些引擎运用底层的云核算资源。支撑的查询引擎包含:
- Apache Spark
- Apache Hive
- Presto
- Trino 请查阅Delta Lake网站以获取支撑的核算引擎的完好列表。
Medallion架构
图1-8供给了一个依据Delta Lake的Lakehouse架构的示例。这种具有Bronze、Silver和Gold层的架构办法一般被称为Medallion架构。尽管这只是很多Lakehouse架构办法之一,但它十分合适现代数据库房、数据集市和其他剖析处理方案。

在这个处理方案中,最高层次咱们有三个组件。在左侧,咱们有不同的数据源。数据源能够选用多种办法,这儿供给了一些示例:
- 存储在外部数据湖上的一组CSV或TXT文件
- 本地数据库,如Oracle或SQL Server
- 流数据源,如Kafka或Azure Event Hubs
- 来自SAS服务的REST API,如Salesforce或ADP
中心组件施行了Medallion架构。Medallion架构是一种数据规划办法,用于经过Bronze、Silver和Gold层在Lakehouse中逻辑安排数据。Bronze层是咱们从左侧的源体系中吸取的数据着陆的当地。Bronze区域的数据一般是按原样着陆的,但能够附加其他元数据,如加载日期和时刻、处理标识等。
在Silver层,来自Bronze层的数据被清洗、规范化、兼并和规范化。这是企业数据在不同主题范畴之间逐渐聚集的当地。
Gold层中的数据是“可用于消费的”数据。这些数据能够选用经典的星型办法格局,包含维度和现实表,或者能够选用合适于运用事例的任何数据模型。
Medallion架构的方针是在数据经过架构的每个层次活动时,逐步提高数据的结构和质量,每个层次都具有固有的意图。这个数据规划办法将在第10章中更具体地介绍,但重要的是要了解Lakehouse与Delta Lake一同怎么支撑可靠的、高功用的数据规划办法或多跳架构。像Medallion架构这样的规划办法为一致Lakehouse中的数据流水线供给了一些架构根底,以支撑多个用例(如批量数据、流数据和机器学习)。
Delta生态
正如咱们在本章中所介绍的,Delta Lake使咱们能够构建数据湖库房架构,然后能够直接在数据湖上保管数据库房和机器学习/人工智能应用。目前,Delta Lake是最广泛运用的湖库房格局,已被超越7,000个安排运用,每天处理的数据到达艾克赫。
但是,数据库房和机器学习应用程序并不是Delta Lake的仅有应用方针。除了其中心业务性ACID支撑,为数据湖带来可靠性之外,Delta Lake还使咱们能够无缝地吸取和消费流数据和批处理数据,一切这些都能够在一个处理方案架构中完成。
Delta Lake的另一个重要组件是Delta Sharing,它使公司能够以安全的办法同享数据集。Delta Lake 3.0现在支撑独立的读取器和写入器,使任何客户端(如Python、Ruby或Rust)都能够直接将数据写入Delta Lake,而无需任何大数据引擎,如Spark或Flink。Delta Lake附带了一组扩展的开源连接器,包含Presto、Flink和Trino。Delta Lake存储层现在广泛用于许多渠道,包含ADLS、Amazon S3和GCS。Delta Lake 2.0的一切组件都已由Databricks开源。
Delta Lake和湖库房的成功催生了一个彻底新的生态体系,围绕Delta技能构建。这个生态体系由各种独立组件组成,包含Delta Lake存储格局、Delta Sharing和Delta Connectors。
Delta Lake存储
Delta Lake存储格局是一个开源的存储层,运行在依据云的数据湖之上。它为数据湖文件和表增加了业务才干,将数据库房相似的功用带到了规范的数据湖。Delta Lake存储是生态体系的中心组件,因为一切其他组件都依赖于这一层。
Delta Sharing
数据同享在业务中是一个常见的用例。例如,一家采矿公司或许期望将其大型采矿卡车引擎的IoT信息安全地与制造商同享,以进行预防性保护和诊断。恒温器制造商或许期望将暖通空调数据安全地与公用事业公司同享,以优化高负荷运用日的电网负载。但是,在曩昔,施行安全可靠的数据同享处理方案十分具有应战性,需求贵重的定制开发。
Delta Sharing是一个用于安全同享Delta Lake数据的开源协议。它答应用户安全地同享存储在Amazon S3、ADLS或GCS中的数据。运用Delta Sharing,用户能够直接连接到同享的数据,运用他们喜欢的东西集,如Spark、Rust、Power BI等,而无需布置任何其他组件。请注意,数据能够跨云供给商进行同享,无需进行任何自界说开发。
Delta Sharing能够支撑以下用例:
- 存储在ADLS中的数据能够由AWS上的Spark引擎处理。
- 存储在Amazon S3中的数据能够由GCP上的Rust处理。
有关Delta Sharing的具体评论,请参阅第9章。
Delta Connectors
Delta Connectors的首要方针是将Delta Lake引进Apache Spark之外的其他大数据引擎。Delta Connectors是一组开源连接器,能够直接连接到Delta Lake。该结构包含Delta Standalone,这是一个答应直接读写Delta Lake表格的Java本地库,而无需Apache Spark集群。消费应用程序能够运用Delta Standalone直接连接到由其大数据根底架构编写的Delta表格,然后无需在数据被耗费之前将其仿制到另一种格局中。
还有其他用于不同引擎的本地库,包含:
- Hive
Hive连接器能够直接从Apache Hive读取Delta表格。
- Flink
Flink/Delta连接器能够在Apache Flink应用程序中读取和编写Delta表格。该连接器包含一个用于将数据写入Delta表格的sink以及一个用于运用Flink读取Delta表格的source。
- sql-delta-import
此连接器答应从JDBC数据源直接导入数据到Delta表格。
- Power BI
Power BI连接器是一个自界说的Power Query函数,答应Power BI从Microsoft Power BI支撑的任何依据文件的数据源中读取Delta表格。
Delta Connectors是一个快速增长的生态体系,定时推出更多连接器。实际上,在最近宣告的Delta Lake 3.0版别中包含Delta Kernel。Delta Kernel及其简化的库消除了了解Delta协议细节的需求,因而更简单构建和保护连接器。
总结
考虑到数据的数量、速度、多样性和精确性,数据库房和数据湖的约束和应战推进了一种新的数据架构范式。由Delta Lake等敞开表格格局的前进提出的湖宅架构为现代数据架构供给了一种办法,聚集了其前身的最佳元素,为数据渠道带来了一致的办法。
正如前语中说到的,本书不仅仅是触及外表;它将深入探讨本章中现已提及的Delta Lake的一些中心功用。您将了解怎么最佳设置Delta Lake,辨认不同功用的用例,了解最佳实践和需求考虑的不同事项等等。本书将不断为数据从业者供给背景信息和证据,阐明这种敞开表格格局怎么支撑湖宅架构的现代数据渠道。经过阅览本书,您将自傲地开端运用Delta Lake并构建现代数据湖宅架构。