Informatica性能调优：逻辑处理选Source Qualifier还是转换组件？

没有非黑即白的标准答案，核心是结合数据源类型、节点负载、逻辑复杂度选方案，以下是实际项目中验证过的实操规则：

优先放在Source Qualifier（SQ）中实现的场景 #

SQ的本质是将逻辑下推到源数据库执行，核心优势是能利用数据库原生的优化能力、从源头减少传输到Informatica服务端的数据量，以下场景优先选SQ：

• 同构关系型源的多表关联：如果所有关联表都在同一个数据库实例内，直接在SQ中写关联SQL，比把全量表数据拉到Informatica用Joiner组件关联性能高几个量级。数据库可以直接利用索引、内置的连接优化算法完成匹配，省去了跨网络传输大量原始数据、在Informatica端构建连接缓存的开销。
• 可命中索引的条件过滤：这是投入产出比最高的性能优化手段。所有能在源端完成的where过滤逻辑，全部写在SQ里，让数据库直接把不符合条件的数据筛掉，不要把全量数据拉到Informatica后再用Filter/Router组件过滤，避免无意义的网络传输和内存占用。
• 简单行级计算、单源原生聚合：比如单价*数量算金额、字符串截取/替换这类数据库原生支持的简单计算，或是带索引支撑的单表group by聚合（sum/count/max等），放在SQ里直接返回计算后的结果集，比传输全量明细数据到Informatica再用Expression、Aggregator计算效率更高。

优先使用Informatica转换组件实现的场景 #

不要为了追求性能硬把所有逻辑塞到SQ里，以下场景用原生转换组件反而更合理：

• 异构数据源的加工关联：如果源数据来自不同类型的存储（比如一部分是Oracle表、一部分是CSV文件、一部分是接口返回数据），SQ本身不支持跨异构源的SQL编写，只能用Joiner、Lookup组件完成关联。
• 依赖Informatica平台能力的逻辑：比如需要调用Informatica自定义函数、使用工作流/会话参数做动态逻辑判断、做增量数据的字段比对、数据脱敏这类平台特有能力，SQ里无法实现，必须用Expression、Router等组件完成。
• 源库负载过高、重计算逻辑：如果连接的是线上业务库，本身CPU、IO负载已经很高，把重型计算、复杂聚合下推到源库会直接影响业务正常运行，这时候应该把逻辑拉到专用的ETL服务器上，通过转换组件执行，避免抢占业务资源。另外如果是多层嵌套聚合、跨行复杂计算（比如累计值、动态窗口移动平均），硬写在SQ里会形成嵌套数层的慢SQL，调试、优化成本极高，用Aggregator等组件配合排序输入、缓存调优，性能和可控性反而更好。
• 高可维护性要求的复杂逻辑：如果业务规则非常复杂，十几层嵌套的SQL写在SQ里后续修改、排错极其困难，拆成职责单一的转换组件，开发调试时可以直接查看每个组件的中间结果，排错效率提升非常明显，这点性能损失在非极端海量数据场景下完全可以接受。

通用优化优先级原则 #

不用纠结“必须用哪种方式”，按下面的优先级判断基本不会出大问题：

1. 第一优先级永远是减少从源端拉取的数据量，能在SQ里过滤的无效数据绝对不传到Informatica端。
2. 同构源、源库负载充足的前提下，简单关联、计算、聚合优先下推到SQ执行。
3. 异构源、依赖平台能力、源库资源紧张、逻辑过于复杂的场景，用对应转换组件实现，同时做好组件级调优：比如Joiner用小表做构建缓存的主表、Aggregator开启排序输入提升聚合效率、Expression中把重复计算的逻辑抽成变量端口避免重复运算。

避坑提醒：不要盲目信“下推数据库一定最快”或者“组件化最灵活”的极端说法，性能优化的核心是平衡数据传输开销、各节点（源库、Informatica服务）的算力负载，适合当前架构的方案才是最优的。

内容的提问来源于stack exchange，提问作者Tan Duong