“数据湖三剑客”Hudi、Delta Lake和Iceberg 深度对比

一个热爱生活又放荡不羁的程序猿

本文主要讲解如下内容：

一、数据湖的优点

二、目前有哪些开源数据湖组件

三、三大数据湖组件对比

数据湖相比传统数仓而言，最明显的便是优秀的T+0能力，这个解决了Hadoop时代数据分析的顽疾。传统的数据处理流程从数据入库到数据处理通常需要一个较长的环节、涉及许多复杂的逻辑来保证数据的一致性，由于架构的复杂性使得整个流水线具有明显的延迟。

目前开源的数据湖有江湖人称“数据湖三剑客”的 Hudi、Delta Lake和Iceberg

Iceberg官网定义：Iceberg是一个通用的表格式（数据组织格式），提供高性能的读写和元数据管理功能。

Iceberg 的 ACID 能力可以简化整个流水线的设计，传统 Hive/Spark 在修正数据时需要将数据读取出来，修改后再写入，有极大的修正成本。

[玫瑰]ACID能力，无缝贴合流批一体数据存储

随着flink等技术的不断发展，流批一体生态不断完善，但在流批一体数据存储方面一直是个空白，直到Iceberg等数据湖技术的出现，这片空白被慢慢填补。

Iceberg 提供 ACID 事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了 ETL；

Iceberg 提供了 upsert、merge into 能力，可以极大地缩小数据入库延迟；

[玫瑰]统一数据存储，无缝衔接计算引擎和数据存储

Iceberg提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；

Iceberg 支持隐藏分区和分区进化，方便业务进行数据分区策略更新。

Iceberg屏蔽了底层数据存储格式的差异，提供对于Parquet，ORC和Avro格式的支持。将上层引擎的能力传导到下层的存储格式。

[玫瑰]开放架构设计，开发维护成本相对可控

Iceberg 的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎对接，目前 Iceberg 支持的计算引擎有 Spark、Flink、Presto 以及 Hive。

相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计；

面向对象存储的优化。Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename *** 作，使其在基于对象存储的数据湖架构适配上更有优势。

[玫瑰]增量数据读取，实时计算的一把利剑

Iceberg 支持通过流式方式读取增量数据，支持 Structed Streaming 以及 Flink table Source。

Apache Hudi是一种数据湖的存储格式，在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。

Hudi支持如下两种表类型：

使用Parquet格式存储数据。Copy On Write表的更新 *** 作需要通过重写实现。

使用列式文件格式（Parquet）和行式文件格式（Avro）混合的方式来存储数据。Merge On Read使用列式格式存放Base数据，同时使用行式格式存放增量数据。最新写入的增量数据存放至行式文件中，根据可配置的策略执行COMPACTION *** 作合并增量数据至列式文件中。

应用场景

Hudi支持插入、更新和删除数据。可以实时消费消息队列（Kafka）和日志服务SLS等日志数据至Hudi中，同时也支持实时同步数据库Binlog产生的变更数据。

Hudi优化了数据写入过程中产生的小文件。因此，相比其他传统的文件格式，Hudi对HDFS文件系统更加的友好。

Hudi支持多种数据分析引擎，包括Hive、Spark、Presto和Impala。Hudi作为一种文件格式，不需要依赖额外的服务进程，在使用上也更加的轻量化。

Hudi支持Incremental Query查询类型，可以通过Spark Streaming查询给定COMMIT后发生变更的数据。Hudi提供了一种消费HDFS变化数据的能力，可以用来优化现有的系统架构。

Delta Lake是Spark计算框架和存储系统之间带有Schema信息数据的存储中间层。它给Spark带来了三个最主要的功能：

第一，Delta Lake使得Spark能支持数据更新和删除功能；

第二，Delta Lake使得Spark能支持事务；

第三，支持数据版本管理，运行用户查询 历史 数据快照。

核心特性

Delta lake

由于Apache Spark在商业化上取得巨 成功，所以由其背后商业公司Databricks推出的Delta lake也显得格外亮眼。在没有delta数据湖之前，Databricks的客户 般会采 经典的lambda架构来构建他们的流批处理场景。

Hudi

Apache Hudi是由Uber的 程师为满 其内部数据分析的需求 设计的数据湖项 ，它提供的fast upsert/delete以及compaction等功能可以说是精准命中 民群众的痛点，加上项 各成员积极地社区建设，包括技术细节分享、国内社区推 等等，也在逐步地吸引潜在 户的 光。

Iceberg

Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为 研Iceberg，并最终演化成Apache下 个 度抽象通 的开源数据湖 案。

三者均为Data Lake的数据存储中间层，其数据管理的功能均是基于 系列的meta 件。Meta 件的 类似于数据库的catalog，起到schema管理、事务管理和数据管理的功能。与数据库不同的是，这些meta 件是与数据 件 起存放在存储引擎中的， 户可以直接看到。这个做法直接继承了 数据分析中数据对 户可见的传统，但是 形中也增加了数据被不 破坏的风险。 旦删了meta 录，表就被破坏了，恢复难度很 。

Meta包含有表的schema信息。因此系统可以 掌握schema的变动，提供schema演化的 持。Meta 件也有transaction log的功能（需要 件系统有原 性和 致性的 持）。所有对表的变更都会 成 份新的meta 件，于是系统就有了ACID和多版本的 持，同时可以提供访问 历史 的功能。在这些 ，三者是相同的。

Hudi 的设计 标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调了其主要 持Upserts、Deletes 和 Incremental 数据处理，其主要提供的写 具是 Spark HudiDataSource API 和 提供的 HoodieDeltaStreamer，均 持三种数据写 式：UPSERT，INSERT 和 BULK_INSERT。其对 Delete 的 持也是通过写 时指定 定的选项 持的，并不 持纯粹的 delete 接 。

在查询 ，Hudi 持 Hive、Spark、Presto。

在性能 ，Hudi 设计了 HoodieKey ， 个类似于主键的东西。对于查询性能， 般需求是根据查询谓词 成过滤条件下推 datasource。Hudi 这 没怎么做 作，其性能完全基于引擎 带的谓词下推和 partition prune 功能。

Hudi 的另 特 是 持 Copy On Write 和 Merge On Read。前者在写 时做数据的 merge，写 性能略差，但是读性能更 些。后者读的时候做 merge，读性能差，但是写 数据会 较及时，因 后者可以提供近实时的数据分析能 。最后，Hudi 提供了 个名为run_sync_tool 的脚本同步数据的 schema 到 Hive 表。Hudi 还提供了 个命令 具 于管理 Hudi 表。

Iceberg 没有类似的 HoodieKey 设计，其不强调主键。没有主键，做 update/delete/merge 等 *** 作就要通过 Join 来实现， Join 需要有 个类似 SQL 的执 引擎。

Iceberg 在查询性能 做了 量的 作。值得 提的是它的 hidden partition 功能。Hidden partition 意思是说，对于 户输 的数据， 户可以选取其中某些列做适当的变换（Transform）形成 个新的列作为 partition 列。这个 partition 列仅仅为了将数据进 分区，并不直接体现在表的 schema中。

Delta 的定位是流批 体的， 持 update/delete/merge，spark 的所有数据写 式，包括基于dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是 持的。

不强调主键，因此其 update/delete/merge 的实现均是基于 spark 的 join 功能。在数据写 ，Delta 与 Spark 是强绑定的，这 点 Hudi 是不同的：Hudi 的数据写 不绑定 Spark。

在查询 ，Delta 前 持 Spark 与 Presto，但是，Spark 是不可或缺的，因为 delta log 的处理需要 到 Spark。这意味着如果要 Presto 查询 Delta，查询时还要跑 个 Spark 作业。更为难受的是，Presto 查询是基于 SymlinkTextInputFormat 。在查询之前，要运 Spark 作业 成这么个 Symlink 件。如果表数据是实时更新的，意味着每次在查询之前先要跑 个 SparkSQL，再跑 Presto。为此，EMR 在这 做了改进可以不必事先启动 个 Spark 任务。

在查询性能 ，开源的 Delta 乎没有任何优化。

Delta 在数据 merge 性能不如 Hudi，在查询 性能不如 Iceberg，是不是意味着 Delta 是处了呢？其实不然。Delta 的 优点就是与 Spark 的整合能 ，尤其是其流批 体的设计，配合 multi-hop 的 data pipeline，可以 持分析、Machine learning、CDC 等多种场景。使 灵活、场景 持完善是它相 Hudi 和 Iceberg 的最 优点。另外，Delta 号称是 Lambda 架构、Kappa 架构的改进版， 需关 流批， 需关 架构。这 点上 Hudi 和 Iceberg 是 所不及的。

三个引擎的初衷场景并不完全相同，Hudi 为了 incremental 的 upserts，Iceberg 定位于 性能的分析与可靠的数据管理，Delta 定位于流批 体的数据处理。这种场景的不同也造成了三者在设计上的差别。尤其是 Hudi，其设计与另外两个相 差别更为明显。

Delta、Hudi、Iceberg三个开源项 中，Delta和Hudi跟Spark的代码深度绑定，尤其是写 路径。这两个项 设计之初，都基本上把Spark作为他们的默认计算引擎了。 Apache Iceberg的 向 常坚定，宗旨就是要做 个通 化设计的Table Format。

Iceberg完美的解耦了计算引擎和底下的存储系统，便于多样化计算引擎和 件格式，很好的完成了数据湖架构中的Table Format这 层的实现，因此也更容易成为Table Format层的开源事实标准。另 ，Apache Iceberg也在朝着流批 体的数据存储层发展，manifest和snapshot的设计，有效地隔离不同transaction的变更， 常 便批处理和增量计算。并且，Apache Flink已经是 个流批 体的计算引擎， 者都可以完美匹配，合 打造流批 体的数据湖架构。

Apache Iceberg这个项 背后的社区资源 常丰富。在国外，Netflix、Apple、Linkedin、Adobe等公司都有PB级别的 产数据运 在Apache Iceberg上；在国内，腾讯这样的巨头也有 常庞 的数据跑在Apache Iceberg之上，最 的业务每天有 T的增量数据写 。

‍

数据仓库的定义？

首先，用于支持决策，面向分析型数据处理；其次，对多个异构的数据源有效集成，集成后按照主题进行重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。

数据仓库(Data Warehouse)是一个面向主题的(subject oriented)、集成的(integrated)、相对稳定的(non-volatile)、反应历史变化(time variant)的数据集合，用于支持管理决策(decision making support)。

数据仓库和数据库的区别？

从目标、用途、设计来说

数据库是面向事物处理的，数据是由日常的业务产生的，常更新；数据仓库是面向主题的，数据来源多样，经过一定的规则转换得到，用来分析。数据库一般用来存储当前事务性数据，如交易数据；数据仓库一般存储的历史数据。数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入；数据仓库的设计一般不符合三范式，有利于查询

如何构建数据仓库？

数仓模型的选择是灵活的，不局限于某种模型方法。

数仓数据是灵活的，以实际需求场景为导向。

数仓设计要兼顾灵活性、可扩展性，要考虑技术可靠性和实现成本。

系统分析，确定主题。通过与业务部门的交流，了解建立数仓要解决的问题，确认各个主题下的查询分析要求选择满足数据仓库系统要求的软件平台。选择合适的软件平台，包括数据库、建模工具、分析工具等建立数据仓库的逻辑模型。确定建立数据仓库逻辑模型的基本方法，基于主题视图，把主题视图中的数据定义转到逻辑数据模型中逻辑数据模型转换为数据仓库数据模型数据仓库数据模型优化。随着需求和数据量的变化进行调整数据清洗转换和传输。业务系统中的数据加载到数据仓库之前，必须进行数据的清洗和转换，保证数据仓库中数据的一致性。开发数据仓库的分析应用。满足业务部门对数据进行分析的需求。数据仓库的管理。包括数据库管理和元数据管理。

什么是数据中台？

数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台吧数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。

这些服务和企业的业务有较强的关联性，是企业所独有且能复用的，它是企业业务和数据的积淀，其不仅能降低重复建设，减少烟囱式协作的成本，也是差异化竞争的优势所在。

数据中台通过整合公司开发工具、打通全域数据、让数据持续为业务赋能，实现数据平台化、数据服务化和数据价值化。数据中台更加侧重于“复用”与“业务”。

数据中台、数据仓库、大数据平台的关键区别是什么？

基础能力上的区别

数据平台：提供的是计算和存储能力

数据仓库：利用数据平台提供的计算和存储能力，在一套方法论指导下建设的一整套的数据表

数据中台：包含了数据平台和数据仓库的所有内容，将其打包，并且以更加整合以及更加产品化的方式对外提供服务和价值。

业务能力上的区别

数据平台：为业务提供数据主要方式是提供数据集

数据仓库：相对具体的功能概念是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表

数据中台：企业级的逻辑概念，提现企业数据产生价值的能力，为业务提供服务的主要方式是数据API

总的来说，数据中台距离业务更近，数据复用能力更强，能为业务提供速度更快的服务。数据中台是在数据仓库和数据平台的基础上，将数据生产为一个个数据API服务，以更高效的方式提供给业务。数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

大数据的一些相关系统？

数仓设计中心：按照主题域、业务过程，分层的设计方式，以维度建模作为基本理论依据，按照维度、度量设计模型，确保模型、字段有统一的命名规范

数据资产中心：梳理数据资产，基于数据血缘，数据的访问热度，做成本的治理

数据质量中心：通过丰富的稽查监控系统，对数据进行事后校验，确保问题数据第一时间被发现，避免下游的无效计算，分析数据的影响范围。

指标系统：管理指标的业务口径、计算逻辑和数据来源，通过流程化的方式，建立从指标需求、指标开发、指标发布的全套协作流程。

数据地图：提供元数据的快速索引，数据字典、数据血缘、数据特征信息的查询，相当于元数据中心的门户。

如何建设数据中台？

数据中台在企业落地实践时，结合技术、产品、数据、服务、运营等方面，逐步开展相关工作。

理现状。了解业务现状、数据现状、IT现状、现有的组织架构定架构。确认业务架构、技术架构、应用架构、组织架构建资产。建立贴近数据层、统一数仓层、标签数据层、应用数据层用数据。对数据进行输出、应用。数据运营。持续运营、持续迭代。

中台建设需要有全员共识，由管理层从上往下推进，由技术和业务人员去执行和落地是一个漫长的过程，在实施数据中台时，最困难的地方就是需要有人推动。

数据湖的理解？

数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。

数仓最重要的是什么？

个人认为是数据集成。

企业的数据通常是存储在多个异构数据库中的，要进行分析，必须先要对数据进行一致性整合。

集成整合后才可以对数据进行分析、挖掘数据潜在的价值。

概念数据模型、逻辑数据模型、物理数据模型

概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。

概念数据模型CDM

概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，以数据类的方式描述企业级的数据需求。

概念数据模型的内容包括重要的实体与实体之间的关系。在概念数据模型中不包含实体的属性，也不包含定义实体的主键

概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系

逻辑数据模型LDM

逻辑数据模型反应的是系统分析设计人员对数据存储的观点，是对概念数据模型的进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项以及业务对象之间关系的基本蓝图。

逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。

逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑在物理上如何实现。

物理数据模型PDM

物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。

物理数据模型的内容包括确定所有的表和列，定义外键用于确认表之间的关系，基于用户的需求可能要进行反范式化等内容。

SCD的常用处理方式？

slowly changing dimensions缓慢变化维度

不记录历史变化信息添加列来记录历史变化新插入数据行，并添加对应标识字段来记录历史数据。拉链表。

元数据的理解？

狭义来讲就是用来描述数据的数据

广义来看，除了业务逻辑直接读写处理的业务数据，所有其他用来维护整个系统运转所需要的数据，都可以较为元数据。

定义：元数据metadata是关于数据的数据。在数仓系统中，元数据可以帮助数据仓库管理员和数据仓库开发人员方便的找到他们所关心的数据；元数据是描述数据仓库内部数据的结构和建立方法的数据。按照用途可分为：技术元数据、业务元数据。

技术元数据

存储关于数据仓库技术细节的数据，用于开发和管理数据仓库使用的数据

数据仓库结构的描述，包括数据模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容业务系统、数据仓库和数据集市的体系结构和模式由 *** 作环境到数据仓库环境的映射，包括元数据和他们的内容、数据提取、转换规则和数据刷新规则、权限等。

业务元数据

从业务角度描述了数据仓库中的数据，他提供了介于使用者和实际系统之间的语义层，使不懂计算机技术的业务人员也能读懂数仓中的数据。

企业概念模型：表示企业数据模型的高层信息。整个企业业务概念和相互关系。以这个企业模型为基础，不懂sql的人也能做到心中有数多维数据模型。告诉业务分析人员在数据集市中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。业务概念模型和物理数据之间的依赖。业务视图和实际数仓的表、字段、维的对应关系也应该在元数据知识库中有所体现。

元数据管理系统？

元数据管理往往容易被忽视，但是元数据管理是不可或缺的。一方面元数据为数据需求方提供了完整的数仓使用文档，帮助他们能自主快速的获取数据；另一方面数仓团队可以从日常的数据解释中解脱出来，无论是对后期的迭代更新还是维护，都有很大的好处。元数据管理可以让数据仓库的应用和维护更加的高效。

元数据管理功能

数据地图：以拓扑图的形式对数据系统的各类数据实体、数据处理过程元数据进行分层次的图形化展示，并通过不同层次的图形展现。元数据分析：血缘分析、影响分析、实体关联分析、实体差异分析、指标一致性分析。辅助应用优化：结合元数据分析功能，可以对数据系统的应用进行优化。辅助安全管理：采用合理的安全管理机制来保障系统的数据安全；对数据系统的数据访问和功能使用进行有效监控。基于元数据的开发管理：通过元数据管理系统规范日常开发的工作流程

元数据管理标准

对于相对简单的环境，按照通用的元数据管理标准建立一个集中式的元数据知识库

对于比较复杂的环境，分别建立各部分的元数据管理系统，形成分布式元数据知识库，然后通过建立标准的元数据交换格式，实现元数据的集成管理。

数仓如何确定主题域？

主题

主题是在较高层次上将数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对企业中某一宏观分析领域所涉及的分析对象。

面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。

主题是根据分析的要求来确定的。

主题域

从数据角度看（集合论）

主题语通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域。主题域的确定由最终用户和数仓设计人员共同完成。

从需要建设的数仓主题看（边界论）

主题域是对某个主题进行分析后确定的主题的边界。

数仓建设过程中，需要对主题进行分析，确定主题所涉及到的表、字段、维度等界限。

确定主题内容

数仓主题定义好以后，数仓中的逻辑模型也就基本成形了，需要在主题的逻辑关系中列出属性和系统相关行为。此阶段需要定义好数据仓库的存储结构，向主题模型中添加所需要的信息和能充分代表主题的属性组。

如何控制数据质量？

校验机制，每天进行数据量的比对 select count()，早发现，早修复

数据内容的比对，抽样比对

复盘、每月做一次全量

如何做数据治理？

数据治理不仅需要完善的保障机制，还需要理解具体的治理内容，比如数据应该怎么进行规范，元数据该怎么来管理，每个过程需要那些系统或者工具来配合？

数据治理领域包括但不限于以下内容：数据标准、元数据、数据模型、数据分布、数据存储、数据交换、数据声明周期管理、数据质量、数据安全以及数据共享服务。

模型设计的思路？业务驱动？数据驱动？

构建数据仓库有两种方式：自上而下、自下而上

Bill Inmon推崇自上而下的方式，一个企业建立唯一的数据中心，数据是经过整合、清洗、去掉脏数据、标准的、能够提供统一的视图。要从整个企业的环境入手，建立数据仓库，要做很全面的设计。偏数据驱动

Ralph Kimball推崇自下而上的方式，认为数据仓库应该按照实际的应用需求，架子啊需要的数据，不需要的数据不要加载到数据仓库中。这种方式建设周期短，用户能很快看到结果。偏业务驱动

数据质量管理

数据质量管理是对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的数据质量问题，进行识别、度量、监控、预警等，通过改善了提高组织的管理水平使数据质量进一步提高。

数据质量管理是一个集方法论、技术、业务和管理为一体的解决方案。放过有效的数据质量控制手段，进行数据的管理和控制，消除数据质量问题，从而提高企业数据变现的能力。

会遇到的数据质量问题：数据真实性、数据准确性、数据一致性、数据完整性、数据唯一性、数据关联性、数据及时性

什么是数据模型？

数据模型就是数据组织和存储的方法，通过抽象的实体以及实体间联系的形式来表达现实世界中事务的相互关系的一种映射，他强调从业务、数据存取和使用角度合理的存储数据。

为什么需要数据仓库建模？

数仓建模需要按照一定的数据模型，对整个企业的数据进行采集，整理，提供跨部门、完全一致的报表数据。

合适的数据模型，对于大数据处理来讲，可以获得得更好的性能、成本、效率和质量。良好的模型可以帮助我们快速查询数据，减少不必要的数据冗余，提高用户的使用效率。

数据建模进行全方面的业务梳理，改进业务流程，消灭信息孤岛，更好的推进数仓系统的建设。

OLAP和OLTP的模型方法的选择？

OLTP系统是 *** 作事物型系统，主要数据 *** 作是随机读写，主要采用满足3NF的实体关系模型存储数据，在事物处理中解决数据的冗余和一致性问题。

OLAP系统是分析型系统，主要数据 *** 作是批量读写，不需要关注事务处理的一致性，主要关注数据的整合，以及复杂大数据量的查询和处理的性能。

3范式

每个属性值唯一，不具有多义性

每个非主属性必须完全依赖于整个主键，而非主键的一部分

每个非主属性不能依赖于其他关系中的属性

数据仓库建模方法？

有四种模型：ER模型、维度模型、Data Vault模型、Anchor模型。用的较多的是维度模型和ER模型。

ER模型

ER模型用实体关系模型描述企业业务，在范式理论上满足3NF。数仓中的3NF是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。

采用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据按照主题进行相似性整合，并进行一致性处理。

ER模型特点：

需要全方位了解企业业务数据

实施周期较长

对建模人员要求教高

维度建模

维度建模按照事实表和维度表来构建数仓。

维度建模从分析决策的需求出发构建模型，为分析需求服务。重点关注用户如何快速的完成数据分析，可以直观的反应业务模型中的业务问题，需要大量的数据预处理、数据冗余，有较好的大规模复杂查询的响应性能。

事实表

发生在现实世界中的 *** 作性事件，其产生的可度量数值，存储在事实表中。从最细粒度级别来看，事实表的一行对应一个度量事件。事实表表示对分析主题的度量。

事实表中包含了与各个维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数不断增加，表数据量迅速增长。

维度表

维度表示分析数据时所用的环境。

每个维度表都包含单独的主键列。维度表行的描述环境应该与事实表行完全对应。维度表通常比较宽，是扁平型的非规范表，包含大量的低粒度的文本属性。

注意：

事实表的设计是以能够正确记录历史信息为准则

维度表的设计是以能够以合适的角度来聚合主题内容为准则

维度建模的三种模式

星形模型：以事实表为中心，所有的维度直接连接在事实表上。由一个事实表和一组维度表组成。

雪花模型：是对星形模型的扩展。雪花模型的维度表可以拥有更细的维度，比星形更规范一点。维护成本较高，且查询是要关联多层维表，性能较低

星座模型：基于多张事实表，多张事实表共享维度信息

维度建模步骤：

选择业务过程

选择粒度

选定事实表

选择维度

事实表的类型？

事实表有：事务事实表、周期快照事实表、累积快照事实表、非事实事实表

事务事实表

事务事实表记录的是事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务记录一条记录。

周期快照事实表

以具有规律性的、可预见的时间间隔来记录事实。它统计的是间隔周期内的度量统计，每个时间段一条记录，是在事务事实表之上建立的聚集表。

累积快照事实表

累积快照表记录的不确定的周期的数据。代表的是完全覆盖一个事务或产品的生命周期的时间跨度，通常具有多个日期字段，用来记录整个生命周期中的关键时间点。

非事实型事实表

在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文一般翻译为“非事实型事实表”。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。

第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。

事实表中通常要保留度量事实和多个维度外键，度量事实是事实表的关键所在。

非事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或说明某些活动的范围。

第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。

数仓架构为什么要分层

分层可以清晰数据结构，使用时更好的定位和理解方便追踪数据的血缘关系规范数据分层，可以开发一些通用的中间层数据，能够减少极大的重复计算把复杂问题简单化屏蔽原始数据的异常。不必改一次业务就重新接入数据

数据分层思想？

理论上数据分为： *** 作数据层、数据仓库层、数据服务层。可根据需要添加新的层次，满足不同的业务需求。

*** 作数据层ODS

Operate Data Store *** 作数据存储。数据源中的数据经过ETL后装入ODS层。

ODS层数据的来源一般有：业务数据库、日志、抓取等。

数据仓库层DW

根据ODS层中的数据按照主题建立各种数据模型。

DW通常有：DWD、DWB、DWS

DWD: data warehouse detail细节数据层，是业务层和数据仓库的隔离层。

DWB: data warehouse base基础数据层，存储的是客观数据，一般用作于中间层。

DWS: data warehouse service服务数据层，整合汇总分析某个主题域的服务数据。一般是大宽表。

数据服务层/应用层ADS

该层主要提供数据产品和数据分析使用的数据，一般会放在ES、Mysql系统中供线上系统使用

数仓架构进化

经典数仓架构：使用传统工具来建设数仓

离线大数据架构：开始使用大数据工具来替代经典数仓中的传统工具

Lambda架构：在离线大数据架构的基础上，使用流处理技术直接完成实时性较高的指标计算

Kappa：实时处理变成了主要的部分，出现了以实时处理为核心的kappa架构

离线大数据架构

数据源通过离线的方式导入离线数仓中。下游应用根据业务需求选择获取数据的方式

Lambda架构

在离线数仓的基础上增加了实时计算的链路，并对数据源进行流式改造，实时计算去订阅消息队列，并推送到下游的数据服务中去。

Lambda架构问题：同样的需求需要开发两套一样的代码；资源占用增多

Kappa架构

kappa架构可以认为是lambda架构的简化版，移除了lambda架构中的批处理部分。

在kappa架构中，需求修改或者历史数据重新处理都通过上游重放完成

kappa架构最大的问题是流式重新处理历史数据的吞吐能力会低于批处理，但可以通过增加计算资源来弥补

总结

真实场景中，是lambda架构和kappa架构的混合。大部分实时指标通过kappa架构计算，少量关键指标用lambda架构批量计算

随着数据多样性的发展，数据库这种提前规定schema的模式显得力不从心。这时出现了数据湖技术，把原始数据全部缓存到某个大数据存储上，后续分析时根据需求去解析原始数据。简单来说，数据仓库模式是schema on write，数据湖模式是schema on read

OLAP简介

OLAP（On-line Analytical Processing），联机分析处理，其主要的功能在于方便大规模数据分析及统计计算，对决策提供参考和支持。

特点：数据量大、高速响应、灵活交互、多维分析

OLAP分类

存储类型分类

ROLAP（RelationalOLAP）

MOLAP（MultimensionalOLAP）

HOLAP（HybridOLAP）

处理类型分类

MPP架构

搜索引擎架构

预处理架构

开源OLAP解决方案

Persto、SparkSQL、Impala等MPP架构和ROLAP的引擎Druid和Kylin等预处理架构和MOLAP的引擎ES这种搜索引擎架构ClickHouse及IndexR这种列式数据库

OLAP引擎

Presto

Facebook开发的分布式大数据SQL查询引擎，专门进行快速数据分析

特点

可以将多个数据源的数据进行合并，可以跨越整个组织进行分析直接从HDFS读取数据，在使用前不需要大量的ETL *** 作

查询原理

完全基于内存的并行计算

流水线

本地化计算

动态编译执行计划

小心使用内存和数据结构

类BlinkDB的近似查询

GC控制

Druid

Druid是一个用于实时查询和分析的分布式实时处理系统，主要用于广告分析，互联网广告监控、度量和网络监控

特点

快速的交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内可被查询到。高可用性——Druid的数据在系统更新时依然可用，规模的扩大和缩小都不会造成数据丢失；可扩展——Druid已实现每天能够处理数十亿事件和TB级数据。为分析而设计——Druid是为OLAP工作流的探索性分析而构建，它支持各种过滤、聚合和查询

应用场景

需要实时查询分析具有大量数据时，如每天数亿事件的新增、每天数10T数据的增加；需要一个高可用、高容错、高性能数据库时。需要交互式聚合和快速探究大量数据时

Kylin

Kylin是提供与Hadoop之上的SQL查询接口及多维分析能力以支持超大规模数据

数据治理工程师是负责设计、开发和维护数据治理系统的工程师。数据治理是指对企业内部的数据进行管理、控制和保护的过程，包括数据的获取、存储、处理、分发、使用和保护等。

数据治理工程师的工作职责包括：

负责设计和开发数据治理系统，包括数据库、数据仓库、数据湖等。

负责维护数据治理系统，包括升级系统、修复漏洞、更新数据等。

负责制定数据治理政策，包括数据获取、存储、处理、分发、使用和保护的规则。

负责监控数据治理系统的运行情况，及时发现并解决问题。

负责与各部门协调，确保数据治理系统的正常运行。

负责与数据湖、数据仓库、数据库等相关的技术团队协作，确保数据治理系统的高效运行。

数据治理工程师需要具备良好的沟通能力、团队协作能力和分析问题解决问题的能力，同时还需要熟悉数

数据治理工程师还需要熟悉数据库技术和数据治理相关的工具和方法，例如 SQL、ETL、数据湖和数据仓库等。此外，数据治理工程师还需要熟悉数据治理相关的法律法规和标准，例如《个人信息保护法》、《数据安全标准》等。

数据治理工程师的职业前景良好，随着信息化建设的不断深入，数据治理的重要性也在不断提高。许多企业都需要建立数据治理体系，因此数据治理工程师的需求也在不断增加。此外，数据治理工程师还可以通过不断学习新技术和知识，提升自己的专业能力，为职业发展打下坚实的基础。

中国最大的数据库在北京昌平中国石油科技交流中心。

北京昌平梦想云平台统一数据湖已管理48万口井、600个油气藏、7000个地震工区、4万座站库，共计17PB、横跨60多年的数据资产，涵盖6大领域、15个专业，实现上游业务核心数据全面入湖共享，形成了国内最大的勘探开发数据湖。

以上就是关于“数据湖三剑客”Hudi、Delta Lake和Iceberg 深度对比全部的内容，包括:“数据湖三剑客”Hudi、Delta Lake和Iceberg 深度对比、大数据和大数据开发有什么区别、数据治理工程师是干嘛的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！