ビッグデータガバナンスにおけるAIアルゴリズムの応用

この記事では、主にデータケーキがビッグデータガバナンスにAIアルゴリズムを適用した経験を紹介します。プレゼンテーションは5つのパートに分かれています。パート1では、ビッグデータとAIの関係を明確にし、ビッグデータはAIに役立つだけでなく、AI を使用して自身のサービスを最適化することもできることを示します。つまり、両者は相互に支え合い、依存し合っています。パート2では、 AIモデルを使用してビッグデータタスクの健全性を総合的に評価し、後続のデータガバナンスに定量的な根拠を提供するアプリケーションの実践を紹介します。パート3では、AIモデルを使用してSparkタスク実行パラメータ設定をインテリジェントに推奨し、クラウドリソースの使用率を向上させるというアプリケーションの実践を紹介します。パート4では、モデルを使用してSQLクエリシナリオでタスク実行エンジンをインテリジェントに推奨する実践を紹介します。パート5では、ビッグデータのライフサイクル全体にわたるAIの応用シナリオを見据えます。

完全な目次:

1. ビッグデータとAI

2. ビッグデータタスクの健全性評価

3. Sparkタスクのインテリジェントなパラメータ調整

4. SQLタスク実行エンジンのインテリジェントな選択

5. ビッグデータガバナンスにおけるAIアルゴリズムの応用の展望

ゲストスピーカー: HappyEggplant アルゴリズムエンジニア Li Weimin 氏

チャールズによる編集と編集

コミュニティ制作 | DataFun

ビッグデータとAI

クラウドコンピューティングは膨大な量のデータを収集・蓄積し、ビッグデータを形成し、そのビッグデータからマイニングと学習を行うことでAIモデルをさらに発展させるという認識が一般的です。この考え方は、ビッグデータがAIに役立つことを前提としていますが、AIアルゴリズムもビッグデータにフィードバックできるという事実を見落としています。両者の関係は双方向で、相互に支え合い、相互依存的です。

ビッグデータのライフサイクル全体は6つの段階に分けられ、それぞれに課題があります。AIアルゴリズムを適切に活用することで、これらの課題の解決に役立ちます。

データ収集：この段階では、データ収集の品質、頻度、セキュリティに重点を置きます。例えば、収集データの完全性、収集速度が速すぎるか遅すぎるか、収集データが匿名化または暗号化されているかどうかなどを検討します。AIは、類似アプリケーションに基づいてログ収集の合理性を評価したり、異常検出アルゴリズムを使用してデータ量の急激な増加や減少を特定したりするなど、ここで重要な役割を果たします。

データ転送：この段階では、データの可用性、整合性、セキュリティに重点が置かれます。AIアルゴリズムは、障害診断や侵入検知に使用できます。

データストレージ： この段階では、データストレージ構造が合理的であるか、リソース消費が十分に少ないか、そして十分に安全であるかに重点が置かれます。AIアルゴリズムは評価と最適化にも活用できます。

データ処理：この段階はメリットに最も大きな影響を与え、最適化を行います。中核となる課題は、データ処理の効率を向上させ、リソース消費を削減することです。AIはこれを複数の角度から最適化できます。

データ交換：企業間の連携が進むにつれて、データセキュリティが懸念事項となります。この分野ではアルゴリズムを適用できます。例えば、現在普及しているフェデレーテッドラーニングは、より優れた安全なデータ共有を促進するのに役立ちます。

データ破棄：データは単に削除せずに保存することはできません。そのため、いつデータを削除するか、そしてそれに伴うリスクの有無を検討する必要があります。AIアルゴリズムは、ビジネスルールに基づいて、データ削除のタイミングとそれに伴う影響を判断するのに役立ちます。

データライフサイクル管理には、効率性、低コスト、そしてセキュリティという3つの主要な目標があります。従来、ルールや戦略の策定には専門家の経験に頼ってきましたが、これには高コストと低効率という大きな欠点がありました。AIアルゴリズムを適切に活用することで、これらの欠点を回避し、基本的なビッグデータサービスの構築に貢献することができます。

ビッグデータタスクの健全性評価

Eggplant Technology で実装された最初のアプリケーションシナリオの 1 つは、ビッグデータタスクの健全性の評価です。

ビッグデータプラットフォームでは、毎日数万ものタスクが実行されます。しかし、多くのタスクは、タスク実行時間やリソース消費量を考慮することなく、データを正しく生成する段階までしか進みません。その結果、多くのタスクが非効率になり、リソースを無駄にしています。

データ開発者がタスクの健全性に注目し始めたとしても、タスクが真に健全であるかどうかを正確に評価することは依然として困難です。これは、失敗率、時間消費、リソース使用量など、タスクに関連する指標が多数存在するためです。さらに、タスクごとに複雑さや処理するデータ量も当然異なります。したがって、単一の指標の絶対値を評価基準として単純に選択することは明らかに不合理です。

タスクの健全性を定量化できなければ、どのタスクが不健全で対処が必要なのかを判断することは困難であり、ましてやどこに問題があり、どこから対処を始めればよいのかを判断することは困難です。たとえタスクに対処できたとしても、その効果は不明であり、ある指標が改善する一方で、他の指標が悪化するといった状況さえ起こり得ます。

要件：前述の課題に直面し、タスク全体の健全性を正確に反映する定量的な指標が緊急に必要です。手動でルールを策定するのは非効率的かつ不完全であるため、機械学習モデルの力を活用することを検討しています。目標は、モデルによってタスクの定量的なスコアとグローバル分布における位置を提供し、タスクの主な問題点と解決策を特定することです。

この要件に対する私たちの解決策は、管理インターフェースにオーナー名で表示されるすべてのタスクに関する重要な情報（評価、タスクコスト、CPU使用率、メモリ使用率など）を表示することです。これにより、タスクの健全性を明確に把握でき、タスクオーナーによるその後のタスク管理が容易になります。

次に、評価関数のモデルについてですが、これを分類問題として扱います。直感的に、タスク評価は明らかに回帰問題であり、与えられた値は0から100までの任意の実数である必要があります。しかし、これには十分な数の評価サンプルが必要であり、手作業によるアノテーションはコストがかかり、信頼性も低くなります。

そこで、この問題を分類問題に変換することを検討します。分類モデルによって与えられたクラス確率は、実数値スコアにマッピングされます。タスクは、ビッグデータエンジニアによってラベル付けされた「良いタスク1」と「悪いタスク0」の2つのクラスに分類されます。「良いタスク」とは、通常、同じワークロードと複雑さで、より短時間で消費されるリソースが少ないタスクを指します。

モデルのトレーニングプロセスは次のとおりです。

まず、サンプルを準備します。サンプルは過去のタスクデータから取得し、サンプルの特徴には実行時間、使用リソース、実行失敗の有無が含まれます。サンプルラベルは、ビッグデータエンジニアがルールや経験に基づいて「良好」と「不良」のカテゴリに分類します。次に、モデルをトレーニングします。LR、GBDT、XGboostなどを試した結果、理論と実践の両方において、XGboostの方が優れた分類性能を示すことが示されています。モデルは最終的に、タスクが「良好タスク」である確率を出力します。この確率が高いほど、最終的なタスクスコアも高くなります。

トレーニング後、初期の約50個の特徴量から19個の特徴量が選択されました。これらの19個の特徴量は、基本的にタスクの良し悪しを判断するのに役立ちます。例えば、失敗回数が多いタスクやリソース利用率が低いタスクは、一般的にスコアがあまり高くなりません。これは基本的に人間の主観的な感覚と一致しています。

モデルを用いてタスクをスコアリングした結果、0～30点未満のタスクは不健全と判断され、早急に改善が必要です。一方、30～60点のタスクは比較的健全と判断され、60点以上のタスクは比較的健全と判断され、現状維持が望ましいと判断されます。これらの定量化可能な指標を用いることで、タスクオーナーがタスクを積極的に管理し、コスト削減と効率向上という目標を達成できるよう支援できます。

このモデルの適用により、次のような利点がもたらされました。

① まず、タスクオーナーは自分の担当するタスクの健全性を明確に把握でき、スコアやランキングを通じてタスクに対処する必要があるかどうかを知ることができます。

② 定量化された指標は、その後のタスクガバナンスの基礎となる。

③ タスク管理完了後に達成されたメリットや改善の程度もスコアを通じて定量化できます。

Sparkタスクのインテリジェントなパラメータ調整

2つ目の応用シナリオは、Sparkタスクのインテリジェントなパラメータチューニングです。ガートナー社の調査によると、クラウドユーザーが消費するクラウドリソースの70%が不必要に浪費されています。クラウドリソースを要求する際、多くの人はタスクを正常に実行するために必要な量よりも多くのリソースを要求し、不必要な浪費につながっています。また、タスク作成時にデフォルト設定を使用する人も多くいますが、これは最適ではありません。注意深く設定することで優れた結果が得られ、効率と成功の両方を保証しながら、大幅なリソースを節約できます。ただし、タスクパラメータの設定はユーザーに高い要求を課します。設定項目の意味を理解するだけでなく、それらの相互関係も考慮する必要があります。専門家の経験に頼っても最適な結果を得るのは難しく、ルールベースの戦略を動的に調整することは困難です。

これにより、モデルがタスク実行に最適なパラメータ構成をインテリジェントに推奨できるようにして、元のタスク実行時間を変えずにタスククラウドリソースの利用率を向上させるという要件が生じます。

タスクパラメータチューニングモジュールの設計には、次の 2 つのシナリオが含まれています。まず、しばらくオンラインで実行されているタスクの場合、モデルはタスクの履歴実行データに基づいて最適な構成パラメータを推奨できる必要があります。次に、ユーザーがまだ展開していないタスクの場合、モデルはタスク分析を通じて適切な構成を提供できる必要があります。

次のステップはモデルのトレーニングです。そのためには、モデルの出力ターゲットを定義する必要があります。設定可能な項目は300以上あり、モデルで提供できる項目は多すぎます。テストと調査を経て、タスクのパフォーマンスに最も大きな影響を与える3つのパラメータ、すなわちエグゼキューターコア数、メモリ総量、インスタンス数を選択しました。各設定項目にはデフォルト値と調整可能な範囲があり、モデルが最適な解を探索するためのパラメータ空間を提供します。

トレーニングフェーズでは、2つのアプローチが採用されました。1つ目のアプローチは、経験則を学習するというものです。当初はルールを用いてパラメータが推奨され、デプロイ後に有効性が証明されました。そのため、迅速なデプロイを実現するために、モデルはまずこれらのルールを学習するようにトレーニングされました。モデルのトレーニングサンプルは、ルールに基づいて事前に計算された70,000以上のタスク構成で構成されていました。サンプルの特徴量には、タスク実行履歴データ（処理データ量、リソース使用量、タスク所要時間など）と統計情報（過去7日間の平均および最大リソース消費量など）が含まれていました。

ベースモデルとして、複数の従属変数を持つ多変量回帰モデルを選択しました。一般的な回帰モデルは単一出力で、独立変数は多数ありますが従属変数は1つだけです。ここでは3つのパラメータを出力することを目指しているため、複数の従属変数を持つ多変量回帰モデル、つまり本質的にLRモデルを使用します。

上の図は、このモデルの理論的根拠を示しています。左側は、3つの構成項を持つマルチラベルモデルです。βは各特徴量の係数、Σは誤差です。学習方法は単変量回帰と同じで、最小二乗推定を用いてΣの要素の二乗和を最小化します。

オプション1の利点は、比較的低コストでルールと経験を迅速に学習できることです。欠点は、最適化の限界がルール自体と同等のパフォーマンスレベルに制限されており、そのレベルを超えることは非常に困難であることです。

2つ目のアプローチはベイズ最適化です。これは強化学習に似ており、パラメータ空間内で実験を行うことで最適な構成を探索します。ベイズフレームワークがここで使用されるのは、過去の試行を活用することで、後続の試行に過去の経験を提供し、より良い位置をより速く探索できるようにするためです。トレーニングプロセス全体はパラメータ空間内で行われ、検証用の構成をランダムにサンプリングし、プログラムを実行します。実行後、使用率やコストなどの指標を監視し、最適かどうかを判断します。これらのステップは、チューニングが完了するまで繰り返されます。モデルのトレーニングが完了すると、回避策が存在します。新しいタスクが過去のタスクとある程度の類似性を持つ場合、構成を再計算する必要はありません。以前の最適な構成をそのまま使用できます。

これら2つのアプローチの試行と実践を通じて、いくつかの肯定的な結果が確認されています。既存のタスクでは、モデルの推奨に従って設定パラメータを変更することで、80%以上のタスクでリソース使用率が約15%向上し、一部のタスクではリソース使用率が2倍になったことさえありました。しかし、どちらのアプローチにも欠点があります。学習ルールに基づく回帰モデルは最適化の上限が比較的低く、グローバル最適化に基づくベイズ最適化モデルは複数の試行が必要であり、コストが高すぎます。

今後の探究の方向性としては以下のようなものがあります。

セマンティクス分析： Sparkのセマンティクスは非常に豊富で、様々なコード構造と演算子関数を網羅しており、タスクパラメータの設定やリソース消費に密接に関連しています。しかしながら、現状ではタスクの実行履歴データのみを活用し、Sparkのセマンティクスそのものは考慮されておらず、これは情報の無駄遣いとなっています。次のステップは、コードレベルにまで踏み込み、Sparkタスクに含まれる演算子関数を分析し、それに応じてよりきめ細かな最適化を行うことです。

カテゴリベースの最適化： Sparkには、純粋な分析、開発、処理など、多くのアプリケーションシナリオがあります。シナリオごとに最適化空間と目標が異なるため、カテゴリベースの最適化を実行する必要があります。

エンジニアリングの最適化:実際に遭遇する困難の 1 つは、サンプルサイズが小さく、テストコストが高いことです。そのため、エンジニアリングやプロセスを最適化するには、関係者の協力が必要です。

SQLタスク実行エンジンのインテリジェントな選択

3 番目のアプリケーションシナリオは、SQL クエリタスク実行エンジンのインテリジェントな選択です。

背景：

(1) SQLクエリプラットフォームは、多くのユーザーが最も頻繁に利用し、最も明確な経験を持つビッグデータ製品です。データアナリスト、研究開発担当者、製品マネージャーなど、誰もが必要なデータを取得するために毎日大量のSQLを記述しています。

（2）SQLタスクを実行する際に、基盤となる実行エンジンに注目する人は少ない。例えば、Prestoは純粋メモリコンピューティングをベースにしている。単純なクエリシナリオでは、実行速度が比較的速いという利点があるが、ストレージが不足するとすぐにクラッシュしてしまうという欠点がある。一方、Sparkは大量のデータを扱う複雑なシナリオに適している。たとえOOMが発生しても、ディスクストレージを使用することでタスクの失敗を回避できる。そのため、タスクシナリオによって適切なエンジンは異なる。

(3) SQLクエリの効果は、タスクの実行時間とリソース消費量を考慮する必要があります。リソース消費量を考慮せずにクエリ速度だけを追求したり、リソースを節約するためにクエリ効率に影響を与えたりすべきではありません。

（4）業界では、RBO、CBO、HBOという3つの主要な従来のエンジン選択方法があります。RBOはルールベースのオプティマイザーであり、定式化が難しく、更新頻度が低いです。CBOはコストベースのオプティマイザーであり、コストの最適化に重点を置きすぎるとタスクの実行に失敗する可能性があります。HBOは過去のタスク操作に基づいたオプティマイザーであり、履歴データに比較的限定されています。

機能モジュールの設計に関しては、ユーザーが SQL 文を記述して実行のために送信すると、モデルは使用するエンジンを自動的に決定し、ポップアップウィンドウでユーザーにプロンプトを表示して、推奨されたエンジンを使用して実行するかどうかをユーザーが最終的に決定できるようにします。

全体的なモデルアプローチでは、SQL 文自体に基づいて実行エンジンを推奨します。SQL 文自体から、使用されているテーブルと関数が明らかになり、その複雑さが直接決定され、実行エンジンの選択に影響を与えます。トレーニングサンプルは、過去に実行された SQL 文から取得されます。モデルラベルは、過去の実行パターンに基づいています。たとえば、実行時間が非常に長いタスクやデータセットが大きいタスクは Spark に適しているとラベル付けされ、残りの SQL 文は Presto に適していると判断されます。特徴抽出には NLP 手法、具体的には N-gram と TF-IDF を組み合わせて利用します。基本的な原理は、文中での出現頻度に基づいてフレーズを抽出し、キーフレーズを識別することです。結果として得られるベクトル特徴は非常に大きくなります。最初に線形モデルを使用して 3000 個の特徴をフィルター処理し、次に最終的な予測モデルとして XGBoost モデルをトレーニングします。

トレーニング後、モデルの予測精度は非常に高くなり、約 90% 以上になります。

モデルの最終的なオンラインアプリケーションプロセスは次のとおりです。ユーザーがSQLを送信すると、モデルは実行エンジンを推奨します。推奨されたエンジンがユーザーが最初に選択したエンジンと異なる場合、言語変換モジュールが呼び出され、SQL文が変換されます。エンジンの切り替え後に実行が失敗した場合は、フェイルオーバーメカニズムによって元のエンジンに戻り、タスクが正常に実行されるようにします。

この方法の利点は、ユーザーが追加の学習を行う必要なく、モデルが最適な実行エンジンを自動的に選択し、後続のステートメント変換を完了できることです。

さらに、モデル推奨エンジンは基本的に元の実行効率を維持しながら失敗率を低減できるため、全体的なユーザーエクスペリエンスが向上します。

最後に、不要な高コストエンジンの使用が削減され、タスク実行の失敗率が低下したことにより、全体的なリソースコストの消費が減少しました。

パート2からパート4では、ビッグデータ・プラットフォームにおけるAIアルゴリズムの3つの応用例をご紹介しました。重要な特徴は、使用されているアルゴリズムはそれほど複雑ではないにもかかわらず、得られる結果が非常に重要であることです。これは、ビッグデータ・プラットフォームにおける問題点と最適化の機会を積極的に理解するためのきっかけとなります。適用シナリオが特定されれば、様々な機械学習手法を用いてこれらの問題を解決し、AIアルゴリズムをビッグデータに還元することが可能になります。

ビッグデータガバナンスにおけるAIアルゴリズムの応用の展望

最後に、ビッグデータガバナンスにおける AI アルゴリズムの適用シナリオを見てみましょう。

上記で紹介した3つの応用シナリオは、主にデータ処理段階に集中しています。実際、第1章で議論したAIとビッグデータの関係を反映して、AIはデータライフサイクル全体を通して重要な役割を果たすことができます。

例えば、データ取得段階ではログの合理性を判断でき、転送段階では侵入検知、処理段階ではさらなるコスト削減と効率化、交換段階ではデータセキュリティ対策、破棄段階では破棄のタイミングとその影響度を判断できます。ビッグデータプラットフォームにおけるAIの応用シナリオは多岐にわたりますが、これはほんの始まりに過ぎません。AIとビッグデータの相互補完関係は、今後さらに顕著になると考えられています。AIはビッグデータプラットフォームのデータ収集と処理の向上を支援し、データ品質の向上はより優れたAIモデルのトレーニングに役立ち、好循環が実現します。

質疑応答セッション

Q1: どのようなルールエンジンを使用していますか？オープンソースですか？

A1: ここで言及したパラメータ調整ルールは、ビッグデータ分野の同僚たちが、手動による最適化の経験に基づいて開発したものです。例えば、タスクの実行時間が一定時間（分）を超えたり、処理データ量が一定量を超えたりした場合、そのタスクに対して特定のコア数やメモリ使用量を推奨します。これは長年にわたり蓄積されてきたルールであり、導入後も良好なパフォーマンスを発揮しています。そのため、このルールセットを用いてパラメータ推奨モデルを学習しています。

Q2: 従属変数のパラメータ調整のみですか？ビッグデータプラットフォームの性能不安定性が計算結果に与える影響は考慮されていますか？

A2: パラメータを推奨する際には、盲目的に低コストを追求することはありません。そうしないと、推奨されるリソースが不足し、タスクが失敗する可能性があります。従属変数はパラメータ調整のみですが、不安定性を防ぐために追加の制約を設けています。まず、モデル特性については、特定の日の値ではなく、一定期間の平均値を選択します。次に、モデルが推奨するパラメータについては、実際の設定値との差を比較します。差が大きすぎる場合は、段階的に増減する戦略を採用することで、一度に大きな変更を加えすぎることを防ぎ、タスクが失敗するのを防ぎます。

Q3: 回帰モデルとベイズモデルを同時に使用できますか?

A3: いいえ。前述の通り、パラメータ推奨には2つのアプローチを採用しました。1つはルール学習のための回帰モデル、もう1つはベイズ最適化フレームワークです。この2つは同時に使用せず、異なる手法で実験を行いました。前者（ルール学習）の利点は、過去の経験を迅速に活用できることです。後者のモデルは、前者に基づいて、より良い、あるいは最適な設定を見つけることができます。これらは順次、あるいは段階的に適用され、同時に使用されることはありません。

Q4: さらなる機能を拡張するために、セマンティック解析の導入が検討されましたか?

A4: はい。先ほども申し上げたように、Sparkハイパーパラメータのチューニングでは実行履歴情報のみを使用していますが、Sparkタスク自体にはまだ焦点を当てていません。Spark自体には、様々な演算子やステージなど、多くの情報が含まれています。そのセマンティクスを解析しなければ、多くの情報が失われてしまいます。そのため、次の計画としては、Sparkタスクのセマンティクスを解析し、パラメータ計算を支援する機能をさらに拡張していく予定です。

Q5: パラメータの推奨が不合理で、タスクの異常や失敗につながる可能性はありますか？そのような場合、異常なタスクエラーやタスクの変動をどのように減らせばよいでしょうか？

A5: モデルに完全に依存してしまうと、モデルはリソース使用率を最大限に高めることを目指してしまう可能性があります。この場合、推奨パラメータは、メモリを30GBから5GBに急激に減らすなど、かなりアグレッシブなものになる可能性があります。そのため、モデルの推奨に加えて、パラメータ調整範囲を一定量（GB単位）に制限するなど、段階的に増減させる戦略など、追加の制約を追加します。

Q6:シグモイド2022のパラメータチューニングに関して参考にした記事はありますか？

A6: タスクベースのインテリジェントパラメータチューニングは比較的人気の高い研究分野であり、様々な分野のチームが様々な手法やモデルを採用しています。私たちは研究を始める前に、ご指摘いただいたSigmoid 2022の論文をはじめ、様々な業界の手法を研究しました。比較と実践を経て、最終的にご紹介した2つのソリューションを試しました。今後もこの分野の最新動向を注視し、レコメンデーションのパフォーマンス向上に向けて、より多くの手法を試していく予定です。

HUOXIU

ビッグデータガバナンスにおけるAIアルゴリズムの応用

関連するおすすめ記事

ランダムにおすすめされた記事

人気のタグ