Delta Lake - 数据湖的数据可靠性

今天笔者将分享一位大神关于 Delta Lake 的演讲内容。这位是 Apache Spark 的 committer 和 PMC 成员，也是 Spark SQL 的最初创建者，目前领导 Databricks 团队，设计和构建 Structured Streaming 和 Databricks Delta，技术涉及分布式系统、大规模结构化存储和查询优化等方面。

这位大神就是 Michael Armbrust。

Delta Lake 回顾

前面的文章对于 Delta Lake 介绍很多，为了方便新的读者更快了解项目，这里简要说明：

Delta Lake 是一个开源的存储层，为数据湖带来了可靠性。Delta Lake 提供了ACID事务、可伸缩的元数据处理以及统一的流和批数据处理。它运行在现有的数据湖之上，与 Apache Spark API完全兼容。

因为 Michael 的演讲视频我也是粗略听过，到现在也忘记差不多了。不过，根据 slides 的内容，我尽量串起来，让读者明白。

笔者的注解基本都在每个 slide 的下方，为了让读者先查看 slides 内容，思考一番，然后再查看笔者的解读。

抛出问题

很多企业使用 Apache Spark 将各种数据导入到数据湖（data lake）中，在这个过程会花费很多money。

但是至少数据都进到数据湖，是不是看起来很美好。

然后渴望使用 Apache Spark 基于数据湖存储的海量数据进行数据科学分析和机器学习（ML）。

开始干活了，是不是真的很美好。

OMG，出问题了，一堆数据大部分都是不可靠的，导致大部分项目都失败了。这是因为数据科学分析和机器学习对数据质量要求非常高。

看来，美好只是想想而已，别当真。

数据湖的模样

那么，你期望的数据湖是什么样子的？

• 可能是收集所有的数据，比如客户数据、视频/语音、点击流、传感器数据等
• 不是传统的 RDBMS，不需要提前设置 Schema
• 基于数据湖进行科学分析和机器学习，用于推荐引擎、风险/欺诈检测、IoT等

但是问题是，通常你的数据是 garbage（不要惊讶，没分析之前的确是），也就是数据湖里面存储的都是 garbage，所以 garbage out 给推荐引擎的都是无用数据，导致输出没有意义的结果。

那么一个典型的数据湖项目看起来是什么样子呢？如果不太清楚，就继续看。

一天 boss 跑过来说，兄dei，所有数据都进到 Kafka，现在要出需求了，两个任务，一个是 Streaming Analytics，实时查看 Business 运行情况等；另外一个任务是进行更加复杂的 AI 和 Reporting 分析，查看更多指标的洞察报告。

那我们如何做，怎么开始呢？

OK，引入 Apache Spark，因为 Spark API 可以消费 Kafka 数据，然后进行基于 DataFrame 和 DataSet 对数据进行各种计算包括实时窗口聚合操作，可以实时分析商业业务指标，但是有没有发现，很难处理以前历史数据，比如一年前的数据分析，以及更新的历史数据情况。

上面就是我们遇到的一个 Challenge #1: Historical Queries?

针对上面的问题，所以要把 Kafka 数据导入数据湖，保留历史，以备 boss 不时之需。其实上图就是典型的 lambda 架构，这样就可以解决实时和历史数据查询的问题。

但是我们又发现了另外一个问题：散乱的数据，Challenge #2: Messy Data?

如上图所示，我们需要启动额外的 Spark Jobs 来检查数据质量，如果出问题要及时告警，方便及时修复，即上图中加入 Validation 可以解决问题。

加入 Validation 校验数据质量功能后，的确很棒，又会带来新的问题，Challenge #3: Mistakes and Failures?

有时可能会丢失什么，数据一旦存储在数据湖中，那么怎么修复呢，可能需要不停的调整，根据时间、区域等创建分区目录等，进行计算，如果错误的话，删除分区目录，再重新处理。

上面引入 Reprocessing 框架，就需要更新数据，涉及 Challenge #4: Updates?

更新就要考虑事务，多版本等等一系列情况。

本来你就想静静地做个 Reporting、ML等，终将你会入坑，徘徊在以下几个问题当中：

• Wasting Time & Money
• Solving Systems Problems
• Instead of Extracting Value From Data

• 没有原子性意味着失败的生产作业会使数据处于损坏状态，需要繁琐的恢复操作
• 没有质量强制执行会产生不一致和不可用的数据
• 没有一致性/隔离性，就基本不可能混合追加和读取、批处理和流处理

到此，遇到的问题一堆，于是提出解决方案 Delta Lake。

Delta Lake 解决方案

回顾一下，我们在上面构建的整个系统，融入各种解决方案的数据湖，是不是有点复杂而且杂乱。

Delta Lake 将上面的整体解决方案转变为下图的解决方案。

是不是觉得柳暗花明又一村，现在你只需要关注 data flow。

这里，笔者把三个 slides 都放在一起了，Delta Lake 带来了几个关键的特性：

• 支持 ACID 事务
• 开放标准、开放源码(Apache License)，存储 PB 级的数据。不断增长的社区包括 Presto, Spark 等
• Apache Spark 支持，流批统一

Delta Lake 提供了一种工具，可以增量地提高数据质量，直到可以被有意义地消费。在 Delta Lake 中，数据被划分成了三个数据质量逻辑层次：

• Bronze
• Silver
• Gold

下面会依次介绍功能和作用。

Bronze 层主要用于存储原始数据，即所谓的 Raw Data 。Delta Lake是一个数据湖存储引擎，可以支持各种各样的数据接入，这些数据源可能是 Kafka、Kinesis、Spark 或者是其他数据湖，这些数据接入 Delta Lake 之后就存储在Bronze 层，Bronze 层可以为大数据常用的分布式存储 HDFS 或其他存储，这也保证了数据湖中数据存储的可扩展性。

Silver 层主要用于存储经过初步处理（解析 Json格式、增加 Schema、过滤、清理、Join等）的数据。存储 Silver 中间数据主要有两方面好处：

• 对企业的很多人来说有价值，数据共享
• 这些中间数据可查询，便于调试

Gold 层可以直接用来消费，可以给业务层直接使用，这些数据是处理后的可以被 ML 或 Tableau 等使用。可以使用 Spark 或者 Presto 在Gold层上直接做展现，或者在这些数据上做数据挖掘。

其实就是 Streams，数据流，通过 Delta Lake 增量地在不同层传送数据。

可能有的人说我不需要实时数据，我的报表每小时、每天或每月运行一次。但是 Streaming 并不是总是指低延时（low latency），而是关于持续增量地处理数据，不用去管什么数据是新的，哪些数据是旧的，已经处理哪些数据，如何从失败中恢复等，Streaming 考虑了这一切。Delta Lake 当然也支持批处理作业和标准的 DML。

最后，介绍一个比较酷的模式，recomputation，重新计算。因为我们在初始的 Bronze 存储了所有 Raw Data ，使用 Streaming 处理这些数据。如果发现代码存在 bug 或者存在一些未曾发觉的新需求，需要加入到分析系统，我们需要做的就是清理表的数据、清理掉 Checkpoint 并重启 Streaming。

广告时间

直接看，没有什么补充的。

如何使用 Delta Lake

这一块内容，笔者在之前的文章中，非常详细地实战过，这里的确不太适合再说。

数据质量

这里创建了一张 warehouse 的表，定义一些属性，包括存储路径、Schema等。

其实这里更关注的是特性是 expect，定义对数据质量的要求。关于数据质量这一块，大数据行业也是一直比较关注的，开源的产品也有几个，比如 Apache Griffin 等。

Delta Lake 数据质量，以后笔者会单独细说。

Delta Lake 如何工作

这部分 slides 的内容，笔者都曾带领大家详细的研究和实战过，这里为了该演讲内容的完整性，都带上。

存储可以有HDFS、S3 或其他 BlobStore 等。

数据表由一系列操作集合的数据信息组成的结果。

Roadmap

这个Roadmap有点老了，截至目前，Delta Lake 发布的版本为 0.4.0，支持：

• Python APIs for DML and utility operations You can now use Python APIs to update/delete/merge data in Delta Lake tables and to run utility operations (i.e., vacuum, history) on them.
• Convert-to-Delta You can now convert a Parquet table in place to a Delta Lake table without rewriting any of the data. This is great for converting very large Parquet tables which would be costly to rewrite as a Delta table. Furthermore, this process is reversible - you can convert a Parquet table to Delta Lake table, operate on it (e.g., delete or merge), and easily convert it back to a Parquet table.
• SQL for utility operations You can now use SQL to run utility operations vacuum and history.

到此，Michael 演讲的内容比较详细地过了一遍，大家慢慢消化。