ポイント: ビッグデータ自動化におけるベストプラクティスは、Control-Mのような企業ツールと比較したOozieの制約を強調し、監視とエラーメッセージ通知が不十分であるなどの問題を指摘しています。企業は、効率と可視性を向上させるために、Hadoopを包括的な自動化ツールと統合することをお勧めします。
- Oozieは堅牢なエラーメッセージ通知およびアラート機能が不足しています。
- ワークロード自動化ツールは、より優れた依存ロジックと統合を提供します。
多くのHadoop開発者にとって、Oozieを使用することは自然に思えるでしょう。これはHadoopインストールの一部であり、ほとんどのHadoopプロバイダーで標準であり、PigやHiveのような単一のHadoopジョブではなく、バッチプロセス全体をスケジュールする方法を提供します。
多くのHadoop開発者が見失っているのは、それがビジネスの他の部分とどのように統合されるかです。特にそのビジネスがバッチスケジューラやワークロード自動化ツール（例えばControl-M）を使用している場合です。考慮すべきいくつかのポイント：• ほとんどの企業には、重要な生産フローを監視するために指定されたグループがすでにあります• Oozieではエラーメッセージ通知やアラートが制限されています• Oozieの依存ロジックは、企業クラスのワークロード自動化ほど堅牢ではありません• Hadoopは単独のプロセスではなく、さまざまなソースからデータを取得し、データを再送信します• 動的処理は制限されています
重要な生産フローの監視
重要な違いの1つは、フローを監視しているのが誰かということです。ワークロード自動化を持つほとんどの企業には、バッチを監視するための最初の防衛線として専任のチームがあります。これらのバッチプロセスは通常、製造フローと見なされ、ビジネス全体にとって重要なプロセスを含みます。生産バッチ環境は、データウェアハウス、ERP、自社開発ツール、サプライチェーンなど、企業のほぼすべてのアプリケーションを監視します。このチームが最初に問題やビジネスに影響を与える状況を見ます。ワークロード自動化ツールは、バッチフローのすべてのレベルの可視性を提供するUIを提供します。フローが定義され、Oozieを通じて実行されている場合、バッチチームはOozieという別のツールを学ぶ必要があり、全体のフローのエンドツーエンドのロジックを見ることができません。これらのフローは、作成したチームやアプリケーション開発チームの一部として監視する必要があります。つまり、Oozieプロセスの監視は、一般的により高価で分散型のチームに押し付けられることになります。そして、特にこれらのフローがビジネスにとって重要な場合、その他のプロセスと一緒に監視されていないという点が特に重要です。
エラーメッセージ通知とアラートが制限されている
Oozieは、定義された決定に基づいて電子メールを介していくつかのアラート機能を提供しますが、他のアラート用には堅牢ではなく、決定を定義するのも簡単ではありません。Control-Mのようなワークロード自動化ツールは、アラートを送信したり、アラートに対してアクションを取るための複数のオプションを提供します。アラートの送信には、SNMPメッセージ、出力が添付された電子メール、または集中管理されたアラートパネルへのメッセージが含まれる場合があります。アクションには、プロセスの再実行、自己修復プロセスの実行、ヘルプデスクチケットの開設、他のジョブの実行のための依存関係の投稿、または特定のエラーコードに基づいてこれらのアクションのいずれかを実行することが含まれる場合があります。
依存ロジックは堅牢ではない
多くのツールがスケジューリング機能を含むのとは異なり、Oozieは開発者にフローを作成する方法を提供しますが、単一のプロセスをスケジュールすることはできません。すべてのHadoopタイプのジョブをスケジュールできますが、Java、SSH、ストリーミング、およびシェルスクリプトジョブも含まれています。シェルスクリプトを使用することで、開発者は他のサードパーティパッケージへの任意のコマンドライン統合を実行できます。しかし、InformaticaやIBM Datastageなどのこれらのパッケージへの直接接続はできません。Control-Mのようなワークロード自動化ツールは、サードパーティツールと接続し、それらのプロセスを実行、監視、制御する真の統合を提供します。データがHadoopジョブを実行する前に受信されることを確認するために、より堅牢なファイル監視機能があります。また、複数のデータベースに対してSQLスクリプト、ストアドプロシージャ、SSIS、およびSQLエージェントプロセスを実行してHadoopデータを取得または投稿することもできます。さらに重要なのは、Hadoopプロセスと外部プロセスの両方を単一の統合サービスにグループ化できることです。このサービスは、そのサービスレベル契約に従って管理され、遅延や問題が発生したときに通知を送信します。Webやモバイルアプリを含む複数のUIを通じて表示および監視できます。依存関係は、ファイル、ジョブの完了、または外部プロセスが投稿するなど、複数のシナリオに基づいて作成できます。フローは時間駆動またはイベント駆動、またはその両方で実行できます。並行または単一スレッドで実行できます。
Hadoopは単独のプロセスではない
Hadoop開発者はビッグデータプロセスに集中しており、ITオペレーションが管理する必要がある他のアプリケーションや技術に気づかない場合があります。彼らは、Oozieフローが完了するとプロセスが完了したと考えます。実際には、企業の他の部分がHadoopからの出力を必要としており、業務を行いシステムを更新する必要があります。Control-MのようなツールにHadoopを追加するショップは、これらの非Hadoopプロセスを含むサービスを作成しています。多くの場合、複数のジョブやアプリケーションがデータを処理する必要があり、Hadoopがその機能を実行する前に処理する必要があります。Hadoopの出力は他のシステムにも供給され、すべてがワークロード自動化ツールによって監視および制御されています。非HadoopおよびHadoopプロセスのためにアラートと通知が設定されているため、全体のフローが管理されています。
動的処理は制限されている
ほとんどのOozieフローは、時間に基づいてスケジュールされているか、時間に束ねられています。開発チームはアクセスでき、動的にフローを実行できますが、外部チームが同様に行う能力はありません。Control-Mのようなワークロード自動化ツールを使用すれば、任意のユーザーに、サービスやジョブを動的に実行、監視、制御する機能を提供できます。さらに、これらのサービスは遅延や失敗が発生した場合に監視され、時間内に完了できないことを防ぎます。
要約
Oozieは、サードパーティ製品に統合された従来のスケジューリングツールよりも多くの機能とオプションを提供していますが、企業全体が最終的に依存する必要がある多くの必須機能が不足しています。特に、Control-Mのような高度なワークロード自動化ツールで利用できる機能と比較すると顕著です。多くの企業がHadoop開発チームにWAチームと協力し、適切なツールで機能的フローを作成するよう求めています。
BMCのHadoop完全ガイド
これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも代表するものではありません。