Category: Analytics*


暗号化を用いたセキュアな Amazon EMR

ここ数年で、エンタープライズ企業において Apache hadoop エコシステムを用いて、センシティブであったり、きわめて秘匿性が高かったりするデータを扱う、重要なワークロードを走らせるケースが非常に増えてきています。そうしたワークロードの特性により、エンタープライズ企業ではしっかりした組織/業界全体のポリシーや、規制、コンプライアンスのルールを定めています。それに基づいて、機密データの保護や、権限のない人がアクセスできないようにすることが求められています。

こうしたポリシーにおいては一般的に、データストアに保存されているとき、そしてデータを転送しているときの両方で暗号化が要求されます。Amazon EMR では “セキュリティ設定” を使うことで、AWSキーマネジメントサービス (KMS) からお客様自身が用意した暗号化要素まで、さまざまな暗号化キーや証明書を指定することができます。

暗号化設定についてのセキュリティ設定を作り、クラスター作成の際に、その設定を当てることができます。セキィリティ設定を一度作っておくことで、いくつものクラスターにその設定を簡単に適用可能です。

o_Amazon_EMR_Encryption_1_

この投稿ではEMRのセキュリティ設定による、複数段階のデータ暗号化のセットアッププロセスを概観します。暗号化について深く見ていく前に、データ暗号化が必要な状況を整理しましょう。

保存時のデータ

  • Amazon S3にあるデータ – EMRのS3クライアントサイド暗号化
  • ディスク上のデータ – Linux Unified Key System (LUKS) による、Amazon EC2 のインスタンスストアボリューム(ブートボリュームを除く)、クラスターインスタンスにアタッチされた Amazon EBS
    ボリューム

転送中のデータ

  • EMRからS3に転送中のデータ、またはその逆 – EMR の S3 クライアントサイド暗号化
  • クラスター内のノード間で転送中のデータ – Secure Socket Layer (SSL) による MapReduce の in-transit 暗号化と、Simple Authentication と Security Layer (SASL) による Spark の shuffle 暗号化
  • ディスクに溢れたデータ、またはシャッフルフェーズの最中にキャッシュされたデータ – Spark の shuffle 暗号化、またはLUKS 暗号化

暗号化の手順

この投稿のために、転送中、保存時の暗号化に使うためのセキュリティ設定を作りましょう。

  • EMRやS3にあるデータに対して、LUKS 暗号化やS3 クライアントサイド暗号化のための KMS キー
  • MapReduce のshuffle 暗号化で使用する SSL 証明書
  • EMR クラスタが立ち上げられる環境。プライベートサブベットで EMR を立ち上げて、S3 からデータを取得するための VPC エンドポイントを設定します
  • EMR セキュリティ設定

この手順で説明するすべてのスクリプトとコードスニペットは、aws-blog-emrencryption Github レポジトリから取得できます。

KMS キーの生成

この手順では鍵管理について、データやディスクを暗号化するために使用する暗号化キーを、簡単に生成、管理できるマネージドサービスの、AWS KMS を使用します。

2つの KMS マスターキーを生成します。ひとつは EMR外のデータを暗号化する S3 クライアントサイド暗号化キーとして、もうひとつはローカルディスクを暗号化するための LUKS 暗号化のキーとして使用します。 Hadoop MapReduce フレームワークは HDFS を使用します。Spark は、ワークロードの中でメモリから溢れた中間データを一時的に保存する先として、各スレーブインスタンスのローカルファイルシステムを使用します。

鍵を生成するために、kms.json という AWS CloudFormation スクリプトを使用します。スクリプトの中で、キーの エイリアス名またはディスプレイ名を指定します。エイリアスは “alias/エイリアス名” 形式で、エイリアス名はアルファベット、アンダースコア、ダッシュのみで構成される必要があります。

o_Amazon_EMR_Encryption_2

キーの作成が終わったら、Outputs として ARN が表示されます。

o_Amazon_EMR_Encryption_3

SSL 証明書の作成

SSL 証明書によって、Mapreduce のシャッフル中にデータがノード間を転送されるときに、データの暗号化が行われます。

o_Amazon_EMR_Encryption_4

この手順では、OpenSSL で 2048-bit RSA 秘密鍵による X.509 自己署名証明書を作成します。これを使って EMR クラスタのインスタンスにアクセスします。画面に従って、証明書発行に必要な情報を入力します。

cert-create.sh を使って、zip ファイルに圧縮した SSL 証明書を生成します。zip 圧縮済みの証明書を S3 にアップロードし、S3 のプレフィックスをメモしておきます。セキュリティ設定を構成するときには、この S3 プレフィックスを使用します。

重要
この例は、あくまで proof-of-concept のデモにすぎません。自己署名証明書を使うことは推奨されませんし、潜在的なセキュリティリスクを孕みます。実運用システムでは、信頼できる認証局が発行した証明書を使ってください。

カスタムプロバイダの証明書には、TLSArtifacts プロバイダインタフェースを使用してください。

環境の構築

EMR クラスタをプライベートサブネットに構築します。もしすでに VPC があり、パブリックサブネットにクラスターを立てたい場合には、このセクションを飛ばして、セキュリティ設定の作成のセクションに進んでください。

クラスターをプライベートサブネット内に立てるためには、以下のリソースが必要です。

  • VPC
  • プライベートサブネット
  • パブリックサブネット
  • 踏み台サーバ
  • マネージド NAT ゲートウェイ
  • S3 VPC エンドポイント

EMR クラスターをプライベートサブネットに立てる際には、クラスターに SSH で入るための踏み台サーバかジャンプサーバが必要になります。クラスターの起動が終わったら、KMS からデータキーを取得するためにインターネットに接続する必要があります。プライベートサブネットからは直接インターネットに接続できないので、マネージド NAT ゲートウェイ経由でトラフィックの経路を制御します。S3 に対して、高信頼性を確保して安全に接続するために、S3 VPC エンドポイントを使用します。

o_Amazon_EMR_Encryption_5

CloudFormation コンソールで、environment.json テンプレートを使って、環境構築用の新しいスタックを作成します。

パラメタとして、踏み台サーバのインスタンスタイプと、そのサーバに SSH アクセスするための EC2 キーペアを入力します。適切なスタック名とタグを指定します。例えば、私の作成したスタックのレビューステップのスクリーンショットは、以下の通りになります。

o_Amazon_EMR_Encryption_6

スタックの作成が終わったら、Outputs タブを開いて VPC、踏み台サーバ、プライベートサブネットのIDをメモしておきます。これらはあとで EMR クラスタを立ち上げる際に使用します。

o_Amazon_EMR_Encryption_7

セキュリティ設定の作成

セキュアな EMR クラスタを立ち上げる前の最終ステップは、セキュリティ設定の構成です。EMR の S3 クライアントサイド暗号化と、先ほど作成した KMS キーを用いたローカルファイルの LUKS 暗号化について、セキュリティ設定を作成します。さらに MapReduce のシャッフルで暗号化を行うために、先ほど作成して S3 にアップロードしておいた SSL 証明書も使用します。

o_Amazon_EMR_Encryption_8

EMR クラスターの立ち上げ

さて、これでプライベートサブネットに EMR クラスタを立ち上げることができるようになりました。まずサービスロールとして、サービスポリシー内の AmazonElasticMapReduceRole が EMR に割り当てられていることを確認します。デフォルトのサービスロールは EMR_DefaultRole です。詳しくはIAMロールを使用したユーザーアクセス権限の設定を参照してください。

環境の設定セクションでメモしておいた VPC ID とサブネット ID の中で、EMR クラスタを立ち上げます。Network EC2 Subnet フィールドで、それらの値を選択してください。続いてクラスタの名前とタグを入力します。

o_Amazon_EMR_Encryption_9

最後のステップはプライベートキーの選択です。ここでは、セキュリティ設定の作成セクションで作っておいたセキュリティ設定を適用します。そして Create Cluster をクリックします。

o_Amazon_EMR_Encryption_10

これで作成した環境の上で、クラスタが立ち上がりました。続いてマスターノードに入ってスクリプトを実行します。EMR コンソールページからクラスタの IP アドレスを取得します。HardwareMaster Instance Group と選択して、マスターノードのプライベート IP アドレスをメモします。

o_Amazon_EMR_Encryption_11

マスターノードはプライベートサブネット内にあるので、まず踏み台サーバに SSH で入り、そこからさらにマスターノードに接続します。踏み台サーバと Hadoop マスタへの SSH については、ssh-commands.txt ファイルをみてください。踏み台サーバへのアクセスについてのさらなる詳細は、Securely Connect to Linux Instances Running in a Private Amazon VPC のエントリーを参照してください。

マスターノードに入った後は、Hive や Spark のスクリプトを実行します。動作確認用として、GitHub /code ディレクトリには PySpark の test.py と Hiveの test.q スクリプトが含まれています。

まとめ

この投稿の中で、データの暗号化が必要な複数のパターンについて述べ、各パターンでどうやって暗号化するかについての手順を説明しました。そして暗号化の前提要件である KMS キーの作成、SSL 証明書の発行、強力なセキュリティ設定による EMR クラスタの立ち上げについて、順を追って解説しました。そして VPC 内のプライベートサブネットでのクラスター起動によって、データをセキュアに
保つとともに、EMR クラスターにアクセスするために踏み台サーバを活用することができました。

もし疑問や助言があれば、ぜひおしらせください。

(翻訳はSA志村が担当しました。原文はこちら

新リリース:Amazon QuickSight Enterprise Edition

私がAmazon QuickSightについて初めて書いたのは2015年のことで(Amazon QuickSight 高速で簡単に利用できるビッグデータ用BI(Business Intelligence), 従来型ソリューションの1/10のコストで実現)、その際にStandard EditionとEnterprise Editionを用意することをお知らせしました。

Enterprise Edition
先月、私達はAmazon QuickSightのStandard Editionをリリースしました。本日、Enterprise Editionをリリースいたします。Standard Editionの機能に加え、Enterprise EditionにはActive Directoryとの統合と、データ暗号化(Encryption at Rest)が実装されています。

Enterprise EditionはAWSのマネージド・サービスとして提供しているMicrosoft Active Directory (AD)(Managed Microsoft AD)を使った認証をサポートします。これにより、AWS上で稼動しているMicrosoft ADやオンプレミスにある信頼関係をもったADを使ってQuickSightへのサインインできるようになります。どちらの方法であるにせよ、シングルサインオン(SSO)によって、ユーザがQuickSightを使い始めるのをよりクイックに、また管理を減らすことが可能になります。

あなたが企業でのQuickSight管理者であった場合、大量のユーザに対してQuickSightを一度に使えるようにしたり、パーミッションを数クリックで管理することが可能になります。これまで通りのディレクトリ操作のツールを使って管理できますし、企業のガバナンスポリシーに準拠させることも可能です。
以下の図は、どのように動作するのかを説明しています:

qs_ee_ad_setup_1

QuickSightはSPICE (Super-fast, Parallel, In-memory Calculation Engine) によって、分析用のアドホッククエリに対して高いスケーラビリティを実現しています。Enterprise Editonはデータをアマゾンによって管理されている鍵で暗号化してSPICE内に保存し、これによりさらなるデータ保護の層を追加しています。
Enterprise Editionを始動させましょう

管理者側の作業としては、Amazon QuickSight Enterprise Editionをセットアップするのはとても簡単です。作業には、必要とされるパーミッションを持つIAMでログインします。(ドキュメントの”Sign Up for Amazon QuickSight With an Existing AWS Account“を参照してください。”Set your IAM Policy“にIAM設定についての説明があります)

Enterprise Editionを選択し、あなたのユーザコミュニティを管理するAWSマネージドのADを選択して、ディレクトリへのアクセス権限を与えます。そしてディレクトリにエリアスを追加し、それをQuickSightのアカウント名として使用します。最後にマネージドAD、もしくは信頼されたフォレスト(Trusted forest)上にあるADグループを選択し、QuickSightアクセス用に有効化します。

qs_ee_create_account_1

サインアッププロセスが完了すると、設定したグループに所属するユーザはQuickSightのアカウント名(ディレクトリエリアス)とADのクリデンシャルでQuickSightにログインをすることが出来るようになります。

パスワードの制限、タイムアウト、ユーザ管理は、そのAD(AWSに上、もしくはオンプレミス)上で設定し、所属企業のポリシーに従うことが可能です。既存のツールを使ってグループのメンバーシップをマネージでき、必要に応じてユーザを追加・削除する管理タスクを実行することが可能になります。

費用、および利用可能リージョン

Amazon QuickSight Enterprise EditionのAD連携機能はUS East(北バージニア)リージョンでのみ利用可能です。Enterprise Editionのもう一つの機能であるデータの暗号化については、US East(北バージニア)、US West (オレゴン)、EU (アイルランド)で利用可能です 。費用は1ヶ月・1ユーザあたり$18からで利用でき、10GB分のSPICEキャパシティが含まれます。このSPICEキャパシティはアカウント内のユーザで共有されます(QuickSightの無料枠(Free tier)や、4ユーザまで利用できる60日間トライアルでも、SPICEストレージが共有されるという考え方は同様です)。詳細はQuickSightの価格ページを確認してください。

すでにUS East (北バージニア)リージョンでMicrosoft ADのインスタンスを利用されている場合、無料枠やフリートライアルを使って、追加コスト無しでEnterprise Editionを本日から利用いただくことが可能です。

原文:https://aws.amazon.com/jp/blogs/aws/new-amazon-quicksight-enterprise-edition/

翻訳:下佐粉 昭 (simosako@)

S3のデータをAmazon Athenaを使って分析する

Amazon Athenaは対話型クエリサービスで、標準的なSQLを使ってAmazon S3の直接データを直接分析することを簡単にしてくれます。Athenaはサーバレスなので、インフラを構築したり管理する必要はなく、今すぐにデータ分析を始めることができます。Athenaはデータをロードしたり、複雑なETL処理をする必要すらありません。S3に保存されているデータに直接クエリすることができます。

Athenaは、クエリを実行する際に分散SQLエンジンのPrestoを利用しています。また、テーブルを作成、削除、変更、パーティションするためにApache Hiveも利用しています。Hive互換のDDL文や、ANSI SQL文をAthenaクエリエディタ内で書くことができます。複雑なJOINやウィンドウ関数、そして複雑なデータ型をAthenaで使うこともできます。Athenaはschema-on-readとして知られるアプローチを取っていて、クエリを実行する時にデータに対してスキーマを定義することができます。これによって、データロードやETLを必要としていません。

Athenaはクエリ毎にスキャンしたデータの量に応じて課金します。データをパーティションしたり、圧縮したり、またはApache Parquet等の列指向フォーマットに変換することでコストを抑えパフォーマンスを向上させることができます。詳しくはAthenaの料金ページをご覧ください。

この記事では、既に決められた形式のテキストファイルで生成されるElastic Load Balancingのログに対して、どのようにAthenaを使うかをお見せします。テーブルを作成し、Athenaで使われる形式でデータをパーティションして、それをParquetに変換してから、クエリのパフォーマンスを比較してみます。

(more…)

Auto Scalingを利用して、Amazon EMRのアプリケーションを動的にスケールする

Apache SparkやPresto、Apache Hadoopエコシステムを利用しているお客様は、ワークフローの完了次第クラスターを終了させることや、安価なAmazon EC2スポットインスタンスを利用してクラスターをリサイズをすることよってコスト節約するために、Amazon EMRの弾力性を活用しています。例えば、お客様は日次のETLや機械学習処理のためにクラスターを作成し、それらの処理が完了したらクラスターを終了させるということや、BI分析者がアドホックでレイテンシーの低いSQLをAmazon S3に置かれたデータに対して行えるよう、業務時間帯のみPrestoクラスターをスケールアウトする、ということが可能です。

Amazon EMRリリース4.xと5.xで新しくサポートされたAuto Scalingによって、お客様は、クラスターのノードを、より簡単に追加(スケールアウト)や削除(スケールイン)できます。スケーリングの動作は、EMRから提供される5分間隔のAmazon CloudWatchメトリクスによって、自動的にトリガーされます。トリガーになるメトリクスには、メモリ利用、未実行アプリケーションの状態、HDFS利用、に関連するいくつかのYARNメトリクスも含まれます。

EMRリリース5.1.0には、2つの新しいメトリクスが導入されました。YARNMemoryAvailablePercentageとContainerPendingRatioです。これらは、Apache SparkやApache Tez、そして、Apache Hadoop MapReduceのような、スケーラブルなYARNベースのフレームワーク向けの、クラスターの利用状況を知るのに便利なメトリクスです。さらに、お客様は、カスタムCloudWatchメトリクスをAuto Scalingポリシーに利用することもできます。

以下は、最大40・最小10インスタンスで、一度に1インスタンスずつ増減する、インスタンスグループに対するAuto Scalingポリシーの例示です。インスタンスグループは、YARN内の利用可能なメモリが15%を下回ると、スケールアウトし、75%を上回るとスケールインします。また、インスタンスグループは、割り当てられているYARNコンテナに対するYARNコンテナの未実行率が0.75になった場合も、スケールアウトします。

さらに、お客様は、EMR 5.1.0のクラスターによってノードが終了される際に、スケールダウンの振る舞いを設定することができます。デフォルトで、EMRは、いかなるタイミングで終了リクエストが投げられたとしても、インスタンス時間単位の境目に実施されるスケールインイベントの最中のみ、ノードの停止を行います。これは、EC2は、いつインスタンスを終了したかに関わらず、時間単位で請求をするためです。この振る舞いによって、クラスター上で実行されているアプリケーションは、コスト効率をより高く、動的にスケールする環境で、インスタンスを利用することができます。

反対に、5.1.0より前のEMRリリースでは、お客様は、以前のデフォルト設定を利用できます。インスタンス時間単位の境目に近接しているかどうかを考慮せず、ノードを終了する前に、ノードをブラックリストしたり、タスクを排出したり、ということが可能です。いずれの振る舞いにおいても、EMRは、まず最も動きの少ないノードを削除しますし、HDFSの不整合を招き得る場合は、終了処理をブロックします。

EMRコンソール、AWS CLI、または、AWS SDKのEMR APIを利用して、Auto Scalingポリシーの作成や変更ができます。Auto Scalingを有効にするためには、Auto Scalingで容量の追加・削除を行うための権限を付与すべく、追加のIAMロールをEMRに与える必要があります。さらに詳細な情報は、Amazon EMRでのAuto Scalingを確認して下さい。また、もし、EMRでのAuto Scalingに関して、ご質問や公開したい面白い事例などございましたら、コメントを下に書いていただければと存じます。

原文: Dynamically Scale Applications on Amazon EMR with Auto Scaling (翻訳: 半場 光晴)

Amazon QuickSightが一般提供開始 – 高速で利用が簡単なビッグデータ用ビジネスアナリティクス

1,500以上のスタートアップからグローバルエンタープライズまでのAWSカスタマーが参加したプレビュー期間を経て、 Amazon QuickSightが一般提供開始(Generally Available:GA)になった事を発表いたします!去年、プレビューへのお誘いのブログエントリで、私は以下のように書きました:qs_net_tty_1

これまではビジネスインテリジェンス(Business Intelligence, BI)を実現するには対処方法が不明確で複雑な作業が大量に必要でした。インフラとソフトウェアをセットアップし、ユーザが不満に思わないようにシステムをスケールさせるために多くの費用が必要で、データからモデルを作成するために高給のコンサルタントを雇う必要がありました。システムが出来上がったあとは、ユーザは複雑なユーザインターフェースに不満を覚え、モバイルデバイスからデータを分析できるようにするリクエストを受けることになります。さらにNoSQLやストリーミングデータも含めて分析したいですって?幸運を祈ります!

Amazon QuickSightは、高速で使いやすくクラウドの力で構築されたビジネスアナリティクスをトラディショナルなオンプレミスBIシステムと比較して1/10のコストで提供します。QuickSightは数分で利用開始することが可能です。ログインし、データソースを指定すればデータを可視化(Visualize)できるようになります。その背後でSPICE(Super-fast, Parallel, In-Memory Calculation Engine)があなたのクエリを高速に処理し、結果を美しく可視化します。

データにディープダイブする

私が会話したお客様はみな、保存したデータからより多くの価値を得たいを考えておられました。彼らは価値を生む可能性がデータの中に埋もれており、そのデータが日々増えているということを理解していました。しかし、データから価値を取り出すことはとても高くつき、難易度が高いということを学習し、しばしば落胆していました。オンプレミスのビジネスアナリティクスツールは高価なライセンスが必要であり、既存のインフラに大きい負荷を追加する必要がありました。このライセンスコストと高い難易度は、ツールを利用できる人間をごく一部に制限してしまっていました。これらの要因が合わさることにより、多くの組織は自分たちが本当にビジネスアナリティクスの機能に投資をできる状態には無いと結論付けてしまっていました。

QuickSightはこういった状態を変えます!サービスとして実行され、全てのタイプ・全てのサイズの組織にビジネスアナリティクスをもたらします。高速で使うのが簡単であり、既存のインフラに負荷を追加することなく、わずか1ユーザあたり1ヶ月$9からという費用で利用を開始することが可能です。

使い始めるとすぐに分かるように、QuickSightは異なる場所に格納された多種多様なサービスのデータにアクセスすることが可能です。Amazon Redshiftデータウェアハウスや、Amazon Relational Database Service (RDS) 、S3上に置かれたフラットファイルからデータを取得することが可能です。オンプレミス上のMySQL、PostgreSQL、SQL Server、もしくはMicrosoft ExcelのスプレッドシートやSalesforce等の外部サービスにもデータコネクターを使うことでアクセスが可能です。

QuickSightはお客様の利用に合わせてスケールします。ユーザやデータソースを追加したり、新たなデータを追加した場合でもDC上でハードウェアを増強したり、長期契約のライセンスを追加購入する必要はありません。

ツアーに出かけましょう

QuickSightをめぐるツアーに出かけましょう。組織の管理者が、すでに私をQuickSightに招待(Invite)してくれています。これでもうログインしてスタート出来る状態にすでになっています。こちらがメインスクリーンです:

qs_main_screen_turn_on_how_are_you_gentlemen_1

Redshiftクラスターからデータを取得するところから始めたいと思います。Manage dataをクリックして、存在するデータセットを確認します:

qs_all_my_data_are_belong_to_me_1

欲しいものが無いようですので、New data setを押して別の方法をとることにします:

qs_data_sources_to_the_edge_3

Redshift(Manual connect)をクリックし、認証情報を入力します。これでデータウェアハウスにアクセスできるようになりました(もし私が自分のAWSアカウント内にRedshiftクラスターを稼動させている場合は、自動ディスカバリによりデータソースとして最初から現れているでしょう):

qs_new_data_source_dude_2

QuickSightはデータウェアハウスをクエリし、スキーマ(テーブルのセット)の一覧と、存在するテーブル一覧を見せてくれます。publicというスキーマを選択し、all_flightsテーブルから始めることにします:

qs_pick_a_table_1

ここで2つの選択肢があります。テーブルをSPICEにインポートしてアナリティクスの速度を上げる方法、もしくはクエリをウェアハウスで直接実行する方法です。ここではSPICEにデータをインポートします:

qs_import_spice_dune_1

もう一度2つの選択肢があります!Edit/Preview dataを選択してどの行や列をインポートするかを選択するか、もしくはVisualizeをクリックして全データをインポートし、楽しいパートをすぐに開始するかです!ここではEdit/Previewを選択しましょう。左側にフィールド(Fields)が確認でき、ここから必要な列だけにチェックボックスを付けて選択することができます:

qs_data_see_me_3

New Filterを選択してポップアップメニューからフィールドを選択し、フィルター(絞り込み条件)を作成することもできます:

qs_edit_my_filter_baby_1

それぞれの選択肢(フィールドを選択、列を選択)によりSPICEにインポートするデータをコントロールすることが可能です。つまり可視化したいデータを自分でコントロールすることができ、メモリをより効率的に利用することを可能にします。準備が完了したら、Prepare data & visualizeをクリックします。この時点でSPICEにデータがインポートされ、そのデータを使った可視化が可能になります。ここではシンプルにフィールドを選択して開始します。例えばorigin_state_abbrフィールドを選択して、それぞれの州を出発点としたフライトがどれぐらいあるのかを確認します:

qs_air_by_state_1

右側の縮小ビュー(右側の縦長いスクロールバー)を使うと追加の情報を得られます。スクロールアップ・ダウンして表示するレンジを調整することが可能です。データからもっと知見を得るためめに上部の2つ目のフィールドをクリックします。flightsをクリックし、ソート順をdescending(大きい順)とし、スクロールバーで一番上までスクロールします。これにより、それぞれの州からどれぐらいのフライトがあるかを自分のデータから取得し、確認することができます:

qs_air_by_state_and_flights_1

QuickSightのAutoGraph(オートグラフ)は、選択したデータをもとに自動的に適切なビジュアルを使用します。例えば、fl_data_fieldを追加すると、州ごとの折れ線グラフが表示されます:

qs_origin_flight_date_line_1

また、クエリやデータ型、もしくはデータの特質に応じてQuickSightは他の表現方法を提案します:

qs_try_this_instead_2

縦&横棒グラフ、折れ線グラフ、ピボットテーブル、ツリーマップ、パイチャート、ヒートマップなど多くの他のビジュアルから自分で選択することも可能です:

qs_pick_a_vis_1

効果的なビジュアルを作成した後は、それらをキャプチャし、ストーリーボードに結果をまとめることによって、データドリブンのストーリーを伝えることが可能になります:

qs_story_1

これらビジュアルを同僚と共有することも可能です:

qs_share_the_love_1

最後に、作成したビジュアルにモバイルデバイスからアクセスしてみましょう:

qs_ip_image1_1   qs_ip_image2_1b

価格とSPICEキャパシティ

QuickSightは1ユーザかつ1GBのSPICEのキャパシティを無料で永続的に利用することが可能です。これによりAWSユーザは追加コスト無しでビジネスインサイトを得ることが可能になります。Amazon QuickSightのStandard Editionは$9/月で開始することができ、それには10GBのSPICEキャパシティが含まれています(詳細はプライスのページをご覧ください)。

SPICEキャパシティの管理は簡単です。メニューからManage QuickSightを選択し(変更にはQuickSightのADMIN権限が必要です):

qs_manage_menu_1

すると現在の状況を確認できます:

qs_yum_pumpkin_spice_1

Purchase more capacity をクリックしてキャパシティを追加購入することが出来ますし、:

qs_more_spice_please_1

Release unused purchased capacityをクリックすることで使用していない分のSPICEキャパシティを削減することが可能です:

qs_take_my_spice_please_1

今日から使い始めましょう

Amazon QuickSightは、US East (Northern Virginia)、US West (Oregon)、 EU (Ireland)リージョンで提供されており、今日から使い始めることが可能です。

このブログポストの長さにも関わらず、まだQuickSightの表面を少しなぞって紹介しただけにすぎません。みなさんはすでに無料でQuickSightを利用開始できますので、ぜひサインアップしていただき、ご自身のデータをロードし、QuickSightを分析に活用してください!

— Jeff

翻訳:下佐粉 昭 (simosako@)

※日本語版補足) Amazon QuickSightのオンラインセミナーが12月14日(水)18時~19時で開催予定です。Webブラウザがあればどこからでもご覧いただける無料のセミナーです。

以下よりお申込みください。

https://connect.awswebcasts.com/qs-webinar-20161214/event/event_info.html

https://aws.amazon.com/jp/about-aws/events/webinars/

さあ、Amazon EMRで、Apache Flinkを使って、大規模なリアルタイムストリーム処理を実行しよう

Amazon EMR リリース5.1.0

Amazon EMRリリース5.1.0で、Apache Flink 1.1.3と、バージョンアップしたApache Zeppelin(0.6.2)Apache HBase(1.2.3)が利用できるようになりました。また、Hueのinteractive notebookが、Prestoを用いたクエリをサポートしました。

Apache Flinkは、高スループットのデータソースに対して、簡単にリアルタイムストリーム処理を実行できる、ストリーミングデータフローエンジンです。順不同なイベントに対するイベントタイムセマンティクスや、exactly-onceセマンティクス、バックプレッシャー制御、そして、ストリーミングバッチ処理どちらにも最適化されたAPIを兼ね備えています。さらに、Flinkは、Amazon Kinesis StreamsApache KafkaElasticsearchTwitter Streaming API、それから、Cassandraへのコネクターを持っており、さらに、Amazon S3(EMRFS経由)やHDFSにアクセスすることもできます。

AWSマネージメントコンソール、AWS CLI、または、SDKから、リリースラベル「emr-5.1.0」を選択して、リリース5.1.0のAmazon EMRクラスターを作成することができます。Flink、Zeppelin、それから、HBaseを指定して、これらのアプリケーションをクラスターにインストールすることができます。リリース5.1.0や、Flink 1.1.3Zeppelin 0.6.2HBase 1.2.3についての、より詳細な情報については、Amazon EMRのドキュメントをぜひご確認下さい。(原文)

Amazon EMRでApache Flinkを利用する

Apache Flinkは、お客様の間でリアルタイムビッグデータアプリケーションを構築するために使われている、並列データ処理エンジンです。Flinkによって、例えばAmazon Kinesis StreamsApache Cassandraデータベースのような、たくさんの異なるデータソースを変換することができるようになります。バッチとストリーミングどちらのAPIも提供しています。また、Flinkは、これらのストリームやバッチデータセットに対するSQLも、多少サポートしています。多くのFlinkのAPIのアクションは、Apache HadoopやApache Sparkにおける分散オブジェクトコレクションの変換と、非常に類似しています。FlinkのAPIは、DataSetとDataStreamに分類されます。DataSetは、分散データのセットやコレクションの変換ですが、一方で、DataStreamは、Amazon Kinesisに見られるようなストリーミングデータの変換です。

Flinkは、純粋なデータストリーミング実行エンジンです。リアルタイムに以前のデータ変換結果を操作するためのパイプライン並列処理を有しています。つまり、複数の操作を並行して実行できます。Flinkのランタイムは、これらの変換パイプライン間のデータの交換をハンドリングします。また、例えバッチ処理を記述したとしても、同一のFlinkストリーミングデータフローランタイムが、その処理を実行します。

Flinkのランタイムは、2つの異なるタイプのデーモンで構成されています。スケジューリング、チェックポイント、リカバリーといった機能をまとめる責任を担うJobManagerと、アプリケーション内のストリーム間のデータ転送やタスクの実行を担うワーカープロセスであるTaskManagerです。それぞれのアプリケーションは、ひとつのJobManagerと、ひとつ以上のTaskManagerを持ちます。

TaskManagerの数をスケールさせることができますが、同時に「タスクスロット」と呼ばれるものを使って、並列処理をさらに制御しなければなりません。Flink-on-YARNでは、JobManagerは、YARNのApplicationMasterに内包されます。一方で、個々のTaskManagerは、そのアプリケーションのために割り当てられた別々のYARNコンテナに配置されます。

本日(11/3)、Amazon EMRリリース5.1.0でネイティブサポートしたことにより、AWS上でFlinkを実行することが、さらに簡単になりました。EMRがFlink-on-YARNの実行をサポートしたことにより、複数のジョブを受け付けるロングランニングクラスターを作成することも、利用中の料金のみにコストを抑えるために一時的なクラスターでショートランニングのFlinkセッションを作成することも、どちらも可能です。

ロギングや設定パラメータ用の設定分類を、EMRの設定APIを使って、Flinkがインストールされたクラスターに設定することもできます。

直接EMRコンソールから、もしくは、以下のようにCLIを実行すれば、今日からEMRでFlinkの利用を開始できます。

aws emr create-cluster --release-label emr-5.1.0 \
 --applications Name=Flink \
 --region us-east-1 \
 --log-uri s3://myLogUri \
 --instance-type m3.xlarge \
 --instance-count 1 \
 --service-role EMR_DefaultRole \
 --ec2-attributes KeyName=YourKeyName,InstanceProfile=EMR_EC2_DefaultRole

Apache Flinkについてもっと知りたいという方は、Apache Flinkのドキュメントをご確認下さい。そして、EMRでのFlinkについてもっと知りたいという方は、ぜひAmazon EMRリリースガイドのFlinkトピックをご確認下さい。(原文)

翻訳: 半場 光晴

Amazon EMR に保存データと転送中データの暗号化オプションを追加

AWS をご利用のお客様は Amazon EMR (Apache HadoopApache Spark エコシステムを形成する全範囲のツールを含む) を使用して様々なタイプのミッションクリティカルなビッグデータのユースケースを処理しています。以下の例をご覧ください。

  • Yelp 毎日テラバイト以上のログファイルと写真を処理
  • Expedia クリックストリーム、ユーザー操作、データ提供を処理
  • FINRA 毎日数十億件の証券取引の記録を分析
  • DataXu 毎月 30 兆件の広告チャンスを判断

こうしたお客様 (詳しくはその他のビッグデータのユースケースを参照) は、多くの場合ミッションクリティカルであり安全に保護する必要がある重要なデータを処理しています。

AWS では、EMRFS を使用する Amazon S3 や HDFS の透過的なデータ暗号化など、EMR 用のデータ暗号化オプションを複数ご提供しています。こうしたソリューションは保存データを保護する場合には優れていますが、一時ファイルに保存しているデータやジョブステップの間にあるデータには対処していません。暗号化オプションはそれぞれ有効にしてから設定する必要があるため、暗号化の実装を必要以上に面倒なものにしていました。

ただし、それはもう過去のこと。

新しい暗号化のサポート
本日、AWS は EMR の新しい包括的な暗号化ソリューションをリリースしました。今後は EMR で使用する Apache Spark、Apache Tez、Hadoop MapReduce で保存データや転送中データを簡単に暗号化することができます。

保存データの暗号化は次のストレージタイプに対処しています。

  • EMRFS 経由で S3 に保存したデータ
  • 各ノードのローカルファイルシステムで保存したデータ
  • HDFS を使用してクラスターに保存したデータ

転送中データの暗号化は次のフレームワークでネイティブなオープンソースの暗号化機能を利用します。

  • Apache Spark
  • Apache Tez
  • Apache Hadoop MapReduce

この新機能は Amazon EMR セキュリティ設定を使用して設定することができます。EMR コンソールEMR CLI、または EMR API 経由で設定を作成できます。
EMR コンソールに一連のセキュリティ設定が追加されました。

新しく作成するには [Create] をクリックします。

名前を入力してから新機能に指定するモードと各アスペクトを入力します。モードやタイプに基づき、コンソールが追加情報の入力をリクエストします。
S3 暗号化:

ローカルディスクの暗号化:

転送中データの暗号化

証明書プロバイダーのタイプを PEM にした場合は、暗号化に使用したい PEM ファイルを含む Zip ファイルの S3 内の保存先を入力してください。カスタムを選択した場合は、JAR ファイルの S3 内の保存先とカスタム証明書プロバイダーのクラス名を入力してください。

希望通りに設定したら [Create] をクリックします。セキュリティ設定がコンソールに表示されます。

この操作を完了後、新しく EMR クラスターを作成する際に設定を特定できるようになります。この機能は Amazon EMR リリース 4.8.0 または 5.0.0 を使用しているクラスターでご利用いただけます。詳しくは「セキュリティ設定を使用した Amazon EMR の暗号化」をご覧ください。

Jeff;

新発表 – Redshift や QuickSight で AWS のコストや使用状況レポートのアップロードが可能に

以前より、AWS の多くのお客様からプログラムを使用してコストや使用状況レポートを分析する方法をリクエスト頂いていました (詳しくは New – AWS Cost and Usage Reports for Comprehensive and Customizable Reporting をご覧ください)。リクエストをお寄せくださったお客様は、いくつものリージョンにわたり AWS を使用して複数のビジネスを行い、幅広く様々なサービスをご利用されている傾向があります。AWS では請求レポートやコストに関する詳細情報をご提供しているため、これはビッグデータに関与する問題であり、AWS サービスを使用すれば簡単に解決することができます。今月初旬に私が休暇を取っていた間に、AWS はコストや使用状況レポートを Amazon RedshiftAmazon QuickSight にアップロードできる新機能をリリースしました。今回はその新機能についてご説明します。

Redshift にアップロード
まず、新しい Redshift クラスターを作成してみました (すでに実行しているクラスターがある場合は新たに作成する必要はありません)。私が作成したクラスターは次の通りです。

次に請求レポート機能が有効になっていることを確認しました。

そしてコストと請求レポートに行き、Create report をクリックしました。

次にレポート名を指定 (MyReportRedshift) し、時間制に設定してから Redshift と QuickSight 両方のサポートを有効にしました。

最後に配信オプションを選択しました。

次のページでレポートを作成することを確認し、Review and Complete をクリックしました。レポートが作成され、最初のレポートは 24 時間以内にバケットに届くという通知が届きました。

待機している間に PostgreSQL を EC2 インスタンス (sudo yum install postgresql94) にインストールし、 Amazon QuickSight プレビューで登録済みであることを確認しました。また、Create an IAM Role の指示に従って、読み取り専用の IAM ロールを作成しその ARN もキャプチャしました。

Redshift コンソールでは、Manage IAM Roles をクリックし ARN を自分の Redshift クラスターと関連付けました。

翌日、予定通りにバケットにファイルが到着したことを確認してから、Redshift にアクセスできるようにヘルパーファイルを取得するためコンソールにアクセスしました。

Redshift ファイルをクリックし、SQL コマンドをコピーしました。

ARN と S3 リージョン名を SQL に挿入しました(予想通りにクエリが作動するようにするため、リージョン名に引用符を使用する必要がありました)。

次に psql を使用して Redshift に接続しました (任意のビジュアルまたは CLI ベースの SQL クライアントの使用が可能)。

$ psql -h jbcluster.XYZ.us-east-1.redshift.amazonaws.com \
  -U root -p 5439 -d dev

SQL コマンドを実行しました。これで 1 組のテーブルが作成され、S3 から請求データをインポートしました。

Redshift でのデータのクエリ
手始めに同僚が提供してくれたいくつかのクエリを使用して、今月の S3 使用量を計算してみました。

AZ ベースのコストを見てみました。

次に AZ ごと、サービス別に見てみました。

試しに Redshift コンソールも少し調べてみました。すると、私のクエリをすべて見ることができました。

QuickSight のデータ分析
Amazon QuickSight を使ってコストや請求データも分析してみました。ログインしてから Connect to another data source or upload a file をクリックしました。

次に S3 バケットにアクセスし (jbarr-bcm) マニフェストファイルの URL をキャプチャ (MyReportRedshift-RedshiftManifest.json) しました。

データソースとして S3 を選択し URL を入力しました。

QuickSight は数秒内でデータをインポートし、新しいデータソースが利用可能になりました。SPICE (QuickSight のインメモリ計算エンジン) にロードしました。3 回から 4 回のクリックで AZ には関係のないデータを除外し AZ 特有のデータだけに集中することができました。

もう一度クリックして円グラフの表示に切り替えました。

サービス別のコストも調べてみました。

ご覧のように、新しいデータと QuickSight の解析能力により、数分で AWS のコスト詳細を確認することができました。

今すぐ利用可能
この機能は今すぐ使い始めることができます。

Jeff;

Amazon Kinesis Analytics - SQL を使用してリアルタイムにストリーミングデータを処理

ご存知の通り、Amazon Kinesis では、AWS Cloud でリアルタイムにストリーミングデータを操作するプロセスが大幅に簡素化されています。独自のプロセスおよび短期のストレージインフラストラクチャを設定および実行する代わりに、ただ Kinesis ストリームまたは Kinesis Firehose を作成し、そこにデータを流し込むように設定してから、それを処理または分析するアプリケーションを構築するのみです。Kinesis ストリームと Kinesis Firehose を使用してストリーミングデータソリューションを構築するのは比較的簡単なのですが、さらに簡素化したいと考えました。作業開発者、データサイエンティスト、または SQL 開発者であるかどうかにかかわらず、お客様がウェブアプリケーション、テレメトリ、およびセンサーレポートの大量のクリックストリームを、接続されたデバイス、サーバーログなどからすべてリアルタイムに標準クエリ言語を使用して処理できるようにしたいと考えました。

Amazon Kinesis Analytics
本日より、Amazon Kinesis Analytics がご利用いただけるようになりました。ストリーミングデータに対して SQL クエリを継続的に実行し、データが届くと同時にフィルタリング、変換、および集約できるようになりました。インフラストラクチャで時間を無駄にするのではなく、データの処理とそこからのビジネス価値の抽出に注力できます。強力なエンドツーエンドのストリームプロセスパイプラインを 5 分で構築できます。SQL クエリより複雑なものを作成する必要はありません。
データベーステーブルに対する一連の SQL クエリの実行を考慮する場合、クエリは通常、非常に素早く追加および削除されるのに対して、データはほぼ静的なままです。常に行が追加、変更および削除されますが、これは特定の時点で実行する単一のクエリを考慮する際、一般的には関係ありません。Kinesis Analytics のクエリをストリーミングデータに対して実行すると、このモデルと正反対のことが生じます。クエリは長時間実行され、新しいレコード、監視、またはログエントリが届くと同時に、データは毎秒何度も変化します。一度この仕組みを把握すると、クエリプロセスモデルが非常に理解しやすいことが分かります。レコードが届くと同時に処理する、持続的なクエリを構築するのです。所定のクエリで処理されるレコードのセットを制御するには、プロセス「ウィンドウ」を使用します。Kinesis Analytics では、3 つの異なるタイプのウィンドウがサポートされています。

タンブリングウィンドウは定期的なレポートに使用されます。タンブリングウィンドウを使用して、時間の経過と共にデータをまとめることができます。おそらく毎秒数千~数百万ものリクエストを受信するので、1 分ごとの受信数を知りたいと思うでしょう。現在のタンブリングウィンドウが閉じると、その後に次のウィンドウが開始します。ウィンドウがいっぱいになるたびに、新しい結果が生成されます。

スライディングウィンドウは、モニタリングとその他のタイプのトレンド検出に使用されます。例えば、スライディングウィンドウを使用してリアルタイムで動くエラー率の平均をコンピューティングできます。レコードがウィンドウに入り、レコードがその中にあるかぎり結果に反映され、ウィンドウは進行します。新しいレコードがウィンドウに入るたびに、新しい結果が生成されます。ウィンドウのサイズを調整して、結果の精度を制御できます。

カスタムウィンドウは、適切なグループが厳密に時間に基づいていない場合に使用されます。クリックストリームデータまたはサーバーログを処理している場合、カスタムウィンドウを使用してセッション化として知られるアクションを実行できます。つまり、各ユーザーが実行する最初と最後のアクション (受信データ内のセッション ID により識別される) によって、各クエリをバインドできます。各ユーザーが閲覧したページ数またはサイトで費やした時間をコンピューティングするクエリを作成できます。

これらすべてはいくらか複雑に聞こえるかもしれませんが、実装するのは非常に簡単です。Kinesis Analytics では、受信レコードのサンプルを分析し、最適なスキーマを提案します。それをそのまま使用することも、微調整して実際のデータモデルをさらに反映することもできます。スキーマが定義されると、組み込み SQL エディターを使用できます (ライブデータに対する構文チェックと簡単なテストを含む)。クエリの結果を Amazon S3Amazon RedshiftAmazon Elasticsearch Service、または Amazon Kinesis Stream を含む最大 4 つの送信先にルーティングするように、Kinesis Analytics を設定できます。初めての Amazon Kinesis Analytics アプリケーションを構築する場合、SQL ステートメントのペアを作成する必要があります (より複雑なアプリケーションには多くを使用する場合がありますが、必要なのは起動と実行の 2 つのみです)。

これは、中間 SQL 結果を保存するアプリケーション内のストリームを作成するためのステートメントです (ストリームは、選択および挿入でき、継続的にアップデートされる SQL テーブルのようなものです)。

1 つのアプリケーション内のストリームから SQL クエリを選択し、別のアプリケーション内のストリームに挿入します。

また、S3 を送信元とするデータを参照するよう、SQL ステートメントもレコードに追加できます。これはレコードを強化または変更し、追加のさらに詳細な情報を含める時に役立ちます。

動作中の Amazon Kinesis Analytics
動作中の Amazon Kinesis Analytics を数分見てみましょう。
Amazon Kinesis Analytics コンソールにログインし、Create new application をクリックします。名前とアプリケーションの説明を記入します。

データソース、クエリ、および送信先を管理できるようになりました。

既存の入力ストリームの 1 つを選択できます。

または、新しいストリームを設定できます (こちらを実行します)。

Create demo stream をクリックし、サンプルの株式相場表示機のデータが入力されるストリームを作成します。これには 30~40 秒かかります。Kinesis Analytics はストリームを参照し、スキーマを提案します。それをそのまま承認することも、微調整することもできます。

それから SQL エディターに移動します。アプリケーションの起動を提案しています。良いアイデアだと思うので、同意して Yes をクリックし、アプリケーションを起動します。

これが実際の SQL エディターです。

クエリをゼロから作成することも、テンプレートを使用することもできます。

継続的なフィルターを選びました。これが SQL です。

確認し、アグリーメントを承認し、Save and run SQL をクリックしました。数秒以内に結果が流れ始め、コンソールに表示されました。

SQL エディターを使用して、部門料金列を削除するようクエリを変更し、クエリを再度実行しました。この作業を行ってみて、CREATE STREAM ステートメントから列を削除する必要があることを学びました (振り返ってみると明白なのですが、これは長い 1 日の最後の作業でした)。こちらが修正した結果セットです。

ほとんどの場合、次のステップでは結果を新規または既存のストリームにルーティングすることになるでしょう。これはコンソールから実行できます。

数回のクリックとほんの少しの入力のみで、本番環境規模の株式相場表示機のストリームを処理できる Amazon Kinesis Analytics アプリケーションを作成できました。本番環境で使用される前に、この「デモ」には何の変更も必要ありません。素晴らしいです。

詳細 & お試し
いつものように、このすばらしい新サービスについては、やっと分かり始めたばかりです。詳細については、新しい投稿をご覧ください。Writing SQL on Streaming Data with Amazon Kinesis Analytics上記のステップは 5 分またはそれ以下で再現できるはずです。ぜひお試しされるようにお勧めします。アプリケーションを作成し、SQL クエリをカスタマイズし、大規模なストリーミングデータの処理方法を学んでください。

今すぐご利用可能
今すぐ Amazon Kinesis Analytics をご利用いただけます。今日からストリーミングデータに対してクエリの実行を開始できます。

Jeff

Amazon EMR 5.0.0 – メジャーアプリアップデート、UI改善、デバッグ改善、その他

Amazon EMRチームは新しいリリースをものすごい勢いでリリースし続けています。今年のローンチを振り返ってみましょう:

  • EMR 4.7.0 – Apache Tez, Apache Phoenix, Presto, HBase, Mahout (6月)
  • EMR 4.6.0 – 巨大データへのリアルタイムアクセス用に、HBase (4月)
  • EMR 4.5.0 – Hadoop, Presto, SparkとEMRFS追加 (4月)
  • EMR 4.4.0 – Sqoop, HCatalog, Java 8, 他 (3月)
  • EMR 4.3.0 – Spark, Presto, Ganglia (1月)

今日、チームからEMR 5.0.0が発表されました。こちらはメジャーリリースとなり、16のオープンソースのHadoopエコシステムプロジェクトをサポートしています。SparkとHiveのメジャーバージョンアップ、TezがHiveとPigのデフォルトに、HueとZeppelinのUI改善、そしてデバッグ機能の改良が含まれています。

こちらは過去の幾つかのリリースでEMRがどの様に進化してきたかの図になります。

それではEMR 5.0.0の新しい機能をチェックしてみましょう!

16のオープンソースHadoopエコシステムプロジェクトのサポート

EMR 4.0.0の開発からEMRのビルドとパッケージング処理を管理するために、Apache Bigtopを使い始めました。最新のGA (一般利用可能)なオープンソースのバージョンを出来る限り早くアクセス可能にするというゴールのために、Hadoopエコシステムから新しいパッケージを追加し続けながらもリリースサイクルを加速することができたのはBigtopのおかげです。

そのゴールのもとに、EMR 5.0は16のHadoopエコシステムプロジェクトをサポートしていて、その中にはApache Hadoop, Apache Spark, Presto, Apache Hive, Apache HBase, そしてApache Tezが含まれます。EMRクラスタ作成時に、必要なアプリを選択することができます。

SparkとHiveのメジャーバージョンアップグレード

今回のEMRのリリースより、Hive (TezやHadoop MapReduceのSQL風インタフェース)が1.0から2.1にアップデートされ、同時にJava 8に移行しました。また、Spark (巨大データ処理エンジン)も1.6.2から2.0へアップデートされ、同時にScala 2.11に移行しました。SparkとHiveのアップデートは共にメジャーリリースで、新しい機能、パフォーマンス改善、そしてバグ修正が含まれています。例えば、SparkではStructured Streaming APIの追加、SQLサポートの改良等が含まれています。ただし、新しいバージョンのSparkとHiveは100%の後方互換を持っていません。なので、お使いのコードでの動作を確認しながらEMR 5.0.0への更新を行って下さい。

今回のリリースから、Hive 2.1とPig 0.16ではHadoop MapReduceに代わりTezがデフォルトエンジンになり、パフォーマンスが改善され、クエリのレイテンシが削減されています。このアップデートにより、MapReduceはHadoop MapReduceジョブが直接実行された時のみ使われることになりました。(HiveとPigはTezを使いますし、Sparkは独自のフレームワークを持っています)

UI改善

またEMR 5.0.0では、Apache Zeppelin (対話的データ分析のためのノートブック)を0.5.6から0.6.1に、Hue (Hadoopのデータを分析するためのインタフェース)を3.7.1から3.10にアップデートしました。これらウェブベースのツールの新しいバージョンでは、新しい機能や多数の細かい改善が含まれています。

ZeppelinはSparkとよく一緒に使われ、HueはHive, Pig, HBaseと協調します。新しいバージョンのHueはノートブックの機能が追加され、複数のクエリを1つの同じページから実行することができるようになりました。

HueはOozieのワークフローのデザインもできます:

デバッグ機能の改善

最後に、EMR 5.0.0はデバッグ機能の改善も含まれていて、特定のEMRジョブのステップがなぜ失敗したのかを簡単に調べることができます。コンソールにはスタックトレースの一部とログファイル(Amazon S3に保存)へのリンクが表示され、簡単に調べてトラブルシュートしてエラーを修正することができます。

今日からクラスタが起動できます

EMR 5.0.0は今日から全てのAWSリージョンで起動することができます!EMRコンソールを開き、クラスタの作成をクリックし、リリースメニューからemr-5.0.0を選ぶだけです。

詳細な情報はこちら

この強力な新しいEMRのリリースをもっと詳しく知りたい場合には、8月23日のウェビナー Introducing Amazon EMR Release 5.0: Faster, Easier, Hadoop, Spark, and Prestoへの参加もご検討下さい。

Jeff;

原文: Amazon EMR 5.0.0 – Major App Updates, UI Improvements, Better Debugging, and More (翻訳: SA岩永)