Apache Kuduを使った分析システムの裏側

1© Cloudera, Inc. All rights reserved.
Apache Kudu を使った分析システムの裏側
Takahiko Sato - Sales Engineer at Cloudera
Nov 7, 2017

⾃⼰紹介
• 佐藤貴彦 (さとうたかひこ) / takahiko at cloudera.com
• セールスエンジニア
• お客様がCloudera製品及び関連技術をを活⽤できるように、⼀緒に議論する
のがメインの仕事
• これまでの経験
• Internet & Network（⼤学）
• RDBMS（1社⽬）
• NoSQL（2社⽬）
• Hadoop（3社⽬） ←Now!

はじめに

いきなり今⽇のまとめ
Apache Kuduとは？
• ⼤規模データ（ペタバイト、1000億⾏以上）を扱えるデータベース
• SQLを使って構造化データを分析
• 更新(INSERT/UPDATE/DELETE)を⾏いつつ、⼤規模スキャン(SELECT)可能
• HTAP: OLTPとOLAPの融合
Kuduで分析システムをつくるには？
• 複数ノードで分散並列処理
• スキーマ設計パーティション戦略が重要
• 各ノードのディスクは複数本⽤意、SSDの利⽤を推奨
• あとはリレーショナルDBのようにSQLアクセスで分析！

分析データベース

分析データベースといわれて想像するものは？
SQL? DWH？
BI?
OLAP?RDBMS?
DataMart?

リレーショナルDBを⽤いたデータ分析
拡張性のつらさ
• スケールアップするにも、OLTPはせいぜい1TBのRAMに収まるまで
• スケールアウトは、シェアードナッシングが基本で設計運⽤で対処
OLTPとOLAPの世界は分離
• 異なる2種類のワークロード
進歩しつつはあるも、依然として⼤規模データの分析に困難
insert/update/delete
分析対象
OLTPの世界 OLAPの世界（DWH）
BIツール
select

Hadoopエコシステムを⽤いた⼤規模データ分析
スケーラビリティの⾼いHadoopエコシステム
• スケールアウトでペタバイト(PB)級のデータも処理可能
HDFSは⼤規模スキャンが得意なので、OLAP系のアクセスは得意
• Impala/Hive経由でSQLによるスキャンもできる
• しかしHDFSはデータの更新は得意ではない
• HBaseでは⼤規模のOLTP系のアクセスは得意
しかしHBaseからの結局データ変換が必要ですぐさま分析することができない
put
Hadoopの世界 BIツール
select
HBase
ETL
Impala
HDFS
put

HTAP : 求められるOLTPとOLAPの融合
OLTP? OLAP?
次世代のデータ処理はこれらのハイブリッド
• 流れ続けるデータに対して継続的な分析
• OLTPのようにデータを受け続け、OLAPの様に分析をし続ける、そんなハイ
ブリッド型のアーキテクチャが求められる
HTAP(Hybrid Transactional/Analytic Processing)
• ガートナーによる造語
• 技術的に固まった定義があるわけではなく、様々な解釈があるが...
• 「新たに発⽣したアーキテクチャ」
• KuduもこのHTAPと呼ばれるジャンルのデータベース
HTAP

Kudu概要

Kudu: 急速に変化するデータに⾼速な分析
HDFS
⾼速スキャン,
分析及びストアされ
たデータの処理
オンラインでの
⾼速な更新＆
データ提供
任意のストレージ
(アクティブアーカイブ)
⾼速な分析
(急速に変化 or 頻繁に
更新されるデータ)
変化なし
急速に変化し
頻繁に更新
HBase
追記のみ
リアルタイム
Kudu
Analytic
Gap
分析のペース
データの更新ペース

スケーラブルで⾼速な表形式のストレージ
スケーラビリティ
• 275ノード（〜3PBクラスター）までテスト済み
• 1000ノード超、数⼗PBまでスケールできるような設計
⾼速性能
• クラスターで秒間数百万のリード/ライト
• 1ノードあたり数GB/秒のリードスループット
テーブル形式
• リレーショナルDBのような構造化されたテーブルでデータを表現
• 厳密なスキーマ、有限個の列、⾮BLOB
• 1000億⾏以上からなるテーブルの個々の⾏レベルのアクセスが可能
複数ノードで1つのデータベース
...

Kuduは次世代のハードウェアに対応
SSDは毎年安くなり速くなる。
永続性のあるメモリー (3D XPoint™)の登場。
KuduはIntelのNVMeライブラリを使ってお
り、SSDやNVMeを効果的に扱える。
RAMは毎年安くなり毎年⼤きくなる。
Kuduは⼤規模なメモリー上でスムーズ
に動作する。
GC問題を避けるために、C++で書かれ
ている。
現在のCPUは、コア数の増加とSIMD
命令幅の増加であり、GHzの増加では
なくなっている。
KuduはSIMD命令と同時並⾏性の⾼い
データ構造を効果的に扱うことがで
きる。
SSD より安くより⼤きなメモリ現在のCPUにおける効率性

KuduのSQLインターフェース
• Kudu はリレーショナルデータベースに似た構造を持つストレージだが、クエ
リエンジン（SQL）は他に任せている
Query Engine
Storage Engine
Catalog
Query Engine
(Impala)
Catalog
(HMS)
モノリシックな
モダンな分析データベース
Storage
(Kudu)
Storage
(S3)
Storage
(HDFS)

Apache Impala: Hadoop向けのセルフBI
SQL on Hadoop
• BIスタイルのSQLをHadoop(HDFSなど)に対して実⾏
• HiveのようにSparkやMapReduceの処理に変換せず直接実⾏
⾼速性能
• アドホッククエリ⽤途
• レイテンシーを意識した設計(数秒〜数⼗秒で応答を返す)
同時並⾏性
• 複数ユーザーが同時にSQLを実⾏しても、⼗分な性能を発揮できる
互換性
• JDBC/ODBCドライバーにより、様々なBIツールと接続可能

Impalaを⽤いたKuduへのSQLアクセス

KuduへのAPIによるアクセス
各種プログラミング⾔語のバインディング
• C++
• Java
• Python
各種ミドルウェアとの統合
• MapReduce
• YARN
• Spark
• Flume

KuduとSparkとの連携
• DataFrameからテーブルの操作
• SparkSQLの使⽤
• Kuduに保存されているデータをSpark
上で容易に処理することが可能

構成例と事例

Kuduを⽤いた典型的なアーキテクチャ例
Spark
Streaming
ImpalaData
Sources
Applications
KuduKafka
〜メッセージキュー〜
多種多様のデータソースに対
応するため、直接データベー
スに⼊れるのではなく、⼀旦
受け⽌める層を設置。
〜データの前処理〜
Kuduは構造化データを格納す
るため、⾮構造化データから
の変換や、追加情報の付与な
どを必要に応じて⾏う。
〜SQLアクセス〜
SQLアクセスを⾏うことに
よって、BIツールをはじめ、
様々な分析アプリから容易に
接続可能
SQL w/ JDBC
NoSQL API

ウェブのログ
JD.comの事例
中国第2位のリテール系企業、ECサイト「JD.com」が有名
Kafka経由でリアルタイムにデータを取得しKuduへデータを収拾
• クリックログ
• アプリケーション及びブラウザーのトレース
1⽇に100億トランザクション以上、ピーク時毎秒1000万インサート
ブラウザの
トレース
Impala
SQLによる直
接アクセス
ウェブ
アプリケー
ション
SQLSQL
Kafka
Kudu

Xiaomiの事例
世界第4位のスマートフォンメーカー
• モバイルアプリとバックエンドサービスから、RPCの追跡イベントを取得
• サービスモニタリング＆トラブルシューティングツールとして利⽤
⾼い書き込みスループット
• 現時点で 50億レコード/⽇以上ありさらに増加中
データ
ソース
Impala 結果の取得
SQL
データの直接格納
Storm
Kudu
Kafka
バックプレッシャーの制御 / ETL
OLAPスキャン
サイドテーブルのルックアップ
結果の格納

Comcastの事例
Comcast
• 世界最⼤のケーブルテレビ会社
• テレビ視聴データのリアルタイム及びバッチ分析にKuduを利⽤
• データ増加は5億records/day以上
Real-time analytics using Kudu at petabyte scale
• https://conferences.oreilly.com/strata/strata-ca-
2017/public/schedule/detail/56113

その他の例）リアルタイムの機械学習アーキテクチャ
Spark
Streaming
Spark MLlib
Spark
Data
Sources
Applications
2) メッセージ配信 3) ストリーム処理 4) Kuduに格納
5) 機械学習ライブラリの適⽤
１) イベント発⽣
KuduKafka
Height
Weight
Height
Weight
1 2
Height
Weight
3
Height
Weight
4
L
M
S
XL
L
M
S
XS
Near
Custom
?
機械学習ライブラリの適⽤例 - クラスタリング
〜Note〜
機械学習を含む、Clouderaのデータサイ
エンス製品には、Cloudera Data Science
Workbench がある

Kuduのデータ構造

Kuduのデータモデル
• リレーショナルデータベースに似ている
• テーブル構造
• 各列は強いデータ型を持つ
• 主キーを持つ

カラムナー（列指向）ストレージ
• 物理構造として、列ごとにデータが分離している
{25059873,
22309487,
23059861,
23010982}
Tweet_id
{newsycbot,
RideImpala,
fastly,
llvmorg}
User_name
{1442865158,
1442828307,
1442865156,
1442865155}
Created_at
{Visual exp…,
Introducing ..,
Missing July…,
LLVM 3.7….}
text

カラムナーストレージ
{25059873,
22309487,
23059861,
23010982}
Tweet_id
{newsycbot,
RideImpala,
fastly,
llvmorg}
User_name
{1442865158,
1442828307,
1442865156,
1442865155}
Created_at
{Visual exp…,
Introducing ..,
Missing July…,
LLVM 3.7….}
text
この1列だけを読む
1GB 2GB 1GB 200GB
SELECT COUNT(*) FROM tweets WHERE user_name = ‘newsycbot’;
列ごとのエンコーディングと圧縮によって、IOの増加に対応できるようになった

列のデザイン
制約
• 主キー列は必須かつユニーク制約だが、他の列はNULLも可能
データ型
• Boolean
• 8/16/32/64 bit signed integer
• timestamp (64-bit microseconds since the Unix epoch)
• float/double (IEEE-754)
• UTF-8 encoded string（64KBまで）
• Binary (64KBまで)
データ型の重要性
• エンコーディングと圧縮による、IOと保存容量の効率化

列のエンコーディング
エンコーディング（符号化）
• データのbit表現をどうするか
列のデータ型がわからないと...
• 容量効率やIO効率が悪い
• 多くのNoSQLでは、Valueを単なるバイナリとしてしか扱っていない
Kudu ではデータ特性に合わせ効率よくデータを扱える
• Plain Encoding
• Bitshuffle Encoding
• Run Length Encoding(RLE)
• Dictionary Encoding
• Prefix Encoding

Kuduが対応しているエンコーディング⽅式
Plain Encoding
• データ型ごとの標準的な形式で保存（つまり何もしない）
Bitshuffle Encoding
• ビット列を並び替え、その後LZ4圧縮を⾏う
• 多くの反復値を持つ列、主キーでソートすると少量ずつ変化する値に有効
Run Length Encoding(RLE)
• いわゆるランレングス圧縮を⾏う
• 主キーでソートされた際、連続した反復値が多数⾒られる列に効果的
Dictionary Encoding
• 列の値からディクショナリを作成時、実際の列側にはそのインデックスが格納
• カーディナリティの低い列に有効
• ユニークな値が多くなって圧縮が効かなくなってきたら、Plainにフォールバック
Prefix Encoding
• 共通プレフィックスを持つ値、主キーの最初の列に有効

データ型のエンコーディング
• Kudu 1.5 / CDH 5.13 現在は以下のエンコーディング及びデフォルト設定
列のデータ型可能なエンコーディングデフォルト設定
int8, int16, int32 plan, bitshuffle, run length bitshuffle
int64, unixtime_micros plan, bitshuffle, run length bitshuffle
float, double plan, bit shuffle bitshuffle
bool plan, run length run length
string, binary plain, prefix, dictionary dictionary

エンコーディング例
key string bool
1 sato true
2 tanaka true
3 tanaka true
4 sato false
5 suzuki false
6 suzuki true
7 suzuki true
8 sato true
9 sato true
10 sato true
boolの列 - RLEの例stringの列 - dictionaryの例
dictionary
1:sato
2:suzuki
3:tanaka
string
1
3
3
1
2
2
2
1
1
1
bool
true x3
false x2
true x4
テーブル例

Kuduの列圧縮
• Kuduは列単位でデータの圧縮が可能
• LZ4、Snappy、zlib
• 圧縮は圧縮速度と圧縮サイズのバランスを考える
• 圧縮処理はCPUと時間を使うが、圧縮によってサイズが減ればIO量を減らす
ことができる
• ⼀般的に圧縮/展開速度と圧縮サイズの⾯でLZ4が最もバランスが良く
• 圧縮率だけみるならzlibが最も⾼い
• 通常の列はデフォルトでは無圧縮
• Bitshuffleエンコーディングは例外で、内部で⾃動的にLZ4で圧縮が⾏われる
ので、その上に追加で圧縮を掛ける必要はない
〜Note〜
つまり圧縮とは、IOのボトルネックをCPU
側に寄せるものである

主キーのデザイン
• Kuduの表は、現在は主キーが必須
• 主キーは⼀意制約を持つ
• null, boolean, float/double は許可されない
• 現時点ではシーケンス機能（⾃動でインクリメントするinteger）を持たない
ため、アプリケーションは挿⼊時に常に主キーを提供する必要がある
• 主キー列の値は更新不可
• 通常のRDBMSでも同様

Kuduの物理構成
• KuduはMasterとTabletServer（ワーカー）から構成される
TabletServer
Master

タブレット
• Kuduでテーブルを作成した際、1つのテーブルに格納されるデータは、タブ
レットに分割されて、各タブレットサーバー上に保存される
Tablet
Kudu上のテーブル
TabletServer

タブレットの複製
• ある1つのタブレットは、さらに複数のタブレット（デフォルト3）に複製さ
れ、これもまた異なるタブレットサーバーに保持される
• つまり実際のタブレット数は、3倍の数になる
• タブレットではRaftコンセンサスアルゴリズムを使ってリーダーが選出される
• タブレットへのデータの書き込み処理はリーダーでのみ受け付けられる
• タブレットからのデータの読み込みは、どのレプリカからでも可能
タブレット
リーダー
タブレット
フォロワー
Tablet
TabletServer
タブレット
フォロワー
〜Note〜
つまり実際のタブレット数は
3倍の数になる

CDHとKudu

CDH: ClouderaのHadoopディストリビューション
• Cloudera's Distribution including Apache Hadoop
• Hadoopディストリビューション
• Hadoopエコシステムを⼀般利⽤者が利⽤できる形にまとめあげたもの
• Cloudera が提供する CDH
• 他で例えると・・・
• Linuxディストリビューション
• Red Hat が提供する Red Hat Enterprise Linux

CDH 5.10 より Kudu をサポート！
• 2016-09-19 Apache Kudu 1.0.0 リリース
• 2017-01-31 CDH 5.10 で Apache Kudu 1.2 が GA に

エンタープライズとKudu
• Apache Kudu 1.3.0
• Kerberos認証に対応
• 通信路の暗号化に対応

CDHへKuduが合流
• CDH 5.13 より CDH parcel に Kudu が取り込まれる
• Cloudera の製品は Parcel と呼ばれるパッケージ形式で提供
• CDH 5 の Parcel（これにほどが⼊っているが...）
• Kafka の Parcel
• Spark 2系の Parcel
• Kudu の Parcel
• Kudu 1.4 まではCDHとは別のParcelで提供されていた
〜Note〜
Parcelでインストールすると、
アップグレードなどもすべて
Cloudera Managerから⼀元管
理できる

最新のマニュアル
• CDH 5.13 より、KuduはCDHに含まれるようになった
• マニュアルもCDHに含まれるので古いものを参照しないよう注意
• 旧マニュアルは Kudu 1.4までのもの
• Kudu 1.5/CDH 5.13 以降のマニュアルはこちら
• https://www.cloudera.com/documentation/enterprise/latest/topics/kudu.ht
ml
←古い

Kuduのインストール - サービスの追加
• Cloudera Managerより、数クリックでKuduのインストールが完了
• ⼊⼒する情報
• Kudu Master（マスターノード）とTabletServer（ワーカー）の配置
• WAL DirectoryとData Directoryの指定

Kuduサービスのホーム画⾯
• Cloudera ManagerよりKuduのメトリクス監視ができる

Impala連携の設定
• ImpalaからKuduにアクセスするには、Impala側に設定が必要
• Impala設定画⾯の「Kuduサービス」にてKudu選択するだけ

Hue（Impala経由）からのデータの投⼊
• Impalaと連携したKuduは、JDBC経由などでSQLにて処理を
• もちろんHue経由でImpalaからKuduテーブルの作成や各種クエリを投げるこ
とができる

Kuduのスキーマ設計とパーティション戦略

Kuduにおけるタブレットとパーティション
• Kuduはパーティションを持ち、データを分割することができる
• レンジパーティション
• ハッシュパーティション
• マルチレベルパーティション
• レンジとハッシュの組合せ
• 複数のハッシュの組合せ
• Kuduのパーティションは、タブレットと対応する
Tablet
Partition
パーティション
に分割

レンジパーティション
• レンジパーティションでは、完全に順序付けされたレンジパーティション
キーを使って、⾏を分散させる
• このパーティションキーは、主キーのサブセットである必要がある
• ハッシュパーティションを併⽤しない場合、各レンジパーティションは、完
全に1つのタブレットと対応する
• つまりレンジの個数だけ、タブレットが存在する

ハッシュパーティション
• ハッシュ値によって、値を複数のバケットの1つに対応させる
• ハッシュパーティション単⼀であれば、各バケットはそれぞれ1つのタブレッ
トに⼀致する
• バケットの数は、テーブル作成時に設定
• 通常は主キーをハッシュ⽤の列として使うが、主キー列のサブセットを使う
こともできる
• テーブルに順序アクセスをする必要がない場合は効果的
• 特に書き込みにおいて、ホットスポットや、タブレットサイズの不均衡を緩
和することに役⽴つ

マルチレベルパーティション
• マルチレベルパーティションでは、0個以上のハッシュパーティションと、レ
ンジパーティションを組み合わせることが可能
• 制約として、複数レベルのハッシュパーティションが、同じ列をハッシュし
てはならない
• マルチレベルパーティションでは、合計タブレット数は、各レベルのパー
ティション数の積になる
〜Note〜
多⽤すると、タブレット数が膨⼤になる
のでよく考えて設計をする

適切なパーティションデザイン
• タブレット数を意識
• タブレットはパーティションと対応、複数の種類のパーションを利⽤した
場合、その積になる
• スキャンは1タブレットごとに1つのスキャナー
• 基本的には、スキャンの並列度を考えると1ノードあたりのタブレットは多い
ほうが良いが、CPUコア数を超過すべきではない
• ⼤規模テーブルのタブレット数の⽬安
• CPUのコア数から並列度を考慮
• ⼩規模テーブルのタブレット数の⽬安
• 1タブレットに少なくとも1GB程度のデータが⼊るように調整
タブレット数＝ ×ハッシュバ
ケット1の数
...×ハッシュバ
ケット2の数
レンジの数

サイジングの⽬安
推奨される最⼤サイズ
• 最⼤TabletServer（つまりワーカーノード）数は100
• TabletServerごとの最⼤タブレット数は、複製後2000
• TabletServerごとのデータサイズは、圧縮後で8TB
• 最新のマニュアルを確認
⼤量のパーティションと⼤量のスレッド
• 現バージョンのKuduでは、1パーティション毎に最低でも2つの内部スレッ
ドが⽣成される
• 上記推奨値を越える様なパーティションを⽣成した場合、内部的にスレッ
ドが⼤量⽣成され、動作に影響を与える可能性がある
• 特にノード数が少ない場合に注意
• 効率よく動作するような改良を進めいている（KUDU-1913など)
〜Note〜
あくまで安全側に倒した値。適切なHW構
成やチューニングを⾏えば、これ以上で
あっても動作する。

パーティションのプルーニング
• Kuduは、スキャンの述語（いわゆる WHRER句）によって該当パーティショ
ンを読む必要が無いと判断した時、⾃動的にそのパーティションの読み取り
をプルーニング（スキップ）する
• ハッシュパーティションのプルーニング
• 全てのハッシュ列に等価（=）の述語を含める必要がある
• レンジパーティションのプルーニング
• レンジパーティション列に、等価（=）または範囲（<,>,≦,≧,etc.）を含む
必要がある

パーティション戦略
• ハッシュパーティションは書き込みスループットの最⼤化によい
• レンジパーティションはタブレットの肥⼤化を防ぐことができる
• 両者を組合せたマルチレベルパーティションでは、正しく設計できれば、両
者のメリットを享受することができる
戦略書き込み読み込みタブレットの肥⼤化
range(time) ❌全ての書き込みは最新の
パーティションに⾏く
✅時間を指定して読み
込む場合、時間の境界
を超えた不要な読み取
りは発⽣しない
✅将来のレンジ⽤に、
新たなタブレットが追
加される
hash(host, metric) ✅書き込みはタブレット全
体に均等に⾏く
✅特定のhostやmetricを
スキャンする際、不要
な読み込みは発⽣しな
い
❌各タブレットは肥⼤
化する

パーティション vs インデックス
パーティション
• データをどのように複数パーティションに分散させるか
• Kudu： tablet
• HBase：region
• Cassandra：vnode
インデックス
• 1パーティション内のデータをどのようにソートするか
• 時系列データでは、⼀般に (series, time) でインデックス化する → なぜ？
(us-east.appserver01.loadavg, 2016-05-09T15:14:00Z)
(us-west.dbserver03.rss, 2016-05-09T15:14:30Z)
(2016-05-09T15:14:00Z, us-east.appserver01.loadavg)
(2016-05-09T15:14:30Z, us-west.dbserver03.rss)
(series, time) (time, series)

主キーのインデックスによるプルーニング
• Kuduの主キーは、クラスターインデックスになっている
• 1つのタブレット内にある全ての⾏は、主キーのソート順に保持される
• スキャンの述語に、等価（=）、範囲（<,>,≦,≧,etc.）などがある場合、合
致しないものはIOをスキップする
• 主キーによるプルーニングは、主キーのプレフィックスにのみ有効
• 複合主キーPK(A,B,C)があり、where C=‘...’ という条件をかけた場合、プレ
フィックスではないのでプルーニングは起こらないので注意
• PK(series, time)はプルーニングされるが
• PK(time, series)はプルーニングがされない
(series, time) (time, series)
SELECT * WHERE series = ‘us-east.appserver01.loadavg’;

レンジパーティションのメンテナンス
• 実⾏時に、レンジパーティションを動的に追加及び削除可能
• この操作は他のパーティションの可⽤性に影響を与えない
• パーティションの削除は、内部データも削除される
• ⼀旦削除されたパーティションへの挿⼊は失敗となる
• 追加に関しては、既存パーティションとレンジが重複してはいけない
• alter table で操作可能

Impalaからの実際のテーブル構築例
ハッシュパーティションの例コンポジットパーティションの例

Kuduと書き込みの⼀貫性
• Kuduのトランザクション設計は、2012年に出された、SpannerやCalvinの論⽂
を参考にして開発された
• 将来的には複数⾏や複数タブレットにまたがったACIDトランザクション対応
に向けて進めている、現時点では⾏単位のACIDのみ対応
• まだコーナーケースに対応しきれてない
• 実験的に幾つかの機能は提供している

Kuduと読み取りの⼀貫性
• Kuduは内部でMVCC（Multi-version Concurrency Control）を使っており、読
み込み時には、すでにコミットが完了したデータだけをみることができる
• これは、リードつまり分析⽬的等でスキャンをする際、スキャン開始時点の
データのスナップショット（断⾯）に対して読み取りを⾏う
• WALとは別に、内部的にREDOとUNDOを⽤いている
• よって、それ以降に裏側でデータの挿⼊や更新が⼊っても、読み取り時は⼀
貫性を保ったまま分析処理を⾏うことができる
〜Note〜
過去の時間を指定することで、その時点
の静⽌断⾯をスキャンすることができる。
Kuduはこれをタイムトラベルリードと呼
んでいる。

読み取り時のモード
⼤きく2種類
READ_LATEST（デフォルト）
• タブレット内の最新のバージョンを読む
• 単純に各タブレット上での最新の情報を⾒るだけなので、特定の静⽌断⾯
を⾒ているわけではない
READ_AT_SNAPSHOT
• 特定のタイムスタンプのバージョンを含んだ、MVCCのスナップショットを
取得し、それをスキャンする
• 全ての書き込みにはタイムスタンプがタグ付けされているため、ある時間
断⾯のデータにアクセスができる（Repeatable Read）

書き込みと読み込みの流れ
〜Note〜
WALはすべての書き
込み操作が記録され、
ディスクに保存され
るため、ディスクが
遅いとここがボトル
ネックとなりやすい。

Blog:Kuduにおけるリードとライトの流れ
• Cloudera Engineering Blog - Apache Kudu Read & Write Paths
• https://blog.cloudera.com/blog/2017/04/apache-kudu-read-write-paths/
• ⽇本語訳
• https://blog.cloudera.co.jp/11c3a749a81b

Kuduのステータス画⾯
• Kuduが持つ各種ステータス画⾯
• Masterは http://<マスターのIP>:8051
• TabletServerは各サーバーごとに http://<タブレットサーバーのIP>:8050
• Cloudera Managerはこれらの情報を集約して表⽰してるが...
• Kudu側の画⾯でなければ得られない情報もある（細かいタブレットの配置な
ど）

Kuduのステータス画⾯
• タブレットごとの各種情報など
〜Note〜
パーティションの実配置をみるのには、
この画⾯からみるのがよい。

Kuduのトレーシング機能
• サーバー内部のトレーシング機能
• トレースの記録を開始してから停⽌するまでの詳細なトレースを取得

Kudu環境の構築

インストール要件（Kudu 1.5 /CDH 5.13現在）
Kudu 1.5よりCDH5.13に統合されたため、今後はCDH5.13のドキュメントを参照
• まだ過渡期のためKuduについては注記等があるので注意
ハードウェア構成
• CPU: SSSE3 及び SSE4.2
• マスターノード（Master）: 1台（冗⻑性構成なし）, 3台, 5台
• ワーカーノード（TabletServer）: 任意台数
OS（⼀部抜粋）
• RHEL/CentOS/Oracle Linux 6.4, 6.5, 6.6, 6.7, 6.8, 6.9, 7.1, 7.2, 7.3, 7.4
• Ubuntu 14.04, 16.04
• Debian 8.2, 8.4
• SLES 12 SP1
ファイルシステム
• xfs, ext4
NTPによる時刻同期
• ずれていると起動しない（10秒ずれると強制終了）
参考ドキュメント
https://www.cloudera.com/documentation/enterprise/release-
notes/topics/rn_consolidated_pcm.html#pcm_kudu
https://www.cloudera.com/documentation/enterprise/release-
notes/topics/rn_consolidated_pcm.html#concept_mh3_sht_kbb

推奨ハードウェア構成（Kudu 1.5 /CDH 5.13現在）
ハードウェア推奨構成
• 基本的には⼀般的にHadoopが要求するものと同様
• ワークロードに応じて必要な構成は⼤きく変わるため、実際のサイジングには、POCなど
の検証を⾏い検討をすることを強く推奨
• 実際にはKudu⾃⾝以外にも、ImpalaやHDFSやSparkなどが利⽤する分を考慮
CPU
• ワークロードに応じて4〜16コアなど
• IOの並列度とコア数を意識
メモリ
• KuduのMasterは、あまりメモリーを使⽤せず、多くても1GB程度
• KuduのTabletServerは、ワークロード次第だが、10GB〜程度から始めて検証するとよい
• 上記にプラスして相乗りするImpalaやHDFS、Spark等が利⽤する分を⾜す
• 特にImpala利⽤時はImpalaが⼤量にメモリを必要とする点に注意
ディスク
• 可能であればSSDの利⽤を強く推奨
• 詳細は後述のスライド
ネットワーク
• 10Gbps Ethernetを推奨、1Gbpsの線を使う場合は4Gbps(1Gbps x4)など複数本束ねる
• 必要に応じてbondingなどの冗⻑構成を取る
• 複数のネットワークを使い分けるようなマルチホームネットワークはサポート対象外

OK
サーバーとネットワークトポロジー
• マルチホームネットワークはサポート対象外
• サーバーが複数のネットワークに所属し、⽤途ごとに使うネットワークを
分けるような構成のこと
例1) サポートされるネットワーク構成
例2) サポートされないマルチホーム構成NG
...
...
外部へ
外部へ
参考ドキュメント：https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#cdh_cm_network_security
例えばノード間通信だけをこちらのネットワークを通したいなど

ロールの配置例
DNIDTS DNIDTS
ZK
NN
KM ZK
JN
KMJN
NN
ZKKM JN
ISS ICSHMS
CM
Kudu Master
TabletServer
Impala CatalogServer
StateStore
ImpalaDaemon
Hive HiveMetaStore
HDFS NameNode
JournalNode
DataNode
ZooKeeper ZooKeeper
その他 Cloudera Manager
任意のRDB
ワーカー1
マスター1 マスター2 マスター3
ワーカーN
NN
JN
DN
ISS
ICS
ID
......
ZK
CM
KM
TS
RDB
Cloudera Manager⽤
サーバー
HMS
RDB
RDB
アイコンの意味

HDFSは必要か？
Kuduをメインで使う場合にもHDFSは必要なので注意
運⽤⾯（必須）
• Kudu以外のHadoopエコシステムはHDFSがあることを前提としていることが多い
• 実際のデータ保存だけでなく、運⽤やジョブの実⾏に際して、ノード間でのデー
タ共有やログの保存なのど、様々な場⾯で使われる
⾮構造データの保存（任意）
• Kuduは構造化データのみを扱うため、Kuduにinsertする前の⽣データなどを、⾮構
造化データとして保存する場合などには活躍する
DRサイトの構築（任意）
• 現時点で、KuduはCloudera ManagerのBDRに⾮対応であり、Kudu⾃⾝もHDFSの
dstcpの様なクラスタ間レプリケーション機能を持っていない
• Kuduのバックアップやクラスタ間レプリケーションを⾏う場合、HDFSにParquetと
して書き出してBDRで別クラスタに転送する⽅法が取られる

推奨ディスク構成 - OS領域
⽤途
• ルートファイルシステム等のOS領域
• CDHを含む各種ソフトウェア
• ログの保存
考慮点
• ルートファイルシステムを持つディスクが故障すると、OS全体が停⽌する恐れがあることを念頭に置く
• マスターノード
• 複数ノードで冗⻑構成が取ってはいるが、その重要度の⾼さから、RAID1などで可⽤性をもたせること
を推奨
• ワーカーノード
• 設計上ノードがダウンしても問題ないため、ルートファイルシステムを持つディスクを冗⻑化する必要
は本来はない
• しかしワーカーがダウンした場合、該当ノードが持つデータの再複製と転送が⾏われるため、それによ
る負荷を無視できない場合、要件次第ではルートファイルシステムを持つディスクを冗⻑構成にするこ
とも検討
構成例
• ルートファイルシステム⽤に、1つのディスクまたはRAID1で冗⻑化された2つのディスクを使い、OS⾃⾝
やCDHを含む各種ソフトウェア⽤のディレクトリは、このディスクを使⽤
• 必要に応じて、CDHを含む各種ソフトウェア等が出⼒する「ログ」⽤のディレクトリは、専⽤ディスクを
⽤意する
RAID1
/
OS⽤

推奨ディスク構成 - Kudu領域
⽤途
• WALの保存：更新時のすべての操作がここに保存される
• Dataの保存：ディスクにフラッシュされたデータが保存される
考慮点
• KuduはHDDも使えるが、SSDにより最適化されているため、SSDの利⽤を推奨
• 特にWALだけでも、SSDにすることを強く推奨
• マスターノード（Kudu Master）
• Masterには管理⽤のTabletが1つずつあるだけなので、データ量負荷量共にそこま
で⼤きくならない
• マスターノードのKuduのWAL及びData⽤ディスクは KUDU-1620 のため、現時点
では、RAID1などで冗⻑化されたディスクに配置することを推奨
• ワーカーノード（Kudu TabletServer）
• WAL⽤ディスクの負荷が⾮常に⼤きいため、WAL専⽤ディスクをSSDで⽤意する
• Data⽤ディスクもSSD推奨だが性能要件が厳しくなければHDD複数のディスクを
JBOD構成で⽤意する
構成例
• MasterにはSSDでRAID1を組みそこにWALとDataを保存
• TabletServerにはWAL⽤にSSD1本と、Data⽤にSSDかHDDで複数本 SSD SSD SSD SSD
RAID1
wal, data
SSD SSD
...
wal data1 data2 dataN
TabletServer⽤
Master⽤

構成例 - マスターノード
各マスターノードのディスク構成例
OS
• OS領域⽤ - HDD x2 (RAID1)
Kudu
• WAL+Data⽤ - SSD/HDD x1or2
HDFS
• NameNode⽤ - HDD x2 (RAID1推奨)
• JournalNode⽤ - HDD x1
• HDFSは様々な⽤途で利⽤されるためHDFS
の設置は必要
• ただし主⽤途でなくアクセス負荷が低いこ
とが予想されるなら、占有ディスクでなく
Kuduのディスクと共⽤も可
ZooKeeper
• Zookeeper⽤ - HDD/SSD x1
SSD SSD
Kudu
WAL+Data
OS
(RAID1)
ZooKeeper
〜Note〜
Kudu⾃⾝はZooKeeperを使わない
が、HMSやHDFSその他のサービス
で使⽤される為、多くのケースで
は必要とされる。
(RAID1)
HDFS
JN
HDFS
NN
(RAID1)

構成例 - ワーカーノード
各ワーカーノードのディスク構成例
OS
• OS領域⽤ - HDD x1or2(RAID1も可)
Kudu
• WAL⽤ - SSD x1
• Data⽤ - SSD/HDD x複数本
• SSDに最適化されているがHDDも可
• TabletServerごとに保存可能な合計デー
タサイズは、Kudu 1.5 / CDH 5.13 現在
8TBまでが⽬安
HDFS
• DataNode⽤ - HDD x複数本
• KuduとHDFSはアクセス特性が異なる
ため、ディスクは分けた⽅がよいが、
⽤途次第ではではKuduとディスクの共
有もあり
SSD SSD SSD SSD...
Kudu
WAL
OS Kudu Data HDFS DN
...

ディスクのJBOD構成について
• HDFSのDataNode⽤データディレクトリ、KuduのTabletServer⽤データディレクトリ
は、複数本のディスクをJBOD（Just Bunch Of Disks）で構成する
• JBODとは、RAIDなどを設定せず各ディスクをそのままOSに認識させること
• JBODで性能が出るような実装がされている
• 例えば4本のディスクがある場合
• 例1）それぞれをOS上で個別のブロックデバイス（/dev/sdb, /dev/sdc, /dev/sdd,
/dev/sdf など) として認識できるようにし、それらをHDFSやKuduに使わせる
• 例2）ハードウェアRAIDが既に組み込まれておりかつJBODモードが設定上できな
い場合などは、4本それぞれを個別に「1ディスクだけのRAID0構成」として、OS
上から4本個別に認識できるようにしておくことはOK
• 例3）RAID 0, 5, 6 などで4本を1つにストライピングする構成は⾮推奨
RAID0
RAID 0/5/60 0 0 0
例1) 通常のJBOD構成例2) RAID0でのJBOD構成例3) ストライピングNGOK OK

クラウドに構築する場合は？
• クラウド環境に構築する場合はReference Architectureの資料を参考
• リファレンスアーキテクチャの公開ページ
• https://www.cloudera.com/documentation/other/reference-
architecture.html
• AWS
• http://www.cloudera.com/documentation/other/reference-
architecture/PDF/cloudera_ref_arch_aws.pdf
• Azure
architecture/PDF/cloudera_ref_arch_azure.pdf
• GCP
architecture/PDF/cloudera_ref_arch_gcp.pdf

Cloudera Directorによるクラウド環境への⾃動構築
• Hadoopクラスターをクラウド上でデプロイ＆管理するためのツール
• ベストプラクティスを再利⽤可能な構成ファイルで提供
• クラスターのライフサイクル（grow & shrink）を管理
• Cloudera Manager との管理の同期
クラウド
（AWS/Azure/GCP）Cloudera Director Client
インスタンス
インスタンス
インスタンス
Cloudera
Director
Server
インスタンス
インスタンス
インスタンス
起動

Cloudera Directorを⼊れてクラウドにCDHクラスタを作ろう
• 主にデモ環境や開発環境を作る視点で、Cloudera Directorをシンプルに使って、
クラスターを構築する例
• https://blog.cloudera.co.jp/getting-started-cloudera-director-35405d421084
• Cloudera Directorの構成ファイル
• https://github.com/takabow/impala-demo-env

おわりに

Kuduまとめ
Apache Kuduとは？
• ⼤規模データ（ペタバイト、1000億⾏以上）を扱えるデータベース
• SQLを使って構造化データを分析
• 更新(INSERT/UPDATE/DELETE)を⾏いつつ、⼤規模スキャン(SELECT)可能
• HTAP: OLTPとOLAPの融合
Kuduで分析システムをつくるには？
• 複数ノードで分散並列処理
• スキーマ設計パーティション戦略が重要
• 各ノードのディスクは複数本⽤意、SSDの利⽤を推奨
• あとはリレーショナルDBのようにSQLアクセスで分析！

Thank you
takahiko at cloudera.com

Apache Kuduを使った分析システムの裏側

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Apache Kuduを使った分析システムの裏側

Similar to Apache Kuduを使った分析システムの裏側 (20)

More from Cloudera Japan

More from Cloudera Japan (20)

Apache Kuduを使った分析システムの裏側