以hadoop 作为基础生态，从0到进行数仓建设，主要分为基础篇和实战篇两部分，基础篇主要是各种组件的学习和案例，实战篇主要是三家企业的数仓设计案例，最后是扩展篇主要是实时数仓。

Delta Lake与实时计算前面我们已经花了大量的篇幅在介绍Delta Lake，而且我们介绍了多种场景中去使用Delta Lake，你可以参考下面的文章Spark SQL Scala版 使用 Delta LakeSpark SQL Shell 版 使用Delta LakeSpark SQL SQL 版 使用 Delta LakeSpark SQL Python版 使用 Delta LakeSpark Streaming 使用 Delta Lake今天我们来看一下Delta Lake 对

Delta Lake 最佳实践这一节我们看一下关于Delta Lake的最佳实践选择合适的分区字段可以按列对Delta表进行分区。最常用的分区列是date。遵循以下两条经验法则来决定分区依据的列：如果列的基数非常高，则不要将该列用于分区。例如，如果按列userId进行分区，并且可以有1M个不同的用户id，那么这是一种糟糕的分区策略。每个分区中的数据量：如果希望分区中的数据至少为1GB，则可以按列进行分区。整理文件如果你不断地向Delta表写入数据，随着时间的推移，它会积累大量的文件，尤其是

Delta Lake 并发控制Delta Lake 提供了读写之间ACID 的语义保证，这意味着：对于支持的存储系统，跨多个集群的多个写入可以同时修改表分区并查看表的一致快照视图，并且这些写入有串行顺序。读取可以继续看到 Apache Spark 作业开始时使用的表的一致快照视图，即使在作业期间修改了表也是如此。乐观并发控制Delta Lake 使用乐观并发控制来提供写入之间的事务保证。 在这种机制下，写操作分为三个阶段：读取：读取（如果需要）表的最新可用版本，以确定哪些文件需要修改（即

Delta Lake Schema 约束与演化随着业务问题和需求的发展，数据的结构也在不断变化。在 Delta Lake 中，合并新的列或对象是很容易的，用户可以访问简单的语义来控制其表的 Schema。同时，重要的是要强调 Schema 约束的重要性，以防止用户在 Schema 演变过程中意外地用错误或垃圾数据污染他们的表，这使他们能够自动添加新的数据列。Schema 约束（Schema Enforcement）拒绝任何不兼容表的新增和修改操作。通过设置和维护这些更高的标准，分析师和工程师可以相信他们

Delta Lake 1.0 版本功能预览在本博客中，我们回顾了迄今为止发布的主要功能让我们首先从什么是 Delta Lake 开始。 Delta Lake 是一个开源项目，可以在您现有的存储系统（如 S3、ADLS、GCS 和 HDFS）之上构建 Lakehouse 架构。 Delta Lake 的特性提高了处理云存储对象中数据的可管理性和性能，并启用了结合数据仓库和数据湖关键特性的湖库范式：标准 DBMS 管理功能可用于低成本对象存储。 Delta Lake 与数据质量框架一起使用 ACID 事务

Delta Lake DML 内部原理读者交流群已经开通了，有需要的可以私信进入读者交流群Delta Lake 支持 DML（数据操作语言）命令，包括 DELETE、UPDATE 和 MERGE。 这些命令简化了变更数据的捕获 (CDC)、审计和治理以及 GDPR/CCPA 工作流等。在这篇博文中，我们将演示如何使用这些 DML 命令，以及当运行一个命令时 Delta Lake 在幕后所做的事情，并为这些命令提供一些性能调优技巧。简单复习首先，让我们快速回顾一下 Delta Lake 表是如何

Delta Lake 版本管理前面我们在学习Delta Lake 时间旅行的时候已经提到过这个版本管理了，但是我们没有深入探究，其实版本管理这个概念并不陌生，我们知道我们用的git 就是一个开源的分布式版本控制系统,还有就是我们的业务系统数据库也经常做按照时间的快照备份，其实这也是版本的一种。Delta Lake 版本管理与时间旅行Delta Lake 版本管理的原理也是Delta Lake 实现时间旅行的原因，Delta Lake 的时间旅行，其实就是版本切换，不同的是它不光提供了根据版本号切换的功

Delta Lake 时间旅行读者交流群已经开通了，有需要的可以私信进入读者交流群听到时间旅行，你是不是觉得很高大上，既然如此高大上，我们就来看看,时间旅行其实就是可以读取历史数据，或者说是历史上某一个版本的数据，这里的版本你也可以认为是历史上某一时刻的快照，其实这就是时间旅行。数据版本Delta Lake 允许用户读取表或目录之前的快照。当文件被修改文件时，Delta Lake 会创建较新版本的文件并保留旧版本的文件。当用户想要读取旧版本的表或目录时，可以在 Apache Spark 的读取

Delta Lake 事务日志实践读者交流群已经开通了，有需要的可以私信进入读者交流群前面我们介绍了Delta Lake 事务日志,具体你可以参考Delta Lake 事务日志,今天我们就借助实际操作，来看一下Delta Lake 事务日志，这里我们使用scala api 来操作环境准备scala 版本 2.12.10spark 版本 3.1.2启动命令:spark-shell --packages io.delta:delta-core_2.12:1.0.0 --conf "spark

- 事务日志是什么，它是如何构造的，以及提交如何作为文件存储在磁盘上；- 事务日志如何作为一个单一的事实来源，允许 Delta Lake 实现原子性原则；- Delta Lake 如何计算每个表的状态——包括它如何使用事务日志来跟踪最近的检查点，以及它如何解决“小文件”问题；- 通过使用 Apache Spark 的强大功能来大规模处理元数据；- 使用乐观并发控制允许多个并发读和写，即使在表发生更改时也是如此；- Delta Lake 如何使用互斥来确保正确地线性（serialized）提交

Spark Streaming 使用 Delta Lake前面我们已经介绍了在各种环境中使用Delta Lake，你可以参考Spark SQL Scala版 使用 Delta LakeSpark SQL Shell 版 使用Delta LakeSpark SQL SQL 版 使用 Delta LakeSpark SQL Python版 使用 Delta Lake从前面的学习我们知道Delta Lake是完全兼容了Spark API, 而且我们希据数据湖是可以实现我们的离线计算和实时计算使用同

Python使用 Delta Lake今天我们看一下如何在Python 中使用 Delta Lake，毕竟现在很多人开发Spark任务是通过Python而不是scala,当然这也体现了Spark 生态的完善。当然我们还是要看一下版本的兼容情况Delta Lake versionApache Spark version1.0.x3.1.x0.7.x and 0.8.x3.0.xBelow 0.7.02.4.2 - 2.4.环境准备通过上面的表格，我们可以使用

Spark SQL SQL 版 使用 Delta Lake

Spark SQL Shell 版 使用Delta Lake前面我们学了项目工程中使用Delta Lake，但是很多时候我们在学习和实验阶段，都喜欢使用Spark shell ，所以这一节我们介绍一下如何在Spark shell 中使用Delta Lake。开始之前，我们还是强调一下版本的问题，虽然我们上次我们说过了半本的问题，但是还是有人来问，下面是版本的兼容性问题。Delta Lake versionApache Spark version1.0.x3.1.x0.7.x

Spark SQL 使用 Delta Lake前面我们介绍过了 Delta Lake可以解决我们数据更新和小文件合并的问题，我们知道数据湖三驾马车的特性如下：Iceberg 的设计初衷更倾向于定义一个标准、开放且通用的数据组织格式，同时屏蔽底层数据存储格式上的差异，向上提供统一的操作 API，使得不同的引擎可以通过其提供的 API 接入；Hudi 的设计初衷更像是为了解决流式数据的快速落地，并能够通过 upsert 语义进行延迟数据修正；Delta Lake 作为 Databricks 开源的项目

Delta lake 和数据湖Data lakes provide a complete and authoritative data store that can power data analytics, business intelligence, and machine learning数据湖提供了一个完整的、权威的数据存储，可以赋能数据分析、商业智能和机器学习。什么是数据湖泊A data lake is a central location that holds a large amoun

Delta Lake 概论开始之前请参考前面的文章数仓建模—实时数仓架构发展史数仓建模—数仓架构发展史数据存储层遇到的一些问题早先基于Hive的数仓或者传统的文件存储形式（比如Parquet/ORC）,都存在一些长期难以解决的问题：小文件的问题并发读写问题有限的更新支持海量元数据（例如分区）导致Hive metastore不堪重负细节展开的话，你会发现每一个问题又会引发众多应用场景层面的问题。比如并发读写还有更新问题让实时数仓的实现变得很困难。小文件问题需要我们自己写合并代码，并

数据湖再识前面我们说过用户需求驱动数据服务，一切新技术的诞生，时代都会赋予它特有的意义，当然数据湖也一样，数据湖作为大数据体系下的一员，时代又赋予了它什么样的意义呢？数据[仓库] 数据[湖]，既然都是数据存储的地方，又有什么不同呢 ? 下面我们将一一解答这个问题开始之前请先阅读数据湖初识,了解一下为什么会出现数据湖数据集成能力数据湖需要具备完善的数据获取和数据发布能力,相比数据仓库数据湖的要求更高数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数

近两年，为什么都开始谈论起 Data Lake 这个”新名词”了？先说我的想法，其实还是用户需求驱动数据服务，大家开始关注 Data Lake 的根本原因是用户需求发生了质变，过去的数据仓库模式以及涉及到的相关组件没有办法满足日益进步的用户需求。