Netezza 部分 转换更多内容，而不是仅转换数据

Netezza 中的大规模处理：第 2
部分
转换更多内容，而不是仅转换数据
英文原文：
http://ibmdatamag.com/2012/08/large-scale-processing-in-n
etezza-part-2/
作者：David Birmingham | 发布时间：2012 年 8 月 3 日 | 113 次阅读
打印
PDF
在本文的第 1 部分中，我们探讨了 IBM® Netezza® 平台如何利用简单的 SQL insert/select
语句处理超大规模的复杂数据。
许多决定将逻辑从 ETL 机转移到 Netezza 的企业都会受困于一个简单的问题：我们能否扩展
这种方法？简而言之，SQL insert/select 语句有一些后勤工作，我们必须合理加以利用，以形
成一种可靠的方法基础。请考虑以下查询：
Insert into EMPLOYEE (EMP_ID, EMP_FNAME, EMP_LNAME, EMP_START_DATE) select
ID, FirstName, LastName, St_Date from OldEmployees;
看起来很简单，或许应该说有些过于简单。那么再请看下面这条查询：
Insert into EMPLOYEE select ID, FirstName, LastName, St_Date from OldEmployees;
请注意，在上面的查询中，insert 词组是隐式的。或许有些读者已经发现了这里存在的重大危险。
如果后续我们在这些内容中间添加一个列，则会造成其他列发生偏移，使之无法与目标列正确对
齐。有些用户表示，至少有一个目标列会出现问题，但事实是怎样的？我曾经遇到过未能对齐的
查询仍然运行数天乃至数月之后才被发现的情况。这些查询只是碰巧与可接受的目标数据类型相
符，但内容完全是错误的。我们必须掌控这样的问题。
如果是包含 150 列的事实表，情况会怎样？insert/select 子句会立即失去控制。如果我们需要
添加或删除列，或者需要根据数据模型的更改来更新查询，情况又会怎样？这些情况会造成查询
功能冻结，导致解决方案脆弱不堪。细微的变化可能就会导致整个解决方案工作失常。
我们可以采用的最好方法就是将目标列与源规则（将填充目标列的 SQL Select 词组的元素）
保持一致：1
EMP_ID
ID
EMP_FNAME
FirstName
EMP_LNAME
LastName
EMP_START_DATE
St_Date
我们可以对上面这样的模板加以扩展，限制数据库机。目标列始终与源保持一致/select 列永远
不会发生偏移。这听起来是否就像是采用某种更为先进的方法，而非仅仅依靠 ETL 工具？不要
被愚弄了。一切的目的就是简化和降低 SQL 语句生成后勤工作的复杂度。这种结构有助维护，
而且无需艰难的影响审查。它能极为轻松地扫描简单的工具，并将其内容与目录内容进行对比，
以查找、应用或直接报告更改。但请务必牢记，只要数据模型发生更改，其所有列都会受到影响
。在这种情况下，我们主要关注的是异常，数据模型中 90% 以上的协调工作可能都自动完成。
1
因此，新数据模型的协调工作会变得敏捷起来——或者可以说是极其敏捷。
拥有这种掌控查询生成的力量之后，我们就能自由处理大量查询，而不会失去对后勤的控制力。
这种方法能否扩展？答案是肯定的，而且已经得到了实现。这种模板更高级的形式是框架引擎的
推进动力 2，我们常常会看到数十个此类查询按照受控制的次序加以执行，致力于实现某种功能
目标，这种方法简化了维护和重用。
MIMD 与 SIMD 之间在后勤方面的主要差异是：使用 MIMD 时，我们必须使用更少、更复杂
的 SQL 语句，这些语句必然是串行化的，因为它们会使硬件饱和。SIMD 鼓励我们使用更多、
更简单的 SQL 语句，同时并行运行这些语句，因为机器将迅速分派语句。因此 SIMD 查询能
够以比同等的 MIMD 查询更快的速度完成。
通用 MIMD 平台从最初起便有着较高的（也是永久性的）复杂性，专门构建的 SIMD 平台则
允许我们从简单的地方入手，并始终保持简单性。简单就意味着一切易于维护、扩展和排除故障，
这奠定了贯穿系统整个使用寿命的敏捷性基础。
参考资料
1
Compleat Netezza，Copyright © 2012 VMII ISBN: 978-1-4610-9574-3。经允许方可摘录。
2
Netezza Data Integration Framework，Copyright © 2007-2012 Brightlight Consulting。保留所
有权利。
无相关文章