Apache Impalaパフォーマンスチューニング #dbts2018

Apache Impala パフォーマンスチューニング

2 © Cloudera, Inc. All rights reserved.
嶋内翔 (しまうちしょう)
テクニカルエバンジェリスト
兼シニアセールスエンジニア
お客様にとって最適なデータ分析基盤の提案をする仕事をして
います
主な担当業種: 金融業界
主な専門分野: 分析データベース
略歴
2006年、NEC入社。OSS推進センターでOSSの基盤についての
基礎を学ぶ。
2011年、Cloudera入社。サポートエンジニアとして、日本のお
客様の技術問い合わせに回答していく傍ら、Hadoopの啓蒙活
動に務める。
2015年から現職。
自己紹介

Clouderaは
現在は不可能なことも、データの力によって
近い将来可能になると信じています
Apache Hadoopの
信頼できるリーダー企業
▪ エンタープライズ企業1000社以
上の実績を持つ、Apache
Hadoopをコアとしたデータ基盤
を提供するベンダー
▪ Apacheエコシステム全体に対す
るトップレベルのコントリビュータ
陣
▪ 10万以上のノードの運用管理実
績
Hadoopを簡単に使える
企業向けソリューションに
▪ 検証・認定済みで、サポートも行う
Apache Hadoopディストリビュー
ション
▪ Hadoop管理者用マネジメント・ソフ
トウェア群
▪ トレーニングと認定プログラム
▪ 包括的なサポートとコンサルティン
グサービス
Hadoopを簡単に使える
エンタープライズ向けデータ
基盤に
▪ Hadoopをコアに、20種類以上の
OSSを組み合わせ、運用管理・セ
キュリティ・データガバナンスの機
能を加えた統合データ基盤
▪ 日本で2000人以上の実績を持つ
トレーニングと認定プログラム
▪ 日本語での包括的なサポートと、
機械学習を活用した予測サポート
業界をリードする　　　卓越
した知識と経験　　　　　　
▪ PoCから本番環境まで、あらゆ
るフェーズでの設計・構築・最適
化を支援
▪ 金融、通信、医療、ハイテクな
ど、あらゆる業界のトップ10企業
や、27カ国もの政府機関での実
績
▪ トレーニング、サポート、プロ
フェッショナルサービスの全てを
日本語で提供
実績ある能力を持つ
強力な経営陣
CEO
Tom
Reilly
COO
Mike Olson
CTO
Amr Awadallah
Chief Architect
Doug Cutting

Cloudera Enterprise
あらゆるデータを蓄積し、活用するための最新のデータレイク基盤
クラウドストレージ
(Amazon S3 / Microsoft ADLS)
オンプレミス分散ストレージ
(Hadoop / Kudu)
IoTセンサー
データソース
サーバー
ログ
RDBMS
ファイル
定型レポート
ダッシュボード
セルフサービスBI
機械学習システム
リアルタイムBI
全文検索システム
NoSQL バッチ処理
ストリーム処理
ETL
データ
サイエンス
データ
ウェアハウス

• Impala概要
• Impalaパフォーマンスチューニングの基本
• 計測における主要確認項目
• ストレージIOチューニング
• Parquet
• パーティション
• 統計情報
目次
APPENDIXにより詳しい話が書いています

• Impalaを高速化したい、性能を引き出したいという人向けのスライドです
• 以下の内容については触れません
• Impalaの事例
• Impalaの他製品との比較
• Impalaの機能紹介
• 前提知識
• Hadoopについての基本的な知識
• サーバリソース(CPU、メモリ、ネットワークIO、ストレージIO)についての基本的な知識
• Impalaを始めとしたSQL-on-Hadoopについての基本的な知識
• OLAPについての基本的な知識
このスライドについて

© Cloudera, Inc. All rights reserved.
Impala概要

大規模データに特化した
分析用途の
分散
クエリエンジン
• Apache Foundationトップレベルプロ
ジェクトのOSS
• C++ / Java
• ベータ版リリースは2012年
• 2018年9月現在の最新版は3.0.0
• http://impala.apache.org/
Apache Impala

• 速い
• 大規模データに対して速い
• 分析クエリが速い
• 同時並列で実行しても速い
• スケールする
• サーバやインスタンスを足せばリニアにスケールする
• 数百ノード規模まで拡張可能
• 互換性が高い
• ANSI SQL:92 互換 + ウィンドウ関数等の分析用機能の追加
• 主要BIツールとの直接接続が可能
• Tableau, Qlik, Microstrategy, Pentaho, ZoomData, etc.
• セキュリティ機能が充実(要Apache Sentry)
• Kerberos / Active Directory 認証
• 列レベルアクセス制御
• DB単位の管理者設定
Impalaの特長
https://blog.cloudera.co.jp/apache-impala-leads-traditional-analytic-database-april-25th-b6fd8dcc916f

• Impalaはマスターレスアーキテクチャ
• Impalaは、各サーバやインスタンスを
ノードとして、複数台で協調稼働する分
散アーキテクチャ
• Impalaクライアントからクエリを受け取
るImpalaノードはコーディネータノードと
呼ぶ
Impalaのアーキテクチャ(1)
Impalaの基本アーキテクチャ
クラスタ
Impalaノード
コーディネータノード
クライアント
Impalaノード Impalaノード

Impalaの実際のアーキテクチャ
Impalaは数百ノードオーダーでスケールする分散アーキテクチャ
Impalaノード Impalaノード Impalaノード
Impalaノード
コーディネータ Impalaノード Impalaノード Impalaノード Impalaノード Impalaノード Impalaノード
Impalaノード Impalaノード Impalaノード Impalaノード Impalaノード Impalaノード Impalaノード Impalaノード Impalaノード Impalaノード
クライアント
毎回これだけ書くと煩雑なので、以後の説明では 3ノードのみ記述する

• Impalaデーモン
• クラスタ内で複数動作し、計算処理を行うデー
モン
• コーディネータノード
• クライアントからクエリを受け取り、分散処理
を制御するImpalaデーモン。
• 全てのImpalaデーモンはクエリを受け取った
時点でコーディネータノードとなる
Impalaデーモン(impalad)とコーディネータノード
クラスタ Impalaノード
クライアント
Impalaデーモン
Impalaデーモン Impalaデーモン

• StateStoreデーモン
• Impalaデーモンのヘルスチェックを行い、互
いの死活状態を共有する
• StateStoreデーモンが存在していると、
Impalaデーモンがダウンしても他のImpala
デーモンはそのことを検知できる
• StateStoreがダウンしても、他のImpalaノード
がダウンしない限りは業務継続可能。つまり1
ノードでもSPOFでないことに注意
StateStoreデーモン(statestored)
クライアント
Impalaデーモン
StateStoreデーモン
互いの死活をチェック

• Hiveメタストアサーバ
• スキーマ情報を管理するサーバ
• Hiveを始め、各種サービスと共通のスキーマを利
用可能
• Catalogデーモン
• Impalaデーモンによるメタデータ変更を自動でリ
レーする
• Catalogデーモンがダウンしても業務継続可能
• SELECT文等は実行可能
• メタデータの変更を行っても明示的にキャッシュを更新
すればいいだけ
Catalogデーモン(catalogd) と Hive メタストア
クライアント
Impalaデーモン
StateStoreデーモン Catalogデーモン
Hive
メタストアサーバ
メタストアDBスキーマ情報の更新をリレー

Impalaの動作の仕組み
クライアント
Impalaデーモン
ストレージストレージ
1. クライアントはImpalaデーモンに
接続し、クエリを発行
2. コーディネータノードはクエリの
実行計画を立てる
3. コーディネータノードは各Impala
デーモンに処理を依頼
4. Impalaデーモンはストレージの
データをスキャンした後、ローカル
で実行可能な計算処理を実施
5. JOIN等、必要があればノード間
でデータを転送し、さらに処理を継
続
6. コーディネータノードが結果を集
約して最終処理
7.結果をクライアントに返す

Impalaはどこでリソースを使うのか
クライアント
Impalaデーモン
1. クライアントはImpalaデーモンに
接続し、クエリを発行
2. コーディネータノードはクエリの
実行計画を立てる
3. コーディネータノードは各Impala
デーモンに処理を依頼
4. Impalaデーモンはストレージの
データをスキャンした後、ローカル
で実行可能な計算処理を実施
5. JOIN等、必要があればノード間
でデータを転送し、さらに処理を継
続
6. コーディネータノードが結果を集
約して最終処理
7.結果をクライアントに返す
ネットワーク IO
ディスクIO
メモリ・CPU

• Impalaはクエリエンジンのみ
• ストレージエンジンは別
• 例: HDFS, S3など
• 従来のRDBMSはクエリ+ストレージがセットになっているも
のが大半
• Impalaのパフォーマンスチューニングの大半は
ストレージエンジン周りであり、Impala固有の
チューニングは多くない
• つまり、このチューニングをきちんとやれば他のHadoopエ
コシステムのチューニングにもなる
• Spark
• Hive
従来のRDBMSとの違い(1) ストレージとの疎結合性
クラスタ
Impalaサービス
外部ストレージサービス
Impalaとは別にストレージ選定
の必要あり

• Impalaはメタデータ(スキーマ情報)とデータが疎結合
になっている
• メタデータはHiveメタストアサーバで管理されている
従来のRDBMSとの違い(2)スキーマ情報とデータの疎結合性
クラスタ
Impalaサービス
外部ストレージ
サービス
Impalaノード
Impalaデーモン
ストレージ
id name date
1 sato 2018-01-01
2 tanaka 2018-01-01
3 kato 2018-01-01
4 yamada 2018-01-02
5 morita 2018-01-02
6 kawada 2018-01-02
7 mikami 2018-01-03
8 ishii 2018-01-03
9 kitami 2018-01-03
Hive
メタストアサーバ
メタストアDB
テーブルとストレージ上の
データのマッピング情報
(メタデータ)

• Impalaは分散システム
• データは水平分割されていて、各Impalaノードが別
個に分割したデータにアクセスを行う
• JOIN等で必要に応じて、ノード間でデータが転送され
る
• チューニングのポイント
• ストレージ: きれいに水平分割できるよう設計する必要が
ある
• ネットワーク: なるべくネットワーク転送を減らすようにする
必要がある
従来のRDBMSとの違い(3) 分散システム
クラスタ
Impalaサービス
サービス
Impalaノード
Impalaデーモン
ストレージ
id name date
1 sato 2018-01-01
2 tanaka 2018-01-01
3 kato 2018-01-01
4 yamada 2018-01-02
5 morita 2018-01-02
6 kawada 2018-01-02
7 mikami 2018-01-03
8 ishii 2018-01-03
9 kitami 2018-01-03
大きなテーブルは水平分割されている
個々のノードで独立して格納
ノード間通信で必要なデータを共有

• RDBMS的なパフォーマンスチューニングのイメージ = SQLをいかに効率よく書くか
• Impalaのパフォーマンスチューニング = アーキテクチャの見直しがメイン
• SQLの改善は正しいアーキテクチャを作ってから
• SQLの改善は(時間がないので)話しません
• APPENDIXに書いてるのでそっちを読んでください
従来のRDBMSとの違い(4) パフォーマンスチューニング戦略

Impalaパフォーマンスチューニングの基本

• 合理的な性能目標をもつこと
• 無計画なチューニングはお金と時間の無駄
• 推測するな計測せよ
• チューニングはボトルネックを特定してから
パフォーマンスチューニングについての一般的な原則

• クエリプロファイルを取得する
• クエリの並列実行数を計測する
• CPU、ストレージIO、ネットワークIO、メモリの利用状況を調べる
計測方法

• 今日紹介する以下の4項目だけは必ず実施すること
• Impalaのバージョンを最新版にする
• 適切なストレージエンジンとデータフォーマットを選択する
• 適切にパーティションを切る
• 統計情報を取る
この4つを改善するだけで全然違うはず
これ以上に性能がほしい場合はちゃんと工数とってチューニングしてください
APPENDIXに色々な手法や詳細が書いてるので、興味ある人はそちらを読んでください
主要なパフォーマンスチューニング項目

計測における主要確認項目

• クエリの実行計画を確認可能
• EXPLAIN_LEVEL クエリオプションでより詳細な情報を出力可能
• SET EXPLAIN_LEVEL=<N>
• 1: デフォルト
• 2: 拡張
• 主に以下のチェックが可能
• 予想メモリ消費量
• スキャン対象範囲
• JOIN戦略
• 統計情報の有無
• 実行計画だけなのでクエリの実行は不要
• 性能調査の初期調査としては一番簡単
• 実行前の簡単なチェックなどにも使用可能
• あくまで実行計画であり、実際のクエリがどう実行されるかは別
• EXPLAINだけで性能を判断しないこと！
• 後述のプロファイルを必ず取得すること
EXPLAIN
[impalad-host:21000] > explain select count(*) from customer_address;
+----------------------------------------------------------+
| Explain String |
+----------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=42.00MB VCores=1 |
| |
| 03:AGGREGATE [MERGE FINALIZE] |
| | output: sum(count(*)) |
| | |
| 02:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
| 01:AGGREGATE |
| | output: count(*) |
| | |
| 00:SCAN HDFS [default.customer_address] |
| partitions=1/1 size=5.25MB |
+----------------------------------------------------------+
EXPLAIN <SQL> と実行するだけ

• 実行したクエリのプロファイルの概要だけを出力
• EXPLAINと違い、クエリの実行直後でないと実
行不可
• 通常は完全なプロファイルを使うことが多く、
SUMMARY自体を使うことはあまりない
• PROFILEコマンドの出力にSUMMARYの出力は含まれる
• とはいえ、結果の読み方は非常に重要
SUMMARY
[localhost:21000] > select avg(ss_sales_price) from store_sales where ss_coupon_amt = 0;
+---------------------+
| avg(ss_sales_price) |
+---------------------+
| 37.80770926328327 |
+---------------------+
[localhost:21000] > summary;
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
| Operator | #Hosts | Avg Time | Max Time | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail
|
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
| 03:AGGREGATE | 1 | 1.03ms | 1.03ms | 1 | 1 | 48.00 KB | -1 B | MERGE FINALIZE |
| 02:EXCHANGE | 1 | 0ns | 0ns | 1 | 1 | 0 B | -1 B | UNPARTITIONED |
| 01:AGGREGATE | 1 | 30.79ms | 30.79ms | 1 | 1 | 80.00 KB | 10.00 MB | |
| 00:SCAN HDFS | 1 | 5.45s | 5.45s | 2.21M | -1 | 64.05 MB | 432.00 MB | tpc.store_sales |
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
実クエリをまず実行
直後にSUMMARYコマンドを実行

• 実行したクエリの完全なプロファイルを出力
• SUMMARYと同様、クエリを実行直後にPROFILEを実行
• 全Impalaデーモンのあらゆるメトリクスを出力するので、かな
り大きい
• 左はそのごく一部
• EXPLAINとSUMMARYの結果も含むので、性能調査では
PROFILEの実行が基本
• 左のクエリタイムラインは、クエリ実行時間の内訳の概要を
示している
• PROFILEをとったら、SUMMARYとともにまず最初に見るべき項目
PROFILE
[localhost:21000] > profile;
(長いのでクエリタイムラインだけ添付)
Query Timeline: 20s670ms
- Start execution: 2.559ms (2.559ms)
- Planning finished: 23.587ms (21.27ms)
- Rows available: 666.199ms (642.612ms)
- First row fetched: 668.919ms (2.719ms)
- Unregister query: 20s668ms (20s000ms)
SUMMARYと同様、実クエリを実行直
後にコマンドを叩く

• Impalaはクエリ毎にメモリ空間が独立
• よってクエリの並列実行数はメモリ消費
に直結
• ユーザ数が多い場合は並列実行数を
チェックすること
Impalaの並列実行数の確認
Cloudera Managerによるクエリ実行数のチャート

• クエリごとにどれだけリソースを消費し
ているかを調べる
• CPU、メモリ、ストレージIOのどこがボト
ルネックかによって対策が変わる
CPU、メモリ、ストレージIO
CPU時間の多いクエリメモリ消費の多いクエリ
ストレージIOの多いクエリ
(画像が潰れてて見えない)
Cloudera Managerによるクエリ毎リソース消費のチャート
実行時間は同程度に遅くても
原因はバラバラ

Impalaのバージョンごとの性能改善

• バージョンが上がるごとに確実に性能
改善されている
• 古いバージョンでのチューニングはコス
パが悪いので非推奨
• 可能な限り最新版を使うこと
Impalaのバージョンごとの性能改善
Impalaのリリース毎の性能向上の推移 (高い方が高性能)
正規化した性能(%)
2年
間
で
10倍
2年間で3倍

ストレージIOチューニング

• ストレージIOチューニングの戦略は2つ
• ストレージIOを極力減らす
• ストレージIOの性能を上げる
• ストレージIOチューニングの方法は3つ
• ストレージ層を最適化する
• スキーマ設計(特にパーティション設計)を最適化する
• クエリを最適化する
ストレージIOチューニングの基本

• スキャン
• データを読み込むこと
• フルスキャン
• 全てのデータを読み込むこと
• 部分スキャン
• 一部のデータを読み込むこと
• スループット
• 単位時間あたりどれだけの量のデータを読み書きできるか。今回一番重要な指標
• レイテンシ
• アクセス時にどれだけ素早くレスポンスを返せるか
• IOPS
• 一秒あたりに処理可能なストレージアクセスの回数。 Impalaはランダムアクセス用途で使わないため、今回は使いません
ストレージ性能周りの基本用語

• 大きく分けて3層存在
• データフォーマット
• データ構造を決定する層
• Parquet, Avro, CSV, JSON, etc.
• ストレージエンジン
• データに対するアクセス方法を提供する層
• 純粋にエンジンのみなのはHDFSだけ
• ストレージデバイス
• 物理的にデータを格納する層
• HDD, SSDなど
• Amazon EBS などのクラウド上のストレージデバイスもある
• 実際には一つのストレージエンジンが複数の層をカバーする
ことが多い
• Kudu: データフォーマット + ストレージエンジン
• S3 / ADLS / EMC Isilon: ストレージエンジン + ストレージデバイス
Impalaのストレージ層
Impalaノード
Impalaデーモン
ストレージ
データフォーマット
ストレージエンジン
ストレージデバイス
HDFS
Parquet / Avro / CSV HBase
Kudu
S3
ADLS
Isilon HDD / SSD / Amazon EBS
今日話すのはParquetだけ
残りはAPPENDIX読んでね

Parquet

• HDFS・クラウドストレージ上に保存できるファイ
ルフォーマット
• 列ごとにデータを持つため、分析クエリに対して
非常に高速で、しかも圧縮率が高い
• すなわち、安価・高速
• 短所
• 更新・追記不可
列指向ファイルフォーマット: Parquet (パーケイ)
製品ID 顧客ID 売上
a1 b1 c1
a2 b2 c2
a3 b3 c3
a4 b4 c4
a1 a2 a3 a4 b1 b2 b3 b4 c1 c2 c3 c4
行グループ
列チャンク列チャンク列チャンク

• 列単位でスキャン
• 100列中10列だけにクエリ発行→スキャンするデータ量は
10%だけ
• 行グループ単位でスキャン
• 100万行中1万行だけにクエリ発行→スキャンするデータ
は1%だけ
• フルスキャンに比べて遥かに少ないデータしか
スキャンしない
• 10% × 1% = 0.1% のデータに対してしかスキャンしない
• 100GBの元データであれば100MBだけスキャン
Parquetへのデータアクセスの仕組み
行グループ列チャンク列チャンク列チャンク
必要な行・列しかスキャンしない

• Parquetは列単位で格納しているので、
類似のデータであることを前提とした
様々なエンコーディングが可能
• デルタエンコーディング
• 前の行の値との差分を保存
• 辞書エンコーディング
• ランレングスエンコーディング(RLE)
• etc.
エンコーディングによる効率的な圧縮
作成日(タイムスタンプ) Diff(作成日)
1442825158 (なし)
1442826100 942
1442827994 1894
1442828527 533
各64ビット各11ビット
同じデータが重複していて冗長
差分だけ保存することでデータ圧縮
約1/6に圧縮
デルタエンコーディングの例
(イメージ。実際にはもっと複雑 )

• 対象データが全て集まってからでないとParquet形式に変換できない
• 1日分のログデータを変換するのであれば、1日待ってからでないと変換不可
• つまり、即座にデータ分析することはできない
• 追記・更新不可のため、データの訂正が入ると全部作り直しになる
• 訂正処理が頻繁に発生するデータの場合、再計算コストが無視できない
• 追記・更新が必要な場合はKuduを使うこと
• フルスキャンは他の行指向データよりも遅い
• SELECT * FROM を頻繁に実行するのなら AvroやSequenceFile等の方が速い
• 変換処理は必ずImpalaのINSERT INTO ... SELECT を使うこと
• 圧倒的に効率がいい
Parquetの注意事項

パーティション

• Impalaにおけるデータの水平分割の方法は3つ
• ブロック単位
• ファイル単位
• パーティション単位
• パーティションとは、ある条件によって分類され
たファイル群をまとめるディレクトリのこと
• 左の例では日付ごとに別パーティションにしている
パーティション
クラスタ
Impalaサービス
サービス
Impalaノード
Impalaデーモン
ストレージ
id name date
1 sato 2018-01-01
2 tanaka 2018-01-01
3 kato 2018-01-01
4 yamada 2018-01-02
5 morita 2018-01-02
6 kawada 2018-01-02
7 mikami 2018-01-03
8 ishii 2018-01-03
9 kitami 2018-01-03
日付単位でパーティションを切る

パーティションの有無によるスキャンの違い
SELECT * FROM order WHERE date=‘2018-01-01’ というクエリを例に取ると…
パーティションがない場合
order/
data001.p
q
data002.p
q
data003.p
q
...
データ量 1024 GB
スキャン
全てのデータをスキャンし
て、しかもする必要あり各行
でdate列をチェック
(CPUコストかかる)
パーティションがある場合 (一年分のデータを日付で切る場合 )
order/
date=‘2018-01-01’/
data001.pq
data002.pq
data003.pq
...
データ量 1024 GB
スキャン
データ量約 2.8 GB
スキャンするのは、条件に合致したパーティションのみ
よって大幅にスキャンデータの削減が可能
さらにdate列のチェックも不要なため計算コストも減少
ディレクトリ名がそのままパーティ
ション列名=値となっている
スキャンデータは
1/365だけ

クエリプロファイルから見るパーティションの効果
クエリプロファイル上の実行計画によって算出されたHDFSのスキャン
| 02:SCAN HDFS [<テーブル名>, RANDOM]
| partitions=1/1438 files=1 size=12.21MB
| predicates: <テーブル名>.name != ‘ClouderaBot’, ...
| stored statistics:
| table: rows=40829409 size=4.85MB
全パーティション中、実際に読み取っているパーティションの数
スキャン予定のデータ量
このテーブルは本来13GBなので、1/1000以下までスキャン量を削減できた
テーブルの行数

• パーティション数はテーブルあたり10万が限度
• パーティション数が多いほど…
• メタデータが肥大化する
• Impalaデーモンのメモリのオーバーヘッドの増大
• 起動時やメタデータ更新時に時間がかかる
• クエリの実行計画作成に時間がかかる
パーティションに関する注意事項

• 時間単位をきちんと把握する
• 1年 = 12ヶ月 = 365日 = 8760 時間
• 今どきのデータ基盤はデータの10年保持は当然のように想定される
• つまり10年 = 120ヶ月 = 3650日 = 87600 時間
• ネストを考慮するなら日単位や時間単位はなるべく選択しない方がいい
• パーティションを増やしすぎてファイルサイズを小さくしすぎないようにすること
• 各パーティションのデータは最低でも256MBは置くこと
• WHERE文で常に(あるいはほぼ常に)使われるカラムだけをパーティション列にすること
パーティション設計のポイント

• 小売業の売上データ
• 第一パーティション: 日単位
• 第二パーティション: 店舗グループ単位
• 例えば、東北・北海道、関東、中部・北陸、近畿、中国・四国、九州の6つに分割
• 10年保存
• パーティション総数は 365 * 10 * 6 = 21900
パーティションの設計例

• CREATE TABLE ... PARTITIONED BY でパーティション列を指定
• ALTER TABLE ADD PARTITION でパーティションを作成
• INSERT INTO ... PARTITION(year=‘2018’, month=‘01‘) SELECT ... で該当パーティ
ションにデータを追加
パーティションの作り方と使い方

• INSERT INTO ... PARTITION(year, month) SELECT ... とすれば、ソーステーブルのyear, month 列を
読み取って動的にパーティションを選択してデータを挿入可能
• しかも、パーティションが存在しない場合は自動で作成
• つまりALTER TABLE ADD PARTITION が不要
• 個人的にはダイナミックパーティショニングは非推奨
• パーティション数とファイルサイズが管理できない
• 大抵の場合、大量のパーティションと小さいファイルの山となる
• メモリ管理ができない
• 特にParquetに変換する場合、全データを一度メモリに読み込んでから書き出そうとするので、あっという間にOOMで死ぬ
• パーティション管理は手を抜かずきちんとやってください
ダイナミックパーティショニング

統計情報

• 統計情報取得コマンド
• 以下の統計情報を収集する
• パーティション単位の行数
• カラム毎のユニークな値の数 (# of distinct values = NDV)
• あるカラムに出現する値が1,2,3,4の4種類のとき、# of distinct values = 4
• 統計情報の用途 (クエリ実行時に自動で使用)
• 述語選択 (特に、スキャン時のフィルタに使う )
• JOIN戦略
• テーブルサイズが極端に違うとき: 小さいテーブルをブロードキャスト
• テーブルサイズがさほど変わらないとき: パーティションJOIN
• 内部的には以下の2つのSQLを実行している
• SELECT COUNT(*) FROM table GROUP BY <パーティション列 >
• SELECT NDV(col1), NDV(col2), ... , NDV(colN) FROM table
• 統計情報は以下のコマンドで閲覧できる
• SHOW TABLE STATS
• SHOW COLUMN STATS
COMPUTE STATS
統計を取ってないとクエリプロファイルに上記のような警告が出る
WARNING: The following tables are missing relevant table and/or column statistics.
<テーブル名>, <テーブル名>, ...
統計情報がないと、遅くなる、ハングする、OOM
で落ちるなど、いいことが一つもない

• 重い
• codegenありで4000万セル/sec
• 40カラム、100億行のデータだと(4000億セル)、1000秒かかる
• codegenが効かないカラムについては700万セル/sec
• 例えばTIMESTAMP型やCHAR型はcodegenが効かない
• COMPUTE INCREMENTAL STATS: 新規パーティションだけを対象に指定可能
• ただしスループットはCOMPUTE STATSの半分
• 全統計情報を取り直す場合はCOMPUTE STATSを使うこと
COMPUTE STATS の注意事項

• 重いからといって取らない選択肢は一切ない
• 問題はどのタイミングで取得するか
• 大原則はデータの追加やパーティションの追加とセットで実行
• COMPUTE STATS実行によりなんらかの問題が発生する場合のみ、ずらして実行
• よほどのことがない限り許容できない手段と思うべき
• COMPUTE STATSを直後に実行しても問題ないように、データの追加タイミングを変えることをまず
検討すべき
パフォーマンスの観点から考えるCOMPUTE STATS

まとめ

• クエリプロファイルをとってボトルネックを調査すること
• 適切なストレージエンジンやデータフォーマットを選ぶこと
• Parquetは推奨だがベストではない
• パーティションを使うこと
• COMPUTE STATSを実行して統計情報を取得すること
今日話したこと

APPENDIXに書いてあること
• ストレージエンジン
• データフォーマット
• 圧縮アルゴリズム
• ストレージデバイス
• ScannerとIOManager
• ファイルサイズチューニング
• メモリチューニング
• JOINと統計情報
• メタデータ
• マルチテナントとアドミッションコントロール
• スキーマデザイン
• ハードウェア選定
• クライアントとコーディネータノード
• ベンチマーク取得の基本
APPENDIXにも書いてないこと
• メタデータの転送の流れ
• ランタイムフィルター
• LLVMとcodegen
• クエリスケジューリング詳細
• KuduScanner
• セキュアクラスタにおけるパフォーマンス
• プロファイル詳細
• 実行計画詳細
• ケーススタディ
• あと他にもたくさん
今日話していないこと
APPENDIXが本編なので、ダウンロードして読んでください

Welcome to the Data Age
〜データ駆動型企業への第一歩〜
2018年11月6日（火）
虎ノ門ヒルズフォーラム
www.clouderaworldtokyo.com

• Hadoopはどのように動くのか─並列・分散システム技術から読み解くHadoop処理系の設計と実装
• https://gihyo.jp/admin/serial/01/how_hadoop_works/0019
• Impala Cookbook
• https://www.slideshare.net/cloudera/the-impala-cookbook-42530186
• Cloudera のドキュメント
• https://www.cloudera.com/documentation/enterprise/latest/topics/impala.html
• Impalaのパフォーマンスガイドラインとベストプラクティス(翻訳)
• https://qiita.com/shiumachi/items/6439df4eaf1c1412cc4e
• Compression Options in Hadoop - A Tale of Tradeoffs
• https://www.slideshare.net/Hadoop_Summit/singh-kamat-june27425pmroom210c
参考資料

APPENDIX

Impala実行計画とクエリプロファイル(完全版)

• クエリの実行計画を確認可能
• EXPLAIN_LEVEL クエリオプションでより詳細な情報を出力可能
• SET EXPLAIN_LEVEL=<N>
• 1: デフォルト
• 2: 拡張
• 主に以下のチェックが可能
• 予想メモリ消費量
• スキャン対象範囲
• JOIN戦略
• 統計情報の有無
• 実行計画だけなのでクエリの実行は不要
• 性能調査の初期調査としては一番簡単
• 実行前の簡単なチェックなどにも使用可能
• あくまで実行計画であり、実際のクエリがどう実行されるかは別
• EXPLAINだけで性能を判断しないこと！
• 後述のプロファイルを必ず取得すること
EXPLAIN
[impalad-host:21000] > explain select count(*) from customer_address;
+----------------------------------------------------------+
| Explain String |
+----------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=42.00MB VCores=1 |
| |
| 03:AGGREGATE [MERGE FINALIZE] |
| | output: sum(count(*)) |
| | |
| 02:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
| 01:AGGREGATE |
| | output: count(*) |
| | |
| 00:SCAN HDFS [default.customer_address] |
| partitions=1/1 size=5.25MB |
+----------------------------------------------------------+
消費メモリの見積もり
過度な信用は禁物
スキャンを実行するノード
真っ先に確認すべき
読み込む対象のパーティション数とサイズ
実行計画レベルで無駄スキャンが発生していないかはここでチェック

• 実行したクエリのプロファイルの概要だけを出力
• EXPLAINと違い、クエリの実行直後でないと実
行不可
• 通常は完全なプロファイルを使うことが多く、
SUMMARY自体を使うことはあまりない
• PROFILEコマンドの出力にSUMMARYの出力は含まれる
• とはいえ、結果の読み方は非常に重要
SUMMARY
[localhost:21000] > select avg(ss_sales_price) from store_sales where ss_coupon_amt = 0;
+---------------------+
| avg(ss_sales_price) |
+---------------------+
| 37.80770926328327 |
+---------------------+
[localhost:21000] > summary;
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
| Operator | #Hosts | Avg Time | Max Time | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail
|
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
| 03:AGGREGATE | 1 | 1.03ms | 1.03ms | 1 | 1 | 48.00 KB | -1 B | MERGE FINALIZE |
| 02:EXCHANGE | 1 | 0ns | 0ns | 1 | 1 | 0 B | -1 B | UNPARTITIONED |
| 01:AGGREGATE | 1 | 30.79ms | 30.79ms | 1 | 1 | 80.00 KB | 10.00 MB | |
| 00:SCAN HDFS | 1 | 5.45s | 5.45s | 2.21M | -1 | 64.05 MB | 432.00 MB | tpc.store_sales |
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
クエリ実行直後にコマンド発行
処理を実行したホスト数
SCANノードのホスト数がデータ量に対して少ない場合、データが偏ってる可能性あり
平均処理時間と最大処理時間
ノード単位・ホスト単位でのボトルネックはここでチェック
Avg Timeに対してMax Timeが著しく長い場合、特定のノードのチューニングが有効な可能性あり
処理した行数と見積もり上の行数
実行計画通りに処理できているか？
消費したピークメモリと見積もり上のピークメモリ
これも実行計画との比較用
SCANノード
まず真っ先にこのノードを確認すること
大抵の場合ここがボトルネックになってるはずで、その切り分けを最初に行うのが定石

• 実行したクエリの完全なプロファイルを出力
• SUMMARYと同様、クエリを実行直後にPROFILEを実行
• 全Impalaデーモンのあらゆるメトリクスを出力するので、かな
り大きい
• 左はそのごく一部
• EXPLAINとSUMMARYの結果も含むので、性能調査では
PROFILEの実行が基本
• 左のクエリタイムラインは、クエリ実行時間の内訳の概要を
示している
• PROFILEをとったら、SUMMARYとともにまず最初に見るべき項目
PROFILE
[localhost:21000] > profile;
(長いのでクエリタイムラインだけ添付)
Query Timeline: 20s670ms
- Start execution: 2.559ms (2.559ms)
- Planning finished: 23.587ms (21.27ms)
- Rows available: 666.199ms (642.612ms)
- First row fetched: 668.919ms (2.719ms)
- Unregister query: 20s668ms (20s000ms)
クエリの総実行時間
Hueで実行する場合は無視
クエリ開始時間
ここが遅い = キューが詰まっている
アドミッションコントロール等の設定を見直すべし
実行計画作成時間
ここが遅いのはパーティション多すぎとか
クエリ複雑すぎとか
結果が返り始めたタイミング
ここが遅い = クエリの実行本体が遅い
クエリの終了処理の時間
ここが遅い = 結果セットが大きすぎなど
Hueの場合はセッションを貼り続けるので、ページ遷移するか
次のクエリ実行までこの時間が伸びるので、ここは無視すること

ストレージエンジン

Impalaの対応ストレージエンジン一覧
ストレージ
エンジン
オンプレorクラウド DAS (ノード直結) or NAS
(ネットワーク越し )
スキャン適正挿入・更新データフォーマットの要
不要
型定義
HDFS オンプレ
(デバイス層のクラウド化は可
能)
DAS ◎ × 必要 -- (データフォーマット
依存)
HBase オンプレ
(下位ストレージエンジンに
よってはクラウド可は可能 )
-- (下位ストレージエンジン
に依存)
× ◎ 不要不要
Kudu オンプレ
(デバイス層のクラウド化は可
能)
DAS ◯ ◯ 不要必要
EMC Isilon オンプレのみ NAS ◯ × 必要 -- (データフォーマット
依存)
Amazon S3 クラウド NAS ◯ × 必要 -- (データフォーマット
依存)
ADLS クラウド NAS ◯ × 必要 -- (データフォーマット
依存)

• どっちでもいいです
• クラウド上でもスループット出せるストレージデバイスは一通り揃ってる
• データフォーマットの設計等でIOの量自体を減らせば問題ない
オンプレかクラウドか？

• 性能だけ見ればDASがベターだが昔ほど極端な優位性はない
• 理由はオンプレorクラウドと同じで、ストレージIOを減らせば問題になりにくい
• NASとの間のネットワークは最低でも10G前提。帯域大きければ大きいほどいい
• 100ノード超の大規模クラスタだと、NASとの間のネットワークIOがさばききれないか
もしれない
• どうしても不安ならDASを検討してもいいが、その前に他のチューニングを全部やっ
てからにすること
DASかNASか？

• 分析データは二種類
• ファクト: 通常データは追加のみ。データ量は多い
• ディメンション: 挿入や更新が発生する。データ量はファクトよりも少ない
• ストレージの選定はビジネスロジックやSLAに大きく依存
• 更新発生のたびにデータを総入れ替えしていいのならParquetのみでも問題なし
• 詳細な選定方法は本スライドのスコープ外
• ユースケース毎に複数組み合わせるのが普通
• どうしたらいいかわからなければ、とりあえずスキャン適性高い方を選ぶ
• 要するにHDFS、S3、ADLSなど
スキャン適性と挿入・更新可否

• データフォーマットによって、コストと性能が大きく変わる
• 圧縮率: 100ノードクラスタで1%圧縮できれば1ノード分のコスト削減になる
• スキャン効率: 必要最低限のデータアクセスによりスキャン時間を大幅短縮可能
• スキーマ情報を組み込んでいるかも重要
• スキーマ情報あり
• ポータビリティが高い(別ストレージに移行しやすい)
• 外部システムからスキーマ情報込でクラスタへデータ投入が可能
他のあらゆるパフォーマンスチューニングをやる前に、まずデータフォーマットの最適化を行うこと
圧倒的に費用対効果が大きい

データフォーマット一覧
データフォーマット/ ストレージ Impala対応追記挿入更新用途保存期間(一例)
テキスト
CSV、XML、JSONなど
CSVのみ ×？(使い方次第) × × 生データのストレージエンジンへのアップロード。適切な
フォーマットに変換の後削除
変換完了後1週間〜1ヶ月
バイナリデータ
画像や動画ファイルなど
× × × × データの閲覧などにそのまま活用
ディープラーニングの学習用データ
永久保存
SequenceFile ◯ ◯ × × 生データの長期保存形式。バッチ処理などにはこのデー
タを使う
単体でスキーマを持たない
長期保存or永久保存
Avro ◯ ◯ × × 生データの長期保存形式。バッチ処理などにはこのデー
タを使う
単体でスキーマを持つ
長期保存or永久保存
(SequenceFileとどちらか一択でも
可)
Parquet ◯ × × × BIツールなどによる分析永久保存
HBase ◯ ◯ ◯ ◯ 小さい画像データ(サムネイル等)
ユーザアプリケーションが参照するデータ
永久保存
Kudu ◯ ◯ ◯ ◯ 時系列データや分析データを格納
BIツールなどによる分析
特に、ホットデータを取り込んですぐに分析したい場合に
有効
長期保存
(コールドデータになったら
Parquetに移行)
注: HBaseとKuduはストレージエンジンだが、これらは
データフォーマットと同列に検討すべきなのでここに記載している

• 例: Webログ、サーバログ、CSVファイル、Eメール
• 長所
• 取扱いが非常に簡単
• 人間が読める
• 短所
• データサイズが非常に大きい→圧縮必須
• 全てのデータは文字列として扱われるため、型変換が必須。よって速度は非常に遅い
• 例: “123” は文字列→数値への変換が必要
• ImpalaはCSVをサポートしているが、遅いのでそのまま分析するのはおすすめしない
テキストデータ

• 例: xml, json
• 長所
• 取扱いが非常に簡単
• スキーマを保持できる
• 人間が読める
• 短所
• Hadoopビルトインの入力フォーマットでは分割不可能
• 遅い
• jsonのまま分析するのは本当に遅いので絶対にやめるべき
• そのためImpalaはxmlやjsonサポートはしていない
構造化テキストデータ

• 例: 画像、動画、特殊なフォーマットのデータ
• 取り扱うために独自のReader/Writerを開発する必要あり
• Hadoopでバイナリを扱う場合、以下の方針で保存しておく
• 100KB以下: SequenceFile か HBase
• 10MB以下: SequenceFile か HBase (MOBモード有効)
• 128MB(またはHDFSのブロックサイズ)以下: SequenceFile
• 128MB以上: そのままHDFSに保存
• 2018年現在、大量の画像データの主な用途は機械学習のデータソースであり、アンサンブル学習のためにランダムアクセスが必
須になることから、可能な限りHBaseに置くというのが定石
• ファイルサイズが大きい場合は頑張ってなんとかすること
• Impalaで分析する場合はUDF書くか数値化されたデータ(類似スコア等)になるので画像を直接扱うことはほぼない
バイナリデータ

• 最も標準的なHadoopのフォーマット。Impalaのサポート対象
• バイナリのキーバリューペアでデータを格納する
• 長所:
• ほぼ全てのHadoopエコシステムに対応
• レコード・ブロック単位の圧縮により、分割不可の圧縮アルゴリズムを使ってもファイル分割が可能
• 行指向のため追記が可能
• 短所:
• スキーマがない
• 行指向のため分析クエリが遅い
SequenceFile

• 言語中立なデータシリアライズシステム
• インタフェース定義言語(IDL)を使ってインタフェースを定義して、異なる言語間でデータを扱えるようにする。コード生成はオプショ
ン
• スキーマをファイルヘッダに埋め込むことが可能
• 長所
• ファイル自体にスキーマを保持可能
• MapReduceでの読書をネイティブサポート
• 圧縮・分割もサポート
• スキーマエボリューション (書き込み時のスキーマと読み込み時のスキーマの不一致の許容 )のサポート
• 行指向のため追記が可能
• 短所
• 行指向のため分析クエリは遅い
Avro

• テーブルのような形式で活用可能なKVS
• デフォルトで10KB/セル、MOBモードで10MB/セルまでのデータを格納可能
• テーブル定義は列ファミリのみでOK。列そのものは自由に追加可能
• データは下位ストレージエンジン(通常はHDFS)にSequenceFileの形式で保存されている
• 長所
• 更新・追記が可能
• 単一行ルックアップが非常に高速
• データはHDFSに永続化されているため、スキャンのスループットは高い。よってバッチ処理などには比較的強い
• 短所
• レンジスキャンのレイテンシが高いため分析クエリに不向き
HBase

• Parquetと同様、列指向でデータを格納
するため、圧縮率が高く、分析クエリに
対して高速
• しかも、更新・追記が可能
• HDFSやS3とは別にクラスタを立てる必
要があるので、コストがかかる
• コールドデータはParquetに変換して他
のストレージに保存するのが無難
分析ストレージ: Kudu (クドゥ)

• 基本はParquetかKuduを選択
• Parquetを使う場合は以下の点に注意
• データソースのフォーマットの選定は別途必要(CSV、JSON、SequenceFile、Avro)
• 生データからの変換処理が必須
• 今から新規にデータを取り込むなら、圧縮形式はlz4推奨
• 既存のデータの圧縮形式を変更するほどではない
• 他のデータフォーマット・ストレージエンジンは状況に応じて適宜選択
• テスト用途等、人間が読める形式にしておきたい→CSV
• 別のアプリケーションからのランダムアクセスが必須で、分析クエリの実行速度は遅くてもいい→HBase
• データソース側がスキーマを自由に指定してデータ投入したい→Avro, JSON
結局どれを選べばいいのか？

圧縮アルゴリズム

• 注目すべき指標は2つ
• 圧縮率
• 圧縮率が高いと、ストレージ効率を向上させ、ネットワークIOを削減できる
• 圧縮・展開速度
• 圧縮・展開速度が速いと、CPU効率を向上させることができる
• 多くの場合、圧縮率と圧縮・展開速度はトレードオフ
圧縮アルゴリズム

圧縮アルゴリズム一覧
圧縮アルゴリズム圧縮・展開速度圧縮率備考
lzo 速い普通ライセンスがGPLのためHadoopとは別にインストー
ルする必要あり
snappyが登場した今、積極的に選ぶ理由はない
snappy 速い普通 Parquetのデフォルト圧縮形式
Hadoopエコシステムのデファクトアルゴリズム
gzip やや遅い高いあらゆるシステムで使われている定番アルゴリズム
bzip2 非常に遅い非常に高い非常に遅いので推奨しない
lz4 速い高い Kuduのデフォルト圧縮形式
Parquetも選ぶならこちらにした方がいいが、他の
チューニングをやってからでいい
zstd 速い(らしい) 高い(らしい) 新しめの圧縮アルゴリズム
2018年9月時点でClouderaは未サポート
使うなら自己責任で
現時点で新規に選ぶなら lz4 がベストで、将来的には (多分) zstd
別に snappy でも問題ないので、既存の snappy圧縮のファイルを全部コンバートするほどでもない
その他のチューニングを先に済ませること
圧縮・展開速度(高いほど速い)
圧縮率(右に行くほど高い)
※ zstdは新しいアルゴリズムのため図には未記載

ストレージデバイス

• Hadoopエコシステムの大原則: 容量のコストパフォーマンスが高いものを選ぶ
• HDFS
• 2018年現在もHDDがまだ一番コスパが高い
• 昔ほど差はなくなってきているので、調達コスト次第ではSSDも選択肢としてはあり
• HWベンダーの営業におねだりしてみよう
• SATA / 7500rpmで十分、というのが教科書通りの推奨だが、調達の関係なのかSASしか見ない
• Kudu
• NVMeライブラリに対応しているので、フルNVMeだと凄まじい性能が出る
• そして価格も凄まじいことになる
• WALだけSSDにして他をHDDにする構成がコスパ的に現実的
HDD vs SSD vs NVMe

• インスタンスストレージ
• リファレンスアーキテクチャ上の推奨デバイス
• 物理デバイスと同じ性能が出るが、揮発性があるのでインスタンスが死ぬとデータが飛ぶ
• そのため、インスタンス起動時には S3等からデータのロードが必須だし、新規データを作成したときは S3への書き戻しが必須
• 使うなら参照専用と割り切った方が楽
• EBS
• ここ数年でだいぶスループット上がったので使いやすくなった
• データも揮発しないので管理がやや楽
• S3
• 初期コストがほぼかからない、ストレージエンジンの管理が不要という大きなメリットがある
• 性能は上記2つに比べて劣るが、データロードが必要がないことを考えるとシステム全体では S3の方が短時間で処理が終わることも
• INSERT時の中間データの書き込み先にローカルデバイスを使うようになったので圧倒的に使いやすくなった
AWS

• プレミアムストレージ
• 性能は高いが値段も高い
• ADLSを使うべし
• Azure Data Lake Store (ADLS)
• 性能とコスパがいい
• 物理ディスクの数十%程度の性能が出るらしい
• Impala を Azure で使うなら ADLS 一択
• Azureにはインスタンスストレージ相当のサービスは存在しない
• Azure BLOB Storage
• Impalaは非対応なので使わないこと
MS Azure

ScannerとIOManager

• Scanner
• クエリがデータをスキャンする責務を持つ
• クエリ単位でCPUコア数分のスレッドを生成
• NUM_SCANNER_THREADS クエリオプションで調整可能
• IO Manager
• IOリクエストをスケジューリングし、ストレージからのデータをスキャンする責務を
持つ
• スキャンはラウンドロビンでスケジューリングされる
• 先読みで生データをスキャンしていく
• よって直接的なストレージ IOは全てIO Managerが発生させる
• ストレージデバイスごとにスレッド数が異なる
• HDD: ディスクあたり 1スレッド (固定)
• SSD: ディスクあたり 8スレッド (固定)
• S3: 16スレッド
• num_s3_io_threads デーモン起動オプションで調整可能
• Isilon: 8スレッド
• num_remote_hdfs_io_threads デーモン起動オプションで調整可能
• 詳しく知りたい人は以下のページを参照
• http://impala.io/doc/html/disk-io-mgr_8cc.html
Impalaのスキャン管理機構
Impalaデーモン
HDD SSD S3 Isilon
IO Manager
Scanner
1スレッド 8スレッド 8スレッド16スレッド
IOスケジューラ(ラウンドロビン)
スレッド
CPUコア数分
Scanner
スレッド
CPUコア数分
クエリクエリ

IO Manager
• Scannerスレッドの読み込み単位 = スキャンレ
ンジ
• 通常、1スキャンレンジ = 1 HDFSブロック
• IO Managerは、スキャンレンジ単位でスケ
ジューリングし、生データを先読みする
• Scannerはデータに対し、述語に基づいたフィル
タ処理を行う
スキャンレンジ
デバイス1
スレッド1 スレッド2
Scanner
スレッド1 スレッド2
スキャンノード
ブロック
デバイス2
ブロック
スキャンレンジスキャンレンジ
1スキャンレンジ = 1ブロック生データを先読み
述語に基づき
データをフィルタ

ファイルサイズチューニング

• デバイスを遊ばせず、なおかつ忙しくさせすぎないことが基本
• ファイルサイズは重要
• ファイルサイズが小さすぎ: Hiveのメタデータが肥大化したり、ストレージエンジンへのリクエストが多
くなって重くなる
• ファイルサイズが大きすぎ: 並列性が下がり、1スレッド・デバイスに負荷が偏る
• Parquetであれば、1ブロックあたり256MBで作ると最適なケースが多い
• Impala で INSERT INTO ... SELECT 文によってParquetファイルを生成する場合はデフォルトでこの
設定になっている
スキャン仕様から考えるパフォーマンスチューニング

メモリチューニング

• 本スライドで説明する項目
• ハッシュJOIN
• メタデータ(クエリ間で共有)
• 本スライドで説明しない項目
• GROUP BY
• Parquet書き込みバッファ: パーティション毎256MB
• IOバッファ(クエリ間で共有)
• クエリ間で共有と書いていない項目は、すなわちクエリ単位でメモリ消費が発生するということに注意
• 10並列のクエリなら10倍消費(クエリにもよる)
Impalaはどこでメモリを使うのか

JOINと統計情報

• JOINは二種類
• ブロードキャストJOIN
• パーティションJOIN
• JOINはImpalaのネットワークIOとメモリ消費の大半の要因
• 適切なJOINの選択には統計情報の取得が必須
ImpalaのJOIN

Impalaデーモン
ストレージ
メモリ領域
テーブルA-1
テーブル
B-1
テーブルB
Impalaデーモン
ストレージ
テーブルA-2
テーブル
B-2
メモリ領域
テーブルB
Impalaデーモン
ストレージ
テーブルA-3
メモリ領域
テーブル
B-3
テーブルB
• テーブルAとBをJOINするとき、スキャンしたBのデータの全
てを、全てのノードにコピー(シャッフル)してJOIN
• 当然ネットワークIOコストがかかる
• 個々のImpalaデーモンのメモリ領域には、スキャンしたテー
ブルBの全データのハッシュテーブルがロードされる
• 例: テーブルB(100GB)のうち1%(=1GB)だけをスキャンした
場合
• 1GB * ノード数分のネットワークIOが必要
• Impalaデーモンのメモリをノード毎に1GB消費
• 統計情報をとらないと大きいテーブルがシャッフルされる可
能性がある
• 簡単にOOMで死んだり、ハングしたりする
JOIN戦略(1) ブロードキャストJOIN
シャッフル
JOIN
スキャン

Impalaデーモン
ストレージ
メモリ領域
テーブルA-1
テーブル
B-1
テーブルB-1’
Impalaデーモン
ストレージ
テーブルA-2
テーブル
B-2
メモリ領域
テーブルB-2’
Impalaデーモン
ストレージ
テーブルA-3
メモリ領域
テーブル
B-3
テーブルB-3’
• テーブルAとB両方ともシャッフルするJOIN
• ノードごとに特定のJOINキーで集約
• Bに加えてAのデータもシャッフルするため、ネッ
トワークIOは増加
• Aのデータはストリームで入力することに加え、B
が各デーモンで分割されているため、消費メモリ
領域はBのデータ / ノード数に減少している
JOIN戦略(2) パーティションJOIN
シャッフル
JOIN
スキャン
テーブルA-1’ テーブルA-2’ テーブルA-3’
シャッフル

メタデータ

メモリ上のメタデータのサイズ =
T * 5.00 KB
+ P * 2.00 KB
+ F * 0.75 KB
+ B * 0.30 KB
+ Σ(k=1, T, Ck * Pk * 0.40 KB)
T = 総テーブル数
P = 総パーティション数
F = 総ファイル数
B = 総ブロック数
Ck = テーブルkにおけるカラム数
Pk = テーブルkにおけるパーティション数
• 例
• テーブル数 100
• パーティション数 10万
• ファイル数 200万
• ブロック数 400万
• 各テーブルは100カラム、1000パーティション
• このときメタデータのサイズは約6.6GBとなる
• このメタデータは全てのImpalaデーモンのメモリ
オーバーヘッドになる
メモリ上のメタデータのサイズ

• 起動時
• CatalogデーモンがHiveメタストアサーバからロードし、全てのImpalaデーモンにブロードキャストす
る
• ImpalaがDDLを発行したとき
• 差分をCatalogデーモンがブロードキャスト
• COMPUTE STATSを発行したとき
• 対象テーブルだけ
• INVALIDATE METADATAを発行したとき
• 対象テーブルだけ
メタデータのロードタイミング

マルチテナントとアドミッションコントロール

• デフォルトではクエリ毎のリソース制限
はない
• 特定のクエリがリソースを使い潰すと他
のクエリが実行できない
• ある程度同時実行数が増えたらリソー
ス管理機能を使う
リソース管理機能の必要性
Impalaクラスタ
クエリ1
メモリ
クエリ2
クエリ1がメモリを100%利用
クエリ2はメモリが
不足し実行不可

• リソースプール毎に、クエリの数とメモリ
量を制御する機能
• 以下の項目を設定可能
• 同時実行クエリ数
• キューイング可能クエリ数
• 割当てメモリ
アドミッションコントロール
marketing
実行可能クエリ数: 10
メモリ量: 100GB
キューイング可能クエリ数: 100
batch
実行可能クエリ数: 1
メモリ量: 1000GB
キューイング可能クエリ数: 10

• バッチとアドホックで分ける
• バッチ: 並列度少ない、メモリ消費量多い
• 通常は並列度1
• アドホック: 並列度多い、メモリ消費量少ない
• 並列度は実環境の測定結果に依存
• リソースプールに割当てる合計メモリは
多少多くても問題ない
• 全部使い切ることは稀
• 割当てメモリ量はクエリの実行結果を測
定して計算
• 机上での計算は不可能
• 1つのリソースプール内で最も多くメモリ
を消費したクエリに注目
• 最大メモリ消費量 * 1.2 をリソースプールの割
当てメモリとする
アドミッションコントロールのベストプラクティス

• リソース管理はソフトリミット
• Statestoreデーモンを通じて利用状況が一定間隔で各Impalaデーモンに共有される
• デフォルトは500ms
• つまり、500ms以内にメモリ許容限界を超えたクエリを同時に投げるとメモリがあふ
れるリスクがあることを意味する
• 巨大なクエリが同時に投げ込まれる事態をなるべく回避すること
アドミッションコントロールの注意事項

スキーマデザイン

• 文字列(STRING)は可能な限り使わないこと
• メモリ消費多い、ストレージ消費多い、計算が遅くなる(数値型の1/5)
• HBaseの行キーだけは例外的に文字列型推奨
• 数値型(INT, FLOAT, DOUBLE等)を可能な限り使うこと
• BLOB/CLOB
• 文字列型を使うこと
• 文字列型の最大サイズ
• 仕様上の制限はないが、1MBまでならいけるっぽい
• それ以上にすると多分Impalaデーモンがクラッシュする
• このデータがネットワークIOやメモリを消費する可能性を常に念頭に置いておくこと
データ型(1) 文字列型

• TIMESTAMP と日付
• 日付を表すカラム: TIMESTAMP型を使う
• パーティション列として日付を使う: INTを使う(例: ‘20180101’ を INT とする)
• DECIMALは必要がない限り使わないこと
• パーティションキーには使えない
• UDFの中で使えない
• なるべく FLOAT / DOUBLE を使うこと
データ型(2) TIMESTAMPとDECIMAL

• カラム数
• ハードリミットはないが、概ね2,000が限度と思っておくべき
• パーティション数
• こちらもハードリミットはないが、100,000 / テーブルくらいが限界
• どちらも大きければ大きいほどメタデータが肥大化し、以下の性能に影響を与える
• メタデータの更新
• パーティションの追加
• 統計情報の更新
• メタデータの取得
テーブルの最大サイズ

ハードウェア選定(ディスク以外)

• 前述の通り、1CPUコア = 1スキャナースレッド
• ここでいうコアは仮想的なコア数で、通常ハイパースレッディングが有効化されている場合は物理コアを2倍して計算する
• 例: 10core + HT = 20 vcore
• ストレージが遊ばないようにするためには、IO Manager のスレッド数よりやや多めのvcoreがあるのがベスト
• HDD 24本のノード: 24 vcore か、それよりやや多め
• S3(デフォルト16スレッド): 16 vcore か、それよりやや多め
• OSやImpalaデーモン、他のコンポーネント用のCPUコアも計算にいれておくこと
• HDFS + YARN + Impala なら、OS / DataNode / NodeManager / Impalad で最低4コア(+ YARNコンテナ用コア)を予約しておくこと
• CPUコアあたりの性能も重要であることに注意
• コア数さえ稼げばいい MapReduceとは考え方が異なる
• とはいえコスパが一番重要なので、優先度は低め
CPU選定

• 推奨は128GB / Impala ノード以上。256GBはほしい
• あくまでImpalaに割り当てるメモリなので、ハード自体にはさらに積む必要があることに注意
• それ以下にする場合は本スライドのメモリチューニングを熟読してサイジングすること
• 別に16GBとかでも動かないわけではないが、本番環境でここまでケチるくらいならそもそもImpalaの
採用を考え直した方がいい
• 16GB * 8ノード(マスター含めたら11ノード)買うくらいならメモリ128GB積んだRDBMSの方が安いし速いはず
• クラウド上の場合は別。低スペックインスタンスを一時的に横に並べてクエリを流したいケースはある
• 単なるバッチ的な操作で、CPUコア数とIOスレッドだけを稼ぎたい場合など
メモリ選定

• 最低10Gを用意すること
• ボンディング等でより太い帯域を確保できるならそれがベスト
ネットワーク選定

クライアントとコーディネータノード

• SELECT文を実行する場合、最終的には結果はクライアント
に返る
• よって、可能な限り最終結果を小さくすることが重要
• 以下の点に注意してクエリを作る
• 必ずLIMITをつける
• 可能な限りWHERE句でフィルタする
• 可能な限りSUMやMAXなどの集約関数を使う
• impala-shellを使う場合はさらに以下の点に注意
• 結果が大きいのであればファイルにリダイレクトする(画面に出
力しない)
• ストレージ側に保存するのなら INSERT INTOを使う
Impalaクライアントアクセスの最適化
クライアント
Impalaデーモン

• コーディネータノードの仕事は多い
• クライアントからクエリを受け取る
• 実行計画を立てる
• 他のImpalaノードに指示を出す
• 他のImpalaノードから結果を受け取る
• 最終計算を行う
• 最終結果をクライアントに返す
• 自分自身も通常のImpalaノードと同様、計算処理を
行うことに注意
• 左図のように1台のImpalaノードだけにクエリを投げ
るとボトルネックになってしまう
Impalaコーディネータノード
クライアント
Impalaデーモン
クライアントクライアントクライアント
負荷が集中しすぎ

• Impalaにクエリを投げる際は可能な限
り前段にロードバランサを設置する
ロードバランサによるコーディネータノードの負荷分散
クラスタ
ロードバランサ
Impalaノード Impalaノード Impalaノード Impalaノード
クライアントクライアントクライアントクライアント

• コーディネータ専用ノードを設置することで、Impalaを擬似的なマスター・ワー
カー型アーキテクチャに変更可能
• コーディネータ専用ノードは、他のコーディネータノードからのクエリを受け付け
ない
• 計算処理を全く行わないわけではないので、他のImpalaノードと同様にワー
カーノード側に置いておく必要がある
• 1コーディネータ専用ノードあたり、50 Impalaノード程度をカバー可能
• CPU利用率が80%超えたら専用ノードを増やす
• HA化するならさらに追加で1ノード以上作成しておく
• 起動オプション
• is_executor=false : 他コーディネータからのクエリの受付を禁止する。初期構築時に
コーディネータ専用ノードを作るときに有効
• is_coordinator=false : クライアントからのクエリの受付を禁止する。クラスタ増設時の
Impalaデーモンの初期設定に有効
コーディネータ専用ノード
コーディネータ専用ノード
クライアント
Impalaデーモン

ベンチマーク取得の基本

• 追試できる状態で情報公開すること
• サーバスペック、データセット、クエリセット、ソフトウェアバージョンなど
• 追試不可能なベンチマーク結果は信用できない
• 業界標準のベンチマークテストを使うこと
• 分析クエリならTPC-H か TPC-DS。Impalaの場合はTPC-DSが一般的
• マイクロベンチマークは本当にやめてください
• その上で、社内での独自のデータセット、クエリセットを用意すること
• 最終的には自社で使うクエリが速くなることが重要
• TPC-* はあくまで基礎検証における参考値
ベンチマーク取得の原則

• https://github.com/cloudera/impala-tpcds-kit
• Impalaに対して簡単にTPC-DSを実行可能
• クラスタ全体の基本性能を見たければこれを実行するのが一番確実
Impala TPC-DS Toolkit

Apache Impalaパフォーマンスチューニング #dbts2018

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Apache Impalaパフォーマンスチューニング #dbts2018

Similar to Apache Impalaパフォーマンスチューニング #dbts2018 (20)

More from Cloudera Japan

More from Cloudera Japan (20)

Recently uploaded

Recently uploaded (9)

Apache Impalaパフォーマンスチューニング #dbts2018