當(dāng)企業(yè)需要建設(shè)獨(dú)立的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)來(lái)支撐BI和分析業(yè)務(wù)時(shí)，有了“數(shù)據(jù)湖+數(shù)據(jù)倉(cāng)庫(kù)”的混合架構(gòu)。但混合架構(gòu)帶來(lái)了更高的建設(shè)成本、管理成本和業(yè)務(wù)開(kāi)發(fā)成本。隨著大數(shù)據(jù)技術(shù)的發(fā)展，通過(guò)在數(shù)據(jù)湖層增加分布式事務(wù)、元數(shù)據(jù)管理、極致的SQL性能、SQL和數(shù)據(jù)API接口能力，企業(yè)可以基于統(tǒng)一的架構(gòu)來(lái)同時(shí)支持?jǐn)?shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)的業(yè)務(wù)，這就是湖倉(cāng)一體架構(gòu)。本篇繼續(xù)介紹星環(huán)科技Inceptor和Apache Delta Lake。

—?星環(huán)科技Inceptor?—星環(huán)科技 Inceptor是一個(gè)分布式的關(guān)系型分析引擎，于2013年開(kāi)始研發(fā)，主要用于ODS、數(shù)據(jù)湖以及其他結(jié)構(gòu)化數(shù)據(jù)的分析型業(yè)務(wù)場(chǎng)景。Inceptor支持絕大部分ANSI 92、99、2003 SQL標(biāo)準(zhǔn)，兼容傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)方言，如Oracle、IBM DB2、Teradata等，并且支持存儲(chǔ)過(guò)程。2014年起，國(guó)內(nèi)一些銀行客戶開(kāi)始嘗試將一些原本在DB2上一些性能不足的數(shù)據(jù)加工業(yè)務(wù)，遷移到Inceptor上，而這些原本構(gòu)建在關(guān)系型數(shù)據(jù)庫(kù)上的數(shù)據(jù)任務(wù)有大量的并發(fā)update、delete的需求，并且存在多個(gè)數(shù)據(jù)鏈路加工一個(gè)結(jié)果表的情況，因此有很強(qiáng)的并發(fā)事務(wù)性能要求。此外，由于用戶不僅期望完成數(shù)據(jù)批處理業(yè)務(wù)從關(guān)系數(shù)據(jù)庫(kù)遷移到Hadoop平臺(tái)上，并且期望性能上有數(shù)量級(jí)上的提升，因此星環(huán)科技從2014年開(kāi)始研發(fā)基于HDFS的分布式事務(wù)機(jī)制，以支撐部分?jǐn)?shù)據(jù)倉(cāng)庫(kù)的業(yè)務(wù)場(chǎng)景，到2016年隨著Inceptor 4.3版本正式發(fā)布了相關(guān)的技術(shù)，并后續(xù)幾年在數(shù)百個(gè)金融行業(yè)用戶落地生產(chǎn)，技術(shù)成熟度已經(jīng)金融級(jí)要求。

Inceptor的總體架構(gòu)圖如上，因?yàn)镺RC是列式存儲(chǔ)，有非常好的統(tǒng)計(jì)分析性能，我們選擇基于ORC文件格式來(lái)二次開(kāi)發(fā)分布式系統(tǒng)。由于HDFS也不支持文件的random access和文件內(nèi)的事務(wù)操作，因此對(duì)數(shù)據(jù)的并發(fā)update和delete，我們采用了MVCC機(jī)制，每次提交的數(shù)據(jù)更新，不直接對(duì)數(shù)據(jù)文件進(jìn)行改寫(xiě)，而是對(duì)數(shù)據(jù)文件增加一個(gè)相應(yīng)的新版本，一個(gè)事務(wù)內(nèi)的所有的數(shù)據(jù)操作都寫(xiě)入一個(gè)delta文件中。讀取數(shù)據(jù)的時(shí)候再將所有文件數(shù)據(jù)讀入內(nèi)存，并且在內(nèi)存中對(duì)多個(gè)文件中的同一個(gè)數(shù)據(jù)按照事務(wù)順序和可見(jiàn)性來(lái)做合并，也就是Merge on Read機(jī)制。需要強(qiáng)調(diào)一點(diǎn)，數(shù)據(jù)倉(cāng)庫(kù)上都是數(shù)據(jù)批處理加工，批處理的數(shù)據(jù)業(yè)務(wù)每個(gè)SQL都可能操作的數(shù)據(jù)量比較大，單個(gè)的SQL操作需要的延時(shí)可能是幾十秒甚至是分鐘級(jí)以上，它對(duì)分布式事務(wù)的性能要求是幾十到幾百TPS，而不是分布式數(shù)據(jù)庫(kù)面向交易型業(yè)務(wù)需要的幾萬(wàn)甚至更高的TPS。鎖沖突是批處理情況下并發(fā)性能的一個(gè)主要瓶頸點(diǎn)。如果同時(shí)有多個(gè)ETL任務(wù)在加工一個(gè)數(shù)據(jù)表，那么這個(gè)表很有可能就會(huì)出現(xiàn)鎖沖突，從而導(dǎo)致數(shù)據(jù)任務(wù)之間出現(xiàn)鎖等待而拖慢最終加工節(jié)奏。為了解決性能問(wèn)題，我們開(kāi)發(fā)了一個(gè)獨(dú)立的Lock Manager來(lái)管理分布式事務(wù)的產(chǎn)生與可見(jiàn)性判斷，同時(shí)鎖的粒度包括Database、Table和Partition三個(gè)粒度，這樣就減少了很多的不必要的鎖沖突問(wèn)題。

此外，在數(shù)倉(cāng)加工過(guò)程中，很多表既是上一個(gè)加工任務(wù)的結(jié)果表，也是其他數(shù)據(jù)任務(wù)的數(shù)據(jù)源頭，因此也會(huì)存在讀寫(xiě)沖突問(wèn)題，部分情況下會(huì)導(dǎo)致并發(fā)受限。為了解決這個(gè)問(wèn)題，我們引入快照（snapshot）機(jī)制和Serializable Snapshot的隔離級(jí)別，數(shù)據(jù)表的讀操作可以直接讀取某個(gè)快照，這樣就無(wú)需跟寫(xiě)操作產(chǎn)生事務(wù)沖突。在我們的設(shè)計(jì)中，快照不需要持久化，無(wú)需增加大量的物理存儲(chǔ)，而是一個(gè)輕量級(jí)的、全局一致的邏輯概念，在事務(wù)處理中可以快速判斷數(shù)據(jù)的某版本應(yīng)當(dāng)包含還是排除。在事務(wù)的隔離性上，Inceptor支持Read uncommitted、Read committed、Repeatable reads、Serializable和Serializable Snapshot這5種隔離級(jí)別。在并發(fā)控制技術(shù)上，Inceptor 提供了悲觀和樂(lè)觀兩類(lèi)可序列化隔離級(jí)別：基于嚴(yán)格的兩階段鎖的串行化隔離級(jí)別和基于快照的序列化隔離級(jí)別。用戶可以根據(jù)業(yè)務(wù)場(chǎng)景選擇適合的隔離級(jí)別類(lèi)型。嚴(yán)格的兩階段鎖的序列化隔離（S2PL Based Serializable Isolation）是一種悲觀的并發(fā)控制技術(shù)，其主要特點(diǎn)是先獲得鎖，再處理讀寫(xiě)，直到事務(wù)提交完成后才釋放所有鎖。它的實(shí)現(xiàn)比較方便，主要難點(diǎn)是處理好死鎖問(wèn)題（通過(guò)環(huán)檢測(cè)解決）。該技術(shù)的讀寫(xiě)無(wú)法并發(fā)，因此事務(wù)處理的并發(fā)性能較差。而可序列化快照隔離（Serializable Snapshot Isolation）能夠提高事務(wù)處理的并發(fā)性能，采用了基于樂(lè)觀鎖的可序列化快照隔離，該技術(shù)的優(yōu)勢(shì)是不會(huì)產(chǎn)生兩階段鎖技術(shù)中讀寫(xiě)操作互相阻塞的情況，使得讀寫(xiě)互不阻塞，提高了并發(fā)度。雖然快照隔離也不會(huì)出現(xiàn)臟讀、不可重復(fù)讀、幻讀現(xiàn)象，但它并不能保證可序列化，在處理并發(fā)的事務(wù)時(shí)，仍然可能因?yàn)椴粷M足約束（Constraints）而發(fā)生異常，稱(chēng)之為寫(xiě)偏序問(wèn)題（Write Skew）。為解決寫(xiě)偏序問(wèn)題，Inceptor引入對(duì)可序列化快照沖突的檢查，增加了對(duì)快照隔離級(jí)別下事務(wù)間的讀寫(xiě)依賴(lài)關(guān)系中環(huán)的檢測(cè)來(lái)發(fā)現(xiàn)相關(guān)的沖突問(wèn)題并abort異常的事務(wù)。如上文所述，Inceptor在分布式事務(wù)的并發(fā)能力、事務(wù)隔離性、SQL性能等方面的技術(shù)積累比較完整，此外從2016年就開(kāi)始被金融業(yè)大量采用，在數(shù)據(jù)倉(cāng)庫(kù)的場(chǎng)景下Inceptor的成熟度比較高。由于Inceptor設(shè)計(jì)上不是為了機(jī)器學(xué)習(xí)的場(chǎng)景，因此沒(méi)有提供直接給機(jī)器學(xué)習(xí)框架使用的數(shù)據(jù)API層。另外，Inceptor也沒(méi)有單獨(dú)設(shè)計(jì)面向?qū)崟r(shí)數(shù)據(jù)寫(xiě)入的架構(gòu)，也不能有效的支持流批一體的架構(gòu)，不過(guò)星環(huán)科技在分布式數(shù)據(jù)庫(kù)ArgoDB中解決了流批一體的需求問(wèn)題。

—??Apache?Delta Lake?—

由于Databricks Cloud上大量用戶運(yùn)行機(jī)器學(xué)習(xí)任務(wù)，因此Databricks的主要設(shè)計(jì)目標(biāo)包括：

• 優(yōu)秀的SQL性能

  數(shù)據(jù)分析的性能是BI和分析類(lèi)軟件的核心要求，因此需要采用列式文件格式（如Parquet等）等適合統(tǒng)計(jì)分析的格式，以及向量式計(jì)算引擎、數(shù)據(jù)訪問(wèn)緩存、層級(jí)化數(shù)據(jù)存儲(chǔ)（如冷熱數(shù)據(jù)分離存儲(chǔ)等技術(shù)）等技術(shù)，來(lái)提升數(shù)據(jù)湖內(nèi)SQL統(tǒng)計(jì)分析的性能，達(dá)到數(shù)據(jù)倉(cāng)庫(kù)的技術(shù)要求

• 提供分布式事務(wù)和schema支持

數(shù)據(jù)湖的存儲(chǔ)多以文件方式，采用的schemaless方式，這位數(shù)據(jù)分析提供了靈活性，但是就無(wú)法實(shí)現(xiàn)數(shù)據(jù)庫(kù)的ACID管理能力。Delta Lake完善了文件存儲(chǔ)，提供嚴(yán)格的數(shù)據(jù)庫(kù)schema機(jī)制，之后研發(fā)了一套基于MVCC的多版本事務(wù)機(jī)制，這樣就進(jìn)一步提供數(shù)據(jù)庫(kù)的ACID 語(yǔ)義，并且支持高并發(fā)的update和delete的SQL操作。此外，Delta Lake基于開(kāi)放的數(shù)據(jù)格式（Parquet），這樣既可以直接操作HDFS，也讓其他計(jì)算引擎可以訪問(wèn)相關(guān)的數(shù)據(jù)，提高了生態(tài)兼容性。

• 靈活對(duì)接機(jī)器學(xué)習(xí)任務(wù)和探索式分析的數(shù)據(jù)API

機(jī)器學(xué)習(xí)和AI訓(xùn)練任務(wù)對(duì)Databricks的核心業(yè)務(wù)場(chǎng)景，因此Delta Lake在設(shè)計(jì)上非常注重保證的這類(lèi)業(yè)務(wù)的支撐，其不僅提供DataFrame API，還支持Python、R等編程語(yǔ)言接口，還強(qiáng)化了對(duì)Spark MLlib、SparkR、Pandas等機(jī)器學(xué)習(xí)框架的整合。

基于以上能力，結(jié)合Spark的計(jì)算能力和Delta lake的存儲(chǔ)能力，就可以實(shí)現(xiàn)完全基于Databricks存算技術(shù)的數(shù)據(jù)架構(gòu)，可以支持BI統(tǒng)計(jì)分析、實(shí)時(shí)分析以及機(jī)器學(xué)習(xí)任務(wù)，另外Delta Lake基于開(kāi)放的數(shù)據(jù)存儲(chǔ)格式，也可以對(duì)接其他的計(jì)算引擎如Presto做交互式分析。在項(xiàng)目的初始設(shè)計(jì)目標(biāo)上，Hudi側(cè)重于高并發(fā)的update/delete性能，Iceberg側(cè)重于大量數(shù)據(jù)情況下的查詢(xún)性能，而Delta Lake設(shè)計(jì)的核心是為了更好的在一個(gè)存儲(chǔ)上同時(shí)支持實(shí)時(shí)計(jì)算和離線計(jì)算。通過(guò)與Spark Structured Streaming的深入整合，delta table不僅可以做Streaming的數(shù)據(jù)源，也可以直接作為Streaming的目標(biāo)表，此外還可以保證Exactly-Once語(yǔ)義。Delta社區(qū)結(jié)合multi-hop數(shù)據(jù)架構(gòu)設(shè)計(jì)了一套流批一體的參考架構(gòu)設(shè)計(jì)，能夠做到類(lèi)似Kappa架構(gòu)的一份數(shù)據(jù)存儲(chǔ)響應(yīng)流批兩種場(chǎng)景需求。

由于Databricks對(duì)Delta Lake的開(kāi)源相對(duì)受限，部分功能需要依賴(lài)Databricks File System以及Engine才能比較好，因此社區(qū)里面的關(guān)注度上不如Huid和Iceberg。此外，設(shè)計(jì)上Delta Lake并不提供主鍵，因此高并發(fā)的update/delete不如Hudi，也不提供類(lèi)似Iceberg的元數(shù)據(jù)級(jí)別的查詢(xún)優(yōu)化，因此查詢(xún)性能上可能不如Iceberg，但是Delta Lake強(qiáng)調(diào)的是結(jié)合Spark形成的流批一體的數(shù)據(jù)架構(gòu)以及對(duì)機(jī)器學(xué)習(xí)類(lèi)應(yīng)用的原生API級(jí)別的支持，可適用的業(yè)務(wù)場(chǎng)景有很好的普遍性。—?小結(jié)—從時(shí)間維度上看，星環(huán)科技Inceptor是最早開(kāi)始探索在數(shù)據(jù)湖上提供數(shù)據(jù)倉(cāng)庫(kù)能力的產(chǎn)品，并且在2016年即完成產(chǎn)品的規(guī)模化上生產(chǎn)，因此產(chǎn)品成熟度較高，尤其是在分布式事務(wù)實(shí)現(xiàn)的完備性上更是有明顯的優(yōu)勢(shì)。Hudi在設(shè)計(jì)上適合有高并發(fā)的update/delete的業(yè)務(wù)場(chǎng)景，與星環(huán)科技Inceptor 類(lèi)似，這兩個(gè)技術(shù)也都是基于Hadoop提供update、delete的能力，而相對(duì)來(lái)說(shuō)，Hudi在分布式事務(wù)的實(shí)現(xiàn)細(xì)節(jié)上還需要更多的時(shí)間和生產(chǎn)打磨來(lái)完善。Iceberg項(xiàng)目在設(shè)計(jì)上適合有大量分區(qū)但少事務(wù)操作的海量數(shù)據(jù)的分析場(chǎng)景，對(duì)互聯(lián)網(wǎng)類(lèi)企業(yè)比較適合，加上Iceberg在軟件設(shè)計(jì)上做了非常好的抽象，對(duì)各種計(jì)算引擎的支持比較完備，在partition等優(yōu)化上做的非常細(xì)致，對(duì)一些事務(wù)性要求不太高的場(chǎng)景還是有很強(qiáng)的吸引力。Databricks對(duì)Delta Lake的開(kāi)源相對(duì)受限，部分功能需要依賴(lài)Databricks File System以及Engine才能比較好，因此社區(qū)里面的關(guān)注度上不如Hudi和Iceberg。Delta Lake在性能上沒(méi)有突出的設(shè)計(jì)，在分布式事務(wù)的實(shí)現(xiàn)上相對(duì)比較簡(jiǎn)單，事務(wù)并發(fā)和隔離性實(shí)現(xiàn)都還處于早期階段，目前該項(xiàng)目更強(qiáng)調(diào)的是結(jié)合Spark形成的流批一體的數(shù)據(jù)架構(gòu)以及對(duì)機(jī)器學(xué)習(xí)類(lèi)應(yīng)用的原生API級(jí)別的支持。隨著各個(gè)項(xiàng)目逐步完成了初始設(shè)計(jì)目標(biāo)，他們都想進(jìn)一步擴(kuò)大適用場(chǎng)景，也都在進(jìn)入各自的領(lǐng)域，各個(gè)項(xiàng)目的快速發(fā)展也推動(dòng)著湖倉(cāng)一體架構(gòu)的快速迭代。專(zhuān)欄回顧【專(zhuān)欄 17】支持多模型數(shù)據(jù)分析探索的存算分離湖倉(cāng)一體架構(gòu)解析（上）【專(zhuān)欄 16】靈活、快捷、低運(yùn)維成本的數(shù)據(jù)集成方法：數(shù)據(jù)聯(lián)邦架構(gòu)【專(zhuān)欄 15】分析型數(shù)據(jù)庫(kù)：分布式分析型數(shù)據(jù)庫(kù)【專(zhuān)欄 14】分析型數(shù)據(jù)庫(kù)：MPP 數(shù)據(jù)庫(kù)的概念、技術(shù)架構(gòu)與未來(lái)發(fā)展方向【專(zhuān)欄 13】星環(huán)科技自研技術(shù)，加速大數(shù)據(jù)從持久化、統(tǒng)一化、資產(chǎn)化、業(yè)務(wù)化到生態(tài)化【專(zhuān)欄 12】分布式場(chǎng)景下，Apache YARN、Google Kubernetes 如何解決資源管理問(wèn)題？【專(zhuān)欄 11】分布式計(jì)算技術(shù)（下）：Impala、Apache Flink、星環(huán)Slipstream【專(zhuān)欄 10】分布式計(jì)算技術(shù)（上）：經(jīng)典計(jì)算框架MapReduce、Spark 解析【專(zhuān)欄 09】分布式存儲(chǔ)技術(shù)（下）：寬表存儲(chǔ)與全文搜索引擎的架構(gòu)原理、特性、優(yōu)缺點(diǎn)解析【專(zhuān)欄 08】分布式存儲(chǔ)技術(shù)（上）：HDFS 與 Ceph的架構(gòu)原理、特性、優(yōu)缺點(diǎn)解析
大數(shù)據(jù)開(kāi)放實(shí)驗(yàn)室由星環(huán)信息科技（上海）股份有限公司運(yùn)營(yíng)，專(zhuān)門(mén)致力于大數(shù)據(jù)技術(shù)的研究和傳播。若轉(zhuǎn)載請(qǐng)?jiān)谖恼麻_(kāi)頭明顯注明“文章來(lái)源于微信訂閱號(hào)——大數(shù)據(jù)開(kāi)放實(shí)驗(yàn)室”，并保留作者和賬號(hào)介紹。
??

本文使用 文章同步助手 同步