KUDU(五)kudu優化

_東極發表於2020-10-20
優化

文章目錄

機架感知

Kudu可以知道每個Tablet Server處於哪個資料中心的哪個機架上,副本的負載均衡策略就可以考慮更全面,避免一個tablet的多個副本負載在同一機架,防止機架故障時tablet不可用。
在這裡插入圖片描述
上圖中，L0-L2是三個機架，TS0 -TS5是5臺Tablet Server，有兩張表：
A表(副本因子=3)，包含A0-A3四個tablets
B表(副本因子=5)，包含B0-B2三個tablets
如果Kudu配置了機架感知，它就會發現上面的tablet分佈違背了相關規則：
副本A0.0和A0.1構成了大多數副本（三分之二），並且位於相同的位置/ L0中，一旦L0機架電源或者交換機故障，將只有L1上的A0.2一個tablet副本可用且無法選擇出leader（根據Raft協議必須 n/2+1 個副本正常才可以選舉，n=總副本數）
B表的大多數副本集中在TS0-TS4，而TS5非常空閒，在即考慮機架分散式由考慮負載均衡的前提下，需要把B表的相關副本往TS5挪一挪
經過手工負載均衡，負載可能會變成如下樣子
在這裡插入圖片描述

透明分層儲存管理方案

  1. 儲存選擇方法
    Kudu是為快速資料上的快速分析場景而生的，但是Kudu的成本並不低，且擴充套件性並沒有那麼好（tserver的個數不能太多）
    HDFS旨在以低成本實現無限的可擴充套件性。它針對資料不可更改的面向批處理的場景進行了優化，當使用Parquet檔案格式，可以以極高的吞吐量和效率訪問結構化數
    對於資料比較小且不斷變化的資料（例如維表）通常全部存放到Kudu當資料不會超過Kudu的擴充套件範圍限制，且能夠從Kudu的獨特功能中受益時（快速變化、快速分析），通常作為大表儲存在Kudu
    當資料量非常大，面向批處理且基本不太可能變更的情況下首選以Parquet格式將資料儲存在HDFS中（冷資料）
    2.基於滑動視窗的透明儲存管理方案
    當您需要兩個儲存層的優勢時，滑動視窗模式是一個有用的解決方案。該方案的主要思路是：
    使用Impala建立2張表：Kudu表和Parquet 格式的HDSF表這兩張表都是按照時間分割槽的表，分割槽粒度取決於資料在Kudu表和HDSF表之間遷移的頻率，一般是按照年或者月或者日分割槽，特殊情況下可以更細粒度在Impala另外建立一個統一檢視，並使用where字句定義一個邊界，由該邊界決定哪些資料該從哪個表讀取Kudu中變冷的資料分割槽會定期的被刷寫到HDFS（Parquet ）資料刷寫之後，在HDFS表新增分割槽、使用原子的ALTER VIEW 操作把檢視的邊界往前推移
    優點;

流式資料可立即查詢
可以更新遲到的資料或進行手動更正
HDFS中儲存的資料具有最佳大小，可提高效能並防止小檔案降低成本

  1. 資料從Kudu遷到HDFS的過程
    資料從Kudu遷移到HDFS需要經過下面兩個步驟，該過程需要定時自動排程
    資料遷移在第一階段，將現在不變的資料從Kudu複製到HDFS。 即使將資料從Kudu複製到HDFS，在檢視中定義的邊界也將阻止向使用者顯示重複資料。 此步驟應該包含檢查機制，以確保成功完成資料的遷移和解除安裝。
    在這裡插入圖片描述
    後設資料修改
    在第二階段，既然已將資料安全地複製到HDFS，則更改後設資料以調整如何顯示解除安裝的分割槽。 這包括向前移動邊界，新增下一個時間視窗的新的Kudu分割槽以及刪除舊的Kudu分割槽。

索引跳躍式掃描優化

CREATE TABLE metrics (
 host STRING,
 tstamp INT,
 clusterid INT,
 role STRING,
 PRIMARY KEY (host, tstamp, clusterid)
);

Kudu在內部會建立主鍵索引（B-tree），跟上表類似，索引資料按所有主鍵列的組合排序。當使用者查詢包含第一主鍵列（host）時，Kudu將使用索引（因為索引資料主要在第一個主鍵列上排序）
如果使用者查詢不包含第一個主鍵列而僅包含tstamp列怎麼辦？tstamp雖然在固定host下是有序的，但全域性是無須的，所以無法使用主鍵索引。在關係型資料庫中一般採用二級索引，但是Kudu並不支援二級索引
tstamp之前的列為“prefix column”，列的具體值為“prefix
key”，在我們們的例子中host就是prefix column。在索引中首先按照prefix key排序，相同的prefix key在按照剩餘列的值排序，因此可以使用索引跳轉到具有不同prefix key且tstamp滿足條件的行上

SELECT clusterid FROM metrics WHERE tstamp = 100，其餘的是跳過的。Tablet Server使用索引（ prefix key (host =
helium)+tstamp = 100）跳過不匹配的行直接到達第三行並逐步掃描直到不匹配tstamp = 100，就通過下一個prefix key (host = ubuntu)+tstamp = 100繼續跳過不匹配的行。其餘prefix key採用相同的做法，這就叫做Index Skip Scan優化

效能

索引跳躍式掃描優化的效能與字首列（prefix column）的基數（prefix key去重後的數量）負相關
host的基數越低，跳躍掃描效能越高，反之則效能越差。
字首列基數很高時，索引跳躍式掃描優化就不可取了

在每個tablet一千萬行的資料規模下，當【字首列host基數>sqrt(number_of_rows_in_tablet)】時，索引跳躍式掃描效能開始下降。 為了解決這個問題：
Kudu目前在【跳躍次數>sqrt(number_of_rows_in_tablet)】時自動禁用跳躍掃描優化

資源規劃

在做資源規劃是重點考慮的是tserver，master負載要小很多，回顧已知tserver相關的建議和限制如下

選項 最佳效能(建議值) 限制
tablet server數 不超過100 300+
tablet數/tablet server（含副本） 1000+ 4000+
tablet數/表/tablet server（含副本） 60+ 60+
單臺tablet server儲存資料（含副本，壓縮後） 8TB+ 10TB+
單tablet儲存資料（超過會效能下降、合併失敗、啟動慢） 10G 50G
單tablet對應CPU核心數（不考慮副本，不考慮小表） 1 多對1
tablet server記憶體 16G以上最佳 不低於4G

相關文章