Skip to main content

Talendのゞョブ蚭蚈パタヌンずベストプラクティス第2郚

 前回掲茉した、Talendのゞョブ蚭蚈パタヌンずベストプラクティスの第1郚は、非垞に奜評をいただきたした。読んでくださった方、ありがずうございたす。ただ読んでいない方は、ぜひお読みください。第2郚では、第1郚の内容をもずに、さらに詳现な内容を解説しおいきたす。たた、さらに高床な内容に぀いおもいく぀かご玹介しようず思いたす。

はじめに

私は、Talendの開発に長幎携わっおきたしたが、他の開発者がゞョブを䜜成する方法に察しお垞に興味を持っおいたす。機胜を正しく䜿甚しおいるか、䞀般的なスタむルを䜿甚しおいるか、それずも私が知らないスタむルなのか、他にはない優れた゜リュヌションを開発しおいるか、キャンバス/コンポヌネントデヌタ/ワヌクフロヌが持぀抜象的な特性に苊劎しおいるのではないか。答えがどうであれ、重芁なのは、蚭蚈の意図に沿っおツヌルを䜿甚するこずです。これこそが、このブログでゞョブ蚭蚈のパタヌンずそのベストプラクティスを解説しおいる理由です。Talendの機胜をすべお理解しただけでは十分ではなく、ゞョブを䜜成する最適な方法を理解する必芁がある、ず私は考えおいたす。

論理的には、「ビゞネスナヌスケヌス」はあらゆるTalendゞョブの基本的な掚進芁玠です。実際には、同じワヌクフロヌでもさたざたなバリ゚ヌションがありたすし、ワヌクフロヌにもさたざたなタむプが存圚したす。このような「ナヌスケヌス」のほずんどは、「デヌタ゜ヌスからデヌタを抜出しお凊理し、そのデヌタを倉換した埌、最終的には別のタヌゲットにロヌドする」ずいう最もシンプルな圢匏で行われるデヌタ統合ゞョブ、ずいう倧前提からスタヌトしたす。この点で、ETL/ELTコヌドは私たちの䜜業の掻力源であるず蚀えたす。これは、Talendで日々コヌディングに取り組んでいる開発者の皆さんがよくご存じなので、ここでは扱いたせん。第2郚では、皆さんの芖野を広げる内容をご玹介したいず思いたす。

Talendの最新リリヌスv6.1.1は、これたでで最高のバヌゞョンだず思いたす。ビッグデヌタ、Spark、機械孊習、UIのモダナむれヌション、継続的な統合ず展開の自動化他にも倚圩な機胜が実装されおいたすにおいお、コンポヌネントが新たに加わりたした。今日販売されおいるデヌタ統合テクノロゞヌの䞭で最も優れた堅牢性ず機胜性を誇るバヌゞョンです。少々手前味噌かもしれたせんが、ナヌザヌの皆さんも私ず同じ評䟡をしおくださるず思いたす。ぜひ、ご自分で実感しおみおください。

DIプロゞェクトを成功ぞず導く3぀の基本的指針

では、始めたしょう。怅子が立぀には、脚が少なくずも3本は必芁です。これは、゜フトりェア開発にも圓おはたりたす。デヌタ統合プロゞェクトの䜜成ずデリバリヌを成功させるには、3぀の基本的な芁玠が存圚したす。

  • ナヌスケヌス - 明確に定矩されたビゞネスデヌタ/ワヌクフロヌ芁件
  • テクノロゞヌ - ゜リュヌションを構築、展開、実行するツヌル
  • 手法 - 䞀般的に合意された実行方法

䞊蚘を念頭に、明確に定矩された「開発ガむドラむン」ドキュメントこのシリヌズの第1郚を読んでいただけたでしょうか プロゞェクト甚のドキュメントは䜜成されおいたすかに沿っお、前提ずなる条件を構築しおいきたしょう。

基本的指針の拡匵

Talendの「ゞョブ」が「ナヌスケヌス」ワヌクフロヌ内のテクノロゞヌであれば、ゞョブ蚭蚈パタヌンはそれを構築するベストプラクティスの「手法」です。このブログの内容で最も重芁なこずは、䞀貫した方法でゞョブを䜜成する、ずいう点です。もしもより良い方法が芋぀かり、それがうたく機胜しおいるのであれば、そのたた進んでください。ただし、パフォヌマンス、再利甚性、保守性の向䞊に苊戊しおいる方や、倉化を続ける芁件に合わせおコヌドのリファクタリングを続けおいる方には、これらのベストプラクティスが圹立ちたす。

さらに怜蚎すべき9぀のベストプラクティス

゜フトりェア開発ラむフサむクルSDLC

億䞇長者のMarcus Leminos氏が提䟛する番組、「The Profit」CNBCによれば、「人、補品、プロセス」は、あらゆるビゞネスの成吊を分ける3倧芁玠です。これには、私も同意したす。SDLCプロセスは、゜フトりェア開発チヌムの芁です。このプロセスを適切に行うこずが非垞に重芁であり、それを無芖すれば、プロゞェクトに深刻な圱響を及がし、プロゞェクトは倱敗に陥っおしたいたす。TalendのSDLCベストプラクティスガむドには、Talendが開発者に提䟛する継続的統合ず展開に関する抂念、原則、仕様、詳现な説明が蚘茉されおいたす。前のブログ蚘事でご玹介した「開発ガむドラむン」ドキュメントにSDLCベストプラクティスを反映するこずを、すべおの゜フトりェア開発チヌムにお勧めしたす。

ワヌクスペヌスの管理

Talend StudioをノヌトPC/ワヌクステヌションにむンストヌルするず管理者暩限があるものずしたす、デフォルトの[Workspace]ディレクトリがロヌカルディスクドラむブ䞊に䜜成されたす。倚くの゜フトりェアむンストヌルず同様に、このデフォルトディレクトリは、実行可胜ファむルず同じディレクトリ内に䜜成されたす。私は、これは良いプラクティスだずは思いたせん。なぜでしょうか。

プロゞェクトファむルゞョブ、リポゞトリメタデヌタのロヌカルコピヌは、この[Workspace]に栌玍されたす。これを、゜ヌスコヌド管理システムSVN、GITにTalend Administration CenterTACを介しおアタッチするず、プロゞェクトをオヌプンたたは保存するたびに同期が行われたす。このようなファむルは、簡単に識別および管理できる堎所に栌玍すべきです。ディスクたたは別のロヌカルドラむブ䞊に栌玍するのがよいでしょう。

ワヌクスペヌスは、Talend Studioで接続を䜜成する際に䜿甚されたす。接続は、「ロヌカル」ず「リモヌト」のいずれかです。この2぀の盞違点は、「ロヌカル」接続がTACで管理されないのに察しお、「リモヌト」接続はTACで管理される、ずいう点です。䞀般的に、サブスクリプションナヌザヌは「リモヌト」接続のみを䜿甚したす。

チヌム党員が䜿甚する「開発ガむドラむン」ドキュメントでディレクトリ構造を明確に定矩するこずで、最適なコラボレヌションを実珟できたす。ここで重芁なのは、チヌムの同意を埗お、芏範を培底し、䞀貫性を維持するこずです。

参照プロゞェクト

皆さんは、参照プロゞェクトを䜿甚しおいたすか。参照プロゞェクトをご存知でしょうか。参照プロゞェクトは、シンプルであるにもかかわらず生産性を高める機胜なのですが、䜿甚しおいないナヌザヌが数倚く存圚したす。再利甚可胜な汎甚コヌドを䜜成し、耇数のプロゞェクトで共有するこずは、開発者共通のニヌズです。開発者は、プロゞェクトを開始する際、コヌドの䞀郚をコピヌし、別のたたは同じプロゞェクトやゞョブに貌り付ける、ずいう䜜業をよく行いたす。たたは、あるプロゞェクトのオブゞェクトを゚クスポヌトし、別のプロゞェクトにむンポヌトするこずもあるでしょう。か぀おは、私もこの方法を䜿甚しおいたした。このような方法に問題はないのですが、お勧めはしたせん。このプロセスには、保守においお深刻な問題が発生する危険が朜んでいたす。そこでお勧めなのが、参照プロゞェクトです。私は、参照プロゞェクトを芋぀けたずき、ずおも嬉しかったこずを憶えおいたす。

TACを䜿甚しおプロゞェクトを䜜成しおいる方は、ひっそりず存圚する[Reference]チェックボックスに気付き、「これは䜕だろう」を思ったこずがあるのではないでしょうか。プロゞェクトを䜜成し、このチェックボックスを遞択しお「参照プロゞェクト」を䜜成するず、他のプロゞェクトを「含める」蚭定や「リンク」するこずが可胜になりたす。「参照プロゞェクト」で䜜成したコヌドは、リンクしたプロゞェクト内で䜿甚できるようになるため読み取り専甚、再利甚可胜性が非垞に高たりたす。このプロゞェクトには、共通のオブゞェクトやコヌドをすべお栌玍すべきです。

 

     

ただし、「参照プロゞェクト」は最小限に留める必芁がありたす。ベストプラクティスでは、参照プロゞェクトの数は1぀に限定しおください。堎合によっおは、2぀たたは3぀でも問題ありたせん。泚意「参照プロゞェクト」の数が倚すぎるず、その効果が損なわれおしたす。参照プロゞェクトでは、慎重な管理が非垞に重芁になりたす。その甚途ずルヌルを「開発ガむドラむン」ドキュメントに明蚘し、チヌム党䜓が順守するこずにより、最適なコラボレヌションを実珟できたす。

オブゞェクトの呜名芏則

「名前が䜕だずいうのか。どのような名で呌ばれようず、薔薇は矎しく銙る」ずいう有名な台詞がありたすね。

そうはいっおも、やはり「呜名芏則」は重芁です。どの開発チヌムも呜名芏則に関しお怜蚎し、プラクティスを確立すべきです。Talendオブゞェクトの名前、呜名のタむミング、呜名方法にかかわらず、䞀貫性が必芁䞍可欠です。Talendのオブゞェクトの呜名芏則を「開発ガむドラむン」ドキュメントに明蚘し、チヌム党䜓が順守するこずで、最適なコラボレヌションを実珟できたす次第にパタヌンが芋えおきたこずにお気付きでしょうか。

プロゞェクトリポゞトリ

Talend StudioEclipse IDEIntegrated Development Environment。簡単に蚀えば、ゞョブ゚ディタヌですでゞョブを開くず、巊のパネルにプロゞェクトリポゞトリが衚瀺されたす。ここに、プロゞェクトオブゞェクトが栌玍されおいたす。ここには、極めお重芁なセクションがいく぀か存圚したす。その1぀がjob Designsセクションであり、v6.1.1では3぀のタむプのゞョブデヌタ統合、バッチ、ストリヌミングを䜜成できるように拡匵されたした。これ以倖にも、知っおおくべき重芁なセクションがありたす。

  • コンテキストグルヌプ - 組み蟌みのゞョブコンテキスト倉数を䜜成するのではなく、リポゞトリのコンテキストグルヌプ内に䜜成したす。これにより、ゞョブ党䜓で再利甚可胜になりたす参照プロゞェクトに含めた堎合は、プロゞェクト内でも䜿甚可胜。そのためには、グルヌプを効果的に線成する必芁がありたす。SBX/DEV/TEST/UAT/PRODの環境ごずにグルヌプを䜜成するのがベストプラクティスです。「デフォルト」のコンテキストは削陀しおください。 

この䟋では、「SysENVTYPE」ずいうコンテキスト倉数が远加されおいたす。この倉数には、遞択した環境内の動的なプログラマビリティで䜿甚する倀が栌玍されおいたす。぀たり、ゞョブ内でこの倉数を䜿甚するこずによっお珟圚の実行環境を特定できるため、条件付きロゞックを䜿甚しおフロヌをプログラムで倉曎するこずが可胜になりたす。

 

  • メタデヌタ - メタデヌタはさたざたな圢態を取りたす。DB接続やテヌブルスキヌマも、倚岐にわたるフラットファむル構造.csv、.xml、.jsonなども、すべお掻甚しおください。さらに、垞に有甚な汎甚スキヌマは、ここに曞き切れないほどさたざたな甚途に掻甚できたす。
  • ドキュメント - プロゞェクトWikiを䜜成し、チヌムに公開したす。圹立぀情報など、プロゞェクトに関するhtmlファむル矀が䜜成されたす。簡単に操䜜でき、わずか数分しかかかりたせん。

チヌムに圹立぀ベストプラクティスをいく぀か「開発ガむドラむン」ドキュメントに掲茉し、順守したす。必芁に応じお調敎が必芁ですが、この䜜業にはチヌム党員が参加するようにしおください。

バヌゞョン管理ブランチずタグ付け

ゞョブのプロパティタブには、バヌゞョン番号スキヌマずしお、「メゞャヌ」ず「マむナヌ」を指定する堎所がありたす。さらに、ステヌタスを蚭定するこずも可胜です。「development」、「test」、「production」ずいった倀をデフォルトで蚭定できたす。譊告これは、SVN/GITリポゞトリで共同開発や゜ヌスコヌド管理SCC機胜を利甚しない単独の開発者TOSTalend Open Studio向けに蚭蚈されおいたす。この堎合、内郚ゞョブプロパティが倉わるたびに、ゞョブの完党なコピヌがロヌカルワヌクスペヌスに䜜成され、SCCシステムず同期する、ずいう点に泚意しおください。私は、内郚バヌゞョンが10回以䞊倉曎され、ゞョブがコピヌされたプロゞェクトを芋たこずがありたす。ゞョブのコピヌがコピヌされお増殖し、すべおがSCCず同期されたす。その結果、プロゞェクトは巚倧になり、プロゞェクトのオヌプンずクロヌズ時にパフォヌマンスが倧幅に䜎䞋する可胜性がありたす。このような珟象が発生しおいる堎合には、最新バヌゞョンのみを゚クスポヌトおよびむンポヌトするこずでワヌクスペヌスを消去する必芁がありたす。面倒な䜜業ですが、やる䟡倀はありたす。

有料サブスクリプション環境のバヌゞョン管理では、SCCネむティブのブランチおよびタグ機胜を䜿甚するこずがベストプラクティスです。SCCは保存したゞョブの差分のみを保持するため、プロゞェクトバヌゞョンリリヌスの最適な管理方法です。これには、ゞョブ履歎に必芁なスペヌスを倧幅に削枛する効果もありたす。数字や日付などを䜿甚したバヌゞョンスキヌマを考え、「開発ガむドラむン」ドキュメントに蚘茉し、チヌム党䜓が順守しおください。

メモリ管理

ゞョブの実行では、さたざたな項目を考える必芁がありたす。どの皋床のメモリ容量が必芁になるか、デヌタフロヌで膚倧な数の行を凊理するか、カラムやtMapのルックアップの数、ゞョブを実行する「ゞョブサヌバヌ」で他のゞョブも同時実行するか、「ゞョブサヌバヌ」に搭茉されおいるコアやRAM、tMap結合は、[Load Once]ず[Row by row]のどちらを蚭定するか、ゞョブで子ゞョブを呌び出すか、芪ゞョブに呌び出されるか、ネスト構造の数、子ゞョブを別のJVM䞊で実行するか、ESBゞョブを蚘述する堎合、䜜成されるルヌトの数はいく぀あるか、䞊列凊理䞋を参照を䜿甚するか、などがありたす。いかがでしょうか。このような項目をすべお怜蚎しおいる人はいないでしょう。

デフォルト蚭定は、蚭定可胜な基本倀です。メモリ割り圓おなど、ゞョブにはいく぀かのデフォルト倀が蚭定されおいたす。ずころが、デフォルト倀が垞に適切であるずは限らず、実際には問題の原因になる可胜性もあるのです。[Use Case Job Design]、[Operational Ecosystem]、[Real Time JVM Thread Count]がメモリ䜿甚量を決定したす。メモリ䜿甚量は管理する必芁がありたす。

 JVMメモリ蚭定は、プロゞェクトレベルや個々のゞョブで指定が可胜です䞊蚘参照。

[Preferences] > [Talend] > [Run]

すぐに䜜業を開始しお問題を解決したしょう。メモリ管理は芋萜ずされがちな䜜業ですから、開発ず運甚の䞡面で、チヌムのガむドラむンに蚘茉しお順守する必芁がありたす。このシリヌズの第1郚をただ読んでいない方は、ぜひ読んでください。

動的SQL構文

倚くのデヌタベヌス入力コンポヌネントでは、SQL構文を[Basic Settings]タブで正しく指定する必芁がありたす。もちろん、tMyDBInputコンポヌネントに構文を盎接入力するこずもできたすが、ゞョブや芪ゞョブを制埡するロゞックに基づいお、実行時に耇雑なSQLク゚リヌを動的に䜜成するこずを考えるず、こちらの方が簡単です。SQLク゚リヌの基本構成に䜿甚する「コンテキスト倉数」を䜜成し、tMyDBInputコンポヌネントに到達する前のゞョブフロヌで蚭定し、ハヌドコヌドク゚リヌの代わりにコンテキスト倉数を䜿甚したす。

たずえば、「コンテキストグルヌプ」を「参照」プロゞェクトリポゞトリに䜜成し、「SystemVARS」ずいう名前を付けたずしたす。ここには、再利甚可胜な幅広い倉数が含たれおいたす。動的SQLのパラダむムには、次の「文字列」倉数を定矩し、初期倀を「null」ずしたした。

この倉数をtJavaコンポヌネントに蚭定し、次のように、tMyDBInputク゚リヌフィヌルドに組み蟌みたす。

“SELECT “ + Context.sqlCOLUMNS + Context.sqlFROM + Context.sqlWHERE

倉数倀の連結では、倀の埌ろに「スペヌス」を入力するこずで芋やすくなりたす。さらにきめ现かい制埡が必芁な堎合には、「sqlSYNTAX」倉数を䜿甚し、SQL構文の句を連結する条件を制埡しお、Context.sqlSYNTAXをtMyDBInputク゚リヌフィヌルドに入力したす。デヌタベヌスホストから芋るず動的SQLではありたせんが、ゞョブから芋るずSQLは動的に生成されたす。

以䞊の内容すべおをガむドラむンに蚘茉し、チヌム党員が順守しおください。

オプションの䞊列化

Talendは、コヌドを䞊列化するメカニズムをいく぀か提䟛しおいたす。適切か぀効率的に䜿甚し、CPUコアやRAMぞの圱響をしっかりず怜蚎するこずにより、優れたパフォヌマンスを発揮するゞョブ蚭蚈パタヌンを生成できたす。では、オプションをご玹介したしょう。

  • 実行蚈画 - 耇数のゞョブ/タスクをTACから䞊列実行する蚭定が可胜です。
  • 耇数のゞョブフロヌ - 1぀のゞョブ内で耇数のデヌタフロヌを䜜り、同じスレッドを共有したす。フロヌ間に䟝存関係がない堎合、皀なナヌスケヌスシナリオのための手法ずなりたす。䞀般的に私はこの方法を䜿甚せず、ゞョブを個別に䜜成したす。
  • 芪/子ゞョブ - tRunJobコンポヌネント内で子ゞョブを呌び出すずき、[Use an independent process to run subjob]ボックスを遞択するこずにより、別のJVMヒヌプ/スレッドが確立され、そこで子ゞョブを実行できたす。ただしこれは、厳密に蚀うず䞊列化ではありたせん。
  • コンポヌネント - tParallelizeコンポヌネントは耇数のデヌタフロヌにリンクしたす。tPartitioner、tDepartitioner、tCollector、tRecollectorコンポヌネントは、デヌタフロヌの䞊列スレッドの数を盎接制埡したす。
  • DBコンポヌネント - ほずんどのDB入出力コンポヌネントは、特定のSQLステヌトメントでスレッド数の䞊列化を有効にする高床な蚭定が可胜です。倧幅な効率化が可胜ですが、倀が倧きすぎるず逆効果です。ベストプラクティスずしおは、25を指定しおください。

䞊蚘の䞊列化手法を組み合わせおネスト化する堎合にも、泚意が必芁です。メモリ䜿甚スタックを把握し、ゞョブ蚭蚈パタヌンの実行フロヌに现心の泚意を払っおください。この䞊列化オプションは、高床な機胜ずしおTalend Platformのみで提䟛されおいたす。䞊列化のガむドラむンはドキュメントから削陀したしょう...ずいうのは冗談です

Talendゞョブを成功させる秘蚣

ゞョブ蚭蚈パタヌンのベストプラクティスは、Talendゞョブを䜜成する最善の方法を怜蚎する際の参考になるはずです。ゞョブの䜜成を成功ぞず導く基本は、ガむドラむンの䜜成、芏範、䞀貫性です。実践するこず決定し、順守しおください。デヌタ/ワヌクフロヌのコヌディングでは、次の点を留意しおください。

「行動がすべおの成功の鍵だ」- パブロ・ピカ゜

最埌に、Talendゞョブの䜜成を成功ぞず導く秘蚣ずしお、泚意事項をたずめたす。

  • - tPreJobコンポヌネントずtPostJobコンポヌネントの䞡方を䜿甚する
  • キャンバスを煩雑にしない。コンポヌネントを過剰にグルヌプ化せず、少し広げる
  • コヌドを芋やすくレむアりトする。䞊から䞋ぞ、巊から右ぞ
  • 初回のコヌディングでうたくいくず期埅しない
  • メむンのゞョブルヌプを特定し、修了を制埡する
  • ゚ラヌ凊理手法を無芖しない
  • コンテキストグルヌプを幅広くDEV/QA/UAT/PROD賢く䜿う
  • 1぀のゞョブレむアりトを巚倧にしない
  • 小さなゞョブモゞュヌルを䜜成する
  • 耇雑にせず、シンプルにする
  • 汎甚スキヌマを必ず䜿甚する単䞀カラムのスキヌマを䟋倖ずするこずも可胜
  • オブゞェクトに名前を付ける
  • 必芁に応じおわずかではあるがゞョブレットを䜿甚する
  • tJavaFlexコンポヌネントの䜿いすぎに泚意する。tJavaたたはtJavaRowで十分な堎合がある
  • プロゞェクトドキュメントを䜜成しお公開する
  • 実行時メモリヒヌプの蚭定を省略しない

たずめ

いかがだったでしょうか。このシリヌズはただただ続きたすので、どうぞお楜しみに。次回は「ナヌスケヌスのサンプル」をお届けしたす。このブログ蚘事では、

基本的な抂念を拡匵し、より高床な内容をいく぀かご玹介したした。ぜひ参考にしおください。皆さんが実践しおいるベストプラクティスに関するコメントをお寄せください。有意矩なディスカッションになるこずを期埅しおいたす。では、次のブログ蚘事をお楜しみに。

関連リ゜ヌス

Talend Open Studio for Data Integrationの玹介

この蚘事で取り䞊げおいる補品

Talend Data Integration

Talendを䜿う準備はできおいたすか