Kudu 表具有與傳統(tǒng) RDBMS 中的表類似的結(jié)構(gòu)化數(shù)據(jù)模型。模式設計對于實現(xiàn) Kudu 的最佳性能和運行穩(wěn)定性至關重要。每個工作負載都是獨一無二的，沒有一個最合適每個表的單一模式設計。在高層次上，創(chuàng)建 Kudu 表有三個問題：列設計，主鍵設計和分區(qū)設計。其中只有分區(qū)對于熟悉傳統(tǒng)的非分布式關系數(shù)據(jù)庫的人來說將是一個新的概念。

The Perfect Schema (完美的模式)

完美的模式將完成以下工作：

• 數(shù)據(jù)將以這樣的方式進行分發(fā)，即讀取和寫入在 tablet servers 上均勻分布。受分區(qū)影響。
• Tablets 將以均勻，可預測的速度增長， tablets 的負載將隨著時間的推移而保持穩(wěn)定。受分區(qū)影響很大。
• 掃描將讀取完成查詢所需的最少數(shù)據(jù)量。主要受到主鍵設計的影響，分區(qū)通過修剪進行影響。

完美的模式取決于數(shù)據(jù)的特性，需要做的事情以及集群的拓撲。模式設計是最大限度地發(fā)揮 Kudu 集群性能的最重要的一件事。

Column Design (列設計)

Kudu 表由一個列或多個列組成，每個列都有一個定義的類型。不屬于主鍵的列可為空。支持的列類型包括：

• boolean
• 8-bit signed integer
• 16-bit signed integer
• 32-bit signed integer
• 64-bit signed integer
• unixtime_micros (64 位微秒)
• single-precision (32-bit) (單精度32位)
• double-precision (64-bit) (雙精度64位)
• UTF-8 encoded string (up to 64KB uncompressed) ( UTF-8 編碼字符串)
• binary (up to 64KB uncompressed) ( 二進制（高達 64KB 未壓縮） )

Kudu 利用強類型的列和柱狀磁盤存儲格式來提供高效的編碼和序列化。為了充分利用這些功能，列應該被指定為適當?shù)念愋?#xff0c;而不是使用字符串或二進制列來模擬 ‘schemaless’ 表，否則可能會進行結(jié)構(gòu)化。除了編碼之外，Kudu 允許按照每列進行壓縮。

Column Encoding ( 列編碼 )

可以根據(jù)列的類型，使用編碼創(chuàng)建 Kudu 表中的每個列。

Column Type ( 列類型 )Encoding ( 編碼 )Default ( 默認 )

int8, int16, int32	plain, bitshuffle, run length	bitshuffle
int64, unixtime_micros	plain, bitshuffle, run length	bitshuffle
float, double	plain, bitshuffle	bitshuffle
bool	plain, run length	run length
string, binary	plain, prefix, dictionary	dictionary

plain Encoding

數(shù)據(jù)以其自然格式存儲。例如，int32 values 作為固定大小的 32 位 little-endian integers 存儲。

Bitshuffle Encoding

重新排列一組值以存儲每個值的最高有效位，其次是每個值的第二個最高有效位，依此類推。最后，結(jié)果是 LZ4 壓縮。 Bitshuffle 編碼對于具有許多重復值的列或按主鍵排序時少量更改的列是不錯的選擇。 bithuffle 項目對性能和用例有很好的概述。

Run Length Encoding

通過僅存儲值和計數(shù)，在列中壓縮運行（連續(xù)重復值）。當按主鍵排序時，運行長度編碼對于具有許多連續(xù)重復值的列是有效的。

Dictionary Encoding

構(gòu)建了唯一值的字典，并且每個列值都被編碼為字典中的相應索引。字典編碼對于基數(shù)較低的列是有效的。如果給定行集的列值由于唯一值的數(shù)量太高而無法壓縮，則 Kudu 將透明地回退到該行集的純編碼。這在 flush 過程中進行評估。

Prefix Encoding

公共前綴在連續(xù)列值中進行壓縮。前綴編碼對于共享公共前綴的值或主鍵的第一列可能有效，因為行按 tablet 內(nèi)的主鍵排序。

Column Compression (列壓縮)

Kudu 允許使用 LZ4 ， Snappy 或 zlib 壓縮編解碼器進行每列壓縮。默認情況下，列未壓縮存儲。如果減少存儲空間比原始掃描性能更重要，考慮使用壓縮。

Primary Key Design (主鍵設計)

每個 Kudu 表必須聲明一個主鍵索引由一個或多個列組成。主鍵列必須不為空，并且可能不是布爾值或浮點型。在表創(chuàng)建期間設置后，主鍵中的列集合可能不會更改。像 RDBMS 主鍵一樣，Kudu 主鍵強制執(zhí)行唯一性約束;嘗試插入與現(xiàn)有行具有相同主鍵值的行將導致重復的鍵錯誤。與 RDBMS 不同，Kudu 不提供自動遞增列功能，因此應用程序必須始終在插入期間提供完整的主鍵。行刪除和更新操作還必須指定要更改的行的完整主鍵; Kudu 本身不支持范圍刪除或更新。在插入行之后，列的主鍵值可能不會被更新;但是，可以刪除該行并重新插入更新的值。

Primary Key Index (主鍵索引)

與許多傳統(tǒng)關系數(shù)據(jù)庫一樣，Kudu 的主鍵是 clustered index ( 聚集索引 )。 tablet 中的所有行都保持主鍵排序順序。在主鍵上指定相等或范圍約束的 Kudu 掃描將自動跳過不能滿足謂詞的行。這允許通過在主鍵列上指定相等約束來有效地找到各行。

Partitioning (分區(qū))

為了提供可擴展性，Kudu 表被劃分為稱為 tablets 的單元，并分布在許多 tablet servers 上。行總是屬于單個 tablet 。將行分配給 tablet 的方法由在表創(chuàng)建期間設置的表的分區(qū)決定。
選擇分區(qū)策略需要了解數(shù)據(jù)模型和表的預期工作負載。對于寫入繁重的工作負載，重要的是設計分區(qū)，以使寫入分散在 tablet 上，以避免單個 tablet 的超載。對于涉及許多短掃描的工作負載，如果所有掃描的數(shù)據(jù)位于同一個 tablet 中，那么遠程服務器的開銷占主導地位，可以提高性能。
Kudu 在創(chuàng)建表時不提供默認分區(qū)策略。建議預期具有較大讀寫工作負荷的新表至少與 tablet servers 一樣多的 tablets 。
Kudu 提供了兩種類型的分區(qū)：range partitioning 和 hash partitioning。表也可能具有多級分區(qū)，其結(jié)合范圍和哈希分區(qū)，或多個散列分區(qū)實例。

Range Partitioning (范圍分區(qū))

范圍分區(qū)使用完全有序的分區(qū)鍵。每個分區(qū)分配了范圍分區(qū)空間的連續(xù)段。如果范圍分區(qū)列與主鍵列匹配，則行的范圍分區(qū)鍵將等于其主鍵。在沒有哈希分區(qū)的范圍分區(qū)表中，每個范圍分區(qū)將對應于一個 tablet 。
在創(chuàng)建表時，將初始的范圍分區(qū)集合指定為一組分區(qū)邊界和拆分行。對于每個綁定，將在表中創(chuàng)建一個范圍分區(qū)。每個分割將兩個范圍分割。如果沒有指定分區(qū)界限，則表將默認為覆蓋整個空間的單個分區(qū)。范圍分區(qū)必須始終不重疊，拆分行必須在范圍分區(qū)內(nèi)。

Range Partition Management (范圍分區(qū)管理 )

Kudu 允許在運行時從表中動態(tài)添加和刪除范圍分區(qū)，而不影響其他分區(qū)的可用性。刪除分區(qū)將刪除屬于分區(qū)的 tablet 以及其中包含的數(shù)據(jù)。隨后插入到丟棄的分區(qū)將失敗?？梢蕴砑有路謪^(qū)，但不能與任何現(xiàn)有的分區(qū)重疊。 Kudu 允許在單個事務性更改表操作中刪除并添加任意數(shù)量的范圍分區(qū)。
動態(tài)添加和刪除范圍分區(qū)對于時間序列使用情況尤其有用。隨著時間的推移，可以添加范圍分區(qū)以覆蓋即將到來的時間范圍。例如，存儲事件日志的表可以在每月開始之前添加一個月份的分區(qū)，以便保存即將到來的事件。必要時可以刪除舊范圍分區(qū)，以便有效地刪除歷史數(shù)據(jù)。

Hash Partitioning (哈希分區(qū))

哈希分區(qū)通過哈希值將行分配到許多 buckets ( 存儲桶 )之一。在 single-level hash partitioned tables 中，每個 bucket將對應于一個 tablet 。在創(chuàng)建表時設置桶數(shù)。通常，主鍵列用作散列的列，但與范圍分區(qū)一樣，可以使用主鍵列的任何子集。哈希分區(qū)是一種有效的策略，當不需要對表進行有序訪問時。哈希分區(qū)對于在 tablet 之間隨機散布這些功能是有效的，這有助于減輕熱點和 tablet 大小不均勻。

Multilevel Partitioning (多級分區(qū))

Kudu 允許一個表在單個表上組合多級分區(qū)。零個或多個哈希分區(qū)級別可以與可選的范圍分區(qū)級別組合。除了單個分區(qū)類型的約束之外，多級分區(qū)的唯一附加約束是多個級別的哈希分區(qū)不能對相同的列進行哈希。當正確使用時，多級分區(qū)可以保留各個分區(qū)類型的優(yōu)點，同時減少每個分區(qū)的缺點。多級分區(qū)表中的 tablet 總數(shù)是每個級別中分區(qū)數(shù)量的乘積。

Partition Pruning ( 分區(qū)修剪 )

當可以確定分區(qū)可以被掃描謂詞完全過濾時，Kudu 掃描將自動跳過掃描整個分區(qū)。 要修剪哈希分區(qū)，掃描必須在每個散列列上包含相等謂詞。 要修剪范圍分區(qū)，掃描必須在范圍分區(qū)列上包含相等或范圍謂詞。對多級分區(qū)表的掃描可以獨立地利用任何級別的分區(qū)修剪。

Partitioning Examples (分區(qū)示例)

為了說明與為表設計分區(qū)策略相關的因素和權(quán)衡，通過一些不同的分區(qū)方案。 考慮存儲機器度量數(shù)據(jù)的下表模式（為了清楚起見，使用 SQL 語法和日期格式的時間戳）：

CREATE TABLE metrics (host STRING NOT NULL,metric STRING NOT NULL,time INT64 NOT NULL,value DOUBLE NOT NULL,PRIMARY KEY (host, metric, time), );

Range Partitioning Example (范圍分區(qū)示例)

分割度量表的一種自然方式是在時間列上對范圍進行分區(qū)。假設我們想要每年都有一個分區(qū)，該表將保存 2014 年，2015 年和 2016 年的數(shù)據(jù)。表格至少有兩種方式可以被分割：具有無界范圍的分區(qū)，也可以是有限范圍的分區(qū)。

上圖顯示了度量表可以在時間列上進行范圍分區(qū)的兩種方式。在第一個示例（藍色）中，使用默認范圍分區(qū)邊界，并在 2015-01-01 和 2014 年 1 月分隔。這導致三個 tablet ： 2015 年之前的第一個值， 2015 年的第二個值，以及 2016 年以后的第三個值。第二個例子（綠色）使用了[(2014-01-01) ，(2017-01-01)]，并分期于 2015-01-01 和 2016-01-01 。第二個例子可以等價地通過[(2014-01-01)，(2015-01-01)]，[(2015-01-01)，(2016-01-01)]和[(2016-01-01)，(2017-01-01)]，沒有分裂。第一個例子有無界的下限和上限分區(qū)，而第二個例子包括邊界。
上述范圍分區(qū)示例中的每一個都允許有時限的掃描來修剪掉在掃描時間限制之外的分區(qū)。當有很多分區(qū)時，這可以大大提高性能。寫作時，兩個例子都有潛在的熱點問題。由于度量趨向于始終在當前時間寫入，大多數(shù)寫入將進入單個范圍分區(qū)。
第二個例子比第一個例子更靈活，因為它允許未來幾年的范圍分區(qū)添加到表中。在第一個示例中，在 2016-01-01 之后的時間的所有寫入將落入最后一個分區(qū)，因此分區(qū)可能最終變得太大，以致于單個 tablet servers 無法處理。

Hash Partitioning Example (哈希分區(qū)示例)

分割 metrics table的另一種方法是在 host 和 metric columns 上哈希分區(qū)。

在上面的示例中，metrics table 是將 host 和 metric columns 上的哈希分區(qū)分為四個存儲桶。與前面的范圍分區(qū)示例不同，此分區(qū)策略將均勻地在表中的所有 tablets 上傳播寫入，這有助于總體寫入吞吐量。通過指定相等謂詞，掃描特定的 host 和 metric 可以利用分區(qū)修剪，將掃描的 tablet 數(shù)量減少到一個。使用純哈希分區(qū)策略要小心的一個問題是，隨著越來越多的數(shù)據(jù)被插入到表中， tablet 可以無限期地增長。最終 tablet 將變得太大，無法讓個人 tablet servers 持有。雖然這些示例編號為 tablet ，但實際上 tablet 只提供 UUID 標識符。哈希分區(qū)表中的 tablet 之間沒有自然排序。
Hash and Range Partitioning Example (哈希和范圍分區(qū)示例 )
上面的示例顯示了 metrics table 如何在 time column上進行范圍分區(qū)，或者在 host 和 metrics column 上進行哈希分區(qū)。這些策略具有相關的實力和弱點：

Strategy ( 策略 )Writes ( 寫入 )Reads ( 讀取 )Tablet Growth ( tablet 增長 )

range(time)	? - 所有寫入到最新分區(qū)	? - 可以修剪與時間綁定的 scan	? - 可以在未來的時間段添加新的 tablets
hash(host, metric)	? - 在 tablets 上均勻分布	? - 可以修剪對特定 hosts 和 metrics 的 scan	? - tablets 可以增長到很大

哈希分區(qū)有利于最大限度地提高寫入吞吐量，而范圍分區(qū)可避免 tablet 無限增長的問題。這兩種策略都可以利用分區(qū)修剪來優(yōu)化不同場景中的掃描。使用多級分區(qū)，可以組合這兩種策略，以獲得兩者的優(yōu)點，同時最大限度地減少每個策略的缺點。

在上面的示例中， time column 上的范圍分區(qū)與 host 和 metric columns 上的哈希分區(qū)相結(jié)合。這個策略可以被認為具有二維劃分：一個用于哈希級別，一個用于范圍級別。在當前時刻寫入此表將并行化到哈希桶的數(shù)量，在 4 這種情況下。讀取可以利用時間限制和特定的 host 和 metric 謂詞來修剪分區(qū)。可以添加新的范圍分區(qū)，這將導致創(chuàng)建 4 個額外的 tablet （好像新列已添加到圖表中）。
Hash and Hash Partitioning Example (哈希和哈希示例 )
Kudu 可以在同一個表中支持任意數(shù)量的哈希分區(qū)級別，只要這些級別沒有共同的 hashed columns。

在上面的示例中，表是主機上的哈希分區(qū)，分為 4 個桶，散列在公制中分區(qū)為 3 個桶，從而產(chǎn)生12個 tablet 。盡管在使用此策略時，所有 tablets 中的寫入將趨向于傳播，但是比單獨的 host 或 metric 的所有值始終屬于單個 tablet 時，與多個獨立列的哈希分區(qū)相比，它更容易受到熱點查找。掃描可以分別利用 host 和 metric columns 上的等式謂詞來修剪分區(qū)。多級哈希分區(qū)也可以與范圍分區(qū)相結(jié)合，邏輯上增加了分區(qū)的另一個維度。

總結(jié)

以上是生活随笔為你收集整理的Kudu模式设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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