Cloudera Altus によるデータエンジニアリング

元記事: http://blog.cloudera.com/blog/2017/05/data-engineering-with-cloudera-altus/

元記事著者: Philip Langdale

現代のビジネスでは、より膨大な量のデータや一連のデータソースを扱うため、分析、可視化、レポート作成を可能にするデータエンジニアリングの重要性がますます高まっています。

パブリッククラウドでのデータエンジニアリングワークロードでは、オンプレミスの導入とは異なる運用モデルが可能となります。ここでの主な要素は、クラウド環境内に別個のストレージレイヤが存在することと、オンデマンドでコンピューティングリソースをプロビジョニングする能力 (例: それぞれ Amazon S3 と EC2) です。このような環境では、データサイロを作り出すことなくデータストレージを計算リソースから切り離すことが可能になります。これらの環境特性を、多くの一般的なデータエンジニアリングワークロードが繰り返して定期的に繰り返されるという観察結果と組み合わせると、特定のワークロード用のクラスターを作成し、作業が完了した時点で終了させるというモデルを考えることができます。

これは、使用されているときにのみリソースを払うことと、それに付随するライフサイクル管理のオーバーヘッド (アップグレード、再構成など) を伴う長期運用クラスターの運用オーバーヘッドを回避するという点で興味深いものです。

Cloudera Altus Data Engineering

このことは Cloudera の新しい Altus Data Engineering サービスがどこに当てはまるのか、を示しています。Altus は新しいクラウドサービスプラットフォームであり、弊社が提供する最初のサービスは Data Engineering です。これまでの説明から分かるように、必要なときにクラスターを作成して終了し、それらのクラスターにジョブを投入することが主な機能です。Data Engineering サービスでは、これらの基本的なアクションを可能な限りシンプルかつ合理化しているので、お客様は現実の課題、つまりデータエンジニアリングワークロードの作成と実行にのみ注意していればよいということになります。

Altus を AWS に接続する

Altus にログインしたら、最初の仕事は自分の AWS アカウントを Altus に接続することです。AWS のクロスアカウントアクセスを活用して、Altus が永続的な資格情報を保持しなくてもクラスターをプロビジョニングするためのアクションを実行できる信頼関係を確立します。この委任されたロールの他に、クラスターを導入するサブネットやクラスターログを格納する S3 バケットなど、AWS 側の特定のリソースも指定する必要があります。

Altus 内では、これらの AWS リソースと信頼関係をカプセル化するための Environment を定義します。Environment は必要に応じて好きなだけ用意することができます。たとえば、開発と運用の作業負荷を分けるなど、作業がどこで行われているかを論理的に分けることができます。

Environment を作成する最も簡単な方法は、Environment Quickstart を使用することです。Environment Quickstart は実際にすべての AWS 側リソースを作成するため、事前に明示的に必要な設定はありません。これは AWS の CloudFormation を通じて実行されるため、別の VPC と関連するリソースを手に入れて、Altus クラスターを AWS アカウントの他のものと区別するようにします。Environment QuickStart は、以下のように非常にシンプルです。

たとえば既存の VPC を使用する場合など、AWS リソースをより詳細に制御する必要がある場合、Altus は、必要なAWS リソースの作成または変更のプロセスを順を追ってガイドするステップバイステップの Configuration Wizard も提供します (訳注: Configuration Wizard を用いた日本語のセットアップ手順は追って公開予定)。

Altus Data Engineering でクラスターを作成する

Environment が設定できたら、クラスターを作成できるようになります。このステップは簡単で、今まで運用してきたような共用クラスターを設定するよりもはるかに少ない情報しか必要としません。我々はクラスター上でどのような種類のワークロードが実行されるかを把握しており、実際に特定のワークロードしか実行しないため、クラスター用に最適化された構成を自動的に確立できるのです。入力すべき項目は、使用するコンピューティングサービス (Hive/Spark/MapReduce2)、実行する Environment、およびクラスターの物理的な特性 (インスタンスの種類とノード数) です。最後のセクションでは、クラスターで使用する SSH キーと Cloudera Manager の資格情報を指定します (Altus Data Engineering クラスターには Cloudera Manager への読み取り専用アクセスが含まれています)。

全て入力したら Create Cluster をクリックしてください。

Altus Data Engineering でジョブを投入する

クラスター作成中であっても、ジョブを投入するのを待つ必要はありません。Altus Data Engineering は、クラスター自体とは独立した内部ジョブキューを保持しているため、クラスターが準備完了になるまで投入されたジョブをキューイングすることができるのです。

ジョブのサブミット手順は柔軟です。ジョブを個別に、またはグループ化してサブミットすることができます。また、既存のクラスター、あるいはまったく新しいクラスター (ジョブ投入時にインラインで定義)、または既存のクラスターをクローンしたものにサブミットするかどうかを選択することができます。新しいクラスターにジョブを投入する場合は、すべてのジョブが完了した時点でクラスターを終了するように指定することもできます。このようにして、クラスターのライフサイクルを管理するための同期やポーリングを行うことなく、完全なワークロードを投入して処理することができます。

ジョブのパラメータ

投入するジョブの種類にかかわらず、S3 に格納されているジョブリソース (データファイルや、jar/hql スクリプトといったプログラムファイルの両方を指す) を使用するのが一般的でしょう。これらのファイルに s3a:// 形式の URL を指定することで、データと同様に S3 からプログラムファイルを読み込むことができます。

Altus の CLI

これまでの話はすべて UI を使用していましたが、Altus には簡単に使用できる包括的な CLI が付属しています。これは Altus 自身が提供するすべての機能が利用可能で、スクリプトや自動化のシナリオで有効でしょう。CLI のインストールと使用の詳細については、Altus のドキュメントを参照してください。

クラスターに接続する

通常の状態では、クラスターに直接接続する必要はありませんが、開発中は実行されるジョブの詳細を Cloudera Manager や YARN/Spark History Servers から調べたいかもしれません。クラウドクラスターへのネットワーク接続は複雑なシナリオになる可能性があるため、CLI に SOCKS プロキシヘルパーを実装することで、より簡単に接続できるようになっています。SOCKS プロキシは、クラスターへの単一の ssh 接続を処理し、内部 DNS 名 (クラウド環境外で解決しないもの) を通常どおり使用できるようにするのに役立ちます。我々が提供する CLI は、プロキシを自動的に設定し、プロキシを使用するように設定された Chrome ブラウザセッションを自動的に立ち上げることも可能です (この部分はオプションで、必要に応じて好みのブラウザ利用しても構いません)。

これで、ブラウザから Cloudera Manager にアクセスし、必要に応じて History Server の UI にアクセスできるようになりました。

最後になりますが、クラスター作成中に提供されたキーを使用してクラスターに SSH 接続もできます。

今後の展望

このブログ記事では、Altus Data Engineering の機能について簡単に紹介しました。これらの機能の詳細とより複雑なシナリオの説明については、製品ドキュメントを参照してください。

今後のブログ記事では、より詳細な機能や、追加予定の新機能についても詳しくご案内する予定です。

関連ブログ