毎日、Amazon のデバイスは、世界中の配送、在庫、容量、供給、販売、マーケティング、生産者、カスタマー サービス チームからの数十億件のトランザクションを処理および分析しています。 このデータは、Amazon の顧客の要求を満たすためにデバイスの在庫を調達する際に使用されます。 データ量が前年比で 2021 桁の成長率を示し、XNUMX 年には COVID のパンデミックがグローバル ロジスティクスを混乱させたため、ほぼリアルタイムのデータをスケーリングして生成することがより重要になりました。
この投稿では、複数のソースとさまざまな形式から自動的にデータを消費する、AWS 上に構築されたサーバーレス データ レイクに移行した方法を示します。 さらに、データ サイエンティストとエンジニアが AI と機械学習 (ML) サービスを使用してデータを継続的にフィードし、分析する機会がさらに生まれました。
課題と設計上の懸念事項
主に使用される従来のアーキテクチャ アマゾン エラスティック コンピューティング クラウド (Amazon EC2) を組み合わせて、さまざまな内部異種データ ソースと REST API からデータを抽出します。 Amazon シンプル ストレージ サービス (Amazon S3) にデータをロードし、 Amazonレッドシフト さらに分析し、発注書を生成するため。
このアプローチにはいくつかの欠陥があることがわかったため、次の領域で改善が促進されました。
- 現像速度 – 実行時障害の主な原因であるスキーマの統合と発見が行われていないため、開発者は多くの場合、運用と保守の問題に対処するのに時間を費やしていました。
- スケーラビリティ – これらのデータセットのほとんどは、世界中で共有されています。 したがって、データのクエリ中にスケーリングの制限を満たす必要があります。
- 最小限のインフラストラクチャ メンテナンス – 現在のプロセスは、データ ソースに応じて複数の計算にまたがっています。 したがって、インフラストラクチャのメンテナンスを減らすことが重要です。
- データ ソースの変更に対する応答性 – 現在のシステムは、さまざまな異種データ ストアおよびサービスからデータを取得します。 これらのサービスの更新には、数か月の開発サイクルが必要です。 これらのデータ ソースの応答時間は、主要な利害関係者にとって重要です。 したがって、高性能アーキテクチャを選択するには、データ駆動型のアプローチを採用する必要があります。
- ストレージと冗長性 – 異種のデータ ストアとモデルが原因で、さまざまなビジネス関係者チームからのさまざまなデータセットを格納することが困難でした。 したがって、比較する増分データと差分データとともにバージョニングを行うことで、より最適化された計画を生成する優れた機能が提供されます。
- 逃亡者とアクセシビリティ – ロジスティクスの不安定な性質のため、一部のビジネス関係者チームは、オンデマンドでデータを分析し、発注書のほぼリアルタイムの最適な計画を生成する必要があります。 これにより、ほぼリアルタイムでデータにアクセスして分析するために、データのポーリングとプッシュの両方が必要になります。
実装戦略
これらの要件に基づいて、戦略を変更し、ソリューションを特定するために各問題の分析を開始しました。 アーキテクチャ的には、サーバーレス モデルを選択しました。データ レイク アーキテクチャのアクション ラインは、改善の一部であると判断したすべてのアーキテクチャのギャップと挑戦的な機能を指します。 運用上の観点から、データ取り込みのための新しい共有責任モデルを設計しました。 AWSグルー データを抽出するために Amazon EC2 で設計された内部サービス (REST API) の代わりに。 私たちも使用しました AWSラムダ データ処理用。 それから私たちは選びました アマゾンアテナ 私たちのクエリサービスとして。 データ コンシューマの開発速度をさらに最適化および改善するために、次のように追加しました。 Amazon DynamoDB データ レイクに到達するさまざまなデータ ソースのメタデータ ストアとして。 これら XNUMX つの決定は、私たちが行ったすべての設計と実装の決定に影響を与えました。
次の図は、アーキテクチャを示しています
次のセクションでは、プロセス フローを進めながら、アーキテクチャ内の各コンポーネントを詳しく見ていきます。
ETL 用の AWS Glue
新しいビジネスのデータ ソースの規模をサポートしながら顧客の要求を満たすには、さまざまなデータ ソースのクエリにおいて高度な機敏性、スケーラビリティ、応答性を備えていることが重要でした。
AWS Glue は、分析ユーザーが複数のソースからデータを簡単に検出、準備、移動、統合できるようにするサーバーレス データ統合サービスです。 分析、ML、およびアプリケーション開発に使用できます。 また、オーサリング、ジョブの実行、およびビジネス ワークフローの実装のための追加の生産性および DataOps ツールも含まれています。
AWS Glue を使用すると、70 を超える多様なデータソースを検出して接続し、一元化されたデータカタログでデータを管理できます。 抽出、変換、読み込み (ETL) パイプラインを視覚的に作成、実行、監視して、データをデータ レイクに読み込むことができます。 また、Athena を使用して、カタログ化されたデータをすぐに検索およびクエリできます。 アマゾンEMR, AmazonRedshiftスペクトラム.
AWS Glue を使用すると、さまざまなデータストアのデータに簡単に接続し、必要に応じてデータを編集およびクリーニングし、AWS がプロビジョニングしたストアにデータをロードして統一されたビューを表示できます。 AWS Glue ジョブをオンデマンドでスケジュールまたは呼び出して、クライアントのリソースおよびデータレイクからデータを抽出できます。
これらのジョブの責任の一部は次のとおりです。
- ソース エンティティの抽出とデータ エンティティへの変換
- 年、月、日を含むようにデータを強化してカタログ化を改善し、スナップショット ID を含めてクエリを改善する
- Amazon S3 の入力検証とパス生成を実行する
- ソースシステムに基づいて認定されたメタデータを関連付けます
内部サービスから REST API を照会することは、私たちの主要な課題の XNUMX つであり、インフラストラクチャが最小限であることを考慮して、このプロジェクトでそれらを使用したいと考えました。 AWS Glue コネクタは、要件と目標を順守するのに役立ちました。 REST API やその他のデータ ソースからデータをクエリするために、PySpark と JDBC モジュールを使用しました。
AWS Glue は、さまざまな接続タイプをサポートしています。 詳細については、を参照してください。 AWS Glue での ETL の接続タイプとオプション.
ランディング ゾーンとしての S3 バケット
抽出されたデータの直接のランディング ゾーンとして S3 バケットを使用し、さらに処理して最適化しました。
AWS Glue ETL トリガーとしての Lambda
S3 バケットで S3 イベント通知を有効にして Lambda をトリガーし、データをさらに分割しました。 データは、InputDataSetName、Year、Month、および Date で分割されます。 このデータ上で実行されるクエリ プロセッサは、データのサブセットのみをスキャンして、コストとパフォーマンスを最適化します。 データは、CSV、JSON、Parquet などのさまざまな形式で保存できます。
生データは、多くの場合、重複または不適切なデータ型が含まれているため、最適な計画を生成するためのほとんどのユース ケースには理想的ではありません。 最も重要なことは、データが複数の形式になっていることですが、すぐにデータを変更したところ、Parquet 形式を使用することでクエリのパフォーマンスが大幅に向上することがわかりました。 ここでは、パフォーマンスに関するヒントの XNUMX つを使用しました。 Amazon Athena のパフォーマンス調整のヒントトップ 10.
ETL の AWS Glue ジョブ
データの分離とアクセシビリティを改善したかったため、パフォーマンスをさらに向上させるために別の S3 バケットを使用することにしました。 同じ AWS Glue ジョブを使用して、データをさらに変換して必要な S3 バケットにロードし、抽出されたメタデータの一部を DynamoDB にロードしました。
メタデータストアとしての DynamoDB
データが得られたので、さまざまなビジネス関係者がさらにそれを使用します。 これにより、データ レイクに存在するソース データとそのバージョンという XNUMX つの疑問が残ります。 DynamoDB をメタデータ ストアとして選択しました。DynamoDB は、データを効果的にクエリするために最新の詳細をコンシューマーに提供します。 システム内のすべてのデータセットは、メタデータ ストアから検索できるスナップショット ID によって一意に識別されます。 クライアントは、API を使用してこのデータ ストアにアクセスします。
データレイクとしての Amazon S3
データ品質を向上させるために、強化されたデータを同じ AWS Glue ジョブで別の S3 バケットに抽出しました。
AWS グルー クローラー
クローラは、スキーマの変更に対応できるようにする「秘密のソース」です。 プロセス全体を通して、各ステップを可能な限りスキーマに依存しないようにすることを選択しました。これにより、スキーマの変更が AWS Glue に到達するまで通過できるようになります。 クローラーを使用すると、スキーマに発生する不可知論的な変更を維持できます。 これにより、Amazon S3 からデータを自動的にクロールし、スキーマとテーブルを生成することができました。
AWSGlueデータカタログ
Data Catalog は、Amazon S3 内のデータの場所、スキーマ、ランタイム メトリクスへのインデックスとしてカタログを維持するのに役立ちました。 Data Catalog の情報はメタデータ テーブルとして格納され、各テーブルは単一のデータ ストアを指定します。
SQL クエリ用の Athena
Athena は、標準 SQL を使用して Amazon S3 のデータを簡単に分析できるインタラクティブなクエリ サービスです。 Athena はサーバーレスであるため、管理するインフラストラクチャはなく、実行したクエリに対してのみ料金が発生します。 主な改善要因として、運用の安定性と開発速度の向上を考慮しました。
以下を作成することで、ユーザーが値とクエリをプラグインして Athena からデータを取得できるように、Athena にクエリを実行するプロセスをさらに最適化しました。
- An AWSクラウド開発キット (AWS CDK) テンプレートを使用して Athena インフラストラクチャを作成し、 AWS IDおよびアクセス管理 任意のアカウントからデータ レイク S3 バケットとデータ カタログにアクセスするための (IAM) ロール
- クライアントが IAM ロール、クエリ、データ形式、および出力場所を提供して、Athena クエリを開始し、選択したバケットで実行されたクエリのステータスと結果を取得できるようにするためのライブラリ。
Athena にクエリを実行するには、次の XNUMX 段階のプロセスがあります。
- StartQueryExecution – これにより、クエリの実行が開始され、実行 ID が取得されます。 ユーザーは、クエリの出力が保存される出力場所を指定できます。
- GetQuery実行 – 実行が非同期であるため、クエリのステータスを取得します。 成功したら、S3 ファイルまたは経由で出力をクエリできます。 API.
クエリの実行を開始して結果を取得するためのヘルパー メソッドは、ライブラリにあります。
データレイク メタデータ サービス
このサービスはカスタム開発されており、DynamoDB とやり取りしてメタデータ (データセット名、スナップショット ID、パーティション文字列、タイムスタンプ、およびデータの S3 リンク) を REST API の形式で取得します。 スキーマが検出されると、クライアントは Athena をクエリ プロセッサとして使用してデータをクエリします。
スナップショット ID を持つすべてのデータセットがパーティション分割されているため、結合クエリはフル テーブル スキャンではなく、Amazon S3 でのパーティション スキャンのみになります。 Athena はクエリ インフラストラクチャの管理を容易にするため、クエリ プロセッサとして使用しました。 後で、さらに何かが必要だと感じた場合は、Redshift Spectrum または Amazon EMR を使用できます。
まとめ
Amazon Devices チームは、AWS Glue を使用してデータレイク アーキテクチャに移行することで大きな価値を発見しました。これにより、複数のグローバル ビジネス関係者がより生産的な方法でデータを取り込むことができるようになりました。 これにより、チームは適切なビジネス ロジックを使用してほぼリアルタイムでさまざまなデータセットを分析し、サプライ チェーン、需要、および予測の問題を解決することで、デバイスの発注を行うための最適な計画を生成できるようになりました。
運用上の観点からは、投資はすでに成果を上げ始めています。
- 取り込み、保存、取得のメカニズムが標準化され、オンボーディング時間が短縮されました。 このシステムを実装する前は、1 つのデータセットをオンボードするのに 15 か月かかりました。 新しいアーキテクチャのおかげで、2 か月足らずで 70 個の新しいデータセットをオンボードすることができ、アジリティが XNUMX% 向上しました。
- スケーリングのボトルネックが取り除かれ、数千回の実行に迅速にスケーリングできる均質なシステムが作成されました。
- このソリューションは、入力を受け入れる前にスキーマとデータ品質の検証を追加し、データ品質違反が発見された場合はそれらを拒否しました。
- これにより、将来のシミュレーションやバージョン管理された入力を必要とするバックテスターのユースケースをサポートしながら、データセットを簡単に取得できるようになりました。 これにより、モデルの起動とテストがより簡単になります。
- このソリューションは、データの取り込み、ストレージ、および取得のユース ケースで同様の問題を抱えている DIAL 全体の他のチームに簡単に拡張できる共通のインフラストラクチャを作成しました。
- 運用コストはほぼ 90% 削減されました。
- このデータ レイクは、当社のデータ サイエンティストやエンジニアが効率的にアクセスして、他の分析を実行し、将来の機会として予測アプローチを使用して、発注書の正確な計画を生成することができます。
この投稿の手順は、AWS マネージド サービスを使用して同様の最新のデータ戦略を構築し、さまざまなソースからデータを取り込み、メタデータ カタログを自動的に作成し、データ レイクとデータ ウェアハウスの間でシームレスにデータを共有し、イベントでアラートを作成するのに役立ちます。オーケストレーションされたデータ ワークフローの失敗。
著者について
アビナッシュ・コルリ AWS のシニア ソリューション アーキテクトです。 彼は、Amazon Alexa とデバイスを横断して、最新の分散ソリューションを設計および設計しています。 彼の情熱は、AWS で費用対効果が高くスケーラブルなソリューションを構築することです。 余暇には、フュージョン レシピの調理と旅行を楽しんでいます。
ヴィプル・ヴェルマ Amazon.com のシニア ソフトウェア エンジニアです。 彼は 2015 年から Amazon に勤務しており、Amazon の顧客の生活に直接影響を与えて改善するテクノロジーを通じて、現実世界の課題を解決しています。 余暇には、ハイキングを楽しんでいます。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
- 情報源： https://aws.amazon.com/blogs/big-data/how-amazon-devices-scaled-and-optimized-real-time-demand-and-supply-forecasts-using-serverless-analytics/
