Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Apache Impala パフォーマンスチューニング
2 © Cloudera, Inc. All rights reserved.
嶋内 翔 (しまうち しょう)
テクニカルエバンジェリスト
兼シニアセールスエンジニア
お客様にとって最適なデータ分析基盤の提案をする仕事をして
います
主な担当業...
3 © Cloudera, Inc. All rights reserved.
Clouderaは
現在は不可能なことも、データの力によって
近い将来可能になると信じています
Apache Hadoopの
信頼できるリーダー企業
▪ エンタープ...
4 © Cloudera, Inc. All rights reserved.
Cloudera Enterprise
あらゆるデータを蓄積し、活用するための最新のデータレイク基盤
クラウドストレージ
(Amazon S3 / Microsof...
5 © Cloudera, Inc. All rights reserved.
• Impala概要
• Impalaパフォーマンスチューニングの基本
• 計測における主要確認項目
• ストレージIOチューニング
• Parquet
• パーテ...
6 © Cloudera, Inc. All rights reserved.
• Impalaを高速化したい、性能を引き出したいという人向けのスライドです
• 以下の内容については触れません
• Impalaの事例
• Impalaの他製品と...
© Cloudera, Inc. All rights reserved.
Impala概要
8 © Cloudera, Inc. All rights reserved.
大規模データに特化した
分析用途の
分散
クエリエンジン
• Apache Foundationトップレベルプロ
ジェクトのOSS
• C++ / Java
• ベ...
9 © Cloudera, Inc. All rights reserved.
• 速い
• 大規模データに対して速い
• 分析クエリが速い
• 同時並列で実行しても速い
• スケールする
• サーバやインスタンスを足せば リニアにスケール す...
10 © Cloudera, Inc. All rights reserved.
• Impalaはマスターレスアーキテクチャ
• Impalaは、各サーバやインスタンスを
ノードとして、複数台で協調稼働する分
散アーキテクチャ
• Impal...
11 © Cloudera, Inc. All rights reserved.
Impalaの実際のアーキテクチャ
Impalaは数百ノードオーダーでスケールする分散アーキテクチャ
Impalaノード Impalaノード Impalaノード
...
12 © Cloudera, Inc. All rights reserved.
• Impalaデーモン
• クラスタ内で複数動作し、計算処理を行うデー
モン
• コーディネータノード
• クライアントからクエリを受け取り、分散処理
を制御す...
13 © Cloudera, Inc. All rights reserved.
• StateStoreデーモン
• Impalaデーモンのヘルスチェックを行い、互
いの死活状態を共有する
• StateStoreデーモンが存在していると、
...
14 © Cloudera, Inc. All rights reserved.
• Hiveメタストアサーバ
• スキーマ情報を管理するサーバ
• Hiveを始め、各種サービスと共通のスキーマを利
用可能
• Catalogデーモン
• Im...
15 © Cloudera, Inc. All rights reserved.
Impalaの動作の仕組み
クラスタ Impalaノード
コーディネータノード
クライアント
Impalaノード Impalaノード
Impalaデーモン
Imp...
16 © Cloudera, Inc. All rights reserved.
Impalaはどこでリソースを使うのか
クラスタ Impalaノード
コーディネータノード
クライアント
Impalaノード Impalaノード
Impalaデー...
17 © Cloudera, Inc. All rights reserved.
• Impalaはクエリエンジンのみ
• ストレージエンジンは別
• 例: HDFS, S3など
• 従来のRDBMSはクエリ+ストレージがセットになっているも
...
18 © Cloudera, Inc. All rights reserved.
• Impalaはメタデータ(スキーマ情報)とデータが疎結合
になっている
• メタデータはHiveメタストアサーバで管理されている
従来のRDBMSとの違い(2...
19 © Cloudera, Inc. All rights reserved.
• Impalaは分散システム
• データは水平分割されていて、各Impalaノードが別
個に分割したデータにアクセスを行う
• JOIN等で必要に応じて、ノード...
20 © Cloudera, Inc. All rights reserved.
• RDBMS的なパフォーマンスチューニングのイメージ = SQLをいかに効率よく書くか
• Impalaのパフォーマンスチューニング = アーキテクチャの見直し...
© Cloudera, Inc. All rights reserved.
Impalaパフォーマンスチューニングの基本
22 © Cloudera, Inc. All rights reserved.
• 合理的な性能目標をもつこと
• 無計画なチューニングはお金と時間の無駄
• 推測するな計測せよ
• チューニングはボトルネックを特定してから
パフォーマンスチ...
23 © Cloudera, Inc. All rights reserved.
• クエリプロファイルを取得する
• クエリの並列実行数を計測する
• CPU、ストレージIO、ネットワークIO、メモリの利用状況を調べる
計測方法
24 © Cloudera, Inc. All rights reserved.
• 今日紹介する以下の4項目だけは必ず実施すること
• Impalaのバージョンを最新版にする
• 適切なストレージエンジンとデータフォーマットを選択する
• 適...
© Cloudera, Inc. All rights reserved.
計測における主要確認項目
26 © Cloudera, Inc. All rights reserved.
• クエリの実行計画を確認可能
• EXPLAIN_LEVEL クエリオプションでより詳細な情報を出力可能
• SET EXPLAIN_LEVEL=<N>
• 1...
27 © Cloudera, Inc. All rights reserved.
• 実行したクエリのプロファイルの概要だけを出力
• EXPLAINと違い、クエリの実行直後でないと実
行不可
• 通常は完全なプロファイルを使うことが多く、
S...
28 © Cloudera, Inc. All rights reserved.
• 実行したクエリの完全なプロファイルを出力
• SUMMARYと同様、クエリを実行直後にPROFILEを実行
• 全Impalaデーモンのあらゆるメトリクスを出...
29 © Cloudera, Inc. All rights reserved.
• Impalaはクエリ毎にメモリ空間が独立
• よってクエリの並列実行数はメモリ消費
に直結
• ユーザ数が多い場合は並列実行数を
チェックすること
Impal...
30 © Cloudera, Inc. All rights reserved.
• クエリごとにどれだけリソースを消費し
ているかを調べる
• CPU、メモリ、ストレージIOのどこがボト
ルネックかによって対策が変わる
CPU、メモリ、ストレ...
© Cloudera, Inc. All rights reserved.
Impalaのバージョンごとの性能改善
32 © Cloudera, Inc. All rights reserved.
• バージョンが上がるごとに確実に性能
改善されている
• 古いバージョンでのチューニングはコス
パが悪いので非推奨
• 可能な限り最新版を使うこと
Impala...
© Cloudera, Inc. All rights reserved.
ストレージIOチューニング
34 © Cloudera, Inc. All rights reserved.
• ストレージIOチューニングの戦略は2つ
• ストレージIOを極力減らす
• ストレージIOの性能を上げる
• ストレージIOチューニングの方法は3つ
• スト...
35 © Cloudera, Inc. All rights reserved.
• スキャン
• データを読み込むこと
• フルスキャン
• 全てのデータを読み込むこと
• 部分スキャン
• 一部のデータを読み込むこと
• スループット
• ...
36 © Cloudera, Inc. All rights reserved.
• 大きく分けて3層存在
• データフォーマット
• データ構造を決定する層
• Parquet, Avro, CSV, JSON, etc.
• ストレージエン...
© Cloudera, Inc. All rights reserved.
Parquet
38 © Cloudera, Inc. All rights reserved.
• HDFS・クラウドストレージ上に保存できるファイ
ルフォーマット
• 列ごとにデータを持つため、分析クエリに対して
非常に高速で、しかも圧縮率が高い
• すな...
39 © Cloudera, Inc. All rights reserved.
• 列単位でスキャン
• 100列中10列だけにクエリ発行→スキャンするデータ量は
10%だけ
• 行グループ単位でスキャン
• 100万行中1万行だけにクエリ発...
40 © Cloudera, Inc. All rights reserved.
• Parquetは列単位で格納しているので、
類似のデータであることを前提とした
様々なエンコーディングが可能
• デルタエンコーディング
• 前の行の値との差...
41 © Cloudera, Inc. All rights reserved.
• 対象データが全て集まってからでないとParquet形式に変換できない
• 1日分のログデータを変換するのであれば、1日待ってからでないと変換不可
• つまり、...
© Cloudera, Inc. All rights reserved.
パーティション
43 © Cloudera, Inc. All rights reserved.
• Impalaにおけるデータの水平分割の方法は3つ
• ブロック単位
• ファイル単位
• パーティション単位
• パーティションとは、ある条件によって分類され...
44 © Cloudera, Inc. All rights reserved.
パーティションの有無によるスキャンの違い
SELECT * FROM order WHERE date=‘2018-01-01’ というクエリを例に取ると…
パー...
45 © Cloudera, Inc. All rights reserved.
クエリプロファイルから見るパーティションの効果
クエリプロファイル上の実行計画によって算出されたHDFSのスキャン
| 02:SCAN HDFS [<テーブル名>...
46 © Cloudera, Inc. All rights reserved.
• パーティション数はテーブルあたり10万が限度
• パーティション数が多いほど…
• メタデータが肥大化する
• Impalaデーモンのメモリのオーバーヘッドの...
47 © Cloudera, Inc. All rights reserved.
• 時間単位をきちんと把握する
• 1年 = 12ヶ月 = 365日 = 8760 時間
• 今どきのデータ基盤はデータの10年保持は当然のように想定される
• ...
48 © Cloudera, Inc. All rights reserved.
• 小売業の売上データ
• 第一パーティション: 日単位
• 第二パーティション: 店舗グループ単位
• 例えば、東北・北海道、関東、中部・北陸、近畿、中国・四国...
49 © Cloudera, Inc. All rights reserved.
• CREATE TABLE ... PARTITIONED BY でパーティション列を指定
• ALTER TABLE ADD PARTITION でパーティシ...
50 © Cloudera, Inc. All rights reserved.
• INSERT INTO ... PARTITION(year, month) SELECT ... とすれば、ソーステーブルのyear, month 列を
読...
© Cloudera, Inc. All rights reserved.
統計情報
52 © Cloudera, Inc. All rights reserved.
• 統計情報取得コマンド
• 以下の統計情報を収集する
• パーティション単位の行数
• カラム毎のユニークな値の数 (# of distinct values ...
53 © Cloudera, Inc. All rights reserved.
• 重い
• codegenありで4000万セル/sec
• 40カラム、100億行のデータだと(4000億セル)、1000秒かかる
• codegenが効かない...
54 © Cloudera, Inc. All rights reserved.
• 重いからといって取らない選択肢は一切ない
• 問題はどのタイミングで取得するか
• 大原則はデータの追加やパーティションの追加とセットで実行
• COMPUT...
© Cloudera, Inc. All rights reserved.
まとめ
56 © Cloudera, Inc. All rights reserved.
• クエリプロファイルをとってボトルネックを調査すること
• 適切なストレージエンジンやデータフォーマットを選ぶこと
• Parquetは推奨だがベストではない
...
57 © Cloudera, Inc. All rights reserved.
APPENDIXに書いてあること
• ストレージエンジン
• データフォーマット
• 圧縮アルゴリズム
• ストレージデバイス
• ScannerとIOManag...
58 © Cloudera, Inc. All rights reserved.
Welcome to the Data Age
〜データ駆動型企業への第一歩〜
2018年11月6日(火)
虎ノ門ヒルズフォーラム
www.clouderawor...
59 © Cloudera, Inc. All rights reserved.
• Hadoopはどのように動くのか─並列・分散システム技術から読み解くHadoop処理系の設計と実装
• https://gihyo.jp/admin/seri...
THANK YOU
© Cloudera, Inc. All rights reserved.
APPENDIX
© Cloudera, Inc. All rights reserved.
Impala実行計画とクエリプロファイル(完全版)
63 © Cloudera, Inc. All rights reserved.
• クエリの実行計画を確認可能
• EXPLAIN_LEVEL クエリオプションでより詳細な情報を出力可能
• SET EXPLAIN_LEVEL=<N>
• 1...
64 © Cloudera, Inc. All rights reserved.
• 実行したクエリのプロファイルの概要だけを出力
• EXPLAINと違い、クエリの実行直後でないと実
行不可
• 通常は完全なプロファイルを使うことが多く、
S...
65 © Cloudera, Inc. All rights reserved.
• 実行したクエリの完全なプロファイルを出力
• SUMMARYと同様、クエリを実行直後にPROFILEを実行
• 全Impalaデーモンのあらゆるメトリクスを出...
© Cloudera, Inc. All rights reserved.
ストレージエンジン
67 © Cloudera, Inc. All rights reserved.
Impalaの対応ストレージエンジン一覧
ストレージ
エンジン
オンプレorクラウド DAS (ノード直結) or NAS
(ネットワーク越し )
スキャン適正 ...
68 © Cloudera, Inc. All rights reserved.
• どっちでもいいです
• クラウド上でもスループット出せるストレージデバイスは一通り揃ってる
• データフォーマットの設計等でIOの量自体を減らせば問題ない
オ...
69 © Cloudera, Inc. All rights reserved.
• 性能だけ見ればDASがベターだが昔ほど極端な優位性はない
• 理由はオンプレorクラウドと同じで、ストレージIOを減らせば問題になりにくい
• NASとの間の...
70 © Cloudera, Inc. All rights reserved.
• 分析データは二種類
• ファクト: 通常データは追加のみ。データ量は多い
• ディメンション: 挿入や更新が発生する。データ量はファクトよりも少ない
• スト...
© Cloudera, Inc. All rights reserved.
データフォーマット
72 © Cloudera, Inc. All rights reserved.
• データフォーマットによって、コストと性能が大きく変わる
• 圧縮率: 100ノードクラスタで1%圧縮できれば1ノード分のコスト削減になる
• スキャン効率: ...
73 © Cloudera, Inc. All rights reserved.
データフォーマット一覧
データフォーマット/ ストレージ Impala対応 追記 挿入 更新 用途 保存期間(一例)
テキスト
CSV、XML、JSONなど
CS...
74 © Cloudera, Inc. All rights reserved.
• 例: Webログ、サーバログ、CSVファイル、Eメール
• 長所
• 取扱いが非常に簡単
• 人間が読める
• 短所
• データサイズが非常に大きい→圧縮必須...
75 © Cloudera, Inc. All rights reserved.
• 例: xml, json
• 長所
• 取扱いが非常に簡単
• スキーマを保持できる
• 人間が読める
• 短所
• Hadoopビルトインの入力フォーマット...
76 © Cloudera, Inc. All rights reserved.
• 例: 画像、動画、特殊なフォーマットのデータ
• 取り扱うために独自のReader/Writerを開発する必要あり
• Hadoopでバイナリを扱う場合、以下...
77 © Cloudera, Inc. All rights reserved.
• 最も標準的なHadoopのフォーマット。Impalaのサポート対象
• バイナリのキーバリューペアでデータを格納する
• 長所:
• ほぼ全てのHadoopエ...
78 © Cloudera, Inc. All rights reserved.
• 言語中立なデータシリアライズシステム
• インタフェース定義言語(IDL)を使ってインタフェースを定義して、異なる言語間でデータを扱えるようにする。コード生成...
79 © Cloudera, Inc. All rights reserved.
• テーブルのような形式で活用可能なKVS
• デフォルトで10KB/セル、MOBモードで10MB/セルまでのデータを格納可能
• テーブル定義は列ファミリのみで...
80 © Cloudera, Inc. All rights reserved.
• Parquetと同様、列指向でデータを格納
するため、圧縮率が高く、分析クエリに
対して高速
• しかも、更新・追記が可能
• HDFSやS3とは別にクラスタ...
81 © Cloudera, Inc. All rights reserved.
• 基本はParquetかKuduを選択
• Parquetを使う場合は以下の点に注意
• データソースのフォーマットの選定は別途必要(CSV、JSON、Sequ...
© Cloudera, Inc. All rights reserved.
圧縮アルゴリズム
83 © Cloudera, Inc. All rights reserved.
• 注目すべき指標は2つ
• 圧縮率
• 圧縮率が高いと、ストレージ効率を向上させ、ネットワークIOを削減できる
• 圧縮・展開速度
• 圧縮・展開速度が速いと、...
84 © Cloudera, Inc. All rights reserved.
圧縮アルゴリズム一覧
圧縮アルゴリズム 圧縮・展開速度 圧縮率 備考
lzo 速い 普通 ライセンスがGPLのためHadoopとは別にインストー
ルする必要あり
...
© Cloudera, Inc. All rights reserved.
ストレージデバイス
86 © Cloudera, Inc. All rights reserved.
• Hadoopエコシステムの大原則: 容量のコストパフォーマンスが高いものを選ぶ
• HDFS
• 2018年現在もHDDがまだ一番コスパが高い
• 昔ほど差は...
87 © Cloudera, Inc. All rights reserved.
• インスタンスストレージ
• リファレンスアーキテクチャ上の推奨デバイス
• 物理デバイスと同じ性能が出るが、揮発性があるのでインスタンスが死ぬとデータが飛ぶ
...
88 © Cloudera, Inc. All rights reserved.
• プレミアムストレージ
• 性能は高いが値段も高い
• ADLSを使うべし
• Azure Data Lake Store (ADLS)
• 性能とコスパがいい...
© Cloudera, Inc. All rights reserved.
ScannerとIOManager
90 © Cloudera, Inc. All rights reserved.
• Scanner
• クエリがデータをスキャンする責務を持つ
• クエリ単位でCPUコア数分のスレッド を生成
• NUM_SCANNER_THREADS クエ...
91 © Cloudera, Inc. All rights reserved.
IO Manager
• Scannerスレッドの読み込み単位 = スキャンレ
ンジ
• 通常、1スキャンレンジ = 1 HDFSブロック
• IO Manage...
© Cloudera, Inc. All rights reserved.
ファイルサイズチューニング
93 © Cloudera, Inc. All rights reserved.
• デバイスを遊ばせず、なおかつ忙しくさせすぎないことが基本
• ファイルサイズは重要
• ファイルサイズが小さすぎ: Hiveのメタデータが肥大化したり、ストレ...
© Cloudera, Inc. All rights reserved.
メモリチューニング
95 © Cloudera, Inc. All rights reserved.
• 本スライドで説明する項目
• ハッシュJOIN
• メタデータ(クエリ間で共有)
• 本スライドで説明しない項目
• GROUP BY
• Parquet書き...
© Cloudera, Inc. All rights reserved.
JOINと統計情報
97 © Cloudera, Inc. All rights reserved.
• JOINは二種類
• ブロードキャストJOIN
• パーティションJOIN
• JOINはImpalaのネットワークIOとメモリ消費の大半の要因
• 適切なJ...
98 © Cloudera, Inc. All rights reserved.
Impalaデーモン
ストレージ
メモリ領域
テーブルA-1
テーブル
B-1
テーブルB
Impalaデーモン
ストレージ
テーブルA-2
テーブル
B-2
メ...
99 © Cloudera, Inc. All rights reserved.
Impalaデーモン
ストレージ
メモリ領域
テーブルA-1
テーブル
B-1
テーブルB-1’
Impalaデーモン
ストレージ
テーブルA-2
テーブル
B-...
© Cloudera, Inc. All rights reserved.
メタデータ
101 © Cloudera, Inc. All rights reserved.
メモリ上のメタデータのサイズ =
T * 5.00 KB
+ P * 2.00 KB
+ F * 0.75 KB
+ B * 0.30 KB
+ Σ(k=1, ...
102 © Cloudera, Inc. All rights reserved.
• 起動時
• CatalogデーモンがHiveメタストアサーバからロードし、全てのImpalaデーモンにブロードキャストす
る
• ImpalaがDDLを発行...
© Cloudera, Inc. All rights reserved.
マルチテナントとアドミッションコントロール
104 © Cloudera, Inc. All rights reserved.
• デフォルトではクエリ毎のリソース制限
はない
• 特定のクエリがリソースを使い潰すと他
のクエリが実行できない
• ある程度同時実行数が増えたらリソー
ス管...
105 © Cloudera, Inc. All rights reserved.
• リソースプール毎に、クエリの数とメモリ
量を制御する機能
• 以下の項目を設定可能
• 同時実行クエリ数
• キューイング可能クエリ数
• 割当てメモリ
ア...
106 © Cloudera, Inc. All rights reserved.
• バッチとアドホックで分ける
• バッチ: 並列度少ない、メモリ消費量多い
• 通常は並列度1
• アドホック: 並列度多い、メモリ消費量少ない
• 並列度は...
107 © Cloudera, Inc. All rights reserved.
• リソース管理はソフトリミット
• Statestoreデーモンを通じて利用状況が一定間隔で各Impalaデーモンに共有される
• デフォルトは500ms
•...
© Cloudera, Inc. All rights reserved.
スキーマデザイン
109 © Cloudera, Inc. All rights reserved.
• 文字列(STRING)は可能な限り使わないこと
• メモリ消費多い、ストレージ消費多い、計算が遅くなる(数値型の1/5)
• HBaseの行キーだけは例外的...
110 © Cloudera, Inc. All rights reserved.
• TIMESTAMP と日付
• 日付を表すカラム: TIMESTAMP型を使う
• パーティション列として日付を使う: INTを使う(例: ‘2018010...
111 © Cloudera, Inc. All rights reserved.
• カラム数
• ハードリミットはないが、概ね2,000が限度と思っておくべき
• パーティション数
• こちらもハードリミットはないが、100,000 / テ...
© Cloudera, Inc. All rights reserved.
ハードウェア選定(ディスク以外)
113 © Cloudera, Inc. All rights reserved.
• 前述の通り、1CPUコア = 1スキャナースレッド
• ここでいうコアは仮想的なコア数で、通常ハイパースレッディングが有効化されている場合は物理コアを2倍し...
114 © Cloudera, Inc. All rights reserved.
• 推奨は128GB / Impala ノード以上。256GBはほしい
• あくまでImpalaに割り当てるメモリなので、ハード自体にはさらに積む必要があること...
115 © Cloudera, Inc. All rights reserved.
• 最低10Gを用意すること
• ボンディング等でより太い帯域を確保できるならそれがベスト
ネットワーク選定
© Cloudera, Inc. All rights reserved.
クライアントとコーディネータノード
117 © Cloudera, Inc. All rights reserved.
• SELECT文を実行する場合、最終的には結果はクライアント
に返る
• よって、可能な限り最終結果を小さくすることが重要
• 以下の点に注意してクエリを作る...
118 © Cloudera, Inc. All rights reserved.
• コーディネータノードの仕事は多い
• クライアントからクエリを受け取る
• 実行計画を立てる
• 他のImpalaノードに指示を出す
• 他のImpalaノ...
119 © Cloudera, Inc. All rights reserved.
• Impalaにクエリを投げる際は可能な限
り前段にロードバランサを設置する
ロードバランサによるコーディネータノードの負荷分散
クラスタ
ロードバランサ
I...
120 © Cloudera, Inc. All rights reserved.
• コーディネータ専用ノードを設置することで、Impalaを擬似的なマスター・ワー
カー型アーキテクチャに変更可能
• コーディネータ専用ノードは、他のコーディ...
© Cloudera, Inc. All rights reserved.
ベンチマーク取得の基本
122 © Cloudera, Inc. All rights reserved.
• 追試できる状態で情報公開すること
• サーバスペック、データセット、クエリセット、ソフトウェアバージョンなど
• 追試不可能なベンチマーク結果は信用できない...
123 © Cloudera, Inc. All rights reserved.
• https://github.com/cloudera/impala-tpcds-kit
• Impalaに対して簡単にTPC-DSを実行可能
• クラスタ...
Próxima SlideShare
Cargando en…5
×

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

DB Tech Showcase 2018 で発表した、Impalaパフォーマンスチューニングのスライドです。

https://www.db-tech-showcase.com/dbts/tokyo

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

  1. 1. Apache Impala パフォーマンスチューニング
  2. 2. 2 © Cloudera, Inc. All rights reserved. 嶋内 翔 (しまうち しょう) テクニカルエバンジェリスト 兼シニアセールスエンジニア お客様にとって最適なデータ分析基盤の提案をする仕事をして います 主な担当業種: 金融業界 主な専門分野: 分析データベース 略歴 2006年、NEC入社。OSS推進センターでOSSの基盤についての 基礎を学ぶ。 2011年、Cloudera入社。サポートエンジニアとして、日本のお 客様の技術問い合わせに回答していく傍ら、Hadoopの啓蒙活 動に務める。 2015年から現職。 自己紹介
  3. 3. 3 © Cloudera, Inc. All rights reserved. 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
  4. 4. 4 © Cloudera, Inc. All rights reserved. Cloudera Enterprise あらゆるデータを蓄積し、活用するための最新のデータレイク基盤 クラウドストレージ (Amazon S3 / Microsoft ADLS) オンプレミス分散ストレージ (Hadoop / Kudu) IoTセンサー データソース サーバー ログ RDBMS ファイル 定型レポート ダッシュボード セルフサービスBI 機械学習システム リアルタイムBI 全文検索システム NoSQL バッチ処理 ストリーム処理 ETL データ サイエンス データ ウェアハウス
  5. 5. 5 © Cloudera, Inc. All rights reserved. • Impala概要 • Impalaパフォーマンスチューニングの基本 • 計測における主要確認項目 • ストレージIOチューニング • Parquet • パーティション • 統計情報 目次 APPENDIXにより詳しい話が書いています
  6. 6. 6 © Cloudera, Inc. All rights reserved. • Impalaを高速化したい、性能を引き出したいという人向けのスライドです • 以下の内容については触れません • Impalaの事例 • Impalaの他製品との比較 • Impalaの機能紹介 • 前提知識 • Hadoopについての基本的な知識 • サーバリソース(CPU、メモリ、ネットワークIO、ストレージIO)についての基本的な知識 • Impalaを始めとしたSQL-on-Hadoopについての基本的な知識 • OLAPについての基本的な知識 このスライドについて
  7. 7. © Cloudera, Inc. All rights reserved. Impala概要
  8. 8. 8 © Cloudera, Inc. All rights reserved. 大規模データに特化した 分析用途の 分散 クエリエンジン • Apache Foundationトップレベルプロ ジェクトのOSS • C++ / Java • ベータ版リリースは2012年 • 2018年9月現在の最新版は3.0.0 • http://impala.apache.org/ Apache Impala
  9. 9. 9 © Cloudera, Inc. All rights reserved. • 速い • 大規模データに対して速い • 分析クエリが速い • 同時並列で実行しても速い • スケールする • サーバやインスタンスを足せば リニアにスケール する • 数百ノード規模まで拡張可能 • 互換性が高い • 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
  10. 10. 10 © Cloudera, Inc. All rights reserved. • Impalaはマスターレスアーキテクチャ • Impalaは、各サーバやインスタンスを ノードとして、複数台で協調稼働する分 散アーキテクチャ • Impalaクライアントからクエリを受け取 るImpalaノードはコーディネータノードと 呼ぶ Impalaのアーキテクチャ(1) Impalaの基本アーキテクチャ クラスタ Impalaノード コーディネータノード クライアント Impalaノード Impalaノード
  11. 11. 11 © Cloudera, Inc. All rights reserved. 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ノード 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ノード 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ノード Impalaノード Impalaノード Impalaノード Impalaノード クライアント 毎回これだけ書くと煩雑なので、以後の説明では 3ノードのみ記述する
  12. 12. 12 © Cloudera, Inc. All rights reserved. • Impalaデーモン • クラスタ内で複数動作し、計算処理を行うデー モン • コーディネータノード • クライアントからクエリを受け取り、分散処理 を制御するImpalaデーモン。 • 全てのImpalaデーモンはクエリを受け取った 時点でコーディネータノードとなる Impalaのアーキテクチャ(2) Impalaデーモン(impalad)とコーディネータノード クラスタ Impalaノード コーディネータノード クライアント Impalaノード Impalaノード Impalaデーモン Impalaデーモン Impalaデーモン
  13. 13. 13 © Cloudera, Inc. All rights reserved. • StateStoreデーモン • Impalaデーモンのヘルスチェックを行い、互 いの死活状態を共有する • StateStoreデーモンが存在していると、 Impalaデーモンがダウンしても他のImpala デーモンはそのことを検知できる • StateStoreがダウンしても、他のImpalaノード がダウンしない限りは業務継続可能。つまり1 ノードでもSPOFでないことに注意 Impalaのアーキテクチャ(3) StateStoreデーモン(statestored) クラスタ Impalaノード コーディネータノード クライアント Impalaノード Impalaノード Impalaデーモン Impalaデーモン Impalaデーモン StateStoreデーモン 互いの死活をチェック
  14. 14. 14 © Cloudera, Inc. All rights reserved. • Hiveメタストアサーバ • スキーマ情報を管理するサーバ • Hiveを始め、各種サービスと共通のスキーマを利 用可能 • Catalogデーモン • Impalaデーモンによるメタデータ変更を自動でリ レーする • Catalogデーモンがダウンしても業務継続可能 • SELECT文等は実行可能 • メタデータの変更を行っても 明示的にキャッシュを更新 すればいいだけ Impalaのアーキテクチャ(4) Catalogデーモン(catalogd) と Hive メタストア クラスタ Impalaノード コーディネータノード クライアント Impalaノード Impalaノード Impalaデーモン Impalaデーモン Impalaデーモン StateStoreデーモン Catalogデーモン Hive メタストアサーバ メタストアDBスキーマ情報の更新をリレー
  15. 15. 15 © Cloudera, Inc. All rights reserved. Impalaの動作の仕組み クラスタ Impalaノード コーディネータノード クライアント Impalaノード Impalaノード Impalaデーモン Impalaデーモン Impalaデーモン ストレージ ストレージ 1. クライアントはImpalaデーモンに 接続し、クエリを発行 2. コーディネータノードはクエリの 実行計画を立てる 3. コーディネータノードは各Impala デーモンに処理を依頼 4. Impalaデーモンはストレージの データをスキャンした後、ローカル で実行可能な計算処理を実施 5. JOIN等、必要があればノード間 でデータを転送し、さらに処理を継 続 6. コーディネータノードが結果を集 約して最終処理 7.結果をクライアントに返す
  16. 16. 16 © Cloudera, Inc. All rights reserved. Impalaはどこでリソースを使うのか クラスタ Impalaノード コーディネータノード クライアント Impalaノード Impalaノード Impalaデーモン Impalaデーモン Impalaデーモン ストレージ ストレージ 1. クライアントはImpalaデーモンに 接続し、クエリを発行 2. コーディネータノードはクエリの 実行計画を立てる 3. コーディネータノードは各Impala デーモンに処理を依頼 4. Impalaデーモンはストレージの データをスキャンした後、ローカル で実行可能な計算処理を実施 5. JOIN等、必要があればノード間 でデータを転送し、さらに処理を継 続 6. コーディネータノードが結果を集 約して最終処理 7.結果をクライアントに返す ネットワーク IO ディスクIO メモリ・CPU
  17. 17. 17 © Cloudera, Inc. All rights reserved. • Impalaはクエリエンジンのみ • ストレージエンジンは別 • 例: HDFS, S3など • 従来のRDBMSはクエリ+ストレージがセットになっているも のが大半 • Impalaのパフォーマンスチューニングの大半は ストレージエンジン周りであり、Impala固有の チューニングは多くない • つまり、このチューニングをきちんとやれば他のHadoopエ コシステムのチューニングにもなる • Spark • Hive 従来のRDBMSとの違い(1) ストレージとの疎結合性 クラスタ Impalaノード Impalaノード Impalaデーモン Impalaデーモン ストレージ ストレージ Impalaサービス 外部ストレージサービス Impalaとは別にストレージ選定 の必要あり
  18. 18. 18 © Cloudera, Inc. All rights reserved. • Impalaはメタデータ(スキーマ情報)とデータが疎結合 になっている • メタデータはHiveメタストアサーバで管理されている 従来のRDBMSとの違い(2)スキーマ情報とデータの疎結合性 クラスタ Impalaノード Impalaノード Impalaデーモン Impalaデーモン ストレージ ストレージ 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 テーブルとストレージ上の データのマッピング情報 (メタデータ)
  19. 19. 19 © Cloudera, Inc. All rights reserved. • Impalaは分散システム • データは水平分割されていて、各Impalaノードが別 個に分割したデータにアクセスを行う • JOIN等で必要に応じて、ノード間でデータが転送され る • チューニングのポイント • ストレージ: きれいに水平分割できるよう設計する必要が ある • ネットワーク: なるべくネットワーク転送を減らすようにする 必要がある 従来のRDBMSとの違い(3) 分散システム クラスタ Impalaノード Impalaノード Impalaデーモン Impalaデーモン ストレージ ストレージ 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 大きなテーブルは水平分割されている 個々のノードで独立して格納 ノード間通信で必要なデータを共有
  20. 20. 20 © Cloudera, Inc. All rights reserved. • RDBMS的なパフォーマンスチューニングのイメージ = SQLをいかに効率よく書くか • Impalaのパフォーマンスチューニング = アーキテクチャの見直しがメイン • SQLの改善は正しいアーキテクチャを作ってから • SQLの改善は(時間がないので)話しません • APPENDIXに書いてるのでそっちを読んでください 従来のRDBMSとの違い(4) パフォーマンスチューニング戦略
  21. 21. © Cloudera, Inc. All rights reserved. Impalaパフォーマンスチューニングの基本
  22. 22. 22 © Cloudera, Inc. All rights reserved. • 合理的な性能目標をもつこと • 無計画なチューニングはお金と時間の無駄 • 推測するな計測せよ • チューニングはボトルネックを特定してから パフォーマンスチューニングについての一般的な原則
  23. 23. 23 © Cloudera, Inc. All rights reserved. • クエリプロファイルを取得する • クエリの並列実行数を計測する • CPU、ストレージIO、ネットワークIO、メモリの利用状況を調べる 計測方法
  24. 24. 24 © Cloudera, Inc. All rights reserved. • 今日紹介する以下の4項目だけは必ず実施すること • Impalaのバージョンを最新版にする • 適切なストレージエンジンとデータフォーマットを選択する • 適切にパーティションを切る • 統計情報を取る この4つを改善するだけで全然違うはず これ以上に性能がほしい場合はちゃんと工数とってチューニングしてください APPENDIXに色々な手法や詳細が書いてるので、興味ある人はそちらを読んでください 主要なパフォーマンスチューニング項目
  25. 25. © Cloudera, Inc. All rights reserved. 計測における主要確認項目
  26. 26. 26 © Cloudera, Inc. All rights reserved. • クエリの実行計画を確認可能 • 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> と実行するだけ
  27. 27. 27 © Cloudera, Inc. All rights reserved. • 実行したクエリのプロファイルの概要だけを出力 • 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コマンドを実行
  28. 28. 28 © Cloudera, Inc. All rights reserved. • 実行したクエリの完全なプロファイルを出力 • 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と同様、実クエリを実行直 後にコマンドを叩く
  29. 29. 29 © Cloudera, Inc. All rights reserved. • Impalaはクエリ毎にメモリ空間が独立 • よってクエリの並列実行数はメモリ消費 に直結 • ユーザ数が多い場合は並列実行数を チェックすること Impalaの並列実行数の確認 Cloudera Managerによるクエリ実行数のチャート
  30. 30. 30 © Cloudera, Inc. All rights reserved. • クエリごとにどれだけリソースを消費し ているかを調べる • CPU、メモリ、ストレージIOのどこがボト ルネックかによって対策が変わる CPU、メモリ、ストレージIO CPU時間の多いクエリ メモリ消費の多いクエリ ストレージIOの多いクエリ (画像が潰れてて見えない) Cloudera Managerによるクエリ毎リソース消費のチャート 実行時間は同程度に遅くても 原因はバラバラ
  31. 31. © Cloudera, Inc. All rights reserved. Impalaのバージョンごとの性能改善
  32. 32. 32 © Cloudera, Inc. All rights reserved. • バージョンが上がるごとに確実に性能 改善されている • 古いバージョンでのチューニングはコス パが悪いので非推奨 • 可能な限り最新版を使うこと Impalaのバージョンごとの性能改善 Impalaのリリース毎の性能向上の推移 (高い方が高性能) 正規化した性能(%) 2年 間 で 10倍 2年間で3倍
  33. 33. © Cloudera, Inc. All rights reserved. ストレージIOチューニング
  34. 34. 34 © Cloudera, Inc. All rights reserved. • ストレージIOチューニングの戦略は2つ • ストレージIOを極力減らす • ストレージIOの性能を上げる • ストレージIOチューニングの方法は3つ • ストレージ層を最適化する • スキーマ設計(特にパーティション設計)を最適化する • クエリを最適化する ストレージIOチューニングの基本
  35. 35. 35 © Cloudera, Inc. All rights reserved. • スキャン • データを読み込むこと • フルスキャン • 全てのデータを読み込むこと • 部分スキャン • 一部のデータを読み込むこと • スループット • 単位時間あたりどれだけの量のデータを読み書きできるか。 今回一番重要な指標 • レイテンシ • アクセス時にどれだけ素早くレスポンスを返せるか • IOPS • 一秒あたりに処理可能なストレージアクセスの回数。 Impalaはランダムアクセス用途で使わないため、 今回は使いません ストレージ性能周りの基本用語
  36. 36. 36 © Cloudera, Inc. All rights reserved. • 大きく分けて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読んでね
  37. 37. © Cloudera, Inc. All rights reserved. Parquet
  38. 38. 38 © Cloudera, Inc. All rights reserved. • 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 行グループ 列チャンク 列チャンク 列チャンク
  39. 39. 39 © Cloudera, Inc. All rights reserved. • 列単位でスキャン • 100列中10列だけにクエリ発行→スキャンするデータ量は 10%だけ • 行グループ単位でスキャン • 100万行中1万行だけにクエリ発行→スキャンするデータ は1%だけ • フルスキャンに比べて遥かに少ないデータしか スキャンしない • 10% × 1% = 0.1% のデータに対してしかスキャンしない • 100GBの元データであれば100MBだけスキャン Parquetへのデータアクセスの仕組み 行グループ 列チャンク 列チャンク 列チャンク 行グループ 列チャンク 列チャンク 列チャンク 行グループ 列チャンク 列チャンク 列チャンク 行グループ 列チャンク 列チャンク 列チャンク 行グループ 列チャンク 列チャンク 列チャンク 行グループ 列チャンク 列チャンク 列チャンク 必要な行・列しかスキャンしない
  40. 40. 40 © Cloudera, Inc. All rights reserved. • Parquetは列単位で格納しているので、 類似のデータであることを前提とした 様々なエンコーディングが可能 • デルタエンコーディング • 前の行の値との差分を保存 • 辞書エンコーディング • ランレングスエンコーディング(RLE) • etc. エンコーディングによる効率的な圧縮 作成日(タイムスタンプ) Diff(作成日) 1442825158 (なし) 1442826100 942 1442827994 1894 1442828527 533 各64ビット 各11ビット 同じデータが重複していて冗長 差分だけ保存することでデータ圧縮 約1/6に圧縮 デルタエンコーディングの例 (イメージ。実際にはもっと複雑 )
  41. 41. 41 © Cloudera, Inc. All rights reserved. • 対象データが全て集まってからでないとParquet形式に変換できない • 1日分のログデータを変換するのであれば、1日待ってからでないと変換不可 • つまり、即座にデータ分析することはできない • 追記・更新不可のため、データの訂正が入ると全部作り直しになる • 訂正処理が頻繁に発生するデータの場合、再計算コストが無視できない • 追記・更新が必要な場合はKuduを使うこと • フルスキャンは他の行指向データよりも遅い • SELECT * FROM を頻繁に実行するのなら AvroやSequenceFile等の方が速い • 変換処理は必ずImpalaのINSERT INTO ... SELECT を使うこと • 圧倒的に効率がいい Parquetの注意事項
  42. 42. © Cloudera, Inc. All rights reserved. パーティション
  43. 43. 43 © Cloudera, Inc. All rights reserved. • Impalaにおけるデータの水平分割の方法は3つ • ブロック単位 • ファイル単位 • パーティション単位 • パーティションとは、ある条件によって分類され たファイル群をまとめるディレクトリのこと • 左の例では日付ごとに別パーティションにしている パーティション クラスタ Impalaノード Impalaノード Impalaデーモン Impalaデーモン ストレージ ストレージ 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 日付単位でパーティションを切る
  44. 44. 44 © Cloudera, Inc. All rights reserved. パーティションの有無によるスキャンの違い 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だけ
  45. 45. 45 © Cloudera, Inc. All rights reserved. クエリプロファイルから見るパーティションの効果 クエリプロファイル上の実行計画によって算出された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以下までスキャン量を削減できた テーブルの行数
  46. 46. 46 © Cloudera, Inc. All rights reserved. • パーティション数はテーブルあたり10万が限度 • パーティション数が多いほど… • メタデータが肥大化する • Impalaデーモンのメモリのオーバーヘッドの増大 • 起動時やメタデータ更新時に時間がかかる • クエリの実行計画作成に時間がかかる パーティションに関する注意事項
  47. 47. 47 © Cloudera, Inc. All rights reserved. • 時間単位をきちんと把握する • 1年 = 12ヶ月 = 365日 = 8760 時間 • 今どきのデータ基盤はデータの10年保持は当然のように想定される • つまり10年 = 120ヶ月 = 3650日 = 87600 時間 • ネストを考慮するなら 日単位や時間単位はなるべく選択しない方がいい • パーティションを増やしすぎてファイルサイズを小さくしすぎないようにすること • 各パーティションのデータは最低でも256MBは置くこと • WHERE文で常に(あるいはほぼ常に)使われるカラムだけをパーティション列にすること パーティション設計のポイント
  48. 48. 48 © Cloudera, Inc. All rights reserved. • 小売業の売上データ • 第一パーティション: 日単位 • 第二パーティション: 店舗グループ単位 • 例えば、東北・北海道、関東、中部・北陸、近畿、中国・四国、九州の6つに分割 • 10年保存 • パーティション総数は 365 * 10 * 6 = 21900 パーティションの設計例
  49. 49. 49 © Cloudera, Inc. All rights reserved. • CREATE TABLE ... PARTITIONED BY でパーティション列を指定 • ALTER TABLE ADD PARTITION でパーティションを作成 • INSERT INTO ... PARTITION(year=‘2018’, month=‘01‘) SELECT ... で該当パーティ ションにデータを追加 パーティションの作り方と使い方
  50. 50. 50 © Cloudera, Inc. All rights reserved. • INSERT INTO ... PARTITION(year, month) SELECT ... とすれば、ソーステーブルのyear, month 列を 読み取って動的にパーティションを選択してデータを挿入可能 • しかも、パーティションが存在しない場合は自動で作成 • つまりALTER TABLE ADD PARTITION が不要 • 個人的にはダイナミックパーティショニングは非推奨 • パーティション数とファイルサイズが管理できない • 大抵の場合、大量のパーティションと小さいファイルの山 となる • メモリ管理ができない • 特にParquetに変換する場合、全データを一度メモリに読み込んでから書き出そうとするので、 あっという間にOOMで死ぬ • パーティション管理は手を抜かずきちんとやってください ダイナミックパーティショニング
  51. 51. © Cloudera, Inc. All rights reserved. 統計情報
  52. 52. 52 © Cloudera, Inc. All rights reserved. • 統計情報取得コマンド • 以下の統計情報を収集する • パーティション単位の行数 • カラム毎のユニークな値の数 (# 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 で落ちるなど、いいことが一つもない
  53. 53. 53 © Cloudera, Inc. All rights reserved. • 重い • codegenありで4000万セル/sec • 40カラム、100億行のデータだと(4000億セル)、1000秒かかる • codegenが効かないカラムについては700万セル/sec • 例えばTIMESTAMP型やCHAR型はcodegenが効かない • COMPUTE INCREMENTAL STATS: 新規パーティションだけを対象に指定可能 • ただしスループットはCOMPUTE STATSの半分 • 全統計情報を取り直す場合はCOMPUTE STATSを使うこと COMPUTE STATS の注意事項
  54. 54. 54 © Cloudera, Inc. All rights reserved. • 重いからといって取らない選択肢は一切ない • 問題はどのタイミングで取得するか • 大原則はデータの追加やパーティションの追加とセットで実行 • COMPUTE STATS実行によりなんらかの問題が発生する場合のみ、ずらして実行 • よほどのことがない限り許容できない手段と思うべき • COMPUTE STATSを直後に実行しても問題ないように、データの追加タイミングを変えることをまず 検討すべき パフォーマンスの観点から考えるCOMPUTE STATS
  55. 55. © Cloudera, Inc. All rights reserved. まとめ
  56. 56. 56 © Cloudera, Inc. All rights reserved. • クエリプロファイルをとってボトルネックを調査すること • 適切なストレージエンジンやデータフォーマットを選ぶこと • Parquetは推奨だがベストではない • パーティションを使うこと • COMPUTE STATSを実行して統計情報を取得すること 今日話したこと
  57. 57. 57 © Cloudera, Inc. All rights reserved. APPENDIXに書いてあること • ストレージエンジン • データフォーマット • 圧縮アルゴリズム • ストレージデバイス • ScannerとIOManager • ファイルサイズチューニング • メモリチューニング • JOINと統計情報 • メタデータ • マルチテナントとアドミッションコントロール • スキーマデザイン • ハードウェア選定 • クライアントとコーディネータノード • ベンチマーク取得の基本 APPENDIXにも書いてないこと • メタデータの転送の流れ • ランタイムフィルター • LLVMとcodegen • クエリスケジューリング詳細 • KuduScanner • セキュアクラスタにおけるパフォーマンス • プロファイル詳細 • 実行計画詳細 • ケーススタディ • あと他にもたくさん 今日話していないこと APPENDIXが本編なので、ダウンロードして読んでください
  58. 58. 58 © Cloudera, Inc. All rights reserved. Welcome to the Data Age 〜データ駆動型企業への第一歩〜 2018年11月6日(火) 虎ノ門ヒルズフォーラム www.clouderaworldtokyo.com
  59. 59. 59 © Cloudera, Inc. All rights reserved. • 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 参考資料
  60. 60. THANK YOU
  61. 61. © Cloudera, Inc. All rights reserved. APPENDIX
  62. 62. © Cloudera, Inc. All rights reserved. Impala実行計画とクエリプロファイル(完全版)
  63. 63. 63 © Cloudera, Inc. All rights reserved. • クエリの実行計画を確認可能 • 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 | +----------------------------------------------------------+ 消費メモリの見積もり 過度な信用は禁物 スキャンを実行するノード 真っ先に確認すべき 読み込む対象のパーティション数とサイズ 実行計画レベルで無駄スキャンが発生していないかはここでチェック
  64. 64. 64 © Cloudera, Inc. All rights reserved. • 実行したクエリのプロファイルの概要だけを出力 • 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ノード まず真っ先にこのノードを確認すること 大抵の場合ここがボトルネックになってるはずで、その切り分けを最初に行うのが定石
  65. 65. 65 © Cloudera, Inc. All rights reserved. • 実行したクエリの完全なプロファイルを出力 • 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の場合はセッションを貼り続けるので、ページ遷移するか 次のクエリ実行までこの時間が伸びるので、ここは無視すること
  66. 66. © Cloudera, Inc. All rights reserved. ストレージエンジン
  67. 67. 67 © Cloudera, Inc. All rights reserved. Impalaの対応ストレージエンジン一覧 ストレージ エンジン オンプレorクラウド DAS (ノード直結) or NAS (ネットワーク越し ) スキャン適正 挿入・更新 データフォーマットの要 不要 型定義 HDFS オンプレ (デバイス層のクラウド化は可 能) DAS ◎ × 必要 -- (データフォーマット 依存) HBase オンプレ (下位ストレージエンジンに よってはクラウド可は可能 ) -- (下位ストレージエンジン に依存) × ◎ 不要 不要 Kudu オンプレ (デバイス層のクラウド化は可 能) DAS ◯ ◯ 不要 必要 EMC Isilon オンプレのみ NAS ◯ × 必要 -- (データフォーマット 依存) Amazon S3 クラウド NAS ◯ × 必要 -- (データフォーマット 依存) ADLS クラウド NAS ◯ × 必要 -- (データフォーマット 依存)
  68. 68. 68 © Cloudera, Inc. All rights reserved. • どっちでもいいです • クラウド上でもスループット出せるストレージデバイスは一通り揃ってる • データフォーマットの設計等でIOの量自体を減らせば問題ない オンプレかクラウドか?
  69. 69. 69 © Cloudera, Inc. All rights reserved. • 性能だけ見ればDASがベターだが昔ほど極端な優位性はない • 理由はオンプレorクラウドと同じで、ストレージIOを減らせば問題になりにくい • NASとの間のネットワークは最低でも10G前提。帯域大きければ大きいほどいい • 100ノード超の大規模クラスタだと、NASとの間のネットワークIOがさばききれないか もしれない • どうしても不安ならDASを検討してもいいが、その前に他のチューニングを全部やっ てからにすること DASかNASか?
  70. 70. 70 © Cloudera, Inc. All rights reserved. • 分析データは二種類 • ファクト: 通常データは追加のみ。データ量は多い • ディメンション: 挿入や更新が発生する。データ量はファクトよりも少ない • ストレージの選定はビジネスロジックやSLAに大きく依存 • 更新発生のたびにデータを総入れ替えしていいのならParquetのみでも問題なし • 詳細な選定方法は本スライドのスコープ外 • ユースケース毎に複数組み合わせるのが普通 • どうしたらいいかわからなければ、とりあえずスキャン適性高い方を選ぶ • 要するにHDFS、S3、ADLSなど スキャン適性と挿入・更新可否
  71. 71. © Cloudera, Inc. All rights reserved. データフォーマット
  72. 72. 72 © Cloudera, Inc. All rights reserved. • データフォーマットによって、コストと性能が大きく変わる • 圧縮率: 100ノードクラスタで1%圧縮できれば1ノード分のコスト削減になる • スキャン効率: 必要最低限のデータアクセスによりスキャン時間を大幅短縮可能 • スキーマ情報を組み込んでいるかも重要 • スキーマ情報あり • ポータビリティが高い(別ストレージに移行しやすい) • 外部システムからスキーマ情報込でクラスタへデータ投入が可能 データフォーマット 他のあらゆるパフォーマンスチューニングをやる前に、まずデータフォーマットの最適化を行うこと 圧倒的に費用対効果が大きい
  73. 73. 73 © Cloudera, Inc. All rights reserved. データフォーマット一覧 データフォーマット/ ストレージ Impala対応 追記 挿入 更新 用途 保存期間(一例) テキスト CSV、XML、JSONなど CSVのみ ×?(使い方次第) × × 生データのストレージエンジンへのアップロード。適切な フォーマットに変換の後削除 変換完了後1週間〜1ヶ月 バイナリデータ 画像や動画ファイルなど × × × × データの閲覧などにそのまま活用 ディープラーニングの学習用データ 永久保存 SequenceFile ◯ ◯ × × 生データの長期保存形式。バッチ処理などにはこのデー タを使う 単体でスキーマを持たない 長期保存or永久保存 Avro ◯ ◯ × × 生データの長期保存形式。バッチ処理などにはこのデー タを使う 単体でスキーマを持つ 長期保存or永久保存 (SequenceFileとどちらか一択でも 可) Parquet ◯ × × × BIツールなどによる分析 永久保存 HBase ◯ ◯ ◯ ◯ 小さい画像データ(サムネイル等) ユーザアプリケーションが参照するデータ 永久保存 Kudu ◯ ◯ ◯ ◯ 時系列データや分析データを格納 BIツールなどによる分析 特に、ホットデータを取り込んですぐに分析したい場合に 有効 長期保存 (コールドデータになったら Parquetに移行) 注: HBaseとKuduはストレージエンジンだが、これらは データフォーマットと同列に検討すべきなのでここに記載している
  74. 74. 74 © Cloudera, Inc. All rights reserved. • 例: Webログ、サーバログ、CSVファイル、Eメール • 長所 • 取扱いが非常に簡単 • 人間が読める • 短所 • データサイズが非常に大きい→圧縮必須 • 全てのデータは文字列として扱われるため、型変換が必須。よって速度は非常に遅い • 例: “123” は文字列→数値への変換が必要 • ImpalaはCSVをサポートしているが、遅いのでそのまま分析するのはおすすめしない テキストデータ
  75. 75. 75 © Cloudera, Inc. All rights reserved. • 例: xml, json • 長所 • 取扱いが非常に簡単 • スキーマを保持できる • 人間が読める • 短所 • Hadoopビルトインの入力フォーマットでは分割不可能 • 遅い • jsonのまま分析するのは本当に遅いので絶対にやめるべき • そのためImpalaはxmlやjsonサポートはしていない 構造化テキストデータ
  76. 76. 76 © Cloudera, Inc. All rights reserved. • 例: 画像、動画、特殊なフォーマットのデータ • 取り扱うために独自のReader/Writerを開発する必要あり • Hadoopでバイナリを扱う場合、以下の方針で保存しておく • 100KB以下: SequenceFile か HBase • 10MB以下: SequenceFile か HBase (MOBモード有効) • 128MB(またはHDFSのブロックサイズ)以下: SequenceFile • 128MB以上: そのままHDFSに保存 • 2018年現在、大量の画像データの主な用途は機械学習のデータソースであり、アンサンブル学習のためにランダムアクセスが必 須になることから、可能な限りHBaseに置くというのが定石 • ファイルサイズが大きい場合は頑張ってなんとかすること • Impalaで分析する場合はUDF書くか数値化されたデータ(類似スコア等)になるので画像を直接扱うことはほぼない バイナリデータ
  77. 77. 77 © Cloudera, Inc. All rights reserved. • 最も標準的なHadoopのフォーマット。Impalaのサポート対象 • バイナリのキーバリューペアでデータを格納する • 長所: • ほぼ全てのHadoopエコシステムに対応 • レコード・ブロック単位の圧縮により、分割不可の圧縮アルゴリズムを使ってもファイル分割が可能 • 行指向のため追記が可能 • 短所: • スキーマがない • 行指向のため分析クエリが遅い SequenceFile
  78. 78. 78 © Cloudera, Inc. All rights reserved. • 言語中立なデータシリアライズシステム • インタフェース定義言語(IDL)を使ってインタフェースを定義して、異なる言語間でデータを扱えるようにする。コード生成はオプショ ン • スキーマをファイルヘッダに埋め込むことが可能 • 長所 • ファイル自体にスキーマを保持可能 • MapReduceでの読書をネイティブサポート • 圧縮・分割もサポート • スキーマエボリューション (書き込み時のスキーマと読み込み時のスキーマの不一致の許容 )のサポート • 行指向のため追記が可能 • 短所 • 行指向のため分析クエリは遅い Avro
  79. 79. 79 © Cloudera, Inc. All rights reserved. • テーブルのような形式で活用可能なKVS • デフォルトで10KB/セル、MOBモードで10MB/セルまでのデータを格納可能 • テーブル定義は列ファミリのみでOK。列そのものは自由に追加可能 • データは下位ストレージエンジン(通常はHDFS)にSequenceFileの形式で保存されている • 長所 • 更新・追記が可能 • 単一行ルックアップが非常に高速 • データはHDFSに永続化されているため、スキャンのスループットは高い。よってバッチ処理などには比較的強い • 短所 • レンジスキャンのレイテンシが高いため分析クエリに不向き HBase
  80. 80. 80 © Cloudera, Inc. All rights reserved. • Parquetと同様、列指向でデータを格納 するため、圧縮率が高く、分析クエリに 対して高速 • しかも、更新・追記が可能 • HDFSやS3とは別にクラスタを立てる必 要があるので、コストがかかる • コールドデータはParquetに変換して他 のストレージに保存するのが無難 分析ストレージ: Kudu (クドゥ)
  81. 81. 81 © Cloudera, Inc. All rights reserved. • 基本はParquetかKuduを選択 • Parquetを使う場合は以下の点に注意 • データソースのフォーマットの選定は別途必要(CSV、JSON、SequenceFile、Avro) • 生データからの変換処理が必須 • 今から新規にデータを取り込むなら、圧縮形式はlz4推奨 • 既存のデータの圧縮形式を変更するほどではない • 他のデータフォーマット・ストレージエンジンは状況に応じて適宜選択 • テスト用途等、人間が読める形式にしておきたい→CSV • 別のアプリケーションからのランダムアクセスが必須で、分析クエリの実行速度は遅くてもいい→HBase • データソース側がスキーマを自由に指定してデータ投入したい→Avro, JSON 結局どれを選べばいいのか?
  82. 82. © Cloudera, Inc. All rights reserved. 圧縮アルゴリズム
  83. 83. 83 © Cloudera, Inc. All rights reserved. • 注目すべき指標は2つ • 圧縮率 • 圧縮率が高いと、ストレージ効率を向上させ、ネットワークIOを削減できる • 圧縮・展開速度 • 圧縮・展開速度が速いと、CPU効率を向上させることができる • 多くの場合、圧縮率と圧縮・展開速度はトレードオフ 圧縮アルゴリズム
  84. 84. 84 © Cloudera, Inc. All rights reserved. 圧縮アルゴリズム一覧 圧縮アルゴリズム 圧縮・展開速度 圧縮率 備考 lzo 速い 普通 ライセンスがGPLのためHadoopとは別にインストー ルする必要あり snappyが登場した今、積極的に選ぶ理由はない snappy 速い 普通 Parquetのデフォルト圧縮形式 Hadoopエコシステムのデファクトアルゴリズム gzip やや遅い 高い あらゆるシステムで使われている定番アルゴリズム bzip2 非常に遅い 非常に高い 非常に遅いので推奨しない lz4 速い 高い Kuduのデフォルト圧縮形式 Parquetも選ぶならこちらにした方がいいが、他の チューニングをやってからでいい zstd 速い(らしい) 高い(らしい) 新しめの圧縮アルゴリズム 2018年9月時点でClouderaは未サポート 使うなら自己責任で 現時点で新規に選ぶなら lz4 がベストで、将来的には (多分) zstd 別に snappy でも問題ないので、既存の snappy圧縮のファイルを全部コンバートするほどでもない その他のチューニングを先に済ませること 圧縮・展開速度(高いほど速い) 圧縮率(右に行くほど高い) ※ zstdは新しいアルゴリズムのため図には未記載
  85. 85. © Cloudera, Inc. All rights reserved. ストレージデバイス
  86. 86. 86 © Cloudera, Inc. All rights reserved. • Hadoopエコシステムの大原則: 容量のコストパフォーマンスが高いものを選ぶ • HDFS • 2018年現在もHDDがまだ一番コスパが高い • 昔ほど差はなくなってきているので、調達コスト次第ではSSDも選択肢としてはあり • HWベンダーの営業におねだりしてみよう • SATA / 7500rpmで十分、というのが教科書通りの推奨だが、調達の関係なのかSASしか見ない • Kudu • NVMeライブラリに対応しているので、フルNVMeだと凄まじい性能が出る • そして価格も凄まじいことになる • WALだけSSDにして他をHDDにする構成がコスパ的に現実的 HDD vs SSD vs NVMe
  87. 87. 87 © Cloudera, Inc. All rights reserved. • インスタンスストレージ • リファレンスアーキテクチャ上の推奨デバイス • 物理デバイスと同じ性能が出るが、揮発性があるのでインスタンスが死ぬとデータが飛ぶ • そのため、インスタンス起動時には S3等からデータのロードが必須だし、新規データを作成したときは S3への書き戻しが必須 • 使うなら参照専用と割り切った方が楽 • EBS • ここ数年でだいぶスループット上がったので使いやすくなった • データも揮発しないので管理がやや楽 • S3 • 初期コストがほぼかからない、ストレージエンジンの管理が不要という大きなメリットがある • 性能は上記2つに比べて劣るが、データロードが必要がないことを考えるとシステム全体では S3の方が短時間で処理が終わることも • INSERT時の中間データの書き込み先にローカルデバイスを使うようになったので圧倒的に使いやすくなった AWS
  88. 88. 88 © Cloudera, Inc. All rights reserved. • プレミアムストレージ • 性能は高いが値段も高い • ADLSを使うべし • Azure Data Lake Store (ADLS) • 性能とコスパがいい • 物理ディスクの数十%程度の性能が出るらしい • Impala を Azure で使うなら ADLS 一択 • Azureにはインスタンスストレージ相当のサービスは存在しない • Azure BLOB Storage • Impalaは非対応なので使わないこと MS Azure
  89. 89. © Cloudera, Inc. All rights reserved. ScannerとIOManager
  90. 90. 90 © Cloudera, Inc. All rights reserved. • 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コア数分 クエリ クエリ
  91. 91. 91 © Cloudera, Inc. All rights reserved. IO Manager • Scannerスレッドの読み込み単位 = スキャンレ ンジ • 通常、1スキャンレンジ = 1 HDFSブロック • IO Managerは、スキャンレンジ単位でスケ ジューリングし、生データを先読みする • Scannerはデータに対し、述語に基づいたフィル タ処理を行う スキャンレンジ デバイス1 スレッド1 スレッド2 Scanner スレッド1 スレッド2 スキャンノード スキャンレンジ ブロック デバイス2 ブロック スキャンレンジ スキャンレンジ スキャンレンジ 1スキャンレンジ = 1ブロック 生データを先読み 述語に基づき データをフィルタ
  92. 92. © Cloudera, Inc. All rights reserved. ファイルサイズチューニング
  93. 93. 93 © Cloudera, Inc. All rights reserved. • デバイスを遊ばせず、なおかつ忙しくさせすぎないことが基本 • ファイルサイズは重要 • ファイルサイズが小さすぎ: Hiveのメタデータが肥大化したり、ストレージエンジンへのリクエストが多 くなって重くなる • ファイルサイズが大きすぎ: 並列性が下がり、1スレッド・デバイスに負荷が偏る • Parquetであれば、1ブロックあたり256MBで作ると最適なケースが多い • Impala で INSERT INTO ... SELECT 文によってParquetファイルを生成する場合はデフォルトでこの 設定になっている スキャン仕様から考えるパフォーマンスチューニング
  94. 94. © Cloudera, Inc. All rights reserved. メモリチューニング
  95. 95. 95 © Cloudera, Inc. All rights reserved. • 本スライドで説明する項目 • ハッシュJOIN • メタデータ(クエリ間で共有) • 本スライドで説明しない項目 • GROUP BY • Parquet書き込みバッファ: パーティション毎256MB • IOバッファ(クエリ間で共有) • クエリ間で共有と書いていない項目は、すなわちクエリ単位でメモリ消費が発生するということに注意 • 10並列のクエリなら10倍消費(クエリにもよる) Impalaはどこでメモリを使うのか
  96. 96. © Cloudera, Inc. All rights reserved. JOINと統計情報
  97. 97. 97 © Cloudera, Inc. All rights reserved. • JOINは二種類 • ブロードキャストJOIN • パーティションJOIN • JOINはImpalaのネットワークIOとメモリ消費の大半の要因 • 適切なJOINの選択には統計情報の取得が必須 ImpalaのJOIN
  98. 98. 98 © Cloudera, Inc. All rights reserved. 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 スキャン
  99. 99. 99 © Cloudera, Inc. All rights reserved. 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’ シャッフル
  100. 100. © Cloudera, Inc. All rights reserved. メタデータ
  101. 101. 101 © Cloudera, Inc. All rights reserved. メモリ上のメタデータのサイズ = 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デーモンのメモリ オーバーヘッドになる メモリ上のメタデータのサイズ
  102. 102. 102 © Cloudera, Inc. All rights reserved. • 起動時 • CatalogデーモンがHiveメタストアサーバからロードし、全てのImpalaデーモンにブロードキャストす る • ImpalaがDDLを発行したとき • 差分をCatalogデーモンがブロードキャスト • COMPUTE STATSを発行したとき • 対象テーブルだけ • INVALIDATE METADATAを発行したとき • 対象テーブルだけ メタデータのロードタイミング
  103. 103. © Cloudera, Inc. All rights reserved. マルチテナントとアドミッションコントロール
  104. 104. 104 © Cloudera, Inc. All rights reserved. • デフォルトではクエリ毎のリソース制限 はない • 特定のクエリがリソースを使い潰すと他 のクエリが実行できない • ある程度同時実行数が増えたらリソー ス管理機能を使う リソース管理機能の必要性 Impalaクラスタ クエリ1 メモリ クエリ2 クエリ1がメモリを100%利用 クエリ2はメモリが 不足し実行不可
  105. 105. 105 © Cloudera, Inc. All rights reserved. • リソースプール毎に、クエリの数とメモリ 量を制御する機能 • 以下の項目を設定可能 • 同時実行クエリ数 • キューイング可能クエリ数 • 割当てメモリ アドミッションコントロール marketing 実行可能クエリ数: 10 メモリ量: 100GB キューイング可能クエリ数: 100 batch 実行可能クエリ数: 1 メモリ量: 1000GB キューイング可能クエリ数: 10
  106. 106. 106 © Cloudera, Inc. All rights reserved. • バッチとアドホックで分ける • バッチ: 並列度少ない、メモリ消費量多い • 通常は並列度1 • アドホック: 並列度多い、メモリ消費量少ない • 並列度は実環境の測定結果に依存 • リソースプールに割当てる合計メモリは 多少多くても問題ない • 全部使い切ることは稀 • 割当てメモリ量はクエリの実行結果を測 定して計算 • 机上での計算は不可能 • 1つのリソースプール内で最も多くメモリ を消費したクエリに注目 • 最大メモリ消費量 * 1.2 をリソースプールの割 当てメモリとする アドミッションコントロールのベストプラクティス
  107. 107. 107 © Cloudera, Inc. All rights reserved. • リソース管理はソフトリミット • Statestoreデーモンを通じて利用状況が一定間隔で各Impalaデーモンに共有される • デフォルトは500ms • つまり、500ms以内にメモリ許容限界を超えたクエリを同時に投げるとメモリがあふ れるリスクがあることを意味する • 巨大なクエリが同時に投げ込まれる事態をなるべく回避すること アドミッションコントロールの注意事項
  108. 108. © Cloudera, Inc. All rights reserved. スキーマデザイン
  109. 109. 109 © Cloudera, Inc. All rights reserved. • 文字列(STRING)は可能な限り使わないこと • メモリ消費多い、ストレージ消費多い、計算が遅くなる(数値型の1/5) • HBaseの行キーだけは例外的に文字列型推奨 • 数値型(INT, FLOAT, DOUBLE等)を可能な限り使うこと • BLOB/CLOB • 文字列型を使うこと • 文字列型の最大サイズ • 仕様上の制限はないが、1MBまでならいけるっぽい • それ以上にすると多分Impalaデーモンがクラッシュする • このデータがネットワークIOやメモリを消費する可能性を常に念頭に置いておくこと データ型(1) 文字列型
  110. 110. 110 © Cloudera, Inc. All rights reserved. • TIMESTAMP と日付 • 日付を表すカラム: TIMESTAMP型を使う • パーティション列として日付を使う: INTを使う(例: ‘20180101’ を INT とする) • DECIMALは必要がない限り使わないこと • パーティションキーには使えない • UDFの中で使えない • なるべく FLOAT / DOUBLE を使うこと データ型(2) TIMESTAMPとDECIMAL
  111. 111. 111 © Cloudera, Inc. All rights reserved. • カラム数 • ハードリミットはないが、概ね2,000が限度と思っておくべき • パーティション数 • こちらもハードリミットはないが、100,000 / テーブルくらいが限界 • どちらも大きければ大きいほどメタデータが肥大化し、以下の性能に影響を与える • メタデータの更新 • パーティションの追加 • 統計情報の更新 • メタデータの取得 テーブルの最大サイズ
  112. 112. © Cloudera, Inc. All rights reserved. ハードウェア選定(ディスク以外)
  113. 113. 113 © Cloudera, Inc. All rights reserved. • 前述の通り、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選定
  114. 114. 114 © Cloudera, Inc. All rights reserved. • 推奨は128GB / Impala ノード以上。256GBはほしい • あくまでImpalaに割り当てるメモリなので、ハード自体にはさらに積む必要があることに注意 • それ以下にする場合は本スライドのメモリチューニングを熟読してサイジングすること • 別に16GBとかでも動かないわけではないが、本番環境でここまでケチるくらいならそもそもImpalaの 採用を考え直した方がいい • 16GB * 8ノード(マスター含めたら11ノード)買うくらいならメモリ128GB積んだRDBMSの方が安いし速いはず • クラウド上の場合は別。低スペックインスタンスを一時的に横に並べてクエリを流したいケースはある • 単なるバッチ的な操作で、CPUコア数とIOスレッドだけを稼ぎたい場合など メモリ選定
  115. 115. 115 © Cloudera, Inc. All rights reserved. • 最低10Gを用意すること • ボンディング等でより太い帯域を確保できるならそれがベスト ネットワーク選定
  116. 116. © Cloudera, Inc. All rights reserved. クライアントとコーディネータノード
  117. 117. 117 © Cloudera, Inc. All rights reserved. • SELECT文を実行する場合、最終的には結果はクライアント に返る • よって、可能な限り最終結果を小さくすることが重要 • 以下の点に注意してクエリを作る • 必ずLIMITをつける • 可能な限りWHERE句でフィルタする • 可能な限りSUMやMAXなどの集約関数を使う • impala-shellを使う場合はさらに以下の点に注意 • 結果が大きいのであればファイルに リダイレクトする(画面に出 力しない) • ストレージ側に保存するのなら INSERT INTOを使う Impalaクライアントアクセスの最適化 クラスタ Impalaノード コーディネータノード クライアント Impalaノード Impalaノード Impalaデーモン Impalaデーモン Impalaデーモン
  118. 118. 118 © Cloudera, Inc. All rights reserved. • コーディネータノードの仕事は多い • クライアントからクエリを受け取る • 実行計画を立てる • 他のImpalaノードに指示を出す • 他のImpalaノードから結果を受け取る • 最終計算を行う • 最終結果をクライアントに返す • 自分自身も通常のImpalaノードと同様、計算処理を 行うことに注意 • 左図のように1台のImpalaノードだけにクエリを投げ るとボトルネックになってしまう Impalaコーディネータノード クラスタ Impalaノード コーディネータノード クライアント Impalaノード Impalaノード Impalaデーモン Impalaデーモン Impalaデーモン クライアント クライアント クライアント 負荷が集中しすぎ
  119. 119. 119 © Cloudera, Inc. All rights reserved. • Impalaにクエリを投げる際は可能な限 り前段にロードバランサを設置する ロードバランサによるコーディネータノードの負荷分散 クラスタ ロードバランサ Impalaノード Impalaノード Impalaノード Impalaノード クライアント クライアント クライアント クライアント
  120. 120. 120 © Cloudera, Inc. All rights reserved. • コーディネータ専用ノードを設置することで、Impalaを擬似的なマスター・ワー カー型アーキテクチャに変更可能 • コーディネータ専用ノードは、他のコーディネータノードからのクエリを受け付け ない • 計算処理を全く行わないわけではないので、他のImpalaノードと同様にワー カーノード側に置いておく必要がある • 1コーディネータ専用ノードあたり、50 Impalaノード程度をカバー可能 • CPU利用率が80%超えたら専用ノードを増やす • HA化するならさらに追加で1ノード以上作成しておく • 起動オプション • is_executor=false : 他コーディネータからのクエリの受付を禁止する。初期構築時に コーディネータ専用ノードを作るときに有効 • is_coordinator=false : クライアントからのクエリの受付を禁止する。クラスタ増設時の Impalaデーモンの初期設定に有効 コーディネータ専用ノード クラスタ Impalaノード コーディネータ専用ノード クライアント Impalaノード Impalaノード Impalaデーモン Impalaデーモン Impalaデーモン
  121. 121. © Cloudera, Inc. All rights reserved. ベンチマーク取得の基本
  122. 122. 122 © Cloudera, Inc. All rights reserved. • 追試できる状態で情報公開すること • サーバスペック、データセット、クエリセット、ソフトウェアバージョンなど • 追試不可能なベンチマーク結果は信用できない • 業界標準のベンチマークテストを使うこと • 分析クエリならTPC-H か TPC-DS。Impalaの場合はTPC-DSが一般的 • マイクロベンチマークは本当にやめてください • その上で、社内での独自のデータセット、クエリセットを用意すること • 最終的には自社で使うクエリが速くなることが重要 • TPC-* はあくまで基礎検証における参考値 ベンチマーク取得の原則
  123. 123. 123 © Cloudera, Inc. All rights reserved. • https://github.com/cloudera/impala-tpcds-kit • Impalaに対して簡単にTPC-DSを実行可能 • クラスタ全体の基本性能を見たければこれを実行するのが一番確実 Impala TPC-DS Toolkit

×