E 考慮点、制限および問題

この付録では、ODIでのビッグ・データ統合プロジェクトの作業の際に注意する必要がある考慮点、制限および問題のリストを提供します。

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

• 第E項「考慮点、制限および問題」

E.1 考慮点、制限および問題

ビッグ・データ統合プロジェクトの作業の際は、次の点に注意してください。

• ODI 12c (12.2.1.1)より前は、ODIプロシージャ/カスタムKMのGroovy、Jython、Beanshellコードは、ODIクラス・パスにこれらのJARが追加されていないかぎり、Hadoop/Pigクラスにアクセスできませんでした。

  ODI 12c (12.2.1.1)からは、Hadoop/Pigデータ・サーバーで構成されたパスにHadoop/Pigクラスが存在していれば、ODIプロシージャ/カスタムKMがそのHadoop/Pigクラスにアクセスできます。

• Hiveデータ・サーバー、そしてHadoopおよびPigデータ・サーバーにおいて、新しいプロパティoracle.odi.prefer.dataserver.packagesが使用できるようになりました。このプロパティでは、どのパッケージが親優先ではなく子優先でロードされるかを指定できます。

  注意: アップグレードされたリポジトリでは、アップグレードされたHadoop/Pigデータ・サーバーにこのプロパティは表示されません。このプロパティが表示されるのは新規データ・サーバーにおいてのみです。

• JEE環境において、エージェント・アプリケーションは再デプロイできます。しかし、Pigのシャットダウン・フック、ロギング・リークおよびその他の未検出のリークにより、作成された実行クラスローダはガベージ・コレクションされません。そのため、ODI 12c (12.2.1)では、ビッグ・データ機能を使用している場合、JEEエージェント・アプリケーションは再デプロイできず、サーバーの再起動が必要になります。

• データ・サーバーに割り当てられるパッケージ・フィルタはできるだけ明確である必要があります。安易に範囲の最も広いフィルタを指定しないようにしてください。たとえば、フィルタ要素としてorg.apacheを指定すると、BeanshellのClassCastExceptionやXMLパーサーのインスタンス化などが発生します。これが発生するのは、Java言語仕様により、2つのクラス・インスタンスがキャスト可能なのは、両者が同じタイプ宣言であり、かつ同じクラスローダによってロードされる場合のみであるためです。この例では、インタフェースはorg.apache.util.IMyInterfaceなどの、org.apacheのサブパッケージの下になります。Studioクラスローダ/Webアプリケーション・クラスローダによりロードされるインタフェース・クラスがキャストのターゲットです。実装クラスがリフレクションによりインスタンス化される際、インスタンス・クラスのインタフェース・クラスも実行クラスローダによりロードされます。JNIEnvコードでキャスト元とキャスト先で同じタイプ宣言を共有しているかのチェックが行われている場合、LHSにはStudio/Webアプリケーション・クラスローダが、RHSには実行クラスローダがあるため、そのチェックはfalseになります。

• 実行クラスローダ・インスタンスはキャッシュされます。データ・サーバー・パッケージ・フィルタまたはデータ・サーバー・クラスパスを変更すると、新規クラスローダ・インスタンスが作成されます。古いクラスローダはすぐには(あるいはその後もずっと)ガベージ・コレクションされない可能性があります。これはヒープ・スペースの不足につながる可能性があります。唯一のソリューションはJVMの再起動です。

• パッケージ・フィルタリング・プロパティが設定されたPig、Hadoopまたはその他のデータ・サーバーをSDKを使用して作成する場合、さらにデータ・サーバー・プロパティを追加するには、1つの点に注意する必要があります。現在のプロパティのセットを取得し、それに対して自分のプロパティを追加して、それからそれをデータ・サーバーで設定する必要があります。そのようにしない場合、フィルタリング・プロパティは失われます。