【转】Talend做业设计模式和最佳实践-Part I

原文地址：https://mp.weixin.qq.com/s?__biz=MzA3OTg1Mzk4Nw==&mid=2453261363&idx=2&sn=e0f42602271d4bb0415b174dfad9963b&chksm=88604cffbf17c5e9b4a48daf5ec09341f34e0d4a44bba9e31501cbb1701bd8d995a5d173e3e8&mpshare=1&scene=1&srcid=0111PXlXmg0GVBeIsITB7zl5#rd

原文做者：talend官方

做为Talend开发者，无论是入门新手仍是资深人士，经常要处理同一个的问题：“在编写这项做业时，哪一种方式最好？”咱们知道，一般应当高效、易读易写，而且尤为（多数状况下）要易于维护。咱们也知道，Talend Studio比如自由形态的“画布”，有全面而丰富的组件、存储库对象、元数据和连接选项，咱们能够运用这些来“绘制”代码。那么，如何肯定在建立做业设计时使用的是最佳实践？

做业设计模式

自Talend版本3.4起，在每次使用时我都体会到做业设计对个人重要性。起初我在开发做业时并未思考模式。以前我用过Microsoft SSIS和其余相似工具，因此像Talend这样的可视化编辑器对我来讲并不陌生。相反，我关注的主要是基本功能、代码可重用性；其次是画布布局；最后是命名规则。现现在，针对各类用例我已经开发了数百项Talend做业，我发现代码变得更加精巧，可重用性更高，一致性也更好，此时，模式的意义才逐渐显露出来。

加入Talend后，我有不少机会看到由客户开发的做业，得以证明本身的见解：对于每位开发者，每一个用例都有多种解决方案。我认为这一点是很多人的问题所在。咱们做为开发者的确都这么认为，可是在开发特定做业时，每每认为本身的方式是最佳或者惟一选择，但实际上也知道“或许还有更好的方式”，这种声音反复萦绕于耳际。在此状况下，咱们期待或寻觅最佳实践，也就是做业设计模式！

制定基本规范

考虑实现最佳做业代码所需元素时，一般用到一些基本法则。这些法则源于多年来从失败中汲取的教训以及积累的成功经验。它们相当重要，为构建代码奠基坚实基础。我我的认为应该引发高度重视。我认为这些法则包括（重要程度不分前后）：

l 可读性：建立明白易懂的代码

l 可写性：在最短期内建立简洁明了的代码

l 可维护性：肯定适当的复杂性，同时最大限度减小变动带来的影响

l 功能性：建立知足要求的代码

l 可重用性：建立可共享对象和原子工做单元

l 符合性：建立跨团队、项目、存储库和代码的真正规则

l 易适应性：建立能够变通而不致破坏的代码

l 可扩展性：建立可根据须要调整吞吐量的弹性模块

l 一致性：肯定全部内容之间的共性

l 效率：建立优化的数据流和组件利用率

l 分区：建立服务于单一目标的原子化重点模块

l 优化：使用最少代码建立最多功能

l 性能：建立提供最快吞吐量的有效模块

重中之重是如何真正平衡这些法则，特别是前三条，由于这三者老是相互矛盾，知足其中两条每每要牺牲另一条。若是能够，尝试按重要性对这些法则进行排序。

指导原则并不是硬性标准，主要是为了有章可循！

在真正深刻研究做业设计模式以前，结合刚刚阐述的基本法则，咱们首先要确保了解一些其余值得考虑的细节。我发现不少时候标准过于严苛，并未针对与其相悖的非预期场景留出足够余量。而另一些时候则相反。不一样开发者一模一样地遵循刻板粗糙、有失协调的规范，更有甚者在做业设计中不连贯、缺少规划甚至毫无章法，造成不良风气。坦率说来，我认为这样过于草率并会形成误导，其实想要避免这些并不困难。

出于上述以及其余至关明显的缘由，首先要制定成文的“指南”，而非创建“标准”。

其中包含基本法则并随附细则。参与SDLC（软件开发生命周期）过程的全部团队建立并采用“开发指南”文档以后，这些基本法则便可为开发中的结构、定义和上下文方面提供支持。对这一环节的投入具备长远意义，往后全部相关人员都将从中获益。

如下建议要点，您可根据自身状况予以采纳（仅做指导参考，欢迎自行修改扩充）。

1. 方法：其中应详细说明但愿如何构建

1. 数据建模

1. 总体/概念/逻辑/物理

2. 数据库、NoSQL、EDW、文件

2. SDLC流程控制

1. 瀑布式或敏捷式/Scrum

2. 要求和规范

3. 错误处理和审计

4. 数据治理与管理

2. 技术：其中应列出各类工具（内部工具和外部工具）以及各工具间如何相互关联

1. 操做系统和基础架构拓扑

2. 数据库管理系统

3. NoSQL系统

4. 加密和压缩

5. 第三方软件集成

6. Web服务接口

7. 外部系统接口

3. 最佳实践：其中应说明要遵循特定指南的内容和时间

1. 环境 (DEV/QA/UAT/PROD)

2. 命名规则

3. 项目、做业和小做业

4. 存储库对象

5. 记录、监测和通知

6. 做业返回代码

7. 代码 (Java) 例程

8. 上下文组和全局变量

9. 数据库和NoSQL链接

10. 源/目标数据和文件架构

11. 做业切入和退出点

12. 做业工做流程和布局

13. 组件利用率

14. 并行化

15. 数据质量

16. 父/子任务和小做业（joblet）

17. 数据交换协议

18. 持续集成和部署

1. 集成源代码控制 (SVN/GIT)

2. 发布管理和版本控制

3. 自动化测试

4. 项目存储库和提高

19. 管理与运营

1. 配置

2. 用户安全和受权

3. 角色和权限

4. 项目管理

5. 做业任务、计划和触发器

20. 存档和灾难恢复

我认为应当开发和维护的一些其余文件包括：

l 模块库：描述全部可重用的项目、方法、对象、小做业和上下文组

l 数据字典：描述全部数据模式和相关的存储过程

l 数据访问层：描述与链接和操做数据相关的全部事项

诚然，建立这样的文档须要时间，但与之在整个生命周期中发挥的价值相比，这些成本物超所值。文档应尽量简明扼要、直截了当并与时俱进（没必要具备声明性质），它将有助于大幅减小开发错误（不然往后会为此付出高昂代价），为您全部的项目取得成功大有助益。

是时候探讨做业设计模式了吧？

固然，但首先还要说明一点。我认为，每位开发者在编写代码时均可能造成或好或坏的习惯。因此培养良好的习惯相当重要。能够从一些简单的习惯开始，好比为每一个组件添加标签。这会让代码更具可读性，而且便于理解（咱们的基本法则之一）。人人都养成这样的习惯后，确保全部做业都有序组织到存储库文件夹中，而且使用的名称对项目有必定意义（也即符合性）。而后让每一个人都采用相同的日志记录消息样式，比方说对于 System.out.PrintLn() 函数采用通用方法封装器，而且对于做业代码创建共同的切入/退出点标准（其中包含替代要求选项）。这二者都有助于快速实现多个法则。随着时间的推移，因为开发团队采用并充分利用定义明确的开发指南，项目代码将变得更易读写，而且可由团队中任何人进行维护（这也是我最指望的效果）。

做业设计模式和最佳实践

在我看来，Talend做业设计模式可为咱们提供建议的模板或框架布局，其中涉及关注特定用例的重要和/或必需的元素。模式一般可重用于相似做业建立，如此一来，咱们能够快速启动代码开发做业。如您预期，多个不一样用例也可引入通用模式，通过正确识别和实施，可以加强总体代码库、压缩做业量并减小重复或类似的代码。咱们下面就此展开探讨。

如下是要考虑的7项最佳实践：

画布工做流程和布局

可经过多种方法在做业画布上放置组件，并将这些组件相互关联。我偏好的作法大致是首先“自上而下”，而后“从左至右”，其中左侧边界流程一般是错误路径，右侧边界和/或下方边界流程则为指望的或正常的路径。理想状况下应尽量避免连线交叉，自6.0.1版开始引入巧妙的弧线链接，很好地体现了这种策略。

我本身不太认同“之”字型模式，也就是组件按顺序“从左到右”放置，到达最右边界后即向下排列，随后再返回到左侧边界，依次类推。感受这种模式既不方便也很差维护，不过的确容易编写。若是必需要用这种模式，执行的做业可能较以前会增多，而且可能没法得以正确组织。

原子做业模块 ~ 父/子做业

简言之，包含大量组件的大型做业很难理解和维护。要避免这种状况，建议尽量将大型做业分解为较小做业或工做单元。以后以子做业形式执行（使用tRunJob组件），其目的即对他们加以控制和执行。这么作也便于更好地处理错误和后续事件。请记住，杂乱的做业可能难以理解，难以调试/修复，而且几乎没法维护。而简单的小型做业具备明确目的，经过画布便可肯定意图，绝大多数易于调试/修复，维护也相对垂手可得。

建立嵌套的父/子做业层次结构虽然彻底能够接受，但须要考虑实际限制。根据做业内存利用率、传递的参数、测试/调试问题以及并行化技术（以下所述），良好的做业设计模式不该超过3级嵌套tRunJob父/子调用。嵌套再深可能更安全，但我有充分理由认为，对于任何用例5级足矣。

tRunJob与小做业

肯定子做业与使用小做业之间的简单区别在于，子做业是从做业中“调用”，而小做业“包含”在做业中。二者都提供建立可重用和/或通用代码模块的机会，在任何做业设计模式中结合使用二者都是一种很是有效的策略。

切入和退出点

全部Talend做业都须要在某个地方开始和结束。Talend提供两个基本组件，即tPreJob和tPostJob，目的是帮助控制执行做业内容先后发生的状况。在个人代码中，“初始化”和“收卷”步骤至关于这两个组件。如您预期，首先执行tPreJob，而后执行实际代码，最后执行tPostJob代码。请注意，不管代码正文中是否存在设计的退出（例如tDie组件，或者组件复选框选项“错误结束"），都将执行tPostJob代码。

关于做业切入和退出点，也应考虑使用tWarn和tDie组件。这些组件提供对做业完成位置和方式的可编程控制，还支持改进错误处理、日志记录和恢复机会。

在做业设计模式中，我常使用tPreJob初始化上下文变量，创建链接并记录重要信息。对于tPostJob，则关闭链接和其余重要清理以及更多记录。至关简单对吗？您是这么作的吧？

错误处理和日志记录

这一项很是重要，或者说相当重要，若是能够正确建立通用的做业设计模式，几乎全部项目都能创建高度可重用的机制。个人做业模式是针对任何做业可能包含的具备一致性和可维护性的记录处理器，建立“logPROCESSING”小做业，再附加包含具备符合性、可重用性和高效性的明肯定义的“返回代码”。其中的附加项易于编写、易于阅读且易于维护。我相信，若是您能以本身独有的成熟方式来处理和记录项目做业的错误，则必将收获事半功倍的喜悦。建议合理借鉴，善加利用！

最新版Talend增长了对Log4j和日志服务器使用的支持。只需启用“项目设置 > Log4j”菜单选项，而后在TAC中配置Log Stash服务器便可。强烈建议您在做业中归入这项基本功能，实践证实其效果卓越。

“OnSubJobOK /Error”与“OnComponentOK/Error”（及Run If）组件连接

有时候，Talend开发人员对于“OnSubJob”或“OnComponent”连接之间的差别心存一丝困惑。“OK”与“Error”的区别显而易见，那么这些“触发链接”差别何在，如何影响做业设计流程？

组件之间的”触发链接”可定义处理序列和数据流，其中组件之间的依赖关系存在于子做业中。子做业的特色是所用组件有一个或多个组件与其连接，从而处理当前数据流。单个做业中可能存在多个子做业，默认状况下全部相关子做业组件周围带有蓝色高亮方框（可在工具栏予以开启/关闭）。

子做业中的全部组件完成处理后，“OnSubJobOk /Error”触发器将继续处理下一个“连接”子做业。仅可从该子做业中的起始组件处使用。在该特定组件完成处理后，“OnComponenOK/Error”触发器将继续处理下一个“连接”组件。若是继续处理的下一个“连接”组件是须要基于可编程java表达式（true|false断定执行的状况），则“Run If”触发器会很是有用。

何为做业循环？

对于几乎每种做业设计模式，代码中的“主循环”和“辅助循环”都很是重要。这些点用于控制做业执行的潜在退出位置。“主循环”一般表现为数据流结果集的最顶层处理，完成主循环以后，做业即告完成。“辅助循环”嵌套在更高阶循环中，且一般需借助重要控制才可确保做业正确退出。我每次会肯定“主循环”并确保向控制组件添加tWarn和tDie组件。tDie一般设置为当即退出JVM（但请注意，即使如此tPostJob代码也会执行）。这些顶层出口点使用简单的代码，“0”表示成功，“1”表示失败返回，不过遵循本身制定的“返回代码”指南再好不过了。“辅助循环”（以及流程中的其余关键组件）中十分适合归入其余tWarn和tDie组件（其中tDie未设置为“当即退出 JVM”）。

上面讨论的大多数做业设计模式最佳实践以下图所示。请注意我用到了实用的组件标签，不过仍对组件放置规则稍做变通。不管如何，最终结果是做业具备高度可读性、可维护性并易于编写。

结语

至此，虽然说并未悉数解答您关于做业设计模式的疑问（实际上也不可能），但这总归是良好的开端。咱们介绍了一些基础知识，提供了方向，并做了小结。但愿这些有所帮助，而且能为诸位读者带来一些有益的启示。

若是您以为此文章对您有帮助，请点击右下方【推荐】让更多人看到，thanks！