Amazon Web Services ブログ

Category: Analytics

Amazon Elasticsearch Service でペタバイト規模のクラスタを実行する

ログデータに Amazon Elasticsearch Service (Amazon ES) を使用するのは、あたかも強力な消火ホースから水を飲むようなもので、システムそのものの潜在力は絶大です。Elasticsearch と Kibana の知識が深まるにつれ、より説得力のあるデータの使い方が見つかるでしょう。カスタマーベースが拡大し、それに対処するためにインフラストラクチャも拡張するのに伴い、さらに多くのログデータが生まれます。 膨らむ一方のログデータを格納および分析するためには、いくつかのデザインパスを辿ることができます。たとえば、複数の Amazon ES ドメインを展開し、ワークロードをそれらに分散することもできます。しかし、このデザイン戦略では、単独の Kibana ダッシュボードによる分析がサポートされません。また、ログストリームの一部を「共同所有」することで、ハイブリッドアプローチを取るか、オールインワンドメインアプローチを取るかを選ぶことができます。 最終的に、単独のワークロードドメインを使用したとしても、1 PB に達する、あるいはそれを上回るストレージに拡大できます。 Amazon ES では最近、大規模クラスタのサポート制限を倍増させました。今日現在では、ドメイン制限を増やすことで、デフォルトで 20 個のデータインスタンスを、クラスタあたり最大 200 件のデータインスタンスまでサポートします。データインスタンスに I3.16xlarge.elasticsearch インスタンスを選択した場合、クラスタに最大で 3 PB のストレージを持たせることができます。このような XL 規模のワークロードの運用を成功させるベストプラクティスは何でしょう? Elasticsearch の最新バージョンを実行する Elasticsearch はバージョンが上がるたびに、安定性とパフォーマンスの面で大きく改善されています。この記事の執筆時点で、Amazon Elasticsearch Service では Elasticsearch バージョン 6.4 がサポートされています。大規模なクラスタでは、Elasticsearch の最新のサポートバージョンへデプロイするか、アップグレードする (インプレースアップグレードを使用することで) ことをお勧めします。 I3 インスタンスを使用する ペタバイト規模へ拡張するには、I3s を使用する必要があります。I3 インスタンスには NVMe SSD エフェメラルストアがあります。大規模な環境では、I3.16xlarge.elasticsearch […]

Read More

Amazon Athena と Amazon QuickSight を使用して、200 年以上にわたる世界の気候データを視覚化する

気候変動は、私たちの生活の質に深く影響を及ぼし続けています。その結果、持続可能性に関する調査が増えています。公共部門と民間部門の両方の研究者が、記録された気候履歴を研究し、気候予測モデルを使用することによって将来に備えています。 こうした概念を説明するのを助けるために、この投稿では Global Historical Climatology Network Daily (GHCN-D) を紹介します。 このレジストリは、地球規模の気候変動研究コミュニティによって使用されています。 また、この投稿では、アマゾン ウェブ サービス (AWS) のサービスが気候変動調査のためにこのデータへのアクセスをどのように改善するかについても段階的に示します。データサイエンティストやエンジニアはこれまで、このデータを照会するために高性能コンピュータ上の何百ものノードにアクセスしなければなりませんでした。現在は、AWS でいくつかの手順を使用するだけで、同じデータを入手できるようになりました。 背景 地球規模の気候分析は、研究者が地球の自然資本と生態系資源に対する気候変動の影響を評価するうえで不可欠です。この活動には質の高い気候データセットが必要ですが、規模と複雑さのためにそのデータセットを使用するのはとても困難です。研究成果に自信を持つために、研究者は扱っている気候データセットの起源について自信を持っていなければなりません。たとえば、研究者は次のような質問に答えようとしているかもしれません。「特定の食料生産地の気候が、食料安全保障に影響を与えるように変化しましたか?」 研究者は簡単に信頼できる選ばれたデータセットを照会することができなければなりません。 米国の国立環境情報センター (NCEI) は、世界中の気象観測所による観測に基づいた気候データのデータセットを管理しています。それが、Global Historical Climatology Network Daily (GHCN-D) であり、地上局からの毎日の天気概要をまとめた中央リポジトリです。毎日更新される何百万もの品質保証された観測結果で構成されています。 記録される最も一般的なパラメータは、毎日の気温、降雨量、降雪量です。これらは干ばつ、洪水、異常気象のリスクを評価するうえで有益なパラメータです。 課題 NCEI は、GHCN_D データを年ごとに整理した CSV 形式で、FTP サーバーを介して利用可能にしています。データを年ごとに整理すると、アーカイブの完全なコピーには 255 を超えるファイルが必要になります (アーカイブの最初の年は 1763 年です)。従来、研究者がこのデータセットで作業をしたい場合、まずダウンロードしてローカルに取り組まなければなりませんでした。確実に最新のデータを分析に使用したい場合、毎日このダウンロードを繰り返さなければなりません。 研究者にとって、このデータから洞察を引き出すことが困難である場合があります。技術的スキル、コンピューティングリソース、主題に関する専門知識が必要であるため、データに完全に取り組むことができなければならないのです。 新しい効率的なアプローチ AWS と NOAA ビッグデータプロジェクトのコラボレーションによって、GHCN_D データセットの毎日のスナップショットが AWS で利用可能になりました。このデータは、Amazon S3 バケットを介して一般にアクセス可能です。詳細については、AWS の Registry of […]

Read More

Amazon EMR で Apache Atlas を使用して、メタデータの分類、系統および発見を行う

  今日の世界ではデータの役割が絶えず進化し、増大しているため、データガバナンスが効果的にデータを管理する上で重要な側面となっています。多くの組織は、データレイクを単一のリポジトリとして使用して、組織の事業体に属するデータをさまざまな形式で格納しています。メタデータ、カタログ化、およびデータ系統の使用は、データレイクを効果的に使用する上で鍵をにぎります。 この記事では、Amazon EMR にインストールされた Apache Atlas がこれを行う上でどのように機能するかについて説明します。この設定を使用すると、データを動的に分類し、さまざまなプロセスを経る際にデータの系統を表示できます。この一部として、Atlas のドメイン固有言語 (DSL) を使用してメタデータを検索できます。 Amazon EMR と Apache Atlas の紹介 Amazon EMR は、Apache Hadoop や Spark などのビッグデータフレームワークの実装を簡素化するマネージドサービスです。Amazon EMR を使用している場合、定義済みのアプリケーションセットから選択するか、リストから独自のものを選択できます。 Apache Atlas は、Hadoop のエンタープライズ規模のデータガバナンスおよびメタデータフレームワークです。Atlas は、組織がデータ資産のカタログを作成するためのオープンなメタデータ管理およびガバナンス機能を提供します。Atlas は、データがどのように進化したかを表す、ストレージ系統を含むデータ分類をサポートしています。また、重要な要素とそのビジネス定義を検索する機能も提供します。 Apache Atlas が提供するさまざまな機能の中でもとりわけこの記事で関心を寄せる中核的な機能は、Apache Hive のメタデータ管理とデータ系統です。Atlas のセットアップが成功したら、ネイティブツールを使用して Hive テーブルをインポートし、データを分析して直感的にエンドユーザーにデータ系統を提示します。Atlas とその機能の詳細については、Atlas のウェブサイトをご覧ください。 AWS Glue Data Catalog 対Apache Atlas AWS Glue Data Catalog は、さまざまなデータソースとデータ形式にわたる統一されたメタデータリポジトリを提供します。AWS Glue Data […]

Read More

[AWS Black Belt Online Seminar] Amazon Redshift Update 資料及び QA 公開

先日 (2018/1/22) 開催しました AWS Black Belt Online Seminar「Amazon Redshift Update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190122 AWS Black Belt Online Seminar Amazon Redshift Update from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Redshiftアドバイザ実行中、Redhiftのパフォーマンスに影響を及ぼさないでしょうか? A. Redshiftアドバイザのための各種ログ収集は内部的にスケジューリングされて自動実行され、パフォーマンスに影響を及ぼさないように動作します Q. クエリエディタについて質問です。ds2.xlargeでも、将来的に使えるようになるのでしょうか? A. 将来的なことはご回答できませんが、お客様のRequestに答えられるよう活動してまいります​ 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております! AWS Black Belt Online Seminar 1月分申込先 ≫ AWS Black Belt Online Seminar 2月分申込先 ≫ 2019 年 1 […]

Read More

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

2018 年に最もよく読まれた AWS データベースブログ

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

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

Apache Spark および Hadoop を Amazon EMR に移行してコストを削減

Apache Spark および Hadoop は、分析用のデータ処理向けのフレームワークとして広く普及しています。レガシーアプローチと比較すれば、コストもほんのわずかな額で済みますが、それでもそのスケーリングとなると、依然として高くつくケースがあります。本記事では、TCO を削減し、かつ同時にスタッフの生産性を引き上げる方法について考察します。その実現を可能にするのは、オンプレミスのワークロードの Amazon EMR への移行、良いアーキテクチャの選択、リソースの消費量を削減するよう設計された機能の活用です。今回のアドバイスは、お客様との多数の事例から得た知見に基づいており、主な論点の多くは IDC の Carl Olofson および Harsh Singh が実施したビジネス価値の研究結果によっても検証されています。当該研究はアマゾン ウェブ サービス (AWS) が資金提供しており、IDC ホワイトペーパー「The Economic Benefits of Migrating Apache Spark and Hadoop to Amazon EMR」(2018 年 11 月) としてご覧いただけます。 それではまず、ヘッドラインとして統計データをいくつかご紹介して、Amazon EMR への移行が生むコスト面のプラスのインパクトをご説明します。IDC が調査した Amazon EMR のお客様 9 社では TCO が平均 57% 削減されました。同時に、5 年間の投資利益率の 342% 増しで、8 か月で投資を回収しました。この 9 […]

Read More

Amazon Elasticsearch Service、Amazon Kinesis Data Firehose、Kibana を使用してユーザーの行動を分析する

あなたは E コマースの会社で働いていて、顧客に最高のユーザーエクスペリエンスを提供したいと考えているとします。顧客は、アプリケーションの別のページでのリコメンデーションから製品ページに来るかもしれませんし、検索エンジンから移動してくるかもしれませ。経路に関わらず、顧客が本当に探しているページに確実にたどり着けるようにしたいと考えています。ただし、すべての顧客が同じ経路をたどるわけではありません。どのようにアプリケーションにアクセスしているのか、どのような場所からアクセスしているのか、その他多くの属性に依存します。パターンを分析して決定するには、貴重なデータが豊富に含まれているログを確認する必要があります。 このブログ記事では、Apache ウェブサーバーのログにアクセスしてユーザーの行動を分析し、実用的な洞察を得る方法について説明します。 このブログでは、以下の AWS のサービスを使用しています。 Amazon Kinesis Data Firehose Amazon Elasticsearch Service Amazon Elastic Compute Cloud (Amazon EC2) AWS Lambda Amazon Cognito Amazon Simple Storage Service (Amazon S3) AWS CloudFormation (ソリューションをデプロイするため)

Read More

Amazon EMR を保護するベストプラクティス

どの業界でも、組織が機能する上で中心となるのは、データです。お客様とデータ戦略について話し合うとき、データの取り込み、保存、処理、分析、配布、最終的なデータを安全性について語ります。 Amazon EMR は、膨大な量のデータを処理するために使用するマネージド型 Hadoop フレームワークです。お客様が Amazon EMR を選ぶ理由の 1 つは、そのセキュリティ機能です。例えば、金融サービスなどの規制された業界や医療分野の FINRA のようなお客様は、データ戦略の一環として Amazon EMR を選びます。ペイメントカード業界データセキュリティ基準(PCI)や 医療保険の携行と責任に関する法律(HIPAA)など、エンティティからの厳しい規制要件に準拠するためのものです。 この記事では、Amazon EMR セキュリティの原則についていくつか説明します。また、Amazon EMR で使用できる機能についての説明は、ビジネスのセキュリティとコンプライアンスの目標を達成するのに役立ちます。使用している共通のセキュリティベストプラクティスについて取り上げます。また、開始するためのサンプル構成もいくつか示しています。詳しい情報については、「EMR管理ガイド」の「セキュリティ」を参照してください。

Read More