譯注：本文是作者今年在 Progscon & JAX Finance 大會(huì )上的同名主題演講《Elements of Scale: Composing and Scaling Data Platforms》。
@何_登成 的推薦語(yǔ)：此文很長(cháng)，但長(cháng)而不臭，而且配圖非常Q。作者以簡(jiǎn)潔易懂的文字，將數據庫設計中應該考慮的存儲、并行、架構等問(wèn)題做了詳細的闡述。
作為軟件工程師，不可避免地受到周?chē)嬎銠C工具的影響，語(yǔ)言、框架、甚至執行過(guò)程都會(huì )影響我們構建的軟件。
數據庫亦如此，基于一種特殊的方式，不可避免地影響到我們對應用程序中易變和共享狀態(tài)的處理。
過(guò)去的十多年，我們采用不同的方式去探尋這個(gè)世界。采用不同理念的一小眾開(kāi)源項目，它們不斷成長(cháng)，你中有我，我中有你。平臺集成了這些工具，每個(gè)控件通常都能提高某些基礎硬件或者系統效能。結果是平臺無(wú)法通過(guò)任何單一的工具解決某些問(wèn)題，不是太過(guò)笨重，就是局限于某一特定部分。
因此當今數據平臺多種多樣，從簡(jiǎn)單的緩存層、多語(yǔ)言持久化層到整個(gè)集成數據管道，針對多種特定需求的多種解決方案。在某些方面，確實(shí)有不錯的表現。
因此本對話(huà)的目的就是解釋一些流行的方式方法如何發(fā)揮作用，為什么會(huì )有如此表現。我們先來(lái)考慮組成它們的基本元素，這樣便于在后續的討論中對這些認識通盤(pán)地考慮。
從某種抽象的角度看，當我們處理數據時(shí)，實(shí)際上就是對其進(jìn)行局部性(locality)處理，局部性到CPU、局部性到我們需要的其它數據。有序地獲取數據是其中很重要的部分，計算機很擅長(cháng)序列化的操作，這些操作是可以預測的。
（譯者注：局部性是計算機中一種預測行為，通過(guò)緩存、內存中預取指令、處理器管道分支預測等技術(shù)來(lái)提高性能；更多參見(jiàn)《操作系統精髓與設計原理》。）
若是有序地從硬盤(pán)中獲取數據，數據會(huì )預獲取存入硬盤(pán)緩存、頁(yè)緩存、以及不同層級的CPU緩存中，這可以極大地提升性能。但這對隨機數據尋址意義不大，這些數據存于主內存、硬盤(pán)或者網(wǎng)絡(luò )中。實(shí)際上，預獲取反倒會(huì )拉低隨機負載能力：不論是各種緩存或是前端總線(xiàn)，充滿(mǎn)了不太會(huì )被用到的數據。
硬盤(pán)通常被認為性能稍低，而主內存稍快些。這種認識不見(jiàn)得一直是對的，隨機和有序主內存負載之間相差一兩個(gè)數量級。用某種語(yǔ)言管理內存，事情往往會(huì )變得更加糟糕。
從硬盤(pán)有序獲取的數據流性能確實(shí)好過(guò)隨機尋址主內存，或許硬盤(pán)并不像我們想的那樣跟烏龜似的，至少在有序獲取的情況不會(huì )很慢。固態(tài)盤(pán)(SSD),特別是采用PCIe接口，正如它們顯示不同的權衡，將事情復雜化。但采用這兩種獲取模式帶來(lái)的緩存收益是不變的。
譯者注：數據流就是大量連續到達的、潛在無(wú)限的有序數據序列，這些數據按順序存取并被讀取一次或有限次。
假設我們要創(chuàng )建一個(gè)簡(jiǎn)單的數據庫，首先從基礎部分文件開(kāi)始。
保持有序讀和寫(xiě)，文件在硬件上會(huì )表現地很好。我們可以將寫(xiě)入的數據放入文件的末尾，可以通過(guò)掃面整個(gè)文件進(jìn)行數據讀取。任何我們希望的處理過(guò)程可以隨著(zhù)數據流穿過(guò)CPU而成真，比如過(guò)濾，聚合、甚至做一些更復雜的操作，總之非常完美。
倘如數據發(fā)生諸如更新這樣的變化會(huì )怎樣？
我們有多個(gè)選擇，在某個(gè)位置更新這個(gè)值。我們需要利用固定長(cháng)度的字段，在我們淺顯的思想實(shí)驗中這是沒(méi)有問(wèn)題的。不過(guò)在某個(gè)位置更新數據意味著(zhù)隨機輸入輸出流(IO)，這會(huì )影響性能。
替代的辦法是將更新值放置在文件的末尾，在讀取值時(shí)對過(guò)期的數據進(jìn)行處理。
我們第一次做出權衡，將“日記”或者“日志”放在文件末尾，就能保證有序獲取進(jìn)而提高性能。另外倘若某處需要更新數據，可以實(shí)現每秒300次左右的讀取，前提是更新數據刷入底層介質(zhì)中。
實(shí)際上完整的讀取文件是很慢的，獲取十億字節(GB)數據，最好的硬盤(pán)也需要花費數秒，這是一個(gè)數據庫全表掃描所花費的時(shí)間。
我們時(shí)常只需要一些特定的數據，比如名為“bob”的客戶(hù)，這時(shí)掃描整個(gè)文件就不妥當，我們需要一個(gè)索引。
我們可用許多不同類(lèi)型的索引，最簡(jiǎn)單的一種是固定長(cháng)度的有序數組，比如本例中的客戶(hù)名，和對應的偏移量一起存放在一個(gè)堆文件中。有序數組可以進(jìn)行二進(jìn)制搜索查找。同樣，我們可以用樹(shù)結構、位圖索引、哈希索引、字典索引等。這里是一個(gè)樹(shù)的結構圖。
索引就像是在數據中添加了一個(gè)總覽結構，值是有序排放的，這樣我們就能快速獲取我們想要讀取的數據。但總覽結構有個(gè)問(wèn)題，數據進(jìn)來(lái)時(shí)需要隨機寫(xiě)。因此理想的、寫(xiě)優(yōu)化僅僅追加文件；考慮到寫(xiě)會(huì )打散文件系統，這會(huì )使一切變慢。
如果你將許多索引放入一個(gè)數據庫表中，那你一定熟悉這個(gè)問(wèn)題。假定我們使用的機械盤(pán)，用這種方式維護某個(gè)索引的硬盤(pán)完整性，速度大約慢1000倍。
幸運的是，這里有幾種解決方案。這里我們討論三種，它們都是一些極端地例子。在現實(shí)世界中，遠沒(méi)有這么復雜，但在考慮海量存儲時(shí)這些概念會(huì )特別有用。
譯者加：
第一種內存映射文件
第二種較小的索引集合，采用元索引或者布隆過(guò)濾算法(Bloom Filter)做一些優(yōu)化
第三種簡(jiǎn)單匹配算法(brute force)又叫面向列(Column Oriented)
第一種方案是將索引放入主內存，隨機寫(xiě)問(wèn)題分隔到隨機存儲存儲器(RAM)，堆文件依舊在硬盤(pán)中。
這是一種簡(jiǎn)單但行之有效的方案，可以解決我們隨機寫(xiě)的問(wèn)題。這種方式在許多數據庫中已得到應用，比如MongoDB、Cassandra、Riak、以及其他采用此優(yōu)化類(lèi)型的數據庫，它們常常用到內存映射文件。
譯者注：內存映射文件是虛擬內存單個(gè)分段，可以與文件或者類(lèi)文件資源的某部分建立直接字節對字節的關(guān)聯(lián)，即文件中的數據存放位置在內存中有對應的地址空間，這時(shí)對文件的讀寫(xiě)可以直接用指針來(lái)做，而不需要read/write函數，處理大文件時(shí)可以顯著(zhù)提高輸入輸出流(IO)性能。
倘若數據量遠超主內存，這種策略就失效了。特別是存在大量小的對象時(shí)，問(wèn)題特別顯眼；索引增長(cháng)很大，最后存儲越過(guò)了可用主內存的容量。多數情況下，這樣做是沒(méi)有問(wèn)題的，但如果存在海量數據，這樣做就會(huì )成為一種負擔。
一種流行的方式拋開(kāi)單個(gè)的“總覽”索引，轉而采用相對較小的索引集合。
這是一個(gè)簡(jiǎn)單的理念：數據進(jìn)來(lái)，我們批量地將其寫(xiě)入主內存。一旦內存數據足夠多，比如達到MB，我們就對它們進(jìn)行排序，而后將它們作為單個(gè)小的索引寫(xiě)入硬盤(pán)中。最后得到的是一個(gè)小的、由不變索引文件組成的年表。
那么這樣做的好處是？這些不變的文件集合被有序地流化處理，這樣就能快速地寫(xiě)，最重要的是無(wú)需將整個(gè)索引加載入內存中。真棒！
當然它也有一個(gè)缺點(diǎn)，當讀操作時(shí)需要詢(xún)問(wèn)非常多的小索引。我們將隨機IO(RandomIO)寫(xiě)問(wèn)題變?yōu)樽x問(wèn)題。不過(guò)這確實(shí)一個(gè)很好的權衡策略，而且隨機讀比隨機寫(xiě)更容易優(yōu)化。
存儲一個(gè)小的元索引(meta-index)在內存中或者采用布隆過(guò)濾算法(Bloom Filter)，提供一種低內存方式,評估單個(gè)索引文件在讀操作中是否需要被詢(xún)問(wèn)。即使保持快速地、有序化寫(xiě)操作，這種方式的讀操作性能幾乎可以和單個(gè)總覽索引相媲美。
實(shí)際開(kāi)發(fā)中，偶爾也需要清理孤子更新，但它有序讀和寫(xiě)確實(shí)不錯。
我們創(chuàng )建的這個(gè)結構稱(chēng)作日志結構合并樹(shù)(Log Structured Merge Tree),這種存儲方式在大數據工具中應用較大，如HBase、Cassandra、谷歌的BigTable等，它能用相對較小的內存開(kāi)銷(xiāo)平衡寫(xiě)、讀性能。
將索引存儲在內存中，或者利用諸如日志結構合并樹(shù)(Log Structured Merge Tree)這樣的寫(xiě)優(yōu)化索引結構，繞開(kāi)“隨機寫(xiě)懲罰”(random-write penalty)。這是第三種方案為純粹的簡(jiǎn)單匹配算法(Pure brute force)。
回到開(kāi)始的文件例子，完整地讀取它。如何處理文件中的數據，可以有許多選擇。簡(jiǎn)單匹配算法(brute force)通過(guò)列而非行來(lái)存儲數據，這種方法叫做面向列。
需要注意的是真實(shí)的列存儲及其遵循的大表模式(Big Table pattern)之間存在一種不好的命名術(shù)語(yǔ)沖突。盡管它們有一些相似的地方，事實(shí)上它們是不同的，所以將它們視為不同的事情是一件明智的。
面向列是一種簡(jiǎn)單的理念，和行存儲數據不同，通過(guò)列分割每一行，將數據追加到單個(gè)文件末尾。接著(zhù)在每個(gè)單獨的文件中存儲每一列，一旦需要只需讀取需要的列。
這樣可以確保文件的含有相同的序列，即每個(gè)列文件的第N行含有相同的地址或者偏移量。這個(gè)很重要，在某一時(shí)刻讀取多列，來(lái)服務(wù)一個(gè)單一的查詢(xún)。意味著(zhù)“連接(joining)”列速度飛快，倘若所有的列含有相同的序列，我們就能在一個(gè)緊湊的循環(huán)中這么做，此循環(huán)有很好緩存和CPU利用率。許多實(shí)現大量使用向量( vectorisation)進(jìn)一步優(yōu)化簡(jiǎn)單連接和過(guò)濾操作吞吐量。
寫(xiě)操作可以提高只在文件末尾追加( being append-only)性能。不利的地方是很多文件需要更新時(shí)，文件的每個(gè)列需要單獨寫(xiě)入數據庫。最常見(jiàn)的解決方案是采用類(lèi)似日志結構合并(LSM)方式，進(jìn)行批量化的寫(xiě)操作。許多列類(lèi)型的數據庫通過(guò)給表添加一個(gè)完整的序列來(lái)提升讀的性能。
通過(guò)列分割數據可以極大地減少從硬盤(pán)中讀取的數據量，只要查詢(xún)操作在所有的列的子集中。
除此之外，單獨列中的數據通?？梢院芎玫膲嚎s?？梢岳昧袛祿?lèi)型優(yōu)勢去壓縮，特別是在我們熟悉列的數據類(lèi)型時(shí)。這意味著(zhù)我們能利用有效的、低成本的編碼方式，比如行程長(cháng)度編碼、delta、位組合(bit-packed)等。對一些編碼來(lái)說(shuō)，謂詞可以直接用來(lái)做壓縮流。
一種簡(jiǎn)單匹配算法(brute force)特別適合大規模掃描操作，諸如平均值、最大值、最小值、分組等聚類(lèi)函數就是這方面的典型。
這和先前提到的“堆文件和索引(‘heap file & index)”方式不同，很好的理解這一點(diǎn)可以問(wèn)自己，諸如此類(lèi)的列方式和每一個(gè)字段帶有索引的“堆和索引”方式有什么不同？
問(wèn)題的關(guān)鍵是索引文件序列：多路查找樹(shù)（Btree）等會(huì )依據檢索的字段排序，兩次檢索的數據連接一端涉及流操作，另一端第二個(gè)索引位置進(jìn)行檢索隨機讀取。平衡樹(shù)總體上說(shuō)效率低于包含兩個(gè)相同序列索引列連接，我們再一次提高了序列化訪(fǎng)問(wèn)。
譯者注：結論是平衡樹(shù)連接性能不如兩個(gè)相同序列索引列連接
我們都想將最好的技術(shù)作為數據平臺控件，提升其中的某種核心功能，勝任一組特定的負載。
將索引存于內存而非堆文件為叢多非關(guān)系型數據庫(NoSQL)所喜愛(ài)，比如Riak、Couchbase或者M(jìn)ongodb，甚至一些關(guān)系型數據庫，這種簡(jiǎn)單的模型效果不錯。
設計用來(lái)處理海量數據集的工具樂(lè )意采用LSM方式，這樣可以快速獲取數據，得到基于硬盤(pán)結構 讀一樣好的性能。HBase、 Cassandra、RocksDB、 LevelDB 甚至Mongo現在也支持這種方式。
每個(gè)文件的列(Column-per-file)引擎常用于數據庫大規模并行處理(MPP)，比如Redshift或者Vertica，以及Hadoop stack中的Parquet。這些數據引擎最大的問(wèn)題是需要大的遍歷，聚合是這些工具最重要的特質(zhì)。
諸如卡夫卡(Kafka)采用一個(gè)簡(jiǎn)單的、基于硬件的高效消息規范。消息可以簡(jiǎn)單地追加到文件的末尾，或者從預定的偏移量處讀取?？梢詮哪硞€(gè)偏移量讀取消息，來(lái)來(lái)回回，你可以從上次結束的偏移量處讀取?？吹贸鍪呛懿诲e的有序輸入輸出(IO)。
這和多數面向消息的中間件不同，JMS(Java消息服務(wù))和AMQP(高級消息隊列協(xié)議)說(shuō)明文檔需要額外的索引，來(lái)管理選擇器和會(huì )話(huà)消息。這意味著(zhù)它們結束某個(gè)行為的方式更像數據庫，而非某個(gè)文件。著(zhù)名的論述是1995年Jim Gray發(fā)表的隊列就是數據庫(Queue’s are Databases).
可見(jiàn)所有的方式都需要這樣那樣的權衡，作為一種分布式手段，使事情變得簡(jiǎn)單、硬件更加用戶(hù)友好。
我們分析了存儲引擎的一些核心方法，其實(shí)只是做了一些簡(jiǎn)要說(shuō)明，現實(shí)世界這些是要復雜的多，不過(guò)概念確實(shí)是很有用的。分布式數據平臺不僅僅是一個(gè)存儲引擎，還需要考慮并行。
對于橫跨多臺計算機的分布式數據我們需要考慮兩個(gè)核心點(diǎn)，分區(partition)和復制(replication)。分區有時(shí)指的是分庫分表(sharding),在隨機讀取和簡(jiǎn)單匹配工作負載(brute force workloads)表現不俗。
如果是基于哈希的分區模型，借助哈希函數，數據就能均攤到一組機器上(譯者注：理想的結果是這樣的)。同哈希表工作方式相似，每個(gè)桶（bucket）盛放某個(gè)機器節點(diǎn)。
這樣通過(guò)哈希函數，直接訪(fǎng)問(wèn)包含此數據的機器讀取來(lái)數據。這是一種很經(jīng)典的分布式模式，也是唯一一種隨著(zhù)客戶(hù)端請求增加呈現線(xiàn)性分布的模式(譯者注：簡(jiǎn)單點(diǎn)說(shuō)就是均攤)。請求隔離到單臺計算機上，由集群中的單臺計算機為其服務(wù)。
利用分區提供并行批量計算，比如聚合函數或者諸如聚眾或者機器學(xué)習的復雜算法。最大的不同是所有的計算機在同一時(shí)刻采用廣播的方式，在很短的時(shí)間采用分治的策略解決大規模計算問(wèn)題。
批量處理系統很好地處理大規模問(wèn)題，但在執行過(guò)程中少有并發(fā)，容易耗盡集群資源。
兩個(gè)極端且特別簡(jiǎn)單的方式：一端直接訪(fǎng)問(wèn)，另一端分治地進(jìn)行廣播。需要注意的是終端之間的中間地帶，最好的例子就是非關(guān)系型數據庫(NoSQL)中跨越多臺計算機的二級索引。
二級索引有別于主鍵索引，這就意味著(zhù)數據分區不再借助索引中的值。不再使用哈希函數直接分發(fā)，而是廣播請求給所有的計算機。這會(huì )制約并發(fā)，任何一個(gè)節點(diǎn)與每一個(gè)請求都有關(guān)。
也是這個(gè)原因許多鍵值存儲不愿采用二級索引，即使它的應用很廣泛，Hbase和Voldemort就是如此。不過(guò)諸如MongoDb、Cassandra、Riak等數據庫采用二級索引，不管咋說(shuō)二級索引還是蠻有用的。但理解它們在整個(gè)系統并發(fā)的影響還是很重要的。
復制解決并發(fā)瓶頸，或許你熟悉備份，不論是異步到從服務(wù)器，還是復制到諸如Mongo或者Cassandra這樣的NoSQL存儲中。
實(shí)際上備份是不可見(jiàn)的(僅僅用于恢復)、只讀(增加并發(fā)量)、或者讀寫(xiě)(增加網(wǎng)絡(luò )分區下的可用性)，選擇哪種方式需要從系統的一致性出發(fā)做出權衡。這是CAP(Consistency、Availability、Partition-Tolerance）理論的簡(jiǎn)單應用，當然CAP理論遠非我們想象中的那么簡(jiǎn)單。
譯者注：網(wǎng)絡(luò )分區( network partitions)指某個(gè)網(wǎng)絡(luò )設備出錯導致網(wǎng)絡(luò )分離，比如某個(gè)數據庫掛掉。
權衡一致性給我們帶來(lái)一個(gè)重要的問(wèn)題，什么時(shí)候需要保證數據的一致性？
一致性的代價(jià)是昂貴，在數據庫的世界里，原子性由線(xiàn)性化(linearisabilty)做保障，這樣可以確保所有的操作有序排列.但代價(jià)也是昂貴的,實(shí)際上這完全是被禁止的，許多數據庫并不將此作為一個(gè)獨立(isolation)執行單元。鑒于此，很少將此設為默認值。
簡(jiǎn)而言之，你想分布式寫(xiě)的系統保持強一致性，系統會(huì )變慢。
注意一致性這個(gè)術(shù)語(yǔ)有兩個(gè)應用場(chǎng)景，在原子性和CAP中，當然其意思是不同的。我通常采用CAP中的定義，對所有的節點(diǎn)而言數據在某一時(shí)刻是相同的。
解決一致性問(wèn)題的方法其實(shí)很簡(jiǎn)單，就是避免它。如果無(wú)法避免，隔離它為其分配盡可能少的寫(xiě)操作和計算機資源。
避免一致性問(wèn)題一般不難，特別是數據為不變的事實(shí)流時(shí)，網(wǎng)絡(luò )日志集合就是一個(gè)很好的例子。無(wú)需關(guān)注一致性，因為這些日志作為事實(shí)是不會(huì )改變的。
需要一致性的用例，比如轉賬、使用優(yōu)惠碼這種非交換行為。
當然從傳統的眼光看一些事情需要一致性，但實(shí)際上卻也未必。比如一個(gè)行動(dòng)從一個(gè)可變狀態(tài)變成一個(gè)新的相關(guān)事實(shí)集合，就可以避免這種變化狀態(tài)。通常是直接對新字段進(jìn)行更新，考慮到標記一個(gè)事務(wù)存在潛在的欺詐，我們可以簡(jiǎn)單地利用某個(gè)事實(shí)流和原始的事務(wù)進(jìn)行關(guān)聯(lián)。
譯者：好觀(guān)點(diǎn)
在數據平臺中移除所有一致性需求、或者隔離它都是很有用的。一種隔離方式是利用單個(gè)寫(xiě)原則，涉及幾個(gè)方面，比如Datomic；另一種方式是拆分可變的和非可變的來(lái)隔離一致性需求。
諸如Bloom/CALM擴展了這些理念，支持默認狀態(tài)下的無(wú)序概念，除非需要才做排序。因此我們有必要做一些基本的權衡，那我們如何利用這些特性去建立一個(gè)數據平臺？
一個(gè)典型的應用架構或許應該是這樣的：有一組處理將數據寫(xiě)入某個(gè)數據庫，然后將其讀出，對于許多簡(jiǎn)單的工作負載這是沒(méi)有問(wèn)題的，許多成功的應用都是基于此模式。但隨著(zhù)吞吐量的增加，此模式越來(lái)越難以適用；在應用領(lǐng)域這個(gè)問(wèn)題或許可以通過(guò)消息傳遞、演員(actors)、負載均衡加以解決。
另外一個(gè)問(wèn)題是這種方式將數據庫作為一個(gè)黑盒，數據庫是一個(gè)透明的軟件。它們提供了海量的特征，但也提供了極少的原子拆分的機制。這樣做有很多好處，默認狀態(tài)下是安全的；但保護過(guò)度地扼殺我們的需求進(jìn)而限制系統的分布式，這就很煩人。
命令查詢(xún)職責分離(CQRS Command Query Responsibility Segregation)可以簡(jiǎn)單地解決此問(wèn)題。
譯注：
實(shí)現一Druid
實(shí)現二操作分析橋(Operational/Analytic Bridge)
實(shí)現三批量管道
實(shí)現四拉姆達框架(Lambda Architecture)
實(shí)現五卡帕(Kappa)框架又叫流數據平臺
想法其實(shí)很簡(jiǎn)單，分離讀寫(xiě)工作負載：最佳寫(xiě)入狀態(tài)時(shí)寫(xiě)入，最切貼的例子比如某個(gè)簡(jiǎn)單日志文件；最佳讀取狀態(tài)時(shí)讀取。有多種實(shí)現方式，比如用于關(guān)系型數據庫的Goldengate工具、內部復制集成的諸如MongoDB的Replica Sets這樣的產(chǎn)品。
許多數據庫底層的行為就是這樣，Druid是一個(gè)不錯的例子，它是一個(gè)開(kāi)源的、分布式、時(shí)序化、列式分析引擎。列式存儲表現不俗，特別是大規模數據錄入，數據必須分散到許多文件中。為了得到更好的寫(xiě)性能，Druid存儲近期的新數據到某個(gè)最佳寫(xiě)入狀態(tài)中，然后逐漸轉移到最佳讀取存儲狀態(tài)。
一旦查詢(xún)Druid，請求就會(huì )同時(shí)派發(fā)到最佳寫(xiě)和最佳讀控件中，對結果進(jìn)行組合(移除冗余)，返回給用戶(hù)。Druid借助時(shí)間標記每條記錄來(lái)進(jìn)行排序。
諸如此類(lèi)的組合方式提供了單個(gè)抽象下的CQRS好處。
另一種相似的方式是操作分析橋(Operational/Analytic Bridge),利用單個(gè)事件流拆分最佳讀以及最佳寫(xiě)視圖。流處在一種不斷變化的狀態(tài)，因此異步視圖可以在隨后的日子里被重寫(xiě)和增強。
前端提供了同步讀和寫(xiě)，這么做即可以簡(jiǎn)單快速地讀取已寫(xiě)入的數據，又可以支持復雜的原子事務(wù)。
后端采用異步、不變狀態(tài)的優(yōu)勢來(lái)提高性能，比如借助復制、反范式化、甚至完全不同的存儲引擎擴展線(xiàn)下處理。前后端之間的消息橋連方便應用通過(guò)平臺去監聽(tīng)數據流。這種模型很適合中等規模的部署，可變視圖至少存在一部分、不可避免的需求。
設計不變的狀態(tài)，以便容易地去支持大規模數據集和更加復雜的分析。Hadoop棧中獨一無(wú)二的實(shí)現——批量管道，就是一個(gè)典型的例子。
Hadoop棧最精彩的地方就是其叢多的工具，不管是快速讀寫(xiě)訪(fǎng)問(wèn)、還是廉價(jià)地存儲、抑或批量處理、高吞吐消息、或者提取、處理、分析數據，hadoop生態(tài)體系應有盡有。
批量管道從多種資源中獲取數據，將其放入HDFS，接著(zhù)對其進(jìn)行處理，進(jìn)而提供一個(gè)原始數據持續優(yōu)化的版本。
數據可能得到富集、清理、反范式化、聚集、移到一個(gè)諸如Parquet的最佳讀模式，或者加載進(jìn)服務(wù)器層或者數據集市，處理之后的數據可以被檢索和處理。
此框架適用于不變數據、以及對數據進(jìn)行大規模獲取和處理，比如100太字節(TBs)。此框架處理過(guò)程很緩慢，以小時(shí)為單位。
批量管道的問(wèn)題是通常我們不想等幾個(gè)小時(shí)去獲取一個(gè)結果。常見(jiàn)的做法是添加一個(gè)流層，有時(shí)又叫拉姆達框架(Lambda Architecture)。
拉姆達框架保留了批量管線(xiàn)，不過(guò)增加了快速流層實(shí)現迂回，就像在忙亂的小鎮架了一個(gè)支路，流層采用諸如Storm、Samza流處理工具。
拉姆達框架核心是我們最樂(lè )意快速粗略作答的，但我想在最后做一個(gè)精確的回答。
流層繞過(guò)了批量層，提供了最佳回答，它的核心就在流視圖中。這些會(huì )寫(xiě)入一個(gè)服務(wù)器層。稍好批量管道計算出精確的數據并覆蓋之前的值。
用響應來(lái)平衡精度是個(gè)不錯的做法，兩個(gè)分支在流和批量處理層都有編碼，這種模式的一些實(shí)現是有問(wèn)題的。解決辦法，一是將此邏輯簡(jiǎn)單抽象到一個(gè)可復用的通用庫中，比如處理都寫(xiě)入了諸如Python、R語(yǔ)言這樣的外源庫中。二是諸如Spark這樣的系統同時(shí)提供了流和批量處理功能，當然spark中的流只是少量的批處理。
因此這種模式適合比如100TB的海量數據平臺，將流和已存、富集的、批量分析函數結合起來(lái)。
另外一種解決慢數據管道的方式，稱(chēng)之為卡帕(Kappa)框架。起初我以為這個(gè)架構名稱(chēng)不對，現在我不太確定。不管它是什么，我叫它流數據平臺，其實(shí)這個(gè)已經(jīng)有人這么叫了。
流數據平臺相對批量模式更有優(yōu)勢：與將數據存儲在HDFS中劃分給新的批量任務(wù)不同，數據分散存儲在消息系統或者諸如kafka日志中。批處理就變成了記錄系統，數據流經(jīng)過(guò)實(shí)時(shí)處理生成三層結構：視圖、索引、服務(wù)或者數據集市。
與拉姆達(lambda)框架的流層相似，不一樣的是沒(méi)有批處理層。顯然這就要求消息層能夠存儲、供應海量數據，并且具有強大有效的流處理器來(lái)處理此過(guò)程。
天下沒(méi)有免費的午餐，問(wèn)題很棘手，流數據平臺運行速度并沒(méi)有同等批量處理系統快多少。但將默認的方法“存儲和處理”切換為“流和處理”，可以極大地提高快速獲取結果的可能性。
流數據平臺方式還可以用來(lái)解決“應用集成”問(wèn)題，應用集成這個(gè)棘手的問(wèn)題困惑Informatica、Tibco和Oracle等大的供應商好多年了。對許多數據庫而言是有益的，但不是一種變革性方案。應用集成至今停留在找尋切實(shí)可行方案的話(huà)題上。
流數據平臺提供了一個(gè)潛在的解決方案：利用操作分析橋的叢多優(yōu)勢—多種異步存儲格式以及重新創(chuàng )建視圖的能力—但這會(huì )增加已有資源中一致性需求：
系統記錄變?yōu)槿罩?，易于增強數據的不變性。諸如Kafka等產(chǎn)品內部保留了足夠的數據量和吞吐量，將其作為歷史記錄來(lái)用。這就意味著(zhù)回復是一個(gè)重演、重新生成狀態(tài)的處理過(guò)程，而非常態(tài)化地檢驗。
相似的方式很在就有應用，早于最新出現的數據湖或者Goldengate等工具，后者將數據放入企業(yè)級數據倉庫。復制層缺乏吞吐量和管理復雜的schema變化使此方法大打折扣?？此谱詈蟮谝粋€(gè)問(wèn)題已經(jīng)解決，但作為最后一個(gè)問(wèn)題，還沒(méi)有定論。
回到局部性，讀和寫(xiě)按序尋址，是控件內部最需要權衡的部分。我們觀(guān)看了如何拓展這些控件，提高了分庫分表和復制最基本的性能。重新審視一致性將其作為一個(gè)問(wèn)題，在構建平臺時(shí)隔離它。
不過(guò)數據平臺本身需要用單一、全局的方式來(lái)平衡這些控件達到最佳狀態(tài)。不斷重建，從最佳寫(xiě)狀態(tài)遷移到最佳讀狀態(tài)，從一致性約束轉移到流、異步、不變狀態(tài)的開(kāi)放地帶。
需要記住幾件事，一是schema，二是時(shí)間、分布式、異步系統風(fēng)險。但這些問(wèn)題都是可控的，前提是你認真對待。未來(lái)大數據領(lǐng)域可能會(huì )出現這樣一些新的工具、革新，逐漸摻入到平臺中，解決過(guò)去和現在更多的問(wèn)題。
譯者注：schema 指數據庫完整性約束。
（點(diǎn)擊閱讀原文完整閱讀）
聯(lián)系客服
