以前、私はボーエンは、私は深く光栄良い反応、のように見える同じテーマを掲示し、私は熱心な読者のためにあなたに心から感謝の意を拡張したいと思います。
同じテーマボーエンの最初の2つのシリーズの新しい読者を初めて訪問している場合は、提案されている最初の読み取り、「才能」ジョブデザインモード「とベストプラクティスは、」パート1とパート2その、その後、この以降のコンテンツを読みます。
次に、我々は、トピックを議論していきます、自分の意見を表現する質問をしても、議論するために、Talendのコミュニティが拡大する場合について議論を歓迎している、私に達するものと考えることができる潜在的な願いを。覚えておいてください「ガイド」「ではありません標準権利、」？敬具私は、自分の意見を共有すること自由に感じ、あなたが発言していることを願っていますが、いくつかのよりエキサイティングに参加しています。
テーマベースのビルド
以前、我々は明確に認識している、ソフトウェアのライフサイクルの成功に不可欠な「開発者ガイド」、また才能のプロジェクトの例外を開発。私たちは確信を持って言うことができるガイドラインの開発の設立は、チームで追求され、徐々に規律がある開発才能の優れた性能を達成するための鍵。だから我々は異論がないと信じています。Talendのジョブは「理解することが、紆余曲折（曲線Iは、新しいバージョンの話ではない）を構築することができる、ビジネスユースケースを」、「技術」と「方法」の基礎を大幅にビルドプロセスの円滑な進行を容易にすることができます。私は将来的にあなたが元々行うには喜んでいるよ、チームのガイドを開発するために時間を割いてすることは価値があると思います。
多くのデータ統合プロセスのユースケースは、通常、Talendの顧客の課題のいくつかのフォームに関連し、これは、1つの場所からデータを移動するための別の場所に、Talendのコア競争力の一部であるされています。データ・ストリームの多くの形態がありますが、その具体的な用途や処理方法は非常に重要であり、その重要性は間違いありません、私たちは各ジョブの際にコア要素を作成したと言うことができます。あなたが実際のビジネス・データのユースケースを移動する必要がある、と才能は、技術スタックの一部である場合、どのような方法は、使用するには？もちろん、SDLCのベストプラクティス我々は議論してきた、それに加えて、データ関連法は、さらにデータモデリングを含み、これは内容を議論するために私は非常に満足しています。25年以上のデータベースアーキテクトとして、私は無数のデータベース・ソリューションを設計、構築されました。私の意見では、データベース・システムのライフサイクルは非常に現実的な問題です。それは、フラットファイル、EDI、OLTP、OLAP、STARであるかどうか 、スノーフレークあなたは、災害のための大きなレシピの小さな左の抜け穴の終焉を処理するために世代からのデータとそれに対応するパターンを無視した場合、またはデータ・ボールトモード。
データモデリングは、このブログの主題ではなく、適切なデータ構造の設計と利用は非常に重要です。あなたは、データ保管庫についての私のブログの内容を参照し、データモデリングの記事の後続のリリースにも注意を払うことができます。私たちは、今は深く掘ることなく、文字通りの意味を検討する必要がありますが、データの開発ライフサイクル（DDLCは） 間違いなくあるベストプラクティス。あなたは私が意味することによって何を意味するか理解し、慎重に検討。
その他のジョブ設計のベストプラクティス
自宅に近い、の才能ジョブのデザインを見ていき、「ベストプラクティス。」これまでのところ、我々は16回のベストプラクティスを導入し、次のように8をご紹介します。あなたのこのシリーズの第一部になり、Benpianが吸収することは困難を避けるためには、継続して次の左のコンテンツをカバーすることはできません...はすぐ始まります！
考慮すべき多くのベストプラクティスを示します。
コードルーチン
時には、特定のプログラムのニーズを満たすことができないTalendのコンポーネントは、それは問題ではありません。Talendのは、結局のところ、Javaコード・ジェネレータ、はい、あなたはまた、プロセスおよび/またはデータストリームに組み込まれたキャンバス純粋なJavaでJavaコンポーネントを使用することができます。そうすることが十分でない場合、私はどのように行うことができますか？コード・ルーチン：別の有用な方法を試してみてください。これは、プロジェクトのリポジトリに追加することができ、実際のJavaメソッドです。これは基本的にJavaユーザー定義関数である、とあなたは仕事を通じてさまざまな場所でエンコードすることができます。
Talendのは、Javaの機能（あなたが使用している場合があります）、などの多くを提供します。
- getCurrentDate（）
- 配列（文字列seqName、INTのstartValue、INTステップ）
- ISNULL（オブジェクト変数）
あなたが仕事を考慮すると、プロジェクトがグローバルな例を使用しているとき、あなたは多くの操作を実行するコード・ルーチンを使用することができます。再利用可能なコードを繰り返し、私のブログの記事に記載されています。ユーティリティコードルーチンは、あなたが仕事を簡素化する一般的な方法を作成することができます場合、あなたは正しいです。あなたは、「ヘルプ」のテキストとしての機能を選択すると、ディスプレイに正しいノートを含めるようにしてください。
リポジトリパターン
プロジェクトのリポジトリの「メタデータ」の部分は、これが開発の重要な基本理念である、再利用可能なオブジェクトを作成するのに役立ちます、あなたはそれを覚えていますか？仕事のための再利用可能なオブジェクトを作成し、リポジトリのモデルには、強力な技術を提供しています。
- ファイルモード -あって、様々なフラット・ファイル・フォーマットをマップするために使用：
-
別居
-
場所
-
正規表現
-
XML
-
秀でます
-
JSON
- 一般的なモード -様々な記録構造をマッピングするために使用
- WDSLの モード - Webサービスメソッドの構造をマッピングするために使用されます
- LDAPの モード - LDAP構造をマッピングするために使用される（LDIFを使用することもできます）
- UN / EDIFACT -様々なマッピングするためのEDI取引構造
创建模式时，您要提供相应的对象名称、用途和说明，以及在作业代码中引用的元数据对象名称。默认情况下，这称为“元数据”。请花时间为这些对象定义命名惯例，或者代码中所有内容采用同样的名称，比如不妨使用“md_{objectname}”。可以参考我们的示例。
通用模式尤其重要，因为您可以借此创建针对特定需求的数据结构。以数据库连接为例（如同一示例所示），该连接采用来自物理数据库连接的反向工程表模式。“accounts”表包含12列，下方定义的匹配通用模式则有16列。额外的列用于将值元素添加到“accounts”表中，以及在作业数据流进程中用于并入其他数据。相反，数据库表也可能超过100列，而特定作业数据流只需要10列。可为这10列定义通用模式，用于对具有匹配10列的表执行查询。这项功能非常有用。因此我建议使用通用模式，除了可能仅有1列的结构，这在多数情况下都适用，只需简单内嵌即可。
请注意，其他连接类型（如 SAP、Salesforce、NoSQL和Hadoop群集）均可包含模式定义。
Log4J
Talend自6.0.1版开始支持Apache Log4J，并提供强大的Java日志记录框架。如今，所有Talend组件完全支持Log4J服务，这改进了我先前博文中谈到的错误处理方法。相信大家都已将这些最佳实践纳入到自身项目当中，至少我希望如此。现在可以使用Log4J进行进一步完善。
要使用Log4J，必须先启用该服务，在“项目属性”部分执行此操作。您还可在此调整团队日志记录指导原则，为控制台(stderr/stdout)和LogStash追加器提供一致的消息传递范式。在单一位置定义这些追加器，通过这种简单的方法，将Log4J功能纳入Talend作业中。请注意，Log4J语法中包含的级别值对应于我们熟悉的INFO/WARN/ERROR/FATAL优先级。
创建作业运行任务时，可在Talend管理控制台(TAC)启用Log4J将要记录的优先级。确保为DEV/TEST和PROD环境正确设置此项。最佳做法是将DEV/TEST设置为INFO级别，UAT设置为WARN，PROD设置为ERROR。更高级别也将包括在内。
Log4J与tWarn和tDie组件以及新日志服务器结合使用，可以真正强化对作业执行的监测和跟踪。您可以使用该功能，并为团队制定一项指导原则。
活动监控台 (AMC)
Talend提供集成附加工具用于增强对作业执行的监测，进而可将详细处理信息的收集活动合并到数据库中。其中包括图形界面，可从Studio和TAC予以访问。该工具有助于开发者和管理员了解组件和作业交互，防止意外故障，并支持重要的系统管理决策。不过，您需要安装 AMC数据库和Web应用程序，这是一项可选功能。“Talend活动监控台用户指南”提供有关AMC组件安装的详细信息，此处不再赘述。我们重点来看与其使用相关的最佳实践。
AMC数据库包含三个表，分别为：
- tLogCatcher - 捕获从 Java 异常或tWarn/tDie组件发送的数据
- tStatCatcher - 捕获从各个组件的tStatCatcher统计信息复选框发送的数据
- tFlowMeterCatcher - 捕获从tFlowMeter组件发送的数据
这些表会存储AMC UI的数据，基于这些数据提供作业活动的稳健可视化。请确保在“项目首选项”选项卡上选择正确的日志优先级设置，并仔细考虑对每种环境 (DEV/TEST/PROD) 的作业执行所施加的任何数据限制。在将版本推送到PROD环境之前，使用“主图表”视图来帮助识别和分析作业设计中的瓶颈。查看“错误报告”视图，分析在指定时间段内发生的错误比例。
这一点很实用。但这些表的用途不仅限于此。由于它们确实是数据库中的表，因而可编写SQL查询以从外部提取有价值的信息。使用脚本工具进行设置，如果某些条件发生并记录在AMC数据库中，可以编制自动查询和通知。在作业设计模式系列博文的第1部分中提到了既定“返回代码”方法，借助这种方法，这些查询能够以编程方式执行自动化操作，经证明这一点非常有用。
恢复检查点
如果您有一项长期运行作业，可能涉及多个关键步骤。如果某一特定步骤出错，重新开始代价太大了。在发生错误之前，如果能尽量减少在作业流指定点重新启动作业所需的作业量和时间，当然再好不过。TAC提供作业遇到错误时专门执行恢复的工具。从策略性和前瞻性角度来看，使用这些“恢复检查点”设计的作业无需重启即可恢复执行并继续处理。
发生故障时，可使用TAC“错误恢复管理”选项卡来确定错误，并在此启动作业以继续处理，这种方法很不错，对吧？
小作业
我们之前讨论了小作业的概念，这类可重用作业代码可以根据需要“包含”在一项或多项作业中，但其本质上是什么？小作业用例其实并不多，若有幸遇到，请善加利用。可通过不同方式构建和使用小作业，我们现在就来看看吧。
新建小作业时，输入/输出组件会自动添加到画布中。通过此快速启动功能，您可以使用小作业来分配出入作业工作流的模式。小作业的典型应用是通过其进行数据传递，内部执行的内容则由您决定。在下面的示例中，先传入一行数据，随即更新数据库表，记录到 stdout，然后将相同的行保持不变（在本例中）传出。
非典型应用包括删除输入和/或输出组件，以提供特殊案例数据/流程处理。在以下示例中，没有任何内容传入或传出此小作业。相反，tLogCatcher组件会监控各种选定的异常情况以进行后续处理（之前我们在错误处理最佳实践中已经看到过这种情形）。
显然，使用小作业可以显著提高代码的可重用性，这正是其初衷。可将这些小作业放入参考项目，使其惠及更多项目，持续发挥作用。
组件测试用例
如果您使用的仍是6.0.1之前的Talend旧版，可以忽略这项最佳实践，或者不如直接升级！我最喜欢的新功能之一是在作业中创建测试用例。现在这些并不完全是“单元测试”，而是组件测试；实际作业关联至父作业，特别是正在测试的组件。并非所有组件都支持测试用例。如果组件接受数据流输入并将其送出，则可以使用测试用例。
要创建组件测试用例，只需右键单击所选组件，然后在底部的“创建测试用例”中找到菜单选项。选择此选项后，将生成新作业，并打开该测试用例的功能模板。被测组件与内置的输入和输出组件一并由数据流打包，该数据流会直接读取“输入文件”，处理其中的数据并将记录传递到被测组件，该组件随后执行相应操作并将结果写入新的“结果文件”。完成后，将该文件与预期结果或“参考文件”进行比较，根据匹配与否，判定是否合格。- 简单吧？我们下面来看看。
以下是我们之前见过的一项作业，采用tJavaFlex组件处理数据流，将其传递至下游以便进行进一步处理。
已创建一个测试用例作业，如下所示：无需作出修改（不过我稍稍清理了画布）。
重要的是应了解，虽然您可以修改测试用例作业代码，但更改被测组件仅可在父作业中进行。比方说需要更改模式，在父作业（或存储库）中作出更改，测试用例将继承该更改。它们以不可分割的方式连接，从而依照其模式进行耦合。
请注意，一旦创建了测试用例“实例”，就可以创建多个“输入”和“引用”文件来运行同一测试用例作业。这样一来，无论测试数据好坏、大小和/或是否专用，均可进行测试。我建议不仅要仔细评估待测试内容，还要评估待使用的测试数据。
最后，如果利用了Nexus项目存储库，并将测试用例作业及其父作业一起存储在该库中，可以使用诸如Jenkins的工具来自动执行这些测试，进而确定作业是否适于推进至下一个环境。
数据流“迭代”
您肯定已经注意到，在完成Talend代码开发后，可以使用“触发器”进程或“行”数据流连接器将组件关联在一起。通过右键单击起始组件并将链接“行”连接到下一个组件，可以建立此关联。进程流链接为“OnSubJobOk/ERROR”、“OnComponentOK/ERROR”或“RunIF”，我们在之前的博文中介绍过这些内容。连接时，数据流链接被动态命名为“row {x}”，其中“x”是一个数字，由 Talend 动态分配以创建唯一的对象/行名称。这些数据流链接当然可以采用自定义名称（命名约定最佳实践），但建立此链接实质上会将数据模式从一个组件映射到另一个组件，并会表示出通过其传递数据的“管道”。运行时通过此链接传递的数据通常被称为数据集。根据下游组件，完整数据集在封装的子作业中进行端到端处理。
并非所有数据集处理都可以像这样一次完成，有时需要直接控制数据流，通过控制“逐行”处理或“迭代”来完成。来看下方图中的无意义代码：
请注意组件tIterateToFlow和tFlowToIterate。通过这些专用组件，您可以逐行迭代数据集来控制数据流处理。这种“基于列表”的处理在需要时非常有用。但要注意的是，在许多情况下，将数据流分解为逐行迭代之后，您可能必须将其重新收集回完整数据集，然后才能继续处理（例如所示的tMap）。这是由于要求某些组件强制处理“行”数据集流，并且无法处理“迭代”数据集流。另请注意，t{DB}Input组件在行菜单上提供“主”和“迭代”数据流选项。
请看示例场景：将数据流转换为列表，以及将文件列表转换为“Talend帮助中心和组件参考指南”中的数据流。这些场景有助于解释如何使用此功能。可以视需要使用此功能，并确保提供可读标签来描述您的目的。
结语
请将以上内容融会贯通！该专题的讲解即将接近尾声。本系列博文的第4部分将介绍最后一组作业设计模式和最佳实践，确保为构建良好的Talend代码奠定坚实基础。应之前的承诺，我会和大家探讨“示范用例”。我认为在开始论及抽象应用前，将所有这些最佳实践融入已有经验将大有助益。一如既往欢迎大家分享看法、提出问题乃至发表异议，为本系列锦上添花！