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

#この記事では主に、ビッグ データ ガバナンスにおける AI アルゴリズムの適用における Datacake の経験を共有します。この共有は 5 つの部分に分かれており、最初の部分では、ビッグデータと AI の関係を明確にします。ビッグデータは AI に役立つだけでなく、AI を使用して自身のサービスを最適化することもできます。この 2 つは相互にサポートし、依存しています。第 2 部分は、ビッグデータと AI の関係を明確にします。 AI モデルのアプリケーション プラクティスの使用を紹介し、ビッグ データ タスクの健全性を包括的に評価し、その後のデータ ガバナンスに定量的な基礎を提供します。第 3 部では、AI モデルを使用して Spark タスクの実行パラメータ構成をインテリジェントに推奨し、目標を達成するアプリケーション プラクティスを紹介します。第 4 部では、SQL クエリ シナリオのモデルによるタスク実行エンジンをインテリジェントに推奨する実践を紹介し、第 5 部では、ビッグ データのライフ サイクル全体における AI のアプリケーション シナリオを展望します。

##1. ビッグデータと AI

# #一般的な概念は、クラウド コンピューティングが大量のデータを収集および保存してビッグ データを形成し、ビッグ データのマイニングと学習を通じて AI モデルがさらに形成されるというものです。この概念は、ビッグデータが AI に役立つことを暗黙の前提としていますが、AI アルゴリズムもビッグデータにフィードバックできるという事実を無視しており、両者の間には双方向の相互サポートと依存の関係があります。

#ビッグデータのライフサイクル全体は 6 つの段階に分けられ、各段階で直面します。問題によっては、AI アルゴリズムを適切に使用することで問題の解決に役立つ場合があります。

データ収集:

この段階では、品質、頻度、セキュリティにさらに注意が払われます。収集されたデータが完全かどうか、データ収集速度が速すぎるか遅すぎるか、収集されたデータが感度を下げられているか暗号化されているかなど、データ収集の状況。このとき、AIは、同様のアプリケーションに基づいてログ収集の合理性を評価したり、異常検出アルゴリズムを使用してデータ量の急激な増加または減少を検出したりするなど、いくつかの役割を担うことができます。

データ送信:

この段階では、データの可用性、整合性、セキュリティ、および AI にさらに注意が払われます。アルゴリズムを使用して、一部の障害診断と侵入検出を実行します。

データ ストレージ:

この段階では、データ ストレージ構造が合理的であるかどうかにさらに注意を払います。リソースの使用量が十分に低いかどうか、十分に安全かどうかなど、AI アルゴリズムを使用して評価と最適化を行うこともできます。

データ処理:

この段階は、収益に影響を与え、最適化する最も明白な段階です。中心的な問題は次のとおりです。データ処理効率を向上させ、リソース消費を削減するために、AI は複数の開始点から最適化できます。

データ交換:

企業間の協力はますます増えており、それにはデータ セキュリティの問題が伴います。この分野にはアルゴリズムも適用でき、たとえば、人気のあるフェデレーテッド ラーニングは、データをより適切かつ安全に共有するのに役立ちます。

データの破棄:

データを削除せずに保存することは不可能なので、いつ行うかを検討する必要があります。データを削除する場合、リスクがあるかどうか。 AI アルゴリズムは、ビジネス ルールに基づいて、データ削除のタイミングとそれに伴う影響の判断を支援します。

全体的に、データ ライフサイクル管理

# には、高効率、低コスト、セキュリティという 3 つの主要な目標があります。これまでのアプローチは、専門家の経験に頼ってルールや戦略を策定することでしたが、高コストや低効率などの明らかな欠点がありました。 AI アルゴリズムを適切に使用すると、これらの欠点を回避し、ビッグデータの基本サービスの構築にフィードバックできます。

2. ビッグ データ タスクの正常性評価

#Qingzi Technology では、いくつかのアプリケーション シナリオが実装されています。データタスクの健全性。

#ビッグ データ プラットフォームでは、毎日何千ものタスクが実行されます。しかし、多くのタスクは正しい数値を出す段階に留まり、タスクの実行時間やリソースの消費量などが考慮されていないため、多くのタスクで効率が低く、リソースの無駄が生じています。

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

# 定量化されたタスクの健全性がなければ、どのタスクが不健全でガバナンスが必要であるかを判断することは難しく、ましてや問題がどこにあるのか、どこからガバナンスを開始すればよいのかを判断することは困難です。ガバナンスがあるとしても、それがどの程度効果があるのか​​正確にはわかりませんし、ある指標が改善しても他の指標が悪化するという状況さえあるかもしれません。

要件: 上記の問題に直面して、全体的な健康状態を正確に反映する定量的な指標が緊急に必要です。ミッションの状況です。手動でルールを作成するのは非効率的で不完全であるため、機械学習モデルの力を利用することを検討してください。目標は、モデルがタスクの定量的なスコアとグローバル分布におけるその位置を提供し、タスクの主な問題と解決策を提供できるようにすることです。

#この要件を満たすために、当社の機能モジュール ソリューションでは、管理インターフェイス上の所有者の名前の下にすべてのタスクの重要な情報 (評価、評価など) を表示します。タスクのコスト、CPU 使用率、レート、メモリ使用率など。このようにして、タスクの健全性が一目でわかるため、タスク所有者は後でタスクを管理しやすくなります。

#第 2 に、スコアリング関数のモデル スキームを分類問題として扱います。直感的には、タスクのスコアリングは明らかに回帰問題であり、0 ～ 100 の間の実数を与える必要があります。ただし、これには十分な数のスコア付けされたサンプルが必要であり、手動によるラベル付けは費用がかかり、信頼性も高くありません。

# したがって、問題を分類問題に変換することを検討します。分類モデルによって与えられるクラス確率を実際のスコアにさらにマッピングできます。私たちはタスクを 2 つのカテゴリ (良いタスク 1 と悪いタスク 0) に分類し、ビッグ データ エンジニアによってラベル付けします。いわゆる良いタスクとは、通常、同じタスク量と複雑さの下で、時間が短く、消費するリソースが少ないタスクを指します。

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

最初はサンプルの準備です。サンプルは実行タスクの履歴データから取得されます。サンプルの特性には、実行時間、使用されたリソース、実行が失敗したかどうかなどが含まれます。サンプル ラベルは、ビッグ データ エンジニアによってルールまたは経験に基づいて良いカテゴリと悪いカテゴリにマークされます。 LR、GBDT、XGboost などのモデルを次々に試したところ、理論と実践の両方で、XGboost の分類効果が優れていることが証明されました。モデルは最終的に、タスクが「良いタスク」である確率を出力します。確率が高いほど、最終的にマップされたタスクのスコアも高くなります。

トレーニング後、元の約 50 個の特徴量から 19 個の特徴量が選択され、これら 19 個の特徴量によって基本的にタスクが良いタスクであるかどうかを判断できます。たとえば、何度も失敗し、リソース使用率が低いタスクのほとんどは、スコアがそれほど高くありません。これは基本的に人間の主観的な感情と一致します。

モデルを使用してタスクにスコアを付けた後、0 ～ 30 未満のスコアは不健全で緊急であることがわかります。管理が必要なタスク。30 ～ 60 のタスクは、許容可能な健全性を備えたタスクです。スコアが 60 を超えるタスクは、比較的良好な健全性を備えており、現状を維持する必要があるタスクです。このように、定量的な指標を使用すると、タスク所有者が一部のタスクを積極的に管理するように誘導でき、それによってコストを削減し、効率を向上させるという目標を達成できます。

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

① まず、タスク所有者ができること。タスクが完了しているかどうかを知ることができる。スコアとランキングによるニーズ管理;

#② 定量的な指標は、その後のタスク管理の基礎を提供します;

③ タスク管理完了後の効果や改善点もスコアで数値化できます。

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

# #2 番目のアプリケーション シナリオは、Spark タスクのインテリジェントなパラメーター調整です。 Gartner の調査では、クラウド ユーザーが消費するクラウド リソースの 70% が不必要に浪費されていることが明らかになりました。クラウド リソースを申請する場合、タスクを確実に実行するために多くの人がより多くのリソースを申請する可能性がありますが、これにより不必要な無駄が発生します。タスクを作成するときにデフォルトの構成を使用する人もたくさんいますが、実際にはこれは最適な構成ではありません。慎重に構成できれば、非常に優れた結果が得られ、運用効率と成功を確実にするだけでなく、多くのリソースを節約することもできます。しかし、タスクパラメータの設定はユーザーへの要求が高く、設定項目の意味を理解するだけでなく、設定項目間の関連付けによる影響も考慮する必要があります。専門家の経験に頼っても最適性を達成することは難しく、ルールベースの戦略を動的に調整することは困難です。

これは、タスクの元の実行時間が変わらないように、モデルがタスク操作に最適なパラメーター構成をインテリジェントに推奨できることを期待して、要件を提示します。 . タスククラウドリソースの利用効率向上を前提としています。

#タスクパラメータ調整機能モジュールに関して、私たちが設計したソリューションには 2 つの状況が含まれています。すでにオンラインになっている 一定期間実行されているタスクの場合、モデルは、タスクの実行ステータスの履歴に基づいて、最も適切な構成パラメータを推奨できなければなりません。2 番目のケースは、ユーザーがまだオンラインになっていないタスクの場合です。 、モデルはタスクの分析を通じて合理的な構成を提供できなければなりません。

次のステップはモデルのトレーニングです。まず、 の出力ターゲットを決定します。モデル。設定可能な項目は300以上あり、モデルによってすべてを指定することは不可能です。テストと調査の結果、タスクの実行パフォーマンスに最も大きな影響を与える 3 つのパラメーター、つまりエグゼキューターのコア数、メモリの合計量、インスタンスの数を選択しました。各設定項目にはデフォルト値と調整範囲があり、実際にはパラメータ空間が与えられており、モデルはその空間内で最適解を見つけるだけで済みます。

トレーニング フェーズには 2 つのオプションがあります。最初のオプションは経験則を学習することです: ルールを使用して初期段階でパラメータを推奨し、結果はオンラインになった後も良好です。したがって、モデルにこの一連のルールを最初に学習させて、迅速にオンラインにするという目標を達成します。モデル トレーニング サンプルは、ルールに基づいて事前に計算された 70,000 を超えるタスク構成であり、サンプルの特性は、タスクの実行履歴データ (タスクによって処理されたデータ量、リソースの使用量、タスクにかかった時間など) です。 、など）、およびいくつかの統計情報（過去 7 日間の平均消費量、最大消費量など）。

基本モデル 複数の従属変数を持つ重回帰モデルを選択しました。一般的な回帰モデルは単一出力であり、多くの独立変数がありますが、従属変数は 1 つだけです。ここでは 3 つのパラメーターを出力したいので、複数の従属変数を持つ重回帰モデル (本質的には LR モデル) を使用します。

上の図は、このモデルの理論的基礎を示しています。左側は3つの設定項目であるマルチラベルで、βは各特徴量の係数、Σは誤差です。学習方法は単項回帰と同じで、最小二乗法を使用して Σ の各要素の二乗和を最小値に推定します。

オプション 1 の利点は、ルールと経験をすぐに学ぶことができ、コストが比較的小さいことです。欠点は、最適化の上限がルールと同じくらい良い効果を達成できることですが、それを超えるのはより困難になることです。

2 番目のオプションはベイジアン最適化です。その考え方は強化学習に似ています。パラメーター空間で最適なソリューションを見つけようとします。 。ここでベイジアン フレームワークが使用されているのは、前回の試行の基礎を使用し、次の試行で事前の経験を積んで、より良い位置を迅速に見つけることができるためです。トレーニング プロセス全体はパラメーター空間で実行され、検証のために構成をランダムにサンプリングして実行します。実行後、使用状況、コストなどのいくつかの指標に注意を払って、適切であるかどうかを判断します。最適化されたら、調整が完了するまで上記の手順を繰り返します。モデルのトレーニング後、使用中にトリック・オア・トリートのプロセスもあり、新しいタスクが過去のタスクとある程度の類似性を持っている場合、構成を再計算する必要はなく、以前の最適な構成を使用できます。直接使用されます。

#これら 2 つの計画の実験と実践を通じて、特定の成果が得られたことがわかります。作られています。既存のタスクについては、モデルが推奨する構成パラメーターに従って変更すると、80% 以上のタスクでリソース使用率が約 15% 向上し、一部のタスクではリソース使用率が 2 倍にまで向上します。しかし、実際にはどちらのソリューションにも 欠点があります。学習ルールの回帰モデルは最適化の上限が低いのに対し、大域最適化のベイズ最適化モデルはさまざまな試行が必要でコストが高すぎるという欠点があります。

今後の探査の方向性は次のとおりです。

#セマンティック分析:

Spark セマンティクスは比較的豊富で、タスク パラメーターの構成やリソース消費に関連するさまざまなコード構造や演算子関数が含まれます。 。しかし現在、タスクの実行ステータスの履歴のみを使用し、Spark セマンティクス自体を無視しています。これは情報の無駄です。次に行うことは、コード レベルに侵入し、Spark タスクに含まれる演算子関数を分析し、それに応じてより詳細な調整を行うことです。

分類チューニング:

Spark には、純粋な分析、開発、処理、など、さまざまなシナリオのチューニング空間と目標も異なるため、分類チューニングを実行する必要があります。

エンジニアリングの最適化: 実際に直面する困難の 1 つは、サンプル数が少ないこととテスト費用が高いことであり、これには関係者の協力が必要です。プロジェクトまたはプロセスを最適化します。

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

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

背景:

(1) SQL クエリ プラットフォームは、ほとんどのユーザーが最も頻繁に接触し、最も明白な経験を持つビッグ データ製品です。データ アナリスト、研究開発、製品マネージャーのいずれであっても、必要なデータを取得するために毎日大量の SQL を作成します。 ;

(2) SQL タスクを実行するときに、多くの人は基礎となる実行エンジンに注意を払いません。たとえば、Presto は純粋なメモリ計算に基づいています。いくつかの単純なクエリ シナリオ 利点は実行速度が速いことですが、欠点はストレージ容量が十分でない場合に直接ハングすることです。Spark とは対照的に、大量のクエリを含む複雑なシナリオの実行に適しています。タスクの失敗を避けるためにディスク ストレージを使用してください。したがって、異なるタスク シナリオには異なるエンジンが適しています。

# (3) SQL クエリの効果は、タスクの実行時間とリソース消費を総合的に考慮する必要があり、リソース消費を考慮せずにクエリ速度を追求しすぎることはなく、リソースを節約するために、クエリの効率が影響を受けます。

(4) 業界では、RBO、CBO、HBO という 3 つの主要な従来のエンジン選択方法があります。 RBOはルールベースの最適化です。ルール策定が難しく更新頻度が低いです。CBOはコストベースの最適化です。コストの最適化を追求しすぎるとタスクの実行が失敗する可能性があります。HBOは過去のタスクの実行条件に基づく最適化です。 . 比較的履歴データに限定されます。

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

#モデルの全体的なソリューションは、SQL ステートメント自体に基づいて実行エンジンを推奨することです。 SQL 自体からどのテーブルが使用されているか、どの関数が使用されているかなどを確認できるため、この情報は SQL の複雑さを直接決定し、実行エンジンの選択に影響します。モデル トレーニング サンプルは、過去に実行された SQL ステートメントから取得され、モデル ラベルは過去の実行条件に基づいてマークされます。たとえば、実行に時間がかかり、大量のデータが含まれるタスクは、Spark での実行に適しているとマークされます。残りは Presto での実行に適しており、SQL を実行します。サンプル特徴抽出には、NLP 技術、N-gram と TF-IDF 手法を使用し、文中に出現する頻度を調べるフレーズを抽出することを原則として、キー フレーズを抽出します。この操作の後に生成されるベクトルの特徴は非常に大きいため、最初に線形モデルを使用して 3000 の特徴を除外し、次にトレーニングして、最終的な予測モデルとして XGBoost モデルを生成します。

#トレーニング後、モデル予測の精度がまだ比較的高いことがわかります。おそらく90％以上でしょう。

#

モデルの最終的なオンライン申請プロセスは、ユーザーが SQL を送信した後、モデルが実行エンジンを推奨します。ユーザーが最初に選択したエンジンと異なる場合は、言語変換モジュールが実行エンジンを推奨します。 SQL ステートメントの変換を完了するために呼び出されます。エンジンの切り替え後に実行が失敗した場合、タスクの実行を確実に成功させるために、ユーザーの元の実行エンジンに切り替えるフェイルオーバー メカニズムが用意されています。

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

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

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

#パート 2 ～ 4 では、ビッグ データ プラットフォームにおける AI アルゴリズムの 3 つのアプリケーションを共有しました。その特徴の 1 つは、 で使用されるアルゴリズムがそれほど複雑ではないにもかかわらず、その効果が非常に明白であるということです。 これにより、ビッグ データ プラットフォームの運用中に問題点や最適化スペースを率先して理解することができます。アプリケーション シナリオを決定した後、さまざまな機械学習手法を使用してこれらの問題を解決できるようになります。 AIアルゴリズムのビッグデータプラットフォームへの適用を実現 データフィードバック。

5. ビッグデータ ガバナンスにおける AI アルゴリズムの適用の見通し

最後に、私たちは、ビッグデータにおける AI アルゴリズムのアプリケーション データ ガバナンスにおけるアプリケーション シナリオ。

# 上記で紹介した 3 つのアプリケーション シナリオは、データ処理段階に集中しています。実際、第 1 章で説明した AI とビッグデータの関係を反映すると、AI はデータのライフサイクル全体を通じて比較的良い役割を果たすことができます。

たとえば、データ収集段階でログが妥当かどうかを判断したり、送信中に侵入検知をしたり、処理中に侵入検知をしたりすることができます。コストのさらなる削減と効率の向上、交換する場合はデータのセキュリティを確保するための作業、破棄する場合は破棄のタイミングとそれに伴う影響を判断するなどの作業が可能です。ビッグ データ プラットフォームにおける AI の応用シナリオは数多くありますが、これはほんの紹介にすぎません。 AI とビッグデータの相互支援関係は将来さらに顕著になると考えられており、AI 支援ビッグデータ プラットフォームはデータの収集と処理を改善し、データ品質の向上によりより優れた AI モデルのトレーニングが可能になり、優れたサイクル。

#6. 質疑応答セッション

#Q1: どのような種類のルール エンジンが使用されていますか? オープン ソースですか?

A1: ここでのいわゆるパラメーター調整ルールは、タスクの実行時間など、手動調整の経験に基づいて、初期段階でビッグデータ担当者によって策定されました。時間が超過しているか、処理されたデータの量がどのくらい超過しているか、タスクに推奨されるコアまたはメモリの数など。これは長期間にわたって蓄積された一連のルールであり、オンライン化後は比較的良好な結果が得られるため、この一連のルールを使用してパラメーター推奨モデルをトレーニングします。

Q2: 従属変数はパラメータの調整のみですか?ビッグデータプラットフォームのパフォーマンスの不安定性が計算結果に与える影響を考慮したことがありますか?

#A2: パラメーターを推奨する場合、単に低コストを追求することはありません。そうしないと、推奨されるリソースが少なくなり、タスクが失敗します。従属変数にはパラメータ調整のみがありますが、不安定性を防ぐために追加の制限を追加します。 1 つ目はモデルの特性です。特定の日の値ではなく、一定期間の平均値を選択します。2 つ目は、モデルが推奨するパラメータについて、実際の設定値との差を比較します。差が大きすぎる場合、過剰な 1 回調整によるミッション失敗を避けるために、スローアップおよびスローダウン戦略を使用します。

#Q3: 回帰モデルとベイジアン モデルは同時に使用されますか?

#A3: いいえ。先ほど述べたように、パラメーターの推奨には 2 つのソリューションを使用しました: 回帰モデルはルールの学習に使用され、ベイジアン最適化フレームワークは後で使用されます。同時に使用することはありません。2 回の試みを行いました。前者の学習ルールの利点は、過去の経験をすぐに利用できることであり、2 番目のモデルは、前のモデルに基づいて、より優れた、または最適な構成を見つけることができることです。これら 2 つは同時に使用されるのではなく、連続的または漸進的な関係に属します。

#Q4: セマンティック分析の導入は、さらなる機能の拡張に基づいていますか?

#A4: はい。先ほど述べたように、Spark パラメーターの調整を行うときに使用する情報は履歴の実行ステータスだけですが、Spark タスク自体にはまだ注意を払っていません。実際、Spark 自体には、さまざまなオペレーター、ステージなどを含む多くの情報が含まれています。そのセマンティクスを分析しないと、多くの情報が失われます。したがって、次の計画は、Spark タスクのセマンティクスを分析し、パラメーター計算を支援する機能をさらに拡張することです。

#Q5: パラメーターの推奨が不合理で、タスクの異常や失敗が発生することはありますか? では、そのようなシナリオで異常なタスクのエラーやタスクの変動を減らすにはどうすればよいでしょうか?

A5: モデルに完全に依存している場合は、リソース使用率の可能な限り最高の改善を追求している可能性があります。この場合、推奨されるパラメーターは、次のようにより積極的になる可能性があります。 as メモリが30gから5gに急減しました。したがって、モデルの推奨に加えて、パラメーター調整スパンが何 g を超えてはいけないなどの追加の制約、つまりスローアップおよびスローダウン戦略を追加します。

Q6: シグモイド 2022 のパラメータ調整に関する記事がいくつかあります。参考になるものはありますか?

#A6: インテリジェントなタスク パラメーターの調整は、依然として比較的人気のある研究方向であり、さまざまな分野のチームがさまざまな方法モデルを採用しています。私たちは、あなたが言及したシグモイド 2022 論文を含め、これを開始する前に多くの業界の手法を調査しました。比較と実践を経て、最終的には共有した 2 つのソリューションを試しました。今後もこの方向の最新動向に注目し、レコメンド効果を高めるためのさらなる工夫をしていきたいと考えております。 今日の共有はこれで終わりです。皆さん、ありがとうございました。

以上がビッグデータガバナンスにおけるAIアルゴリズムの応用の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。