人工知能シナリオにおける HBase の使用

人工知能シナリオにおける HBase の使用

近年、人工知能は、特にビッグデータと組み合わせて使用​​されることで、ますます人気が高まっています。人工知能の主なシナリオには、画像機能、音声機能、自然言語処理機能、ユーザーポートレート機能などがあります。これらのシナリオでは、大量のデータを処理する必要があり、処理されたデータは一般的に保存する必要があります。このデータの特徴は主に次のとおりです。

大規模:データ量が多いほど、その後のモデリングに有利になります。

スパース:各データ行には異なる属性がある場合があります。たとえば、ユーザー プロファイル データでは、各人が異なる属性を持つ場合があります。ユーザー A はこの属性を持っている可能性がありますが、ユーザー B は持っていない可能性があります。ストレージ システムがこの状況に対処できることを期待します。存在しない属性は最下層のスペースを占有しないため、多くのスペースを節約できます。

列の動的な変更:データの各行には異なる数の列があります。

人工知能のシナリオにおける HBase の使用をよりよく紹介するために、以下では人工知能業界の顧客事例を使用して、HBase を使用して顔の特徴をすばやく検索するシステムを設計する方法を分析します。

[[250188]]

現在、同社の業務シナリオには顔に関する特徴データが多数含まれており、その総数は3,400万点を超え、顔データ1つあたりの数は約3.2kに上ります。これらの顔データは多くのグループに分かれており、それぞれの顔の特徴は特定のグループに属します。現在、顔グループは合計で約 620,000 個あります。各グループに含まれる顔の数は 1 から 10,000 個です。各グループには、同じ人物の異なる形式の顔データが含まれています。グループと顔の分布は次のとおりです。

  • 約 43% のグループには 1 つの顔データが含まれています。
  • 約 47% のグループには 2 ~ 9 個の顔データが含まれています。
  • 残りのグループの顔の数は 10 から 10,000 の範囲です。

現在のビジネスニーズは、主に次の 2 つのカテゴリに分けられます。

  • 顔グループ ID に従ってグループ内のすべての顔を検索します。
  • 顔グループ ID + 顔 ID に基づいて顔の特定のデータを検索します。

MySQL + OSS ソリューション

従来、業務データの量が比較的少なかった頃は、主にMySQLやOSS(オブジェクトストレージ)が利用されていました。関連するテーブルには、主に顔グループ テーブルと顔テーブルが含まれます。表の形式は次のとおりです。

グループテーブル:

[[250189]]

フェイステーブル:

特徴サイズは3.2kで、これはbase64で保存されたバイナリデータです。これが実際の顔の特徴データです。

これで、顔グループ ID と顔 ID の対応が上記のグループ テーブルに対応して MySQL に保存され、顔 ID と顔関連の特徴データが上記の顔テーブルに対応して OSS に保存されます。

各顔グループに含まれる人間の特徴の数は大きく異なるため(1〜10,000)、上記のテーブル設計に基づいて、顔グループと各顔特徴IDを各行に格納する必要があります。この場合、同じ顔グループに属するデータは、実際にはMySQLの多くの行に格納されます。たとえば、特定の顔グループ ID に対応する顔の特徴の数が 10,000 個の場合、MySQL に 10,000 行を保存する必要があります。

顔グループ ID の下にあるすべての顔を見つける必要がある場合は、次の図の左側に示すように、MySQL から多数のデータ行を読み取り、顔グループと顔の対応関係を取得し、顔 ID に基づいて OSS 内のすべての顔関連の特徴データを取得する必要があります。

上の図のクエリ パスから、このようなクエリでは非常に長いリンクが生成されることがわかります。上記の設計から、クエリ対象のグループに多数の顔が含まれている場合、MySQL から多数の行をスキャンし、OSS からこれらの顔の特徴データを取得する必要があることがわかります。全体のクエリ時間は約 10 秒で、既存のビジネスの迅速な開発のニーズを満たすにはほど遠いものです。

HBase ソリューション

上記の設計には 2 つの問題があります。

  • データ自体のサイズにより、同じデータの内容を 1 行に保存することはできないため、後続のクエリでは 2 つのストレージ システムにアクセスする必要があります。
  • MySQL は動的列をサポートしていないため、同じ面グループに属するデータは複数の行に格納されます。

上記の 2 つの問題を分析した結果、次の理由から、これが HBase の典型的なシナリオであると結論付けました。

  • HBase には動的な列機能があり、数兆行と数百万列をサポートします。
  • HBase は複数のバージョンをサポートしており、すべての変更は HBase に記録されます。
  • HBase 2.0 では、小さなファイルのストレージをサポートするために MOB (中サイズ オブジェクト) 機能が導入されました。 HBase の MOB 機能は、画像、短いビデオ、ドキュメントなど、1k ~ 10 MB の範囲のファイルを対象としています。低レイテンシ、強力な読み取り/書き込み一貫性、強力な検索機能、簡単な水平拡張などの主要な機能を備えています。

これら 3 つの機能を使用して、上記の MySQL + OSS ソリューションを再設計できます。上記のアプリケーションシナリオの 2 つのクエリ要件を組み合わせると、顔グループ ID を HBase の Rowkey として使用できます。システム設計は、上図の右側に示されています。テーブルを作成するときは、次のように MOB 機能をオンにします。

  1. 作成する  'face' 、{ NAME => 'c' 、IS_MOB => true 、MOB_THRESHOLD => 2048}

上記では、face という名前のテーブルを作成しました。IS_MOB 属性は、列クラスター c が MOB 機能を有効にすることを示します。MOB_THRESHOLD は、MOB ファイル サイズのしきい値 (バイト単位) です。ここでの設定は、2k を超える列が小さなファイルとして保存されることを示します。上記の元のソリューションでは OSS オブジェクト ストレージが使用されていることにお気づきかもしれません。顔の特徴データを保存するために OSS を直接使用しないのはなぜでしょうか。この疑問がある場合は、次の表のパフォーマンス テストを確認してください。

上記の比較に基づくと、10 MB 未満のオブジェクトを格納するために HBase MOB 機能を使用すると、オブジェクト ストレージを直接使用するよりもいくつかの利点があります。

次に、以下に示す具体的なテーブル設計を見てみましょう。

上記の HBase テーブルの列クラスター名は c であり、列名として顔 ID を使用します。前のアスペクトの 3 つのテーブルを置き換えるために、1 つの HBase テーブルのみを使用しました。MOB を有効にしましたが、具体的な挿入方法は通常の使用と同じです。コード スニペットは次のとおりです。

  1. 文字列 CF_DEFAULT = "c" ;
  2. Put put = new Put(groupId.getBytes());
  3. 列を追加します(CF_DEFAULT.getBytes()、faceId1.getBytes()、feature1.getBytes());
  4. 列を追加します(CF_DEFAULT.getBytes()、faceId2.getBytes()、feature2.getBytes());
  5. 列を追加します(CF_DEFAULT.getBytes()、faceIdn.getBytes()、featuren.getBytes());
  6. テーブル.put(put);

ユーザーが顔グループ ID に基づいてすべての顔のデータを取得する必要がある場合は、次の方法を使用できます。

  1. get = new Get(groupId.getBytes()); を取得します。
  2. 結果 re = table .get(get);

このようにして、特定の顔グループ ID に対応するすべての顔データを取得できます。顔グループ ID + 顔 ID に基づいて顔の特定のデータを検索する必要がある場合は、次の方法を使用できます。

  1. get = new Get(groupId.getBytes()); を取得します。
  2. get.addColumn(CF_DEFAULT.getBytes(), faceId1.getBytes())
  3. 結果 re = table .get(get);

上記の変換後、2 つの HBase ワーカー ノードのメモリは 32​​ GB、コア数は 8、各ノードには 4 つの 250 GB SSD ディスクが搭載され、100 万行が書き込まれ、各行には 10,000 列があり、行の読み取り時間は約 100 ミリ秒〜 500 ミリ秒です。各行に 1,000 個の顔がある場合、行の読み取り時間は約 20 ~ 50 ミリ秒となり、以前の 10 秒の 200 ~ 500 倍の高速化になります。

以下は各ソリューションのパフォーマンスの比較です。

Sparkを使用してデータ分析を加速する

顔の特徴データを Alibaba Cloud HBase に保存しました。これはデータ応用の第一歩にすぎません。このデータの背後に隠された価値をどのように引き出すことができるでしょうか。これにはデータ分析の助けが必要です。このシナリオでは、機械学習の手法を使用してクラスタリングなどの操作を実行する必要があります。 Spark を使用して HBase に保存されているデータを分析することができ、Spark 自体も機械学習をサポートしています。ただし、オープンソースの Spark を直接使用して HBase のデータを読み取ると、HBase 自体の読み取りと書き込みに影響します。

これらの問題に対処するため、Alibaba Cloud HBase チームは、HFile を直接読み取ったり、演算子をシンクしたりするなど、Spark を最適化しました。また、SQL サービス ThriftServer とジョブ サービス LivyServer を通じて Spark の使用を簡素化する、完全に管理された Spark 製品も提供しています。現在の Spark テクノロジー スタックを下図に示します。

Spark サービスを通じて、HBase とうまく統合し、リアルタイム ストリームと顔の特徴マイニングを統合できます。全体のアーキテクチャ図は次のとおりです。

さまざまな顔データ ソースからリアルタイム データを収集し、Spark Streaming を通じて簡単な ETL 操作を実行できます。次に、Spark MLib ライブラリを使用して、収集したデータに対して顔の特徴マイニングを実行し、最後にマイニング結果を HBase に保存します。 *** ユーザーは、他のアプリケーションのために HBase でマイニングされた顔の特徴データにアクセスできます。

<<:  ライトゲーム革命をリードし続けるCheetah Mobile、第3四半期のモバイルゲームの成長率は前年比77.8%で過去最高を記録

>>:  アシモフのロボット工学三原則とモービルアイの自動運転五原則

ブログ    
ブログ    
ブログ    
ブログ    
ブログ    

推薦する

...

xAI Twitterライブ放送:GoogleやOpenAIと直接競合する

人工知能の波に直面して、マスク氏はついに再び行動を起こした! 7月15日、マスク氏とxAI創設チーム...

AIがあなたをビデオから消去しました!効果はシルキーで跡が残りません

この記事はAI新メディアQuantum Bit(公開アカウントID:QbitAI)より許可を得て転載...

...

ベクトル検索エンジン: 大規模な言語モデルの検索と強化された生成のための強力なツール

翻訳者|朱 仙中レビュー | Chonglou導入大規模言語モデル (LLM) が世界を席巻するにつ...

...

大規模言語モデルの量子化手法の比較: GPTQ、GGUF、AWQ

大規模言語モデル (LLM) は過去 1 年間で急速に進化しており、この記事では (量子化) へのい...

欧州が癌治療における人工知能の新基準を設定

EUCAIM (EUropean Federation for CAncer IMages) プロジ...

言語間、人間の声と犬の鳴き声の相互変換をサポートし、最も近いものだけを使用するシンプルな音声変換モデルはどれほど素晴らしいか

AIが関わる音声の世界はまさに魔法のようです。ある人の声を別の人の声に置き換えるだけでなく、動物と声...

...

人工知能は偏見を排除するのに役立ちますか?

「私たちは物事をあるがままに見ているのではなく、私たちが見ているように見ているのです。」彼女は、私...

...

AIアルゴリズムが軍用無人車両への中間者攻撃を検出

研究者らは、軍用無人車両に対する中間者攻撃を検出できる人工知能アルゴリズムを開発した。ロボットオペレ...

...