Category: Amazon EMR

分析されるデータは、異なるアカウントが所有するバケットに分散されることがあります。データのセキュリティを確保するためには、適切な認証情報管理が必要です。これは、さまざまな部門の異なるAmazon S3バケットにデータを格納している大企業にとって特に当てはまります。例えば、顧客サービス部門は、研究部門が所有するデータにアクセスする必要があるかもしれませんが、研究部門はそのアクセスを安全な方法で提供する必要があります。 データを保護するこの側面は非常に複雑になる可能性があります。 Amazon EMRは、統合メカニズムを使用して、S3に格納されたデータにアクセスするためのユーザー認証情報を提供します。 EMR上でアプリケーション（Hive、Sparkなど）を使用してS3バケットとの間でファイルを読み書きする場合、S3 API呼び出しには認証するための適切な認証情報で署名する必要があります。 通常、これらの認証情報は、クラスターの起動時に指定するEC2インスタンスプロファイルによって提供されます。そのオブジェクトが異なる認証情報セットを必要とするため、EC2インスタンスプロファイルの認証情報がS3オブジェクトにアクセスするのに十分でない場合はどうなるでしょうか？ このポストは、カスタム認証プロバイダを使用して、EMRFSのデフォルトの認証プロバイダがアクセスできないS3オブジェクトにアクセスする方法を示しています。

今日は、インスタンスフリートと呼ばれる クラスターの新機能をご紹介します。インスタンスフリートは、インスタンスのプロビジョニングに広範囲な選択肢やインテリジェンスをもたらします。対応する加重容量やスポット入札価格 (スポットブロックを含む) を最大 5 つのインスタンスタイプのリストに追加できるようになりました。EMR は、クラスター作成時にこれらのインスタンスタイプの間でオンデマンドおよびスポット容量を自動的にプロビジョニングします。そのため、これまでよりも簡単かつ低コストに、希望のクラスター容量をすばやく取得して管理することができます。また、アベイラビリティーゾーンのリストを指定することもでき、EMR は、このうちのいずれかの AZ で最適にクラスターを起動します。また、EMR は、インスタンスをフリートの利用可能ないずれかのタイプに置換することで、スポットインスタンスの中断に備えてクラスターの再分散を続けます。その結果、クラスター容量全体を容易に管理できます。インスタンスフリートは、インスタンスグループの代わりに使用することもできます。グループと同様、クラスターには、マスター、コア、タスクフリートが作成されます。コンソールのアップデートを確認し、フリートの動作について詳しく調べてみましょう。EMR コンソールを開き、[クラスターの作成] ボタンをクリックします。なじみのある EMR プロビジョニングコンソールが表示されたら、左上隅付近にある詳細オプションに移動します。最新の EMR バージョン (インスタンスフリートは、5.0.x を除く 4.8.0 以上の EMR バージョンで使用可能) を選択し、[次へ] をクリックします。これで正常に表示されます。ハードウェアオプションの新しい [インスタンスフリート] を選択します。 ここで、コアグループを変更して、クラスターのニーズを満たす一組のインスタンスタイプを選択します。 EMR は、最もコスト効率の高い方法で要件を満たせるように、各インスタンスフリートとアベイラビリティーゾーンの容量をプロビジョニングします。EMR コンソールでは、インスタンスタイプごとに vCPU を加重容量と簡単にマッピングできるため、vCPU を容量ユニットとして使用しやすくなります (コアフリートに合計 16 個の vCPU が必要)。vCPU ユニットが、インスタンスタイプの分量指定に関する条件に一致しない場合は、[Target capacity] セレクタを変更して、任意のユニットを追加し、容量を定義します (API/CLI によるキャパシティーユニットの消費量も変更されます)。クラスターがプロビジョニングされており、ユーザー定義のタイムアウト内に希望のスポット容量を入手できない場合は、オンデマンドインスタンスを終了またはフォールバックして、残りのキャパシティーをプロビジョニングできます。また、インスタンスフリートで使用されるこれらの機能はすべて、「AWS SDK」および「CLI」より入手できます。インスタンスフリートをプロビジョニングする方法を詳しく見てみましょう。まず、my-fleet-config.json に configuration json を作成します。 [ { “Name”: “MasterFleet”, “InstanceFleetType”: “MASTER”, […]

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する（あるいは反論する）ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています（例えば、日時が間違っている、地理座標が間違っているなど）。 最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。 データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。 関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。 このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。 異なる3つのデータセットを適合させて索引付けし、検索可能にします。 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。 Amazon AthenaやAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

ここ数年で、エンタープライズ企業において Apache hadoop エコシステムを用いて、センシティブであったり、きわめて秘匿性が高かったりするデータを扱う、重要なワークロードを走らせるケースが非常に増えてきています。そうしたワークロードの特性により、エンタープライズ企業ではしっかりした組織/業界全体のポリシーや、規制、コンプライアンスのルールを定めています。それに基づいて、機密データの保護や、権限のない人がアクセスできないようにすることが求められています。 こうしたポリシーにおいては一般的に、データストアに保存されているとき、そしてデータを転送しているときの両方で暗号化が要求されます。Amazon EMR では “セキュリティ設定” を使うことで、AWSキーマネジメントサービス (KMS) からお客様自身が用意した暗号化要素まで、さまざまな暗号化キーや証明書を指定することができます。 暗号化設定についてのセキュリティ設定を作り、クラスター作成の際に、その設定を当てることができます。セキィリティ設定を一度作っておくことで、いくつものクラスターにその設定を簡単に適用可能です。 この投稿では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) による […]

Apache SparkやPresto、Apache Hadoopエコシステムを利用しているお客様は、ワークフローの完了次第クラスターを終了させることや、安価なAmazon EC2スポットインスタンスを利用してクラスターをリサイズをすることよってコスト節約するために、Amazon EMRの弾力性を活用しています。例えば、お客様は日次のETLや機械学習処理のためにクラスターを作成し、それらの処理が完了したらクラスターを終了させるということや、BI分析者がアドホックでレイテンシーの低いSQLをAmazon S3に置かれたデータに対して行えるよう、業務時間帯のみPrestoクラスターをスケールアウトする、ということが可能です。 Amazon EMRリリース4.xと5.xで新しくサポートされたAuto Scalingによって、お客様は、クラスターのノードを、より簡単に追加(スケールアウト)や削除(スケールイン)できます。スケーリングの動作は、EMRから提供される５分間隔の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 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 StreamsやApache Kafka、Elasticsearch、Twitter 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.3、Zeppelin 0.6.2、HBase 1.2.3についての、より詳細な情報については、Amazon EMRのドキュメントをぜひご確認下さい。(原文) Amazon EMRでApache Flinkを利用する Apache Flinkは、お客様の間でリアルタイムビッグデータアプリケーションを構築するために使われている、並列データ処理エンジンです。Flinkによって、例えばAmazon Kinesis StreamsやApache 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 \ […]

AWS をご利用のお客様は (Apache Hadoop と Apache 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 […]

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 […]

Amazon EMRを使えば素早くコスト効率よく大量のデータを処理することができます。2009年のローンチ以来、数多くの新機能と増え続けるHadoopエコシステムのアプリケーション達のサポートを追加してきました。以下は今年に入ってから追加したもののうちのいくつかになります。 4月 – Apache HBase 1.2のサポート(EMR4.6) 3月 – Sqoop、HCatalog、Java 8、他のサポート (EMR 4.4) 2月 – EBSボリューム、M4インスタンス、C4インスタンスのサポート 1月 – Apache Sparkのサポートと他のアプリケーションの更新 本日またさらに一歩進めて、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 GuideやApache Phoenix Overviewのプレゼンテーションをご覧下さい。 アプリケーションの更新 また、以下のアプリケーションを更新しています: HBase 1.2.1 – […]