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源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。