Amazon Web Services ブログ

Category: Analytics

Amazon Elasticsearch Service ドメインを設定するベストプラクティス

 Amazon Elasticsearch Service (Amazon ES) は、AWS クラウドで Elasticsearch クラスターのデプロイ、保護、スケール、監視を簡単に行うことができる完全マネージド型サービスです。Elasticsearch は分散型データベースソリューションであり、計画や実行が困難な場合があります。この記事では、Amazon ES ドメインをデプロイするためのベストプラクティスについていくつか説明します。 最も重要なプラクティスは、繰り返し調整を行うことです。これらのベストプラクティスに従えば、基本レベルの Amazon ES のデプロイを計画できます。Elasticsearch はワークロードごとに異なる動作をします。レイテンシーとスループットは、主にリクエストの組み合わせ、リクエスト自体、実行するデータまたはクエリによって大部分が決定されます。ワークロードがどのように動作するかを 100% 予測できる確定的なルールはありません。デプロイの調整と改善、ドメインの動作の監視を行い、状況に応じて調整するための時間を計画に入れてください。

Read More

AWS Glue でメモリ管理を最適化する

AWS Glue は、Apache Spark のパワーを使用して分析用のデータセットを準備および処理するサーバーレス環境を提供します。シリーズの第 3 回目の記事では、AWS Glue が一般的なデータ変換を実行するコードを自動的に生成する方法について説明しました。また、AWS Glue ワークフローを使用して、分析のためにデータを簡単に取り込んで変換し、ロードできるデータパイプラインを構築する方法も見てきました。 Apache Spark には、さまざまなワークロードに対してメモリがどのように管理されるかを制御するためのノブがいくつもあります。ただし、これは厳密な科学ではなく、非効率的な変換ロジック、最適化されていないデータ分割、または基盤となる Spark エンジンの他の特異な動作のために、アプリケーションにさまざまなメモリ不足 (OOM) の例外が発生する可能性があります。本シリーズのこの記事では、Glue Spark ETL ジョブの内部処理について詳しく説明し、AWS Glue 機能を Spark のベストプラクティスとどう組み合わせて、ジョブをスケーリングしてデータの多様性とボリュームを効率的に処理するかについて説明します。 Apache Spark ドライバーのスケーリング Apache Spark ドライバーは、ジョブを分析および調整し、作業をタスクに分散させて、可能な限り最も効率的な方法でジョブを完了できるようにします。ETL ジョブの大部分で、ドライバーは通常、Amazon S3 でテーブルパーティションとデータファイルを一覧表示してから、ファイル分割を計算して個々のタスクを処理しています。ドライバーは次に、各ファイル分割を処理する変換タスクを調整します。さらに、ドライバーは各タスクの進行状況を追跡し、最後に結果を収集する必要があります。ジョブが多数のファイルとパーティションを処理する必要がある場合、Spark ドライバーがボトルネックになる可能性があります。AWS Glue は、多数のファイルを処理する際、Spark ドライバーのメモリを効率的に管理するための 5 つの異なるメカニズムを提供しています。 プッシュダウン述語: Glue ジョブでは、プッシュダウン述語を使用して、基になるデータを読み取る前に、テーブルから不要なパーティションをプルーニングできます。これは、テーブルに多数のパーティションがあり、Glue ETL ジョブでそのサブセットのみを処理する場合に便利です。カタログパーティションをプルーニングすると、ドライバーのメモリフットプリントが削減され、さらにプルーニングパーティション内のファイルを一覧表示するために必要な時間が短縮されます。不要なパーティションを無視するために先ずプッシュダウン述語を適用してから、ジョブのブックマークやその他の除外によって、各パーティションから読み取られるファイルのリストをさらにフィルタリングできます。以下は、週末に限って記録されたイベントのデータのみを処理するためにプッシュダウン述語を使用する方法の例です。 partitionPredicate =”date_format(to_date(concat(year, ‘-‘, month, ‘-‘, day)), ‘E’) in (‘Sat’, ‘Sun’)” […]

Read More

Analytics Lens を使った AWS Well-Architected 環境の構築

AWS でのモダンデータプラットフォームの構築は、あらゆるタイプのデータを収集し、セキュアな中央リポジトリに保存して、専用ツールを使って分析することを可能にします。しかし、開始方法や特定の設計判断の影響に不安が残っているかもしれません。特定のテクノロジーおよびアプリケーション分野に適した助言を提供するニーズに対応するため、AWS は Well-Architected Lenses 2017 という概念を追加しました。AWS は本日、AWS Well-Architected フレームワークのための Analytics Lens を発表します。この記事は、Analytics Lens の目的を紹介し、対象となるトピック、一般的なシナリオ、および含まれるサービスについて説明します。 新しい Analytics Lens は、お客様の分析アプリケーションが AWS のベストプラクティスに従って設計されていることを確実にするための包括的なガイドラインを提供します。その目的は、以下の 5 つの柱に基づいてクラウドアーキテクチャを設計し、評価するための一貫的な方法を提供することです。 運用上の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 このツールは、潜在的なリスクを特定し、改善のための提案を行うことによって、AWS でデプロイされた分析ワークロードを評価する上で役立ちます。 一般的な要件に対応するための Analytics Lens の使用 Analytics Lens は、分析アプリケーションの中核を成すデータアーキテクチャと、アプリケーション動作そのものの両方をモデル化します。これらのモデルは、AWS にデプロイされた分析ワークロードの大部分が含まれる以下の 6 つの領域に分類されます。 データの取り込み セキュリティとガバナンス カタログ化と検索 中央ストレージ 処理と分析 ユーザーアクセス 以下の図は、これらの領域と、それらに関連する AWS のサービスを示したものです。 Analytics Lens が適用される一般的なシナリオは多数存在し、以下のようなものがあります。 データおよび分析イニシアティブの基盤としてのデータレイクの構築 効率的な大規模バッチデータ処理 ストリーミングインジェストとリアルタイムのイベント処理のためのプラットフォームの構築 […]

Read More

Amazon EMR を使用して Amazon DynamoDB の Time to Live (TTL) 属性をバックフィルする

データベースへの一括更新は混乱を招き、ダウンタイム、ビジネスプロセスのパフォーマンスへの影響や、コンピューティングリソースとストレージリソースの過剰プロビジョニングを引き起こす可能性があります。一括更新を実行する場合、迅速に実行でき、ビジネスを中断することなく運営でき、コストを最小限に抑えるプロセスを選択する必要があります。Amazon DynamoDB などの NoSQL データベースを使ってこれを実現する方法を見てみましょう。 DynamoDB は、テーブル内の項目中、どの項目にも存在しない属性を持てる項目を含められる柔軟なスキーマ構造を提供する NoSQL データベースです (リレーショナルデータベースでは、他の行から除外される一方、一部の行にしか存在できない列もあります)。DynamoDB は極端なスケールで実行するように構築されているため、ペタバイトものデータと数兆もの項目を持つテーブルを使用できます。そのため、このようなテーブル全体の変更を行うには、スケーラブルなクライアントが必要です。このようなユースケースでは、通常、Amazon EMR を使用します。DynamoDB は伸縮自在な容量を提供するため、不定期の一括操作に対応できるように、通常の操作の過程で過剰にプロビジョニングする必要はありません。一括操作中にテーブルに容量を追加し、完了したらその容量を削除するだけです。 DynamoDB は Time to Live (TTL) と呼ばれる機能をサポートしています。TTL を使用すると、期限切れの項目を追加コストなしでテーブルから自動的に削除できます。通常、項目を削除すると書き込み容量が消費されるため、TTL を使用すると、特定のユースケースでは大幅なコスト削減を実現できます。たとえば、TTL を使用して、長期間保持するために Amazon Simple Storage Service (Amazon S3) バケットにすでにアーカイブしたセッションデータまたは項目を削除できます。 TTL を使用するには、タイムスタンプ (Unix エポックからの秒数としてエンコード) を含む項目の属性を指定します。この時点で、DynamoDB は項目が期限切れであると見なします。項目の有効期限が切れると、DynamoDB は通常、有効期限から 48 時間以内に項目を削除します。TTL の詳細については、「Time to Live を使用した項目の期限切れ」を参照してください。 DynamoDB テーブルにデータを配置する前に TTL 属性を選択するのが理想ですが、DynamoDB ユーザーは、テーブルにデータを含めた後に TTL を使い始めることがよくあります。アプリケーションを変更してタイムスタンプ付きの属性を新しい項目または更新された項目に追加するのは簡単ですが、古い項目すべての TTL 属性をバックフィルする最良の方法は何でしょうか? 通常、DynamoDB テーブルの一括更新には […]

Read More

AWS Lake Formation と Amazon Forecast を使用して、エンドツーエンドの自動在庫予測機能を構築する

Amazon Forecast は、機械学習 (ML) により、それまでの機械学習経験を待つことなく、非常に正確な予測を生成できる完全マネージド型サービスです。Forecast は、製品需要の見積もり、在庫計画、労働力計画など、さまざまなユースケースに適用できます。 Forecast では、プロビジョニングするサーバーや手動で構築する機械学習モデルはありません。また、使用した分だけお支払いいただくようになっており、最低料金や前払い料金を求められることはありません。Forecast を使用するために必要なことは、予測対象の履歴データをご提供いただくことだけです。予測に影響を与えると思われる関連データも併せてご提供ください。後者には、価格、行事、天候など、時により変化するデータと、色、ジャンル、リージョンなどカテゴリに関するデータの、両方が含まれます。このサービスでは、お手元のデータに基づいて機械学習モデルを自動的にトレーニングし、デプロイして、予測を取得するためのカスタム API を提供します。 この記事では、データの抽出、変換、および Forecast の使用を自動化して、定期的な在庫の補充を必要とする小売業者のユースケースについて説明します。これを実現するには、AWS Lake Formation を使用して安全なデータレイクを構築し、データを取り込み、AWS Glue ワークフローを使用してデータ変換を調整し、Amazon QuickSight で予測結果を視覚化します。 ユースケースの背景 小売業者は、在庫の補充を繰り返す必要があります。たとえば、通常は e コマースチャネルと実際の店舗チャネルを通じて販売する衣料品小売業者があるとします。倉庫のコストを最小限に抑えながら需要を満たすために、手持ちの在庫の最適なレベルを維持する必要があります。効果的な在庫管理のためのいくつかの共通質問にお答えください。 次の販売サイクルに向けてサプライヤーに再注文する際に最適な在庫数量はどれくらいですか? サプライヤー宛ての注文書に製品 SKU の構成を含めるには、どうすればよいですか? 各小売店で用意する在庫製品の適切な構成と数量を最も効果的に決めるには、どうすればよいですか? Forecast を使用して、これらの質問に答えることができます。ソースシステムからデータを抽出し、変換を適用してデータを Forecast で使用できるように準備を整え、Forecast を使用してロード、トレーニング、予測を行います。 次の図は、Lake Formation、AWS Glue、および Amazon QuickSight を使用した提案ソリューションのエンドツーエンドシステムアーキテクチャを示しています。 Lake Formation を使用して、データレイクのガバナンスとアクセス制御を管理します。さらに、次のリソースを使用します。 Lake Formation のブループリントが売上データをデータレイクに取り込む AWS Lambda および Amazon S3 イベント通知で AWS Glue […]

Read More

Amazon EMR、AWS Glue、Amazon QuickSight を使用して自動データプロファイリングおよびレポートソリューションを構築する

 典型的な分析パイプラインでは、データレイクにデータをインポートした後に通常実行する最初のタスクの 1 つは、データプロファイリングと高レベルのデータ品質分析です。これにより、データセットのコンテンツをチェックします。このようにして、テーブル名、列名とそのタイプなどの情報を含む基本的なメタデータを充実させることができます。 データプロファイリングの結果は、データセットに予期した情報が含まれているかどうか、およびそれらを分析パイプラインのダウンストリームでどのように使用するかを決定するのに役立ちます。さらに、これらの結果は、オプションのデータセマンティクス分析ステージへの入力情報の 1 つとして使用できます。 最新のデータレイクには膨大な量のさまざまなタイプのデータがあり、構造化されていない手動のデータプロファイリングとデータセマンティクスの分析は非現実的で時間がかかります。この記事では、AWS Glue データカタログメタデータの拡張として、データプロファイリングリポジトリの自動作成プロセスを実装する方法と、レポートシステムについて説明します。レポートシステムは、分析パイプラインの設計プロセスを支援するもので、信頼性の高いツールを提供することでさらに分析を行えるようにします。 この記事では、AWS Glue データカタログのアプリケーションデータプロファイラーについて詳しく説明し、実装例をステップバイステップで示します。 概要とアーキテクチャ 次の図は、このソリューションのアーキテクチャを示しています。 AWS Glue データカタログのデータプロファイラーは、Apache Spark Scala アプリケーションです。これにより、Amazon Deequ ライブラリのプロファイリング機能を使用して、データカタログ内のデータベースで定義されたすべてのテーブルをプロファイリングし、その結果をデータカタログと Amazon S3 バケットにパーティション化された Parquet 形式で保存します。Amazon Athena や Amazon QuickSight などの他の分析サービスを使用して、データをクエリして視覚化できます。 Amazon Deequ データライブラリの詳細については、「Deequ を使用した大規模なテストデータ品質」、または GitHub リポジトリのソースコードをご覧ください。 メタデータは、「データに関するデータ」と定義できます。テーブルのメタデータには、テーブル名とその他の属性、列の名前とタイプ、データを含むファイルの物理的な場所などの情報が含まれています。データカタログは AWS のメタデータリポジトリであり、Athena、Amazon EMR、Amazon Redshift などの他の AWS のサービスで使用できます。 データベース内のテーブルのメタデータを作成または更新した後 (テーブルへの新しいデータの追加など)、AWS Glue クローラを使用して、または手動でアプリケーションを実行して各テーブルをプロファイルできます。結果は、テーブルのメタデータの新しいバージョンとしてデータカタログに保存されます。保存された結果は、AWS Lake Formation コンソールからインタラクティブに表示したり、AWS Glue […]

Read More

Amazon Kinesis Video Streams ハンズオンを公開 – カメラデバイスからの動画の収集、ストリーミング再生、分析方法を学ぶことができます

こんにちは、IoT Specialist ソリューションアーキテクトの三平です。この記事では、Amazon Kinesis Video Streams ハンズオンをご紹介します。 Amazon Kinesis Video Streams は、分析、機械学習 (ML)、再生、およびその他の処理のために、接続されたデバイスから AWS へ動画を簡単かつ安全にストリーミングできるマネージドサービスです。数百万のデバイスからの動画をセキュアに取り込み、時系列でインデックスして保存、再生や分析のために容易に取り出すためのインフラストラクチャを、自動的にプロビジョンして、伸縮自在にスケールします。 このハンズオンでは Amazon Kinesis Video Streams を用いた PoC などを容易に行っていただけるよう、カメラデバイス (Raspberry Pi) からクラウドへ動画を収集・保存し、ライブやオンデマンドでストリーミング再生したり、動画ファイルとしてダウンロードしたり、Amazon Rekognition Video と組み合わせてライブ顔認識やニアリアルタイムでの分析などを行ったりする方法を、実際に手を動かしながら3〜4時間で学ぶことができます。

Read More

Zendesk がレガシーシステムを Amazon Aurora と Amazon Redshift に移動してパフォーマンスを 3 倍にした方法

 この記事は、Zendesk のエンジニアリングリーダーである James Byrne 氏によるゲスト投稿です。Zendesk は、Zendesk Explore アナリティクス製品のデータパイプラインにおける開発と運用、および AWS ソリューションアーキテクトの Giedrius Praspaliauskas に焦点を当てています。 Zendesk は、より良い顧客関係を促進するために設計されたサポート、販売、顧客エンゲージメントソフトウェアを構築する CRM 企業です。規模、業界、または野心に関係なく、大企業からスタートアップ企業にいたるまで、強力で革新的な顧客体験がすべての企業に届くと、私たちは信じています。Zendesk は、さまざまな業界の 150,000 社以上の顧客に 30 以上の言語でサービスを提供しています。Zendesk はサンフランシスコに本社を置き、世界中に 17 ヵ所のオフィスを展開しています。 Zendesk Explore は、企業が顧客体験全体を測定して改善できるように分析を提供します。Zendesk Explore を使用すれば、企業は重要な顧客分析にすぐにアクセスでき、顧客とその関連ビジネスについてより深く理解できます。 この記事では、レガシーシステムを Amazon Aurora と Amazon Redshift に移行する方法について説明します。新しいデータストアと 3 倍のパフォーマンスを構築できるプロセスとアーキテクチャについて詳しく説明します。 移行を決定する 2015 年、Zendesk はビジネスインテリジェンスのスタートアップ企業である BIME Analytics を買収しました。BIME 製品は、現在のレポート製品である Zendesk Explore の構成要素として機能していました。Zendesk Explore は、Zendesk サポート、トーク、チャット、ガイドなど、さまざまな Zendesk […]

Read More

AWS Glue の自動コード生成機能とワークフローを利用して、データパイプラインをシンプル化する

 これまでの一連の記事では、AWS Glue のジョブブックマークを使用して Amazon S3 やリレーショナルデータベースからデータを増分ロードする方法についてご紹介しました。また、AWS Glue に最適化された Apache Parquet ライターを使用してパフォーマンスを向上させ、スキーマ進化を管理する方法についても説明しました。 3 つ目の記事となる今回は、次の 3 つのトピックを取り上げます。まず、特定の列を選択する、深くネストされたレコードを展開する、ネストされたフィールドを効率的に解析 (パース) する、列データの展開処理といった一般的なユースケースにおいて、AWS Glue でデータの変換に役立つコードを自動生成方法について説明します。 次に、AWS Glue のワークフローとCrawlers、Apache Spark 、Python Shell ETL ジョブといったさまざまな Glue コンポーネントを使用してデータパイプラインを構築し、オーケストレーションする方法について説明します。 最後に、ETL ジョブで SparkSQL を活用し、Amazon S3 とリレーショナルデータベースに保存されたデータセットで SQL ベースの変換を実行する方法について説明します。 自動コード生成と変換: ApplyMapping、Relationalize、Unbox、ResolveChoice AWS Glue では、さまざまなデータ変換タスクの実行に使用するコードを自動的に生成できます。これらの変換では、複雑で深くネストされたデータセットの処理するための、使いやすいインターフェイスを提供します。たとえば、一部のリレーショナルデータベースやデータウェアハウスは、ネストされたデータ構造をネイティブにサポートしていません。AWS Glue を使用すると、データをターゲットデータベースにロードする前にネストされたデータ構造を展開するためのコードを自動生成できるので、時間が節約できるだけでなく、技術に詳しくないユーザーでもデータを扱うことができます。 AWS Glue が提供する、データ処理をシンプル化するための変換のうち、よく利用されるものを次に示します。 ApplyMapping は、列の投影やデータ型の変更に使用される変換処理です。この例では、action.id などいくつかのフィールドのネストを解除し、トップレベルの action.id フィールドにマッピングします。また、id 列を long […]

Read More

小規模な Amazon Elasticsearch Service ドメインのコストを削減する

 Amazon Elasticsearch Service (Amazon ES) ドメインをデプロイして本番環境のワークロードをサポートする場合、使用するデータインスタンスのタイプと数、アベイラビリティーゾーンの数、専用マスターインスタンスを使用するかどうかを選択する必要があります。ベストプラクティスのための推奨事項をすべて実行するには、次のように設定する必要があります。 3 つの専用マスターインスタンス M5.large 3 つの M5.large データノードを備えた 3 ゾーンレプリケーション プライマリに 2 つのレプリカの使用 必要に応じたストレージ、最大 512 GB、データノード用の GP2 Amazon Elastic Block Store (EBS) ボリューム この設定の場合、最大 400 GB のソースデータと 1 秒あたり数十万のリクエストを、1 か月あたり最大 800 USD (米国東部、バージニア北部の料金) のオンデマンドコストでサポートします。実行可能なデプロイを最小限に抑えることで、このコストを削減できます。本番ワークロードで実行可能な最小のデプロイは、次のとおりです。 専用マスターインスタンスなし M5.large ノードを備えた 2 ゾーンレプリケーション プイマリに 1 つのレプリカの使用 必要に応じたストレージ、最大 512 GB、データノード用の GP2 EBS ボリューム このデプロイでは、同じ […]

Read More