Impala + Kudu を用いたデータウェアハウス構築の勘所（仮）

Impala + Kuduを用いた
データウェアハウス構築の勘所（仮）
2018年11月06日 – CWT 2018
Takahiko Sato / Sales Engineer at Cloudera

2 © Cloudera, Inc. All rights reserved.
佐藤貴彦 (さとうたかひこ) / takahiko@cloudera.com
セールスエンジニア
• お客様がCloudera製品及び関連技術をを活用できるよう、一緒に議論するのがメインの仕事
これまでの経験
• Internet & Network（大学）
• RDBMS（1社目）
• NoSQL（2社目）
• Hadoopエコシステム（3社目） ←Now!
自己紹介

• Apache Kuduは、HDFSやHBaseに続き、Hadoopエコシステムにおけるスト
レージ層として登場しました。
• 一方、同時実効性の高いワークロードをサポートするImpalaとの組み合わせが
注目されています。
• 本セッションでは、Impala + Kudu の組み合わせによるDWH構築の勘所や
チューニングポイントを徹底的に解説します。
今回お話する概要

© Cloudera, Inc. All rights reserved.
Clouderaが提供するデータウェアハウスとは？

Cloudera Data Warehouse - オンプレ/クラウドで利用可能な分析基盤
SQL開発者
分析ワークベンチ
アナリスト
任意のBIツール
マイグレーション
とジョブ最適化
Workload XM
監査と
データガバナンス
Navigator
分析向けSQLエンジン
Impala
クエリエンジン
&
処理エンジン
オブジェクトストレージ
S3 | ADLS
ストレージ
Cloudera Data Warehouse
ETL向けSQLエンジン
Hive on Spark
ローカルストレージ
HDFS | Kudu

処理エンジン各種製品との組み合わせ
(Impala)
ストレージ
(Kudu)
ストレージ
(S3)
ストレージ
(HDFS)
処理エンジン
(Impala)
処理エンジン
(Spark)
処理エンジン
ストレージ
エンジン
(Hive)
処理エンジン
(MapReduce)
ストレージ
(ADLS)
（SQL）
処理エンジン
ストレージエンジン
カタログ
モノリシックな
分析データベース
(一般的なリレーショナルDB含む)
エコシステムで構成された
分析データベース
カタログ
（HMS）

Hadoopのためのスケーラブルな分散ファイルシステム
• 一般的なファイルシステムと同様どのようなデータもファイルとして保存可能
• 非構造化データ：生ログ（txt)、画像や動画などのバイナリ、etc...
• 構造化データ：csv, avro, parquet, etc...
• ファイルはブロックに分割されて各ノードに分散配置
• 大量データをフルスキャンをすることに特化している → ETL処理
• IO効率が良くなるよう、大きなファイルサイズを想定（数百MB〜GB）
• 高スループットを重要視している
• データのランダムな更新ができない
• ファイルの末尾に追加はできる
ストレージ：HDFSはあらゆるデータを扱える分散ファイルシステム
HDFS
１ 2 3 4
複数ノードで1つのファイルシステム

分析向けのスケーラブルなストレージエンジン
• 一般的なリレーショナルデータベースのように、表形式でデータを格納
• 構造化されたテーブルでデータを表現
• 列ごとに厳密にデータ型を定義
• 物理的にはカラムナー構造になっており、列単位の集計に強い
• テーブルの個々の行レベルのアクセス、特定列の大量スキャンのどちらも強い
• データのランダムな更新と、データの大量スキャンを同時に行える
• クラスターで秒間数百万のリード/ライト
• 1ノードあたり数GB/秒のリードスループット
ストレージ：Kuduは構造化データ向けの更新可能ストレージ
複数ノードで1つのデータベース
Kudu

• Hive on Spark は SQLをSparkの処理に変換する
• Sparkによるプログラミングをすることなく、SQLを記述するだけでETL的な
処理が可能
クエリエンジン：Hive on Sparkを用いたSQLによるETL処理
(Impala)
ストレージ
(Kudu)
ストレージ
(S3)
ストレージ
(HDFS)
処理エンジン
(Impala)
処理エンジン
(Spark)
(Hive)
処理エンジン
(MapReduce)
ストレージ
(ADLS)
カタログ
（HMS）

クエリエンジン：Impalaを用いた分析SQL
(Impala)
ストレージ
(Kudu)
ストレージ
(S3)
ストレージ
(HDFS)
処理エンジン
(Impala)
処理エンジン
(Spark)
(Hive)
処理エンジン
(MapReduce)
ストレージ
(ADLS)
カタログ
（HMS）
• Kudu自体はSQLエンジンを持たず、他の製品に頼っている
• 特にImpalaとの親和性が高い（更新からスキャンまでなんでもSQLででき
る）

処理エンジン：SparkからKuduへのアクセス
(Impala)
ストレージ
(Kudu)
ストレージ
(S3)
ストレージ
(HDFS)
処理エンジン
(Impala)
処理エンジン
(Spark)
(Hive)
処理エンジン
(MapReduce)
ストレージ
(ADLS)
カタログ
（HMS）
• Sparkからであれば、SQL経由のク
エリと異なり、KuduのAPIを直接使
うことができる
• SparkSQLとしての実行も可能

Cloudera Data Warehouse はどこへ向かっているのか？

データウェアハウスと言われて想像するもの
SQL? DWH？
BI?
OLAP?RDBMS?
データウェアハウス
DataMart?
Analytic DB?

• データウェアハウスとは、ビル・インモン(Bill Inmom)氏が提唱した概念
• 「基本データ / 業務系データ」から「派生データ / 意思決定(DSS)データ」へ
• 当時（90年代〜）は業務データベースからデータを抽出し、分析データベースへ
マーケティング
営業
ERP
SCM
業務系データ
ETL
ETL
データマート
ETL
ETL
更新
更新

業務データベースから分析データベース
• 業務DBは企業内で生成された「内部データ」を「構造化データ」として保持
• しかし分析DBであるDWHでは、内部データだけでなく「外部データ」も組み
合わせて使うことがある
• 外部データは「非構造化データ」となる場合も多い
業務DB
分析DB
（DWH）
ETL更新
外部データ
内部データ
非構造化
データ
ETL

データウェアハウスにおけるワークロード
• 業務DBは、OLTP(online transaction processing)系のワークロード
• 業務処理、更新系（挿入、更新、削除）、1行単位のスキャン
• 分析DBは、OLAP(online analytical processing)系のワークロード
• 分析処理、参照系、フルスキャン
業務DB
分析DB
（DWH）
ETL ETL
データマート
データの更新頻度
更新系参照系
OLTP系のワークロード OLAP系のワークロード

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

スケーラビリティの高いHadoopエコシステム
• スケールアウトでペタバイト(PB)級のデータも処理可能
HDFSは非構造化データもそのまま扱える
HDFSは大規模スキャンが得意なので、OLAP系のアクセスは得意
• Impala/Hive経由でSQLによるスキャンもできる
• しかしHDFSは更新（ランダムライト）は得意ではないため、OLTP系はHBase併用
しかしHBaseからの結局データ変換が必要ですぐさま分析することができない
Hadoopエコシステムを用いたデータウェアハウス
put / delete OLTPの世界 OLAPの世界 BIツールselect
HBase ImpalaHadoopの世界
data ingestion
HDFS
ETL

HTAP(Hybrid Transactional/Analytic Processing)系のワークロード
• OLTP系ワークロードと、OLAP系ワークロードを1つのDBでこなせる
• OLTPのようにデータを受け続け、OLAPの様に分析をし続ける、そんなハイブ
リッド型のアーキテクチャに対応
• データウェアハウスやデータマートを更新する時間を待つ必要が無い
• もちろん必要に応じて個々のマートを作るといった処理も可能
Hadoopエコシステムを用いた次世代データウェアハウス
insert/update/delete
HTAPの世界（DWH） BIツール
select
Kudu

データソース
データウェアハウスシステムとしての構成例
各種非構造化データ
(HDFS)
分析SQL
（Impala）
加工処理等
(Spark Streaming)
データ取得
(Flume)
ETL・バッチ
SQL
（Hive/Spark）
業務DB・分析DB
(Kudu)
IoTセンサー
データソース
データソース
サーバー
ログ
データ取得
(Flume)
BIツール
BIツール
BIツール
アプリ
ETLツール
MQTT
BrokerIoTセンサー
データ取得アプリ
アプリ
BIツール
業務DB・分析DB
クエリ/処理エンジン
業務DB・分析DB
メッセージ
キュー
(Kafka)
加工処理等
(アプリ)

データソース
データウェアハウスシステムとしての構成例
各種非構造化データ
(HDFS)
分析SQL
（Impala）
加工処理等
(Spark Streaming)
データ取得
(Flume)
ETL・バッチ
SQL
（Hive/Spark）
業務DB・分析DB
(Kudu)
IoTセンサー
データソース
データソース
サーバー
ログ
データ取得
(Flume)
BIツール
BIツール
BIツール
アプリ
ETLツール
MQTT
BrokerIoTセンサー
データ取得アプリ
アプリ
BIツール
業務DB・分析DB
クエリ/処理エンジン
業務DB・分析DB
メッセージ
キュー
(Kafka)
加工処理等
(アプリ)
今日の対象はこの範囲

Impala + Kuduを用いたデータウェアハウス構築の勘所

勘所1
まずはマニュアルの最低要件を確認

• Impala
• Kudu
マニュアルの最小要件はあくまでも「最小」要件
https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_hardware_requirements.html
〜Note〜
ここで確認するのは、それぞ
れ最低でもこのぐらいのリ
ソースを必要としているんだ
という感覚。
〜Note〜
Impala はメモリを多めに要求。
Kuduは、マスターはリソース
をあまり必要としない。

勘所2
まず設定変更すべきはメモリ上限

• デフォルトのメモリ上限は小さめになっているので、必要な量まであげる
• Impalaの mem_limit の必要量は、SQLの種類（JOINが多いかなど）次第
• Kuduの memory_limit_hard_bytes は、特に更新（INSERT/UPDATE)が多い環
境では、多めに設定すること
メモリ設定をデフォルトから変更
〜Note〜
Kuduはメモリが足りず更新を受け付
けられない場合、クライアントに
バックプレッシャーを返す

勘所3
机上のチューニングではなく
実際に実検証にて確認しよう

実検証による基礎値の取得
〜Note〜
クラウド環境による簡易検証など、
基礎値を取得することによって、サ
イジングの精度をあげ、またその先
のチューニングを容易にする。
実検証をし各種メトリクスを取得し、設計やチューニングの基礎値とする

勘所4
Kudu単体ではなくHDFSも使おう

非構造化データを扱うため
• KuduはRDBと同様にテーブル定義を厳密に行う
• 外部データや非構造化データを扱うためにHDFSが役立つ
データのexport/importなどを行うため
• KuduテーブルとHDFS上のparquetテーブルは、Impalaから透過的に扱える
• 実際にはHDFS DN上のデータからKudu TS上のデータへコピー
• 初期ロード、バルクロードが高速
• SELECT INSERT や CTAS で行う（後ほど解説）
なぜHDFSもあったほうがよいのか？
分析DB
（DWH）
外部データ
非構造化
データ
HDFS
Kudu
Impala

Kudu
• WAL用 - SSD x1
• Data用 - SSD/HDD x複数本
• SSDに最適化されているがHDDも可
• TabletServerごとに保存可能な合計データ
サイズは、Kudu 1.7 / CDH 5.15 では 8TB
までが目安
HDFS
• DataNode用 - HDD x複数本
• KuduとHDFSはアクセス特性が異なるため、
理想としてはディスクは分けた方がよいが、
用途次第ではではKuduとディスクの共有
もあり
Kudu及びHDFSの物理構成
KM ZK
マスターの物理構成例
〜Note〜
ディスク構成はあくまで一例、理想を言えばサービスや
ロールごとに独立させるべきだが、小規模の場合同居させ
ても問題ない（要相談）
OS
(RAID1)
NN JN
Kudu WAL
Kudu Data
HDFS NN
(RAID1)
JN ZK
TS DN
ワーカーの物理構成例
OS Kudu
WAL
Kudu Data
HDFS DN
(JBOD)
...

勘所5
ディスクの本数は多めに

ディスクの本数はIOの並列度を稼ぐ上で重要
• 並列度 = ディスク本数 x ノード数
何本つけるか？
• ディスクの本数は「並列度」と「ストレージ容量」の両方に影響
• Kuduは1ノードあたりの最大容量が 8TB でHDFSに比べると小さめ
例1) 500GB SSD x16本
例2) 1TB HDD x8本
ディスクの本数がDWHの性能を左右する
〜Note〜
あくまで例なので、OS分やWAL用は別途専用ディス
クを与えること。HDFSとはワークロード次第では共
用もあり。また8TBは推奨値にすぎないので、これを
超える場合もテストをした上で検討の余地あり
https://kudu.apache.org/docs/known_issues.html

性能面
HDDかSSDか？
• 特にレイテンシ（応答速度）が重要なディスクにはSSDを推奨
• Kudu TS の WAL
• Kafka の ZooKeeper
• Kuduのデータ用ディスクについてもSSDに最適化されており、可能であればSSD推奨
• もちろんHDDでも動くが十分に検証する
JBODかRAIDか？
• 基本的にデータを格納する領域にはJBOD（Just Bunch Of Disks）がよい
• ↓可用性の観点では必要に応じてRAID10
可用性
単一ディスクかRAIDか？
• OS領域やWALなど、それぞれ専有ディスクを与えるべき部分の冗長性をどうするか？
• 単一ディスク障害がすぐさまノード障害となり、その影響度が高い場合RAID1またはRAID10
• ノード障害となっても、他のノードでカバーできるなら単一ディスクも可、そこはトレードオフ
性能と可用性からみたディスクの考慮
〜Note〜
ZooKeeperは一般に低レイテンシを要求
するが、用途次第ではHDDでも可

• HDFSのDataNode用データディレクトリ、KuduのTabletServer用データディレクトリは、複数
本のディスクをJBODで構成する
• JBODとは、RAIDなどを設定せず各ディスクをそのままOSに認識させること
• HDFSやKuduといったストレージは、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つにストライピングする構成は非推奨
ディスクは原則JBOD構成で
RAID0
RAID 0/5/60 0 0 0
例1) 通常のJBOD構成例2) RAID0でのJBOD構成例3) ストライピングNGOK OK

勘所6
適切なデータ型を考えよう

データモデル
• リレーショナルデータベースに似ている
• テーブル構造
• 各列は強いデータ型を持つ
• 主キーを持つ
カラムナー
• 物理構造として、列ごとにデータが分離し
ている
• 集計する際、必要な列のみをスキャン
• 例）平均気温を出す
KuduのスキーマはリレーショナルDBに似ている
humidity
83
81
81
83
80
sensor_i
d
1
2
2
3
3
time
1531975456
1531975457
1531975458
1531975459
1531975460
region
TOKYO
TOKYO
TOKYO
TOKYO
KYOTO
temp
32.35
33.12
33.12
32.36
37.00

制約
• 主キー列は必須かつユニーク制約だが、他の列はNULLも可
能
データ型
• Boolean
• 8/16/32/64 bit signed integer
• timestamp (64-bit microseconds Unix epoch)
• float/double (IEEE-754)
• UTF-8 encoded string（64KBまで）
• decimal
• Binary (64KBまで)
データ型の重要性
• エンコーディングと圧縮による、IOと保存容量の効率化
列のデータ型
sensor_i
d
time region temp humidity
1 1531975456 TOKYO 32.35 83
2 1531975457 TOKYO 33.12 81
2 1531975458 TOKYO 33.12 81
3 1531975459 TOKYO 32.36 83
3 1531975460 KYOTO 37.00 80
INT TIMESTAMP STRING DOUBLE INT

適切なデータ型を使う理由
• 保存するデータ容量の削減するため
• フィルター（述語）などを効率よく適用するため
• 基本はリレーショナルDBの考え方ととあまりかわらない
ありがちなNG例）
• 数字を文字列で表現："1500-0001231-12414"
• 日付を文字列で表現："2018-11-06"
適切なデータ型とは？
sensor_i
d
time region temp humidity
1 1531975456 TOKYO 32.35 83
2 1531975457 TOKYO 33.12 81
2 1531975458 TOKYO 33.12 81
3 1531975459 TOKYO 32.36 83
3 1531975460 KYOTO 37.00 80
INT TIMESTAMP STRING DOUBLE INT
〜Note〜
扱うデータ量がお多いため、少しで
も効率よく格納することで、全体の
データ削減につながる。

勘所7
エンコーディングはまずは自動で十分

エンコーディング（符号化）
• データのbit表現をどう表すかのこと
• 列にデータ型があるから適切なエンコーディングが可能
• エンコーディングによりデータサイズやIOの削減が可能
基本はデフォルトの設定で十分
列のエンコーディング humidity
83
81
81
83
80
sensor_i
d
1
2
2
3
3
time
1531975456
1531975457
1531975458
1531975459
1531975460
region
TOKYO
TOKYO
TOKYO
TOKYO
KYOTO
temp
32.35
33.12
33.12
32.36
37.00
この例のようにカーディナリティの低いSTRINGの列を、
文字列（UTF-8）のまま格納するのは効率が悪い。
辞書の索引の様に、置き換えることで、格納効率が格段に上がる
〜Note〜
データのカーディナリティやソートを考えた際に、run length や
prefix encoding が良いと判断されるときは、変更を行う価値あり
region
1
1
1
1
2
dictionary
1:TOKYO
2:KYOTO
3:OSAKA

勘所8
列圧縮は必要に応じて明示的にLZ4設定

• Kuduは列単位でデータの圧縮が可能
• LZ4、Snappy、zlib
• 圧縮は圧縮速度と圧縮サイズのバランスを考える
• 圧縮処理はCPUと時間を使うが、圧縮によってサイズが減ればIO量を
減らすことができる
• 一般的に圧縮/展開速度と圧縮サイズの面でLZ4が最もバランスが良く
• 圧縮率だけみるならzlibが最も高い
• 通常の列はデフォルトでは無圧縮になっている
• まずはLZ4による圧縮を試すのがよい
• Bitshuffleエンコーディングは例外で、内部で自動的にLZ4で圧縮が行わ
れるので、その上に追加で圧縮を掛ける必要はない
列圧縮
〜Note〜
つまり圧縮とは、IOのボト
ルネックをCPU側に寄せる
ものである
〜Note〜
主キー列の様にソートされ
てる列は圧縮効率がよい
humidity
83
81
81
83
80
sensor_i
d
1
2
2
3
3
time
1531975456
1531975457
1531975458
1531975459
1531975460
region
TOKYO
TOKYO
TOKYO
TOKYO
KYOTO
temp
32.35
33.12
33.12
32.36
37.00

勘所9
マルチレベルパーティションを使いつつ
合計パーティション数を意識しよう

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

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

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

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

CREATE TABLE時のパーティション設定例
ハッシュパーティションの例コンポジットパーティションの例
range(20) x hash(4) → 60パーティション
hash(16) → 16パーティション
〜Note〜
さらにパーティションは3つのレプリカを持つ
ため、実際にはさらにこの3倍存在している。
〜Note〜
さらにパーティションは3つのレプリカを持つ
ため、実際にはさらにこの3倍存在している。

• 現在のところパーティションに関する制約がスキーマ設計の制約につながる
• レンジパーティションのadd/dropのみ可能、それ以外はパーティションの変更は不可
• とくに後からノード追加が想定される場合、パーティションを多めに用意
• パーティション（タブレット）を各ノードに配分するため、十分なパーティ
ション数がないと、ノード追加してもノードあたりのパーティション数が減る
基本はマルチレベルパーティションを使う
ノード追加時に配分
〜Note〜
パーティション数を変えるには、
レンジパーティションの追加削除
しか現状はできない

• タブレット数を意識
• タブレットはパーティションと対応、複数の種類のパーションを利用した場合、その積になる
• スキャンは1タブレットごとに1つのスキャナー
• 基本的には、スキャンの並列度を考えると1ノードあたりのタブレットは多いほ
うが良いが、CPUコア数を超過すべきではない
• 大規模テーブルのタブレット数の目安
• CPUのコア数から並列度を考慮
• 小規模テーブルのタブレット数の目安
• 1タブレットに少なくとも1GB程度のデータが入るように調整
マルチレベルパーティションの考え方
タブレット数＝ ×
ハッシュバケット
1の数
... ×
ハッシュバケット
2の数
レンジの数
〜Note〜
フルスキャンの際、各ノードIO並列度が
いくつになるかを意識する

勘所10
主キーの設計はパーティションとセット

• 主キーの設計が最重要な1つ
• パーティションキーは主キーに含まれる必要があるため、
複合主キーを構成することが多い
• 例）時系列によるキー + パーティションキー
• Kuduは、スキャンのフィルター条件（WHERE
句）を判断し、不要なパーティションは読み取り
をスキップ
• ハッシュパーティションのプルーニング
• 全てのハッシュ列に等価（=）の述語を含める必要がある
• レンジパーティションのプルーニング
• レンジパーティション列に、等価（=）または範囲
（<,>,≦,≧,etc.）を含む必要がある
主キーの設計とパーティションのプルーニング
〜Note〜
パーティションを読まないということは、
並列度自体は下がってしまうことに注意

• Kuduの主キーは、クラスターインデックスになっている
• 1つのタブレット内にある全ての行は、主キーのソート順に保持される
• スキャンの述語に、等価（=）、範囲（<,>,≦,≧,etc.）などがある場合、合致しないものはIOを
スキップする
• 主キーによるプルーニングは、主キーのプレフィックス（先頭列）にのみ有効
• 複合主キーPK(A,B)があり、where B=‘...’ という条件をかけた場合、プレフィックスではない
（先頭列ではない）のでプルーニングは起こらないので注意
• 例）SELECT * WHERE series = ‘us-east.appserver01.loadavg’;
• PK(series, time) と主キーが構成されていればはプルーニングされるが
• PK(time, series) と主キーが構成されている場合プルーニングがされない（全部読むしか無
い）
主キーの設計と主キーによるプルーニング
(us-east.appserver01.loadavg, 2016-05-09T15:14:00Z)
(us-east.appserver01.loadavg, 2016-05-09T15:15:00Z)
(us-west.dbserver03.rss, 2016-05-09T15:14:30Z)
(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)
(2016-05-09T15:15:00Z, us-east.appserver01.loadavg)
(2016-05-09T15:14:30Z, us-west.dbserver03.rss)
PK(series, time) PK(time, series)
〜Note〜
パーティションプルーニングの
方が効果が高いのでまずはそち
らを重視

勘所11
Kuduへのデータ投入
バルクロードはImpala経由で

• HDFSにParquetなどでデータを置いた後に、CTASでバルクインサートする
のが、現時点では最速
• 現行バージョンのImpalaでは、一旦メモリー上でソートを行ってKuduに書き
込もうとするため、特にインサート対象データサイズに対してメモリが不足
している際、顕著に遅くなる
• CTASに /* +noclustered,noshuffle */ ヒントをつけることで高速化につながる
場合がある（将来のバージョンでは挙動が変わる可能性あり）
ImpalaによるHDFS → Kuduバルクインサート

勘所12
データロード後は
テーブルの統計情報を取得

• 統計情報取得コマンド: COMPUTE STATS
• 統計情報は以下のコマンドで閲覧できる
• SHOW TABLE STATS
• SHOW COLUMN STATS
• 統計情報がないと、遅くなる、ハングする、OOMで落ちるなど、
compute stats による統計の取得
統計を取ってないとクエリプロファイルに上記のような警告が出る
WARNING: The following tables are missing relevant table and/or column statistics.
<テーブル名>, <テーブル名>, ...

勘所13
ネットワーク転送時間は意外な落とし穴

• KuduでSCANしたデータはImpalaレイヤーで適切に
aggregationされ、最終結果がSQLを発行したクライアント
に戻る
• Kuduレイヤーでデータ量を十分に絞れない場合、Impala
daemon間のネットワーク転送がオーバーヘッドになりがち
• 特に最終結果が絞られず、例えば100万レコードなどがクラ
イアントやBIツール返る場合、クライアントへの転送に時
間がかかることが多い
KuduとImpalaの通信
集計
例）3億行読んで最終的に
90行に絞られている
〜Note〜
BIツールなどのクライアントへの最終転送はクラス
ターの外の世界なので、ネットワークが相対的に細い、
TCPコネクションが1本、シリアライズ/デシリアライ
ズに時間がかかるなど、オーバーヘッドが大きい

勘所14
Cloudera Managerで性能情報を取得しよう

Impalaのクエリプロファイル
• SQL単体チューニングは、CMの Impala → クエリより、各クエリの詳細を確
認できる
ある単体クエリの詳細ノードごとにかかった時間
Kuduレイヤーの情報

勘所15
BIツールが投げるSQLに注意しよう

• BIツールはほとんどの場合SQLにてアクセスする
• Impala経由でKuduにアクセス
• Impala用JDBC/ODBCドライバーを利用
• 重要な点は、「BIツールが投げるSQLを意識する」こと
• BIツールは必ずしも数百億件もの大量データを意識したSQLを投げてこない
BIツールなどからの分析

• 「BIツールが投げるSQL」はImpalaのクエリから確認できる
• Kuduがパーティションプルーニングなどを適切に行うには、SQL
のフィルターがKuduにpush downされる必要がある
• 気をつけるべき例
• 例）region列でパーティションされる際、regionに関数が使わ
れてると、パーティションプルーニングがされない
• 例）BIツールが全ての値をのdistinct値を取得しようとする場合
• 例えばピボットテーブルのフィルターとなっているディメンジョンについ
て、フィルターのリストを生成するために、最初に select distinct が行われ
る。これが100億件のテーブルでこれが発生すると、100億件の hash
distinct が実行されてしまう。
BIツールに合わせた設計
NGOK

勘所16〜
1セッションでは伝えきれないため
お気軽にご相談ください

Impala + Kudu を用いたデータウェアハウス構築の勘所（仮）

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Impala + Kudu を用いたデータウェアハウス構築の勘所（仮）

Ähnlich wie Impala + Kudu を用いたデータウェアハウス構築の勘所（仮） (20)

Mehr von Cloudera Japan

Mehr von Cloudera Japan (20)