最新のデータ インフラストラクチャ向けの新たなアーキテクチャ

過去 1 年間で、ほぼすべての主要な業界指標が過去最高を記録し、ほとんどのデータ チームが合理的に追跡できるよりも早く新しい製品カテゴリーが出現しました。この記事では、一連のデータ インフラストラクチャが公開されています。これらは、現在の分析とオペレーティング システムに最も関連するコンポーネントを紹介します。

1. リファレンスアーキテクチャ

すべてのデータ インフラストラクチャのユースケースの統合概要:

 

情報元 収集と変換 保管所 分析と処理 変換 分析と出力
関連するビジネスデータと実用的なデータを生成する 1) 既存のビジネス システムからデータを抽出
2) ストレージへの転送、ソースとターゲット間の調整スキーム (L)
3) 分析データを必要なビジネス システムに転送

クエリおよび処理システムがアクセスできる形式でデータを保存します。

データの一貫性、パフォーマンスを最適化し、コストとスケールを削減します。 
高頻度コード (SQL、Python、Java、scala) をメンテナンスの少ないデータ処理ジョブに変換します。

分散コンピューティングを使用してクエリとデータ モデルを実行する

履歴分析と予測分析の両方を組み込む
    データを分析用の構造化データに変換する

データ変換アーキテクチャの処理リソースを計画する
意思決定者またはデータ分析科学に洞察と協力を提供し、

結果を表示する一連の

インターフェイス ユーザー アプリケーションにデータ モデルを埋め込む

機械学習後にアーキテクチャ設計を拡張します。

データ変換 モデルのトレーニングと開発 モデルインターフェース 統合
大まかなデータを、教師あり学習やラベル付けなどのモデル トレーニングに使用できるデータに変換します。 処理されたデータに基づいてモデルをトレーニングします - 通常、公開データ コーパスに事前トレーニングされたモデルのオントロジーを構築します

入力データ、使用されるスーパーパワー メーター、反復ループの一部としての

最終モデルのパフォーマンス

、モデルのパフォーマンスの監査、分析、検証を含む実験とモデルのトレーニングプロセスを追跡します多くの場合、再トレーニングや追加のデータ収集と処理が必要になります

関連するハードウェア ターゲットにコンパイルし、推論フェーズ中にアクセスできるように保存することで、トレーニングされたモデルをデプロイメント用に準備します


入力データに基づいてトレーニング モデルをリアルタイム (オンライン) またはバッチ (オフライン) で実行します。データ ドリフト、有害な予測、パフォーマンスの低下などについて実稼働モデルを監視します。
構造化された反復可能な方法で、モデルの出力をユーザー向けアプリケーションに統合します。

分析エコシステムと運用エコシステムの両方が成長し続けています。Snowflake などのクラウド データ ウェアハウスは、主に SQL ユーザーとビジネス インテリジェンスのユースケースに焦点を当てて急速に成長しています。しかし、他のテクノロジーの導入も加速しており、たとえば Databricks などのデータ ウェアハウスは、これまで以上に急速に顧客を増やしています。私たちが話を聞いたデータ チームの多くは、データ スタックに異種性が残る可能性が高いことを認めました。

他のコア データ システム (つまり、取り込みと変換) も同様に耐久性があることが証明されています。これは、Fivetran と dbt (または同様のテクノロジ) の組み合わせがほぼ普及している最新のビジネス インテリジェンス モデルで特に顕著です。しかし、これはオペレーティング システムにもある程度当てはまり、Databricks/Spark、Confluent/Kafka、Astronomer/Airflow などの事実上の標準が出現します。

ブループリント 1: 最新のビジネス インテリジェンス アプリケーション

あらゆる規模の企業向けのクラウドネイティブなビジネス インテリジェンス

 

変わっていないこと:

データ レプリケーション (Fivetran など)、クラウド データ ウェアハウス (Snowflake など)、SQL ベースのデータ モデリング (dbt を使用) の組み合わせが、引き続きこのパターンの中核を形成します。これらのテクノロジーの採用は大幅に増加し、Airbyte や Firebolt などの新しい競合他社の資金調達と早期成長を促進しました。

ダッシュボードは、Looker、Tableau、PowerBI、Superset などの新規参入者を含め、依然として出力層で最も使用されているアプリケーションです。

新機能:

メトリクス レイヤー (データ ウェアハウス上に標準の定義セットを提供するシステム) には多くの関心が集まっています。これにより、どのような機能を搭載すべきか、どのベンダーが搭載すべきか、どのような仕様に従うべきかについて、激しい議論が巻き起こりました。これまでのところ、いくつかの堅固な純粋なプレイ製品 (Transform や Supergran など) と、このカテゴリへの dbt の拡張を見てきました。

リバース ETL ベンダー、特に Hightouch と Census が大幅に成長しました。これらの製品の目的は、データ ウェアハウスからの出力や洞察を使用して CRM や ERP などの運用システムを更新することです。

データ チームは、標準ダッシュボード、特に Hex などのデータ ワークスペースを強化するための新しいアプリケーションに強い関心を示しています。大まかに言えば、新しいアプリケーションは、クラウド データ ウェアハウスの標準化が進んだ結果である可能性が高く、データが明確に構造化されてアクセスできるようになると、データ チームは自然にそれをさらに活用したくなるでしょう。

データ発見および可観測性を備えた企業が急増し、多額の資金を調達しました (特にモンテカルロと Bigeye)。これらの製品の利点 (より信頼性の高いデータ パイプラインとより優れたコラボレーション) は明らかですが、顧客が関連するユースケースと予算を見つけると、導入は比較的早い段階で行われます。(技術的なメモ: Select Star、Metaphor、Stemma、Secoda、Castor など、データ ディスカバリ分野では堅実な新興ベンダーがいくつかありますが、シード段階の企業はチャートから除外しています。)

ブループリント 2: マルチモーダル データ処理

分析および運用のユースケースをサポートする進化するデータ レイク – 最新のインフラストラクチャに対する Hadoop 難民としても知られています

明るいボックスは新しいまたは意味のある変更であり、明るいボックスはほとんど変更されていません。灰色のボックスは、このブループリントとの関連性が低いと考えられます。

 

変わっていないこと:

データ処理 (Databricks、Starburst、Dremio など)、送信 (Confluent や Airflow など)、ストレージ (AWS) のコア システムは急速に成長し続けており、このブループリントのバックボーンを形成しています。

マルチモーダル データ処理では設計の多様性が維持され、企業は分析および運用データ アプリケーションにおける特定のニーズに最適なシステムを導入できます。

新機能:

データ レイクの基礎となるアーキテクチャについては、ますます受け入れられ、明確になりつつあります。このアプローチは、さまざまなベンダー (AWS、Databricks、Google Cloud、Starburst、Dremio など) やデータ ウェアハウスのパイオニアによってサポートされています。Lakehouse の基本的な価値は、強力なストレージ レイヤーと一連の強力なデータ処理エンジン (Spark、Presto、Druid/Clickhouse、Python ライブラリなど) を組み合わせることです。

ストレージ層自体がアップグレードされています。Delta、Iceberg、Hudi などのテクノロジーは新しいテクノロジーではありませんが、急速に採用され、商用製品に組み込まれています。これらのテクノロジーの一部 (特に Iceberg) は、Snowflake などのクラウド データ ウェアハウスとも相互運用します。異種混合が続くと、これがマルチモーダル データ スタックの重要な部分になる可能性があります。

ストリーム処理 (つまり、リアルタイムの分析データ処理) の採用が増加する可能性があります。Flink のような第一世代のテクノロジーはまだ主流になっていませんが、Materize や Upsolver のようなよりシンプルなプログラミング モデルを備えた新規参入者が早期に採用され始めており、興味深いことに、既存の Databricks や Confluent の使用法によるストリーム処理製品も高速化し始めています。

 

ブループリント 3: 人工知能と機械学習

機械学習モデルの堅牢な開発、テスト、運用のためのアーキテクチャ

変わっていないこと:

2020 年と比較すると、現在、モデル開発用のツールは、主要なクラウド プロバイダー (Databricks や AWS など)、ML フレームワーク (XGBoost や PyTorch など)、実験管理ツール (Weights&Biases や Comet など) など、ほぼ同様になっています。

実験管理では、モデルの視覚化と調整が事実上、別のカテゴリに追いやられてきました。

機械学習スタックの構築と運用は複雑で、専門知識が必要です。この青写真は気の弱い人向けではなく、AI の製品化は多くのデータ チームにとって依然として課題です。

新機能:

ML 業界はデータ中心のアプローチを中心に統合しており、段階的なモデリングの改善よりも複雑なデータ管理を重視しています。これにはいくつかの影響があります。

データ ラベル (Scale や Labelbox など) の急速な成長、および主に Tesla の Autopilot データ パイプラインに基づく閉ループ データ エンジンへの関心の高まり。

バッチとリアルタイムの両方のユースケースで、運用グレードの ML データを共同開発する方法である Tecton などのフィーチャ ストアの採用が増加しています。

ML モデリング プロセスを少なくとも部分的に自動化する、Continuous や MindsDB などのローコード ML ソリューションに新たな関心が集まっています。これらの更新されたソリューションは、新しいユーザー (アナリストやソフトウェア開発者など) を ML 市場に呼び込むことに重点を置いています。

特に NLP では、事前トレーニング済みモデルの使用がデフォルトになりつつあり、OpenAI や Hugging Face などの企業に追い風を与えています。微調整、コスト、スケーリングに関しては、対処すべき興味深い問題がまだあります。

ML の運用ツール (MLops とも呼ばれる) はより成熟しており、ML モニタリング、最も需要の高いユースケース、当面の予算を中心に構築されています。同時に、さまざまな新しい運用ツール、特に検証と監査が登場しており、最終的な市場はまだ決定されていません。

OpenAI などの事前構築 API、Pinecone などのベクトル データベース、洞察力に優れたフレームワークなどを介して、開発者が ML モデルをアプリケーションにシームレスに統合する方法に注目が集まっています。

 

おすすめ

転載: blog.csdn.net/shishi521/article/details/129261059