問題タブ [spring-batch]

私はSpringバッチを使用しています.datareadersを使用してアイテムのリストをロードしています。私のリーダーごとに、それらはすべて、リストの最後に追加の null オブジェクトを返します。

誰もこれを見たことがありますか？私は何を間違っていますか？

バックグラウンド

ファイルを読み取り (使用しているサンプル ファイルのサイズは約 4 GB です)、ファイルに対して少量の処理を行い、それを Oracle データベースに書き出す Spring バッチ プログラムがあります。

私のプログラムは、1 つのスレッドを使用してファイルを読み取り、12 のワーカー スレッドを使用して処理とデータベースのプッシュを行います。

若い世代のメモリを大量に大量に消費しているため、プログラムが思ったよりも遅くなります。

設定

JDK 1.6.18
Spring バッチ 2.1.x
4 コア マシン、16 GB RAM 搭載

問題

これらの JVM パラメータを使用すると、Tenured Generation で約 5.x GB のメモリ、Young Generation で約 5.X GB のメモリを取得できます。

この 1 つのファイルを処理する過程で、私の Tenured Generation は問題ありません。最大で 3 GB になるかもしれませんが、完全な GC を 1 回実行する必要はありません。

しかし、ヤングジェネレーションは何度もマックスに達します。それは 5 GB の範囲まで上がり、その後並列マイナー GC が発生し、Young Gen を 500MB の使用量までクリアします。マイナー GC は優れており、完全な GC よりも優れていますが、それでもプログラムの速度が大幅に低下します (データベース アクティビティが停止するため、若い世代のコレクションが発生すると、アプリがまだフリーズしていると確信しています)。プログラム時間の 5% 以上をマイナー GC のために凍結して費やしていますが、これは過剰に思えます。この 4 GB のファイルを処理する過程で、50 ～ 60 GB の若い世代のメモリを大量に消費したと言えます。

私のプログラムには明らかな欠陥は見当たりません。一般的な OO の原則に従い、クリーンな Java コードを作成しようとしています。理由もなくオブジェクトを作成しないようにしています。私はスレッド プールを使用しており、新しいオブジェクトを作成する代わりに、可能な限りオブジェクトを渡しています。アプリケーションのプロファイリングを開始しようとしていますが、過剰なメモリ チャーンを回避するための優れた一般的な経験則やアンチ パターンがあるかどうか疑問に思っていました。4GB のファイルを処理するには、50 ～ 60GB のメモリ チャーンが最適ですか? オブジェクト プーリングのような JDK 1.2 のトリックに戻す必要がありますか? (ただし、Brian Goetz はオブジェクト プーリングが馬鹿げている理由を含むプレゼンテーションを行いますが、もうそれを行う必要はありません。私は自分自身よりも彼を信頼しています .. :) )

Spring Batch での JMS Item Writer/Reader の使用法を詳細に (Spring Batch のドキュメントよりも) よく調べるための優れたリソースを知っている人はいますか?

具体的には、キューを介して唯一のインターフェイスが非同期である既存のシステムを再利用しようとする任務を負っているため、次のことが可能かどうか疑問に思っています。

ステップ 1: いくつかのデータを読み取り、メッセージを作成します。
ステップ 2: JMSItemWriter を使用してメッセージをキューにドロップします。
ステップ 3: 応答キューで JMSItemReader を使用して、メッセージが戻ってくるのを待ちます。
ステップ 4: 他のことをし
ます... 1 日に数千回、すすぎと繰り返しを行います。

つまり、基本的に Spring Batch を使用して、非同期リソースとの同期対話を強制します。研究を進める前に、これが A) 可能であり、B) 将来大きな頭痛の種となるフレームワークの恥知らずな乱用ではないことを確認したいと思います。

事前に情報をありがとう。

夜間/毎時データの要約と大量のデータの統計収集を実行する一連の Python ETL スクリプトを置き換えることを検討しています。

私が達成したいことは

• 堅牢性 - 失敗したジョブ/ステップは自動的に再開する必要があります。場合によっては、代わりに回復手順を実行したいことがあります。
• フレームワークは、クラッシュから回復できる必要があります。ここは粘り強さが必要だと思います。
• 監視 - ジョブ/ステップの進行状況を監視できる必要があり、できればパフォーマンスに関する履歴と統計を確認できる必要があります。
• トレーサビリティ - 実行の状態を理解できなければなりません
• 手作業による介入 - あると便利です... API / UI / コマンドラインからジョブを開始 / 停止 / 一時停止できます。
• シンプルさ - 代替品を導入するときに、同僚から怒ったような目で見られたくない... シンプルで理解しやすい API が必要です。

現在のスクリプトは次のことを行います。

• 多くのマシンからテキスト ログを収集し、Hadoop DFS にプッシュします。将来、このステップで Flume を使用する可能性があります ( http://www.cloudera.com/blog/2010/07/whats-new-in-cdh3b2-flume/を参照)。
• データに対してHiveサマリー クエリを実行し、新しい Hive テーブル / パーティションに挿入 (上書き) します。
• 新しい集計データをファイルに抽出し、MySql テーブルにロード (マージ) します。これは、後でオンライン レポートに必要なデータです。
• 新しく追加された MySql データ (MySql テーブルから) に対して追加の結合を実行し、データを更新します。

私の考えは、スクリプトをスプリングバッチに置き換えることです。Scriptellaも調べましたが、この場合は「単純すぎる」と思います。

Spring-Batch (主に古い投稿) でいくつかの悪い雰囲気を見たので、ここでいくつかの情報を得たいと思っています。また、Spring-Batch と Hive の統合についてもあまり見たことがなく、面倒です。

私はSpringの経験がありますが、SpringBatchは初めてです。これで、データ構造を1つのデータベースの単純な構造から別のデータベースのより複雑な構造に移行するタスクがあります。データ構造は、このように名前を付けるオブジェクト階層に対応しています

古いデータベースではテーブルが2つしかなく、新しいシステムでは状況がさらに複雑になり、テーブルが8つありますが、今のところそれは関係ありません。

基本的に、行マッパーがOldParentから読み取り、NewParentに変換する単純なJDBCベースのソリューションを使用したいと思います。

したがって、基本的な構成スニペットは次のようになります。

このシナリオでは、parentReaderはOldChildオブジェクトを取得して変換し、おそらくchildReader/childWriterオブジェクトに委任します。

問題はこれです。数十万の親がありますが、各親は0から数百万の子を持つことができるため、親に基づくコミット間隔はまったく役に立ちませんが、構成可能なコミット間隔が必要です。

したがって、別の解決策は、ワークフローを子ベースにすることです。

このシナリオでは、childReaderはOldParentオブジェクトを読み取り、NewParentsを書き込み、parentReaderオブジェクトとparentWriterオブジェクトに委任する必要があります。ここでの主な欠点は、OldChildオブジェクトが関連付けられていないすべてのOldParentを失うことです。

OldParent -> NewParent3番目に考えられるシナリオは、との2つの異なるワークフローを持つことOldChild -> NewChildです。（OldParentIDとNewParentIDの間の関係を格納するマッピングテーブルを維持する必要がありますが、commit-intervalを含む標準構成を使用できます。

他の可能性はありますか？これらのうち、ベストプラクティスとして推奨するものはどれですか。

WAV を MP3 に順次変換するバッチ プロセスがあります。問題は、数千の後、開いたままのファイルが多すぎて、ファイルの制限に達してしまうことです。

これを行う理由は、SystemCommandTasklet のコードのためです。

これには、JVM に依存してプロセスをクリーンアップしたり、ファイルを開いたままにしたりするという厄介な副作用があります。

私はそれを次のように書き直しました：

これが私の mac で動作することは 95% 確信していますが (lsof のおかげで)、どのシステムでも動作する適切なテストを作成して、実行しようとしていることが実際に動作していることを証明するにはどうすればよいでしょうか?

すべてのエラー ログが正しいファイルに出力されるように、ロガー リスナーがアタッチされたベース ステップをセットアップしたいと考えています。

以下のセットアップは十分に単純で、http://static.springsource.org/spring-batch/reference/html/configureStep.html#mergingListsOnStep で示されている例にかなり似ていますが、 http ://www.springframework.org/schemaに従っています。 /batch/spring-batch.xsd、リスナーはステップの下ではなく、タスクレットの下に属しているようです。

では、正しいのは誰で、正しい xsd を使用して目的の結果を得るにはどうすればよいでしょうか?

次の基本ステップは、StepLogListenerリスナーがStepExecutionListenerを実装するトリックを行うようです。

しかし、それは最適ではなく、率直に言って完全に正しいとは言えません。これは、baseLoggedStep が TaskletStep の抽象インスタンスであることを意味します。

データベースを 2 回読み取る必要があるジョブを作成する必要があります。

最初のクエリは 1 つのレコードのみを返し、このレコードをフラット ファイルのヘッダーとして送信する必要があります。
2 番目のクエリは、同じフラット ファイルに書き込む必要がある一連のレコードを返します。

そのためのコンポジットライターを作成しようとしましたが、その中で2つのflatFileItemWriterを提供し、両方のflatFileItemWriterに同じリソース名を設定しました。しかし、これはリソースが既に存在するというエラーになります。

誰でも私が従うべきアプローチを教えてもらえますか?

前もって感謝します。

例外をスローする代わりに、指定されていない場合にnullと評価されるという意味で、ジョブパラメータをオプションにすることは可能ですか？

私が求めているのは

fileNamePatternが指定されていない場合を処理する別のBeanにプロパティとして渡すことができます。

2 つのテーブルに対して削除クエリを実行できるように、Java hibernate でバッチ処理の例を見つけることができますか。