Netezza 部分 从

Netezza 中的大规模处理：第 1
部分
从 ETL 转换为 ELT
英文原文：
http://ibmdatamag.com/2012/08/large-scale-processing-in-n
etezza-part-1/
作者：David Birmingham | 发布时间：2012 年 8 月 3 日 | 34 次阅读
打印
PDF
CIO：为什么超级 [商业级 RDBMS] 系统后劲不足？我们不是刚刚升过级吗？
经理：是的，但是升级没有被接受。
CIO：没有被接受？听起来就像是医生移植器官一样。难道说 CPU 出现了排异反应？（笑）
经理：（冷静地）不，只是没有被用户接受。系统速度还是太慢了。
CIO：我们已经在硬件设备上投入了 [X] 百万美元，它最好能达到目标，否则我恐怕只能将它拆
成了零件，连同您的首席架构师一起请出公司！
经理：我没法解释。白皮书里说„„（看着犹如天书一般难以理解的商业文章，无法理清头绪）
CIO：我也浏览了一遍那本手册。上周您手下的所有员工都穿着印有这家供应商徽标的 T 恤，
我注意到他们现在又都换回了普通的马球衫。是不是发生了什么事情？
经理：我们无法达到预期的数字。我们正在调优。
CIO：调优？可是系统正在严重恶化。这可不是所谓的“调优”。
经理：（声音转小）是，我知道。（口中念念有词地缓缓走开）
把一切都归咎于经理是不公平的。把不适合具体工作的硬件强加给经理，不考虑硬件最初的设计
目标与工作根本不符，却希望得到硬件无法实现的成果？
在数据库以外的地方，“批量数据处理”只有一个含义：提取、转换、加载 (ETL)，而可供选择
的工具有几十种。这些选择将会迅速升级，造成多米诺效应，不但要求必要的基础架构（如 ETL
机），还要求了解工具、了解如何应用工具的人员。可伸缩性不仅仅与硬件有关，还与后勤密切
相关；目标是在不聘用大量开发人员来提供支持的前提下开发更多的功能。但如果不想聘用工具
专家又会怎样？如果 UNIX 基础知识以及出色处理 SQL 和企业自有信息的能力是大规模成功
数据处理环境的核心技能集，又会怎样？
数据库机内的批量数据处理只有一种形式：使用 SQL 的 insert/select 语句，通常在中间数据
库表和/或持久数据库表（即 ELT）之间执行。除了 SQL 为支持这种形式而生成的机制之外（不
需要为业务逻辑手动编写 SQL 语句！），我们还应该深入探索硬件方面，确定这种方法对于大
规模数据是否可行。
通用平台是“水平的”，也就是说 CPU 与磁盘驱动器物理分离，通过基板连接，共享硬件级
的一切资源。复制就是从磁盘获取大量数据，经过基板，通过 CPU 和具有表的逻辑表示形式
的软件，最终传递到基板，再返回磁盘。在这样的数据流中，数据可以在（饱和的）基板上来回
传递。这必然会造成庞大、臃肿、单体式的查询，因为我们只能在获得数据之后处理数据。可以
说，这种多指令多数据 (MIMD) 模型无法为了实现批量处理而进行伸缩。
相比之下，IBM® Netezza® 平台是使用精心优化的商业级零件专门制作的专有组装平台，其中
的 CPU 与一个磁盘驱动器配对（无共享硬件）。创建表时，从逻辑上来说，只存在一个表，
但从物理上来说，这个表的各个部分可以分别处于各 CPU/磁盘组合当中，其中 10 个这种类型
的 CPU/磁盘对可能会将一个包含 1,000 条记录的表分为 10 个位置存储，每个位置存储 100
条记录。但一次查询即可同时查询所有这些 CPU，也就是说，并行移动 10 个各包含 100 条
记录的组，所需的时间是将全部 1,000 条记录作为单独一个数据块进行移动时的十分之一。这
种模型称为单指令多数据 (SIMD) 模型。SIMD 能够为实现批量处理而进行大幅扩展，因此配
备 90 枚或更多 CPU 的 TwinFin® 能够在极短的时间内处理数十亿条记录，远胜过能力相似
的通用竞争产品。
在本系列的 第 2 部分 文章中，我们会更加深入地探讨这种模型给数据仓库处理流程带来的显
著变化。
相关文章
1. Netezza 中的大规模处理：第 2 部分
2. Netezza 迁移技巧，第 1 部分
3. Netezza 迁移技巧，第 2 部分
4. 利用 IBM DB2 for z/OS 执行超高速分析
5. 带有高级分析功能的 IBM Netezza 数据仓库设备的总体经济效益