'DataBricks推出新一代開源大殺器Delta Lake，助力Spark一統天下'

DataBricks最近新開源了一個項目Delta Lake。這其實不算是個新項目了。DataBricks在其商業版裡面提供這樣的功能已經有一段時日了。對我來說Delta Lake就是久聞大名，但是不知道廬山真面目。

當然以DataBricks一貫的既要為人民服務，更要為人民幣服務的做法，開源出來的Delta Lake肯定不是其內部商業版的全部。但是即便如此也可以讓我們管中窺豹了。

文章分兩部分。第一部分介紹一下Delta Lake的一些情況，主要是基於：

https://youtu.be/whaV6bMaf5o

的內容。講課的小哥是DataBricks的大神Michael Armburst。他負責Structured Stream和Delta Lake。第二部分會給出我個人的一些看法。

圖中展示的是一個之前非常著名的lambda架構，簡單來說就是數據的一部分用批處理來獲取準確值，但是需要時間，另外一個pipeline用streaming的方式來獲取非精確但是及時的值。當然這張圖裡面是有點給Spark貼金了。標準Lambda出來的時候，流引擎主要是storm，而批處理引擎最常用的HIVE。當然作為DataBricks公司出品的PPT，這樣去寫也是可以理解的。

如上面的圖片，我基本上完整的保留了整個PPT。Delta Lake可以理解為一個文件存儲方式。它在一個目錄上同時存了transaction log和數據文件。並且它可以通過用spark處理transaction log來生成不同的checkpoint，和對應的數據文件。它同時也支持了事務處理。Delta Lake同時可以作為Streaming的Source和Sink，這無疑是很強有力的。

從一個做數據庫的人的角度來說，Delta Lake的實現機制上，沒有讓我覺得特別吃驚的先進技術，有的是數據庫系統幾十年內使用過的經典技術。但是沒有新技術不代表Delta Lake這個東西不好。Delta Lake這個東西解決的是問題很多之前BI和數倉，現在大數據應用裡必不可少的。從這個角度上來說，這個開源項目很有前途。

Delta Lake裡面很多的地方採用複用Spark的方式來處理Delta Lake的問題。比如說可以通過讀取transaction log來分析出哪些partion哪些文件是需要讀的，做Partition pruning。又比如說來做checkpoint。Partition pruning本身不是什麼新鮮技術。使用引擎自己去處理自身的想法，我在微軟做的時候也實現過一些類似的東西。但是大數據開源項目裡這應該是頭一遭。這是非常精細的想法。

這裡我需要補充一點我個人的經驗。要了解數據庫和大數據的動向，一定要時刻關注Michael Stonbraker的講話，論文等等。他雖然經常夾雜著很多個人的私貨，但是依然是數據庫圈子裡最有洞見的人。你所需要做的，就是區分哪些是私貨，哪些是真知灼見。

比如說2015年他來清華給了21世紀的計算的講話，裡面大量夾雜自己私貨的同時也給出了很多真知灼見。對Spark他當時說這個東西現在只是個數據處理引擎，但是很有意思。它會變，要關注。我當時在想，數據處理引擎和傳統DB來說還是差很多的，DataBricks是不是會一腳伸進存儲層，後來就聽說了Delta Lake。

當然萬事不能盡善盡美。個人喜好也不同。Delta Lake也有一些我不喜歡的地方。比如說，把transaction log和數據文件放在一個目錄裡，但是並沒有任何保護措施。這就意味著用戶可以不經過spark就去讀取和改變數據文件或者日誌文件，從而造成兩者之間的不一致。這是我在產品設計開發裡面不喜歡的。一個東西如果很容易就被人破壞，那就有很多潛在的危險。好的軟件不應該是這樣的。

Delta Lake選擇用Parquet來做數據文件，我可以理解是兼容性的問題。為了讓社區放心不會被lock in。但是既然有了metadata存儲的地方，其實是不是應該用parquet就是一個兩可的問題了。有些數據類型也許其他的格式會更合適。

在Talk裡Michael Armburst提到，他一開始以為只要有了transaction log就不需要HCatalog了，後來發現HCatalog還是有用的，因為那裡可以給一個組織提供一個全局視圖，告訴大家有哪些數據。他還提到HCatalog的整合會指向這些transaction log。

說實話都9102年了，開源社區都還沒有一個讓我滿意的Catalog，實在是一個遺憾。一個好用的Catalog，其實不是那麼難。但是一系列的後續技術實現都構建在一個好用的Catalog上。比如說最簡單的企業需要的權限管理。沒有Catalog簡直寸步難行。

我很難想象一個企業不需要權限管理。尤其是精確到某行某列的權限管理。這種東西對企業是剛需，而Delta Lake現在的做法是搞不定的。總不能這些東西全寫進transaction log吧。

有一個好的Catalog，另外一個方面，對最新版本的數據的metadata，也可以直接從Catalog裡讀取。而不需要再去transaction log裡扒。很多簡單的partition pruning可以直接做掉了。用不著再起一個spark job去做。

所以這個Delta Lake的設計裡，沒有一個Catalog，在我看來是挺遺憾的。尤其是企業市場上，精細的權限管理完全沒辦法做。當然你可以說Hadoop裡本來就沒辦法做。這也是我覺得開源社區折騰那麼多年居然連一個像樣的Catalog都沒有做出來，實在是有點joking。

以上是我的一些簡單分析和看法。當然我更好奇的是DataBricks的企業版和這個開源版有什麼區別。為什麼內部折騰那麼久之後最終開源了一個閹割版給大家。畢竟對於DataBricks這樣既全心全意為人民服務，更全心全意為人民幣服務的公司，任何的舉動我們都應該從技術和商業兩個方面去分析。