如上面的圖片，我基本上完整的保留了整個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這樣既全心全意為人民服務，更全心全意為人民幣服務的公司，任何的舉動我們都應該從技術和商業兩個方面去分析。