SPARK+AI SUMMIT 2020中文精华版线上峰会带领你们一块儿回顾2020年的SPARK又产生了怎样的最佳实践，技术上取得了哪些突破，以及周边的生态发展。本文中Databricks开源组技术主管范文臣从数据工程师的角度出发向你们介绍Delta Lake。如下是视频内容精华整理。
原视频连接：https://developer.aliyun.com/live/43189?spm=a2c6h.12873639.0.0.4eca1a518KlgJ5
活动连接：SPARK中文峰会议题（三）｜听听砖厂和领英工程师说的吧
1、Delta Lake的诞生
相信做为一个数据工程师，心中都有这么一个理想的工具：git
能够持续不断地对各类各样的数据源进行增量处理；github
批流合一；web
处理速率高效，智能化生成报表；微信
······架构
想要实现上面的工具，一个最简单的办法就是先用一个Spark Streaming Job把各类各样的数据源写到一个表中，以下图，而后再根据业务需求选择是用流做业仍是批做业去进行相应的查询工做。可是，这种方式会存在一些问题，好比由于是流式写入，会产生大量的小文件，对后续的性能产生很大的影响。app
面对上面遇到的小文件问题，一个改进的方法以下图所示，是在上述方法中建立的表以后加一个批做业定时的将小文件合并起来，可是这个改进方法仍然有明显的缺点，那就是存在着小时级别的延迟，这种级别的延迟对于不少业务来说是没法知足要求的。工具
为了解决上述延迟问题，Lambda架构畅行一时。其架构思路以下图所示，简单说就是分别用流和批的方式对数据源处理两次，而后将批和流的视角合起来提供给后续业务。Lambda架构虽然解决了上述的问题，可是也存在自身的缺点：性能
由于业务逻辑在要用批和流的方式处理两次，而批和流的处理方式不一致，可能会致使某些问题；大数据
若是处理逻辑中加入了数据校验的工做，就须要在批和流上分别校验两次，一旦须要回滚等操做，数据修正也须要进行两次，费时费力；ui
若是涉及到Merge、Update等操做，也须要进行两次修改，使得整个事务变得复杂；
······
上面的几种方案都有本身的缺点，Lambda架构虽然看似有效可是架构过于复杂。那么，有没有一种方案能够将Lambda架构进行简化呢？其实，咱们的目标很简单，就是让流做业处理咱们的源数据，而且后续做业能够批流统一的处理，具体来讲有：
保证数据的一致性；
保证每次是增量的读取；
可以作回滚；
可以访问历史记录；
可以在不影响下游做业的同时合并小文件。
结合以上几点目标，有了目前的解决方案：Delta Lake + Structured Streaming = The Delta Architecture。这套方案的优势很明显，首先是批流合一的，其次Delta Lake能够很方便的作时间旅行相似的操做，且Delta Lake是单纯的储存层，与计算层分离，符合当前云数据计算的大方向，方便用户灵活的进行扩容。
2、Delta Lake的工做原理
Delta Lake的核心是其事务日志，它的表跟普通的表没有大的区别，可是在表下会创建一个隐藏文件，其中的JSON存储了一些关于事务的记录，以下图所示：
所以，在Delta Lake中，读取一张表也会重放这张表的历史记录，好比表的重命名、修改Schema等等操做。
更细节地来讲，在Delta Lake中的每一个JSON文件都是一次commit，这个commit是原子性的，保存了事务相关的详细记录。另外，Delta Lake还能够保证多个用户同时commit而不会产生冲突，它用的是一种基于乐观锁处理的方式，其逻辑以下图所示。这种解决冲突的方案适用于写比较少，读取比较多的场景，你们在使用的时候要注意场景是否适用。
假设咱们要处理一个很是大的表，有百万级别的文件，那么如何高效的处理元数据呢？Delta Lake的处理方案以下图所示，用Spark来读取事务日志，而后Delta Lake隔一段时间对commit作一次合并，以后能够从Checkpoint开始应用后续的commit。
总结起来，Delta Lake解决数据一致性、增量读取、历史回溯等问题的方案即为下图所示：
3、Demo
从如下连接你们能够看到详细的Demo展现，还有详细的社区版本（免费）Databricks的设置方法：https://github.com/delta-io/delta/tree/master/examples/tutorials/saiseu19 。
Demo中提供了Python API和Scala API的实现文件，你们能够根据本身的实际状况进行尝试。上面连接的Demo中展现的主要features有：
Schema Enforcement：在作Pipeline的时候咱们必定要保证数据质量，所以Schema Enforcement能够帮助咱们作到这点。
Schema Evolution：随着公司业务的发展，一开始的表结构可能不适用于当前的业务，Schema Evolution能够帮助咱们进行表结构的演化。
Delete from Delta Lake table：Delete操做能够控制表的无限制增加，而且经过事务日志来进行操做，实际上数据没有被删掉，只是在Log中进行了标记。
Audit Delta Lake Table History：经过此功能能够看到对表的详细历史操做。
Travel back in time：有了表的历史数据，咱们即可以访问表在各个历史节点的数据。
Vacuum old versions of Delta Lake tables：Delta Lake经过标记的方式来实现删除，随着时间的增加会占用大量储存空间，Vacuum操做将删除在必定时间内从表中删除的数据文件，实现物理删除，默认会保留七天内的数据。
Upsert into Delta Lake table using Merge：在一个命令中同时作update和insert操做。
上述Features的具体代码能够在Github中查看。
4、Q&A
Q1：Delta Lake能够线上使用吗？支持实时增删查改吗？
A1：Delta 最新发布了0.7.0，支持Spark 3.0。Databricks已经有不少客户在使用Delta Lake，其余公司也有在用，好比eBay。实时增删查改如demo演示的那样都是支持的。
Q2：是否能够纯SQL实现？
A2：Delta Lake是一个数据储存层，若是是与Hive等引擎作整合，只支持基本的SELECT/INSERT，没有支持DELETE等SQL操做，只能用Delta Lake本身的Scala或Python API。若是使用的是Spark 3.0的话，像MERGE、DELTE等都支持SQL AQI，能够直接用SQL开发。可是某些管理操做好比VACCUM没有对应的SQL API，仍是要用Delta Lake本身的Scala或Python API。
关键词：Databricks、Spark、Delta Lake、Schema Enforcement
阿里巴巴开源大数据技术团队成立Apache Spark中国技术社区，按期推送精彩案例，技术专家直播，问答区近万人Spark技术同窗在线提问答疑，只为营造纯粹的Spark氛围，欢迎钉钉扫码加入！
对开源大数据和感兴趣的同窗能够加小编微信（下图二维码，备注“进群”）进入技术交流微信群。
Apache Spark技术交流社区公众号，微信扫一扫关注
本文分享自微信公众号 - Delta Lake技术圈（deltalake-emr2020）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。