2019大數據技術公開課第一季《技術人生專訪》來襲，本季將帶領開發者們探討大數據技術，分享不同國家的工作體驗。本文整理自阿里巴巴計算平臺事業部高級技術專家吳剛的專訪，將為大家介紹Apache ORC開源項目、主流的開源列存格式ORC和Parquet的區別以及MaxCompute選擇ORC的原因。此外，吳還將分享他是如何一步步成為Apache開源項目的Committer和PMC的。

以下內容根據演講視頻以及PPT整理而成。

個人簡介

吳剛，阿里巴巴計算平臺事業部高級技術專家 ，Apache頂級開源項目ORC的PMC ，目前主要負責MaxCompute平臺存儲線 相關工作。之前就職于Uber總部，從事Spark和Hive等相關工作。

一、Apache ORC項目介紹以及阿里巴巴對于ORC項目的貢獻

Apache ORC Project

正如Apache ORC項目官網所介紹的，Apache ORC是Hadoop生態系統中最快、最小的列式存儲文件格式。Apache ORC主打的三個特性包括支持ACID，也就是支持事務，支持內置索引以及支持各種復雜類型。

ORC Adopter

Apache ORC有很多的采用者，比如大家所熟知的Spark、Presto、Hive、Hadoop等開源軟件。此外，在2017年，阿里巴巴MaxCompute技術團隊也開始參與到Apache ORC項目的工作中，并將ORC作為MaxCompute內置的文件存儲格式之一。

Timeline

Apache ORC項目的大致發展歷程如下圖所示。在2013年初的時候，Hortonworks開始在來替代RCFile文件格式 ，經過了兩個版本的迭代，ORC孵化成為了Apache頂級項目，并且順利地從Hive中脫離出來成為一個單獨的項目。在2017年1月，阿里云MaxCompute團隊開始向ORC社區持續地貢獻代碼，并且使得ORC成為MaxCompute內置的文件格式之一。

Contribution from Alibaba

阿里巴巴MaxCompute技術團隊為Apache ORC項目做出了大量貢獻，比如研發了一個完整的C++的ORC Writer，修復了一些極為重要的Bug，并且大大提升了ORC的性能。阿里巴巴MaxCompute技術團隊總共向Apache ORC項目提交了30多個Patch，總計1萬5千多行代碼，并且目前阿里仍然在持續地向ORC貢獻代碼。阿里巴巴的技術團隊中共有3個ORC項目貢獻者，1個PMC和1個Committer。在2017年的Hadoop Summit上，ORC也專門用一頁PPT來點名表揚阿里巴巴對于ORC項目的貢獻。

二、阿里云MaxCompute為何選擇ORC？

Row-based VS. Column-based

對于文件存儲而言，有兩種主流的方式，即按行存儲以及按列存儲。所謂按行存儲就是把每一行數據依次存儲在一起，先存儲第一行的數據再存儲第二行的數據，以此類推。而所謂按列存儲就是把表中的數據按照列存儲在一起，先存儲第一列的數據，再存儲第二列的數據。而在大數據場景之下，往往只需要獲取部分列的數據，那么使用列存就可以只讀取少量數據，這樣可以節省大量磁盤和網絡I/O的消耗。此外，因為相同列的數據屬性非常相似，冗余度非常高，列式存儲可以增大數據壓縮率，進而大大節省磁盤空間。因此，MaxCompute最終選擇了列存。

A Quick Look at ORC

ORC在類型系統上的建模是一個樹形結構，對于一些諸如Struct這樣的復雜類型會有一個或者多個孩子節點，而Map類型有兩個孩子節點，即key和value，List類型就只有一個孩子節點，其他的普通類型則就是一個葉子節點。如下圖所示，左側的表結構就能夠被形象地轉化成右側的樹型結構，簡單并且直觀。

ORC主要有兩個優化指標，其一 為查詢速度。ORC將文件切分成大小相近的塊，在塊內部使用列式存儲，也就是將相同列的數據存儲到一起。針對于這些數據，ORC提供輕量的索引支持，包括數據塊的最小值、最大值、計數和空值等，基于這些統計信息，可以非常方便地過濾掉不需要讀取的數據，以此減少數據的傳輸。此外，ORC還支持列裁剪 (Column Projection)，如果查詢中只需要讀取部分列，那么Reader只需要返回所需的列數據，進一步減小了需要讀取的數據量。

ORC的第二個優化指標就是存儲效率。ORC采用了通用的壓縮算法，比如開源的zStandard、zlib、snappy、LZO等來提高文件壓縮率。同時，ORC也采用了輕量的編碼算法，比如run-length encoding、dictionary等。

How about Apache Parquet

在開源軟件領域中，與 Apache ORC 對標的就是Apache Parquet。Parquet是由 Cloudera 和 Twitter 共同開發的，其靈感來源于 Google 發表的Dremel的論文。Parquet 的思想和 ORC 非常相近，也是將文件拆分成大小相近的塊，并在塊里面使用列式存儲，并且對于開源系統的支持與 ORC 也相差無幾，也能夠支持 Spark、Presto 等，并且也使用了列式存儲和通用的壓縮以及編碼算法，也能夠提供輕量級索引以及統計信息。

相比ORC，Parquet主要有兩點不同。第一點就是Parquet能夠更好地支持嵌套類型，Parquet能夠通過使用definition和repetition levels方式來標識復雜類型的層數等信息，不過這樣的設計卻非常復雜，就連Google的論文中也使用整整一頁來介紹這個算法，但在實際中，大部分數據并沒有使用非常深的嵌套，這像是一個“殺雞用牛刀”的方法。此外，Parquet的編碼類型比ORC也更多一些，其支持plain、bit-packing以及浮點數等編碼方式，所以Parquet在某些數據類型的壓縮率上比ORC更高。

Benchmark: ORC VS Parquet

• Datasets

基于Github日志數據和紐約市出租車數據這兩個開源數據集，Hadoop開源社區進行了ORC和Parquet
的性能對比 ，并得到了一些統計數據。

• Storage Cost

下圖比較了ORC、Parquet以及JSON等文件存儲方式的性能效率。在Taxi Size的這張表中可以看出，Parquet和ORC存儲性能非常相近。

下圖展示了Github項目數據集下的存儲效率比較，從中可以看出ORC比Parquet的壓縮率更高一些，壓縮后數據量變得更小。

因此，綜上所述，在存儲效率方面，ORC和Parquet壓縮效率不相上下，在部分數據上ORC優勢更大。

• Full Table Scan

如下所示列出了ORC和Parquet對于兩個數據集的讀表效率對比情況。總體而言，ORC都比Parquet要更快一些。基于以上比較，MaxCompute最終選擇了ORC，因為其不僅設計更為簡單，并且讀表性能更高。

AliORC = Alibaba ORC

通過上述Benchmark的比較，MaxCompute基于對于性能的考量選擇了ORC。而在其他方面，相比于Parquet，ORC也有一些優勢，比如前面提到的設計更為簡單、代碼質量更佳、語言無關性 、能夠高效地支持多種開源項目。 并且由于ORC研發團隊相對更為集中，創始人對于項目具有較強的掌控力，因此阿里巴巴提出的任何需求和想法都可以獲得快速響應和比較有力的支持，進而成為社區的領導者。

三、AliORC和開源ORC有何不同？

AliORC is More Than Apache ORC

AliORC是基于開源Apache ORC的深度優化的文件格式。AliORC的首要目標還是和開源的ORC完全兼容，這樣才能更加方便于用戶的使用。AliORC主要從兩個方面對于開源的ORC進行了優化，一方面，AliORC提供了更多的擴展特性，比如對于Clustered Index和C++ Arrow的支持以及謂詞下推等。另一方面，AliORC還進行了性能優化，實現了異步預讀、I/O模式管理以及自適應字典編碼等。

AliORC Optimization

• Async Prefetch

這里選取幾個AliORC對于開源的ORC優化的具體特性進行分享。首先就是Async Prefetch (異步預讀)。傳統讀文件的方式一般是從底層文件系統先拿到原始數據，然后進行解壓和解碼，這兩步操作分別是I/O密集型和CPU密集型任務，并且兩者沒有任何并行性，因此就加長了整體的端到端時間，但實際上并無必要，并且造成了資源的浪費。AliORC實現了從文件系統讀數據和解壓解碼操作的并行處理，這樣就將所有的讀盤操作變成了異步的，也就是提前將讀取數據的請求全部發送出去，當真正需要數據的時候就去檢查之前的異步請求是否返回了數據，如果數據已經返回，則可以立即進行解壓和解碼操作，而不需要等待讀盤，這樣就可以極大地提高并行度，并降低讀取文件的所需時間。

如下圖所示的就是打開了異步預讀優化前后的性能對比。開啟異步預讀之前，讀取一個文件需要14秒，而在打開異步預讀之后則只需要3秒，讀取速度提升了數倍。因為將所有的讀請求都變成了異步的，當異步請求返回較慢時還是會變成同步請求。從右側餅圖可以看出，實際情況下80%以上的異步請求都是有效的。

• Small I/O Elimination

AliORC的第二個優化點就是對于小I/O的消除。在ORC文件中，不同列的文件大小是完全不同的，但是每次讀盤都是以列為單位進行數據讀取的。這樣一來，對于數據量比較小的列而言，讀取時的網絡I/O開銷非常大。為了消除這些小的I/O開銷，AliORC在Writer部分針對不同列的數據量進行了排序，在reader端將小數據量的列放在一起形成一個大I/O塊，這樣不僅減少了小I/O數量，還大大地提升了并行度。

如下圖所示的是AliORC打開Small I/O Elimination前后的對比情況。藍色部分表示的就是打開Small I/O Elimination之前的I/O分布情況，橙色的部分則是表示打開之后的I/O分布情況。可以看到，打開Small I/O Elimination之前，小于64K的I/O有26個，而在打開之后，小于64K的I/O為零，因此Small I/O Elimination的優化效果還是非常顯著的。

• Memory Management for streams in each column

AliORC的第三個優化點就是在內存管理 。在開源版本的ORC實現中，Writer的每列數據都使用了一個很大的Buffer去保存壓縮后的數據，默認大小為1M，其目的在于 Buffer設置得越大，壓縮率越高。但是正如前面所說的，不同列的數據量不同，某些列根本用不到1M大小的Buffer，因此就會造成極大的內存浪費。避免內存浪費的簡單方法就是在一開始的時候只給很小的數據塊作為Buffer，并且按需分配，如果需要寫的數據更多，那么就通過類似C++std::vector的resize 方式提供更大的數據塊。原本實現方式中，resize一次就需要進行一次O(N)的操作，將原始數據從老的Buffer拷貝到新的Buffer中去，這樣對于性能而言是不可接受的。因此，AliORC開發了新的內存管理結構，分配64K的Block，但是Block與Block之間不是連續的，這雖然會造成很多代碼的改動，但是這一改動卻是值得的。因為在很多場景下，原來的resize方式需要消耗很多內存，有可能造成內存耗盡，進而導致任務無法完成，而新的方式可以在這種場景下大大降低內存的峰值，效果非常明顯。

• Seek Read

AliORC的第四個優化點就是Seek Read方面的優化。這部分解釋略微復雜，因此這里以一個例子進行概括。Seek Read原來的問題在于壓縮塊比較大，每個壓縮塊中包含很多個Block。在圖中，每一萬行數據叫做一個Row Group。在Seek Read的場景下，可能會Seek Read到文件中間的某一段，其可能是包含在某一個壓縮塊中間的，比如圖中第7個Row Group被包含在第2個Block中。常規Seek的操作就是先跳轉第2個Block的頭部，然后進行解壓，將第7個Row Group之前的數據先解壓出來，再真正地跳轉到第7個Row Group處。但是圖中綠色的部分數據并不是我們所需要的，因此這一段的數據量就被白白解壓了，浪費掉很多計算資源。因此，AliORC的想法就是就是【在寫文件的時候】將壓縮塊Block和Row Group的邊界進行對齊，因此Seek到任何的Row Group都不需要進行不必要的解壓操作。

如圖所示的是進行Seek Read優化前后的效果對比。藍色部分是優化之前的情況，橙色部分代表優化之后的情況。可以發現，有了對于Seek Read的優化，解壓所需的時間和數據量都降低了5倍左右。

• Adapting Dictionary Encoding

字典編碼就是針對重復度比較高的字段首先整理出來一個字典，然后使用字典中的序號來代替原來的數據進行編碼，相當于將字符串類型數據的編碼轉化成整型數據的編碼，這樣可以大大減少數據量。但是ORC編碼存在一些問題，首先，不是所有的字符串都適合字典編碼，而在原來的數據中，每一列都是默認打開字典編碼的，而當文件結束時再判斷列是否適合字典編碼，如果不適合，再回退到非字典編碼。由于回退操作相當于需要重寫字符串類型數據，因此開銷會非常大。AliORC所做的優化就是通過一個自適應的算法提早決定某一列是否需要使用字典編碼，這樣就可以節省很多的計算資源。開源的ORC中通過標準庫中的std::unordered_map來實現字典編碼，但是它的實現方式并不適合MaxCompute的數據，而Google開源的dense_hash_map庫可以帶來10%的寫性能提升，因此AliORC采用了這種實現方式。最后，開源的ORC標準中要求對于字典類型進行排序，但實際上是沒有任何必要的，剔除掉該限制可以使得Writer端的性能提高3%。

• Range Alignment for Range Partition

這部分主要是對于Range Partition的優化。如下圖右側的DDL所示，想要將一張表按照某些列進行RANGE CLUSTERED并對這些列的數據進行排序，比如將這些數據存儲到4個桶中，分別存儲0到1、2到3、4到8以及9到無窮大的數據。這樣做的優勢在于，在具體實現過程中，每個桶都使用了一個ORC文件，在ORC文件尾部存儲了一個類似于B+Tree的索引。當需要進行查詢的時候，如果查詢的Filter和Range Key相關，就可以直接利用該索引來排除不需要讀取的數據，進而大大減少所需要獲取的數據量。

對于Range Partition而言，AliORC具有一個很強大的功能，叫做Range對齊。這里解釋一下，假設需要Join兩張Range Partition的表，它們的Join Key就是Range Partition Key。如下圖所示，表A有三個Range，表B有兩個Range。在普通表的情況下，這兩個表進行Join會產生大量的Shuffle，需要將相同的數據Shuffle到同一個Worker上進行Join操作，而Join操作又是非常消耗內存和CPU資源的。而有了Range Partition之后，就可以將Range的信息進行對齊，將A表的三個桶和B表的兩個桶進行對齊，產生如下圖所示的三個藍色區間。之后就可以確定藍色區間之外的數據是不可能產生Join結果，因此Worker根本不需要讀取那些數據。

完成優化之后，每個Worker只需要打開藍色區域的數據進行Join操作即可。這樣就可以使得Join操作能夠在本地Worker中完成，而不需要進行Shuffle，進而大大降低了數據傳輸量，提高了端到端的效率。

四、AliORC為用戶帶來的價值

如下圖所示的是在阿里巴巴內部測試中AliORC和開源的C++版本ORC以及Java版本ORC的讀取時間比較。從圖中可以看出AliORC的讀取速度比開源ORC要快一倍。

截止2019年5月，在阿里巴巴內部也迭代了3個版本，從下圖可以看出，每個版本之間也有接近30%的性能提升，并且還在持續優化當中。目前，AliORC還處于內部使用階段，尚未在公有云上進行發布，后續也會將AliORC開放出來，讓大家共享技術紅利。

**五、淺談阿里云MaxCompute相比同類產品的優勢
**首先，MaxCompute是開箱即用的，也就是說用戶無需額外的設置，直接啟動MaxCompute服務就可以在其上運行任務了。而使用Hive或者Spark等開源軟件可能會存在很多Bug，而對于問題的排查也異常困難，開源社區的修復周期也非常漫長。當用戶使用MaxCompute時遇到問題，能夠很快地得到反饋并且完成修復。

其次，MaxCompute的使用成本比較低，可以實現按量付費。而使用Hive或者Spark往往需要自建數據中心，這樣的做法非常繁瑣，建設數據中心不僅需要支付機器成本，還需要自己進行運維。

再次，使用開源的Hive或者Spark，對于技術人員而言，門檻也比較高。因為需要招募一些非常了解Hive和Spark的工程師才能進行維護。而公司自己開發的一些特性往往會和開源版本產生沖突，每次都需要對于沖突進行解決。而當開源版本的軟件每次升級之后，就需要將新版本代碼下載下來之后再將自己的開發的特性重新加進去，過程異常繁瑣。而使用MaxCompute之后，這些工作無需用戶關心，阿里巴巴會幫助客戶處理這些問題。

對于穩定性而言，MaxCompute做的也非常好。其抗住了歷年雙11的流量洪峰，而直接使用Hadoop生態系統很難支持很大的體量的任務，往往需要各種深度定制優化。

MaxCompute另外一個優勢在于性能，MaxCompute是第一個跑過100TB數據量的TPCx-BB的Benchmark的平臺，這是Spark至今沒有達到的成就。

此外，開源產品往往不夠重視中國市場。Cloudera、Databricks等公司的主要目標客戶還是在美國，往往更傾向于根據美國客戶需求進行開發，而對于中國市場的支持不夠好。MaxCompute則緊跟中國客戶的需要，同時也更加適合中國市場。

最后一點就是只有在MaxCompute里面才能使用AliORC這樣的文件格式，這也是獨有的優勢。

總結而言，相比于開源軟件，MaxCompute具有需求響應更加及時、成本更低、技術門檻更低、穩定性更高、性能更好、更加適合中國市場等特性。

六、為何選擇加入MaxCompute團隊

從個人角度而言，我更加看好大數據領域。雖然對于一項技術而言，黃金期往往只有10年，而對于大數據技術而言，已經經歷了10年，但我相信大數據技術并不會衰落。尤其是在人工智能技術的加持下，大數據技術仍然有很多需要解決的問題，其技術仍然沒有達到的完美。此外，阿里的MaxCompute團隊更是人才濟濟，北京、杭州、西雅圖等團隊都具有強大的技術實力，能夠學習到很多。最后一點，對于開源大數據產品而言，基本上都是國外的天下，而MaxCompute是完全國產自研的平臺，加入MaxCompute團隊讓自己非常驕傲，能夠有機會為國產軟件盡一份力量。

七、如何走上大數據技術之路的

我走上大數據技術這條路也是機緣巧合的，之前在學校里面所學習的內容與大數據完全沒有關系，第一份工作也是視頻編碼相關的工作，后來在Uber轉向大數據相關的崗位。在進入Uber之前，Hadoop組還處于組建的早期，基本上還沒有人真正使用Hadoop，大家都是自己搭建一些服務來運行任務。當進入Uber的Hadoop組之后，跟著團隊從0到1地學習了Scala、Spark等，從最開始了解如何使用Spark到了解Spark源碼，然后慢慢地搭建起大數據平臺，接觸大數據領域。進入阿里巴巴之后，通過MaxCompute能夠從需求、設計、開發、測試以及最后的優化等全部階段來了解大數據產品，這也是比較寶貴的經歷。

八、在阿里巴巴美國辦公室的工作體驗

在阿里的美國部門其實和在阿里國內的部門差別并不大，可能在西雅圖的辦公室人數并不是很多，但是“麻雀雖小，五臟俱全”。西雅圖辦公室各個BU的成員都非常優秀，能夠和不同技術方向的同事碰撞出不同的思維火花。并且在阿里巴巴的美國辦公室，每年有很多對外交流的機會，也可以組織很多開源的分享。

九、如何成為第一位華人ORC的PMC

這其實是因為MaxCompute團隊需要ORC這款產品，而當時開源的C++版本的ORC只有Reader，卻沒有Writer，因此就需要自行開發C++版本的ORC的Writer。當MaxCompute團隊完成之后就希望集合開源的力量將C++版本的ORC的Writer做好，因此將代碼貢獻回了開源社區，并且得到了開源社區的認可。基于這些工作量，ORC的開源社區給了MaxCompute團隊兩個Committer名額。成為Committer之后，責任也就更大了，不僅自己需要寫代碼，還需要和社區一起成長，review其他成員的代碼，討論短期和長期的問題。ORC社區對于自己和MaxCompute團隊的工作較為認可，因此授予了PMC的職位。對個人而言，ORC開源的工作也代表了阿里巴巴對于開源的態度，不僅需要在數量上足夠多，還需要保證質量足夠好。

十、寄語
只要你對于開源感興趣并樂于持續地貢獻，無論擁有什么樣的背景和基礎，所有的付出最終都會被認可。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的MaxCompute技术人背后的故事：从ApacheORC到AliORC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。