TALEND WEBINAR : March 27th, 2018 | Step-by-Step to Enterprise Data Integration

Talend“作业设计模式”和最佳实践

Talend“作业设计模式”和最佳实践

  • Dale Anderson
    Dale Anderson is a Customer Success Architect at Talend. Over a 30 year career, Mr. Anderson has gained extensive experience in a range of disciplines including systems architecture, software development, quality assurance, and product management and honed his skills in database design, modeling, and implementation, as well as data warehousing and business intelligence. A keen advocate for an appropriate temperance of the software workflow process, he has applied his innovations to the often overlooked lifecycle of a database. The Database Development Lifecycle Mr. Anderson has developed incorporates data modeling best practices to address the complexities involved in modeling adaptations, multi-environment fulfilments, fresh installations, schema upgrades, and data migrations for any database implementation.
  • December 07, 2015
 

作为 Talend 开发人员,不管是入门新手还是资深人士,常常要面对同一个问题:“在编写这项作业时,哪种方式最好”?我们知道,通常应当高效、易读易写,并且尤其(多数情况下)要易于维护。我们也知道,Talend Studio 好比自由形态的画布”,有全面而丰富的组件、存储库对象、元数据和链接选项,我们可以运用这些来“绘制”代码。那么,如何确定在创建作业设计时使用的是最佳实践?

作业设计模式

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

今年一月份加入 Talend 后,我有很多机会看到由客户开发的作业,得以证实自己的看法:对于每位开发人员,每个用例都有多种解决方案

我认为这一点是不少人的问题所在。我们作为开发人员的确都这么认为,但是在开发特定作业时,往往认为自己的方式是最佳或者唯一选择,但实际上也知道“或许还有更好的方式”,这种声音反复萦绕于耳际。在此情况下,我们期待或寻觅最佳实践,也就是作业设计模式!

制定基本规范

考虑实现最佳作业代码所需元素时,通常用到一些基本法则。这些法则源于多年来从失败中汲取的教训以及积累的成功经验。它们至关重要,为构建代码奠定坚实基础。我个人认为应该引起高度重视。我认为这些法则包括(重要程度不分先后):

- 可读性:创建明白易懂的代码

- 可写性:在最短时间内创建简洁明了的代码

- 可维护性:确定适当的复杂性,同时最大限度减少变更带来的影响

- 功能性:创建满足要求的代码

- 可重用性:创建可共享对象和原子工作单元

- 符合性:创建跨团队、项目、存储库和代码的真正规则

- 易适应性:创建可以变通而不致破坏的代码

- 可扩展性:创建可根据需要调整吞吐量的弹性模块

- 一致性:确定所有内容之间的共性

- 效率:创建优化的数据流和组件利用率

- 分区:创建服务于单一目标的原子化重点模块

- 优化:使用最少代码创建最多功能

- 性能:创建提供最快吞吐量的有效模块

重中之重是如何真正平衡这些法则,特别是前三条,因为这三者总是相互矛盾,满足其中两条往往要牺牲另外一条。rd如果可以,尝试按重要性对这些法则进行排序。

指南并非硬性标准,主要是为了有章可循!

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

出于上述以及其他相当明显的原因,首先要制定成文的 '指南'而非 建立 '标准'

其中包含基本法则并随附细则。“开发指南”文档由参与 SDLC(软件开发生命周期)过程的所有团队创建并采用之后,这些基本法则即可为开发中的结构、定义和上下文方面提供支持。对这一环节的投入具有长远意义,日后所有相关人员都将从中获益。

以下建议要点,您可根据自身情况予以采纳(仅作指导参考,欢迎自行修改扩充)。

  1. 方法 : 其中应详细说明希望 如何 构建
    1. 数据建模
      1. 整体/概念/逻辑/物理
      2. 数据库、NoSQL、EDW、文件
    2. SDLC 流程控制
      1. 瀑布式或敏捷式/Scrum
      2. 要求和规范
    3. 错误处理和审计
    4. 数据治理和管理
  2. 技术:其中应列出各种工具(内部工具和外部工具)以及各工具间如何相互关联
    1. 操作系统和基础架构拓扑
    2. 数据库管理系统
    3. NoSQL 系统
    4. 加密和压缩
    5. 3rd第三方软件集成
    6. Web 服务接口
    7. 外部系统接口
  3. 最佳实践:其中应说明要遵循特定指南的内容时间 particular guidelines are to be followed
    1. 环境 (DEV/QA/UAT/PROD)
    2. 命名规则
    3. 项目、作业和小作业
    4. 存储库对象
    5. 日志记录、监测和通知
    6. 作业返回代码
    7. 代码 (Java) 例程
    8. 上下文组和全局变量
    9. 数据库和 NoSQL 连接
    10. 源/目标数据和文件架构
    11. 作业进入和退出点
    12. 作业工作流程和布局
    13. 组件利用率
    14. 并行化
    15. 数据质量
    16. 父/子作业和小作业
    17. 数据交换协议
    18. 持续集成和部署
      1. 集成源代码控制 (SVN/GIT)
      2. 发布管理和版本控制
      3. 自动化测试
      4. 构件库和提升
    19. 管理与运营
      1. 配置
      2. 用户安全和授权
      3. 角色和权限
      4. 项目管理
      5. 作业任务、计划和触发器
    20. 存档和灾难恢复

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

- 模块库:描述所有可重用的项目、方法、对象、小作业和上下文组

- 数据字典:描述所有数据架构和相关的存储过程

- 数据访问层:描述与连接和操作数据相关的所有事项

诚然,创建这样的文档需要时间,但与之在整个生命周期中发挥的价值相比,这些成本值得投入。文档应尽可能简明扼要、直截了当并与时俱进(不必具有声明性质),它将有助于大幅减少开发错误(否则日后会为此付出高昂代价),对您所有的项目取得成功大有助益。

是时候探讨作业设计模式了吧?

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

作业设计模式和最佳实践

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

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

画布工作流和布局

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

我自己不太认同“”字型模式,也就是组件按顺序“从左”放置,到达最右边界后即向下排列,随后再返回到左侧边界,依次类推。感觉这种模式既不方便也不好维护,不过的确容易编写。如果必须要用这种模式,作业的工作负载可能较之前会增多,并且可能无法得以正确组织。

原子作业模块—父/子作业

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

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

tRunJob 与小作业

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

进入和退出点

所有 Talend 作业都需要在某个地方开始和结束。Talend 提供两个基本组件,即 tPreJob 和 tPostJob,目的是帮助控制执行作业内容前后发生的情况。在我的代码中,“初始化”“收卷”步骤相当于这两个组件。如您预期,首先执行 tPreJob,然后执行实际代码,最后执行 tPostJob 代码。请注意,无论代码正文中是否存在设计的退出tPostJob in the(例如 tDie 组件,或者组件复选框选项 “遇到错误时退出”),都将执行 tPostJob 代码。

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

对于这一业设计模式,我常使用 tPreJob to 初始化上下文变量,建立连接并记录重要信息。对于 tPostJob:则关闭连接和其他重要清洗以及更多日志记录。相当简单对吗?您是这么做的吧?

错误处理和日志记录

这一项非常重要,或者说至关重要,如果可以正确创建通用的作业设计模式,则几乎可以跨所有项目建立高度可重用的机制。我的作业模式是针对任何作业可能包含的具有一致性和可维护性的日志记录处理器,创建“logPROCESSING”小作业,再附加包含具有符合性、可重用性和高效性的明确定义的“返回代码。其中的附加项易于编写、易于阅读且易于维护。我相信,如果您能以“自己独有”的成熟方式来处理和日志记录项目作业的错误,则必将收获事半功倍的喜悦。建议合理借鉴,善加利用!

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

“On SubJob 正常/错误”与“On Component 正常/错误”(及 Run If)组件链接

有时候,Talend 开发人员对于“On SubJob”或“On Component”链接之间的差异心存一丝困惑。“正常”“错误”的区别显而易见,那么这些“触发连接”差异何在,如何影响作业设计流程?

“触发连接”可定义处理序列和数据流,其中组件之间的依赖关系存在于子作业中。子作业的特点是所用组件有一个或多个组件与其链接,从而处理当前数据流。单个作业中可能存在多个子作业,默认情况下所有相关子作业组件周围带有蓝色突出显示方框(可在工具栏予以开启/关闭)。

子作业中的所有组件完成处理后,“On SubJob 正常/错误”触发器将继续处理下一个“链接”子作业。仅可从该子作业中的起始组件处使用。在该特定组件完成处理后,“On Component 正常/错误”触发器将继续处理下一个“链接”组件。如果对下一个“链接”组件的继续处理是基于可编程 java 表达式,则“Run If”触发器会非常有用。linked’ component is based upon a programmable java expression.

何为作业循环?

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

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

结语

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

显然,若要尽可能涵盖有关这一主题的各个方面,我需要再写一篇或多篇博文。下一篇将重点探讨有价值的深层次主题,以及若干我们可能会以某种形式遇到的用例。此外,客户成功架构团队正致力于为这些用例提供配套的示例 Talend 代码。相关内容即将在 Talend 帮助中心面向订阅客户推出,敬请留意。

 

相关资源

5 种方式成为数据集成主角

提到的产品

Open Studio for Data Integration

 

Most Downloaded Resources

Browse our most popular resources - You can never just have one.

Join The Conversation

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *