全新大数据 佳实践

Kimball 集团白皮书

作者：Ralph Kimball

新涌现出的大数据 佳实践 1

大数据革命早已开始。大家所关心的并不是数据纯粹的大小。更确切地说，大数据还

与我们所熟知的文本和数值数据相去甚远，20 多年来，我们一直把这些数据存储在关

系数据库中并使用 SQL 分析它们。大数据的格式和内容很广，涵盖范围从非结构化

的自由文本一直到高度结构化的关系、矢量、矩阵、图像和名称-值对。

对系统的第一个巨大冲击在于，标准的关系数据库和 SQL 根本就不能存储或处理大数

据，并且正在接近基本能力和扩展的极限。不仅其数据格式超出了关系数据库的范围，

而且很多处理需要迭代逻辑、复杂分支和特殊的分析算法。SQL 是一种描述性语言，具

有强大却又固定的语法。大数据一般需要过程式语言以及任意新逻辑编程的能力。

对系统的第二个巨大冲击是摒弃了基于简单过滤和聚合进行分析的切片和切块报告。

报告、仪表盘和临时查询始终都非常重要，但利用大数据的 好方式是通过对海量未

过滤数据集进行梳理，此类数据集由历史和实时数据合并而成。

对系统的第三个巨大冲击是人们都认识到，随着延迟缩短、数据的更快交付，

大数据的价值会陡然升高。性能十倍百倍的提高造就了本质上不同的各种分析机会，

而这些分析机会经常会转化为更高的营收和利润。

所有这些都促成了一个生机勃勃的由技术驱动的市场，这个市场两条主要的发展思

路：扩展关系数据库和 Hadoop。我在 Informatica 赞助的白皮书中对这两种架构作

过深入的阐述。这两种架构都力求解决上面所列的大数据挑战。

大数据市场远未成熟，但是我们现在已经积累了数年的经验，有很多针对大数据的

佳实践。本白皮书搜罗了这些 佳实践，并在追本溯源式的引经据典和针对单个工

具、不厌其烦的技术性繁枝末节之间，开辟一条中间路线。

重要的是要认识到，我们有一套为基于关系的企业数据仓库 (EDW) 开发的 佳实

践，这套 佳实践行之有效，大数据工作应该对此加以利用。我们将它们简单列出：

由业务需求驱动 EDW 的输入数据源选择

对用户界面简单性和性能的不懈重视

下列 EDW 佳实践尤其与大数据有关：

多维思考：将世界划分为维度和事实

将单独的数据源与一致性的维度集成

用渐变维度 (SCD) 跟踪时变

通过持久的代理键锁定所有维度

在本文中我们将大数据 佳实践分为四大类：数据管理、数据体系架构、数据建模和

数据治理。

新涌现出的大数据 佳实践 2

大数据管理 佳实践

下列 佳实践适用于大数据环境的整体管理。

围绕分析而不是临时查询或标准报告来构造大数据。从原始源到分析师的屏幕，数据通

路中的每一步必须支持复杂分析路线，这种分析路线或者作为用户定义函数 (UDF)，

或者通过一种可为每种类型的分析编程的元数据驱动开发环境实施。这包括加载器、清

洗器、集成器、用户界面和 终的商业智能工具。这种 佳实践并不建议废弃现有的环

境，而是将其扩展来支持新的分析需求。见下文中的体系架构 佳实践部分。

现在不要尝试建立遗留的大数据环境。当前的大数据环境变化迅速，因此还不是考虑构建

长久基础的时候。相反，要规划方方面面颠覆性的变化: 新的数据类型、竞争性的挑

战、编程方法、硬件、网络技术和数以百计的全新大数据提供商所提供的服务。

在可预见的将来，需要保持几种实施方法之间的均衡，其中包括 Hadoop、传统的网

格计算、RDBMS 的下推优化、内部计算、云计算甚至大型机。这些方法中没有一种将

在这场长跑中成为唯一的赢家。平台即服务 (PaaS) 提供商提供了引人注目的选项，

可以帮助您组成一套兼容的工具。与此类似，很多系统体系结构和编程可在具体部署

选择之上的层面上指定，这正是元数据驱动开发环境的鲜明优势。

示例：在 Hadoop 环境中使用 HCatalog 提供一个具体存储位置和数据格式之

上的抽象层。举例来说，这就允许 Pig 脚本在位置和格式变更时保持不变。

示例：将 Hadoop 看成一个用于很多形式 ETL 处理的灵活、通用的环境，目标

是向大数据加入足够的结构和上下文，使其能够加载到 RDBMS 中。Hadoop

中相同的数据可使用各种各样的语言编写的 Hive、Pig、HBase 和

MapReduce 代码访问和转换，访问和转换甚至同步完成。

要紧的是，这需要灵活性。假定您要在两年内重新编程并重新移植所有的大数据应

用程序，请选择可进行重新编程和移植的方法，并考虑使用一种元数据驱动的无代码

开发环境，以提高生产率，并与底层技术变化隔离。

新涌现出的大数据 佳实践 3

采用沙盒孤岛并构建产品化沙盒结果的实践。允许数据科学家使用他们偏好的语言和

编程环境构造数据实验和原型。然后，在概念得到证明后，由“IT 接管团队”系统性

地改编程序和/或配置这些实施。

示例：您进行客户分析编程的生产环境可能是 PostgreSQL 中的 MatLab 或

Teradata RDBMS 中的 SAS，但是您的数据科学家可能用各种各样他们偏好的

语言和体系架构来构建概念证据。先见之处在于：IT 部门必须一反常态地不去

计较数据科学家使用的技术，并且要时刻准备着使用一套长远来看能够得到支

持的标准技术，来重新实施数据科学家的工作。

示例：您的沙盒开发环境可能是 ETL 转换和直接访问 Hadoop 的 R 代码的组

合，但是由 Informatica PowerCenter 控制。然后，当数据科学家准备好移交概

念证据时，大部分逻辑可以在 PowerCenter 下立即重新部署，在网格计算环境

中运行，这是一种可扩展、高度可用并且安全的环境。

先从简单大数据应用程序试起：备份和存档。在准备开始大数据程序时，在寻找有价

值同时风险不高的业务用例时，以及在汇集必备的大数据技能时，可以考虑使用

Hadoop 作为一种低成本、灵活的备份和存档技术。Hadoop 可存储和检索所有格式的

数据，范围从完全非结构化到高度结构化的专用格式。这种方法还让您能够解决“日

落”问题，其中原来的应用程序在不久的将来可能不可用 (可能因为许可限制)，但是

您可以将这些应用程序内的数据转储为自己的记录格式。 后请记住，即使是

Hadoop 也会消耗资源和成本——所以只要用 Hadoop 存储数据时，都应该事先考虑

数据保留，这样 HDFS 文件夹和数据集在保留期满时就能被清除或很方便地以更低存

储成本在 HDFS 之外存档。

新涌现出的大数据 佳实践 4

大数据体系架构 佳实践

下列 佳实践影响大数据环境的总体结构和组织。

用延迟依次增加的多个缓存规划逻辑上的“数据高速公路”。物理上仅实施适应您环

境的缓存。数据高速公路 多可以有五个数据延迟依次增加的缓存，各有其独特的分

析优势和不足：

* 原始源应用程序：信用卡诈骗探测、包括网络稳定性和网络攻击探测在内的瞬时

复杂事件处理 (CEP)。

* 实时应用程序：网页广告选择、个性化降价促销，网络游戏监视、各种形式的预

测和主动监控。

* 业务活动应用程序：向用户推送的低延迟 KPI 仪表盘、故障单跟踪、过程完成跟

踪、“融合”CEP 报告、客户服务门户和仪表盘以及移动销售应用程序。

* 一线应用程序：战术报告、促销跟踪、基于社交媒体动向的中途修正。“一线”

指的是高级经理审核企业24小时内所发生的主要事务的通常实践。

* EDW 和长时间序列应用程序：所有形式的报告、临时查询、历史分析、主数据管

理、大规模的时间动态和马尔可夫链分析。

存在于给定环境中的每种缓存都实际存在，并与其他的缓存有明显的区别。数据通过

ETL 进程从原始源开始沿这条高速公路一路向下。从原始源到各中间缓存有多种路

径。例如，数据可能进入实时缓存来驱动零延迟式用户界面，但同时被直接提取到看

起来像是典型操作型数据存储 (ODS) 的日常一线缓存。随后，来自这个 ODS 的数据

可以输入到 EDW。数据同样还会沿高速公路反方向流动。见下面的“实施回流”。

沿这条高速公路传输的很多数据必须保持非关系型格式，其范围从非结构化文本一直

到复杂的多结构化数据，如图像、数组、图形、链接、矩阵和名称-值对集。

使用大数据分析作为“事实提取器”，将数据移动到下一个缓存。例如，对非结构化

推文的分析可以产生一整套数值和趋势型的情绪测量值，包括语音共享、观众参与、

对话范围、主动倡导、倡导的影响、宣传的影响、解决率、解决时间、满意度评分、

主题趋势、情感比和思想影响。同样还有 Splunk，一种为很多形式的非结构化机器数

据标引以及从中提取特征的技术；Kapow，一种从博客、论坛、网站和门户网提取多

原始源 (瞬时) 实时缓存

(数秒)

业务活

动缓存

(数分钟)

一线缓存

(24 小时)

EDW 和长时间序列

(每日、定期、每年)

新涌现出的大数据 佳实践 5

种形式基于 web 的数据的技术；当然还有 Informatica 的 HParser，这种技术可以从

非结构化文本文件、多结构化 XML 文件和 web 日志以及市场数据、SWIFT、FIX、

CDR、HL7、HIPAA 等等各种工业标准结构中提取事实和维度。

使用大数据集成构建一个全面的生态系统，将常规结构化 RDMS 数据、电子邮件和内

部以业务为导向的社交网络集成在一起。大数据透露出的强有力信息之一是能够集成

模式各不相同的数据源。我们正在从社交网络、移动设备和自动警报流程这样的新数

据生成渠道获取数据流。想象一下，一家大型金融机构正在应对数以百万计的账户、

以千万计的相关纸质文件，以及数以千计的组织内专业人员 (同时又是该领域中的合作

方或客户)。现在建立一个所有信任方的安全“社交网络”，在开展业务的同时进行沟

通。这种沟通很多都非常重要，应该以可查询的方式加以保存。在 Hadoop 中捕捉所

有这种信息，确定其维度 (见下面的建模 佳实践)，在业务过程中加以使用，然后将

其备份和存档。

作出规划让数据质量沿数据高速公路越来越佳。这是典型的延迟和数据质量的取舍问

题。分析师和业务用户必须接受这个现实，那就是延迟非常低 (即瞬时) 的数据不可避

免的会“脏”，这是因为在非常短的时间间隔中能完成的清洗和诊断有一定限度。单

独字段内容的测试和修正可以在 快的数据传输速度下进行。多个字段中以及数据源

之间结构型关系的测试和修正必定更慢。测试和修正涉及复杂的业务规则，其范围从

瞬时 (如一组日期是否按特定顺序) 到花去任意长的时间 (如等着看异常事件的阈值是

否已被超过)。 后，更慢的 ETL 进程，输入日常一线缓存的进程通常建立在从根本上

来说更完整的数据上，例如将不完整的交易集和拒付交易删除。在这些情况下，瞬时

数据源根本就没有正确信息。

在尽可能早的接触点应用过滤、清洗、修整、遵从、匹配、合并和诊断。这是上述各项

佳实践的必然结果。数据高速公路上的每一步都提供更多的时间增加数据的价值。过

滤、清洗和修整减少了传输到下一个缓存的数据量，消除了无关或受损数据。说句老实

话，有一种流派就主张仅在分析运行时间应用清洗逻辑，因为清洗可能删除“有趣的异

常值”。遵从则采取积极步骤将高度管理下的企业属性放入客户、产品和日期这样的主

要实体。这些遵从属性的存在允许了跨越不同应用程序域的高价值合并。这个步骤简化

的含义就是“集成！”诊断允许将很多有趣的属性加入数据，包括特殊的自信度标签和

代表数据挖掘专业人员识别出的行为集群的文本标识符。数据发现和探查有助于识别数

据域、关系、搜索的元数据标签、敏感数据以及数据质量问题等。

新涌现出的大数据 佳实践 6

实施回流，尤其是从 EDW 回流到数据高速公路上更早的缓存。EDW 中的客户、产品

和日期等高度管理下的主维度应反过来与较早的缓存连接在一起。理想情况下，需要

的只是所有缓存中这些实体的唯一持久键。这里的必然结果就是，从一个缓存到下一

个的每个 ETL 步骤中，头等大事就是用唯一的持久键替换特异性的专用键，这样每个

缓存中的分析可以只需通过连接唯一的持久键就对丰富的上游内容加以利用。甚至能

够当原始源数据传输到实时缓存时不到一秒的时间内实施这种 ETL 步骤？

维度数据不是高速公路上向源方向回传的唯一数据。历史摘要和复杂数据发掘结果等

在事实表中派生的数据可以打包成简单的指标或总数——然后传输到数据高速公路上

更早的缓存中。 后，有用的键或码等参考链接可被嵌入低延迟数据缓存中，以便允

许分析师通过单击链接到其他相关数据。

在所选的数据流中执行流数据分析。对低延迟数据的一个有趣的角度是需要在数据流

入但是数据传输进程可能远没有 终结束前开始数据上的认真分析。人们对流分析系

统有很大的兴趣，该系统允许类似 SQL 的查询在数据流入系统时对其进行处理。在一

些使用案例中，当流查询的结果超过阈值时，分析可能中止，不会让作业运行到底。

被称为连续查询语言 (CQL) 的一项学术工作在定义流数据处理要求方面取得了令人瞩

目的进展，其中包括流数据上动态移动时间窗口的巧妙语义。在加载程序中为

RDBMS 和 HDFS 部署的数据集寻找 CQL 语言扩展和流数据查询功能。理想的实施

会使数据以每秒吉字节加载时的流数据分析得以实现。

在可扩展性上设置长远限制以避免“边界崩溃”。在计算机编程早期，计算机的硬盘

和物理内存都小的可怜，边界崩溃司空见惯，是应用程序开发的克星。应用程序用完

磁盘空间或物理内存时，开发人员必须求助于精心设计的手段，这些手段通常需要大

量与应用程序主要内容无关的编程工作。对于一般的数据库应用程序来说或多或少都

已经消除了边界崩溃，但是大数据又让这个问题浮出水面。Hadoop 是一种使编程可扩

展性问题大大降低的体系架构，这是因为人们在大多数情况下可以无限制添加商品硬

件。当然，即使是商品硬件也必须进行配置、插入并且还要有高带宽的网络连接。教

训就是规划要非常超前，为巨大的容量和吞吐量留足空间。

在公共云实施大数据原型开发，然后转移到私有云。公共云的优势在于其可以即时提

供和扩展。这样的例子包括 Amazon EMR 和 Google BigQuery。对于有的案例，其

数据敏感性允许原型开发快进快出，在这种情况下这样做可能非常有效。只是要记住

不要在程序员回家过周末的时候还把海量数据集留在网上的公共云提供商那里！但是

请记住，在某些情况下，在试图通过机架感知 MapReduce 进程对数据局部性加以利

用时，可能无法使用公共云服务，因为它们可能不会提供你所需要的数据存储控制。

新涌现出的大数据 佳实践 7

寻求和期待 10 倍到 100 倍的渐进性能提升，以非常快的速度确定分析范式的转变。

大数据市场的开放性催生了数以百计针对特定分析类型的专用紧密编码解决方案。这

是一个巨大的福音，也是一个魔咒。一旦不被大供应商的 RDBMS 优化工具和内部循

环所左右，聪明的开发人员就可以实施真正百倍高于标准技术的局部解决方案。例

如，在出了名的“大合并”问题上已经有了一些令人印象深刻的进展，在这个问题中

要将一亿行的维表加入到一万亿行的事实表中。例如雅虎处理海量数据集上稀疏连接

的方法以及谷歌的 Dremel 和 BigQuery 项目。魔咒在于这些单独的局部解决方案还

游离在统一的单一体系架构之外。

大数据一个非常明显的主题就是数据集的可视化。拍字节数据“飞来飞去”需要惊人

的性能!大数据的可视化是一个激动人心的新开发领域，能够分析和发现意想不到的功

能以及进行数据探查。

另一个激动人心的应用领域是没有预聚合的语义缩放，这种应用也提出了巨大性能需

求，其中分析师从高度聚合的层次上走下来，逐步进入非结构化或半结构化数据更详

细的层次，这很像在地图上放大。

这种 佳实践背后的重要一课是，在我们使用和分析大数据的能力上，革命性的进步

将来自于 10 倍到 100 倍的性能提升，我们必须准备好将这些发展加入我们的工具套

件中。

将大数据分析工作量与常规 EDW 分开，以保持 EDW 服务层协议。如果你的大数据

在 Hadoop 中托管，就有可能不会与基于 RDBMS 的常规 EDW 争夺资源。但是要留

心你的大数据分析是否在 EDW 计算机上进行，因为大数据要求向着需要更多计算资

源的方向势不可挡地迅速变化。

利用数据库内分析的独特功能。主要的 RDBMS 参与者都对数据库内分析方面进行了

巨大的投入。一旦你付费将数据加载到关系表中，SQL 可以通过非常强大的方式与分

析扩展相结合。 近的著名数据库内进展包括 IBM 收购 Netezza 和 SPSS、

Teradata 和 Greenplum 嵌入 SAS、Oracle 的 Exadata R Enterprise 和

PostgreSQL 用于编程分析的语法，以及其他具有数据库内循环的任意函数。所有这些

选件使数以百计分析例程的测试库可供使用。一些数据集成平台提供下推优化，利用

数据库内分析作为数据流或 ELT 进程的一部分。

新涌现出的大数据 佳实践 8

大数据的数据建模 佳实践

下列 佳实践影响数据的逻辑和物理结构。

多维思考：将世界划分为维度和事实。业务用户发现，维度的概念非常自然和明显。

不管是什么格式的数据，总是能够找到基本的关联实体，如客户、产品、服务、地点

或时间。在下面的 佳实践中，我们将看到如何通过制定少量规则，将维度用于集成

数据源。但是在我们到达集成终点线之前，必须要识别每个数据源中的维度，并把它

们附加到每个低等级的基本数据观察值上。这种维度化的过程就是大数据分析很好的

一种应用。例如，一句 Twitter 的推文 “哇！真棒！”看起来可能并不包含任何值得

维度化的东西，但是通过一些分析，我们经常可以得到客户 (或市民或患者)、地点、

产品 (或服务或合约或事件)、市场情况、提供商、天气、 队列组 (或人口统计学集

群)、会期、触发前事件、 终结果，不胜枚举。为了始终跟进高速数据流，需要有某

种形式的自动维度化。正如我们在随后的 佳实践中指出的那样，传入的数据应在

早的提取步骤完全维度化。

将单独的数据源与一致性的维度集成。一致性的维度是将孤立的数据源粘合在一起的

胶水，这样它们就可以合并在单一的分析中。一致性的维度可能是来自传统 EDW 世

界 强大的 佳实践，大数据应该加以继承。

一致性维度背后的基本思想是在与孤立数据源相关联的各种版本的维度中存在一个或

多个企业属性 (字段)。例如，企业中每个面向客户的流程都会有一些客户维度的差

异。这些客户维度的差异可能有不同的键、不同的字段定义甚至不同的粒度。但是即

使在不兼容数据的 坏情况下，一个或多个可定义的企业属性都可以被嵌入所有客户

维度变化中。例如，客户人口统计学类别就是一个言之成理的选择。这种描述符可以

附加到几乎每种客户维度上，即使在更高的聚合层次上也是如此。完成了这一项工作

后，就可以通过对不同数据源上单独运行查询后的简单排序-合并进程，跨每个参与数

据源进行这种客户人口统计学类别上的分组分析。 重要的是，将企业属性引入到单

独数据库的步骤可以通过一个渐进、灵活和非破坏性的方式完成，如同我在

Informatica 赞助的白皮书中针对这个主题的详细说明。在一致性维度内容推出时所有

现有分析应用程序将继续运行。

通过持久的代理键锁定所有维度。如果我们在 EDW 世界中有经验教训的话，那就是

不要将客户、产品和时间等重要实体用具体应用程序定义的“自然键”锁定。这些自

然键 终被证明是一个陷阱，是真实世界中的错觉。它们在不同应用程序间互不兼

容，很难管理。每个数据源中的第一个步骤是用企业范围内的持久代理键扩充来自数

据源的自然键。持久意味着没有业务规则能够更改这个键。持久键属于 IT 部门，并不

新涌现出的大数据 佳实践 9

属于数据源。代理意味着键本身仅仅是简单的整数，或者按顺序分配，或者由保证唯

一性的鲁棒哈希算法生成。隔离的代理键没有应用程序内容。它仅仅是一个标识符。

大数据世界充斥着显而易见的维度，它们必须要有持久代理键。在前文中，我们建议

将数据沿数据高速公路反向推回时提到，我们依赖于持久代理键的存在而使这种过程

得以实现。我们还说过，每次从原始数据源进行数据提取的头等大事就是在适当的维

度嵌入持久代理键。

迎接结构化和非结构化数据的集成。大数据极大地扩大了集成的挑战。很多大数据将

永远不会在关系数据库中终结；而是将留在 Hadoop 或网格中。但是我们一旦用一致

性维度和持久代理键武装起来，所有形式的数据都能合并在单一的分析中。例如，医

学研究可能选取一组具有特定人口统计学和健康状态属性的患者，然后将他们的常规

EDW 型数据与图像数据 (照片、x 线、心电图)、自由文本形式的数据 (医生接诊记

录)、社交媒体情绪 (对治疗的看法) 以及队列组联系 (有类似情况的患者)。

在体系架构上讲，这种集成步骤应在查询而非数据加载和构建时进行。执行这种集成

的 灵活方式是通过数据虚拟化，其中的集成数据集看似物理表，但实际上是类似关

系视图的规格，其中的独立数据源在查询时连接在一起。如果没有数据虚拟化， 终

的商业智能层必须完成这种集成步骤。

用渐变维度 (SCD) 跟踪时变。跟踪维度的时变是来自 EDW 世界的一种长期以来备受

推崇的 佳实践。从根本上讲，它兑现了我们所做的准确跟踪历史的承诺。将当前的

客户 (或市民、或患者、或学生) 资料和陈旧的历史相关联是绝不能接受的。 差的情

况下，当前的资料应用到旧历史时会错的离谱。用渐变维度 (SCD) 处理有三种形式。

第一种类型的 SCD 在发生改变时覆盖资料，因此丢失了历史。我们在纠正数据错误时

可能这样做。第二种类型的 SCD 是 常使用的技术，在发生改变时生成一个修订后的

维度记录。第二种类型的 SCD 要求在我们生成新维度记录时保留持久代理键作为将新

旧记录结合在一起的粘合剂，但是我们还必须为维度成员的快照生成一个唯一的主

键。和一致性维度类似，这种流程得到了很广泛的描述和审查。 后是第三种类型的

SCD，这种类型不像其他两种那样常见，其涉及定义了与当前现实共存的“备用现

实”的情况。请参阅我对 SCD 的介绍性文章以及我的著述中大量涉及 SCD 的内容。

但是，就大数据而言，要点是将重要实体正确的当前资料和历史关联在一起，其重要

性正如已在 EDW 世界中加以证明的一样。

要习惯在分析时间前不去声明数据结构。大数据的魅力之一就是在加载到 Hadoop 或

数据网格时推迟声明数据结构。这带来了很多优势。数据结构在加载时可能不清楚。

数据可能有变化多样的内容，用单一的数据结构可能或者没有意义，或者会强迫你修

改数据来适合结构。举例来说，如果能不声明数据结构就将其加载到 Hadoop 中，就

新涌现出的大数据 佳实践 10

可以避免一个资源密集型步骤。 后，不同的分析师可能以不同的方式合理地看待相

同的数据。当然，在某些情况下会需要付出代价，因为未声明结构的数据可能很难或

不可能像在 RDBMS 中那样编索引进行快速访问。但是，大部分大数据分析算法可处

理整个数据集，并不期望数据子集的精确过滤。

这种 佳实践与传统的 RDBMS 方法论相抵触，后者着重强调在加载前对数据进行细

致建模。但是，这并不会导致致命的冲突。对于发往 RDBMS 的数据，从 Hadoop 或

数据网格环境以及从名称-值对结构传输到 RDBMS 命名列可以认为是一个有价值的

ETL 步骤。

围绕名称-值对数据源构建技术。大数据源总是充斥让人惊奇的内容。在很多情况下，

你就像打开了消防水龙头，发现喷涌出来的是意料之外或没有记录的数据内容，无论

如何你必须以每秒吉字节的速度加载。从这个问题脱身的方法就是将这样的数据作为

简单的名称-值对加载。例如，如果申请人披露其金融资产，他们可能会声明一些出乎

意料的东西，例如“珍品邮票 = $10,000”。在名称-值对数据集中，加载将从容进

行，即使你在加载时从来没有见过“珍品邮票”，也不知道该拿它怎么办。当然，这

种做法与前述将声明数据结构推迟到加载时间后的做法协调得很好。

MapReduce 编程框架需要数据用名称-值对表示，鉴于大数据完全可能的一般性，完

全有道理这样做。

使用数据虚拟化实现快速原型开发和方案变更。数据虚拟化是一种声明底层物理数据

上不同逻辑数据结构的强大技术。SQL 中的标准视图定义是数据虚拟化的一个很好的

例子。数据虚拟化在理论上可按分析师所需的任何格式显示数据源。但是数据虚拟化

只是以运行前构建物理表的 ETL 开销取代了运行时的计算开销。数据虚拟化是一种开

发数据结构原型和实现快速变更或提供不同备选方案的强有力方式。 好的数据虚拟

化策略是预期在虚拟架构已通过测试和审核，并且分析师希望提高实际物理表性能之

后对其进行实体化。

大数据的数据治理 佳实践

下列 佳实践适用于将数据作为宝贵的企业资产进行管理。

并不存在所谓的“大数据治理”。您需要牢记的是，数据治理必须是用于整个数据生

态系统的全面方法，而不仅仅是用于大数据的局部解决方案。大数据的数据治理应该

是所有企业数据治理方法的延伸。关于必须怎样通过将大数据与其他现有形式的数据

(尤其是来自 EDW 中的数据) 集成对大数据进行改进，我们已经提供了令人信服的用

例。但是成功集成的同时单独为大数据建立 (或忽略) 数据治理会造成巨大的风险数据

治理至少包含隐私性、安全性、合规性、数据质量、元数据管理、主数据管理以及向

新涌现出的大数据 佳实践 11

业务团体揭示定义和上下文的业务词汇表。这是一个势在必行而又艰巨的责任和能力

列表，IT 部门在取得来自管理层的重要和深入支持之前，不应贸然从事——管理层必

须了解采取措施的范围并支持必要的企业跨组织合作。

应用治理前使数据维度化。这是大数据带来的一个有趣的挑战：甚至在你不知道数据

有哪些内容时就必须应用数据治理的原则。你将以高达每秒吉字节的速度接收到达的

数据，这些数据通常是名称-值对的形式。通过数据治理责任非常重要的方式进行数据

分类时，你 好的机会就是在数据管道的 早阶段尽可能充分实现维度化。在动态中

解析数据、匹配数据并应用身份识别。我们在主张数据集成的优势时持相同的观点，

但是在这里我们倡导不要在这种维度化步骤之前使用数据。

如果分析数据集包括识别有关个人或组织的信息，在使用任何包含有关个人或组织信

息的大数据集时，个人隐私就是治理 重要的一方面。尽管数据治理的每个方面看起

来都至关重要，但是在这些情况下隐私承载了 多的责任和 大的业务风险。侵犯个

人或团体隐私的丑闻可能损害你的声誉、削弱市场信任、使你卷入民事诉讼并承受相

关制裁。这些危害同时可能是在公司、机构、第三方甚至组织内部共享丰富数据集的

障碍，严重限制大数据可在医疗保健、教育和执法等行业发挥的功能。我们有权访问

的海量个人信息很可能会让我们的感觉迟钝，警惕放松。对于大多数形式的分析来

说，至少必须将个人详细资料屏蔽掉，并将数据聚合到足以无法识别个体的程度。请

注意，如果将敏感数据存储在 Hadoop 中，在这样的写入时必须特别加以注意，因为

一旦把数据写入 Hadoop，Hadoop 在管理更新方面就做得不是很好——所以或者应将

数据屏蔽或写入时加密 (即持续数据屏蔽) 或应在读取时屏蔽数据 (即动态数据屏蔽)。

不要因为急于使用大数据就将数据治理完全抛开。即使是试探性的大的数据原型项

目，也要准备问题清单，在向前推进时考虑周详。你不想要一个无效的机构，但或许

你可以努力实现一个灵活的机制！你需谨慎保持的清单应该包括：

验证是否有一种构想和业务案例来提供方向和优先事项。

确定人员职责，包括数据管理员、赞助商、程序推动者和用户。

验证组织赞同和跨组织的指导委员会以及赞助以支持上报和优先事项。

限定现有和所需的工具及体系架构，为进行管理的大数据生命周期提供支持。

加入一些数据使用政策和数据质量标准的概念。

在这个清单上的所有其他要点都采用轻量级的组织变更管理。

测量结果、运营以及业务价值投资回报率。

评估和影响上下游相关流程，以尽量减少无时不在的垃圾输入/垃圾输出的窘境。

新涌现出的大数据 佳实践 12

总结

大数据为 IT 部门带来很多变化和机遇，同时也需要IT部门建立一套新的规则。但是受

益于近十年的经验，已有许多 佳实践涌现出来。可以看出这些实践中很多是企业数

据仓库/商业智能的扩展，当然还有不少是有关数据和 IT 部门任务的新颖奇特的思考方

式。对任务已扩大的认知是件好事，在某些方面这一认知却是姗姗来迟。当前数据收

集渠道、新数据类型和新分析机会的爆炸式增长，意味着 佳实践的列表将会以有趣

的方式继续增长。

致谢

十分感谢下列大数据专家，很荣幸在本白皮书撰写过程中与他们探讨。以下按组织名

称的字母顺序排列：

EMC：Bill Schmarzo

Fannie Mae：Javed Zaidi

美国联邦航空管理局：Wayne Larson 及其同事

Informatica：John Haddad, Robert Karel

摩根大通：Tom Savarese

Kimball 集团：Margy Ross

默克：John Maslanski

Rackspace：Pete Peterson

VertiCloud：Raymie Stata

雅虎：George Goldenberg

新涌现出的大数据 佳实践 13

参考资料

Informatica 赞助的 Kimball 大数据和 Hadoop 白皮书：

http://vip.informatica.com/?elqPURLPage=8808

Informatica 赞助的 Kimball 一致性维度和集成白皮书：

http://vip.informatica.com/?elqPURLPage=807

Kimball 关于渐变维度的介绍性文章： http://www.kimballgroup.com/2008/08/21/slowly-changing-dimensions/

http://www.kimballgroup.com/2008/09/22/slowly-changing-dimensions-part-2/

雅虎应对大合并挑战的方法：

http://www.slideshare.net/Hadoop_Summit/yahoo-display-advertising-attribution

无预聚集的语义缩放演示稿：

http://www.slideshare.net/Hadoop_Summit/empowering-semantic-zooming-with-hadoop-and-hbase