2 Hadoopデータ統合の概念

この章では、Oracle Data Integratorを使用したHadoopデータ統合の基本概念の概要を示します。

この章の内容は次のとおりです。

Oracle Data IntegratorによるHadoopデータの統合

ビッグ・データ処理のシナリオを実装する場合の最初のステップは、データをHadoopにロードすることです。データ・ソースは、通常はファイルまたはSQLデータベースです。

データが集計、簡略化または処理されて小さなデータ・セットになったら、追加の処理および分析を行うためにそれをOracleデータベース、他のリレーショナル・データベース、HDFS、HBase、またはHiveにロードできます。Oracleデータベースへのロードを最適に行うには、Oracle Loader for Hadoopが推奨されます。

データのロード後に、Hive、PigまたはSparkを使用して、SQLと同様の方法でデータの検証と変換を実行できます。データ検証(NULLや主キーのチェックなど)および変換(フィルタ、集計、設定操作、表の導出など)を実行できます。また、カスタマイズした手続き型のスニペット(スクリプト)をデータの処理に含めることもできます。

Kafkaクラスタは、メッセージを処理および格納する1つ以上のKafkaブローカで構成されます。メッセージはトピックに編成され、物理的にトピックのパーティションに分類されます。Kafkaプロデューサは、クラスタに接続してメッセージをトピックに入れます。Kafkaコンシューマは、クラスタに接続してメッセージをトピックから受け取ります。特定のトピックに関するすべてのメッセージが同じメッセージ形式である必要はありませんが、トピックごとに単一のメッセージ形式のみを使用することをお薦めします。Kafkaは新しいテクノロジとしてODIに統合されています。

詳細は、「Hadoopデータの統合」を参照してください。

Oracle Data Integratorによる異なる言語のコードの生成

Oracle Data Integratorは、複数の言語に対応するコードを生成できます。ビッグ・データの場合は、HiveQL、Pig Latin、Spark RDDおよびSpark DataFramesが含まれます。

コードのスタイルは、主に、マッピングのステージングの場所に使用されるデータ・サーバーの選択によって決まります。

Sparkアプリケーションはyarnで実行することをお薦めします。このお薦めに従うと、ODIはyarn-clientモードとyarn-clusterモードの実行のみをサポートするようになり、実行時チェックが導入されます。

他のSparkデプロイメント・モードを使用していて、ODIではサポートされていないモードの場合は、次のデータサーバー・プロパティをSparkデータサーバーに追加する必要があります。
odi.spark.enableUnsupportedSparkModes = true

異なる言語のコードの生成ならびにPigおよびSparkコンポーネントKMの詳細は、次を参照してください。

Apache Oozieを利用したOracle Data Integratorプロジェクトの実行

Apache Oozieは、Hadoopでのアクションをオーケストレートするのに役立つワークフロー・スケジューラ・システムです。Hadoop MapReduceジョブを実行するアクションによるワークフロー・ジョブの実行に特化したサーバーベースのワークフロー・エンジンです。

Oozieワークフローの実装と実行には、Oozieについての詳細な知識が必要になります。

しかし、Oracle Data IntegratorがあればOozieのエキスパートになる必要はありません。Oracle Data Integratorを使用すると、Oozieワークフローを簡単に定義および実行できます。

Oracle Data Integratorでは、Oozieエンジンで統合プロジェクト(パッケージ、プロシージャ、マッピング、またはシナリオ)を実行することで、自動的にOozieワークフロー定義を生成できます。生成されたOozieワークフロー定義はOozieワークフロー・システムに配置されて実行されます。コンテンツの検証のためにOozieワークフローの配置のみを行い、実行は後から行うこともできます。

Oozieログからの情報は取得されてODIリポジトリにOozie UIへのリンクとともに保存されます。この情報はODIオペレータおよびコンソールに表示されます。

詳細は、「Oozieワークフローの実行」を参照してください。

Oozieワークフローの実行モード

Oozieワークフローをタスクおよびセッション・モードで実行できます。タスク・モードがOozieワークフローの実行のデフォルト・モードです。

ODIでは、Oozieワークフローの実行のために次の2つのモードが用意されています。

  • TASK

    タスク・モードではすべてのODIタスクに対してOozieアクションが生成されます。これがデフォルト・モードです。

    タスク・モードでは次は処理できません。

    • 複数のタスクにまたがるスクリプト・コードがあるKM

    • トランザクションがあるKM

    • タスクをまたぐファイル・アクセスができないファイル・システム・アクセスが発生するKM

    • ループ構成のあるODIパッケージ

  • SESSION

    セッション・モードではセッション全体に対してOozieアクションが生成されます。

    次のいずれかの条件に当てはまる場合は、自動的にこのモードが使用されます。

    • いずれかのタスクによりトランザクション接続がオープンされている。

    • いずれかのタスクにスクリプトがある。

    • パッケージにループが含まれている。

      パッケージ内のループはOozieエンジンではサポートされていません。SESSIONモードで実行しているときでも、実行やセッション・ログ・コンテンツの取得に関してループが正しく動作しない可能性があります。

注意:

ほとんどのユースケースにおいて、このモードの使用をお薦めします。

デフォルトの場合、Oozieランタイム・エンジンではタスク・モードが使用されます。つまり、Oozieランタイム・エンジンのOOZIE_WF_GEN_MAX_DETAILプロパティのデフォルト値はTASKです。

前述の条件が満たされているかどうかに関わりなく、Oozieランタイム・エンジンをセッション・モードを使用するように構成できます。Oozieランタイム・エンジンでセッション・レベルのOozieワークフローが生成されるよう設定するには、Oozieランタイム・エンジンのOOZIE_WF_GEN_MAX_DETAILプロパティをSESSIONに設定します。

詳細は、「Oozieランタイム・エンジンのプロパティ」を参照してください。

Lambdaアーキテクチャ

Lambdaアーキテクチャは、バッチ処理方式とストリーム処理方式の両方を利用して大量のデータを処理するように設計されたデータ処理アーキテクチャです。

Lambdaアーキテクチャには次のレイヤーがあります。

  1. バッチ・レイヤー: このレイヤーでは、システムに新規データを定期的にロードします。ロードされるデータには、すべての詳細が含まれていて完全な正確性があります。新しいデータは、ビューの生成時に使用可能なすべてのデータとともに処理されます。

  2. スピード・レイヤー: このレイヤーでは、リアルタイムのデータがすぐに使用できるようにシステムにストリーミングされますが、総合的な完全性が犠牲になります(この問題は次回のバッチ実行で解決されます)。

  3. サービス・レイヤー: このレイヤーでは、バッチ・レイヤーとスピード・レイヤーからのデータを結合するビューが構築されます。

ODIのマッピングでは、複数の物理マッピングを提供できる単一の論理マッピングの作成が可能です。これは、ODIにLambdaアーキテクチャを実装する際に理想的です。

論理マッピング

次の図では、ACTデータ・ストアが汎用データ・ストアとして定義されています。これと同じことが、TRGノードにも当てはまります。これらは、必須の属性を持つリバースエンジニアリングされたデータ・ストアからコピーして貼り付けることで作成できます。

図2-1 Lambdaアーキテクチャの論理マッピング

図2-1の説明が続きます
「図2-1 Lambdaアーキテクチャの論理マッピング」の説明

バッチ物理マッピング

次の図に示すように、バッチ物理マッピングの場合は、ACTにファイル・データ・ストアがあり、TRG_1にはHiveデータ・ストアがあります。

図2-2 Lambdaアーキテクチャのバッチ物理マッピング

図2-2の説明が続きます
「図2-2 Lambdaアーキテクチャのバッチ物理マッピング」の説明

ストリーミング物理マッピング

次の図に示すように、ストリーミング物理マッピングには、ACT用のKafkaデータ・ストアとTRG用のCassandraデータ・ストアがあります。

図2-3 Lambdaアーキテクチャのストリーミング物理マッピング

図2-3の説明が続きます
「図2-3 Lambdaアーキテクチャのストリーミング物理マッピング」の説明

論理マッピングに加えた変更は、それぞれの物理マッピングに同期されるため、Lambdaアーキテクチャの実装にかかわる複雑性を低減できます。