Amazon Web Services ブログ

Category: Analytics

Amazon QuickSight で表計算による高度な分析を行う

Amazon QuickSight は最近、表計算機能を公開しました。これにより、ユーザーはデータに対し複雑な計算を実行し、より意味のある洞察を得られるようになりました。このブログ記事では、これらの計算をサンプルの販売データセットに適用する例を解説し、皆さんのニーズに合わせてこの機能をすぐに活用していただけるようにします。 使用したサンプルデータセットはこちらより参照できます。 表計算とは? Amazon QuickSight で表計算を使用すると、前期比の傾向など、メトリクスを導き出すことができます。指定したウィンドウでそのウィンドウ内のメトリクスを算出するため、または固定ウィンドウの計算に対して評価するために計算を作成することもできます。また、これらすべてのタスクをカスタマイズした詳細レベルで実行することも可能です。たとえば、各産業の売上の前年比増加分を算出したり、ある州で特定の産業の貢献度をパーセンテージで表示したりできます。また、1 年間の前月比の累積売上を算出したり、ある州で、ある産業の売上のランキングを出したりすることも可能です。 これらのメトリクスは関数を組み合わせることで算出できます。これらの関数としては、runningSum、percentOfTotal、percentDifference などのほか、ベースのパーティション関数が挙げられます。このケースで使用できるベースのパーティション関数には、sum、avg、count、distinct_count、rank および denseRank などがあります。パーティションに対し、最小および最大を計算できる minOver や maxOver もあります。 パーティション関数 これらの計算を実行する前に、パーティション関数に関する簡単な説明をご覧ください。パーティションを使用することで、計算が含まれるウィンドウの範囲を指定できるようになります。つまり、パーティションは計算が実行されるウィンドウを定義する際に役立ちます。 例として、複数の区分にまたがる各産業の平均売上を計算してみましょう。まず、図に、industry、segment、sales を追加します。通常の集計フィールド avg(sales) をテーブルに追加することで、産業内の各区分の平均売上が算出されますが、産業全体の平均ではありません。これを達成するには、avgOver 計算を使用する集計フィールドを作成します。 avgOver(aggregated measure, [partition by attribute, …]) ここでの aggregated measure は、図の範囲ごとにグループ分けされたとき、その単位で実行する計算を意味します。この計算は各産業のパーティションに平均が適用される前に実行されます。 産業別平均 = avgOver(sum(sales), [industry]) 同様に、sumOver、minOver、maxOver および countOver の関数を使用することで、それぞれ、売上の合計、売上の最低値と最高値、各産業の区分数を計算できます。 基準対実際の売上 ここでもう 1 つ別のユースケースを使って、ある州の各産業が、その州の平均売上に照らして評価したとき、どのような動きになるか見ていきましょう。 これを実行するには、テーブルの図に state、industry、sales を追加し、州ごとにソートします。基準を計算するために、avgOver 関数で集計フィールドを作成し、State の範囲でパーティションを区切ります。 avgOver(aggregated measure, [partition […]

Read More

Amazon Kinesis Agent for Microsoft Windows を使用して、Windows イベント、ログ、およびメトリックを収集、解析、変換、ストリーム配信する

Amazon Kinesis Agent for Microsoft Windows (KA4W) を含む完全なデータパイプラインは、Windows ベースのサービスのパフォーマンス、セキュリティ、および可用性を分析および監視するのに役立ちます。Windows サービスにほぼリアルタイムのダッシュボードとアラームを構築できます。また Amazon Athena、Kibana、Amazon QuickSight、Amazon CloudWatch などの可視化およびビジネスインテリジェンスツールを使用して、迅速に位置の特定、診断、および解決を行うこともできます。 KA4W は、ログを解析して JSON などの標準形式に変換することで、クラウドベースのログ処理を排除します。これらの形式は、データパイプラインの可視化ツールやビジネスインテリジェンスツールですぐに使用できます。 KA4W を使ってみた経験についてあるお客様から寄せられた声を少しご紹介します。 「Microsoft Windows 用の新しい Amazon Kinesis Agent は、複数の相互接続されたシステム間の複雑なオーケストレーションを排除することで、ログをストリーミングするワークフローを簡略化しました。エージェントはセットアップ、構成、更新が容易でしたが、最も重要な点は、パフォーマンスが大幅に改善された点です。総体的に見て、Amazon Kinesis Agent for Microsoft Windows は、環境内の問題の可視性を大幅に改善し、運用コストを著しく削減するポテンシャルを秘めています」- Sanjay Kumar 氏、シニアソフトウェアエンジニア、Autodesk Inc. この記事では、新しい Kinesis Agent for Windows が Windows アプリケーション、サーバー、およびワークステーションに関連するストリーミング分析のユースケースをどのように行うかを検証します。新しいエージェントを使い始める方法もご紹介します。KA4W を使用してリアルタイムデータを Amazon Kinesis サービスにプッシュすることで、次のようなさまざまな運用上の問題を解決できます。 枯渇したスコープの場合に IP リースが拒否されたことを識別するための Dynamic Host […]

Read More

RStudio を実行するために Amazon EMR のエッジノードを立ち上げる

RStudio Server は R およびデータサイエンティストの間で人気のツールにブラウザベースのインターフェイスを提供します。データサイエンティストは分散型トレーニングを実行するために、Amazon EMR 上で実行する Apache Spark クラスターを使用します。前回のブログ記事では、著者が Amazon EMR クラスターに RStudio Server をインストールする方法を紹介しました。しかし、特定のシナリオでは、スタンドアロンの Amazon EC2 インスタンスにインストールし、リモートの Amazon EMR クラスターに接続するケースも考えられます。EC2 上で RStudio を実行することの利点としては次のようなものが考えられます。 EC2 インスタンス上で RStudio Server を実行することにより、インスタンス上に科学的モデルとモデルアーティファクトをそのまま保存できます。アプリケーションの要件を満たすために、EMR クラスターの再起動が必要になることがあります。RStudio Server を別途実行することで、柔軟性が向上し、Amazon EMR クラスターにすべて依存する必要がなくなります。 Amazon EMR のマスターノード上に RStudio をインストールするには、同一ノード上で稼動しているアプリケーションとリソースを共有する必要があります。スタンドアロンの Amazon EC2 インスタンス上で RStudio を実行することで、他のアプリケーションとリソースを共有する必要なく、リソースを使用できるようになります。 ご使用の環境に複数の Amazon EMR クラスターをお持ちの方もおいでかと思います。エッジノードに RStudio を配置すると、ご使用の環境で任意の EMR クラスターに接続できるという柔軟性が得られます。 Amazon EMR […]

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

Amazon Athena で CTAS ステートメントを使用して、コストを削減し、パフォーマンスを向上させる

Amazon Athena は、標準 SQL を使用して Amazon S3 でのデータの分析を簡易化するインタラクティブなクエリサービスです。Athena はサーバーレスであるため、インフラストラクチャの管理は不要であり、実行したクエリにのみ課金されます。Athena は最近、SELECT クエリまたは CREATE TABLE AS SELECT (CTAS) ステートメントの結果を使用するテーブルの作成のサポートをリリースしました。 アナリストは、CTAS ステートメントを使用して、データのサブセットまたは列のサブセット上の既存のテーブルから新しいテーブルを作成することができます。また、Apache Parquet や Apache ORC などのカラムナ形式にデータを変換し、分割するオプションもあります。Athena は、結果として得られたテーブルとパーティションを AWS Glue データカタログに自動的に追加し、その後のクエリですぐに使用できるようにします。 CTAS ステートメントは、大きなテーブルから構築された小さなテーブルでクエリを実行できるようにすることで、コストを削減し、パフォーマンスを向上させます。この記事では、元のデータセットよりも小さい新しいデータセットを作成し、その後のクエリをより高速に実行できるという、CTAS の使用の利点を示す 3 つのユースケースについて説明します。これらのユースケースではデータを繰り返し照会する必要があると想定して、より小さく、より最適なデータセットを照会して、より迅速に結果を取得できるようになりました。

Read More

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

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

Read More

SimilarWeb が、Amazon Athena と Upsolver を使って毎月数百テラバイトのデータを分析する方法

これは、SimilarWeb のデータ収集およびイノベーションチームのリーダーである Yossi Wasserman 氏の寄稿です。 SimilarWeb は、同社の説明によれば、「SimilarWeb は、インテリジェンス市場の先駆者であり、デジタル世界を理解するための標準です。SimilarWeb は、すべての地域のすべての業界のウェブサイトまたはモバイルアプリに関する詳細な情報を提供します。SimilarWeb は、マーケティング担当者、アナリスト、セールスチーム、投資家、エグゼクティブなどがデジタル世界で成功するために必要な洞察を活用して、企業が意思決定を行う方法を変えています。」 SimilarWeb は、デジタル世界全体で何が起こっているのかについての洞察を提供するマーケットインテリジェンスの会社です。何千社もの顧客がこれらの洞察を活用して、マーケティング、販売促進、投資決定などの戦略を強化する重要な判断を下しています。当社のソリューションがもたらす意思決定の重要性が、こうした情報を効果的に収集して使用する当社の能力を強調しています。 特に、私が率いているチームは SimilarWeb のモバイルデータ収集の監督を担当しています。現在、毎月数百 TB の匿名データを処理しています。 欠陥のあるデータや不完全なデータに基づいて顧客の洞察を提供することはできないので、データ収集プロセスは SimilarWeb にとって重要です。データ収集チームは、新しいタイプのデータ、パートナーの統合、全体的なパフォーマンスなどを可能な限り迅速に効率よく分析することを必要としています。チームは可能な限り早期に異常を特定し、対処することが不可欠です。このプロセスをサポートするツールは、大きな利点をもたらします。 SimilarWeb のモバイルデータ収集の技術的課題 数百 TB のデータが、異なるソースから毎月 SimilarWeb にストリーミングされます。データは複雑です。 数百のフィールドがあり、その多くは深くネストされており、null 値を持つものも数多く含まれています。データをきれいにし、正規化し、照会のために準備する必要があるため、こうした複雑さから技術的な課題が生じます。 最初の選択肢は、実行に数時間かかる毎日のバッチ処理で SimilarWeb のすべてのデータを処理する、既存のオンプレミス Hadoop クラスターを使用することでした。ビジネスクリティカルな監視にとって、24 時間の遅延は受け入れられません。 そこで、Hadoop を使用して新しいプロセスを開発することを検討しました。しかしながら、それには私たちのチームが毎日の作業から離れて、抽出、変換、ロード (ETL) ジョブのコーディング、スケール、維持に集中することが必要です。また、異なるデータベースを扱う必要があるため、チームが業務に集中する妨げともなります。そのため、チームのメンバー全員が新しいレポートを作成し、不一致を調査し、自動化されたテストを追加できるようなアジャイルソリューションが必要でした。 また、コンピューティングのボトルネックを引き起こした別個を数える問題もありました。別個を数える問題とは、反復要素を含むデータストリームで別個の要素の数を数えるのが難しいという問題です。たとえば、デバイス、オペレーティングシステム、国別など、数十億もの可能なセグメントの一意のビジター数を追跡します。別個を数えることは非加算的集約であるため、一意のビジターの正確な数を計算するには、通常、多くのメモリ集約型コンピューティングノードが必要です。 Amazon Athena を選んだ理由 こうした課題を解決するために、当社は Amazon Athena を選びました。  Athena が、もたらしたもの: SQL を使用する高速な照会 — 私たちのチームは SQL を使用してデータを照会したいと考えていましたが、従来の SQL […]

Read More

Pagely が、カスタマーサポートの分析を容易にするために AWS でサーバーレスデータレイクを実装

Pagely は、マネージド型 WordPress ホスティングサービスを提供する AWS アドバンスドテクノロジーパートナーです。当社の顧客は、使用、請求、サービスのパフォーマンスの可視性を向上させるために継続的に当社にプレッシャーをかけています。こうした顧客により良いサービスを提供するため、サービスチームは、アプリケーションサーバーが作成したログに効率的にアクセスする必要があります。 以前から、当社ではオンデマンドで基本的な統計を集めるシェルスクリプトを利用していました。最大の顧客のログを処理する場合、Amazon EC2 インスタンスで実行される最適化されていないプロセスを使用して 1 件のレポートを作成するのに 8 時間以上かかりました—時には、リソースの制限のためにクラッシュすることがありました。そこで、従来のプロセスの修正にさらに力を注ぐのではなく、適切な分析プラットフォームを実装する時が来たと判断しました。 当社の顧客のログはすべて、圧縮された JSON ファイルとして Amazon S3 に保存されています。Amazon Athena を使用して、これらのログに対して直接 SQL クエリを実行しています。データを準備する必要がないため、このアプローチは優れています。単にテーブルとクエリを定義するだけです。JSON は Amazon Athena でサポートされているフォーマットですが、パフォーマンスやコストに関して最も効率的なフォーマットというわけではありません。JSONファイルは、データの各行から 1 つまたは 2 つのフィールドを返すだけであってもその全体を読み取る必要があるので、必要以上に多くのデータをスキャンしなくてはなりません。さらに、JSON を処理するのが非効率であるため、クエリ時間が長くなります。 30 分のクエリタイムアウト限度に達したため、Athena で最大の顧客のログを照会することは理想的ではありませんでした。この制限を増やすことはできますが、クエリは既に必要以上に時間がかかるようになっていました。 この記事では、Pagely が AWS アドバンスドコンサルティングパートナーである Beyondsoft とどのように協力して、Beyondsoft が開発したオープンソースツールである ConvergDB を使用して DevOps 中心のデータパイプラインを構築したかについて説明します。このパイプラインでは、AWS Glue を使用してアプリケーションログを最適化されたテーブルに変換し、Amazon Athena を使用して迅速かつ費用対効果の高いクエリを実行できます。 Beyondsoft との協力 当社は、できるだけ少ないオーバーヘッドで、エンジニアがデータに簡単にアクセスできるようにするために何かを行う必要があることを知っていました。クエリ時間を短縮するために、データをより最適なファイル形式にしたいと考えていました。無駄のない企業なので、当社には技術を深く掘り下げる余裕はありませんでした。このギャップを克服するために、Beyondsoft と協力して、データレイクの最適化と管理に最善のソリューションを決定しました。 ConvergDB […]

Read More

Amazon QuickSight でメールレポートとデータラベルのサポートを開始

今日は、Amazon QuickSight でご利用いただけるようになった、メールレポートとデータラベルについてご紹介します。 メールレポート Amazon QuickSight のメールレポートでは、定期的および 1 回限りのレポートを受け取ることができます。このレポートはメールボックスに直接配信されます。メールレポートを使用することで、Amazon QuickSight アカウントにログインすることなく最新の情報にアクセスできます。また、メールレポートでデータにオフラインでアクセスすることもできます。より深く分析および考察するために、メールレポートをクリックするだけで、Amazon QuickSight のインタラクティブダッシュボードに移動できます。 メールを使用してレポートを送信する 作成者は Amazon QuickSight アカウント内でダッシュボードにアクセスできるユーザーに、1 回限りまたは定期的なメールレポートを送信するよう選択できます。受信者のユーザー設定に応じて、デスクトップまたはモバイルレイアウト用にメールレポートをカスタマイズできます。 ダッシュボード用にメールレポートを有効化するのは簡単です。ダッシュボードページで [Share] (共有) メニューにナビゲートし、[Email Report] (メールレポート) オプションを選択します。ダッシュボード上でメールレポートを送信する、またはスケジュールを変更するには、ダッシュボードの所有者か共有所有者である必要があります。 この画面ではスケジュール、メールの詳細 (たとえば、件名の行)、受信者のオプションを指定してメールレポートを構成できます。 メールレポートがダッシュボード用に有効化されたあとは、そのダッシュボードにアクセスできる全ユーザーが、メールレポートのサブスクリプションを登録または解除できます。また、受信者は自分のアカウント内でダッシュボードにナビゲートすることで、レイアウト設定 (モバイルまたはデスクトップ) を変更することもできます。また、作成者は書式設定とレイアウトが正しいかを確認するために、自分自身にテスト用のメールレポートを送信することもできます。 メールレポートがスケジュールされたあとは、指定された頻度とタイミングでレポートが配信されます。Amazon QuickSight ダッシュボードの所有者は、メールレポートの配信を一時停止したり、スケジュールされた配信とは別に 1 回限りのレポートを送信することもできます。何らかのエラーがあった、またはダッシュボードに関連付けられた、基となる SPICE データセットの更新に失敗した場合は、Amazon QuickSight は自動的にレポートの配信をスキップします。Amazon QuickSight はこのような場合、ダッシュボードの所有者にエラーレポートも送信します。 料金表: メールレポートは Amazon QuickSight Enterprise Edition でご利用いただけます。Amazon QuickSight の作成者の場合、メールレポートは毎月のサブスクリプション料金に含まれています。作成者は 1 か月間無制限でメールレポートを受け取ることができます。Amazon QuickSight の読者の場合、メールレポートの料金はセッション単位の料金モデルが適用されます。読者の場合、受信するメールレポート […]

Read More

Amazon Elasticsearch Service のインプレースバージョンアップグレード

本日、Amazon Elasticsearch Service (Amazon ES) は、バージョン 5.1 以降を実行するドメイン用のインプレース Elasticsearch アップグレードをサポートすることを発表しました。この新しい機能では、数回のクリックだけで、同じメジャーバージョン内での最新リリース (例えば 5.3 から 5.6 など) に、またはメジャーバージョンの最新リリースから次のメジャーバージョンの最新リリース (例えば 5.6 から 6.3) に移行できます。  また、同じドメインエンドポイント URL を保持しているため、ドメインと連動するサービスでは、新しいバージョンにアクセスするのに設定を変更する必要はありません。 これまで手作業でドメインアップグレードしていたのと比べて、新しい機能では新しい方法で操作を簡素化しています。この機能ができる前は、手動で以前のバージョンのスナップショットを作成し、対象バージョンの新しいドメインを作成し、手動でインデックススナップショットを新しいドメインに復元し、さらには新しいドメインを示すにアプリケーション構成に調整する必要がありました。 このブログ記事では、5.1 Elasticsearch ドメインから 6.3 Elasticsearch ドメインに移行する方法を説明します。 新しい機能でできること アップグレードプロセスは自動化しているため、一連のイベントは慎重に計画されており、対象バージョンへと正常に移行することが可能です。アップグレード中、ドメインに要求が追加される可能性もあります。 このプロセスには、以下のものが含まれます。 アップグレードをブロックする可能性のある問題の確認 アップグレードが失敗した場合に、ロールバックに対処するための Elasticsearch クラスタのスナップショットの作成 新しい Elasticsearch 版でのシャードの再配置 5.1 から 5.6 へのアップグレードの開始 アクティブなドメインのインプレースバージョンのアップグレードを実行するには、AWS マネジメントコンソールにサインインし、[Elasticsearch Service] を選択します。Amazon ES コンソールで、リストから自身のドメイン名を選択し、ダッシュボードを開きます。次に、[ドメインをアップグレード] を選択します。 対象となるアップグレードバージョンと、今すぐドメインをアップグレードするか、またはアップグレードの適格性を確認するかのオプションが表示されます。次のように [アップグレードの適格性を確認する] を選択すると、サービスはドメインをターゲットバージョンにアップグレードするためのチェックを実行します。 アップグレードの適格性のチェックを送信したら、[アップグレード履歴] […]

Read More