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

以下內(nèi)容根據(jù)演講視頻以及PPT整理而成。

個人簡介

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

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

Apache ORC Project

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

ORC Adopter

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

Timeline

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

Contribution from Alibaba

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

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

Row-based VS. Column-based

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

A Quick Look at ORC

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

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

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

How about Apache Parquet

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

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

Benchmark: ORC VS Parquet

• Datasets

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

• Storage Cost

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

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

因此，綜上所述，在存儲效率方面，ORC和Parquet壓縮效率不相上下，在部分數(shù)據(jù)上ORC優(yōu)勢更大。

• Full Table Scan

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

AliORC = Alibaba ORC

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

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

AliORC is More Than Apache ORC

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

AliORC Optimization

• Async Prefetch

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

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

• Small I/O Elimination

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

如下圖所示的是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的優(yōu)化效果還是非常顯著的。

• Memory Management for streams in each column

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

• Seek Read

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

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

• Adapting Dictionary Encoding

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

• Range Alignment for Range Partition

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

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

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

四、AliORC為用戶帶來的價值

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

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

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

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

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

對于穩(wěn)定性而言，MaxCompute做的也非常好。其抗住了歷年雙11的流量洪峰，而直接使用Hadoop生態(tài)系統(tǒng)很難支持很大的體量的任務(wù)，往往需要各種深度定制優(yōu)化。

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

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

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

總結(jié)而言，相比于開源軟件，MaxCompute具有需求響應(yīng)更加及時、成本更低、技術(shù)門檻更低、穩(wěn)定性更高、性能更好、更加適合中國市場等特性。

六、為何選擇加入MaxCompute團隊

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

七、如何走上大數(shù)據(jù)技術(shù)之路的

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

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

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

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

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

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。