Talend“做业设计模式”和最佳实践 - 第3部分

此前我发布的同主题博文貌似反响不错，这让我深感荣幸，谨向诸位热心读者致以诚挚谢意。

若是您是初次来访的新读者，建议先行阅读同一主题系列的前两篇博文，也即《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代码奠基坚实基础。应以前的承诺，我会和你们探讨“示范用例”。我认为在开始论及抽象应用前，将全部这些最佳实践融入已有经验将大有助益。一如既往欢迎你们分享见解、提出问题乃至发表异议，为本系列锦上添花！