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

Talend 作业设计模式和最佳实践 ~ 第 2 部分

Talend 作业设计模式和最佳实践 ~ 第 2 部分

  • 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.
  • March 30, 2016

 

很高兴看到上篇博文《Talend“作业设计模式”和最佳实践》收到不错的反响,在此向各位读者表示感谢。如果您尚未读过,建议先行阅读,因为本篇作为第二部分,是在前文基础上展开的后续探讨。现在似乎时机成熟,可以适当接触更深层次的主题。让我们稳扎稳打,现在开始!您将看到一些更有趣的情况。

作业设计入门

作为有经验的 Talend 开发人员,我总是好奇他人如何创建作业。他们是否正确使用各项功能?用到的样式我是否了解,抑或从未见过?想出的解决方案是否独到而精巧?又或者,鉴于画布/组件数据/工作流程本身的抽象性质,接下来是否愁眉不展,不知所措…无论这些问题的答案如何,我觉得使用专门设计的工具都非常重要。为此,我开始着手研究“作业设计模式”及与之相关的最佳实践。在我看来,即便已了解 Talend 的所有特性和功能,但是根本需求仍然不变,那就是探索构建作业的最佳方法。

从逻辑上讲,“业务用例”是任何 Talend 作业的关键基本驱动因素。事实上,我在同一工作流和各类不同工作流中看到各种不同的情况。这些“用例”大多数从基本前提出发,也即最简单的数据集成作业形式是从某个源提取数据并进行处理;在此过程中可能进行数据转换,最终将数据加载到某个目标位置。因而 ETL/ELT 代码不可或缺,Talend 开发人员也正致力于此。这一点我们就不再赘述,接下来我们放宽眼界,扩大探讨面。

毋庸置疑,最新版 Talend(6.1.1 版)是我用过的最好的版本。各个新组件都极具优势,比较典型的有大数据Spark机器学习、现代化 UI 和自动化持续集成/部署,该版本代表当今市场最为强大、功能最丰富的数据集成技术。这么说或许有点偏私,但我们始终设身处地为客户着想,希望您也能透过表象发现价值,作出自己的判断。

奠定 DI 项目成功的三大基础

我们都认同圆凳需要三条腿才能站稳,对吧?软件开发也是如此。构建并交付成功的数据集成项目需要三个基本要素:

  • 用例 - 明确定义的业务数据/工作流要求
  • 技术 - 创建、部署和运行解决方案的工具
  • 方法 - 业界公认的行事方式

考虑这些要素,加上完善的“开发指南”文档(您是否读过我以前的博文?是否已经为自己的项目编制此文档?),我们以此为前提展开探讨。

扩展基本理论

如果说 Talend“作业”在“用例”工作流中包含了技术,那么“作业设计模式”就是构建它们的最佳实践“方法”。若我在这些博文中分享的其他内容于您没有价值,但请至少在作业构建方式上保持一致。如果您找到了更好的方法,认为非常有效,那再好不过,不必做出改变。但是,如果您在性能、可重用性和可维护性方面备受困扰,或者需要反复调整代码以适应不断变化的需求,那么这些最佳实践对于您,Talend 开发人员,将大有裨益!

可供考虑的另外 9 项最佳实践:

软件开发生命周期 (SDLC)

人员、产品和流程”视为决定任何业务成败的三个关键因素。对此我非常赞同。SDLC 流程对于任何软件开发团队都是殊为关键的环节。正确处理非常重要,而忽视则可能导致项目严重受阻,甚至造成灾难性后果。Talend 的 SDLC“最佳实践指南”针对 Talend 开发人员可用的持续集成和部署功能,深入研究相关概念、原则、规范和细节。强烈建议软件开发团队将 SDLC 最佳实践纳入“开发指南”文档(我在本系列上篇博文中有述),然后照此实施。

管理工作区

当您在笔记本电脑/工作站安装Talend Studio 时(假设您拥有管理员权限),通常会在本地磁盘驱动器上创建默认的“工作区”目录,并且与许多软件安装一样,此默认位置位于可执行文件所在的目录中。我认为这么做确实不妥。原因何在?

项目文件(作业和存储库元数据)的本地副本存储在此“工作区”中,如果是通过 Talend Administration Center (TAC) 附加到源代码控制系统(即 SVN 或 GIT),当您打开项目和保存对象时,这些副本也会同步。我认为应将这些文件放在易于查找和管理的位置,最好是在磁盘上的其他位置(或者其他本地盘)。

需要说明的是,在 Talend Studio 中创建任何连接时都会使用工作区,包括“本地”或“远程”连接,区别在于后者由 TAC 管理,而前者则不是。对于我们的订阅客户,“远程”连接通常是唯一使用的类型。

对于如何组织目录结构,应在“开发指南”文档中予以明确说明,并由整个团队采行,以实现最佳合作和协作。关键是团队要在有益的事情上达成共识、培养纪律性并保持一致性

参考项目

您是否使用参考项目?是否了解其具体内容?我发现很多客户都不知道这项简单而高效的功能。我们都希望创建可以跨项目共享的可重用、共用或通用代码。我常常看到开发人员打开一个项目,复制代码片段,然后将其粘贴到单独的(有时是同一个)项目或作业中。或者从一个项目中导出对象,然后将对象导入另一个项目。说来惭愧,这两种方式,我之前都实操过。这些方式基本可行,但并非建议之举,因为对于维护人员可能造成潜在的严重后果。怎么办?可以有更好的方法,那就是参考项目!这些项目的确让人眼前一亮。

如果您用过 TAC 来创建项目,可能注意到一个名为“参考”的不显眼的复选框。有没有想过这是用来做什么的?其实,如果创建项目时选中该框,使其成为“参考项目”,那么该项目可以“包含”或“链接”到任何其他项目。在“参考项目”中创建的代码随后可用于链接的项目(只读),因而具备高度可重用性。这对于创建各类共用对象和共享代码十分适用。

 

 
 
 
 
 
 

但是,请将这些“参考项目”的数量保持在最低限度;我们建议仅保留 1 项作为最佳实践,不过在一些有争议的案例中,也可酌情采用 2-3 项。警告:创建“参考项目”过多则可能失去其原本意义,因此须适可而止。谨慎管理非常重要,应在“开发指南”文档中明确说明其用法和规则,并由整个团队采行,以实现最佳合作和协作。

对象命名规则

“名称有何意义?玫瑰不管怎么称呼,都是一样芬芳。” – 这句话出自哪里?

没关系,不必深究,但“命名规则”确实十分重要。名副其实的开发团队都了解这一点,并使之成为规范。无论 Talend 对象名称的使用时间、内容及方式如何,取得合理成功的核心仍然是一致性。对于 Talend 对象命名规则,应在“开发指南”文档中予以明确说明,并由整个团队采行,以实现最佳合作和协作(您发现这段话的行文模式了吧?)。

项目存储库

使用 Talend Studio(Eclipse IDE,即集成开发环境,或者简言之就是您的作业编辑器)打开项目时,左侧面板代表项目存储库。这是所有项目对象所在的位置。这里有几个非常重要的分区。首先,您必须要了解“作业设计”分区,这些分区已在 6.1.1 版中得到增强,以便适应可以创建的 3 种不同类型的作业(即数据集成、批处理和流式处理)。此外,您还需了解和运用以下分区。

  • 上下文组 - 不是创建内置作业上下文变量,而是在存储库中的上下文组中进行创建,并跨作业(以及参考项目中所包含的项目)予以重用;可以实现各个组有效地保持一致;最佳做法是创建对应于不同环境的组:SBX/DEV/TEST/UAT/PROD,其中 DEV 为默认值;删除现有“默认”上下文; 

 

 

注意我添加了一个上下文变量“SysENVTYPE”,其中包含选定环境中动态可编程性的值。换言之,我在作业中使用此变量来确定运行时当前正在运行的环境,这样就能以编程方式通过条件逻辑更改相应流程

 

  • 元数据 - 元数据以不同形式呈现,尽可全数利用,包括数据库连接及其表架构、各类平面文件布局(csv、xml、json 等),以及始终颇具用处的通用架构,这种架构可用于多种方式,在此不一一列出了,否则这篇博文内容会特别长
  • 文档 - 生成您自己的项目 Wiki 并将其发布至团队;此功能将生成一套完整的项目相关 html 文件,可以轻松导航;此分区十分有用,而且仅需几分钟即可搞定

建议在“开发指南”文档中为团队添加一些最佳实践,并在团队中予以坚持使用。可根据需要进行调整,但要让团队中的每个人都参与进来。

版本控制(分支和标记)

您可能已经注意到,每个作业属性选项卡都有一个设置主要 (M) 和次要 (m) 版本编号方案的位置。此外,您还可以设置自己的创建状态,其中默认的可能状态包括“开发”、“测试”和“生产”。警告:Talend Open Studio (TOS) 等专为单一开发人员设计,这些开发人员无法在 SVN/GIT 存储库中进行合作开发和源代码控制 (SCC)。您需要知道的是,每当更新这些内部作业属性,都会在本地工作区中创建作业的完整副本,并与 SCC 系统同步。我见过一些项目,其中的作业副本由十几次内部版本更新所生成。系统会复制该作业的所有副本,导致所有与 SCC 同步的从属文件迅速增加,项目因此尾大不掉,每次打开和关闭项目时会造成严重的性能问题。如果遇到这种情况,需要先执行导出,然后,重新导入仅最高版本的作业,以便清理工作区。虽然繁琐,但这么做很有必要。

因此,在所有付费订阅环境中,版本控制的最佳做法是使用源生 SCC 分支和标记机制。这始终是管理项目版本发布的最佳方式,因为 SCC 只针对每次作业保存维护增量信息。这么做可以显著减少特定作业历史记录所需的空间。使用数字、日期或有用的内容来设计版本控制方案,在“开发指南”文档中予以详细说明,而且整个团队都采用该流程(形成一套正确的程序)。

内存管理

您希望运行作业吗?是否考虑过作业的内存需求?数据流是否要在 tMap 中处理数百万行和/或众多列和/或多项查找?您是否考虑过当作业在“作业服务器”上运行时,其他作业可能也在同时运行?有没有想过“作业服务器”有多少核心/运行内存?您是如何配置 tMap 连接的?“一次性加载”还是“逐行”进行?您的作业是调用子作业,还是由父作业调用,涉及多少层次的嵌套作业?子作业是否在单独的 JVM 中运行?如果编写 ESB 作业,您知道正在创建多少路由吗?您是否使用并行化(见下文)技术?好吧,这些问题您是否考虑过?有吗?我打赌没有 …

默认设置旨在为可配置的设置提供基本值。作业具有若干设置,包括内存的分配。但默认值并非一定正确,事实上也可能存在错误。您的“用例作业设计”、“操作生态系统”和实时 JVM 线程计数决定了使用的内存量,需要对此进行管理。

 

 

您可以在项目级别或者针对特定作业指定 JVM 内存设置(如上所述):

首选项 > Talend > 运行

正确处理很重要,否则会产生严重后果。内存管理常常被忽视,但是作为一个团队,无论是在开发还是在操作方面,都应当详细记录相应的指南并切实遵循。~ 您终于想阅读上一篇博文了吗st

动态 SQL 语法

许多数据库输入组件需要在其“基本设置”选项卡中包含正确的 SQL 语法。当然,可以直接在 tMyDBInput 组件中输入语法,这么做同样可行;但也要考虑相应的要求,如果在运行时需要根据作业(或其父作业)控制下的某些缓解逻辑来动态地构建复杂的 SQL 查询,可以通过相当直接的方法来解决这个问题。为 SQL 查询的基本结构创建“上下文变量”,到达 tMyDBInput 组件之前在作业流中进行设置,然后使用上下文变量代替硬编码查询。

例如,我在“引用”项目存储库中开发了“上下文组”,称之为“SystemVARS”,其中包含各种有用且可重用的变量。对于动态 SQL 范式,我将以下“字符串”变量定义为初始化为“null”:

 

 

根据需要在 tJava 组件中设置这些变量,然后将它们一并拼接到 tMyDB Input 查询字段中,如下所示:

“选择” + Context.sqlCOLUMNS + Context.sqlFROM + Context.sqlWHERE

请注意,变量值末尾始终包含一个“空格”,以便形成干净的串联。在需要进一步控制的位置,我也利用了“sqlSYNTAX”变量,并有条件地控制串联 SQL 语法子句的方式,然后只是简单地直接将 Context.sqlSYNTAX 放到 tMyDBInput 查询字段中。搞定!从数据库主机角度来看,这并非动态 SQL,但这是针对您的作业动态生成的 SQL!

综上所述,记录这条指导原则,以便每个人都能遵循相同的处理方式。

Parallelization option

Talend 提供几种支持代码并行化的机制。正确、高效地使用这些机制,并认真考虑对 CPU 核心和 RAM 利用率的潜在影响,就能创建高性能作业设计模式。我们来看选项堆栈:

  • 执行计划 - 可将多项作业/任务配置为从 TAC 并行运行
  • 多个作业流 - 单个作业中启动多个数据流,并共用相同的线程;当它们之间不存在依赖关系时,这就可能是适用于罕见用例场景的技巧,我一般避免这么做,而更倾向于创建单独的作业
  • /子作业 - 使用 tRunJob 组件调用子作业时,您可以选中使用独立进程运行子作业复选框,以建立单独的 JVM /线程来运行子作业;虽然这并非完全意义上的并行化
  • 组件- The tParallelize 组件链接多个数据流以供执行;tPartitionertDepartitionertCollector  tRecollector 组件提供对数据流的并行线程数的直接控制
  • 数据库组件 - 大多数数据库输入/输出组件提供高级设置,以在特定 SQL 语句上启用并行化线程计数;这些可以高效进行,但设置数字过高可能会适得其反;设为 2-5 是最佳做法

可将所有这些并行化方法相互结合使用,按原样嵌套(但建议谨慎行之);应了解您的内存利用率堆栈。要非常清楚作业设计模式的执行流程。请注意,这些并行化选项仅作为高级功能出现在 Talend 平台产品。从文档中排除并行化指南:请务必避免!

成功 Talend 作业的秘诀

希望这些作业设计模式最佳实践有助于您想出创建 Talend 作业的最佳方式。从根本上来说,构建成功的作业有赖于指南、纪律性和一致性。只需制定决策,然后遵循即可。在我们将代码绘制到数据/工作流程画布上时,请谨记:

行动是通向所有成功的基本要诀!。”- 巴勃罗·毕加索

最后,我准备了一份“宜与忌”准则清单,其中包含我认为是构建成功的 Talend 作业所需的秘诀:

  • - 宜同时使用 tPreJob和 tPostJob 组件
  • - 避免组件分类过密,建议在画布上分散排列
  • - 合理布置代码,自上而下、从左至右
  • - 初次st编写代码时不必急于求成
  • - 明确主作业循环控制退出点
  • - 不可忽略错误处理技巧
  • - 广泛而明智地Use context groups (DEV/QA/UAT/PROD)
  • - 请勿创建大量单一作业布局
  • - 创建原子作业模块
  • - 化繁为简,避免复杂
  • - 宜随时使用通用架构(值得商榷的例外是单列架构)
  • - 切勿忘记to name the object
  • - 视情况使用小作业(可能只有少数情况)
  • - 不要过度使用 tJavaFlex 组件;tJavatJavaRow 可能足矣
  • - 完成后生成/发布项目文档 When Done
  • - 不要跳过运行时内存堆设置步骤

结语

咻! ~ 感觉如何,是否满足?希望您仍然意犹未尽,因为后续我计划就这个系列做进一步讲解,再介绍一些“示范用例”。今天的博文

丰富了之前的基础理论,并引入了更高一级的概念,敬请您予以考量,希望对您有用。以上仅为抛砖引玉,也欢迎大家畅所欲言,在评论中谈谈自己遵循的一些最佳做法。期待下次再会。

相关资源

Talend Open Studio for Data Integration 简介

提到的产品

Talend 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 *