Amazon Web Services ブログ

Category: Analytics

Elasticsearch と Kibana を使って Amazon Connect のデータをリアルタイムに活用する

このブログポストでは、Amazon Elasticsearch Service (Amazon ES) と Kibana を使って、どのように Amazon Connect コンタクトセンターでリアルタイムなデータ分析を行うかを紹介します。問い合わせ対応時間やサービスレベル、問い合わせの効率具合、エージェントのパフォーマンス、顧客満足度など、様々なサービス・メトリクスを改善するためにコンタクトセンターのパフォーマンスをモニタリングできます。 加えて、Amazon ES を使って問い合わせ追跡レコード (CTR) 、エージェントのイベント・ストリーム、Amazon CloudWatch で取得できる問い合わせフローログを処理し、Kibana を使ってリアルタイムに近い形で可視化するソリューションも紹介します。Elasticsearch はオープンソースの、分散システムの検索と分析のエンジンで、ログ分析や全文検索に利用されています。Kibana はデータ集約と可視化のツールです。Amazon ES と Kibana を用いて、リアルタイムにデータを検索、可視化、分析、洞察することができます。 Amazon Connect は顧客とのやり取りで発生したイベントの詳細をリアルタイムに問い合わせフローログとして提供します。問い合わせフローとは顧客が問い合わせを行ったときの顧客体験を定義したもので、再生するプロンプトや顧客からの入力、問い合わせキューの転送などを定義します。 さらに、Amazon Connect は 分析用にデータをエクスポートするために CTR を Amazon Kinesis Data Firehose に、エージェントのイベントを Amazon Kinesis Data Streams にストリーミングできます。CTR は Amazon Connect インスタンスで発生するイベントや、属性、キュー、エージェントのやり取りをキャプチャーしたものです。エージェントのイベントは、Amazon Connect インスタンスにて起こる、ログイン、ログアウト、ステータスの変更といったエージェントのアクティビティを記録したものです。 ソリューション概要 以下の図は Amazon Connect からの問い合わせフローログや CTR、エージェントのイベントを処理し、Amazon […]

Read More

URL パスを分析して Amazon Elasticsearch Service の個々の要素を検索する

AWS クラウドにデータレイクを構築するのであれば、おそらく基礎となるデータのメタデータやカタログを検索する機能が必要になります。S3 キー、S3 およびオブジェクトメタデータの保存と検索には Amazon Elasticsearch Service (Amazon ES) をお勧めします。少なくとも、S3 キーにはオブジェクト名が含まれていますが、さらに検索したい追加の識別パス要素も含まれているでしょう。この記事では、キーパスを検索できるように Amazon ES を設定する方法について説明します。その過程で、テキストフィールドのためのカスタムアナライザーを作る方法も取り上げます。 分析 Amazon Elasticsearch Service (Amazon ES) を使用すると、Elasticsearch を使用してアプリケーションのデータを簡単に検索することができます。この記事は、Elasticsearch の機能に関するものです。Amazon ES は、データ、マッピング、検索リクエストなどが通過する管理レイヤーです。Amazon ES と Elasticsearch の関係の詳細については、当社のドキュメントを参照してください。 ドキュメントは、マッピングと一緒に Amazon ES に送信されます。このマッピングによって、Elasticsearch がフィールド内の値をどのように解析するかが決まり、クエリのターゲットとなる用語が作成されます。Amazon ES にクエリを送信すると、Elasticsearch はクエリ内の用語とドキュメントのフィールド内の用語を照合して、そのドキュメントがクエリと一致するかどうかを判断します。Elasticsearch は、こうした一致のランク付けされたセットをスコア付けし、クエリ結果として返します。 この記事では、テキストタイプの値に焦点を当てます。Elasticsearch 6.x のマッピングは、テキストとキーワードの 2 種類のテキストフィールドをサポートしています。キーワードフィールドは最低限の処理が行われ、完全一致の基礎として機能します。テキストフィールドは分析され、用語と呼ばれる個々の単語に分割されます。(Elasticsearch の一部の以前のバージョンでは、テキストタイプに異なる名前が使用されていたことに注意してください。) Elasticsearch はテキストフィールドを分析し、いくつかの処理段階を経てテキストを渡します。これは、文字のストリームを文字フィルターに渡し、次にトークナイザを適用して用語のストリームを発行し、最後に生成されたトークンにトークンフィルターを適用します。 下記のように、こうした各段階の動作をカスタマイズすることができます。 Elasticsearch のアナライザー Elasticsearch には、以下のような多数のアナライザーが組み込まれています。 Whitespace – ソース文字列を空白で分割し、文字の追加やトークンのフィルタリングを行わずに用語を作成します。 Simple […]

Read More

Amazon EMR の伸縮性と回復力を高めるための Spark の機能強化

お客様は Amazon EMR の伸縮性を利用して、ワークフローが完了したとき、またはより軽いジョブを実行するときにクラスターをスケールしてコストを節約しています。これは、低コストの Amazon EC2 スポットインスタンスでクラスターを起動する場合も同様です。 Amazon EMR の Automatic Scaling 機能により、お客様はクラスターの使用状況やその他のジョブ関連のメトリックスに基づいて、クラスターを動的にスケーリングできます。これらの機能は、リソースを効率的に使用するのに役立ちますが、実行中のジョブの途中で EC2 インスタンスがシャットダウンすることもあります。これにより、計算とデータが失われる可能性があり、それがジョブの安定性に影響を与えたり、再計算による重複作業を招いたりする可能性があります。 実行中のジョブに影響を与えずにノードを適切にシャットダウンするために、Amazon EMR は Apache Hadoop の廃止メカニズムを使用しています。このメカニズムは Amazon EMR チームが開発し、コミュニティに還元したものです。これはほとんどの Hadoop ワークロードではうまく機能しますが、Apache Spark ではそれほどうまくいきません。Spark は現在、ノードの損失に対処する際、さまざまな問題点に直面しています。これにより、失われたタスクやデータをリカバリおよび再計算しようとしてジョブが停滞したり、場合によってはジョブがクラッシュしたりすることもあります。Spark の未解決問題のいくつかについての詳細は、以下のリンクを参照してください。 フェッチのエラーに関連した問題 シャットダウン中のノードを追跡し、それらのノードに対するタスクのスケジューリングを回避する これらの問題のいくつかを回避し、お客様が Spark を使用して Amazon EMR の伸縮性機能を最大限に活用できるようにするために、Amazon EMR では、オープンソースの Spark をカスタマイズしてノードの損失に対する回復力を高めることができます。再計算は最小限に抑えられ、ジョブはノードのエラーおよび EC2 インスタンスの終了からより迅速にリカバリできます。これらの改善点は、Amazon EMR リリースバージョン 5.9.0 以降で反映されています。 このブログ記事では、問題に対処するためにオープンソースの Spark でノードの損失に対処する方法と、Amazon EMR の改善にまつわる問題点の概要について説明します。

Read More

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