Category: Analytics*


Amazon EMR 4.7.0 – Apache TezとPhoenix, 既存アプリのアップデート

Amazon EMRを使えば素早くコスト効率よく大量のデータを処理することができます。2009年のローンチ以来、数多くの新機能と増え続けるHadoopエコシステムのアプリケーション達のサポートを追加してきました。以下は今年に入ってから追加したもののうちのいくつかになります。

本日またさらに一歩進めて、Apache Tez (データフロー駆動なデータ処理タスクの協調)とApache Phoenix (OLTPや業務分析のための高速なSQL)を新たにサポートし、合わせて既存のいくつかのアプリを更新しました。これらの新規や更新されたアプリケーションを使うためには、Amazon EMRのリリース4.7.0でクラスタを起動する必要があります。

新規 – Apache Tez (0.8.3)

TezはApache Hadoop YARN上で動きます。Tezはデータフローを定義するためのAPIを提供し、それによってデータ処理タスクのDAG (有向非巡回グラフ)を定義することができます。TezはHadoop MapReduceより高速になり得て、HiveとPigの両方と一緒に使うことができます。より詳しくは、EMRリリースガイドをご覧下さい。Tez UIにはDAGの可視化も含まれています:

UIは各DAGの詳細な情報も表示できます。

新規 – Apache Phoenix (4.7.0)

PhoenixはデータストアとしてHBase (Hadoopエコシステムのメンバーの1人)を使います。PhoenixにはJDBCドライバを使って、同じクラスタや他のクラスタ上で実行されているアプリケーションから接続可能です。いずれの方法でも、高速で低レイテンシで完全なACIDトランザクション機能をもったSQLでアクセスすることができます。SQLクエリはHBaseスキャンの手順にコンパイルされ、並列でスキャンし、各々の結果を集約することで結果セットを生成します。より詳しくはPhoenix Quick Start GuideApache Phoenix Overviewのプレゼンテーションをご覧下さい。

アプリケーションの更新

また、以下のアプリケーションを更新しています:

  • HBase 1.2.1 – HBaseは低レイテンシで大量のデータにランダムアクセスできます。新しいバージョンはいくつかのバグ修正を含みます。
  • Mahout 0.12.0 – Mahoutはスケール可能な機械学習やデータマイニングを提供します。新しいバージョンには大量の数学や統計の機能が含まれています。
  • Presto 0.147 – Prestoは大量のデータセットのために設計された分散SQLクエリエンジンです。新しいバージョンは機能追加とバグ修正が含まれます。

Amazon Redshift JDBCドライバ

RedshiftのJDBCドライバを使うことで、EMRクラスタ上のアプリケーションからRedshiftクラスタにアクセスしデータを更新することができます。2つのバージョンのドライバがクラスタにインストールされています。

  • JDBC 4.0 互換 – /usr/share/aws/redshift/jdbc/RedshiftJDBC4.jar.
  • JDBC 4.1 互換 – /usr/share/aws/redshift/jdbc/RedshiftJDBC41.jar.

新しいアプリケーションを使い始めるには、単純にあたらしいEMRクラスタを起動し、その際にリリース4.7.0を選択し必要とするアプリケーションを選択するだけです。

Jeff;

原文: https://aws.amazon.com/blogs/aws/amazon-emr-4-7-0-apache-tez-phoenix-updates-to-existing-apps/ (翻訳: SA岩永)

Amazon Kinesis アップデート – Amazon Elasticsearch Service との統合、シャード単位のメトリクス、時刻ベースのイテレーター

Amazon Kinesis はストリーミングデータをクラウド上で簡単に扱えるようにします。

Amazon Kinesis プラットフォームは3つのサービスから構成されています:Kinesis Streams によって、開発者は独自のストリーム処理アプリケーションを実装することができます;Kinesis Firehose によって、ストリーミングデータを保存・分析するための AWS へのロード処理がシンプルになります;Kinesis Analytics によって、ストリーミングデータを標準的な SQL で分析できます。

多くの AWS のお客様が、ストリーミングデータをリアルタイムに収集・処理するためのシステムの一部として Kinesis Streams と Kinesis Firehose を利用しています。お客様はこれらが完全なマネージドサービスであるがゆえの使い勝手の良さを高く評価しており、ストリーミングデータのためのインフラストラクチャーを独自に管理するかわりにアプリケーションを開発するための時間へと投資をしています。

本日、私たちは Amazon Kinesis Streams と Amazon Kinesis Firehose に関する3つの新機能を発表します。

  • Elasticsearch との統合 – Amazon Kinesis Firehose は Amazon Elasticsearch Service へストリーミングデータを配信できるようになりました。
  • 強化されたメトリクス – Amazon Kinesis はシャード単位のメトリクスを CloudWatch へ毎分送信できるようになりました。
  • 柔軟性 – Amazon Kinesis から時間ベースのイテレーターを利用してレコードを受信できるようになりました。

Amazon Elasticsearch Service との統合

Elasticsearch はポピュラーなオープンソースの検索・分析エンジンです。Amazon Elasticsearch Service は AWS クラウド上で Elasticsearch を簡単にデプロイ・実行・スケールさせるためのマネージドサービスです。皆さんは、Kinesis Firehose のデータストリームを Amazon Elasticsearch Service のクラスターへ配信することができるようになりました。この新機能によって、サーバーのログやクリックストリーム、ソーシャルメディアのトラフィック等にインデックスを作成し、分析することが可能になります。

受信したレコード(Elasticsearch ドキュメント)は指定した設定に従って Kinesis Firehose 内でバッファリングされたのち、複数のドキュメントに同時にインデックスを作成するバルクリクエストを使用して自動的にクラスターへと追加されます。なお、データは Firehose へ送信する前に UTF-8 でエンコーディングされた単一の JSON オブジェクトにしておかなければなりません(どのようにこれを行うかを知りたい方は、私の最近のブログ投稿 Amazon Kinesis Agent Update – New Data Preprocessing Feature を参照して下さい)。

こちらが、AWS マネージメントコンソールを使用したセットアップの方法です。出力先(Amazon Elasticsearch Service)を選択し、配信ストリームの名を入力します。次に、Elasticsearch のドメイン(この例では livedata)を選択、インデックスを指定し、インデックスのローテーション(なし、毎時、日次、週次、月次)を選択します。また、全てのドキュメントもしくは失敗したドキュメントのバックアップを受け取る S3 バケットも指定します:

そして、バッファーのサイズを指定し、S3 バケットに送信されるデータの圧縮と暗号化のオプションを選択します。必要に応じてログ出力を有効にし、IAM ロールを選択します:

一分程度でストリームの準備が整います:

コンソールで配信のメトリクスを見ることもできます:

データが Elasticsearch へ到達した後は、KibanaElasticsearch のクエリー言語による視覚的な検索ができます。

総括すると、この統合によって、皆さんのストリーミングデータを収集し、Elasticsearch に配信するための処理は実にシンプルになります。もはや、コードを書いたり、独自のデータ収集ツールを作成したりする必要はありません。

シャード単位のメトリクス

全ての Kinesis ストリームは、一つ以上のシャードによって構成されており、全てのシャードは一定量の読み取り・書き込みのキャパシティを持っています。ストリームにシャードを追加することで、ストリームのキャパシティは増加します。

皆さんは、それぞれのシャードのパフォーマンスを把握する目的で、シャード単位のメトリクスを有効にすることができるようになりました。シャードあたり6つのメトリクスがあります。それぞれのメトリクスは一分間に一回レポートされ、通常のメトリクス単位の CloudWatch 料金で課金されます。この新機能によって、ある特定のシャードに負荷が偏っていないかを他のシャードと比較して確認したり、ストリーミングデータの配信パイプライン全体で非効率な部分を発見・一掃したりすることが可能になります。例えば、処理量に対して受信頻度が高すぎるシャードを特定したり、アプリケーションから予想よりも低いスループットでデータが読まれているシャードを特定したりできます。

こちらが、新しいメトリクスです:

IncomingBytes – シャードへの PUT が成功したバイト数。

IncomingRecords – シャードへの PUT が成功したレコード数。

IteratorAgeMilliseconds – シャードに対する GetRecords 呼び出しが戻した最後のレコードの滞留時間(ミリ秒)。値が0の場合、読み取られたレコードが完全にストリームに追いついていることを意味します。

OutgoingBytes – シャードから受信したバイト数。

OutgoingRecords – シャードから受信したレコード数。

ReadProvisionedThroughputExceeded – 秒間5回もしくは2MBの上限を超えてスロットリングされた GetRecords 呼び出しの数。

WriteProvisionedThroughputExceeded – 秒間1000レコードもしくは1MBの上限を超えてスロットリングされたレコードの数。

EnableEnhancedMetrics を呼び出すことでこれらのメトリクスを有効にすることができます。いつもどおり、任意の期間で集計を行うために CloudWatch の API を利用することもできます。

時刻ベースのイテレーター

任意のシャードに対して GetShardIterator を呼び出し、開始点を指定してイテレーターを作成することで、アプリケーションは Kinesis ストリームからデータを読み取ることができます。皆さんは、既存の開始点の選択肢(あるシーケンス番号、あるシーケンス番号の後、最も古いレコード、最も新しいレコード)に加え、タイムスタンプを指定できるようになりました。指定した値(UNIX 時間形式)は読み取って処理しようとする最も古いレコードのタイムスタンプを表します。

— Jeff;
翻訳は SA 内海(@eiichirouchiumi)が担当しました。原文はこちらです。

Amazon Kinesis エージェントの更新情報 – 新しいデータ事前処理機能

Amazon Kinesis エージェント用の新しいデータ事前処理機能について同僚の Ray Zhu が説明したゲスト投稿を以下に掲載します。


Jeff


Amazon Kinesis エージェントは、Amazon Kinesis StreamsAmazon Kinesis Firehose にデータを信頼性の高い方法で簡単に送信できるようにする、スタンドアロンの Java ソフトウェアアプリケーションです。エージェントはファイルセットを監視して新しいデータを検出し、Kinesis Streams または Kinesis Firehose に連続的に送信します。ファイルのローテーション、チェックポイント処理、および失敗時の再試行も処理します。また、Amazon CloudWatch もサポートするので、エージェントからのデータフローの入念な監視やトラブルシューティングも行えます。

Kinesis エージェントを使用したデータ事前処理
今回、データ事前処理機能がエージェントに追加され、ユーザーはデータを Kinesis Streams または Kinesis Firehose に送信する前に、適切に書式設定できます。 この投稿の記述時点で、エージェントは次の 3 つの処理オプションをサポートしています。エージェントはオープンソースなので、ユーザーはこれらの処理オプションを開発したり、拡張したりできます。

SINGLELINE – このオプションは、改行文字と、行頭および行末のスペースを削除して、複数行のレコードを単一行のレコードに変換します。

CSVTOJSON – このオプションは、区切り文字で区切られた書式から JSON 書式にレコードを変換します。

LOGTOJSON – このオプションは、一般的に使用されている複数のログ書式を JSON 書式に変換します。現在サポートされているログ書式は、Apache Common Log、Apache Combined Log、Apache Error Log、および RFC3164 (syslog) です。

ほぼリアルタイムで Apache Tomcat のアクセスログを分析
ここでは、Kinesis エージェントの事前処理機能、Amazon Kinesis Firehose、および Amazon Redshift を使用して、Tomcat のアクセスログをほぼリアルタイムで分析する例を示します。 次に、全体的な手順を説明します。

まず、Tomcat アクセスログの保存用に Redshift クラスターでテーブルを作成します。次の SQL 文を使用して、テーブルを作成します。

SQL
CREATE TABLE logs(
host VARCHAR(40),
ident VARCHAR(25),
authuser VARCHAR(25),
datetime VARCHAR(60),
request VARCHAR(2048),
response SMALLINT NOT NULL,
bytes INTEGER,
referer VARCHAR(2048),
agent VARCHAR(256));

次に、前の手順で作成した Redshift テーブルにデータを連続的に配信する Kinesis Firehose 配信ストリームを作成する必要があります。

これで、Redshift テーブルと Firehose 配信ストリームをセットアップできました。次に、Kinesis エージェントを Tomcat サーバーにインストールして、Tomcat アクセスログの監視、およびログデータの配信ストリームへの連続的な送信を行う必要があります。次の図は、生の Tomcat アクセスログのスクリーンショットを示しています。

エージェント構成で、LOGTOJSON 処理オプションを使用して、生の Tomcat アクセスログデータを JSON 書式に変換してから、データを配信ストリームに送信します。セットアップの内容は、次のとおりです。

JavaScript
{
   "cloudwatch.emitMetrics":true,
   "flows":[
      {
         "filePattern":"/data/access.log*",
         "deliveryStream":"access_log_stream",
         "initialPosition":"START_OF_FILE",
         "dataProcessingOptions":[
            {
               "optionName":"LOGTOJSON",
               "logFormat":"COMBINEDAPACHELOG"
            }
         ]
      }
   ]
}

これですべての準備が整ったので、エージェントを起動します。数分後に、Tomcat アクセスログデータが、S3 バケットと Redshift テーブルに現れます。S3 バケットでは、データは次のように表示されます。生ログデータは、正しく JSON 書式になっています。

データは Redshift テーブルで次のように表示されます。

SQL クエリを実行した Tomcat アクセスログの分析や、好みのビジネスインテリジェンスツールを使用したデータ視覚化が可能です。

データパイプライン全体をセットアップするのに、1 時間もかかりませんでした。これで、データが Tomcat サーバーで生成された数分後に、お気に入りのビジネスインテリジェンスツールを使用して、アクセスログデータを分析したり視覚化したりできます。

今すぐ利用しましょう
Kinesis エージェントのデータ事前処理機能は、今すぐに利用し始めることができます。Amazon Kinesis エージェントリポジトリにアクセスしてください。詳細については、「Kinesis Firehose Developer Guide」の「Use Agent to Preprocess Data」をご覧ください。

Ray Zhu、シニア製品マネージャー