|
【譯者介紹】
導(dǎo)讀：One size does not fit all！ 數(shù)據(jù)處理平臺已不集中于傳統(tǒng)關(guān)系型數(shù)據(jù)庫，各種其他平臺層出不窮，也各有其適用范圍。 從哪些角度去理解各種數(shù)據(jù)處理平臺的設(shè)計(jì)思想及發(fā)展演進(jìn)呢？下面我們從幾個(gè)角度討論一下：
一、單機(jī)存儲引擎設(shè)計(jì)（數(shù)據(jù)的位置） 從某種意義上說，當(dāng)我們處理數(shù)據(jù)的時(shí)候，實(shí)際上是在管理數(shù)據(jù)的位置，管理數(shù)據(jù)在CPU的位置，數(shù)據(jù)相對其他數(shù)據(jù)的位置。CPU特別適合處理順序性操作數(shù)據(jù)指令，這樣他可以進(jìn)行數(shù)據(jù)預(yù)取。但是隨機(jī)讀取操作使得預(yù)取功能幾乎失效，好多預(yù)取到緩存、前端總線的數(shù)據(jù)都是無效的。 傳統(tǒng)意義上說，磁盤的存取性能要弱于內(nèi)存，但是要分隨機(jī)存取及順序存取不同的場景下討論。在流式順序處理場景，磁盤及SSD的讀取速度已經(jīng)超過內(nèi)存隨機(jī)讀取速度。 我們?nèi)绾伪M量實(shí)現(xiàn)數(shù)據(jù)的順序存取呢？讓我們設(shè)計(jì)一個(gè)很簡單的數(shù)據(jù)庫開始，存取一個(gè)文件。 1、數(shù)據(jù)存儲和更新 追加寫可以讓我們盡量保持順序存儲文件。但是當(dāng)數(shù)據(jù)要進(jìn)行更新的時(shí)候，有兩種選擇，一種是在數(shù)據(jù)原地進(jìn)行更新操作，這樣我們就有了隨機(jī)IO操作。另一種是把更新都放到文件末尾，然后需要讀取更新數(shù)據(jù)的時(shí)候進(jìn)行替換。 2、數(shù)據(jù)讀取 一下子讀取整個(gè)文件，也是很耗費(fèi)時(shí)間的事情，例如數(shù)據(jù)庫中的全表掃描。當(dāng)我們讀取文件中某一個(gè)字段時(shí)候，我們需要索引。索引的方式有多種，我們可以用一種簡單的固定數(shù)值大小的有序數(shù)組來做索引，數(shù)組里存的是當(dāng)前數(shù)據(jù)在文件中的存儲偏移量。還有其他索引技術(shù)，如hash索引，位圖索引等。 索引相當(dāng)于在數(shù)據(jù)之上又加了一層樹狀結(jié)構(gòu)，可以迅速的讀取數(shù)據(jù)。但是打破了我們前面講的數(shù)據(jù)的追加寫，這些數(shù)據(jù)都是根據(jù)索引隨機(jī)寫入的。在數(shù)據(jù)庫上建立索引的時(shí)候都會遇到這個(gè)問題，在傳統(tǒng)的機(jī)械式磁盤上，這個(gè)問題會造成1000倍的性能差異。 有三種方法可以解決上述問題： 1）把索引放到內(nèi)存中，可以隨機(jī)存儲和讀取，把數(shù)據(jù)順序存儲到硬盤上。MongoDB，Cassandra都是采取這種方式。這種方式有一個(gè)弊端是存儲的數(shù)據(jù)量受限于內(nèi)存的大小，數(shù)據(jù)量一大，索引也增大，數(shù)據(jù)就飽和了。 2）第二種方式是把大的索引結(jié)構(gòu)，拆成很多小的索引來存儲。在內(nèi)存中批量進(jìn)來的數(shù)據(jù)，當(dāng)積累到一個(gè)預(yù)定的量，就排序然后順序?qū)懙酱疟P上，本身就是一個(gè)小的索引，數(shù)據(jù)存儲完，最后加一塊小的全局索引數(shù)據(jù)即可。這樣讀取數(shù)據(jù)的時(shí)候，要遍歷一些小的索引，會有隨機(jī)讀取。本質(zhì)是用部分小的隨機(jī)讀換取了整體的數(shù)據(jù)順序存儲。我們通過在內(nèi)存中保存一個(gè)元索引或者Bloom filter來實(shí)現(xiàn)處理那些小索引的低延遲。 日志結(jié)構(gòu)的歸并樹（log structed merge tree, 簡稱LSM tree）是一種典型的實(shí)現(xiàn)，有三個(gè)特征： a)一組小的、不變的索引集。 b)只能追加寫 ，合并重復(fù)的文件。 c)少量的內(nèi)存索引消耗換來讀取的性能提升。這是一種寫優(yōu)化索引結(jié)構(gòu)。 HBase、Cassandra、Bigtable都是通過這種比較小的內(nèi)存開銷來實(shí)現(xiàn)讀取和存儲的平衡 3）列式存儲或者面向列的存儲（暴力方式）。 純列式存儲和谷歌bigtable那種列式存儲還是有所不同的，大家最好分開來看，雖然占用了同一個(gè)名字。列式存儲很好理解，就是把數(shù)據(jù)按照列順序存儲到文件中，讀取的時(shí)候只讀需要的列。列式存儲需要保持每一列數(shù)據(jù)都有相同的順序，即行N在每一列都有相同的偏移。這很重要，因?yàn)橥徊樵冎锌赡芤祷囟鄠€(gè)列的數(shù)據(jù)，同時(shí)可能我們要對多列直接進(jìn)行連接。每一列保持同樣的順序我們可以用非常簡單的循環(huán)實(shí)現(xiàn)上述操作，且都是高效的CPU和緩存操作。 列式存儲的缺點(diǎn)是更新數(shù)據(jù)的時(shí)候需要更新每一個(gè)列文件中的相應(yīng)數(shù)據(jù)，一個(gè)常用的方法就是類似LSM那種批量內(nèi)存寫的方式。 當(dāng)查詢只是返回某幾列數(shù)據(jù)，列式存儲可以大規(guī)模減少磁盤IO。除此之外，列式存儲的數(shù)據(jù)往往屬于同一類型，可以進(jìn)行高效的壓縮，一些低延遲，高壓縮率的掃描寬度、位填充算法都試用。即使對于未壓縮的數(shù)據(jù)流，同時(shí)可以進(jìn)行針對其編碼格式的預(yù)取。 列式存儲尤其適用于大表掃描，求均值、最大最小值、分組等聚合查詢場景。 列式存儲天然的保持了一列中數(shù)據(jù)的順序性，方便兩列數(shù)據(jù)進(jìn)行關(guān)聯(lián)，而heap-file index結(jié)構(gòu)關(guān)聯(lián)時(shí)候，一份數(shù)據(jù)可以按順序讀取，則另一份數(shù)據(jù)就會有隨機(jī)讀取了。 典型優(yōu)勢總結(jié)：
上面討論的數(shù)據(jù)順序存取的幾種方案，在很多數(shù)據(jù)處理平臺的最優(yōu)技術(shù)方案中大都有參考。 通過heap-file結(jié)構(gòu)把索引存儲在內(nèi)存，是很多NoSQL數(shù)據(jù)庫及一些關(guān)系型數(shù)據(jù)庫的首選，例如Riak，CouchBase和MongoDB，模型簡單并且運(yùn)行良好。 要處理更大量的數(shù)據(jù)，LSM技術(shù)應(yīng)用更為廣泛，提供了同時(shí)滿足高效存儲和讀取效率的基于磁盤的存取結(jié)構(gòu)。HBase、Cassandra、RocksDB, LevelDB，甚至MongoDB最新版也支持這種技術(shù)。 列式存儲在MPP數(shù)據(jù)庫里面應(yīng)用廣泛，例如RedShift、Vertica及hadoop上的Parquet等。這種結(jié)構(gòu)適合需要大表掃描的數(shù)據(jù)處理問題，數(shù)據(jù)聚合類操作（最大最小值）更是他的主戰(zhàn)場。 Kafka 通過追加式的文件或者預(yù)定義的offset集來存儲消息隊(duì)列。你來消費(fèi)消息，或者重新消費(fèi)消息都是很高效的順序IO操作。這和其他的消息中間件架構(gòu)上有所不同，JMS和AMQP都需要上面提到過的額外的索引來管理選擇器和session信息。他們最終性能表現(xiàn)像一個(gè)數(shù)據(jù)庫而非文件。 為滿足讀和寫不同業(yè)務(wù)場景的優(yōu)化，以上這些技術(shù)多少都有某些方面的折中，或者把問題簡化，或者需要硬件支持，作為一種拓展的方法。 二、分布式集群存儲設(shè)計(jì)（并行化） 把數(shù)據(jù)放到分布式集群中運(yùn)算，有兩點(diǎn)最為重要：分區(qū)（partition）和副本（replication）。 分區(qū)又被稱為sharding，在隨機(jī)訪問和暴力掃描任務(wù)下都表現(xiàn)不錯(cuò)。 通過hash函數(shù)把數(shù)據(jù)分布到多個(gè)機(jī)器上，很像單機(jī)上使用的hashtable，只不過這兒每一個(gè)數(shù)據(jù)桶都被放到了不同的機(jī)器上。 這樣可以通過hash函數(shù)直接去存儲數(shù)據(jù)的機(jī)器上把數(shù)據(jù)取出來，這種模式有很強(qiáng)的擴(kuò)展性，也是唯一可以根據(jù)客戶端請求數(shù)線性擴(kuò)展的模式。請求會被獨(dú)立分發(fā)到某一機(jī)器上單獨(dú)處理。 我們通過分區(qū)可以實(shí)現(xiàn)批量任務(wù)的并行化，例如聚合函數(shù)或者更復(fù)雜的聚類或者其他機(jī)器學(xué)習(xí)算法，我們通過廣播的方式在所有機(jī)器上使任務(wù)同時(shí)執(zhí)行。我們還可以運(yùn)行分治策略來使得高計(jì)算的任務(wù)在一個(gè)更短的時(shí)間內(nèi)解決。 這種批處理系統(tǒng)在處理大型的計(jì)算問題時(shí)有不錯(cuò)的效果，但只能提供有限并發(fā),，因?yàn)閳?zhí)行任務(wù)時(shí)會非常消耗集群的資源。 所以分區(qū)方式在兩個(gè)極端情況非常簡單：
二級索引是指不是構(gòu)建在主鍵上的索引，意味著數(shù)據(jù)不會因?yàn)樗饕闹刀M(jìn)行分區(qū)。不能直接通過hash函數(shù)去路由到數(shù)據(jù)本身。我們必須把請求廣播到所有節(jié)點(diǎn)上，這樣會限制了并發(fā)性，每一個(gè)請求都會卷入所有的節(jié)點(diǎn)。 因此好多基于key-value的數(shù)據(jù)庫拒絕引入二級索引，雖然它很有價(jià)值，例如Hbase和Voldemort。 也有些數(shù)據(jù)庫系統(tǒng)包含它了，因?yàn)樗杏?，例如Cassandra、MongoDB、Riak等。重要的是我們要理解好他的效益及他對并發(fā)性所造成的影響。 解決上述并發(fā)性瓶頸的一個(gè)途徑是數(shù)據(jù)副本，例如異步從數(shù)據(jù)庫和Cassandra、MongoDB中的數(shù)據(jù)副本。 實(shí)際上副本數(shù)據(jù)可以是透明的（只是數(shù)據(jù)恢復(fù)時(shí)候使用）、只讀的（增加讀的并發(fā)性），可讀寫的（增加分區(qū)容錯(cuò)性）。這些選擇都會對系統(tǒng)的一致性造成影響，這是CAP理論中的一個(gè)研究課題（也許CAP理論不像你想象中的那么簡單）。 這些對一致性的折中，給我們帶來一個(gè)值得思考的問題？一致性到底有什么用？ 實(shí)現(xiàn)一致性的代價(jià)非常昂貴。在數(shù)據(jù)庫中是用串行化來保證ACID的。他的基本保證是所有操作都是順序排列的。這樣實(shí)現(xiàn)起來的代價(jià)非常昂貴，所以好多關(guān)系型數(shù)據(jù)庫也不把他當(dāng)成默認(rèn)選項(xiàng)。 所以說要想在包含分布式寫操作的系統(tǒng)上實(shí)現(xiàn)強(qiáng)一致性，如同墜入深淵。（補(bǔ)充說明，Consistency, 在ACID和CAP中同時(shí)出現(xiàn)，但是意義不一樣，我這兒說的是在CAP中的定義：所有的節(jié)點(diǎn)在同一時(shí)間看到的是同樣的數(shù)據(jù)） 解決一致性問題的方案也很簡單，避免他。假如不能避免它把他隔離到盡可能少的寫入和盡可能少的機(jī)器上。 避免一致性問題其實(shí)很簡單，尤其是你的數(shù)據(jù)是一串不再改變的事實(shí)描述。web日志就是一個(gè)很好的例子，不用擔(dān)心一致性問題，因?yàn)槿罩敬嫦聛砗缶褪遣蛔兊氖聦?shí)描述。 當(dāng)然有些業(yè)務(wù)場景是必須要保證數(shù)據(jù)一致性的，例如銀行轉(zhuǎn)賬時(shí)候。有些業(yè)務(wù)場景感覺上是必須保持一致性的，但實(shí)際上不是，例如標(biāo)記一個(gè)交易是否有潛在的欺詐，我們可以先把它更新到一個(gè)新的字段里面，另外再用一條單獨(dú)的記錄數(shù)據(jù)去關(guān)聯(lián)最開始的那個(gè)交易。 所以對一個(gè)數(shù)據(jù)平臺來說有效的方式是去避免或者孤立需要一致性的請求，一種孤立的方法是采取單一寫入者的策略，Datamic就是典型的例子。另一種物理隔離的方法就是去區(qū)分請求中可變和不可變的字段，分別查詢。 Bloom/CALM把這種理念走的更遠(yuǎn)，默認(rèn)的配置選項(xiàng)就是無序執(zhí)行的策略，只有在必要的時(shí)候才啟用順序執(zhí)行讀寫語句。 前面是我們必須考慮的一些點(diǎn)，現(xiàn)在思考如何把這些設(shè)計(jì)組裝在一起做成一個(gè)數(shù)據(jù)處理平臺? 三、架構(gòu) 1、命令查詢職責(zé)分離架構(gòu)（CQRS） 最常用的架構(gòu)就是用傳統(tǒng)關(guān)系型數(shù)據(jù)庫存取數(shù)據(jù)，上層承接各種應(yīng)用。這種架構(gòu)會遇到一些瓶頸，比如當(dāng)數(shù)據(jù)吞吐量大到一定程度，就會遇到消息傳遞、負(fù)載均衡、擴(kuò)容、并發(fā)性能降低等問題。為保持ACID特性，擴(kuò)容問題尤其嚴(yán)峻。 一種解決方案是CQRS（Command Query Responsibility Segregation)，命令查詢職責(zé)分離）架構(gòu)，該模式從業(yè)務(wù)上分離修改 (Command，增，刪，改，會對系統(tǒng)狀態(tài)進(jìn)行修改)和查詢（Query，查，不會對系統(tǒng)狀態(tài)進(jìn)行修改)的行為。從而使得邏輯更加清晰，便于對不同部分進(jìn)行針對性的優(yōu)化。 還有一種簡單的方式是把讀和寫的請求進(jìn)行分離，寫數(shù)據(jù)側(cè)進(jìn)行寫優(yōu)化處理，類似于日志文件結(jié)構(gòu)。讀數(shù)據(jù)側(cè)進(jìn)行讀優(yōu)化處理。比較代表性的實(shí)現(xiàn)如Oracle的GoldenGate和MongoDB的Replica Sets . 還有一些數(shù)據(jù)庫，采用增加一層引擎的方式來實(shí)現(xiàn)上述思想。Druid就是一個(gè)很典型的例子，他是一個(gè)開源的、分布式的、實(shí)時(shí)的、列式存儲的分析引擎。列式存儲特別適合需要加載大的數(shù)據(jù)塊，且數(shù)據(jù)塊分到多個(gè)文件中的場景。Druid把一些近線實(shí)時(shí)數(shù)據(jù)放到寫優(yōu)化的存儲中，然后隨著時(shí)間的推移逐步把這些數(shù)據(jù)遷移到讀優(yōu)化的存儲中。當(dāng)Druid接收到請求，會同時(shí)把請求轉(zhuǎn)發(fā)給讀、寫優(yōu)化的存儲，然后把返回的查詢結(jié)果根據(jù)時(shí)間標(biāo)記進(jìn)行排序反饋給用戶。像Druid這 種類似的系統(tǒng)，通過一層抽象實(shí)現(xiàn)了CQRS的優(yōu)點(diǎn)。
2、操作/分析橋（Operational/Analytic Bridge）架構(gòu) 另一種相似的處理方式是操作/分析橋（Operational/Analytic Bridge），讀和寫優(yōu)化視圖被事件流所區(qū)分，數(shù)據(jù)流的狀態(tài)是被永久保存的，所以異步視圖可以通過后來的更新被重組或增強(qiáng)。 這樣前端模塊可以提供同步的讀和寫，這樣可以簡單高效的讀取剛被寫入的數(shù)據(jù)，或者保持復(fù)雜的ACID事物管理。 后端模塊利用異步性、狀態(tài)不變性、去擴(kuò)展離線處理進(jìn)程，具體方式可以采用副本、異化、或者完全使用不同的存儲引擎。信息橋，連接前端與后端，允許上層應(yīng)用使用訪問數(shù)據(jù)處理平臺的數(shù)據(jù)。 這種模試比較適合中級數(shù)量的部署，尤其是至少包含部分的、不可 避免的動態(tài)視圖請求。
3、批處理架構(gòu)（Hadoop） 如果我們的數(shù)據(jù)是一次寫入，多次讀，不在改變的場景，上面可以部署各種復(fù)雜的分析型應(yīng)用。采取批處理模式的hadoop無疑是這種平臺最廣用和出色的代表了。 Hadoop平臺提供快速的讀寫訪問，廉價(jià)的存儲，批處理流程，高吞吐信息流，和其他抽取、分析、處理數(shù)據(jù)的工具。 批處理平臺可以主動拉取或者被推進(jìn)來多種數(shù)據(jù)源的數(shù)據(jù)，將其存儲進(jìn)HDFS，后續(xù)可以處理成多種優(yōu)化的數(shù)據(jù)格式。數(shù)據(jù)可以被壓縮，清洗，去結(jié)構(gòu)化，聚合，處理為一種讀優(yōu)化的格式例如Parquet，或者直接被加載到數(shù)據(jù)服務(wù)層或者數(shù)據(jù)集市。通過這些過程，數(shù)據(jù)可以被查詢或者處理。 這種結(jié)構(gòu)在大批量的、數(shù)據(jù)不再改變的場景表現(xiàn)良好，一般可以到100TB以上，這種結(jié)構(gòu)的進(jìn)化是緩慢的，數(shù)據(jù)處理速度一般也是以小時(shí)為單位的。 4、lambda架構(gòu) 有時(shí)候我們并不想等待小時(shí)后才得到結(jié)果，這是該架構(gòu)的一個(gè)缺陷。一種解決方法就是加一個(gè)流處理層，就是常說的lambda架構(gòu)。 lambda架構(gòu)在批處理的架構(gòu)上增加了一個(gè)流處理層，如同在一個(gè)擁擠城鎮(zhèn)新建一條高架橋。流處理層可以用主流的Storm或者Samza實(shí)現(xiàn)。lambda架構(gòu)的本質(zhì)是可以快速的返回一個(gè)近似的結(jié)果，精確的結(jié)果在后續(xù)返回。 所以流處理旁路提供一個(gè)流處理窗口期內(nèi)最好的結(jié)果，可以先被上層應(yīng)用所使用，后續(xù)批處理流程計(jì)算出精確結(jié)果在覆蓋掉前面的近似結(jié)果。這種架構(gòu)是對精準(zhǔn)度和反饋時(shí)間做了一個(gè)聰明的平衡，作為后續(xù)發(fā)展，Spark平臺同時(shí)提供了批處理和流處理模塊(雖然流處理實(shí)際上市用微型批處理來實(shí)現(xiàn)的）。這種架構(gòu)也可以滿足 100TB以上數(shù)據(jù)的處理。 這種架構(gòu)的另一種代表叫kappa架構(gòu)，但是本文作者沒看中那種架構(gòu)，覺得叫kappa屬于吃飽了撐的。 5、流式處理架構(gòu) 不像是批處理架構(gòu)，把數(shù)據(jù)存儲到HDFS上，然后在上面執(zhí)行各種跑批任務(wù)。流處理架構(gòu)把數(shù)據(jù)存儲到可擴(kuò)展的消息或者日志隊(duì)列，例如kafka，這樣數(shù)據(jù)就可以被實(shí)時(shí)的處理成三級視圖、索引, 被數(shù)據(jù)服務(wù)層或者數(shù)據(jù)集市供上層應(yīng)用使用。 這和去掉批處理層的lambda架構(gòu)很相似，在消息層可以存儲處理海量的數(shù)據(jù)，有足夠強(qiáng)大的流處理引擎可以hold住這些數(shù)據(jù)處理進(jìn)程。 流處理結(jié)構(gòu)可以用來解決“應(yīng)用集成”問題，這是個(gè)頭疼復(fù)雜的問題，IT傳統(tǒng)大佬：Oracle，Tibco，Informatica都曾經(jīng)試圖想解決，一些部分結(jié)果是有用的，但不是真的解決，始終在尋找一套真正可用的解決方案。 流式處理平臺提供了一種解決該問題的可能性，他繼承了O/A橋平臺的優(yōu)點(diǎn)：多樣化的異步存儲形式和重新計(jì)算視圖的能力，把一致性請求給隔離。系統(tǒng)保存的數(shù)據(jù)是日志的話，很天然的擁有不變性。Kafka可以保存高容量和吞吐量的歷史記錄，意味著可以重新計(jì)算數(shù)據(jù)狀態(tài)，而不是持續(xù)的設(shè)置檢查點(diǎn)。 類似流處理架構(gòu)的工具還有Goldengate，用來向大型數(shù)據(jù)倉庫同步數(shù)據(jù)，不過他在數(shù)據(jù)副本層缺乏高吞吐量支持，在數(shù)據(jù)模型管理層過于復(fù)雜。 四、小結(jié)： 我們開始于數(shù)據(jù)的位置，用來讀寫數(shù)據(jù)的順序地址，從而說明了我們用到組件對該問題的折衷。我們討論了對一些組件的拓展，通過分區(qū)和副本構(gòu)建分布式的數(shù)據(jù)處理平臺。最后我們闡述了觀點(diǎn)：盡量在數(shù)據(jù)處理平臺中把一致性的請求隔離。 數(shù)據(jù)處理平臺自身也是一個(gè)動態(tài)調(diào)整變化的平臺，依據(jù)業(yè)務(wù)需求，會把寫優(yōu)化轉(zhuǎn)為讀優(yōu)化，把強(qiáng)一致性依賴轉(zhuǎn)為開放的流式、異步、不變的狀態(tài)。 有些東西我們必須留在思想中，順序的結(jié)構(gòu)化模式是一種，時(shí)序、分布式、異步是另一種。 我們要堅(jiān)信：經(jīng)過認(rèn)真的解決，這些問題都是可控的。
附（知識補(bǔ)充）： 簡單介紹一下heap-file結(jié)構(gòu)（和鏈表結(jié)構(gòu)很相似）：
下面是Heap file自有的一些特性：
頁面可以被分割在某個(gè)存儲體的不同的物理區(qū)域，也可以分布在不同的存儲體上，甚至是不同的網(wǎng)絡(luò)節(jié)點(diǎn)中。我們可以簡單假設(shè)每一個(gè)page都有一個(gè)唯一的地址標(biāo)識符PageAddress，并且操作系統(tǒng)可以根據(jù)PageAddress為我們定位該P(yáng)age。 一般情況下，使用page在其所在文件中的偏移量就可以表示了。 |
|
|
