這篇文章主要介紹“Apache Arrow是什么”，在日常操作中，相信很多人在Apache Arrow是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Apache Arrow是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

汾西網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),汾西網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為汾西成百上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務(wù)好的汾西做網(wǎng)站的公司定做！

Apache Arrow：一種適合異構(gòu)大數(shù)據(jù)系統(tǒng)的內(nèi)存列存數(shù)據(jù)格式標準

Arrow 項目簡介

現(xiàn)存的大數(shù)據(jù)分析系統(tǒng)基本都基于各自不同的內(nèi)存數(shù)據(jù)結(jié)構(gòu)，這就會帶來一系列的重復(fù)工作：從計算引擎上看，算法必須基于項目特有的數(shù)據(jù)結(jié)構(gòu)、API 與算法之間出現(xiàn)不必要的耦合；從數(shù)據(jù)獲取上看，數(shù)據(jù)加載時必須反序列化，而每一種數(shù)據(jù)源都需要單獨實現(xiàn)相應(yīng)的加載器；從生態(tài)系統(tǒng)上看，跨項目、跨語言的合作無形之中被阻隔。能否減少或消除數(shù)據(jù)在不同系統(tǒng)間序列化、反序列化的成本？能否跨項目復(fù)用算法及 IO 工具？能否推動更廣義的合作，讓數(shù)據(jù)分析系統(tǒng)的開發(fā)者聯(lián)合起來？在這樣的使命驅(qū)動下，Arrow 就誕生了。

與其它項目不同，Arrow 項目的草臺班子由 5 個 Apache Members、6 個 PMC Chairs 和一些其它項目的 PMC 及 committer 構(gòu)成，他們直接找到 ASF 董事會，征得同意后直接以頂級 Apache 項目身份啟動。想了解項目的詳細歷史可以閱讀項目 Chair，Jacques Nadeau 寫的這篇博客。另外，這張 google sheet 記錄著項目的取名過程，取名為 Arrow 的原因是：”math symbol for vector. and arrows are fast. also alphabetically will show up on top.” 可以說考慮得相當全面 ????。

Arrow 項目的愿景是提供內(nèi)存數(shù)據(jù)分析 (in-memory analytics) 的開發(fā)平臺，讓數(shù)據(jù)在異構(gòu)大數(shù)據(jù)系統(tǒng)間移動、處理地更快：

項目主要由 3 部分構(gòu)成：

• 為分析查詢引擎 (analytical query engines)、數(shù)據(jù)幀 (data frames) 設(shè)計的內(nèi)存列存數(shù)據(jù)格式

• 用于 IPC/RPC 的二進制協(xié)議

• 用于構(gòu)建數(shù)據(jù)處理應(yīng)用的開發(fā)平臺

整個項目的基石是基于內(nèi)存的列存數(shù)據(jù)格式，現(xiàn)在將它的特點羅列如下：

• 標準化 (standardized)，與語言無關(guān) (language-independent)

• 同時支持平鋪 (flat) 和層級 (hierarchical) 數(shù)據(jù)結(jié)構(gòu)

• 硬件感知 (hardware-aware)

基于內(nèi)存的列存格式

詳細、準確的格式定義請閱讀官方文檔，本節(jié)內(nèi)容參考了官方文檔及 Daniel Abadi 的這篇博客。

在實踐中，工程師通常會將系統(tǒng)中的數(shù)據(jù)通過多個二維數(shù)據(jù)表建模，每張數(shù)據(jù)表的一行表示一個實體 (entity)，一列表示同一屬性。然而，在硬件中存儲器通常是一維的，即計算機程序只能線性地、沿同一方向地從內(nèi)存或硬盤中讀取數(shù)據(jù)，因此存儲二維數(shù)據(jù)表就有兩種典型方案：行存和列存。通常前者適用于 OLTP 場景，后者適用于 OLAP 場景，Arrow 是面向數(shù)據(jù)分析開發(fā)的，因此采用后者。

任何一張數(shù)據(jù)表都可能由不類型的數(shù)據(jù)列構(gòu)成。以某張用戶表為例，表中可能包含如年齡 (integer)、姓名 (varchar)、出生日期 (date) 等屬性。Arrow 將數(shù)據(jù)表中所有可能的列數(shù)據(jù)分成兩類，定長和變長，并基于定長和變長數(shù)據(jù)類型構(gòu)建出更復(fù)雜的嵌套數(shù)據(jù)類型。

Fixed-width data types

定長的數(shù)據(jù)列格式如下所示：

1
2
3
4
5
6

type FixedColumn struct {
  data       []byte
  length     int
  nullCount  int
  nullBitmap []byte // bit 0 is null, 1 is not null
}

除了數(shù)據(jù)數(shù)組 (data) 外，還包含：

• 數(shù)組長度 (length)

• null 元素的個數(shù) (nullCount)

• null 位圖 (nullBitmap)

以 Int32 數(shù)組：[1, null, 2, 4, 8] 為例，它的結(jié)構(gòu)如下：

1
2
3
4
5
6
7
8
9

length: 5, nullCount: 1
nullBitmap:
|Byte 0 (null bitmap) | Bytes 1-63            |
|---------------------|-----------------------|
| 00011101            | 0 (padding)           |
data:
|Bytes 0-3   | Bytes 4-7   | Bytes 8-11  | Bytes 12-15 | Bytes 16-19 | Bytes 20-63 |
|------------|-------------|-------------|-------------|-------------|-------------|
| 1          | unspecified | 2           | 4           | 8           | unspecified |

這里有一個值得關(guān)注的設(shè)計決定，無論數(shù)組中的某個元素 (cell) 是否是 null，在定長數(shù)據(jù)格式中 Arrow 都會讓該元素占據(jù)規(guī)定長度的空間；另一種備選方案就是不給 null 元素分配任何空間。前者可以利用指針代數(shù)支持 O(1) 的隨機訪問，后者在隨機訪問時需要先利用 nullBitmap 計算出位移。如果是順序訪問，后者需要的內(nèi)存帶寬更小，性能更優(yōu)，因此這里主要體現(xiàn)的是存儲空間與隨機訪問性能的權(quán)衡，Arrow 選擇傾向是后者。

從 nullBitmap 的結(jié)構(gòu)可以看出，Arrow 采用 little-endian 存儲字節(jié)數(shù)據(jù)。

Variable-width data types

變長的數(shù)據(jù)列格式如下所示：

1
2
3
4
5
6
7

type VarColumn struct {
  data       []byte
  offsets    []int64
  length     int
  nullCount  int
  nullBitmap []byte // bit 0 is null, 1 is not null
}

可以看出，比定長列僅多存一個偏移量數(shù)組 (offsets)。offsets 的第一個元素固定為 0，最后一個元素為數(shù)據(jù)的長度，即與 length 相等，那么關(guān)于第 i 個變長元素：

1
2

pos  := column.offsets[i]                       // 位置
size := column.offsets[i+1] - column.offsets[i] // 大小

另一種備選方案是在 data 中利用特殊的字符分隔不同元素，在個別查詢場景下，后者能取得更優(yōu)的性能。如掃描字符串列中包含某兩個連續(xù)字母的所有列：利用 Arrow 的格式需要頻繁地訪問 offsets 來遍歷 data，但利用特殊分隔符的解決方案直接遍歷一次 data 即可。而在其它場景下，如查詢某字符串列中值和 “hello world” 相等的字符串，這時利用 offsets 能過濾掉所有長度不為 11 的列，因此利用 Arrow 的格式能獲取更優(yōu)的性能。

Nested Data

數(shù)據(jù)處理過程中，一些復(fù)雜數(shù)據(jù)類型如 JSON、struct、union 都很受開發(fā)者歡迎，我們可以將這些數(shù)據(jù)類型歸類為嵌套數(shù)據(jù)類型。Arrow 處理嵌套數(shù)據(jù)類型的方式很優(yōu)雅，并未引入定長和變長數(shù)據(jù)列之外的概念，而是直接利用二者來構(gòu)建。假設(shè)以一所大學的班級 (Class) 信息數(shù)據(jù)列為例，該列中有以下兩條數(shù)據(jù)：

1
2
3
4
5
6
7
8
9
10
11

// 1
Name:       Introduction to Database Systems
Instructor: Daniel Abadi
Students:   Alice, Bob, Charlie
Year:       2019

// 2
Name:       Advanced Topics in Database Systems
Instructor: Daniel Abadi
Students:   Andrew, Beatrice
Year:       2020

我們可以將改嵌套數(shù)據(jù)結(jié)構(gòu)分成 4 列：Name、Instructor、Students 以及 Year，其中 Name 和 Instructor 是變長字符串列，Year 是定長整數(shù)列，Students 是字符串數(shù)組列 (二維數(shù)組)，它們的存儲結(jié)構(gòu)分別如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

Name Column:
data:      Introduction to Database SystemsAdvanced Topics in Database Systems
offsets:   0, 32, 67
length:    2
nullCount: 0
nullBitmap: 
| Byte 0   | Bytes 1-63 |
|----------|------------|
| 00000011 | 0 (padding)|


Instructor Column:
data:      Daniel AbadiDaniel Abadi
offsets:   0, 12, 24
length:    2
nullCount: 0
nullBitmap:
| Byte 0   | Bytes 1-63 |
|----------|------------|
| 00000011 | 0 (padding)|


Students Column
data:                        AliceBobCharlieAndrewBeatrice
students offsets:            0, 5, 8, 15, 21, 29
students length:             5
students nullCount:          0
students nullBitmap:
| Byte 0   | Bytes 1-63 |
|----------|------------|
| 00011111 | 0 (padding)|
nested student list offsets:   0, 3, 5
nested student list length:    2
nested student list nullCount: 0
nested student list nullBitmap:
| Byte 0   | Bytes 1-63 |
|----------|------------|
| 00000011 | 0 (padding)|

Year Column
data:       2019|2019
length:     2
nullCount:  0
nullBitmap:
| Byte 0   | Bytes 1-63 |
|----------|------------|
| 00000011 | 0 (padding)|

這里的 Students 列本身就是嵌套數(shù)據(jù)結(jié)構(gòu)，而外層的 Class 表包含了 Students 列，可以看出這種巧思能支持無限嵌套，是很值得稱贊的設(shè)計。

Buffer alignment and padding

Arrow 列存格式的所有實現(xiàn)都需要考慮數(shù)據(jù)內(nèi)存地址的對齊 (alignment) 以及填充 (padding)，通常推薦將地址按 8 或 64 字節(jié)對齊，若不足 8 或 64 字節(jié)的整數(shù)倍則按需補全。這主要是為了利用現(xiàn)代 CPU 的 SIMD 指令，將計算向量化。

Memory-oriented columnar format

計算機發(fā)展的幾十年來，絕大多數(shù)數(shù)據(jù)引擎都采用行存格式，主要原因在于早期的數(shù)據(jù)應(yīng)用負載模式基本都逃不出單個實體的增刪改查。面對此類負載，如果采用列存格式存儲數(shù)據(jù)，讀取一個實體數(shù)據(jù)就需要在存儲器上來回跳躍，找到該實體的不同屬性，本質(zhì)上是在執(zhí)行隨機訪問。但隨著時間的推移，數(shù)據(jù)的增多，負載變得更加復(fù)雜，數(shù)據(jù)分析的負載模式逐漸顯露，即每次訪問一組實體的少數(shù)幾個屬性，然后聚合出分析結(jié)果，這時候列存格式的地位便逐漸提高。

在 Hadoop 生態(tài)中，Apache Parquet 和 Apache ORC 已經(jīng)成為最流行的兩種文件存儲格式，它們核心價值也是圍繞著列存數(shù)據(jù)格式建立，那么我們?yōu)槭裁催€需要 Arrow？這里我們可以從兩個角度來看待數(shù)據(jù)存儲：

• 存儲格式：行存 (row-wise/row-based)、列存 (column-wise/column-based/columnar)

• 主要存儲器：面向磁盤 (disk-oriented)、面向內(nèi)存 (memory-oriented)

盡管三者都采用列存格式，但 Parquet 和 ORC 是面向磁盤設(shè)計，而 Arrow 是面向內(nèi)存設(shè)計。為了理解面向磁盤設(shè)計與面向內(nèi)存設(shè)計的區(qū)別，我們來看 Daniel Abadi 做的一個實驗。

Daniel Abadi 的實驗

在一臺 Amazon EC2 的 t2.medium 實例上，創(chuàng)建一張包含 60,000,000 行數(shù)據(jù)的表，每行包含 6 個屬性，每個屬性值都是 int32 類型的數(shù)據(jù)，因此每行需要 24 字節(jié)空間，整張表占用約 1.5GB 空間。我們將這張表分別用行存格式和列存格式保存一份，然后執(zhí)行一個簡單的查詢：在第一列中查找與特定值相等的數(shù)據(jù)，即：

1

SELECT a FROM t WHERE t.a = 477638700;

不論是行存還是列存版本，CPU 的工作都是獲取整數(shù)與目標整數(shù)進行比較。但在行存版本中執(zhí)行該查詢需要掃描每行，即全部 1.5GB 數(shù)據(jù)，而在列存版本中執(zhí)行該查詢只需掃描第一列，即 0.25GB 數(shù)據(jù)，因此后者的執(zhí)行效率理論上應(yīng)該是前者的 6 倍。然而，實際的結(jié)果如下所示：

列存版本與行存版本的性能竟然相差無幾！原因在于實驗執(zhí)行時關(guān)閉了所有 CPU 優(yōu)化 (vectorization/SIMD processing)，使得該查詢的瓶頸出現(xiàn)在 CPU 處理上。我們來一起分析一下其中的原因：根據(jù)經(jīng)驗，從內(nèi)存掃描數(shù)據(jù)到 CPU 中的吞吐能達到 30GB/s，現(xiàn)代 CPU 的處理頻率能達到 3GHz，即每秒 30 億 CPU 指令，因此即便處理器可以在一個 CPU 周期執(zhí)行 32 位整數(shù)比較，它的吞吐最多為 12 GB/s，遠遠小于內(nèi)存輸送數(shù)據(jù)的吞吐。因此不論是行存還是列存，從內(nèi)存中輸送 0.25GB 還是 1.5GB 數(shù)據(jù)到 CPU 中，都不會對結(jié)果有大的影響。

如果打開 CPU 優(yōu)化選項，情況就大不相同。對于列存數(shù)據(jù)，只要這些整數(shù)在內(nèi)存中連續(xù)存放，編譯器可以將簡單的操作向量化，如 32 位整數(shù)的比較。通常，向量化后處理器在單條指令中能夠同時將 4 個 32 位整數(shù)與指定值比較。優(yōu)化后再執(zhí)行相同的查詢，實驗的結(jié)果如下圖所示：

可以看到與預(yù)期相符的 4 倍差異。不過值得注意的是，此時 CPU 仍然是瓶頸。如果內(nèi)存帶寬是瓶頸的話，我們將能夠看到列存版本與行存版本的性能差異達到 6 倍。

從以上實驗可以看出，針對少量屬性的順序掃描查詢的工作負載，列存格式要優(yōu)于行存格式，這與數(shù)據(jù)是在磁盤上還是內(nèi)存中無關(guān)，但它們優(yōu)于行存格式的理由不同。如果以磁盤為主要存儲，CPU 的處理速度要遠遠高于數(shù)據(jù)從磁盤移動到 CPU 的速度，列存格式的優(yōu)勢在于能通過更適合的壓縮算法減少磁盤 IO；如果以內(nèi)存為主要存儲，數(shù)據(jù)移動速度的影響將變得微不足道，此時列存格式的優(yōu)勢在于它能夠更好地利用向量化處理。

這個實驗告訴我們：數(shù)據(jù)存儲格式的設(shè)計決定在不同瓶頸下的目的不同。最典型的就是壓縮，對于 disk-oriented 場景，更高的壓縮率幾乎總是個好主意，利用計算資源換取空間可以利用更多的 CPU 資源，減輕磁盤 IO 的壓力；對于 memory-oriented 場景，壓縮只會讓 CPU 更加不堪重負。

Apache Parquet/ORC vs. Apache Arrow

現(xiàn)在要對比 Parquet/ORC 與 Arrow 就變得容易一些。因為 Parquet 和 ORC 是為磁盤而設(shè)計，支持高壓縮率的壓縮算法，如 snappy、gzip、zlib 等壓縮技術(shù)就十分必要。而 Arrow 為內(nèi)存而設(shè)計，對壓縮算法幾乎沒有要求，更傾向于直接存儲原生的二進制數(shù)據(jù)。面向磁盤與面向內(nèi)存的另一個不同點在于：盡管磁盤和內(nèi)存的順序訪問效率都要高于隨機訪問，但在磁盤中，這個差異在 2-3 個數(shù)量級，而在內(nèi)存中通常在 1 個數(shù)量級內(nèi)。因此要均攤一次隨機訪問的成本，需要在磁盤中連續(xù)讀取上千條數(shù)據(jù)，而在內(nèi)存中僅需要連續(xù)讀取十條左右的數(shù)據(jù)。這種差異意味著 內(nèi)存場景下的 batch 大小 (如 Arrow 的 64KB) 要小于磁盤場景下的 batch 大小。

到此，關(guān)于“Apache Arrow是什么”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

網(wǎng)站名稱：ApacheArrow是什么
鏈接分享：http://aaarwkj.com/article42/jeioec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護、動態(tài)網(wǎng)站、手機網(wǎng)站建設(shè)、小程序開發(fā)、企業(yè)建站、虛擬主機

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)