Earlier, I posted the same theme Bowen looks like a good response, which I deeply honored, I would like to extend my sincere gratitude to you for avid readers.
If you are a first-time visitors new readers, the proposed first reading of the first two series of the same subject Bowen, that "Talend" job design mode "and best practices" Part 1 and Part 2, and then Read this subsequent content .
Next, we will continue to discuss the topic are welcome to express their views, ask questions and even to debate, discuss if the Talend community to extend, it can be considered to reach my potential wish . Remember the " Guide " is not " standard ", right? Sincerely I hope that you speak up, feel free to share their views, have you participate in some more exciting.
Theme-based build
Previously, we have clearly recognized that the development of "Developer's Guide" indispensable for the success of the software life cycle, Talend project also exceptions. We can say with certainty that the establishment of guidelines developers, be pursued in the team, and gradually develop the discipline is Talend key to achieving superior performance. So we believe there is no objection. Talend jobs may build twists and turns (curve I'm not talking about the new version), to understand " the business use case ", " technology " and " methods " basis can significantly facilitate the smooth progress of the build process. I think taking the time to develop the team's Guide is worth, in the future you'll be glad to do originally.
Many data integration process use cases are usually related to some form of Talend customer challenge, and this is part of Talend's core competitiveness, to another location to move data from one location to. There are many forms of data streams, their specific uses and processing methods are very important, its importance is no doubt, we can say that we created when the core elements of each job. If you need to move the actual business data use cases, and Talend is part of the technology stack, then what method to use? Of course SDLC best practices we've discussed, but in addition, data-related method further includes data modeling, this is my very happy to discuss the contents. As a database architect for over 25 years, I designed and built countless database solutions. In my opinion, a database system life cycle is a very real problem . Whether it is a flat file, EDI, OLTP, OLAP, STAR , Snowflake or data vault mode, if you ignore the data and its corresponding pattern from generation to process the demise of the small left loopholes for big recipe for disaster.
Data Modeling is not the subject of this blog, but appropriate data structure design and utilization is very important. You can browse the contents of my blog about the data vault, and pay attention to the subsequent release of data modeling articles. We now only need to consider the literal meaning without having to dig deep, but data development life cycle (DDLC) undoubtedly is the best practice. Think carefully about, you will understand what I mean by meaning.
More job design best practices
Closer to home, continue to look at Talend job design of " best practices ." So far we introduced 16 best practices, the following will introduce eight. This series will be a fourth part, can not cover the content Benpian left next to continue, in order to avoid difficult to absorb ... of you immediately begin!
For more best practices to consider:
Code routine
Sometimes Talend components that can not meet the needs of a particular program, it does not matter. Talend, after all, Java code generator, yes, you can also use the Java component on the canvas pure java incorporated into the process and / or the data stream. If doing so is not enough, how can I do? Try another useful method: Code routines. This is an actual Java method, you can add it to the project repository. This is essentially the java user-defined functions, and you can be encoded in various locations throughout the job.
Talend provide a lot of java function (you may have used), such as:
- getCurrentDate()
- sequence(String seqName, int startValue, int step)
- ISNULL (object variable)
When you consider the job, and when the project using global cases, you can use the code routines that perform many operations. Reusable code is repeatedly mentioned in my blog post. If the utility code routine helps you create a generic way to simplify the job, you are right. When you select a function as the "Help" text, be sure to include the correct notes in the display.
Repository pattern
"Metadata" part of the project's repository helps to create reusable objects, this is an important guiding principle of development, you remember it? Create reusable objects for the job, the repository model provides a powerful technology, including:
- File mode - used to map various flat file format, comprising:
-
Separated
-
position
-
Regular Expressions
-
XML
-
Excel
-
JSON
- general mode - used to map various recording structure
- WDSL mode - used to map the structure of the Web service method
- LDAP mode - used to map LDAP structure (LDIF can also be used)
- UN / EDIFACT - EDI transaction structures for mapping various
创建模式时，您要提供相应的对象名称、用途和说明，以及在作业代码中引用的元数据对象名称。默认情况下，这称为“元数据”。请花时间为这些对象定义命名惯例，或者代码中所有内容采用同样的名称，比如不妨使用“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代码奠定坚实基础。应之前的承诺，我会和大家探讨“示范用例”。我认为在开始论及抽象应用前，将所有这些最佳实践融入已有经验将大有助益。一如既往欢迎大家分享看法、提出问题乃至发表异议，为本系列锦上添花！