1.クーズーがある理由
Hadoopエコシステムで迅速なデータ入力と迅速な分析を実現するために利用できるソリューションは不完全ですが、不完全です。遅いデータ入力を犠牲にして高速分析を実装するか、遅い分析を犠牲にして高速データ入力を実装します。
Apache Kuduは、高速入力されたデータを迅速に分析するために生まれました。
クドゥの重要性は次のとおりです。
- ビッグデータ分析の複雑さは、ストレージシステムの制限が原因であることが多く、Kuduの制限ははるかに小さいため、ビッグデータ分析はある程度簡単になります。
- 新しいアプリケーションシナリオでは、Kuduが必要です。たとえば、機械で生成されたデータとリアルタイム分析に焦点を当てたアプリケーションがますます増えています
- 新しいハードウェア環境に適応し、より高いパフォーマンスとアプリケーションの柔軟性を実現
第二に、ソースコード学習アドレス
ソースコード学習アドレス：https://github.com/kudu-book/getting-started-kudu
3.クーズーのコンセプトと特徴
3.1 Kuduはストレージレイヤーです
Kuduはデータ自体を処理しない単なるストレージレイヤーですが、MapReduce、Spark、Impalaなどの外部Hadoop処理エンジンに依存しています。
Kuduは独立したストレージエンジンとして実行でき、HDFSやZookeeperなどの他のフレームワークに依存しません。
Kuduは、列ストレージ形式に従って、基盤となるLinuxファイルシステムにデータを保存します。
Kuduの使いやすさは以下に反映されています。
- RDBMSにより近い機能とデータモデルを提供します
- RDBMSのようなライブラリテーブルストレージ構造を提供する
- ユーザーがRDBMSと同じ方法でデータを挿入、更新、削除できるようにする
クドゥの最大の利点：
Kuduには、行ごとの挿入、低レイテンシのランダムアクセス、更新、高速分析スキャンの機能もあり、OLAPとOLTPでより優れたサポートを提供できます。同時にサポートするために複数のストレージシステムを必要としたこれらの複雑なアーキテクチャは置き換えられましたストレージシステムは1つだけで、すべてのデータがこのストレージシステムに格納されるため、ビッグデータの構造が大幅に簡素化されます。
3.2 Kuduテーブル構造
Kuduのテーブルは所有タイプの固定数の列で構成され、これらの列のサブセットが主キーを構成し、行の一意性を保証します。
Kuduテーブルは水平方向に多くのブロックに分割され、タブレットになります。
書き込み操作では、Raftコンセンサスアルゴリズムを使用して、タブレット間でデータをコピーします。
3.3 Kuduのメタデータ管理
Kuduは独自のメタデータ情報を保存し、メタデータはマスターサーバーが管理するタブレットに保存され、テーブル内のユーザーデータはタブレットサーバーが管理するタブレットに保存されます。ただし、KuduでImpalaを使用する場合は、サポートとしてHiveのMetastoreサービスも必要です。
3.4 Kuduと従来のエコシステムのSQLエンジンの比較
Kuduは、Hive、Impala、SparkSQLなどの従来のエコシステムのSQLエンジンと比較されます。
KuduはSQLクエリを完全には実行しません。射影演算や述語演算など、一部の演算のみがKuduにプッシュダウンされ、その他の演算はSQLエンジンによって実行されます。SQLには、パーサー、オプティマイザー、クエリ実行メソッドが必要です。
3.5 Kuduと従来のリレーショナルデータベースの比較
- リレーショナルデータベースと同様に、Kuduテーブルには一意の主キーがあります。
- トランザクション、外部キー、非主キーインデックスなどのリレーショナルデータベースの一般的な機能は、現在Kuduではサポートされていません。
- KuduにはOLAPおよびOLTPの機能がいくつかありますが、行間のアトミック性、一貫性、分離、および永続的なトランザクションのサポートが欠けています。
- Kuduは、ハイブリッドトランザクション/分析処理（HTAP）タイプのデータベースとして分類できます。
- Kuduは高速の主キー取得をサポートし、データが継続的に入力されている間に分析を実行できます。このシナリオでは、OLAPデータベースのパフォーマンスは通常あまりよくありません。
- Kuduの耐久性保証はOLTPデータベースに近いです。
- Kuduのクォーラム機能は、フラクチャミラーと呼ばれるメカニズムを実装できます。つまり、1つまたは2つのノードが行ストレージを使用し、他のノードが列ストレージを使用します。このようにして、OLTPタイプのクエリを行ストレージのノードで実行し、OLAPクエリを列ストレージのノードで実行して、2種類の負荷を混在させることができます。
3.6クーズーとビッグデータのコンポーネントの比較
Kuduは、HDFS、HBase、Cassandraなどのビッグデータコンポーネントと比較されます。
- HDFSは大規模スキャンには適していますが、ランダム読み取りには適していません。厳密に言うと、ランダム書き込みはサポートされていません。ランダム書き込みはマージによってシミュレートできますが、コストが高くなります。
- HBaseとCassandraは、ランダムアクセス、データのランダムな読み取りと変更には優れていますが、大規模なスキャンのパフォーマンスは低くなります。
- Kuduの目標は、HDFSのスキャンパフォーマンスの2倍を達成することであり、ランダム読み取りパフォーマンスはHBaseおよびCassandraに近いです。実際の目標は、SSDのランダム読み取り/書き込みレイテンシが1ミリ秒以内であることです。
3.7 Kuduの利点の概要
- ストレージエンジンの簡素化
- リアルタイム分析シナリオにより適しています
- RDBMSに似た機能構造と使用法
4、Kuduサーバー
すべてのKuduサーバーは、マスターサーバーとタブレットサーバーの2つのタイプに分類できます。サーバー上のデータはタブレットの形で保存されます。通常、各役割には少なくとも3つのサーバーがあります。タブレットのデータはこれらのサーバー間でコピーできます。Raftコンセンサスアルゴリズムにより、サーバーの1つがリーダーとして選出されます。
マスターサーバー
マスターサーバーの役割は、Kuduクラスターのさまざまな操作を管理することです。クライアントは、単一のマスターサーバーと対話して、テーブル定義を実装し、テーブル属性またはメタデータを取得します。マスターサーバーは、テーブル名、列名、列タイプ、データの場所などのメタデータ、およびテーブルの作成、実行、削除などのステータス情報を格納する単一のタブレットテーブルです。基本的に、マスターサーバーはシステムの「ディレクトリ」を管理し、この「ディレクトリ」はすべてのRDBMSでも使用されます。
テーブルごとのカタログデータの量が非常に少ない。パフォーマンスを向上させるために、システムは常にディレクトリデータの完全なライトスルーキャッシュをメモリに保持します。マスターサーバーがデータへのアクセスに非常に重要であっても、多くの操作を実行する必要はありません。したがって、それらは小さなサーバー（ハードウェア）に展開できます。マスターサーバーは構成のレプリケーションファクターを使用してメタデータストアを複製するため、レプリケーションファクターと同じ数のマスターサーバーを用意することが重要です。デフォルトでは、3つのサーバーをインストールする必要があります。これにより、Kuduクラスターの高可用性も確保されます。
タブレットサーバー
タブレットサーバーは、HDFS DataNodeとHBaseリージョンサーバーのハイブリッドに似た、機能するノードです。タブレットサーバーの役割は、データに関連するすべての操作（ストレージ、アクセス、エンコード、圧縮、圧縮、レプリケーション）を実行することです。マスターサーバーと比較して、タブレットは重い仕事を引き受けます。タブレットサーバーは、他のタブレットサーバーへのデータのコピーも行います。
- Kuduは最大300台のサーバーをサポートできます。ただし、最高の安定性を得るために、100台以下のタブレットサーバーを使用することをお勧めします。
- 各タブレットサーバーには、最大2000タブレット（コピーを含む）を含めることをお勧めします。
- 各テーブルには、タブレットサーバーごとに最大60タブレット（コピーを含む）を含めることをお勧めします。
- 各タブレットサーバーは、最大8 TBのデータをディスクに保存することをお勧めします。サーバー上のすべてのディスクの合計容量は8TBを超えることができ、HDFSと共有できます。
- 大きなファクトテーブルで最適なスキャンパフォーマンスを得るには、1つのCPUコアに対する1つのタブレットの比率を維持することをお勧めします。コピーされたテーブルはカウントせず、リーダータブレットの数のみを考慮してください。ディメンションが小さいテーブルの場合、割り当てられるタブレットは数個のみです。
5、Kuduパーティション分割メカニズム
ホットスポット
ホットシステムの問題は、分散システムでのデータアクセスにおける最も一般的な問題です。ほとんどの読み取りまたは書き込みクエリ（またはその両方）が同じサーバーにある場合、ホットスポットが表示されます。私たちが本当に達成したい効果は、データが完全に分散されるため、すべての読み取り/書き込み操作がクラスター内のほとんどのノードに分散されることです。
Kuduは、主キーに基づいてデータを再編成し、インデックスを作成します。現在、Kuduには、タスク、セカンダリキー、またはセカンダリインデックスの概念はありません。主キーまたはパーティションの設計が悪いと、通常はホットスポットが発生します。
Kuduのパーティション分割戦略
Kuduは、2つのタイプのパーティション（組み合わせ可能）を使用できます。範囲パーティションとハッシュパーティションです。
さまざまなパーティション化戦略によって主キーをパーティション化すると、ホットスポットを効果的に回避できます。
