Amazon Web Services ブログ

Category: Amazon Redshift

750 TB のデータを使用して Amazon Redshift で Amazon Payments 分析を実行する

 Amazon Payments データエンジニアリングチームは、データの取り込み、変換、計算と保管を担当しています。チームはこれらのサービスを世界で 300 社以上のビジネス顧客が利用できるようにしています。これらの顧客には、製品マネージャー、マーケティングマネージャー、プログラムマネージャー、データサイエンティスト、ビジネスアナリスト、およびソフトウェア開発エンジニアが含まれます。彼らは、ビジネス上の決定を適切に下すために、データをスケジュールされたクエリとワンタイムクエリに使用しています。このデータは、リーダーシップチームがレビューする、週次、月次、および四半期ごとのビジネスレビューメトリクスの構築にも使用されています。 私たちは、以下を含むさまざまな消費者支払いビジネスチームをサポートしています。 Amazon 支払い商品 (クレジットカード、ポイント付きショップ、アマゾン通貨コンバーター、国際決済商品) ギフトカード 支払いの受け取り体験 Amazon ビジネスペイメント また、機械学習の推薦エンジンへのフィードも行っています。このエンジンは、Amazon の支払いチェックアウトページでお客様に最適な支払い手段を提案します。 古いデータウェアハウスの課題 このセクションでは、データウェアハウスと分析のニーズでこれまで直面していた課題について説明します。支払い商品の発売とその新市場への拡大により、データ量が急激に増加しました。その後、抽出、変換、ロードプロセス (ETL) のスケーリングは厳しい課題に直面し、その結果、遅延と運用上の負担が生じました。データウェアハウスで直面していた具体的な課題は、次のとおりです。 Upsert はスケーリングしていないので、1 回の実行あたり最大 10MN を超える更新が行えました。消費者製品カタログのデータセットには、米国市場で 6.5BN を超えるレコードがリストされており、1 日の更新が 10MN を超えることもありました。注文属性データセットについても同様の傾向が見られました。 6 か月分もの支払いデータを分析しなければならなかった場合、データの集計に時間がかかるか、または集計が完了しませんでした。多くの場合、ビジネスオーナーは特定の属性に基づいてデータを集約したいと考えていました。たとえば、成功した取引の数や特定の種類のカードごとの金額などです。 共有クラスター、つまり共有ストレージとコンピューティングは、リソースクランチを引き起こし、その全ユーザーに影響を与えました。各チームにはデータウェアハウスでそれぞれ最大 100TB が割り当てられました。各チームは自分のテーブルを持ち寄り、中央データウェアハウスのテーブルに結合することができます。クラスター上の不正なクエリは、同じクラスター上の他のすべてのクエリに影響を与えました。これらの不正なクエリの所有者を特定するのは困難でした。 本番テーブルは 30,000 以上あり、それらすべてを同じクラスターでホストすることはほとんど不可能になりました。 大きなテーブルでインデックスが破損すると、テーブルを再構築して埋め戻すのが大変です。 データベース管理者はパッチを適用し、更新する必要がありました。 Amazon Redshift を新しい支払いデータウェアハウスとして使用する 私たちは、高速で信頼性が高く、将来のデータの増加に見合う規模がある、分析のニーズに適したさまざまなオプションを検討し始めました。これまでに説明したすべての問題を考慮して、中央データウェアハウスはコンピューティング層とストレージ層を分離する方向に進み、彼らはストレージを担当することにしました。そして機密性の高い重要なデータでも格納できるように暗号化されている Amazon S3 にデータレイクを構築しました。各消費者チームは、分析ニーズに合った独自の計算能力を実現するためのガイドラインを得ました。支払いチームは以下の利点に目を付け出しました。 便利な分析。 S3 や他の AWS のサービスとの統合。 手ごろな価格のストレージと計算レート。 ETL 処理に使えること。 […]

Read More

クライアントのデジタルマーケティング成果の向上を助けるために Amazon Redshift を使用する Bannerconnect

Bannerconnect は、望ましいタイミングと場所で適切な人に広告を見てもらうことによって、アドバタイザーが注意と顧客を惹きつけることができるようにするプログラム的なマーケティングソリューションを使用しています。データ主導の洞察は、大規模アドバタイザー、トレードデスク、およびエージェンシーがブランド認知を促進し、デジタルマーケティングの成果を最大化するために役立ちます。ログデータの適宜を得た分析は、顧客行動における動的変化に応答し、マーケティングキャンペーンを迅速に最適化して、競争優位性を得るために必要不可欠です。 AWS と Amazon Redshift への移行により、当社クライアントはほぼリアルタイムの分析を簡単に得ることができるようになりました。このブログ記事では、オンプレミスのレガシーデータウェアハウスで直面した課題について説明し、Amazon Redshift への移行によって得たメリットについてお話します。現在 Bannerconnect では、データをよりすばやく取り込み、より高度な分析を行って、クライアントがそのデジタルマーケティングを改善するためにより迅速なデータ主導の判断を行えるよう援助することができます。 レガシーオンプレミス状況と課題 当社のオンプレミスのレガシーインフラストラクチャは、IBM PureData System をログレベルのデータウェアハウスとした構成で、MySQL データベースを使用してメタデータと分析データのすべてを保存しました。この仮想化されていない物理的な環境では、データの増加に対応するために、容量をかなり前から注意深く計画する必要がありました。アップグレード、メンテナンス、およびバックアップの管理と、ワークロードとクエリパフォーマンスの日常的な管理を行うためには、かなりの人数のチームが必要でした。 数多くの課題にも直面しました。ログレベルのデータのデータウェアハウスへのロードに利用できる帯域幅は 1 ギガバイトしかありませんでした。ピークロード時には、ETL (extract/transform/load) サーバーがフル稼働状態になり、帯域幅がボトルネックになって、データが分析用に利用できるようになる時間を遅らせました。データウェアハウスに対するソフトウェアとファームウェアのアップグレードはスケジュールしておかなければならず、メンテナンスのダウンタイムは完了までに 8 時間かかることもありました。このインフラストラクチャは脆弱でもありました。すべての事をひとつの PureData System で実行しており、別個の開発/テスト環境はありませんでした。当社の本番環境に直接アクセスできるクライアントは、不正確な SQL クエリを発行してデータウェアハウス全体をダウンさせる可能性がありました。 私たちはログレベルのデータから集約を作成し、それらを MySQL に保存しました。インデックスはロードプロセスを大幅に減速させました。実行したかった集約のいくつかは、どう見ても実行不可能でした。200 ギガバイトの圧縮されていない行ベースのデータに対するアドホック (一回限りの) クエリは、完了にとても長い時間がかかりました。ダッシュボードクエリの多くは 10~15 分、またはそれ以上かかり、最終的にはキャンセルされました。ユーザーが不満を抱いていたため、私たちが全面的に、応答性が高いソリューションに進化しなければならないことは明白でした。Bannerconnect は、データウェアハウスのために AWS と Amazon Redshift を選びました。 Amazon Redshift への移行 当社のレガシーソフトウェアはクラウドでの実行向けに設計されていなかったため、私たちは利用できるすべての AWS コンポーネントを使用してアプリケーションを再構築することに決定しました。そうすることによって、移行プロセスの煩わしさが省かれ、AWS の可能性を最大限に生かすようにアプリケーションを設計することができました。 当社の新しいインフラストラクチャは、ログレベルのデータのウェアハウスとして Amazon Redshift を使用します。本番プロセスには 40 […]

Read More

Amazon Redshiftのクラスターノード数を数分で増減さることで、必要なときに必要なパフォーマンスを得ることができます

Amazon Redshiftは、TuroやYelpなど急速に成長するテクノロジー企業から、21st Century Fox、Johnson&JohnsonなどのFortune 500企業まで、あらゆる規模の組織にとって最適なクラウドデータウェアハウスです。これらの顧客は、ユースケース、データサイズ、アナリストの集団をすばやく拡大することで、スケーラブルなデータウェアハウスにとって非常に重要なニーズがあります。 Amazon Redshiftを発売して以来、お客様と私達はともに成長してきました。お客様と密接に協力することでデータのスケールに応じてニーズがどのように変化するかを学びました。データ分析では、次のようなシナリオが頻繁に発生します。 米国に拠点を置く小売企業は、多数のスケジューリングされたクエリと複雑なBIレポートを実行しています。彼らのAmazon Redshiftの使用状況は、データ科学者とアナリストの作業負荷が高い、午前8時から午後6時にピークに達します。夜間には、データを照会して小規模のレポートを作成するユーザーも少数います。その結果、日中と同じクラスター容量は夜間には必要ありません。 医療コンサルティング会社は、サービスとしてのデータ(DaaS)ビジネスを急速に拡大しています。彼らは、迅速に複製環境を作成し、クライアントにクラスターエンドポイントを提供したいと考えています。複製クラスターを作成した後は、クライアントのコストとパフォーマンスの要件に基づいて、適切なサイズにすばやく変更する必要があります。 IoTサービスプロバイダーは急速な成長軌道に乗っています。大規模なイベントが発生するたびに、そのセンサーはAmazon Redshiftに取り込まれ、その後すぐに分析する必要のあるテラバイトの容量の新しいデータを送信します。 データベース管理者(DBAs)がこれらのシナリオに反応する機敏さを持たない場合、アナリストはミッションクリティカルなワークロードに対する応答時間が長くなります。または、データウェアハウスがサイズ変更のために停止している場合、それらは完全に締め出される可能性があります。DBAは、ビジネスステークホルダーとの間で設定したService Level Agreements(SLAs)をサポートすることができません。 Amazon Redshiftを使用すれば、すでに3つの方法ですばやく拡張できます。第1に、Amazon Redshift Spectrumを使用してAmazon S3データレイクのクエリデータをクラスターにロードせずに、その場所にあるデータを照会することができます。この柔軟性により、抽出、変換、ロード(ETL)ジョブを待つことなく、またはストレージ容量を追加することなく、増大するデータボリュームを分析することができます。第2に、数時間でノードを追加したり、ノードタイプを変更することで、Amazon Redshiftクラスターのサイズを変更することができます。この間は、アナリストはダウンタイムなしで読み取りクエリを実行し続けることができます。これにより、スケールアップに数日かかるオンプレミスのデータウェアハウスに比べて、俊敏性が向上します。第3に、スナップショットからデータをすばやくリストアすることで、複数のAmazon Redshiftクラスターをスピンアップできます。これにより、高い並行性をサポートするために必要なコンピューティングリソースを追加できます。 Elasitc Resizeの導入 Amazon Redshiftクラスターのノードを数分で追加または削除できる新機能、Elastic Resizeを発表出来ることを嬉しく思います。これにより、要求の厳しいワークロードに対して、より優れたパフォーマンスとストレージを実現するための機敏性がさらに高まり、需要が低い期間にコストを削減できます。AWS マネジメントコンソールから手動で、または簡単なAPIコールを使用してプログラムでリサイズできます。 Elastic Resizeを使用すると、次の図に示すように、必要に応じて小規模から始めてオンデマンドでスケールアップすることができます。 リリース前にElastic ResizeをプレビューしていたAmazon Redshiftの顧客は、スケーラビリティによって即座に利益を得ることができました。ここで、顧客の一部がElastic Resizeについて伝えなければならないことがあります:   Amazon Prime Videoは高度なデータ分析を使用して視聴のお薦め内容をカスタマイズし、ファンの視聴経験を測定します。「Redshiftの新しいElastic Resize機能により、作業時間のリサイジング時間が6時間から15分に短縮され、ワークロードのさまざまな性質に応じてインフラを動的に拡張し、コストを最適化しパフォーマンスを最大限に高めました。」 Amazon Prime VideoのデータエンジニアであるSergio Diaz Bautista氏     Yelpは、Amazon Redshiftを使用して、モバイルアプリの利用データと、顧客コホート、オークション、広告指標に関する広告データを分析します。「Yelpは、データ分析を使用してビジネス上の意思決定を行い、ユーザーのエクスペリエンスを向上させる最前線に位置しています。Elastic Resizeを使用することで、需要が通常の変動性ウィンドウを超えて増加し、オフピーク時にスケールダウンするときにクラスターをスケールアップするように設定することで、最良のパフォーマンスを確実に最適化し、コストを低く抑えることができます。数百テラバイトのデータを数分で格納するデータウェアハウスの拡張能力は素晴らしいです」とYelp.comのデータアーキテクトShahid Chohan氏は言います。   「Coupangは、電話を使った世界のショップのあり方を混乱させている。進歩するビジネスニーズや予期せず必要とされる特別な分析のために、分析需要を常に予測できるとは限りません。Elastic Resizeにより、コンピューティングとストレージを迅速に拡張し、大規模なETLジョブをより速く完了させ、データを照会するユーザーの数を増やすことができます」と、Coupangのデータエンジニアリング担当上級マネージャー、Hara Ketha氏は述べています。   […]

Read More

Amazon SageMaker と Amazon Redshift を利用した、高速・柔軟・セキュアな機械学習基盤の構築

データウェアハウス環境として、 Amazon Redshift に販売データ・ログデータ・センシングデータ等を蓄積し、これらのデータを用いて機械学習の活用を検討されるケースは多いと思います。高速にクエリを実行できる Redshift と、Amazon SageMaker による Jupyter Notebook を用いた対話的なデータ分析と機械学習を活用し、需要予測・レコメンド・異常検知などを行うことが可能です。 本稿では、 Redshift から Amazon VPC 内でセキュアにデータを取得し、SageMaker を利用した分析・機械学習パイプラインを構築する方法をご紹介します。前半では、アーキテクチャの概要を説明します。後半では、そのアーキテクチャのサンプルを構築し 、SageMaker から SQL クエリを実行して、データを分析する方法について説明します。環境を簡単に構築できるよう、 AWS CloudFormation のテンプレートを用意しているので、実際に試しながら読み進めることができます。SageMaker や Redshift の概要については末尾に記載した参考記事をご覧下さい。 アーキテクチャ概要 大規模データに対し、高速・柔軟・セキュアにデータ分析を行うための、Redshift と SageMaker を組み合わせたアーキテクチャを以下に示します。     AWS を利用した分析・機械学習パイプラインとしては様々なアーキテクチャが考えられますが、ここでは Redshift に対して SageMaker の Jupyter Notebook 上から SQL クエリを実行し、必要なデータのみを取得して分析・可視化・機械学習を行うことを想定します。Redshift のサンプルデータが Amazon S3 にあるため事前にそれを読み込んでいます。 それでは、具体的にアーキテクチャの詳細を確認していきましょう。 速度と分析の柔軟さの両立 データの分析・可視化・機械学習を行う場合、ブラウザ上で動作する対話型データ分析ツールである Jupyter Notebook […]

Read More

Amazon Redshift を使用して、デジタルコンテンツを収益化するプロデューサーを支援している Narrativ

Narrativ は、彼ら自身の言葉によれば、「Narrativ は次世代のデジタルコンテンツプロデューサーのための収益化技術を構築しています。当社の製品ポートフォリオには、毎月数百万ドルの広告主価値と数十億データポイントを生成するリアルタイム入札プラットフォームとビジュアルストーリーツールが含まれています」ということになります。 Narrativ では、過去 15 ヶ月間に当社の製品によって生成されたデータが同様に桁違いに増加し、プラットフォームの使用量が大幅に増加しました。このブログ記事では、AWS を使用した、堅牢でスケーラブルで、パフォーマンスが高く、費用対効果の高い分析環境への進化を共有します。また、データウェアハウジングとデータレイク分析の過程で学んだベストプラクティスについても説明します。 Narrativ の継続的な成長の加速を見越して、私たちは昨年末、次の規模の計画を立て始めました。当社では Amazon Redshift をデータウェアハウスとして使用してきており、非常に役に立っています。データが増え続ける中、Amazon S3 をデータレイクとして利用し、Amazon Redshift Spectrum の外部テーブルを使用して S3 で直接データを照会しました。これにより、コストや複雑さに対するトレードオフなしで、ニーズを満たすためにストレージやコンピューティングのリソースを容易に個別に拡張できるようになったことを嬉しく思いました。 このプロセスで、Redshift Spectrum での作業を簡素化し、多数のベストプラクティスをカプセル化する Spectrify を作成しました。Spectrify は、簡単なコマンドで次の 3 つのことを実現します。まず、Amazon Redshift のテーブルをコンマ区切り値 (CSV) 形式で S3 にエクスポートします。次に、エクスポートされた CSV ファイルを並行して Apache Parquet ファイルに変換します。最後に、Amazon Redshift クラスターに外部テーブルを作成します。これで、クエリは Amazon Redshift のデータを使用して、膨大な量の Parquet データを S3 で展開し、すぐに結果を返すことができるようになりました。   上の図は、Amazon S3 の Parquet データと Amazon […]

Read More

Equinox フィットネスクラブで、Amazon Redshift を使用して顧客のジャーニーループを閉じる

クリックストリーム分析ツールはデータをうまく処理し、一部のツールは印象的な BI インターフェイスも備えています。ただし、クリックストリームデータを単独で分析するには多くの制限があります。たとえば、顧客はウェブサイトにある商品やサービスに興味があります。そして、顧客はそれらを購入するために物理的な店舗へ行きます。クリックストリームアナリストは「製品を見た後に何が起こったか?」と質問し、コマースアナリストは「購入する前に何が起こったか?」と質問します。 クリックストリームデータが他のデータソースを強化できることは驚くことではありません。購入データとともに使用すると、放棄されたカートの決定やマーケティング支出の最適化に役立ちます。同様に、オフラインおよびオンラインの行動や、顧客がアカウントを登録する前の行動さえも分析できます。ただし、クリックストリームのデータフィードの利点が明らかになったら、すぐに新しいリクエストに対応する必要があります。 このブログ記事では、Equinox フィットネスクラブで、クリックストリームデータで遅延バインディングのビュー戦略を使用するために、どのようにしてデータを Amazon Redshift から Amazon S3 へ移行したかを説明します。Apache Spark、Apache Parquet、データレイク、ハイブパーティショニング、外部テーブルなどの楽しいものを期待してください。すべてこの記事で広く取り上げます!

Read More

【開催報告】Amazon Analytics (Data Lake)セミナー ~AWSで実現するビッグデータ&ログ分析およびデータレイクの構築~

2018年6月21日に、「Amazon Analytics (Data Lake)セミナー」というイベントが開催されました。本セミナーでは、ビッグデータの取り扱いとデータ分析を中心とした利活用、またデータレイクによる効率的なデータの運用を中心テーマにおき、AWS クラウド上での最適な実現方法について、AWS ソリューションアーキテクトおよび Amazon Redshift サービスチームからご紹介しました。また、データの可視化については Amazon QuickSight のデモをご覧いただき、あとでお客さまご自身で QuickSight をお試しいただけるよう、セッション終了後にデモのガイドとサンプルデータを配布しました。 この記事ではそのイベントの内容をご紹介します。また、最後に各発表資料へのリンクも掲載しています。  

Read More

Amazon Redshift の結果のキャッシュでクエリの応答時間を 1 秒未満に

お客様によると、データウェアハウスやビジネスインテリジェンスのユーザは、常に迅速な意思決定ができるように、非常に高速な応答時間を求めているということです。またユーザは、データが変わっていなくても、同じクエリを何度も繰り返すことがよくある、とも言います。クエリを繰り返すたびにコンピューティングリソースを消費するので、クエリ全体のパフォーマンスが低下します。 今回の記事では、Amazon Redshift のクエリ結果のキャッシュについて説明します。結果のキャッシュは、まさにその名前が示すことを実行します。つまり、クエリ結果をキャッシュに格納するのです。同じデータに対して同じクエリが行われると、同じクエリを再実行するのではなく、前の検索結果をキャッシュから読み取って即座に返します。結果のキャッシュによって、システムの使用が削減され、他のワークロードでより多くのリソースを利用できるようになります。これにより、ユーザーの応答時間が高速になり、クエリ全体のスループットが向上し、並行処理が増加します。

Read More

【開催報告】Amazon Redshift 事例祭り(DWHマイグレーション)

先日(5月10日)、「Amazon Analytics (Redshift) 事例祭り」というイベントが開催されました。オンプレミスDWHを利用していた、もしくは現在使用しているお客様がDWHをAWSクラウド上のAmazon Redshiftに移行した経験談を共有していただくという内容のセミナーで、定員の120名を越えるお申込をいただき、会場が満室になる熱気の中で実践的な情報が共有されました。 この記事ではそのイベントの内容をご紹介します。また、各社発表資料へのリンクも掲載しています。

Read More

[AWS Black Belt Online Seminar] AWS で構築するデータレイク基盤のアーキテクチャ 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日(2018/4/24)開催しました AWS Black Belt Online Seminar「AWS で構築するデータレイク基盤のアーキテクチャ」の資料を公開致しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Read More