Impala をベースとした高性能データウェアハウスの構築実践: 仮想データウェアハウス

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

​​https://ost..com​​

この記事では、主に、リソースのグループ化、水平拡張、混合グループ化、タイムシェアリング多重化など、NetEase Cloud Computing NDH が Impala に実装した仮想データ ウェアハウス機能を紹介します。クラスター リソースを柔軟に構成し、ノードの負荷を分散し、クエリの同時実行性を向上させ、ノード リソースを最大限に活用できます。

高性能な分析データ ウェアハウスでは、クエリをできるだけ早く完了するための優れた実行エンジンを備えることに加え、コンピューティング リソースや IO リソースの競合など、クエリ間の相互干渉によって発生するクエリ パフォーマンスの低下などの問題を回避することも必要です。前のセクションでは、Impala がリソース プールを通じてコン​​ピューティング リソースを管理できることについて説明しました。しかし、実際に使ってみると、リソースプールだけでは不十分で、同じコンピューティングノード上で異なるリソースプールがメモリリソースを競合するなどの問題が発生することがわかりました。

1. 基本概念

「仮想データ ウェアハウス」は、Snowflake の「仮想ウェアハウス」に由来し、略して VW と呼ばれます。仮想データ ウェアハウスは、必要に応じて水平方向および垂直方向にスケールアップおよびスケールダウンできます。これは効率的なリソース スケジューリング方法であり、ストレージとコンピューティングを分離した設計アーキテクチャの下でのコンピューティング リソースの弾力的なスケーリングの非常に優れた検証ケースです。次の図に示すように、Snowflake クラスターには、それぞれ BI ユーザーと ETL ユーザーにサービスを提供する 2 つの仮想データ ウェアハウスがあります。 BI 仮想データ ウェアハウスは、レポート クエリのピークと谷に対応するために、統一された水平方向の拡張および縮小モードを採用しています。 ETL は主にコンピューティング能力に焦点を当て、仮想データ ウェアハウスの仕様を変更するモードを採用しています。

NDH の Impala コンポーネントにも同様の機能があります。始める前に、Impala の実際の使用に基づいた 2 つの基本概念を紹介しましょう。 1 つ目は、Impala のコミュニティ バージョンにすでに存在する実行者グループです。次に、仮想データ ウェアハウスをサポートするために導入されたノード グループの概念があります。

実行者グループ

次の図は、CDP ドキュメント内の Impala 実行グループの概略図です。実行グループは、Impala のエラスティック スケーリングの基本単位です。ユーザーは実行グループの仕様 (XSMALL、SMALL、MEDIUM、または LARGE) を構成できます。自動スケーリングが有効になっている場合、CDP は指定された仕様に従って Impala Executor ノードの数を毎回拡大または縮小します。

実行グループは、Impala クラスターを水平方向にスケーリングする機能を提供します。ただし、これは Snowflake で説明されている仮想データ ウェアハウスとはまったく異なります。現在の導入では、実行グループはユーザーにとって透過的な概念です。ユーザーは、実行グループを使用して、Impala クラスターを、前述の BI や ETL などに使用されるさまざまな目的のコンピューティング ユニットに分割することはできません。そのため、NDH Impala ではノード グループの概念が導入されています。

ノードグループ

NDH Impala クラスターの impalad ノードは、ノード グループと呼ばれる複数の独立したグループに分割できます。ノード グループは、エグゼキュータ ノードまたはコーディネーター ノードのみで構成できます。

上図の Impala クラスターには 3 つのノード グループが含まれています。各ノード グループには、impalad 内に少なくとも 1 つのエグゼキュータ ノードが必要です。さらに、ノード グループから独立した 2 つのコーディネーター ノードが存在します。独立したコーディネーター ノードは、任意のノード グループ内のエグゼキュータにリクエストをルーティングできます。ノード グループ内のコーディネーターは、実行のためにこのグループ内のエグゼキューター ノードにリクエストを配布することしかできません。クエリ ルーティング ルールの違いに基づいて仮想データ ウェアハウスを実装する方法は 2 つあります。

2. 実装

NDH Impala は、Zookeeper アドレスに基づく静的構成ソリューションとセッション パラメータに基づく動的構成ソリューションの 2 つの仮想データ ウェアハウス実装をサポートしています。それぞれについて以下に説明します。

（１）静的構成

このソリューションは、異なるノード グループのコーディネーター ノードを異なる Zookeeper アドレスに登録します。 Hive JDBC クライアントは、異なる Zookeeper アドレスに接続することで、さまざまなビジネス グループのコーディネーターを取得し、接続して SQL 要求を発行できます。このようにして、各ノード グループには独自の 1 つ以上のコーディネーター ノードが存在し、これらのコーディネーター ノードは SQL によって生成された実行プランをグループ内のエグゼキューター ノードに送信して実行します。

上の図に示すクラスターには、グループ 1、グループ 2、グループ 3 の 3 つの仮想データ ウェアハウスがあります。これらは、同じ状態保存およびカタログ化され、同じデータ ウェアハウス メタデータを共有します。仮想データ ウェアハウス間の impalad リソースは物理的に分離されています。仮想データ ウェアハウスのコーディネーター ノードは、グループ内のエグゼキューター ノードにのみクエリを送信します。運用環境では、複数の仮想データ ウェアハウスを構成して、異なる種類のビジネスからのクエリ要求を受信することができます。これにより、異なるビジネスからのクエリはコンピューティング リソースの使用において互いに分離され、互いに影響を及ぼさなくなります。図では、グループ 1 はアドホック クエリに使用され、グループ 2 は BI レポートに使用され、グループ 3 は BI セルフサービス データ取得に使用されます。マルチクラスター アプローチと比較すると、マルチ仮想ウェアハウス アプローチでは必要なリソースが少なく、より柔軟な構成が可能です。

（２）ダイナミックルーティング

このソリューションは、セッション接続にクエリ オプション パラメータ request_group を追加します。 set request_group=xxx ステートメントを通じて、コーディネーターはクエリを指定されたグループに自動的にルーティングして実行します。 request_group のデフォルト値は default であり、対応する group_name のデフォルト値も default です。つまり、request_group が指定されていない場合、クエリは実行のためにデフォルト グループに送信されます。

このソリューションでは、コーディネーター ノードはパブリックであり、エグゼキューター ノードのみがグループ化されます。実装は、Snowflake の仮想データ ウェアハウスに似ています。次の図に示すように、パブリックコーディネーターは 2 人、グループは 3 つあります。デフォルト グループが存在しないため、デフォルト グループを grp1 として設定できます。パラメータを通じて動的に構成できます。 Zookeeper ベースのソリューションよりも柔軟性があります。ユーザーは必要に応じて、異なる仮想データ ウェアハウス間でクエリを自由に切り替えることができます。

上記の両方のソリューションが実装されました。 NDH の実稼働環境では通常、Hive JDBC を使用して Zookeeper に接続し、Impala にアクセスするため、前者の方法の方が互換性が高くなります。現在、この方法は主に仮想データ ウェアハウスをオンラインで展開するために使用されています。このセクションで紹介する仮想データ ウェアハウスの高度な機能も、主に前者を中心に展開されます。

3. 主な特徴

（１）水平展開

仮想データ ウェアハウス内の単一ノード グループのリソースと同時実行性がボトルネックに達した場合、グループにノードを追加するだけではクエリの同時実行性を効果的に高めることはできません。この場合、同じまたは類似の仕様を持つノード グループを仮想データ ウェアハウスに追加できます。新しいノード グループ内のコーディネーターの Zookeeper アドレスは、元のノード グループと同じになるように構成する必要があります。 Zookeeper でコーディネーター アドレスを選択する際の Hive JDBC のランダム性を利用することで、クエリ負荷を新しいノード グループと古いノード グループに分散できます。この方法により、クラスター内の同時クエリの数をほぼ直線的に増やすことができます。

上の図に示すように、Impala クラスターには 2 つの仮想データ ウェアハウスがあります。対応するノード グループは group1 と group3 であり、それらが実行する業務はビジネス BI レポートと ABTest シナリオです。 group1 が元のグループであり、3 つの impalad ノード (1 つのコーディネーターと 2 つのエグゼキューター) があるとします。新しいグループ group2 を追加します。このグループにも 3 つの impalad ノードがあり、group1 と同じ構成を使用して水平拡張を実現します。

（２）透明な拡大

NDH Impala は、各仮想データ ウェアハウスの負荷に応じて、仮想データ ウェアハウス ノード グループ内の impalad ノードの数をオンラインで増減できるため、グループ間のリソースの動的なスケーリングを実現します。 Impala が提供する正常なシャットダウン方法を使用してノード グループ内の impalad プロセスをシャットダウンすると、新しいクエリ要求は impalad ノードに送信されなくなり、そのノードで実行されているクエリ フラグメントが完了した後にノードがシャットダウンされます。したがって、実行中のクエリは異常終了せず、ユーザーに影響はありません。実稼働環境では、複数の仮想データ ウェアハウスを備えた NDH Impala クラスターは、履歴クエリ パターンを分析し、グループ内の impalad ノードのシステム負荷を組み合わせることで、仮想データ ウェアハウス間のノード数を動的に増減し、各ノードのリソースをより有効に活用できます。

NetEase Cloud Music を例にとると、Youshu BI のセルフサービス データ取得 (easyfetch) のクエリは通常、業務時間中に発生します。 Youshu BI レポートでは、ユーザーが作業する前に、多数のレポート結果の事前ロード操作 (レポート クエリ SQL を事前に発行し、クエリ結果をキャッシュしてレポートの表示エクスペリエンスを向上させる) が必要です。 easyfetch と BI レポートのシナリオを、同じ NDH Impala クラスター内の 2 つの仮想データ ウェアハウスとして構成できます。作業前に、easyfetch 仮想データ ウェアハウスのほとんどの impalad ノードを BI レポート仮想データ ウェアハウスに移動できるため、レポートの事前ロード効率が大幅に向上します。

もちろん、透過的なスケーリングは仮想データ ウェアハウス間にのみ適用されるわけではありません。クラウド環境では、k8s または同様のスケジューリング メカニズムを通じて、負荷のピーク時にコンテナーまたは仮想マシンのリソースを簡単に適用し、オンライン リソースにすばやく追加できます。ピーク期間が過ぎると、追加されたリソースはクラウドベンダーに解放されます。

4. 高度な機能

Impala リソース キューと比較すると、仮想データ ウェアハウスのノード グループ内のコーディネーター ノードは、他のグループのコンピューティング リソース (エグゼキューター) を使用することはありません。リソースの分離がより徹底されるため、異なるビジネス モジュールのクエリ パフォーマンスが相互に影響を与えなくなります。ただし、異なる仮想データ ウェアハウスに属する業務では負荷が異なる場合があり、リソースの使用率が不十分になる可能性があります。アイドル ノード グループのリソース使用率を向上させるために、仮想データ ウェアハウス機能がさらに強化され、混合グループ化や時分割多重化などの機能が導入されました。

（１）混合グループ

混合グループ化とは、次の図に示すように、実行ノードが同時に 2 つ以上のノード グループに属することを意味します。左のサブ図は通常モードです。 NDH Impala クラスターは、BI レポートとアドホック クエリの 2 つの仮想データ ウェアハウスに分割されていると想定されます。アドホック クエリは明らかに時間に敏感であり、クエリは勤務時間中に集中し、クエリの同時実行性は低くなります。混合グループ化により、仮想データ ウェアハウスの展開モードを適切なサブグラフのモードに変換できます。

図では、n1～n2 は group1 ノード グループのコーディネーター ノードであり、zookeeper パス youdata に登録されます。 Hive JDBC クライアントは、パスから任意のコーディネーター ノードを取得し、それにクエリを送信します。コーディネータはクエリを解析し、分散実行プランを最適化して指定し、最終的に_{実行のために n3 n7 に送信します。 n6} n7 はグループ4 の実行ノードでもあります。グループ 4 のコーディネーターは n8 _{n9 です。これは、Zookeeper パス Ad-Hoc から入力されるクエリを受信し、分散実行プランを指定して、n6 n8 に送信します}。

（２）時分割多重

時分割多重化は、リソースの使用率を向上できるもう 1 つの高度な機能です。特定の期間にクラスター グループ リソースを自動的に構成することで、特定の高負荷グループのクエリ負荷を軽減し、ユーザー エクスペリエンスを向上させることができます。

実装面では、同じコーディネーターを複数の Zookeeper アドレスに登録することをサポートし、各アドレスへの登録の有効時間を設定することもできます。上図に示すように、Ad-Hoc 仮想データ ウェアハウスの 2 つのコーディネーター n8 と n9 (またはそのうちの 1 つ) を、毎日午後 8 時から午前 8 時まで BI レポート仮想データ ウェアハウスの同じ Zookeeper アドレスに登録して、BI レポートのクエリ負荷を共有できます。

混合グループ化と比較すると、タイムシェアリング多重化機能は、同様の仕様を持つノード グループ間での使用にのみ適しており、異なるグループ間でのクエリ パフォーマンスに明らかなギャップがないことが保証されます。

（３）負荷に基づくノード選択

実行ノードのコンピューティング リソースの使用が不均一になる理由は多数あります。たとえば、データの偏りにより、一部のエグゼキュータ ノードがデータのスキャンと処理に多くのコンピューティング リソースを消費したり、混合グループ化機能の導入により一部のノード グループに過度のノード負荷が発生したりする可能性があります。

この問題に対処するために、NDH Impala は 2 つの最適化を行いました。 1 つ目は、エグゼキュータ ノードの負荷に基づいてクエリの分散実行をサポートすることです。実装方法は、クエリ SQL の分散実行プランを決定する際に、エグゼキュータ ノードの現在使用可能なコンピューティング リソースを考慮し、使用可能なリソースが少ないエグゼキュータ ノードを排除することです。 2 つ目は、複数のキューがある場合に、エグゼキュータの同じキューでのクエリ要求の合計リソース使用量を制限して、エグゼキュータのリソースが特定のキューによって独占されるのを防ぐことです。

5. まとめ

このセクションでは、主に仮想データ ウェアハウスの概念の起源と実装を紹介し、NDH Impala の仮想データ ウェアハウスの探求、考え方、使用法の分析に焦点を当てます。現在、仮想データ ウェアハウスは、NetEase のインターネット事業と NetEase Cloud Computing の商用顧客クラスターで成功したアプリケーション事例があります。

著者は、仮想データ ウェアハウスが新世代の分析データ ウェアハウスに不可欠な機能であるべきだと考えています。複雑で多様なビジネス負荷を取り除き、実行エンジン自体の機能を最大限に活用できます。最後に、仮想データ ウェアハウスはクラウド ネイティブの機能であり、コンピューティング リソースを柔軟に拡張できる環境ではその価値を最大化できることを指摘しておく必要があります。

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

​​https://ost..com​​.