Category: AWS Big Data

本日、Amazon QuickSight に一連のアップデートを発表できることを、嬉しく感じております。 通常と組み込み用、両方のダッシュボードがマルチシートでより豊かに。 複数の軸ラベル方向オプションで、ダッシュボードの可読性が改善。 SPICE に、標準偏差、分散、および文字条件関数などの計算機能が追加。 広範囲のインタラクティブシナリオをサポートする、強化されたURLアクション。 画像をワンクリックで複製し、素早いオーサリング。 ダッシュボードのマルチシート対応 まず最初に、新しいタブコントロールからアクセスするマルチシートが使えるようになった、ダッシュボードのアップデートを見てみましょう。これにより、ダッシュボード内の情報が整理しやすくなりました。特定の対象エリアもしくはトピックに関連した画像を分離したシートで整理でき、タブ名によって明確に区別できます。閲覧側では、1 つのトピックに関連するインサイト全体の包括的な表示を、ダッシュボード上でナビゲーションできるようになります。

2019年5月、Amazon Kinesis Data Analytics が東京リージョンで利用できるようになりました。 これまで、東京リージョンにあるデータソース（Amazon Kinesis Data Streams または Amazon Kinesis Data Firehose）を Kinesis Data Analytics に接続するためには、リージョンを跨いで接続する必要がありました。Kinesis Data Analytics が東京リージョンで利用可能となったことにより、日本国内にあるデータソースと接続しやすくなり、ストリームデータ分析の環境をよりシンプルに構築できるようになりました。 Kinesis Data Analytics では、ストリーミングデータをリアルタイムに分析できるため、ビジネス上の素早いアクションが可能になります。今日では、Web・モバイルアプリケーションからのクリックストリームデータ、サーバーのアプリケーションログなど様々なデータソースから継続的にデータが生成されています。Kinesis Data Analytics は、新しいプログラミング言語や処理フレームワークを習得することなく、標準 SQL や Java (Apache Flink) でストリーミングデータをリアルタイムに分析することができます。また、フルマネージドサービスであり、受信データのボリュームとスループットレートに応じて自動的にスケールします。クエリで使用されるリソースのみが課金の対象となり、最低料金や初期費用はありません。

多くの組織では、AWS のサービスログを含むさまざまなログの保存先として Amazon Simple Storage Service (Amazon S3) を主に使用しています。ログデータを Amazon S3 に保存する利点の 1 つは、さまざまな方法でアクセスできることです。一般的な方法の 1 つは、S3 上のデータに対するサーバーレスのクエリエンジンである Amazon Athena を使用してクエリを実行することです。ログのクエリの一般的なユースケースは、サービスとアプリケーションのトラブルシューティング、パフォーマンス分析、およびセキュリティ監査です。Athena で最高のパフォーマンスを得てクエリコストを削減するには、AWS ビッグデータブログの「Top 10 Performance Tuning Tips for Amazon Athena」で概説されているように、一般的なベストプラクティスに従うことをお勧めします。これらのベストプラクティスには、Apache Parquet のようなデータを円柱形式に変換し、結果として得られたデータを S3 で分割することが含まれます。 この記事では、Athena Glue Service Logs (AGSlogger) として知られる Python ライブラリをオープンソース化しています。このライブラリには、最も一般的なログ形式を解析および最適化するための定義済みテンプレートがあります。このライブラリは、AWS Glue のスキーマの定義、パーティションの管理、および抽出、変換、ロード (ETL) ジョブ内でのデータ変換のためのメカニズムを提供します。AWS Glue は、サーバーレスのデータ変換およびカタログ作成サービスです。このライブラリを AWS Glue ETL ジョブと組み合わせて使用すると、ログデータを処理するための共通のフレームワークを有効にできます。 AWS Glue ETLで Python […]

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 5月29日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。去年から行ってきた恒例のワークショップで第7回目となります。去年も盛況でしたが、今回も130名くらいのお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスである Amazon S3 を中心とした Data Lake について解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、Amazon Athena や Amazon Redshift の各 AWS サービスを駆使して実際にラムダアーキテクチャを構築することがゴールです。とはいえ全てを構築するのはボリュームが大きいため、スピードレイヤー or バッチレイヤー or 全部入りでコース分けて取り組めるようハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回、参加者も多くいらっしゃいましたので、サポートするソリューションアーキテクトも6名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか？   次回は真夏の7月に開催予定です。ご参加お待ちしております。    

ノートブックは、インタラクティブにビッグデータアプリケーションを開発するための標準ツールとなりつつありますが、その理由は簡単に想像がつきます。柔軟性のあるアーキテクチャは、複数言語でのデータの実験、インタラクティブなコードのテスト、そして大規模データセットの可視化を可能にしてくれます。科学者と開発者がノートブックツールに簡単にアクセスできるように、AWS は Amazon EMR ノートブックのサービスを開始しました。これは、人気のあるオープンソースアプリケーション、Jupyter ノートブックをベースとしたマネージド型ノートブック環境です。EMR Notebooks は Spark Magic カーネルをサポートし、このカーネルは PySpark、Spark SQL、Spark R、および Scala といった言語を使用して、EMR クラスターにジョブをリモートで送信することができます。Spark Magic カーネルは、クラスターで実行される Spark の REST サーバーである Apache Livy 経由で Spark コードを送信します。 EMR Notebooks は、Apache Spark でのアプリケーションの実験と構築を容易にするように設計されています。このブログ記事では、まず EMR Notebooks が提供するいくつかのメリットについてお話しします。その後、異なる EMR クラスターへのノートブックのアタッチとデタッチ、ノートブック内からの Spark アクティビティの監視、ユーザーアクセス許可を制御するためのタグの使用、およびノートブックユーザーとそのアクションを追跡するためのユーザー偽装のセットアップなどの機能をいくつかご紹介します。EMR Notebooks の作成と使用について学ぶには、「Amazon EMR ノートブックの使用」にアクセスする、または AWS オンラインテックトークのオンラインセミナーの手順に従うことができます。 EMR Notebooks のメリット EMR Notebooks の便利な機能のひとつは、基礎となるクラスターインフラストラクチャからのノートブック環境の分離です。この分離は、新しいクラスターを起動するたびにノートブックをデプロイまたは設定する作業に煩わされることなく、一時的なクラスターに対してノートブックコードを簡単に実行できるようにしてくれます。SSH アクセスをセットアップするための時間を費やしたり、ポートフォワーディングのためにブラウザを設定したりすることなく、EMR の AWS […]

一般的に、コード用のユニットテストを書くと思いますが、お使いのデータもテストしているのでしょうか? 不正確または不正なデータは、本番システムに大きな影響を与える可能性があります。データ品質問題の例は次のとおりです。 値がない場合は、本番システムで null 以外の値を必要とするエラー (NullPointerException) が発生する可能性があります。 データ分布が変化すると、機械学習モデルで予期しない出力につながることがあります。 データの集計を誤ると、ビジネスでの判断を下す際に誤った意思決定につながる可能性があります。 このブログ記事では、Amazon で開発し、使用されているオープンソースツールである Deequ を紹介したいと思います。Deequ では、データセットのデータ品質メトリクスを計算したり、データ品質の制約を定義および確認したり、データ分布の変化について通知を受け取ったりすることができます。確認や検証のアルゴリズムを直接実装する代わりに、データの外観を記述することに集中できます。Deequ は確認を提案することでお客様をサポートします。Deequ は Apache Spark に実装されています。通常は分散型ファイルシステムまたはデータウェアハウスに存在する大規模なデータセット (数十億行の規模と考えられる) に合わせて拡張するように設計されています。 Amazon での Deequ Deequ は、多くの大規模な本番データセットの品質を検証するために Amazon で内部的に使用されています。データセットの製作者は、データ品質の制約を追加および編集できます。このシステムは、定期的に (データセットの新しいバージョンごとに) データ品質メトリクスを計算し、データセットの製作者によって定義された制約を検証し、成功した場合にはデータセットをコンシューマーに公開します。エラーが発生した場合、データセットの公開は中止され、製作者はアクションをとるように通知を受けます。データの品質問題はコンシューマーのデータパイプラインに伝播しないため、問題が発生したときの影響範囲が減少します。 Deequ の概要 Deequ を使用するために、その主要コンポーネントを見てみましょう (図 1 も参照)。 メトリクス計算 — Deequ はデータ品質メトリクス、つまり完全性、最大値、相関関係などの統計情報を計算します。Deequ は、Spark を使用して Amazon S3 などのソースから読み取り、最適化された一連の集計クエリを通じてメトリクスを計算します。データに基づいて計算された未加工メトリクスに直接アクセスできます。 制約の検証 — ユーザーは、一連のデータ品質において検証する制約を定義することに集中できます。Deequ は、データに対して計算される、必要な一連のメトリクスを導き出します。Deequ は、制約の検証結果を含むデータ品質レポートを生成します。 制約の提案 — 独自のカスタムデータ品質の制約を定義するか、有用な制約を推測するためにデータをプロファイルする自動制約提案方法を使用することを選択できます。 図 […]

データウェアハウスは、データから実用的な洞察を分析および抽出するための重要なコンポーネントです。Amazon Redshift は、高速でスケーラブルなデータウェアハウスであり、データウェアハウスとデータレイク全体ですべてのデータを分析するのに費用対効果が高くなります。 Amazon Redshift コンソールは最近、クエリエディタを開始しました。クエリエディタは、AWS マネジメントコンソールから直接 Amazon Redshift クラスターで SQL クエリを実行するためのブラウザ内インターフェイスです。Amazon Redshift クラスターでホストされているデータベースでクエリを実行するには、クエリエディタを使用するのが最も効率的な方法です。 クラスターを作成したら、すぐにクエリエディタを使用して Amazon Redshift コンソールでクエリを実行できます。クエリエディタは外部の JDBC/ODBC クライアントを使用してデータベースに接続するのに代わる優れた方法です。 この記事では、クラスターにデータをロードし、コンソールからクラスターのパフォーマンスを直接モニターするための SQL クエリを実行する方法を説明します。 SQL IDE やツールの代わりにクエリエディタを使用する クエリエディタは、Amazon Redshift クラスターで SQL クエリを実行するためのブラウザ内インターフェイスを提供します。計算ノードで実行されるクエリの場合は、クエリの横にクエリ結果とクエリ実行プランを表示できます。 クエリを可視化し、便利なユーザーインターフェイスを実現する機能により、データベース管理者としてもデータベース開発者としても、さまざまなタスクを実行できます。視覚的なクエリエディタを使用すると、次のことができます。 複雑なクエリを作成すること クエリを編集して実行すること データを作成して編集すること 結果を表示してエクスポートすること クエリに EXPLAIN プランを作成すること クエリエディタを使用すると、複数の SQL タブを同時に開くこともできます。色付きの構文、クエリのオートコンプリート、およびシングルステップのクエリフォーマットはすべて、追加のボーナスです。 データベース管理者は通常、よく使用する SQL ステートメントのリポジトリを定期的に管理しています。これをメモ帳のどこかに書き記せば、保存したクエリ機能を存分に活かせるでしょう。この機能を使用すると、よく実行する SQL ステートメントを一度に保存して再利用できます。これにより、以前に実行した SQL ステートメントを確認、再実行、および変更することが効率的になります。クエリエディタにはエクスポーターもあり、クエリ結果を CSV 形式にエクスポートできます。 クエリエディタを使用すると、クラスター上にスキーマやテーブルを作成する、テーブルにデータをロードするなどの一般的なタスクを実行できます。これらの一般的なタスクは、コンソール上で直接実行するいくつかの単純な SQL ステートメントを使用して可能になりました。コンソールから日々の管理タスクを行うこともできます。これらのタスクには、クラスター上で長時間実行されているクエリを見つけること、クラスター上で長時間実行されている更新で潜在的なデッドロックをチェックすること、およびクラスターで使用可能な容量を確認することなどがあります。 クエリエディタは […]

2019 年 2 月、アマゾン ウェブ サービス (AWS) は、Amazon Kinesis Data Firehose に Custom Prefixes for Amazon S3 Objects と呼ばれる新機能を発表しました。これにより、顧客はデータレコードが配信される Amazon S3 プレフィックスのカスタム表現を指定できます。 以前は、Kinesis Data Firehose ではリテラルプレフィックスのみを指定できました。次に、このプレフィックスを静的な日付形式のプレフィックスと組み合わせて、固定形式の出力フォルダを作成しました。 お客様は柔軟性を求めていたので、AWS は耳を傾け、実現したのです。 Kinesis Data Firehose は、アプリケーションや IoT デバイスなどのストリーミングソースからイベントデータを消費するために最も一般的に使用されています。  データは通常データレイクに格納されるため、処理して最終的にクエリを実行できます。  Amazon S3 にデータを保存するときは、関連データを分割またはグループ化し、同じフォルダにまとめて保存することをお勧めします。  これにより、パーティション化されたデータをフィルタリングし、各クエリでスキャンされるデータ量を制御することができるため、パフォーマンスが向上しコストが削減されます。 データをグループ化する一般的な方法は日付順です。  Kinesis Data Firehose はデータを自動的にグループ化し、日付に基づいて Amazon S3 の適切なフォルダに保存します。  ただし、Amazon S3 内のフォルダーの命名は、Apache Hive の命名規則と互換性がありません。これにより、AWS Glue クローラーを使用してデータをカタログ化し、ビッグデータツールを使用して分析することが難しくなります。 この記事では、Kinesis Data Firehose が […]

ストリーム処理によってリアルタイムデータの収集、処理、分析が容易となるため、洞察が継続して生まれ、新たに生じる状況にも素早く対応できるようになります。この機能は得られた洞察の価値が、時間の経過とともに減少する場合に役立ちます。つまり検出した状況に迅速に対応できればできるほど、この反応がより価値のあるものとなります。たとえば不正なクレジットカードのトランザクションが発生し、それを分析してブロックするようなストリーミングアプリケーションを考えてみましょう。そのアプリケーションを従来のバッチ指向のもの、つまりその日の営業を終了する際に不正な取引を識別して、翌朝にはレポートを生成するアプローチと比較してみてください。 洞察の価値が時間の経過とともに下がっていくのは、よくあることです。そういう訳でストリーム処理をすると、分析アプリケーションの価値が大幅に向上するのです。ただしデータを継続的に受信し処理するストリーミングアプリケーションを構築して運用するのは、従来のバッチ指向の分析アプリケーションを運用するよりもはるかに困難です。 この投稿ではこうした課題に対処するため、Apache Flink と Amazon Kinesis Data Analytics for Java アプリケーションを使用する方法について解説します。自己管理環境と比較して運用上のオーバーヘッドを大幅に削減できるマネージドサービスに基づいて、信頼性が高く、スケーラブルで、可用性の高いストリーミングアーキテクチャを構築する方法を探ります。特に Kinesis Data Analytics for Java アプリケーションを使用して、Flink アプリケーションを準備および実行する方法に焦点を当てています。このため、ソースコードと AWS CloudFormation テンプレートを含む例に言及したシナリオを使用します。この例に沿ってご自身の AWS アカウントを使用するか、特定の要件に従ってコードを修正してください。

ビッグデータの世界における一般的なユースケースは、さまざまなデータソースからの大量のデータにおける抽出/変換 (ET) とデータ分析の実行です。多くの場合、この後でデータを分析してインサイトを取得します。このような大量のデータを処理するための最も人気のあるクラウドベースソリューションのひとつが Amazon EMR です。 Amazon EMR は、AWS での Apache Hadoop および Apache Spark などのビッグデータフレームワークの実行をシンプル化するマネージドクラスタープラットフォームです。Amazon EMR は、組織が複数のインスタンスを持つクラスターをほんの数分でスピンアップすることを可能にします。また、並列処理を使ってさまざまなデータエンジニアリングとビジネスインテリジェンスのワークロードを処理できるようにもしてくれます。こうすることで、クラスターの確立とスケーリングに関わるデータ処理の時間、工数、およびコストを大幅に削減することができます。 Apache Spark は、オープンソースで高速な汎用目的のクラスターコンピューティングソフトウェアで、ビッグデータの分散処理で広く利用されています。Apache Spark は、タスクの I/O と実行時間を削減するためにノード全体のメモリで並行コンピューティングを実行することから、クラスターメモリ (RAM) に大きく依存しています。 一般に、Amazon EMR で Spark アプリケーションを実行するときは、以下の手順を実行します。 Spark アプリケーションパッケージを Amazon S3 にアップロードする。 設定済みの Apache Spark で Amazon EMR クラスターを設定し、起動する。 Amazon S3 からクラスターにアプリケーションパッケージをインストールし、アプリケーションを実行する。 アプリケーションが完了したら、クラスターを終了する。 Spark アプリケーションを成功させるには、データと処理の要件に基づいて Spark アプリケーションを適切に設定することが大切です。デフォルト設定では Spark が利用できるクラスターのリソースのすべてを使用しない場合があり、物理メモリまたは仮想メモリの問題、あるいはその両方が発生する可能性があります。Stackoverflow.com では、この特定のトピックに関連する何千もの質問が提起されています。 […]