華為宣布開源了CarbonData項(xiàng)目，該項(xiàng)目于6月3日通過(guò)Apache社區(qū)投票，成功進(jìn)入Apache孵化器。CarbonData是一種低時(shí)延查詢、存儲(chǔ)和計(jì)算分離的輕量化文件存儲(chǔ)格式。那么相比SQL on Hadoop方案、傳統(tǒng)NoSQL或相對(duì)ElasticSearch等搜索系統(tǒng)，CarbonData具有什么樣的優(yōu)勢(shì)呢？CarbonData的技術(shù)架構(gòu)是什么樣子的？未來(lái)有什么樣的規(guī)劃？我們采訪了CarbonData項(xiàng)目的技術(shù)負(fù)責(zé)人為大家解惑。
InfoQ：請(qǐng)問(wèn)CarbonData是什么時(shí)候開始進(jìn)行的項(xiàng)目？為什么現(xiàn)在向Apache孵化器開源呢？開源發(fā)展歷程和項(xiàng)目目前狀態(tài)是怎么樣的？
CarbonData：CarbonData項(xiàng)目是華為公司從多年數(shù)據(jù)處理經(jīng)驗(yàn)和行業(yè)理解中逐步積累起來(lái)的，2015年我們對(duì)系統(tǒng)進(jìn)行了一次架構(gòu)重構(gòu)，使其演化為HDFS上的一套通用的列式存儲(chǔ)，支持和Spark引擎對(duì)接后形成一套分布式OLAP分析的解決方案。
華為一直是面向電信、金融、IT企業(yè)等用戶提供大數(shù)據(jù)平臺(tái)解決方案的供應(yīng)商，從眾多客戶場(chǎng)景中我們不斷提煉數(shù)據(jù)特征，總結(jié)出了一些典型的對(duì)大數(shù)據(jù)分析的訴求，逐步形成了CarbonData這個(gè)架構(gòu)。
因?yàn)樵贗T領(lǐng)域，只有開源開放，才能最終讓更多的客戶和合作伙伴的數(shù)據(jù)連接在一起，產(chǎn)生更大商業(yè)價(jià)值。開源是為了構(gòu)建E2E生態(tài)，CarbonData是數(shù)據(jù)存儲(chǔ)層技術(shù)，要發(fā)揮價(jià)值，需要與計(jì)算層、查詢層有效集成在一起，形成完成真正的生態(tài)發(fā)揮價(jià)值。
又因?yàn)锳pache是目前大數(shù)據(jù)領(lǐng)域最權(quán)威的開源組織，其中的Hadoop，Spark已成為大數(shù)據(jù)開源的事實(shí)標(biāo)準(zhǔn)，我們也非常認(rèn)可Apache以Community驅(qū)動(dòng)技術(shù)進(jìn)步的理念，所以我們選擇進(jìn)入Apache，與社區(qū)一同構(gòu)建能力，使CarbonData融入大數(shù)據(jù)生態(tài)。
目前CarbonData開源項(xiàng)目已經(jīng)在6月3日通過(guò)Apache社區(qū)投票，成功進(jìn)入Apache孵化器。github地址：https://github.com/apache/incubator-carbondata。歡迎大家參與到Apache CarbonData社區(qū)： https://github.com/apache/incubator-carbondata/blob/master/docs/How-to-contribute-to-Apache-CarbonData.md。
InfoQ：請(qǐng)問(wèn)是什么原因或機(jī)遇促使您們產(chǎn)生做CarbonData這個(gè)項(xiàng)目的想法的？之前的項(xiàng)目中遇到什么樣的困難？
CarbonData：我們一直面臨著很多高性能數(shù)據(jù)分析訴求，在傳統(tǒng)的做法里，一般是使用數(shù)據(jù)庫(kù)加BI工具實(shí)現(xiàn)報(bào)表、DashBoard和交互式查詢等業(yè)務(wù)，但隨著企業(yè)數(shù)據(jù)日益增大，業(yè)務(wù)驅(qū)動(dòng)的分析靈活性要求逐漸增大，也有部分客戶希望有除SQL外更強(qiáng)大的分析功能，所以傳統(tǒng)的方式漸漸滿足不了客戶需求，讓我們產(chǎn)生了做CarbonData這個(gè)項(xiàng)目的想法。
需求一般來(lái)源于幾方面。
第一，在部署上，區(qū)別于以往的單機(jī)系統(tǒng)，企業(yè)客戶希望有一套分布式方案來(lái)應(yīng)對(duì)日益增多的數(shù)據(jù)，隨時(shí)可以通過(guò)增加通用服務(wù)器的方式scale out橫向擴(kuò)展。
第二，在業(yè)務(wù)功能上，很多企業(yè)的業(yè)務(wù)都處在從傳統(tǒng)數(shù)據(jù)庫(kù)逐漸轉(zhuǎn)移到大數(shù)據(jù)平臺(tái)的遷移過(guò)程中，這就要求大數(shù)據(jù)平臺(tái)要有較高兼容老業(yè)務(wù)的能力，這里面主要包含的是對(duì)完整的標(biāo)準(zhǔn)SQL支持，以及多種分析場(chǎng)景的支持。同時(shí)為了節(jié)約成本，企業(yè)希望“一份數(shù)據(jù)支持多種使用場(chǎng)景”，例如大規(guī)模掃描和計(jì)算的批處理場(chǎng)景，OLAP多維交互式分析場(chǎng)景，明細(xì)數(shù)據(jù)即席查詢，主鍵低時(shí)延點(diǎn)查，以及對(duì)實(shí)時(shí)數(shù)據(jù)的實(shí)時(shí)查詢等場(chǎng)景，都希望平臺(tái)能給予支持，且達(dá)到秒級(jí)查詢響應(yīng)。
第三，在易用性上，企業(yè)客戶以往使用BI工具，業(yè)務(wù)分析的OLAP模型是需要在BI工具中建立的，這就會(huì)導(dǎo)致有的場(chǎng)景下數(shù)據(jù)模型的靈活性和分析手段受到限制，而在大數(shù)據(jù)時(shí)代，大數(shù)據(jù)開源領(lǐng)域已經(jīng)形成了一個(gè)生態(tài)系統(tǒng)，社區(qū)隨時(shí)都在進(jìn)步，經(jīng)常會(huì)冒出一些新型的分析工具，所以企業(yè)客戶都希望能跟隨社區(qū)不斷改進(jìn)自己的系統(tǒng)，在自己的數(shù)據(jù)里快速用上新型的分析工具，得到更大的商業(yè)價(jià)值。
要同時(shí)達(dá)到上訴要求，無(wú)疑對(duì)大數(shù)據(jù)平臺(tái)是一個(gè)很大的挑戰(zhàn)。為了滿足這些要求，我們開始不斷在實(shí)際項(xiàng)目中積累經(jīng)驗(yàn)，也嘗試了很多不同的解決方案，但都沒(méi)有發(fā)現(xiàn)能用一套方案解決所有問(wèn)題。
大家首先會(huì)想到的是，在涉及到低時(shí)延查詢的分布式存儲(chǔ)中，一般常用的是KV型NoSQL數(shù)據(jù)庫(kù)（如HBase，Cassandra），可以解決主鍵低時(shí)延查詢的問(wèn)題，但如果業(yè)務(wù)的查詢模式稍作改變，例如對(duì)多維度靈活組合的查詢，就會(huì)使點(diǎn)查變?yōu)槿頀呙瑁剐阅芗眲∠陆怠Ｓ械膱?chǎng)景下，這時(shí)可以通過(guò)加入二級(jí)索引來(lái)緩解該問(wèn)題，但這又帶來(lái)了二級(jí)索引的維護(hù)和同步等管理問(wèn)題，所以KV型存儲(chǔ)并不是解決企業(yè)問(wèn)題的通用方案。
那么，如果要解決通用的多維查詢問(wèn)題，有時(shí)我們會(huì)想到用多維時(shí)序數(shù)據(jù)庫(kù)的方案（如Linkedin Pinot），他們的特點(diǎn)是數(shù)據(jù)都以時(shí)間序列的方式進(jìn)入系統(tǒng)并經(jīng)過(guò)數(shù)據(jù)預(yù)聚合和建立索引，因?yàn)槭穷A(yù)計(jì)算，所以應(yīng)對(duì)多維查詢時(shí)非常快，數(shù)據(jù)也非常及時(shí)，同時(shí)具備多維分析和實(shí)時(shí)處理的優(yōu)點(diǎn)，在性能監(jiān)控、實(shí)時(shí)指標(biāo)分析的場(chǎng)景里應(yīng)用較多。但它在支持的查詢類型上也有一定限制，因?yàn)樽隽藬?shù)據(jù)預(yù)計(jì)算，所以這種架構(gòu)一般無(wú)法應(yīng)對(duì)明細(xì)數(shù)據(jù)查詢，以及不支持Join多表關(guān)聯(lián)分析，這無(wú)疑給企業(yè)使用場(chǎng)景帶來(lái)了一定的限制。
另外一類是搜索系統(tǒng)（如Apache Solr，ElasticSearch），搜索系統(tǒng)可以做多維匯總也可以查詢明細(xì)數(shù)據(jù)，它也具備基于倒排索引的快速布爾查詢，并發(fā)也較高，似乎正是我們希望尋找的方案。但在實(shí)際應(yīng)用中我們發(fā)現(xiàn)兩個(gè)問(wèn)題：一是由于搜索系統(tǒng)一般是針對(duì)非結(jié)構(gòu)化數(shù)據(jù)而設(shè)計(jì)的，系統(tǒng)的數(shù)據(jù)膨脹率一般都比較高，在企業(yè)關(guān)系型數(shù)據(jù)模型下數(shù)據(jù)存儲(chǔ)不夠緊湊，造成數(shù)據(jù)量較大，二是搜索系統(tǒng)的數(shù)據(jù)組織方式和計(jì)算引擎密切相關(guān)，這就導(dǎo)致了數(shù)據(jù)入庫(kù)后只能用相應(yīng)的搜索引擎處理，這又一定程度打破了企業(yè)客戶希望應(yīng)用多種社區(qū)分析工具的初衷，所以搜索系統(tǒng)也有他自己的適用場(chǎng)景。
最后一類系統(tǒng)，就是目前社區(qū)里大量涌現(xiàn)的SQL on Hadoop方案，以Hive, SparkSQL, Flink為代表，這類系統(tǒng)的特點(diǎn)是計(jì)算和存儲(chǔ)相分離，針對(duì)存儲(chǔ)在HDFS上的文件提供標(biāo)準(zhǔn)SQL功能，他們?cè)诓渴鹦院鸵子眯陨峡梢詽M足企業(yè)客戶需求，業(yè)務(wù)場(chǎng)景上也能覆蓋掃描，匯聚，詳單等各類場(chǎng)景，可見可以將他們視為一類通用的解決方案。為了提高性能，Spark，F(xiàn)link等開源項(xiàng)目通過(guò)不斷優(yōu)化自身架構(gòu)提升計(jì)算性能，但提升重點(diǎn)都放在計(jì)算引擎和SQL優(yōu)化器的增強(qiáng)上，在存儲(chǔ)和數(shù)據(jù)組織上改進(jìn)并不是重點(diǎn)。
所以，可以看出當(dāng)前的很多大數(shù)據(jù)系統(tǒng)雖然都能支持各類查詢場(chǎng)景，但他們都是偏向某一類場(chǎng)景設(shè)計(jì)的，在不是其目標(biāo)場(chǎng)景的情況下要么不支持要么退化為全表掃描，所以導(dǎo)致企業(yè)為了應(yīng)對(duì)批處理，多維分析，明細(xì)數(shù)據(jù)查詢等場(chǎng)景，客戶常常需要通過(guò)復(fù)制多份數(shù)據(jù)，每種場(chǎng)景要維護(hù)一套數(shù)據(jù)。
CarbonData的設(shè)計(jì)初衷正是為了打破這種限制，做到只保存一份數(shù)據(jù)，最優(yōu)化地支撐多種使用場(chǎng)景。
InfoQ:能否具體談?wù)凜arbonData的技術(shù)架構(gòu)？有何特征和優(yōu)勢(shì)呢？
CarbonData：整個(gè)大數(shù)據(jù)時(shí)代的開啟，可以說(shuō)是源自于Google的MapReduce論文，他引發(fā)了Hadoop開源項(xiàng)目以及后續(xù)一系列的生態(tài)發(fā)展。他的“偉大”之處在于計(jì)算和存儲(chǔ)解耦的架構(gòu)，使企業(yè)的部分業(yè)務(wù)（主要是批處理）從傳統(tǒng)的垂直方案中解放出來(lái)，計(jì)算和存儲(chǔ)可以按需擴(kuò)展極大提升了業(yè)務(wù)發(fā)展的敏捷性，讓眾多企業(yè)普及了這一計(jì)算模式，從中受益。
雖然MapReduce開啟了大數(shù)據(jù)時(shí)代，但它是通過(guò)純粹的暴力掃描+分布式計(jì)算來(lái)提升批處理性能，所以并不能解決客戶對(duì)所有查詢場(chǎng)景的低時(shí)延查詢要求。
在目前的生態(tài)中，最接近于客戶要求的其實(shí)是搜索引擎類方案。通過(guò)良好的數(shù)據(jù)組織和索引，搜索引擎能提供多種快速的查詢功能，但偏偏搜索引擎的存儲(chǔ)層又和計(jì)算引擎是緊耦合的，并不符合企業(yè)對(duì)”一份數(shù)據(jù)，多種場(chǎng)景”的期望。
這給了我們啟發(fā)，我們何不為通用計(jì)算引擎打造更一個(gè)高效的數(shù)據(jù)組織來(lái)滿足客戶需求呢，做到既利用計(jì)算和存儲(chǔ)解耦架構(gòu)又能提供高性能查詢。抱著這個(gè)想法，我們啟動(dòng)了CarbonData項(xiàng)目。針對(duì)更多的業(yè)務(wù)，使計(jì)算和存儲(chǔ)相分離，這也成了CarbonData的架構(gòu)設(shè)計(jì)理念。
確立了這個(gè)理念后，我們很自然地選擇了基于HDFS+通用計(jì)算引擎的架構(gòu)，因?yàn)檫@個(gè)架構(gòu)可以很好地提供Scale out能力。下一步我們問(wèn)自己這個(gè)架構(gòu)里還缺什么？這個(gè)架構(gòu)中，HDFS提供文件的復(fù)制和讀寫能力，計(jì)算引擎負(fù)責(zé)讀取文件和分布式計(jì)算，分工很明確，可以說(shuō)他們分別定位于解決存儲(chǔ)管理和計(jì)算的問(wèn)題。但不難看出，為了適應(yīng)更多場(chǎng)景，HDFS做了很大的“犧牲”，它犧牲了對(duì)文件內(nèi)容的理解，正是由于放棄了對(duì)文件內(nèi)容的理解，導(dǎo)致計(jì)算只能通過(guò)全掃描的方式來(lái)進(jìn)行，可以說(shuō)最終導(dǎo)致的是存儲(chǔ)和計(jì)算都無(wú)法很好的利用數(shù)據(jù)特征來(lái)做優(yōu)化。
所以針對(duì)這個(gè)問(wèn)題，我們把CarbonData的發(fā)力重點(diǎn)放在對(duì)數(shù)據(jù)組織的優(yōu)化上，通過(guò)數(shù)據(jù)組織最終是要提升IO性能和計(jì)算性能。為此，CarbonData做了如下工作。
CarbonData基礎(chǔ)特性
1. 多維數(shù)據(jù)聚集：在入庫(kù)時(shí)對(duì)數(shù)據(jù)按多個(gè)維度進(jìn)行重新組織，使數(shù)據(jù)在“多維空間上更內(nèi)聚”，在存儲(chǔ)上獲得更好的壓縮率，在計(jì)算上獲得更好的數(shù)據(jù)過(guò)濾效率。
2. 帶索引的列存文件結(jié)構(gòu)：首先，CarbonData為多類場(chǎng)景設(shè)計(jì)了多個(gè)級(jí)別的索引，并融入了一些搜索的特性，有跨文件的多維索引，文件內(nèi)的多維索引，每列的minmax索引，以及列內(nèi)的倒排索引等。其次，為了適應(yīng)HDFS的存儲(chǔ)特點(diǎn)，CarbonData的索引和數(shù)據(jù)文件存放在一起，一部分索引本身就是數(shù)據(jù)，另一部分索引存放在文件的元數(shù)據(jù)結(jié)構(gòu)中，他們都能隨HDFS提供本地化的訪問(wèn)能力。
3. 列組：整體上，CarbonData是一種列存結(jié)構(gòu)，但相對(duì)于行存來(lái)說(shuō)，列存結(jié)構(gòu)在應(yīng)對(duì)明細(xì)數(shù)據(jù)查詢時(shí)會(huì)有數(shù)據(jù)還原代價(jià)高的問(wèn)題，所以為了提升明顯數(shù)據(jù)查詢性能，CarbonData支持列組的存儲(chǔ)方式，用戶可以把某些不常作為過(guò)濾條件但又需要作為結(jié)果集返回的字段作為列組來(lái)存儲(chǔ)，經(jīng)過(guò)CarbonData編碼后會(huì)將這些字段使用行存的方式來(lái)存儲(chǔ)以提升查詢性能。
4. 數(shù)據(jù)類型：目前CarbonData支持所有數(shù)據(jù)庫(kù)的常用基本類型，以及Array，Struct復(fù)雜嵌套類型。同時(shí)社區(qū)也有人提出支持Map數(shù)據(jù)類型，我們計(jì)劃未來(lái)添加Map數(shù)據(jù)類型。
5. 壓縮：目前CarbonData支持Snappy壓縮，壓縮是針對(duì)每列分別進(jìn)行的，因?yàn)榱写娴奶攸c(diǎn)使得壓縮非常高效。數(shù)據(jù)壓縮率基于應(yīng)用場(chǎng)景不同一般在2到8之間。
6. Hadoop集成：通過(guò)支持InputFormat/OutputFormat接口，CarbonData可以利用Hadoop的分布式優(yōu)點(diǎn)，也能在所有以Hadoop為基礎(chǔ)的生態(tài)系統(tǒng)中使用。
CarbonData高級(jí)特性
1. 可計(jì)算的編碼方式：除了常見的Delta，RLE，Dictionary，BitPacking等編碼方式外，CarbonData還支持將多列進(jìn)行聯(lián)合編碼，以及應(yīng)用了全局字典編碼來(lái)實(shí)現(xiàn)免解碼的計(jì)算，計(jì)算框架可以直接使用經(jīng)過(guò)編碼的數(shù)據(jù)來(lái)做聚合，排序等計(jì)算，這對(duì)需要大量shuffle的查詢來(lái)說(shuō)性能提升非常明顯。
2. 與計(jì)算引擎聯(lián)合優(yōu)化：為了高效利用CarbonData經(jīng)過(guò)優(yōu)化后的數(shù)據(jù)組織，CarbonData提供了有針對(duì)性的優(yōu)化策略，目前CarbonData社區(qū)首先做了和Spark的深度集成，其中基于SparkSQL框架增強(qiáng)了過(guò)濾下壓，延遲物化，增量入庫(kù)等特性，同時(shí)支持所有DataFrame API。相信未來(lái)通過(guò)社區(qū)的努力，會(huì)有更多的計(jì)算框架與CarbonData集成，發(fā)揮數(shù)據(jù)組織的價(jià)值。
目前這些特性都已經(jīng)合入Apache CarbonData主干，歡迎大家使用。
InfoQ：在哪些場(chǎng)景推薦使用呢？性能測(cè)試結(jié)果如何？有沒(méi)有應(yīng)用案例，目前在國(guó)內(nèi)的使用情況和用戶規(guī)模？
CarbonData：推薦場(chǎng)景：希望一份存儲(chǔ)同時(shí)滿足快速掃描，多維分析，明細(xì)數(shù)據(jù)查詢的場(chǎng)景。在華為的客戶使用案例中，對(duì)比業(yè)界已有的列存方案，CarbonData可以帶來(lái)5~30倍性能提升。
性能測(cè)試數(shù)據(jù)及應(yīng)用案例等更多信息，請(qǐng)關(guān)注微信公眾號(hào)ApacheCarbonData，及社區(qū)https://github.com/apache/incubator-carbondata。
InfoQ：CarbonData能和當(dāng)前正火的Spark完美結(jié)合嗎？還能兼容哪些主流框架呢？
CarbonData：目前CarbonData已與Spark做了深度集成，具體見上述高級(jí)特性。
InfoQ：您們的項(xiàng)目在未來(lái)有什么樣的發(fā)展規(guī)劃？還會(huì)增加什么功能嗎？如何保證開源之后的項(xiàng)目的持續(xù)維護(hù)工作呢？
CarbonData：接下來(lái)社區(qū)重點(diǎn)工作是，提升系統(tǒng)易用性、完善生態(tài)集成（如：與Flink,Kafka等集成，實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)導(dǎo)入CarbonData）。
CarbonData開源的第一個(gè)月，就有幾百個(gè)commits提交，和20多個(gè)貢獻(xiàn)者參與，所以后續(xù)這個(gè)項(xiàng)目會(huì)持續(xù)的活躍。10多個(gè)核心貢獻(xiàn)者也將會(huì)持續(xù)參與社區(qū)建設(shè)。
InfoQ：在CarbonData設(shè)計(jì)研發(fā)并進(jìn)入Apache孵化器的過(guò)程中，經(jīng)歷了哪些階段，經(jīng)歷過(guò)的最大困難是什么？有什么樣的感受或經(jīng)驗(yàn)可以和大家分享的嗎？
CarbonData：CarbonData團(tuán)隊(duì)大多數(shù)人都有參與Apache Hadoop、Spark等社區(qū)開發(fā)的經(jīng)驗(yàn)，我們對(duì)社區(qū)流程和工作方式都很熟悉。最大的困難是進(jìn)入孵化器階段，去說(shuō)服Apache社區(qū)接納大數(shù)據(jù)生態(tài)新的高性能數(shù)據(jù)格式CarbonData。我們通過(guò)5月份在美國(guó)奧斯丁的開源盛會(huì)OSCON上，做CarbonData技術(shù)主題演講和現(xiàn)場(chǎng)DEMO演示，展示了CarbonData優(yōu)秀的架構(gòu)和良好的性能效果。
InfoQ：您們是一個(gè)團(tuán)隊(duì)嗎？如何保證您們團(tuán)隊(duì)的優(yōu)秀成長(zhǎng)？
CarbonData：CarbonData團(tuán)隊(duì)是一個(gè)全球化的（工程師來(lái)自中國(guó)、美國(guó)、印度）團(tuán)隊(duì)，這種全球化工作模式的經(jīng)驗(yàn)積累，讓我們能快速的適應(yīng)Apache開源社區(qū)工作模式。
采訪嘉賓：Apache CarbonData的PMC、Committers李昆、陳亮。