1. Kuduの設計および使用仕様は、データの研究開発およびデータ設計者に基本的な設計リファレンスを提供します。
2.スキーマ設計
Kuduテーブルはリレーショナルデータベーステーブルに似ており、どちらも構造化されたデータモデルを持っています。最適なパフォーマンスと運用の安定性のためには、スキーマの設計が非常に重要です。1種類のスキーマをすべてのテーブルに適用できるわけではありません。
Kuduテーブルを作成する場合、列の設計、プライマリキーの設計、およびパーティションの設計が含まれます。従来の非分散型リレーショナルデータベースの場合、パーティション化のみが新しい概念です。
3.エレガントなスキーマ
エレガントなスキーマには、次の条件が必要です。
データの読み取りと書き込みは、主にパーティションの影響を受ける各タブレットサーバーに均等に分散されます。
タブレットは安定した予測可能な速度で増加する可能性があり、ロードされたデータは24時間年中無休で利用できることが保証されています。これは主にパーティションの影響を受けます。
スキャン中に読み取られるデータの最小量は、主に主キーの設計に影響されますが、パーティショニングも重要な役割を果たします。
優れたシェマ設計は、データの特性、データを操作する対象、およびクラスターのトポロジーによって異なります。スキーマ設計は、kuduクラスターのパフォーマンスを最大化するための最も重要なことです。
4.カラムの設計
4.1。データタイプ
Kuduテーブルには複数の列が含まれ、各クラスにはタイプがあり、非プライマリキー列はnullにすることができます。サポートされている列タイプは次のとおりです。
ブール
8ビット符号付き整数
16ビット符号付き整数
32ビット符号付き整数
64ビット符号付き整数
unixtime_micros（Unix時代から64ビットマイクロ秒）
単一精度（32ビット）IEEE-754浮動小数点
倍精度（64ビット）IEEE -754浮動
小数点10進法（詳細は10進法タイプを参照）
UTF-8エンコード文字列（最大64KB非圧縮）
バイナリ（最大64KB非圧縮）
Kuduは、厳密に型指定された列と列ディスクストレージ形式を使用して、効率的なエンコードとシリアル化を提供します。これらの機能を最大限に活用するには、文字列またはバイナリ列を使用して「モードレス」テーブルをシミュレートするのではなく、適切なタイプとして列を指定する必要があります。Kuduでは、エンコードに加えて、列ごとに圧縮を指定することもできます。
// hbaseとは異なり、バージョンとタイムスタンプの列はありません。kuduは、行の変更を追跡するためのバージョンとタイムスタンプの列を提供しません。必要に応じて、自分で列を設計する必要があります。
4.2。デシマルタイプ
このタイプは、スケールと精度が固定されており、ファイナンスなどの算術演算に適しています。floatとdoubleの不正確な表現と丸め動作は、比較的非現実的です。10進タイプは、int64より大きい整数や、主キーに10進値がある場合にも役立ちます。
精度：小数点の位置に関係なく、列が表すことができる合計桁数を示します。この値は1から38の間でなければならず、デフォルト値はありません。たとえば、精度4は、最大9999の整数値、または最大99.99の値で小数点以下2桁を示します。対応する負の値をなしで表現することもできます
精度に変更を加えます。たとえば、-9999から9999の範囲でも、必要な精度は4だけです。
スケール：小数点以下の桁数を示します。値は0から精度の間でなければなりません。スケールが0の場合、小数部のない整数値が生成されます。精度とスケールが等しい場合、すべての数値は小数点以下になります。たとえば、精度とスケールが3に等しい小数は、-0.999から0.999の間の値を表すことができます。
パフォーマンスに関する考慮事項：Kuduは、decimalで指定された精度に応じて、各値を可能な限り少ないバイトで格納します。したがって、便宜上、可能な限り最高の精度を使用することはお勧めしません。これを行うと、パフォーマンス、メモリ、およびストレージに悪影響を与える可能性があります。
エンコードおよび圧縮前：
精度が9以下の10進値は4バイトで格納されます。
10〜18の精度の10進値は8バイトで保存されます。
18を超える精度の10進値は、16バイトで保存されます。
alterコマンドで変更できない列の精度とスケール
4.3。列のコーディング
は、列のタイプに応じてコーディングできます。
列タイプ
コーディング
デフォルト
int8、int16、int32
プレーン、ビットシャッフル、ランレングス
ビットシャッフル
int64、unixtime_micros
プレーン、ビットシャッフル、実行ength
ビットシャッフル
float、double、decimal
プレーン、ビットシャッフル
ビットシャッフル
ブール
プレーン、ランレングス
走る長さ
文字列、バイナリ
プレーン、プレフィックス、辞書
辞書
4.3.1。プレーンエンコーディング
データは自然な形式で保存されます。たとえば、int32値は、固定サイズの32ビットリトルエンディアン整数として格納されます。
4.3.2。ビットシャッフルエンコーディング
は、値のブロックを再配置して、各値の最上位ビットを格納し、次に2番目に上位のビットを格納します。最後に、結果はLZ4圧縮です。値が何度も繰り返される場合、または主キーでソートしたときに値がほとんど変化しない場合は、ビットシャッフルエンコーディングが適しています。
4.3.3。ランレングスエンコーディング
は、主に値と数のみを格納することにより、連続して繰り返される値に圧縮ストレージを使用します。このエンコーディングは、主キーで並べ替えたときに、連続して繰り返される値が多数ある列に効果的です。
4.3.4。辞書のエンコード
すべての値を格納する辞書を作成します。各列の値は、インデックスを使用してエンコードおよび格納されます。値の数が少ない場合は、この方法がより効果的です。それ以外の場合、Kuduはラインセットの純粋なエンコーディングに透過的にフォールバックします。これは、フラッシュ中に評価および計算されます。
4.3.5。プレフィックスエンコーディング
は、連続する列値の共通プレフィックスを圧縮します。タブレットの行は主キーを並べ替えることによって保存されるため、共通のプレフィックスまたは主キーの最初の列を持つ値に効果的である可能性があります。
4.3.6。列の圧縮
Kuduを使用すると、列で圧縮されたLZ4、Snappy、またはzlib圧縮コーデックを使用できます。デフォルトでは、圧縮は実行されません。生のスキャンパフォーマンスよりもストレージスペースの削減が重要な場合は、圧縮の使用を検討してください。
各データセットの圧縮方法は異なりますが、一般的に言えば、LZ4が最高のパフォーマンスのコーデックであり、zlibスペースの圧縮は比較的大きくなります。ビットシャッフルでエンコードされた列は自動的にLZ4圧縮を使用するため、このエンコードに他の圧縮を適用することはお勧めしません。
5.プライマリキーの設計
各Kuduテーブルは、1つ以上の列で構成されるプライマリキーを宣言する必要があります。RDBMSプライマリキーと同様に、Kuduプライマリキーは一意性の制約を適用します。既存の行と同じプライマリキー値を持つ行を挿入しようとすると、重複キーエラーが発生します。
主キー列はnull不可である必要があり、boolean、float、またはdoubleタイプにすることはできません。
指定したプライマリキーでテーブルを作成した後は、変更できません。
RDBMSとは異なり、Kuduは列の自動インクリメントを提供しないため、アプリケーションは完全なプライマリキーを提供する必要があります。
削除および更新するときは、完全なプライマリキーを指定する必要があります。Kuduは範囲の削除または更新をサポートしていません。それは、主キーを介して操作を完了することです。
主キーの値は変更できません。ただし、カーブを削除して再挿入すると、国を保存できます。
5.1。プライマリキーインデックス
多くの従来のリレーショナルデータベースと同様に、Kuduのプライマリキーはクラスタ化されたインデックスです。タブレットのすべての行は、主キーで並べ替えられます。Kudu行をスキャンする場合、プライマリキー列で等値または範囲フィルタリングを使用すると、効果的に行を見つけることができます。
5.2。埋め戻し挿入に関する考慮事項
ここで、主キーがタイムスタンプである場合、または主キーの最初の列がタイムスタンプである場合を考えてみます。挿入ごとに、kuduはプライマリキーインデックスストレージ領域でプライマリキーを検索して、プライマリキーが存在するかどうかを確認し、存在する場合は、プライマリキーの複製エラーを返します。データが生成された時間を保存する主キーとして使用すると、ホットデータが少なくなり、存在チェックが高速になり、ディスクに移動しなくてもメモリ内でヒットできます。
オフラインの履歴データの場合、各挿入は事前に冷却されている可能性があり（プライマリキーはメモリに配置できません）、ディスクにアクセスします。場合によっては複数のディスクにアクセスします。通常の状況では、kuduは1秒あたり数百万の挿入に達する可能性がありますが、データを埋め戻す場合、1秒あたり数千の挿入しか維持できません。
埋め戻しデータのパフォーマンスの最適化：
主キーの圧縮を容易にします。
ソリッドステートディスクを使用し
て主キーの構造を変更し、埋め戻しの主キーが連続範囲になるようにします。
6.パーティションの設計
kuduのテーブルは多くのタブレットに分割され、複数のサーバーに分散されています。各行はタブレットに属しています。行がどのタブレットに分割されるかは、テーブルの作成時に設定されるパーティションによって決まります。
書き込みが頻繁に行われる場合は、すべてのタブレット間で書き込みアクションのバランスを取り、1つのタブレットへの圧力を効果的に軽減することを検討してください。小規模なスキャン操作の場合、スキャンしたデータが1つのタブレットにあると、パフォーマンスを向上させることができます。
Kuduにはデフォルトのパーティションがありません。テーブルを作成するとき、kuduはデフォルトのパーティション戦略を提供しません。読み取りと書き込みが多いテーブルは、tserverサーバーの数と同じ数のパーティションに設定することをお勧めします。
Kuduには、範囲パーティションとハッシュパーティションの2種類のパーティションがあります。テーブルには、マルチレベルパーティション、使用範囲とハッシュの組み合わせ、または複数のハッシュの組み合わせを含めることができます。
6.1。範囲パーティション
Kuduを使用すると、他のパーティションの可用性に影響を与えることなく、実行時に範囲パーティションを動的に追加および削除できます。パーティションを削除すると、パーティションに含まれているデータが削除されます。その後、削除されたパーティションへの挿入は失敗します。新しいパーティションを追加できますが、既存の範囲パーティションと重複してはなりません。Kuduでは、1回のトランザクション変更テーブル操作で任意の数の範囲パーティションを削除および追加できます。
範囲パーティションを動的に追加および削除すると、時系列に特に役立ちます。時間の経過とともに、範囲パーティションを追加して、今後の時間範囲をカバーすることができます。たとえば、イベントログを格納するテーブルでは、毎月の開始前に月のパーティションを追加して、今後のイベントを保存できます。古い範囲パーティションを削除して、必要に応じて履歴データを効果的に削除できます。
6.2。ハッシュパーティション
ハッシュパーティションは、ハッシュ値に従ってバケットの1つに行を割り当てます。シングルレベルのハッシュパーティションテーブルでは、各バケットは1つのタブレットにのみ対応します。テーブル作成時にバケット数を設定します。通常、主キー列はハッシュされる列として使用されますが、範囲分割と同様に、主キー列の任意のサブセットを使用できます。
テーブルへの整然としたアクセスが必要ない場合は、ハッシュパーティショニングが効果的な戦略です。ハッシュ分割は、タブレット間のランダム書き込みに非常に効果的であり、ホットスポットや不均一なタブレットサイズを軽減するのに役立ちます。
6.3。マルチレベルパーティショニング
Kuduを使用すると、テーブルで複数レベルのパーティショニングを1つのテーブルに組み合わせることができます。ゼロ個以上のハッシュパーティションを範囲パーティションと組み合わせることができます。各パーティションタイプの制約に加えて、マルチレベルパーティショニングの唯一の追加の制約は、マルチレベルハッシュパーティションが同じ列をハッシュできないことです。
マルチレベルパーティショニングを正しく使用すると、各パーティションタイプのメリットを維持しながら、各パーティションタイプのデメリットを減らすことができます。マルチレベルパーティションテーブル内のタブレットの総数は、各レベルのパーティション数の積です。
6.4。パーティションのプルーニング
スキャン条件によってパーティションを完全に判別できる場合、kuduはパーティション全体のスキャンを自動的にスキップします。ハッシュパーティションを決定するには、スキャン条件に各ハッシュ列の同等性判断条件を含める必要があります。マルチレベルパーティションテーブルのスキャンでは、各レベルのパーティション定義を個別に使用できます。
7.スキーマの変更
次の方法でテーブル構造を変更できます。
テーブルの
名前の変更、プライマリキー列の名前の変更
、非プライマリキー列の追加または削除、
範囲パーティションの追加と削除
、および単一のトランザクション操作での複数の変更手順の組み合わせ。
8.既知の制限
Kuduには現在、アーキテクチャ設計に影響を与える可能性のあるいくつかの既知の制限があります。
列数
デフォルトでは、Kuduは300列を超えるテーブルの作成を許可していません。最高のパフォーマンスを得るには、アーキテクチャ設計の列を少なくすることをお勧めします。
セルサイズ
をエンコードまたは圧縮する前に、1つのセルを64KBより大きくすることはできません。Kuduが内部複合キーのエンコードを完了した後、複合キーを構成するユニットは合計16KBに制限されます。これらの制限を満たさない行を挿入すると、エラーがクライアントに返されます。
1つのセルのサイズは64KBにもなる可能性があり、Kuduは最大300列をサポートしますが、1行が数百KBを超えないようにすることをお勧めします。
テーブル名や列名などの識別子は、有効なUTF-8シーケンスであり、256バイト以下である必要があります。
不変のプライマリキーKuduでは、プライマリキー列を更新できません。
変更できない主キーKuduでは、テーブルの作成後に主キー列を変更することはできません。
不変のパーティション
レンジ・パーティションの追加や削除のほかには、クーズーは、あなたが作成した後、テーブルの分割方法を変更することはできません。
変更できない列タイプKuduでは、列タイプを変更できません。
パーティション分割
によってテーブルが作成された後は、パーティションを分割またはマージすることはできません。
9.保管制限
kuduの単一のtablet_serverパーティションは1500を超えることはできません。複数のtablet_serverが1500を超える場合は、評価と拡張が必要です。
22個の
マスターを備えた5台のタブレットサーバーの
最大データストレージ容量は、レプリケーションと圧縮後の各タブレットサーバーで24TBです。
各タブレットサーバーは、タブレットのコピーを含む1500個のタブレットを管理します。
テーブルを作成する場合、各タブレットサーバーのテーブルあたりのタブレットの最大数は60です。
上記の制限に基づいて、次のことが推測できます。
Kuduに保存されるデータの合計量は、タブレットサーバーの総数として推奨されます。単一のタブレットサーバーのデータ量= 22 24TB = 528TB / 3 = 176TB
単一のタブレットのデータ量は、単一のタブレットサーバーのデータ量/各タブレットサーバーのタブレットの総数です。 = 24TB / 1500 = 16G。
Kuduでサポートされている圧縮方法は、LZ4、Snappy、またはzlibです。さまざまな圧縮アルゴリズムの圧縮率は一般に50％を超えないという事実を考慮して、圧縮前の各タブレットのデータのサイズは8G未満にすることをお勧めします。
kuduシングルテーブルストレージの最大数：8億
10.ライフサイクル仕様
通常のテーブル
SUBSレイヤー：すべてのシステムデータはSUBSレイヤーに入力する必要があります。原則として、データは永続的に保存され、実際の状況に応じて調整できます（たとえば、1日あたりのデータ量が100 GBを超えるなど、データ量が非常に多い）。kuduテーブルデータは12か月間保持されます（実際の状況が定義されています）、12か月以上をハイブにダンプできます。
kuduによって保存されたデータに基づいて、次の定義に従って、ビジネスの実際のニーズに応じて保持されます。
ODS、DW、DM、ADSレイヤー：
3か月以内の最大訪問期間が4日以下の場合、保持日数を7日に設定することをお勧めします。
3か月以内の最大訪問期間が12日以下の場合、保持日数を15日に設定することをお勧めします。
3か月以内の最大アクセス期間が30日以下の場合、保持日数を33日に設定することをお勧めします。
3か月以内の最大訪問期間が90日以下の場合、保持日数を93日に設定することをお勧めします。
3か月以内の最大訪問期間が180日以下の場合、保持日数を183日に設定することをお勧めします。
3か月以内の最大アクセス期間が365日以下の場合、保持日数を368日に設定することをお勧めします。
上記のライフサイクルの定義は業界で一般的な定義であり、実際のビジネス状況に応じて調整できます。
データドメインのさまざまな要件に従って保存し、対応するコールドおよびホットデータ分離ストレージソリューションをサポートします。
時間分割テーブルの場合、データコンテンツのライフサイクルに応じて、ライフサイクルを超えるサブテーブルを定期的に削除します。
中間表
は実際の状況に応じて保管期間を設定し、原則として保管期間は結果表より長くはありません。
バックアップテーブル
は、実際のバックアップニーズに応じてストレージ期間を設定します。
一時テーブル一時テーブル
の最大ライフサイクルは10日です。一時テーブルのライフサイクルについては、対応するテストツールとメソッドを提供し、削除する前に関連するプロンプトを表示する必要があります。
11テーブル構築仕様
1.最大ハッシュパーティションは60パーティションを超えることはできません
2.Kuduハッシュパーティション作成テーブルの例
CREATE TABLE IF NOT EXISTS [db_name.]table_name
(
id BIGINT PRIMARY KEY COMMENT '注释',
agent STRING COMMENT '注释',
...
PRIMARY KEY ( uuid )
)
PARTITION BY HASH (id) PARTITIONS 4
COMMENT '注释' stored AS kudu;kudu混合パーティションの例：
CREATE TABLE cust_behavior_1 (
id BIGINT,
sku STRING,
salary STRING,
edu_level INT,
usergender STRING,
group STRING,
city STRING,
postcode STRING,
last_purchase_price FLOAT,
last_purchase_date BIGINT,
category STRING,
rating INT,
fulfilled_date BIGINT,
PRIMARY KEY (id, sku)
)
PARTITION BY
HASH (id) PARTITIONS 4,
RANGE (sku)
(
PARTITION VALUES < ‘g’,
PARTITION ‘g’ <= VALUES < ‘o’,
PARTITION ‘o’ <= VALUES < ‘u’,
PARTITION ‘u’ <= VALUES
) STORED AS KUDU
TBLPROPERTIES(
‘kudu.table_name’ = ‘cust_behavior_1 ‘,’kudu.master_addresses’ = ‘hadoop5:7051’);時間分割の例：
CREATE TABLE IF NOT EXISTS k_ods_collect_dw_yarn_apps_resource_ds(
app_id string comment'任务ID',
use_type string comment'资源使用类别',
name string comment'资源名称',
ds string comment'日汇总',
resource_type string comment'资源类别',
maximum_allocation bigint comment'最大分配',
minimum_allocation bigint comment'最小分配',
shorthand_representation string comment'快速描述',
units string comment'单位',
value bigint comment'值',
collect_time bigint comment'采集时间',
PRIMARY KEY (app_id,use_type,name,ds))
partition by hash(app_id,use_type,name,ds) partitions 4,
RANGE (ds) (
PARTITION '20201112' <= VALUES < '20210101',
PARTITION '20210101' <= VALUES < '20210201',
PARTITION '20210201' <= VALUES < '20210301',
PARTITION '20210301' <= VALUES < '20210401',
PARTITION '20210401' <= VALUES < '20210501',
PARTITION '20210501' <= VALUES < '20210601',
PARTITION '20210601' <= VALUES < '20210701',
PARTITION '20210701' <= VALUES < '20210801',
PARTITION '20210801' <= VALUES < '20210901',
PARTITION '20210901' <= VALUES < '20211001',
PARTITION '20211001' <= VALUES < '20211101',
PARTITION '20211101' <= VALUES < '20211201',
PARTITION '20211201' <= VALUES < '20220101'
)
COMMENT 'k_ods_collect_dw_yarn_apps_resource_ds'
stored as kudu;