Hiveを高速化するLLAP

Hiveを高速化するLLAP ヤフー株式会社 小澤 祐也 @̲̲john̲smith̲̲

About me • 小澤 祐也( @̲̲john̲smith̲̲ ) • ヤフー株式会社 • データ&サイエンスソリューション統括本部 • データインフラ本部 開発2部 OSS開発 ←平常時の自己紹介

アジェンダ Hiveの復習 – MR, Tez, Spark – Hiveの限界 LLAP(Live Long and Process)の紹介 – – – – LLAPとは LLAPの特徴と動作 LLAP vs Spark SQL 実行速度 LLAPの今後

アジェンダ Hiveの復習 – MR, Tez, Spark – Hiveの限界 LLAP(Live Long and Process)の紹介 – – – – LLAPとは LLAPの特徴と動作 LLAP vs Spark SQL 実行速度 LLAPの今後

LLAPその前に.. 少しだけHiveについて復習 • 実行エンジン • 利用シーン

Hiveの実行エンジン • MapReduce • 今でもこれを想定する人は多い • YARN時代においてはHadoop1系に名残と言ってもよい • Tez • Sparkのライバル的存在として語られることも多い • YARNでしかうごかないがHiveやPigの実行エンジンとして欠かせ ない • Spark • Hive on Spark • Not Spark SQL • かつてSharkというものもあった…

Hiveの限界 • インタラクティブな処理には使えない • SQL likeな記述でMRジョブを実行するために作られた • レイテンシ < スループットな設計 • インタラクティブを求めるなら別なアーキテクチャを選択すべき？ • HiveはETLまで、分析はR, Python, Sparkなどを使う • 元データが大きすぎる場合など • とはいえデータの切り出し方は試行錯誤したいので高速化されると便利

Hiveの限界 とはいえ最近のHiveは速い • 魔法のおまじない(※違います) • SET hive.execution.engine=tez; • カラムナ型のファイルフォーマットをサポート • ORC(やParquet) • 必要なDisk I/Oが減らせる • CBO(Cost Based Optimizer) • データの統計情報を使ったオプティマイザ • ルールベースより効率の良い最適化がされること請け合い • Vectorization • SIMD命令を利用した一括処理

アジェンダ Hiveの復習 – MR, Tez, Spark – Hiveの限界 LLAP(Live Long and Process)の紹介 – – – – LLAPとは LLAPの特徴と動作 LLAP vs Spark SQL 実行速度 LLAPの今後

LLAPとは バッチ処理では速くなったHiveをさらに高速化したい • 扱えるデータ量はそのままよりインタラクティブに！ Hive2.0からの新機能 LLAPの基本的な思想 • Daemon • Cache • Multi Thread, Pipeline

LLAP全体像 Container Queue LLAP Cache Executor Container Tez Job Executor CLIやHS2から Query発行 Container Queue Cache Container LLAP Tez Job Executor Executor Slider ※AMなどは省略

LLAP全体像 Container Queue LLAP Cache Executor Container Tez Job Executor CLIやHS2から Query発行 Container Queue Tez一部Vertexを Daemon化 Cache Container LLAP Tez Job Executor Executor Slider ※AMなどは省略

Daemon • Daemonの立ち上げによる起動コストの削減 • Containerの立ち上げにはJVM起動などのコストがかかる • Daemon化にはApache Sliderを利用 • • • • Hadoop上でDaemonとして起動し任意のプロセスを走らせる StormやMemcachedなどサンプル有 起動コンテナ数を動的に変更可能 Pigと同じくらい検索しづらい

Hybridな環境の実現 • TezのVertexをDaemon化するのがLLAP • LLAP自体は実行エンジンではない • Resource Manager上でもDaemonとジョブは別なものとして動 作 • LLAPの発想自体は他の実行エンジンでも実現可能 • TEZ-2003 • Vertexの一部にTezコンテナの外部サービスを利用 • Daemonとして立ち上げておいたコンテナを利用 • この仕組みを利用しているため現在はTezのみに対応 • Vertexの一部または全部の実行NodeでLLAPを利用 • Hiveのジョブ自体はLLAPの有無には依存しない • 必要に応じて通常のcontainerかllapかは選択可能

LLAPとmode LLAPによって新たに加わるmodeという概念 • 特定のVertexがどちらのmodeで動いているか • TezのジョブをCLIが視覚的にわかりやすい • modeという項目にcontainer/llapのどちらかが記載されている • DAG中のどのVertexにLLAPを使うか • hive.llap.execution.modeで設定されるmode • LLAP deamonで動くVertex, Tezコンテナで動くVertexの設定 • none/map/auto/allがある

ModeとDaemon LLAPを使わない Tezのみと同じ none M M M R すべてLLAPを利用 M R M R all M Mapタスクのみで LLAPを使う map auto Hiveの実行計画に 任せる M M R

ModeとDaemon LLAPを使わない Tezのみと同じ none M M none/map/all/auto DAG中のどのVertexに LLAPを使うかの設定 M R すべてLLAPを利用 M R M R all M Mapタスクのみで LLAPを使う map auto Hiveの実行計画に 任せる M M R

ModeとDaemon LLAPを使わない Tezのみと同じ none M M container/llap 各Vertexがどちらの modeで動いているか M R すべてLLAPを利用 M R M R all M Mapタスクのみで LLAPを使う map auto Hiveの実行計画に 任せる M M R

ModeとDaemon LLAPを使わない Tezのみと同じ none M M M R すべてLLAPを利用 M R M R all M Mapタスクのみで LLAPを使う map auto Hiveの実行計画に 任せる M M R

LLAP全体像 Container Queue LLAP Cache Executor Container Tez Job Executor CLIやHS2から Query発行 Container Queue Cache Container LLAP Tez Job Executor Executor Slider ※AMなどは省略

LLAP全体像 Container Queue LLAP Cache Executor Container Tez Job Executor CLIやHS2から Query発行 Container Queue Cache Container LLAP Tez Job Executor Executor Slider In-Memory Columnar Cache ※AMなどは省略

Cache LLAPのDaemon内でデータをcacheする • Columnar cache • In-memoryなcache機能 • データを行単位ではなく列単位でキャッシュ • ORCファイルにのみ対応 • Columnar型のデータフォーマット • インデックスを利用し必要な部分のみをキャッシュ

Cache LLAPのDaemon内でデータをcacheする • キャッシュアルゴリズム • FIFO, LRFU • DaemonのNodeごとにcacheを持つ • 中央集権的な仕組みはない • Node間での共有は行わない • Off-Heapの利用

LLAP全体像 Container Queue LLAP Cache Executor Container Tez Job Executor CLIやHS2から Query発行 Container Queue Cache Container LLAP Tez Job Executor Executor Slider ※AMなどは省略

LLAP全体像 Container Queue LLAP Cache Executor Container Tez Job Executor CLIやHS2から Query発行 Container Queue Cache Container LLAP Tez Job Executor Executor Multi Tread Pipeline Slider ※AMなどは省略

Multi Thread, Pipeline LLAPのDaemon内で複数のスレッドを起動 • 各スレッドがExecutorとして処理を実行 • 1デーモンあたりで複数の処理を実行可能 • Node数 * Executor数が実際に実行できる処理の並列数 • Queue • 一般的な実行待ち行列に対する扱い • 実行可能になったExecutorにアサインされる • Preemption • 長時間動きがない処理は一度諦める • Executorにアサインされたがなんらかの理由で処理を続けられないなど

Multi Thread, Pipeline Container LLAP Daemon Executor Executor Map 1 Reduce 3 Query Fragment Query Fragment Query Fragment Query Fragment Queue Map 2 Query Fragment Query Fragment Map 0 … Reduce 9 …

Multi Thread, Pipeline Container LLAP Daemon Executor Executor Map 1 Reduce 3 Query Fragment Query Fragment Query Fragment Query Fragment Queue Map 2 Query Fragment Query Fragment Map 0 … 一つのDaemonに 複数のThread Reduce 9 …

Multi Thread, Pipeline Container LLAP Daemon Executor Executor Queue Reduce 3 Query Fragment Query Query Fragment Fragment Query Fragment Map 2 Map 0 … Queueにある 次の処理を実行 Reduce 9 …

Multi Thread, Pipeline Preemptionによって 次の処理が先に実行され る Container LLAP Daemon Executor Executor Map 2 Map 1 Query Fragment Query Fragment Queue Query Fragment Query Reduce 3 Fragment Query Map 0 Fragment … Query Fragment Reduce 9 × …

改めてLLAP全体像 Container Queue LLAP Cache Executor Container Tez Job Executor CLIやHS2から Query発行 Container Queue Cache Container LLAP Tez Job Executor Executor Slider ※AMなどは省略

LLAP vs Spark SQL • LLAP固有の概念 • Daemon内共通で使えるcacheはSparkにはない • Tez vs Spark • データがメモリに乗り切らない場合はTezが有利 • 既存の資産の活用 • クエリの互換性 • HQLはSQL LikeだがSQLではない • 分析環境への繋ぎこみではSparkが有利 • SQLだけではETL以上の処理をやるのは難しい • R, Pythonでの分析環境との連携 • DataFrameAPIやMLlib, GraphX • ストリーム処理 • Spark Streaming • HiveもACIDやトランザクションに対応はしてる

LLAPの実行速度 • Hive on TezとLLAPの速度比較 • • • • LLAPを使うとどれくらい速くなるのか 3回同じ処理を実行しての平均速度 各クエリはシーケンシャルに実行 設定の変更などはなし

LLAPの実行速度 • TPC-DSの結果(一部抜粋) • ほとんどのqueryにおいてLLAPを利用した方がはやい Tez  vs  LLAP 200 180 160 140 120 100 80 60 40 20 0 tezAVG llapAVG

LLAPの実行速度 • その他、様々な条件でのパフォーマンステストを現在実施中 • • • • • • Daemon数 並列数 各種設定の変更による影響 キャッシュヒットの有無による影響 クエリごとの性質に依存した影響 etc.

アジェンダ Hiveの復習 – MR, Tez, Spark – Hiveの限界 LLAP(Live Long and Process)の紹介 – – – – LLAPとは LLAPの特徴と動作 LLAP vs Spark SQL 実行速度 LLAPの今後

LLAPの今後 実際にLLAPを使おうと思った際に課題として上がった点 • バグ周り • 出来たばかりの機能なのでこれから使われると色々出てくるかも • 最近もデッドロックするバグがあった[HIVE-12904] • セキュリティ周り • Kerberosには対応 • キャッシュされたデータの扱い • HS2からの接続(Daemonの実行ユーザとDoAsの設定) • Cacheの洗練, Locality • • • • • HDFS Localityは考慮してくれる cache現状では個々のNodeが個別に持っている どこのノードがどのデータをキャッシュしてるかの考慮はなし そもそもDaemonが立ち上がってるNodeにデータがない場合 Cacheアルゴリズムは適切か？ • タスクリストやWIPは[HIVE-7926]