您希望运行作业吗？是否考虑过作业的内存需求？数据流是否要在tMap中处理数百万行和/或众多列和/或多项查找？您是否考虑过当作业在“作业服务器”上运行时，其他作业可能也在同时运行？有没有想过“作业服务器”有多少核心/运存？您是如何配置tMap连接的？“一次性加载”还是“逐行”进行？您的作业是调用子作业，还是由父作业调用，涉及多少级嵌套作业？子作业是否在单独的JVM中运行？如果编写ESB作业，您知道正在创建多少条路由吗？您是否使用并行化（见下文）技术？好吧...这些问题您是否考虑过？有吗？我打赌没有 …
默认设置旨在为可配置的设置提供基本值。作业具有若干设置，包括内存的分配。但默认值并非一定正确，事实上也可能存在错误。您的“用例作业设计”、“操作生态系统”和“实时JVM线程计数”决定了使用的内存量，需要对此进行管理。
您可以在项目一级或者特定作业中指定JVM内存设置（如上所述）：
首选项 > Talend > 运行
做到这一点很重要，否则会产生严重后果。内存管理常常被忽视，但是作为一个团队，无论是在开发还是在操作方面，都应当详细记录相应的指导原则并切实遵循。
动态SQL语法
许多数据库输入组件需要在其“基本设置”选项卡中包含正确的SQL语法。当然，可以直接在tMyDBInput组件中输入语法，这么做同样可行；但也要考虑相应的要求，如果在运行时需要根据作业（或其父作业）控制下的某些缓解逻辑来动态地构建复杂SQL查询，可以通过相当直接的方法来解决这个问题。为SQL查询的基本结构创建“上下文变量”，到达tMyDBInput组件之前在工作流程中进行设置，然后使用上下文变量代替硬编码查询。
例如，我在“引用”项目存储库中开发了“上下文组”，称之为“SystemVARS”，其中包含各种有用且可重用的变量。对于动态SQL范式，我定义以下初始化为“null”的“字符串”变量：
根据需要在tJava组件中设置这些变量，然后将它们一并拼接到tMyDBInput查询字段中，如下所示：
“选择” + Context.sqlCOLUMNS + Context.sqlFROM + Context.sqlWHERE
请注意，变量值末尾始终包含一个“空格”，以便形成干净的串联。在需要进一步控制的位置，我也利用了“sqlSYNTAX”变量，并有条件地控制串联SQL语法子句的方式，然后直接将Context.sqlSYNTAX放到tMyDBInput查询字段中。大功告成。从数据库主机角度来看，这并非动态SQL，但这是针对您的作业动态生成的SQL！
综上所述，记录这条指导原则，以便每个人都能遵循相同的处理方式。
并行化选项
Talend提供几种支持代码并行化的机制。正确、高效地使用这些机制，并认真考虑对CPU核心和RAM利用率的潜在影响，就能创建高性能作业设计模式。我们来看选项堆栈：
执行计划 - 可将多个作业/任务配置为从TAC并行运行
多个工作流程 - 可在共用相同线程的单个作业中启动多个数据流；当它们之间不存在依赖关系时，这可能是罕见用例场景的技巧，我一般避免这么做，而更倾向于创建单独的作业
父/子作业 - 使用tRunJob组件调用子作业时，您可以选中“使用独立进程运行子作业”复选框，以建立单独的JVM堆/线程来运行子作业；虽然这并非完全意义上的并行化
组件 - tParallelize组件链接多个数据流以供执行；tPartitioner、tDepartitioner、tCollector和tRecollector组件提供对数据流的并行线程数的直接控制
数据库组件 - 大多数数据库输入/输出组件提供高级设置，以在特定SQL语句上启用并行化线程计数；这些可以高效进行，但设置数字过高可能会适得其反；设为2-5是最佳做法
可将所有这些并行化方法相互结合使用，按原样嵌套（但建议谨慎行之）；应了解您的内存利用率堆栈。要非常清楚作业设计模式的执行流程。请注意，这些并行化选项仅作为高级功能出现在Talend平台产品。从文档中排除并行化指导原则：请务必避免！
成功Talend作业的秘诀