認識 Delta Lake

百花齊放的大數據生態

17,18是計算引擎火熱的兩年,19年已然是紅海了。計算引擎中的王者是Spark,綜合指標最好,生態也好,當其他引擎還在ETL,交互查詢,流上廝殺時,Spark已經在AI領域越走越遠。

?對比明顯的是,計算層的上層和下層在17,18年卻乏善可陳。但是到19年整個局勢開發生變化,向下走是存儲層Delta Lake耀眼奪目,解決了原先數倉的諸多痛點,讓數倉進化到數據湖。向上走是交互應用層的Linkis一馬當先,形成交互標準,粘合周邊生態,很好的銜接了應用交互層和計算引擎層的銜接。

問題重重的數據存儲層

前面我們提到,早先基于Hive的數倉或者傳統的文件存儲形式(比如Parquet/ORC),都存在一些長期難以解決的問題:

  • 小文件的問題
  • 并發讀寫問題
  • 有限的更新支持
  • 海量元數據(例如分區)導致Hive metastore不堪重負

細節展開的話,你會發現每一個問題又會引發眾多應用場景層面的問題。

比如并發讀寫還有更新問題讓實時數倉的實現變得很困難。小文件問題需要我們自己寫合并代碼,并且在合并過程中還會造成數據不可讀的問題。如此種種不一而足。

為了解決這些先天不足的問題,我們只能通過復雜的架構設計來解決這些問題(美其名曰lambda架構)。比如為了解決先天不足的更新問題,我們可能需要先將數據寫入一個其他的系統(如HBase),然后再將HBase導出成Parquet文件/Hive表供下游使用。在復雜的流程(超長的Pipeline)運行的過程中,還會不斷涉及到Schema的變換以及磁盤的讀取,所以架構復雜了不僅僅會導致運維成本高企,CPU/IO浪費也就變得異常嚴重。

其實上面這些問題的根源,都是因為存儲層不給力,為了曲線救國,我們無奈通過架構來彌補。Delta Lake單刀直入,直接解決存儲層的問題,帶來的益處就是極大的簡化我們的架構設計,簡化運維成本,降低服務器成本。

Delta Lake 生之逢時

天下苦傳統數倉久已,Delta Lake 橫空出世,那么它是如何解決上面的存儲層問題呢?我列舉了如下幾個重要的特性:
以元數據也是大數據思想武裝自己,設計了基于HDFS存儲的元數據系統,解決metastore不堪重負的問題。
支持更多種類的更新模式,比如Merge/Update/Delete等操作,配合流式寫入或者讀取的支持,讓實時數據湖變得水到渠成。
流批操作可以共享同一張表版本概念,可以隨時回溯,避免一次誤操作或者代碼邏輯而無法恢復的災難性后果。

Delta Lake 其實只是一個Lib庫

Delta Lake 是一個lib 而不是一個service,不同于HBase,他不需要單獨部署,而是直接依附于計算引擎的。目前只支持Spark引擎。這意味什么呢?Delta Lake 和普通的parquet文件使用方式沒有任何差異,你只要在你的Spark代碼項目里引入delta包,按標準的Spark datasource操作即可,可謂部署和使用成本極低。
Delta Lake到底是什么

Parquet文件 + Meta 文件 + 一組操作的API = Delta Lake.

所以Delta沒啥神秘的,和parquet沒有任何區別。但是他通過meta文件以及相應的API,提供眾多特性功能的支持。在Spark中使用它和使用parquet的唯一區別就是把format parquet換成detla。

和Hive如何整合

因為慣性以及歷史的積累,大家還是希望能像使用hive那樣使用delta,而不是去使用spark的datasource API。截止到筆者寫這些文字之前,官方還沒有支持。不過官方透露阿里的同學已經在做這塊的整合。另外最近版本的Delta Lake已經通過Manifests機制允許比如Presto之類的讀取數據了。

競爭對手

Apache Delta目前主要的競爭對手是Apache Hudi 以及 Apache IceBerg。我們統稱為數據湖三駕馬車。最后誰能走出來,拭目以待了。對于這三者之間總結性質的區別和看法,我引用邵賽賽的一段話,我覺得他總結的足夠好了:

Iceberg 的設計初衷更傾向于定義一個標準、開放且通用的數據組織格式,同時屏蔽底層數據存儲格式上的差異,向上提供統一的操作 API,使得不同的引擎可以通過其提供的 API 接入;Hudi 的設計初衷更像是為了解決流式數據的快速落地,并能夠通過 upsert 語義進行延遲數據修正;Delta Lake 作為 Databricks 開源的項目,更側重于在 Spark 層面上解決 Parquet、ORC 等存儲格式的固有問題,并帶來更多的能力提升。他們都提供了 ACID 的能力,都基于樂觀鎖實現了沖突解決和提供線性一致性,同時相應地提供了 time travel 的功能。

因為引用限制的問題,大家可以看看原文。

=========
歡迎大家關注我公眾號 【祝威廉】

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,825評論 6 546
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,814評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,980評論 0 384
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 64,064評論 1 319
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,779評論 6 414
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 56,109評論 1 330
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,099評論 3 450
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,287評論 0 291
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,799評論 1 338
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,515評論 3 361
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,750評論 1 375
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,221評論 5 365
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,933評論 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,327評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,667評論 1 296
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,492評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,703評論 2 380