此前我发布的同主题博文貌似反响不错，这让我深感荣幸，谨向诸位热心读者致以诚挚谢意。
如果您是初次来访的新读者，建议先行阅读同一主题系列的前两篇博文，也即《Talend“作业设计模式”和最佳实践》第1部分和第2部分，然后再阅读本篇后续内容。
接下来我们将继续讨论主题，欢迎大家发表看法，提出问题乃至展开争论，若能将讨论扩展到Talend社区，也算是达成我的潜在心愿。还记得“指南”并非“标准”，对吧？衷心希望诸位踊跃发言，不吝分享自己的观点，有您参与一定更精彩。
基于主题构建
此前我们已经明确认识到，制定“开发人员指南”对于软件生命周期取得成功不可或缺，Talend项目亦莫能外。我们可以肯定地说，确立开发者指导原则、在团队中予以推行，以及逐步培养纪律性是Talend实现卓越成效的关键。相信这么说大家并无异议。构建Talend作业可能一波三折（我说的可不是新版中的曲线），理解“业务用例”、“技术”和“方法”基础可以显著促进构建过程顺利进行。我认为花时间制定团队指南非常值得，日后您会庆幸当初这么做。
不少对Talend客户构成挑战的用例通常关乎某种形式的数据集成过程，这一环节是Talend的核心竞争力，涉及将数据从一个位置移动到另一个位置。数据流有多种形式，其具体用途和处理方法都非常重要，其重要性不容置疑，可以说是我们创建每项作业时的核心要素。如果实际用例需要移动业务数据，而Talend是技术堆栈的组成部分，那么该使用什么方法？当然是我们讨论过的SDLC最佳实践，不过除此之外，与数据相关的方法还包括数据建模，这是我非常乐于探讨的内容。担任数据库架构师逾25年，我所设计和构建的数据库解决方案不计其数。在我看来，数据库系统生命周期是非常实际的问题。无论是平面文件、EDI、OLTP、OLAP、STAR、Snowflake还是数据保险库模式，如果忽略数据及其相应模式从生成到消亡的过程，小则留下漏洞，大则造成灾难。
数据建模方法并非本篇博文的主题，但采用适当的数据结构设计和利用率非常重要。您可以浏览我的博客中有关数据保险库的篇目，并留意后续发布的数据建模文章。我们现在只需考虑字面意义而不必深挖，不过数据开发生命周期(DDLC) 无疑是最佳实践。仔细思考，您会明白我所谓何意。
更多作业设计最佳实践
言归正传，继续来看Talend作业设计的“最佳实践”。到目前为止我们介绍了16项最佳实践，下面再介绍8项。这个系列还会有第4部分，本篇无法涵盖的内容留待下篇继续，以免诸位难以吸收…即刻开始吧！
可供考虑的更多最佳实践：
代码例程
有时Talend组件就是不能满足特定的编程需求，这没关系。Talend毕竟是Java代码生成器，没错，您还可以使用Java组件，在画布上将纯java合并到流程和/或数据流中。要是这么做还不够，还能怎么办？不妨尝试另外一种有用的方法：代码例程。这是一种实际Java方法，您可以将其添加到项目存储库。本质上这是用户定义的java函数，您可以在整个作业的各个位置进行编码和使用。
Talend提供大量java函数（您可能已经用过），例如：
- getCurrentDate()
- sequence(String seqName, int startValue, int step)
- ISNULL（对象变量）
当您考虑作业、项目和用例全局时，可以使用代码例程进行众多操作。可重用代码在我的博文中被反复提及。如果您创建的实用代码例程有助于以通用方式简化作业，那就对了。选择函数作为“帮助”文本时，请确保在显示时包含正确的注释。
存储库模式
项目存储库的“元数据”部分有助于创建可重用对象，这是一项重要的开发指导原则，您还记得吧？针对在作业中创建可重用对象，存储库模式提供功能强大的技术，包括：
- 文件模式 - 用于映射各种平面文件格式，包括：
-
分隔
-
位置
-
正则表达式
-
XML
-
Excel
-
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代码奠定坚实基础。应之前的承诺，我会和大家探讨“示范用例”。我认为在开始论及抽象应用前，将所有这些最佳实践融入已有经验将大有助益。一如既往欢迎大家分享看法、提出问题乃至发表异议，为本系列锦上添花！