delta.io到底解決了什么問題

本篇文章為大家展示了delta.io到底解決了什么問題，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

2019 年 10 月 16 日，在荷蘭阿姆斯特丹舉行的 Spark+AI 歐洲峰會(huì)上，Databricks 正式宣布將 Delta Lake 捐贈(zèng)給了 Linux 基金會(huì)，其成為了該基金會(huì)中的一個(gè)正式項(xiàng)目。我們期待在今年（2019 年）或者是未來，很快， Delta Lake 將會(huì)成為數(shù)據(jù)湖的主流或者說是事實(shí)標(biāo)準(zhǔn)。

在 9 月份公布的 2019 年最佳開源軟件獎(jiǎng)名單中，Delta Lake 也榜上有名。正如官方對(duì) Delta Lake 的頒獎(jiǎng)評(píng)語描述，大家都很驚訝，Databricks 公司竟然把 Delta Lake 這個(gè)核心的拳頭產(chǎn)品開源了。Delta Lake 的推出實(shí)際上是為了解決 Spark 作為大數(shù)據(jù)分析平臺(tái)的諸多痛點(diǎn)，也相信它將會(huì)普惠整個(gè) Spark 社區(qū)以及其他大數(shù)據(jù)社區(qū)，真正解決數(shù)據(jù)湖管理的各種關(guān)鍵問題。

很有幸，我參與了 Delta Lake 早期的開發(fā)，尤其是 merge、update、delete 這種關(guān)鍵 DML 的設(shè)計(jì)和實(shí)現(xiàn)。這個(gè)項(xiàng)目最早啟動(dòng)于 2017 年 6 月。當(dāng)時(shí)，多位用戶向我們抱怨 Spark 的不足和使用的不便，我們公司的工程師們討論后發(fā)現(xiàn)，是時(shí)候去提出我們自己的存儲(chǔ)架構(gòu)。Spark 作為一種存儲(chǔ)和計(jì)算分離的一種計(jì)算引擎，之前我們主要依賴于其他開源或非開源的項(xiàng)目去解決各種數(shù)據(jù)存儲(chǔ)的問題，但實(shí)際上我們發(fā)現(xiàn)在用戶的生產(chǎn)環(huán)境中，現(xiàn)有的存儲(chǔ)方案都沒辦法真正的解決數(shù)據(jù)湖。于是乎，我們就和客戶一起嘗試去開發(fā)，去解決實(shí)際生產(chǎn)環(huán)境中的問題。經(jīng)過四個(gè)月的快速開發(fā)，我們?cè)?2017 年 10 月正式宣布了 Delta Lake 產(chǎn)品的誕生。在第二年 6 月份的 Spark+AI 峰會(huì)中，Apple 的工程師和我們的工程師 Michael 一起做了主題演講，分享了 Apple 在使用 Delta Lake 的一些寶貴經(jīng)驗(yàn)，比如說他們當(dāng)時(shí)用 Delta Lake 解決了 trillion 級(jí)別數(shù)據(jù)的大表的讀寫。

Summit 之后，我們得到了多方的好評(píng)，目前已有超過 3000 個(gè)客戶正在將 Delta Lake 用于他們的生產(chǎn)環(huán)境中。在這個(gè)背景中，我們認(rèn)為我們應(yīng)該把它推廣到整個(gè) Spark 社區(qū)，幫助整個(gè)大數(shù)據(jù)社區(qū)解決他們大數(shù)據(jù)管理的痛點(diǎn)。于是，2019 年 4 月，我們決定開源了。

但在開源之后，Spark 社區(qū)有很多反饋說 Delta Lake 是你們公司的一個(gè)的 Github repository，你們之后隨時(shí)可能會(huì)改開源的 License，你們的開源管理模式都不是很透明。于是乎，為了解決這樣的疑惑，我們決定把它捐贈(zèng)給 Linux 基金會(huì)，讓它成為一個(gè)標(biāo)準(zhǔn)開放的平臺(tái)，讓更多的人可以參與到 Delta Lake 的開發(fā)和使用中來。

今天我們將分享一些典型的場(chǎng)景，為什么 Delta Lake 可以解決大家的各種痛點(diǎn)，然后也分享一下 Delta Lake 的基本原理和 Delta 架構(gòu)，以及它如何取代大家正在普遍使用的 Lambda 架構(gòu)。

數(shù)據(jù)工程師的糾結(jié)與運(yùn)維的凌亂 項(xiàng)目經(jīng)理總會(huì)跟工程師說，我們有一個(gè)很簡(jiǎn)單的需求。可是，事實(shí)往往卻是，這些簡(jiǎn)單的需求相當(dāng)之難以實(shí)現(xiàn)。

在大數(shù)據(jù)的生產(chǎn)系統(tǒng)，往往，作為工程師的你，會(huì)面對(duì)這樣的一個(gè)項(xiàng)目經(jīng)理：“我要有這么一個(gè) Data Pipeline，持續(xù)地處理數(shù)據(jù)，并且是增量處理，只要有新的數(shù)據(jù)來了就處理，不應(yīng)該每次把所有的歷史數(shù)據(jù)都重新處理，而是只應(yīng)該處理增量數(shù)據(jù)，并且要保證高效快速。記住，我們不能讓用戶在使用中意識(shí)到這是批處理還是流處理?？傊褪强焖俚玫秸_結(jié)果。”

那么作為數(shù)據(jù)工程師的你，要建設(shè)一個(gè)基本的 Data Pipeline [數(shù)據(jù)處理流水線]，按照項(xiàng)目經(jīng)理的說法，那就很簡(jiǎn)單。我們把 Kafka、Kinesis、各種各樣數(shù)據(jù)湖的格式用 Spark 讀出來，再用 Spark 做一些數(shù)據(jù)清理和數(shù)據(jù)轉(zhuǎn)換，然后再把結(jié)果存到一個(gè)數(shù)據(jù)湖，再用另一個(gè) Spark job 把數(shù)據(jù)湖的內(nèi)容分析一下，做訓(xùn)練或者做各種各樣的分析，最后產(chǎn)生一個(gè)報(bào)告給終端用戶。這是一個(gè)非常簡(jiǎn)單的 Pipeline。但是這個(gè) Pipeline 有個(gè)頭痛的問題。如果僅僅用 Spark 的批處理，那么延遲可能不達(dá)標(biāo)，而且也不是在做增量處理。

那么第二個(gè)方案就出來了，用 Spark Structured Streaming。Structured Streaming 有 Trigger Once，可以幫你記錄上次處理到什么地方，這樣的話可以把延遲降低，只處理增量，你也不需要去記錄和管理上次處理到哪里了?？墒俏覀冇钟龅搅艘粋€(gè)新的問題，就是你如果用 Structured Streaming，每個(gè)小的 Batch 都會(huì)產(chǎn)生多個(gè)小的 Spark 的結(jié)果文件。小文件越來越多，整個(gè) Pipeline 就越來越慢，延遲往往到了最后就無法接受了。

為此，那我們就得選擇下一個(gè)方案。我們既然有小文件，就得定期去做壓縮。但是在做壓縮的過程中整個(gè)作業(yè)線會(huì)下線。為什么？由于缺乏原子性讀寫的能力，沒辦法在寫你的壓縮的時(shí)候同時(shí)讀數(shù)據(jù)。壓縮的周期太長也會(huì)影響到你的生產(chǎn)最后報(bào)表的時(shí)效性。比如說，業(yè)務(wù)是不能接受半小時(shí)或者一個(gè)小時(shí)這種延遲的。那么，這個(gè)時(shí)候，大家自然而然會(huì)選擇最經(jīng)典的架構(gòu)，Lambda 架構(gòu)。就是說，你同時(shí)可以部署一個(gè)批處理的和一個(gè)流處理的，批可以慢一點(diǎn)，但是結(jié)果全面準(zhǔn)確，而流處理就是用最快的時(shí)間對(duì)最新增量產(chǎn)生結(jié)果。然后將批和流的結(jié)果匯總，產(chǎn)生一個(gè)全局的結(jié)果。

但是這種 Lambda 架構(gòu)需要同時(shí)運(yùn)營兩個(gè)不同的 pipeline，并且額外資源消耗也大幅增多，運(yùn)營的人力和資源成本都大幅提高。

并且我們對(duì)這兩個(gè) pipeline 都需要做驗(yàn)證。尤其是當(dāng)數(shù)據(jù)來源于非結(jié)構(gòu)數(shù)據(jù)的數(shù)據(jù)源，數(shù)據(jù)不是特別干凈和一致。

對(duì)于驗(yàn)證發(fā)現(xiàn)的錯(cuò)誤，我們又不希望將 Pipeline 給宕下來，而是希望它自動(dòng)去修復(fù)。那么，一種解決方案就是避免對(duì)全表做修正，而是對(duì)某些分區(qū)重新處理。數(shù)據(jù)的重新處理一般都會(huì)影響你整個(gè) pipeline 的延遲，而且還進(jìn)一步增加硬件資源的負(fù)荷和 pipeline 的復(fù)雜度。

之后也許會(huì)有一些業(yè)務(wù)上的調(diào)整，或者是諸多原因，你可能想把數(shù)據(jù)湖做一些 update 和 merge。由于當(dāng)前數(shù)據(jù)湖不支持 update 和 delete，那么你可能需要自己實(shí)現(xiàn) update 和 merge。我們發(fā)現(xiàn)不同用戶的實(shí)現(xiàn)方法都不太一樣，簡(jiǎn)直就是各顯神通，這些方案不但容易出錯(cuò)，復(fù)雜度和延遲也很高，而且大多數(shù)情況還不通用。

復(fù)雜歸復(fù)雜，但是經(jīng)過了半年的研發(fā)，方案終于可以上線了，應(yīng)該是一件開心的事情。可是這個(gè) Lambda 架構(gòu)上線之后你會(huì)收到無數(shù)的抱怨，比如說你這個(gè)數(shù)據(jù)加載太慢了，我們做一些元數(shù)據(jù)操作的時(shí)候，其他并行的命令和查詢都沒辦法用，都被 block 了。不得不等這些大的數(shù)據(jù)加載，或者是元數(shù)據(jù)處理做完了才能再做別的事情。或者用戶做 update 改數(shù)據(jù)湖的時(shí)候會(huì)得到大量的報(bào)告說 FileNotFound。也許是你的文件地址被更新了，但是元數(shù)據(jù)緩沖沒有更新，找不到文件還需要 Refresh 緩存，但有時(shí)候客戶會(huì)抱怨說 Refresh 好像不管用，可是什么時(shí)候管用呢？如果你用的 Object Store，分析到最后，可能發(fā)現(xiàn)是 Eventual Consistency 的問題，也許你不得不要過半小時(shí)之后才會(huì)見到這個(gè)文件……總之就是各種各樣的錯(cuò)。

運(yùn)維已經(jīng)很不容易了，相煎何太急。這個(gè) Lambda 架構(gòu)費(fèi)錢又費(fèi)力，將大好的時(shí)光浪費(fèi)到了解決系統(tǒng)的各種不足和局限，而不是花時(shí)間去從數(shù)據(jù)抽取價(jià)值，真是得不償失。

但是我們?cè)俜催^來看，最開始第一個(gè)方案實(shí)際上是很簡(jiǎn)單，很優(yōu)美。那它到底哪里錯(cuò)了？是什么原因?qū)е滤詈笞兊眠@么復(fù)雜？我們?nèi)绷耸裁矗咳绾慰梢院?jiǎn)化來產(chǎn)生一個(gè)簡(jiǎn)單易維護(hù)的架構(gòu)？

這里我們列出了五點(diǎn)原因：

1）第一，要支持同時(shí)讀寫，就意味著你寫的時(shí)候還可以讀，不應(yīng)該讀到一個(gè)錯(cuò)誤的結(jié)果。同時(shí)還可以支持多個(gè)寫，且能保證數(shù)據(jù)的一致性；

2）第二，可以高吞吐地從大表讀取數(shù)據(jù)。大數(shù)據(jù)方案不能有諸多限制，比如，我聽說有些方案里最多只可以支持幾個(gè)并發(fā)讀，或者讀的文件太多了就不讓你提交作業(yè)了。如果這樣，對(duì)業(yè)務(wù)方來說，你的整個(gè)設(shè)計(jì)是不滿足他的需求的；

3）第三，錯(cuò)誤是無可避免，你要可以支持回滾，可以重做，或者可以刪改這個(gè)結(jié)果，不能為了支持刪改而要求業(yè)務(wù)方去做業(yè)務(wù)邏輯的調(diào)整；

4）第四，在重新改變業(yè)務(wù)邏輯的時(shí)候要對(duì)數(shù)據(jù)做重新處理，這個(gè)時(shí)候，業(yè)務(wù)是不能下線的。在數(shù)據(jù)被重新處理完成之前，數(shù)據(jù)湖的數(shù)據(jù)是要一直可被訪問的；

5）第五，因?yàn)橛兄T多原因，數(shù)據(jù)可能會(huì)有晚到的情況，你要能處理遲到數(shù)據(jù)而不推遲下階段的數(shù)據(jù)處理。

基于以上五點(diǎn)，我們基于 Delta Lake 和 Structured Streaming 產(chǎn)生了一個(gè)新的架構(gòu)，叫 Delta 架構(gòu)，它是對(duì) Lambda 架構(gòu)的一種顛覆，或者稱為一種提升。

在 Delta 架構(gòu)下，批流是合并的，并且要持續(xù)的進(jìn)行數(shù)據(jù)處理，按需來重新處理歷史數(shù)據(jù)，并且利用公有或私有云的特性來對(duì)計(jì)算或者存儲(chǔ)資源按需分別做彈性擴(kuò)展。

Delta Lake 的基本原理

Delta Lake 的基本原理其實(shí)很簡(jiǎn)單，簡(jiǎn)單得令人發(fā)指。作為一個(gè)普通的 Partquet 一般就是 Partition Directories 再加一些 Data Files。Delta Lake 也是基于這個(gè)結(jié)構(gòu)的，唯一的區(qū)別就是它有一個(gè) Transaction Log 記錄你的 Table Version 和變更歷史。

現(xiàn)在，讓我們來重新看待什么構(gòu)成了一張表。表實(shí)際上是一堆操作的結(jié)果，比如說改變?cè)獢?shù)據(jù)，改變名字，改變 Schema，增加或刪除一些 Partitioning，還有另外一種操作是添加或者移除文件。所有表的當(dāng)前狀態(tài)或者是結(jié)果，都是這一系列 Action 產(chǎn)生的結(jié)果。這個(gè)結(jié)果包含了當(dāng)前的 元數(shù)據(jù)，文件列表，transaction 的歷史，還有版本信息。

那怎么去實(shí)現(xiàn)這個(gè)原子性？也很簡(jiǎn)單，只要保證 Commit File 的順序和原子性就可以了。

比如說表的第一個(gè)版本，它是增加兩個(gè)文件，第二個(gè)版本就是把這兩個(gè)文件刪掉，增加一個(gè)新的文件，作為 Reader 來說，每次只能看到當(dāng)前已經(jīng) Commit 的結(jié)果。

怎么實(shí)現(xiàn)多個(gè)寫入的并發(fā)？Spark 的 Pipeline 一般都是高并發(fā)讀，低并發(fā)寫。在這種情況下，樂觀并發(fā)就更加合適了。它實(shí)際上很簡(jiǎn)單，就說你多個(gè)用戶讀的時(shí)候，先記錄一下當(dāng)前讀用的 data 版本是什么，如果同時(shí)有兩個(gè)人都在 commit，只有一方可以成功，而另一方就需要去看一下成功方之前的 commit 里有沒有碰他讀的文件。如果沒有改，他就改一下文件名就行了，如果改了，那就得重做。這個(gè)可以是 Delta Lake 自動(dòng)去重試，也可以是事務(wù)提交方 / 業(yè)務(wù)方，去重做。

Delta Lake 需要解決的另一個(gè)經(jīng)典問題就是大規(guī)模元數(shù)據(jù)的處理。你發(fā)現(xiàn)你有大量的 commit log file，因?yàn)槊看?commit 都會(huì)產(chǎn)生一個(gè)文件，這其實(shí)也是一個(gè)經(jīng)典的小文件處理。如何解決這種元數(shù)據(jù)處理？標(biāo)準(zhǔn)答案就是使用 Spark。Delta Lake 便是使用 Spark 去處理它的元數(shù)據(jù)。比如剛才說了一個(gè)例子，加了兩個(gè)文件，減了兩個(gè)文件，之后加了一個(gè) parquet，之后 Spark 會(huì)把這些 commit 全部讀下來，產(chǎn)生一個(gè)新的，我們稱之為叫 Checkpoint。

這就是 Delta Lake，就是這么簡(jiǎn)單。

Delta 架構(gòu) Delta 架構(gòu)簡(jiǎn)介 我們看一下 Delta 架構(gòu) ，怎么用 Delta 架構(gòu)代替經(jīng)典的 Lambda 架構(gòu)。

1）第一，同時(shí)讀寫，并且要保證數(shù)據(jù)的一致性

就是剛才我們提出的第一個(gè)需求，就是要支持 transcation，就是說你只要能實(shí)現(xiàn)讀寫之間的 Snapshot isolation 就行了，這樣你可以集中在你的 data flow，而不用擔(dān)心會(huì)不會(huì)讀到部分結(jié)果，不用擔(dān)心 FileNotFound 的這類錯(cuò)誤，這些事情 Delta Lake 都可以幫你處理。

Delta Lake 提供了流，就是 streaming 和 batch 的讀入和寫入，標(biāo)準(zhǔn) API，很容易實(shí)現(xiàn)，很容易去用。你可以在文檔里面找到具體的 API。

2）可以高吞吐從大表讀取數(shù)據(jù)

可能處理過大數(shù)據(jù)的同學(xué)們就遇到過這個(gè)經(jīng)典痛點(diǎn)，我也處理過客戶的這種問題好多次，在 沒有 Delta Lake 的時(shí)候，簡(jiǎn)直痛不欲生。

如果沒有 Delta Lake，讀取百萬級(jí)的 patition 的 location path 是需要用 Hive metastore 一行行地讀的，要取一百萬行簡(jiǎn)直是奇慢無比。然后，在每個(gè) patition 的 地址里還需要通過文件系統(tǒng) 列里面包含的所有文件。這在對(duì)象存儲(chǔ)的系統(tǒng)里，這種操作也是又貴又慢。

其實(shí)這個(gè)問題不又是一個(gè)典型的大數(shù)據(jù)問題嗎？大數(shù)據(jù)系統(tǒng)都解決不了大數(shù)據(jù)問題，那不是貽笑大方？

當(dāng)然，這里的解決方案很簡(jiǎn)單，就是標(biāo)準(zhǔn)的 Spark，用 parquet 去存 file path，并且用 Spark 的分布式的向量化的讀入去讀，這就是 Delta Lake 怎么去解決之前的痛點(diǎn)。我們客戶因?yàn)檫@個(gè)性能輕松地提高了幾百倍甚至幾千倍。其實(shí)也就是因?yàn)?Hive metastore 和文件系統(tǒng)的 list file 操作實(shí)在太慢了。

3）支持回滾和刪改

數(shù)據(jù)這么臟，回滾和刪改需求難以避免。Delta Lake 提供了 Time travel，因?yàn)?transaction log 實(shí)際能看到整個(gè)歷史變化的結(jié)果，所以 Delta Lake 實(shí)現(xiàn)這個(gè)很方便。我們提供了兩條 API，你可以基于 Timestamp 去做， 也可以基于 version number。Time travel 是一個(gè)特別好的功能，它可以做很多事情，不單單是糾錯(cuò)，你還可以 Debug，重建過往報(bào)告，查賬，審計(jì)，復(fù)雜的 temporal query，對(duì)快速更新數(shù)據(jù)的表做版本查詢……

Delta Lake 還支持刪改（update/delete/merge），不過目前 Delta 還沒有自己的 SQL 語法，當(dāng)然我們可以把 Spark 的語法完全復(fù)制過來，但是維護(hù)成本也很高。但 Spark 3.0 來了之后這個(gè)問題就迎刃而解了。當(dāng)然，如果要支持 Spark 2.4 的話，Delta 需要加上自己的 SQL parser，我們還在討論要不要這樣干。

4）在線業(yè)務(wù)不下線的同時(shí)可以重新處理歷史數(shù)據(jù)

你只要對(duì) Delta Lake 做相關(guān)結(jié)果的刪除，重新改一下業(yè)務(wù)邏輯，歷史數(shù)據(jù)再做批處理，你就可以得到你的最新結(jié)果了。與此同時(shí)，因?yàn)?Delta Lake 支持 ACID，數(shù)據(jù)的下游適用方還可以同時(shí)訪問之前版本的數(shù)據(jù)。

5）處理遲到數(shù)據(jù)而無需推遲下階段的數(shù)據(jù)處理

處理遲到數(shù)據(jù)也不是什么問題，只要你能支持 merge，如果存在就 update，不存在就 insert，不影響你現(xiàn)有的 Delta Lake 重寫。

如上所述， Delta Lake 完美解決了我們的需求，讓大家的 Data pipeline 重新變得簡(jiǎn)單而優(yōu)雅，而不需要用那么復(fù)雜的 Lambda 架構(gòu)了。

怎么最好地使用 Delta 架構(gòu) ？基于跟客戶的各種的討論經(jīng)驗(yàn)，我們總結(jié)出了下面幾點(diǎn)。

你需要有多個(gè) stage 的 Delta Lake。我們的基本 idea 是這樣的：第一個(gè) stage 就是你要保證沒有原始數(shù)據(jù)損失。它保存在 Delta Lake 里，萬一哪天發(fā)現(xiàn)之前的一些數(shù)據(jù)清理導(dǎo)致丟失了很重要的信息，你還可以輕松恢復(fù)。第二個(gè) stage 就是做數(shù)據(jù)清理，做一些清理、轉(zhuǎn)換、filter。然后才真正達(dá)到一個(gè)可以被數(shù)據(jù)分析的第三個(gè) stage。這是基于數(shù)據(jù)質(zhì)量分成多個(gè)級(jí)別，多個(gè)狀態(tài)。至于實(shí)際生產(chǎn)線上需要多少個(gè) stage，這個(gè)取決于業(yè)務(wù)的復(fù)雜度，SLA，和對(duì)延遲的要求。

Delta 架構(gòu)的特性 來看一下 Delta 架構(gòu)的特性。

1）持續(xù)數(shù)據(jù)流

這聽起來好像很高大上，但實(shí)際上稍微解釋多一點(diǎn)就很容易明白。

批流合并。Streaming 和 batch 用同一個(gè) engine，不用維護(hù)多個(gè)；同一套 API，甚至都不用 batch 的 API，就用 streaming 的 API 就能解決問題；同樣的 user code，無需用到 Lambda 架構(gòu)，純粹就是一條 pipeline 解決所有問題。高效增量數(shù)據(jù)載入。如果不斷有新數(shù)據(jù)進(jìn)來就直接用 Structured Streaming 的 Trigger.Once 去記錄上一次你處理到哪，你只需要重啟這個(gè) Trigger.Once，就處理了上次之后的新數(shù)據(jù), 特別方便。快速無延遲的流處理，你可以選擇不同的 Trigger 的模式，當(dāng)然 Trigger.Once 最省錢，當(dāng)然你也可以低延遲，比如多長時(shí)間 Trigger 一次，也可以低延遲用持續(xù) Trigger。你可以把批處理變成一個(gè)持續(xù)流處理，簡(jiǎn)單易用。而且 Delta Lake 因?yàn)橹С衷有裕运鼙ＷC exactly once，這一點(diǎn)很重要，其他的數(shù)據(jù)源基本沒辦法保證。

2）物化中間結(jié)果

這一點(diǎn)就有點(diǎn)顛覆傳統(tǒng)模式了。我們建議多次物化你的中間結(jié)果，也就是之前說的多個(gè) stage。每個(gè) stage 就是把中間結(jié)果落地存在文件里，它有以下好處。

容錯(cuò)恢復(fù)，出問題后可以回到某一個(gè)版本，從那個(gè)時(shí)候再開始，你不需要從最原始的數(shù)據(jù)開始，這點(diǎn)在 pipeline 里是很重要的事情。方便故障排查，你知道哪一步出錯(cuò)了，要是不存，業(yè)務(wù)方報(bào)告出錯(cuò)的時(shí)候你也不知道問題出在哪兒，連 debug 都沒法 debug，回溯都沒辦法回溯。一寫多讀，當(dāng)你的 pipeline 很多很復(fù)雜的時(shí)候，可能重用中間的一些結(jié)果，這真的很方便。這里面比如說圖例的兩個(gè) pipeline ，其實(shí)到 T3 之前，都是一樣的。我們就可以復(fù)用。

如果你的轉(zhuǎn)換很復(fù)雜的時(shí)候，可以物化多次。到底物化多少次，取決于你對(duì) Reliability/SLA 和 end-2-end latency 的取舍，你要是 Reliability/SLA 好，你就必須要物化多幾次，但是寫肯定有代價(jià)，所以 end-2-end latency 就慢，具體就要看你的需求了。

3）費(fèi)用和延遲的取舍

流處理，持續(xù)的數(shù)據(jù)流入和處理，無需作業(yè)調(diào)度管理，需要永遠(yuǎn)在線的 cluster。頻繁的批處理，分鐘級(jí)數(shù)據(jù)流入和處理，不需要低延遲，比如半小時(shí)就可以了，需要 warm pool of machine，無事關(guān)機(jī)，按需啟動(dòng)?？墒褂?Spark structured streaming 的 Trigger.Once 模式。非頻繁批處理，若干小時(shí)或若干天的數(shù)據(jù)批流入和處理，無事關(guān)機(jī)，按需啟動(dòng)，也可使用 structured streaming 的 Trigger.Once 模式。這樣一來，就可以節(jié)省很多資源了。

4）優(yōu)化數(shù)據(jù)的物理存儲(chǔ)

根據(jù)常用查詢的 predicate，為改善讀取速度，可優(yōu)化數(shù)據(jù)的物理存儲(chǔ)。比如，用 partitioning 和 z-ordering。Partitioning 大家都應(yīng)該很清楚了，low cardinality 的 column 比較合適，就是每個(gè) partition 不要超過 1 GB，一般比如說用 date 這是一種經(jīng)常被使用的 partition column，每個(gè) date 里面要給予不同的 eventType。這樣，每個(gè) partition 不會(huì)太大，也不會(huì)產(chǎn)生太多 partition。反之如果用 timestamp 做 partition column，產(chǎn)生的 partition value 就是無數(shù)個(gè)，簡(jiǎn)直奇葩無比，可以輕松把 Hive metastore 給撐爆。在 Delta Lake 里面我們也不建議，即使我們不用 metastore。第二就是 Z-Ordering，這個(gè)還沒到開源的版本，但是這個(gè)是可以解決什么問題呢，就是是針對(duì)那種 high cardinality，就是 column 里有大量的不一樣的 value，這種就適合做 z-ordering index。

5）重新處理歷史數(shù)據(jù)

每次 keep 住上一個(gè) stage 的好處是什么？你把結(jié)果一刪，重新用 Tigger.Once 再做一次就好了，結(jié)果就出來了。如果你系統(tǒng)部署在云上，那對(duì)你來說也很簡(jiǎn)單，你如果要快速回填，你就再多加幾臺(tái)機(jī)器，結(jié)果就更快地出來了。比如，從原來的十臺(tái)機(jī)器擴(kuò)張到一百臺(tái)。

6. 數(shù)據(jù)質(zhì)量的調(diào)整

這是也是一個(gè)需要改變大家思維方式的地方。

在最開始的時(shí)候，我們最好是保證數(shù)據(jù)完整性。schema 可以選擇自動(dòng)合并，就可以避免數(shù)據(jù)的丟失。到了最后階段，我們就需要去強(qiáng)制 schema 不能變，data type 不能變，data expectation 也不能。比如，不能有 NULL。數(shù)據(jù)質(zhì)量對(duì)于數(shù)據(jù)分析的準(zhǔn)確度是至關(guān)重要的。

以上特性也不是很難理解，但是需要改變思維方式。

Delta 架構(gòu)的優(yōu)點(diǎn) 1）減少端到端的 pipeline SLA多個(gè)使用單位（客戶）把 data pipeline 的 SLA 從幾小時(shí)減少到幾分鐘。

2）減少 pipeline 的維護(hù)成本原來的 Lambda 架構(gòu)簡(jiǎn)直就是費(fèi)時(shí)費(fèi)力。要同樣達(dá)到分鐘級(jí)的用例延遲，Delta Lake 架構(gòu)并不需要這么復(fù)雜。

3）更容易的處理數(shù)據(jù)更新和刪除簡(jiǎn)化了 Change data capture，GDPR，Sessionization，數(shù)據(jù)去冗。這些都可以用 Delta Lake 去實(shí)現(xiàn)，方便很多。

4）通過計(jì)算和存儲(chǔ)的分離和可彈縮而降低了 infrastructure 的費(fèi)用多個(gè)使用單位將 infrastructure 的費(fèi)用降低了超過十倍。

Delta 架構(gòu)的經(jīng)典案例 這里分享 3 個(gè) Delta 架構(gòu)的經(jīng)典方案。

第一個(gè)是 COMCAST，一個(gè)像中國移動(dòng)的通訊類公司，它收集了美國海量的用戶數(shù)據(jù)。它的 Petabyte-scale jobs 使用 Delta Lake ，從原來需要 640 個(gè)服務(wù)器降到 64 個(gè)，原來是 84 個(gè) job 降低到 34 個(gè) job，延遲還降了一半。

第二個(gè)是 Sam‘s Club，它們也是使用 Delta Lake ，原來根本達(dá)不到數(shù)據(jù)的一致性，現(xiàn)在可以達(dá)到。延遲從一個(gè)小時(shí)降到六秒。

第三個(gè)就是澳洲的 healthdirect，數(shù)據(jù)更干凈\更一致了，做數(shù)據(jù)分析匹配的準(zhǔn)確度從 80% 升到 95%，數(shù)據(jù)加載的時(shí)耗從一天降到了 20 分鐘。

這都是來自于 Delta Lake 用戶在 Spark Summit 上分享的案例。

使用 Delta Lake 特別簡(jiǎn)單，就把 parquet 的 keywords 一換。

怎么加這個(gè) Delta Lake 呢，把這個(gè) package 加上就好了。

上述內(nèi)容就是delta.io到底解決了什么問題，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。