連續(xù)兩篇文章都聊了不同的存儲格式，這篇我們繼續(xù)深入來看看在存儲格式的演變之上有什么新的"黑科技"。華為公司在2016年開源了類parquet的列存格式：CarbonData，并且貢獻給了Apache社區(qū)。CarbonData僅僅用了不到一年的時間就成功畢業(yè)，成為了Apache社區(qū)的頂級項目，CarbonData是首個由華人公司主導(dǎo)的Apache頂級項目，（來源自eBay的Kylin算是首個由華人主導(dǎo)的頂級開源項目）筆者這里還是要向華為的小伙伴們致敬，能夠完成這樣一個從0到1的突破。
本篇筆者嘗試從技術(shù)細(xì)節(jié)來梳理CarbonData與其“前輩”到底有何不同之處，我們在實際應(yīng)用與設(shè)計存儲格式時有什么可以借鑒汲取之處。

1.CarbonData

首先我們來看看CarbonData本身的定位，如下圖所示：

• 1、支持海量數(shù)據(jù)掃描并取其中幾列；
• 2、支持根據(jù)主鍵進行查找，并在秒級響應(yīng)；
• 3、支持在海量數(shù)據(jù)進行類似于OLAP的交互式查詢，并且查詢中涉及到許多過濾條件，這種類型的workload應(yīng)該在幾秒鐘內(nèi)響應(yīng)；
• 4、支持快速地抽取單獨的記錄，并且從該記錄中獲取到所有列信息；
• 5、支持HDFS，無縫對接Hadoop生態(tài)圈，天生帶有分布式基因。

對于OLAP查詢來說，存在多種不同類型的查詢，存儲結(jié)構(gòu)的不同會影響到不同查詢的數(shù)據(jù)表現(xiàn)。所以CarbonData的定位是作為一種通用的查詢存儲數(shù)據(jù)，通過Spark SQL來解決海量查詢的問題，并且能夠與Hadoop生態(tài)圈進行無縫對接。CarbonData最初的應(yīng)用是與Spark SQL和Spark DataFrame深度結(jié)合，后續(xù)由攜程團隊將CarbonData引入了Presto，滴滴團隊將CarbonData引入Hive。

其實無論是多維的OLAP查詢，還是完整的掃描查詢，還是部分范圍查詢。CarbonData的前輩ORCFile與Parquet都可以同樣完成任務(wù)，那么作為新人，CarbonData有什么過人之處呢？

快，更快

下圖是華為提供進行實測的數(shù)據(jù)，在絕大多數(shù)的測試場景之中CarbonData的性能都略優(yōu)于Parquet。

當(dāng)然快速的查詢是需要付出代價的，查詢的快速所犧牲的是壓縮率的減小與入庫時間的延長。

那我們接下來就是要詳盡討論CarbonData的性能表現(xiàn)與底層設(shè)計之間的邏輯關(guān)系。

文件結(jié)構(gòu)

下圖展示了CarbonData的數(shù)據(jù)存儲格式：

• File Header
  文件頭的格式比較簡單，保存了存儲格式的版本和模式信息。（這部分通常是穩(wěn)定不可變的內(nèi)容）

• Blocklet
  單Blocklet最大的容量閥值為64M，也就是說單個HDFS的Block可以容納多個Blocklet（視Block的大小而定）。這塊內(nèi)容與ORCFile與Parquet的設(shè)計一脈相承，都是利用Pax的存儲模型來優(yōu)化數(shù)據(jù)查詢時的性能表現(xiàn)。

• File Footer
  在文件尾部保存了存儲數(shù)據(jù)的索引和摘要，索引是CarbonData最為核心的關(guān)鍵實現(xiàn)，正是由于索引的存在，大大提高了CarbonData在不同查詢場景之下的性能表現(xiàn)。

二級索引

CarbonData通過支持了二級索引，大大的提高了CarbonData數(shù)據(jù)查詢的性能表現(xiàn)。

由上圖所示CarbonData在HDFS Block級別與內(nèi)部的Blocklet級別都分別建立起索引，這樣可以大大減少非必要的任務(wù)啟動與非必要的磁盤IO操作。眾所周知，引入索引的的確確能夠加快數(shù)據(jù)的查詢速率，但是天下沒有免費的午餐。我想CarbonData壓縮率縮減與數(shù)據(jù)導(dǎo)入時間的延長的原因，想必讀者心中也有了答案。

我們可以看到在CarbonData的文件尾部，通過B+樹的方式來實現(xiàn)索引。由于HDFS追加寫的特性，所以我想讀者應(yīng)該也能明白為何這些索引數(shù)據(jù)與統(tǒng)計數(shù)據(jù)需要存放在CarbonData的末尾。

上圖完整的展現(xiàn)了一次過濾查詢的流程，這個過程在二級索引的作用之下，規(guī)避了大量非必要的查詢交互，由此帶來的性能優(yōu)化是十分明顯的。

相對于ORCFile與Parquet相對簡要的摘要索引，CarbonData在索引層面頗費心思。通過這樣的方式來超越前輩，當(dāng)然這樣的選擇設(shè)計同樣也要付出額外的代價。

全局字典編碼

這是CarbonData之中頗具爭議的功能，在CarbonData之前的版本是默認(rèn)添加的內(nèi)容，目前在1.3版本之中是作為可選項加入其中的。（筆者在華為高斯部門工作的師兄也曾經(jīng)和筆者吐槽過在生產(chǎn)環(huán)境之中，全局字典編碼的似乎還存在一些'坑'）所以看起來能夠運用好字典編碼的確是個值得探討的問題，筆者在此也簡單聊一聊：

如上圖所示，全局字典編碼的方式很簡單，就是通過數(shù)字和字典來替換表格之中重復(fù)出現(xiàn)的數(shù)據(jù)。 這樣的好處很明顯：

• 大大減少了表格數(shù)據(jù)所需要存儲的數(shù)據(jù)量

• 某些需要進行g(shù)roup by的字段進行全局字典編碼，可以大量減少計算時的shuffle的數(shù)據(jù)量。以達到性能提升的目的。

但是在將數(shù)據(jù)導(dǎo)入CarbonData的過程之中，對與重復(fù)率較低的列，一旦建立起全局字典，顯然會大大拖慢數(shù)據(jù)的導(dǎo)入速度，并且影響數(shù)據(jù)的壓縮程度。而如果對于數(shù)據(jù)重復(fù)率較高的數(shù)據(jù)，例如性別，年齡等高重復(fù)數(shù)據(jù)，通過建立全局字典能夠大大提升CarbonData的壓縮程度，并且對數(shù)據(jù)導(dǎo)入的速率影響不大。

筆者建議：對于字典編碼的使用，還是要根據(jù)具體也業(yè)務(wù)場景進行分析壓測，給出較為合適的使用方式，盲目使用字典編碼反而會對性能帶來負(fù)優(yōu)化。

2.小結(jié)

到此為止，筆者也大致聊完了對CarbonData存儲結(jié)構(gòu)的理解以及筆者在簡單實踐之中所引發(fā)的思考。 作為華人圈子之中首個由華人公司主導(dǎo)的Apache的頂級項目，筆者也會繼續(xù)對CarbonData進行關(guān)注與學(xué)習(xí)，也希望將來華人程序員能夠在開源圈之中繼續(xù)擴大影響力。