ワン・プラットフォーム・イニシアティブ

2015年9月9日 Mike Olson

さる2013年、HadoopエコシステムにおけるApache Sparkの台頭について書きました。MapReduceは、長年にわたり、Hadoopにおけるデータ処理や変換処理のためのエンジンとして、大きな成功を納めてきました。しかし、これには問題がありました。まず、MapReduceのプログラミングが難しいことです。さらに、リアルタイムやインタラクティブなワークロードを扱えないという弱点があります。2009年にカリフォルニア大学Berkeley校のAMPLabで開発されたSparkは、まさにこうした弱点を補うよう設計されたものです。これは、MapReduceの成功と限界の両方から学んだ結果です。

2013年に私がポストした頃には、SparkをClouderaの商用ベースのHadoopに追加する作業は完了していました。そしてその頃には既に、Hadoopプラットフォーム上の汎用的なワークロードを処理するMapReduceが、Sparkに取って替わられることを信じていました。Clouderaはマーケットで最初に賭けたベンダーでしたが、多くが追随してきたのです。Sparkは今や、すべてのHadoopベンダーにディストリビューションされていますから。

加速するSparkの広がり

約2年前にCDHの一部としてSparkの出荷を始めて以来、2つの面白い、しかし重要なトレンドがあります。

まず、爆発的に導入が広まっていることです。Clouderaには、Sparkを実業務システム利用しているお客様が150社以上あります。ユーザーの要件は高く、Clouderaはその要望に猛烈な勢いで対応しています。ビッグデータは初めてというお客様もいますが、その多くはClouderaプラットフォームを補完する意味でSparkを使用しています。

次に、Sparkは成熟しているということです。これは、グローバルなオープンソース開発コミュニティの活動によるところが大きいと言えます。Sparkはこれまでもっとも活発なApacheソフトウェア財団のプロジェクトです。過去6か月間、SparkはHadoop本体のプロジェクトより(JIRAの数で言えば)50%も活発です。こうしたプログラマーは、非常に重要な仕事を担っています。Clouderaもまた熱心な参加者です。Clouderaのコミッターは、他のHadoopベンダーすべてを合わせた数を上回っています。

エンタープライズのユーザーは、プラットフォームのいっそうの成熟を望んでいますから、素晴らしい仕事と言えます。プロジェクトは素晴らしいのですが、Birkelayで最初に始まったとき、Sparkは調査用ソフトウェアで、ほとんどの場合、博士課程の学生の学術的な見解を検証する目的に使用されていました。安定性や信頼性の向上、商用ストレージシステムとの連携など、やるべきことは山ほどありました。こうしたギャップが完全に埋められたわけではありませんが、コミュニティ全体で大きな前進を遂げています。

現在、Clouderaのお客様は、ポートフォリオの検証、詐欺行為の検証、金融におけるコンプライアンス対応、ヘルスケア分野では医者向けの専門的な提案提供、保険分野での精緻なリスク分析、などにSparkを利用しています。Sparkは、ビッグデータを追加する、または拡張したいというお客様の数から言えば、Clouderaのプラットフォームでもっとも急成長を遂げているコンポーネントです。

2013年の賭けは元を取りつつあります。

ワン・プラットフォーム・イニシアティブ(One Platform Initiative)

こうした成功もあり、ClouderaはSparkに傾注しています。ClouderaはHadoopをエンタープライズグレードにするため、もっとも早くから、もっとも多くの投資をしてきました。これと同様、ClouderaはグローバルなHadoopコミュニティの協力や参加を得て、Sparkを進化させるためのイニシアティブを本日発表しました。この「

ワン・プラトフォーム・イニシアティブ」と呼ばれるイニシアティブは、SparkをHadoopの現在と将来にわたる主要なコンポーネントに据え、Sparkに今欠けている機能を、Hadoopエコシステムから提供しようというものです。Sparkでビッグデータから最大の成果を得るには、より密接な統合が必要です。

Clouderaは、ギャップを埋めプロジェクトが拡大するよう、Sparkの主要部分の開発と革新に投資します。また、Hadoopプラットフォームのエンタープライズグレードな機能と、幅広い統合を推進することで、Sparkのアプリケーションやユーザーが、ビッグデータインフラストラクチャーのメリットを十分受けられるようにします。

Clouderaが集中する分野は、セキュリティ、スケール、マネジメント、そしてストリーミングです。

セキュリティ

強力なセキュリティは、エンタープライズがSparkを使用する上での当然の要件です。データのプライバシー保護、正しいアクセス権の提供や無効化、データアクセスの正確なトラッキング、制度上要求があった場合の信頼ある報告などが可能でなければなりません。

Clouderaは、Sparkのセキュリティに対し、大きな投資を行なってきました(SPARK-6017 および SPARK-5682 参照)。また上述のように、Clouderaには、既に実業務にSparkを使用している、規制の厳しい業界のお客様も存在します。例えば次のような対応が必要です:

  • ディスクへの書き出しとデータシャッフルを行なうRDD(PDFリンク)を含む、保存データに対する暗号化
  • ネットワーク転送中のデータの暗号化
  • セキュアなWeb UI へのアクセス

Intel社との素晴らしい関係のおかげで、Intel のAdvanced Encryptionライブラリを使用し、低いパフォーマンスオーバーヘッドで、効率的に暗号化を行なうことができます。このライブラリは、暗号化計算をチップ上で行い、劇的に処理スピードを向上することができます。

Hiveテーブルからデータを読み出すために、SparkSQLがよく使用されます。Clouderaは、Sparkユーザーがテーブルのセキュリティやプライバシーを侵害しないよう、Apache Sentry HDFSプラグインを追加しました。さらに、テーブルレベルの保護をカラムやビューレベルのセキュリティに拡張する予定です。

長時間稼働する、Spark Streaming ジョブには、独自のセキュリティ要件があります。Clouderaは、長時間稼働するストリームジョブ向けに、自動認証更新機能を追加しました。さらに、Apache Kafka Direct Connector に対しても認証接続機能を追加する予定です。

スケール

Sparkは、レイテンシやスループットにおいてMapReduceを遙かに上回りますが、MapReduceの拡張性にはかないません。Clouderaの大規模顧客は、MapReduceのジョブを使って、数千ノードのペタバイト級のデータを扱っています。汎用的なワークロードを扱うMapReduceを、本当にSparkで置き換えられるようになるには、Hadoopエコシステムでもっと大規模なデータを扱えるようにならなければなりません。

ワン・プラトフォーム・イニシアティブの大きな目標は、Sparkのスケーラビリティにあります:数千もの実行処理をもつジョブを、1,000ノードを超えるような大規模なマルチテナントクラスタで、同時に実行できるようにすることです。これには、Sparkの処理フレームワークのさまざまなコンポーネントの改善が必要です。

YARNはHadoopのリソース管理フレームワークです。Spark同様、ClouderaはYARNをお客様に出荷した最初のHadoopベンダーです。YARNは、CDHで出荷するすべてのエンジンに対するリソースのアロケーションと管理を行ない、マルチテナントやマルチフレームワークアプリケーションの稼働を可能にします。

過去1年間にわたり、SparkのDynamic Executor Allocation on YARNの実用化に取り組んできました。HDFSとの連携を高め、スケジュールベースのデータローカリティ (SPARK-4352, SPARK-1767) とデータキャッシュを可能にします。しかし、現在のSparkの拡張性能をテストすると、コアのスケジューラに設計や実装上の問題があることが分かります。Clouderaは現在、スケジューラのロジックを見直し、タスクに障害が発生した際の回復力を強化しています (SPARK-5259, SPARK-5945, SPARK-8029, SPARK-8103)。また、大規模データセットを高速かつ高い信頼性で処理できるよう、Spark内部のデータ移動容量を増やしています。

Clouderaは、Intelとの緊密な協力関係のもと、Sparkの拡張性能テストに向けた大規模なクラスタをセットアップしました。動的なリソースアロケーションや、クラスタ、ジョブおよびタスクレベルの弾力性に関して、まだやるべきことが残っていますが、HDFSのDiscardable Distributed Memory(DDM:使い捨て分散メモリ)の強みを活かすことができます。

拡張性能問題への対処は、Sparkに限らず、その周辺ツールでもまた同様です。そして、ツールもまたワン・プラトフォーム・イニシアティブの対象になっています。

Spark Job History Server は、数万ノードで数千タスクを動かす、数千のジョブに対応できる拡張性をもつよう、大幅な改善が必要です。また、Sparkが十分に機能し、また拡張できるための、ライブラリやコンポートネントも必要です。このため、ClouderaはIntelとともに、次世代CPU、メモリ、ストレージ、ネットワークなど、プラットフォームのハードウェア最適化にも投資しています。機械学習や数値分析など、Sparkの一般的なワークロードのパフォーマンスを向上できるよう、Intel Math Kernel Library といった低レベルの機能向上を図れることも我々の強みです。

マネジメント

誰もがSparkの強力な分析機能を正当に評価しています。ただ、ここでよく忘れられるのが、業務環境へのSparkの導入と運用に関する実務的な課題です。大規模分散システムは生易しいものではありません。優れた管理ツールが必須です。

SparkとYARNの統合に問題はありません。ユーザーはYARNを使って集中的な導入と管理ができます。ユーザーは同じクラスタのリソースプールを、Spark、MapReduce、Impala、Hive、Pig、Search、その他のフレームワーク間で共有できます。Clouderaのエンジニアは、SparkとYARNの統合、特にその安定性と運用性能に、深く関与し (SPARK-1101, SPARK-3492) しました。Clouderaは、Sparkアプリケーションを起動するための共通インタフェースを構築し、容易に診断ができるよう、評価基準を追加しました。

しかし、さらに以下のような追加作業が必要です。

  • より優れたマルチテナンシー、パフォーマンス、使い良さに向けた、Spark-on-YARNの改善
  • 運用担当者がクラスタ上のジョブの快適な動作を維持できるよう、リソース消費や利用状況に関するレポートがSparkに必要
  • Sparkにはダイヤルが多すぎる - チューニングパラメータが非常に多く、ワークロードやデータ量、ユーザー数が変わるたびに調整が必要。プラットフォームは、発生した使用パターンを学習し、ひとりでに最適化されるようにする必要がある。
  • Pythonは、データサイエンスに人気がある言語であり、PySparkは人気の高いパッケージです。しかし現状、Pythonライブラリを的確にインストールして利用するのは、極めて難しい状態です。管理システムは、この分野でも役割を果たす必要があります。

ストリーミング

ストリーミングワークロード - モノのインターネット (IoT) からのデータ投入や、類似したリアルタイムデータの取り込みと分析は、Sparkを実業務に採用しているClouderaのお客様のおよそ1/4に該当します。Spark Streaming に障害回復性を持たせ (SPARK-4026, SPARK-4027, SPARK-6222)、サービス停止によるデータロスが発生しないようにすることが、こうしたお客様にとって重要です。Clouderaは、こうした改善に多くの投資を行なってきました。また、Flumeデータ投入フレームワークとの連携も実装し、新しいアプリケーションも、既存のデータパイプラインを活かせるようなっています。

Sparkが高速とはいえ、ストリーム処理における改善余地はあります。パフォーマンスがプラットフォームの焦点となるとはいえ、特にSpark Streamingには、永続的な変更可能状態の管理 (persistent mutable state management) などに、明確な改善余地があり、大きなメリットをもたらすはずです。

こうしたリアルタイムワークロードはビッグデータで大きな成長が見込まれる分野です。ストリーム処理パイプラインの開発はまだ難しいですが、皆様ならできるかもしれません。また、ビジネスアナリストなど、コーダー以外でも容易に自分で使えるようにする必要があります。これを、シンプルな宣言型インタフェースによる高級言語レベル拡張や、シンプルなオーサリングツールを追加して実現する予定です。

ストリームを投入するジョブは通常、数日間、数か月、あるいは何年も動き続けます。アプリケーションコードやプラットフォームを更新するために、ジョブを停止させるわけにはいきません。プラットフォームの新規リリースは、サービスを停止させずに可能でなければなりません。

Hadoopはもう終わりでしょうか?

面白い話ですが、答えはNoです。

GoogleがHadoopをベースにしたシステムを自前で構築した結果、2つの成果を提供しました:スケールアウトストレージプラットフォーム(Hadoopでは、HDFSと呼ばれる)と、MapReduceと呼ばれる汎用的な処理フレームワークです。

MapReduceが最有力候補でしたが、それが唯一の選択肢である理由はありませんでした。「処理機能をデータに送る」という概念は、分散SQLクエリ処理(Impalaフレームワークを参照)や分散ドキュメントインデキシングおよび検索(Apache SolrをベースとしたCloudera Search)、さらにサードパーティーのプロプラエタリなエンジン(SASのHigh-Performance Analytic Server)には大変上手く機能しました。これらはすべてHDFSの上で動き、大規模分散処理の利点を活かし、同じデータに対して連携しながら動作しました。

Hadoopは明らかに恩恵をもたらします。柔軟に、さまざまなフレームワークをサポートするからです。Sparkはワン・プラトフォーム・イニシアティブの一部として、そうしたフレームワークを統合します。また、下位のストレージレイヤを統合することで、他のフレームワークと容易にデータが共有できるようになります。それに関わるセキュリティ、ガバナンス、管理、運用などもしかりです。SparkはHadoopを脅かすよう存在ではなく、Hadoopエコシステムをいっそう優れたものにする、強力で柔軟性をもつ機能追加なのです。

次に来るもの

オープンソースHadoopプラットフォームは、疑いなく、過去20年間のデータ管理分野における、もっとも興味深い革新と言えます。ハードウェアの使用方法、処理できるデータ量、ユーザーに提供する分析ツールの多様性など、当初から大きく進化しています。革新が今後も続くことに疑問の余地はありません。

それは、グローバルなオープンソースコミュニティの、優れた仕事によるところが大きいでしょう。急速に増えている、大企業ユーザーからのビッグデータへの要望が、コミュニティの方向性を決定づけるでしょう:ワークロードの要件はなんでしょう? 答えに窮するデータへの質問はなんでしょう?

それがClouderaのフォーカスするところです。Clouderaは単独で動いているわけではありません。広範なコミュニティや、DatabricksもSparkに深く関わっています。コミュニティがさらに成長し、さらに多くの方々が参加されることを期待しています。

Clouderaは、Hadoopプラットフォームが、この先10年間のランドスケープを支配するプラットフォームであると確信しています。Sparkはプラットフォームな重要な一部です。Sparkをより完全なものとし、Hadoopのもつセキュリティ、ガバナンス、運用面、その他の強みと、Sparkを同じレベルにすることが重要です。

ワン・プラトフォーム・イニシアティブの詳細をご理解いただくために:

  • 9月24日に公開されたウェビナーをご覧ください
  • Sparkに関する定期的なアップデートは、ブログをフォローください
  • com/spark をご訪問ください

Sparkを家族に迎え入れてから、ほぼ2年が経ちました。今後、何が起こるかいっそう楽しみです!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.