Category: AWS Big Data

数週間前に、当社は2つの重要なパフォーマンス改善機能をAmazon Kinesis Data Streams (KDS):に追加しました。拡張ファンアウトと HTTP/2 データ取得 API です。拡張ファンアウトは、開発者が各ストリームコンシューマーにそれぞれの読み取り処理量を提供することにより、ストリームコンシューマー (リアルタイムでのストリームからのアプリケーションの読み取りデータ) の数を増加させることができます。HTTP/2データ取得APIは、一般的なシナリオでデータをプロデューサーからコンシューマーに70ミリ秒以内に配信できるようになります (65%の向上)。これらの新しい機能により、開発者は Amazon Kinesis Data Streams 上でより高速で、より反応性、並列性に優れ、レイテンシに敏感なアプリケーションを構築できるようになります。 Kinesis は実際に、次のストリーミングサービスのファミリを指します。 Kinesis Video Streams、Kinesis Data Firehose、Kinesis Data Analytics、および本日のブログ投稿のトピックである、 Kinesis Data Streams (KDS)。Kinesis Data Streams では、完全に管理され、大規模にスケーラブルなサービスを利用して、開発者は容易に、かつ継続的にストリーミングデータをリアルタイムで収集、処理、および分析できるようになります。KDS は何十万にも上るソースから 1 秒当たりの数ギガバイトのデータを取り込むことができます。ウェブサイトのクリックストリームやソーシャルメディアのフィードから財務取引や位置情報データに至るまであらゆるものを対象としています。 Kinesis Data Streams は、シャード (shard) の概念を使用してスケールされます。1 個のシャードは、1MB / 秒または 1000 レコード / 秒のインジェスト容量と 2MB / 秒の出力容量を提供します。顧客が数千から数万個のシャードを持ち、毎秒数十ギガバイトの入出力をサポートすることは珍しいことではありません。ファンアウト機能を強化する前に、2MB / 秒 / […]

こんにちは。AWS ソリューションアーキテクトの八木達也 ( @ygtxxxx ) です。 7月23日に、「Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –」を開催いたしました。 AWSジャパン主催でデジタル広告業界の方向けのイベントを開催するのは2年ぶりでしたが、定員60人のところ55名の方にお集まりいただき、盛況となりました。             このイベントは「Digital Advertising、AdTech 領域における Machine Learningの実践知」を「互いに学び合う」ことができる場を作ることを目標としていたため、AWSメンバーによるプレゼンテーションだけではなく、お客様プレゼンテーションを中心としたAGENDAを構成しました。機会学習という領域における、テクノロジー視点でのお取組み、組織育成視点でのお取組み、それぞれの視点で最先端な活動をなさる方々よりご登壇を頂きました。 まずは主催者の唐木/八木よりオープニングセッションを行いました。 唐木より全体の説明を行い、八木より「Machine Learning for Digital Advertising」というタイトルでプレゼンテーションを行いました。 Machine Learning for Digital Advertising from Amazon Web Services Japan 次に、アナリティクス スペシャリスト ソリューションアーキテクトの志村より「AWS ML Services Update」というタイトルでプレゼンテーションを行いました。 AWS ML Update from Amazon […]

こんにちは、マーケティングの鬼形です。 先日 (2018/6/19) 開催しました AWS Black Belt Online Seminar「データレイク入門: AWSで様々な規模のデータレイクを分析する効率的な方法」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180619 AWS Black Belt Online Seminar データレイク入門: AWSで様々な規模のデータレイクを分析する効率的な方法 from Amazon Web Services Japan PDF Q. RDSからGlueでData Catalogを作成する際、負荷などかかるのでしょうか？分析用にユーザ操作から切り離したほうが良いのか？気にしなくて良いのかを知りたいです。 A. RDS をクロールする際、スキーマ取得のため Connection を使用します。瞬間的な処理にはなりますが、Connection が使用される点に留意いただき、検証の実施と実行タイミングの検討をお願いいたします。 Q. ベストプラクティス 2/5, 3/5 で説明されていた Parquetを使用した場合のメトリクスはRedshift Spectrum ではなく、Athenaを使用している場合に同様の情報を知ることは可能でしょうか。 A. Athena では同様の情報を確認いただくことができません。 以上です。 今後の AWS Black Belt Online Seminar のスケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております！ […]

新しいことを始めるのは何かと大変です。どこから手をつければよいのでしょうか? どのリソースが不慣れな分野を手助けしてくれるのでしょうか? さらに手助けが必要なときは何を頼ればよいのでしょうか? 新規に AWS アカウントを登録いただいたお客様、すでにご登録いただいているお客様のどちらにも、初めて知ることは常に出てきます。私たちのサービスは、絶えず変化するお客様のニーズに応えるために進化しているからです。お客様が AWS で構築する際に滞りなく設定できるように、こちらの AWS サイトで利用できるビッグデータのトレーニングやリソースについて、このクイックリファレンスガイドをまとめました。

ETL（Extract、Transform、Load）プロセスを使用すると、ソース・システムからデータ・ウェアハウスにデータをロードできます。 これは、通常、バッチまたはほぼリアルタイムのインジェスト（挿入）プロセスとして実行され、データウェアハウスを最新の状態に保ち、エンドユーザーに最新の分析データを提供します。 Amazon Redshiftは、高速でペタバイト規模のデータウェアハウスであり、データ駆動型の意思決定を簡単に行うことができます。 Amazon Redshiftを使用すると、標準的なSQLを使用して、費用対効果の高い方法で大きなデータを洞察することができます。 StarおよびSnowflakeスキーマから、分析クエリを実行するための単純化された正規化されていないテーブルまで、あらゆるタイプのデータモデルを使用した分析が可能です。 堅牢なETLプラットフォームを操作し、Amazon Redshiftにデータをタイムリーに配信するには、Amazon Redshiftのアーキテクチャを考慮してETLプロセスを設計します。 従来のデータウェアハウスからAmazon Redshiftに移行する場合、リフト・アンド・シフト方式を採用することが魅力的ですが、結果としてパフォーマンスとスケールの問題が長期的に発生する可能性があります。 この記事では、ETLプロセスにおける最適かつ一貫した実行時間を確保するためのベスト・プラクティスを下記にご紹介します。 複数の均等なサイズのファイルからデータの COPY Workload Management (WLM) を用いたETL実行時間の改善 定期的なテーブルのメンテナンスの実施 単一のトランザクションで複数ステップの実行 データの一括読み込み UNLOADを利用した大きな結果セットの抽出 アドホックETL処理に Amazon Redshift Spectrumを使用 診断クエリを使用して日常的なETLヘルスの監視 1. 複数の均等なサイズのファイルからデータの COPY Amazon RedshiftはMPP（大規模並列処理）データベースで、すべての計算ノードがデータの取り込み作業を分割して並列化します。 各ノードはさらにスライスに細分され、各スライスは1つ以上の専用コアを有し、処理能力を等しく分割します。 ノードあたりのスライス数は、クラスタのノードタイプによって異なります。 たとえば、各DS2.XLARGE計算ノードには2つのスライスがありますが、各DS2.8XLARGE計算ノードには16のスライスがあります。 Amazon Redshiftにデータを読み込むときは、各スライスに同じ量の作業をさせることを目指すべきです。 1つの大きなファイルまたは不均一なサイズに分割されたファイルからデータをロードすると、一部のスライスは他のスライスよりも多くの仕事をする必要があります。 その結果、プロセスは最も遅い、または最も負荷の高いスライスと同じ速度で実行されます。 以下の例では、1つの大きなファイルが2ノードのクラスタにロードされ、ノード「Compute-0」のうちの1つだけがすべてのデータ処理を実行します。 データファイルを分割する際には、圧縮後のサイズがほぼ同じ（1 MB〜1 GB）であることを確認してください。 ファイル数は、クラスタ内のスライス数の倍数にする必要があります。 また、gzip、lzop、またはbzip2を使用してロードファイルを個別に圧縮し、大規模なデータセットを効率的にロードすることを強くお勧めします。 1つのテーブルに複数のファイルをロードする場合は、複数のCOPYコマンドではなく、テーブルに対して1つのCOPYコマンドを使用します。 Amazon Redshiftはデータの取り込みを自動的に並列化します。 1つのCOPYコマンドを使用してデータをテーブルにバルクロードすると、クラスタリソースの最適な使用と可能な限り高いスループットが可能となります。 2. Workload Management (WLM) を用いたETL実行時間の改善 […]

多くの業務や運用において、頻繁に更新される大規模なデータを分析することが求められるようになっています。例えばログ分析においては、振る舞いのパターンを認識したり、アプリケーションのフロー分析をしたり、障害調査をしたりするために大量のログの可視化が必要とされます。 VPCフローログはAmazon VPCサービス内のVPCに属するネットワークインターフェースを行き来するIPトラフィック情報をキャプチャします。このログはVPC内部に潜む脅威やリスクを認識したり、ネットワークのトラフィック・パターンを調査するのに役立ちます。フローログはAmazon CloudWatchログに格納されます。いったんフローログを作成すれば、Amazon CloudWatchログを用いて見たり取り出したりすることができるようになります。 フローログは様々な業務を助けてくれます。例えば、セキュリティグループのルールを過度に厳しくしすぎたことによって特定のトラフィックがインスタンスに届かない事象の原因調査などです。また、フローログを、インスタンスへのトラフィックをモニタリングするためのセキュリティツールとして使うこともできます。 この記事はAmazon Kinesis Firehose、AWS Lambda、Amazon S3、Amazon Athena、そしてAmazon QuickSightを用いてフローログを収集し、格納し、クエリを実行して可視化するサーバーレス・アーキテクチャを構成する手順を示します。構成する中で、Athenaにおいてクエリにかかるコストや応答時間を低減させるための圧縮やパーティショニング手法に関するベストプラクティスを学ぶこともできることでしょう。 ソリューションのサマリ 本記事は、3つのパートに分かれています。 Athenaによる分析のためにVPCフローログをS3へ格納。このセクションではまずフローログをLambdaとFirehoseを用いてS3に格納する方法と、格納されたデータにクエリを発行するためAthena上のテーブルを作成する方法を説明します。 QuickSightを用いてログを可視化。ここではQuickSightとQuickSightのAthenaコネクタを用いて分析し、その結果をダッシュボードを通じて共有する方法を説明します。 クエリのパフォーマンス向上とコスト削減を目的とした、Athenaにおけるデータのパーティション化。このセクションではLambda関数を用いてS3に格納されたAthena用のデータを自動的にパーティション化する方法を示します。この関数はFirehoseストリームに限らず、他の手段でS3上に年/月/日/時間のプリフィックスで格納されている場合でも使用できます。 パーティショニングはAthenaにおいてクエリのパフォーマンス向上とコスト削減を実現するための3つの戦略のうちの1つです。他の2つの戦略としては、1つはデータの圧縮、そしてもう1つはApache Parquetなどの列指向フォーマットへの変換があります。本記事では自動的にデータを圧縮する方法には触れますが、列指向フォーマットへの変換については触れません。本ケースのように列指向フォーマットへの変換を行わない場合でも、圧縮やパーティショニングは常に価値のある方法です。さらに大きなスケールでのソリューションのためには、Parquetへの変換も検討して下さい。 VPCフローログを分析するためのサーバレスアーキテクチャ 以下の図はそれぞれのサービスがどのように連携するかを示しています。 VPCにフローログを作成すると、ログデータはCloudWatchログのロググループとして発行されます。CloudWatchログのサブスクリプションを利用することにより、S3に書き込むためにFirehoseを用いたLambda関数に対して、リアルタイムにログデータイベントを送り込むことが可能になります。   いったんS3にログデータが格納され始めれば、Athenaを利用してSQLクエリをアドホックに投入することができます。ダッシュボードを構築したり、画面からインタラクティブにデータを分析したりすることを好む場合には、Athenaに加えQuickSightによるリッチな可視化を簡単に構成できます。 Athenaの分析を目的としたS3へのVPCフローログの送信 この章では、Athenaによるクエリを可能とするためにフローログデータをS3に送信する方法を説明します。この例ではus-east-1リージョンを使用していますが、AthenaとFirehoseが利用できるのであればどのリージョンでも可能です。 Firehoseデリバリーストリームの作成 既存もしくは新しいS3バケットを格納先とするFirehoseデリバリーストリームを作成するためには、この手順を参考にして下さい。ほとんどの設定はデフォルトで問題ありませんが、格納先のS3バケットへの書き込み権限を持つIAMロールを選択し、GZIP圧縮を指定して下さい。デリバリーストリームの名前は‘VPCFlowLogsDefaultToS3’とします。 VPCフローログの作成 まず、この手順に従ってデフォルトVPCのVPCフローログを有効にしましょう。(訳注：デフォルトVPC以外の任意のVPCで構いません。) Firehoseに書き込むLambda用のIAMロールの作成 Firehoseに書き込むLambda関数を作成する前に、Firehoseにバッチ書き込みを許可するLambda用のIAMロールを作成する必要があります。次のように定義されるインラインアクセスポリシーを組み込んだ‘lambda_kinesis_exec_role’という名前のLambda用ロールを作成して下さい。 { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Action”: [ “logs:CreateLogGroup”, “logs:CreateLogStream”, “logs:PutLogEvents” ], “Resource”: “arn:aws:logs:*:*:*” }, { “Effect”: “Allow”, “Action”: [ […]