大数据革命正在顺利进行。我们知道，有趣的并非数据之大。而且，大数据也与这20多年来熟悉的把文字和数字数据存储在关系型数据库中并试用SQL进行分析非常不同。大数据的格式和内容非常丰富：非结构化的自由文本，高度结构化的关系型数据，向量，矩阵，图像，名称-值集合。

最大的冲击在于，标准关系型数据库和SQL根本无法存储或者处理大数据，并且已经触及了其处理能力和扩展的极限。关系型数据库所不能处理的不仅仅是更多的数据格式，还包括处理过程中的需要迭代的逻辑，复杂的分支，特殊的分析算法等。SQL是一种声明型的语言，它的语法强大，但是却是固定的。大数据通常需要过程语言，并且可以创建任意新的逻辑。

其次的冲击在于，基于简单的过滤和汇总的切片和切块正在转换为分析。报表，仪表盘，即席查询依旧会重要，但是大数据最佳的利用方式是整合若干未经过滤的巨大的数据集，数据集中将会包括历史数据和实时数据。

再次的冲击在于，随着更短的延时和更快的数据交付，大数据的价值将越发被认可。十倍甚至是百倍的性能提升将给分析机会带来质的不同，而这通常可以转化为收入和利润的增加。

所有这一切造就了一个非常有活力的并且由技术推动的市场，其中有两个主要的发展分支：扩展的关系型数据库和Hadoop。这两种架构都致力于解决上文所述的大数据挑战。

大数据市场远未成熟，但针对大数据的最佳实践，我们现在已经有数年的经验积累。本白皮书收集了这些最佳实践，从高屋建瓴的忠告，到具体的技术细节和所用工具。

在开发基于关系型数据库的企业数据仓库（EDW）过程中，我们已经积累了一套行之有效的最佳实践，大数据开发必须充分利用这些知识，这是非常重要的。包括：

• 由业务需求来决定企业数据仓库的数据源
• 持续关注与用户界面的简单易用和性能表现

下面的企业数据仓库最佳实践和大数据尤其相关：

• 维度思考：把所有的一切拆分为维度（Dimension）和事实（Fact）
• 使用一致性维度（Conformed Dimension）来集成不同数据源的数据
• 使用缓慢变化维（SCDs，Slowly Change Dimensions）来跟踪随时间的变化
• 对所有维度使用持久的代理键（Surrogate Key）

在下文中，我们将会对大数据最佳实践分四个种类：数据管理，数据架构，数据建模，数据治理。

大数据管理最佳实践

下面的最佳实践适用于大数据环境的全面管理。

围绕分析构建大数据环境，而不是即席查询或者标准报表。数据从源到分析师屏幕中的每一步都必须支持复杂分析套路，实现方式包括用户定义功能（User Defined Functions, UDFs）或者使用元数据驱动开发环境开发的各种类型的分析。这些套路包括装载，清洗，整合，用户界面，以及商业智能工具。这个最佳实践不是建议否定现有的环境，而是对其进行扩展以支持新的分析需求。参考后文的架构最佳实践章节。

不要试图在当前建立一个传统的大数据环境。当前大数据环境变化非常快速，不适合考虑建立一个做长远打算的基础。相反，要为自于各个方面颠覆性的变化做好准备：新的数据类型，竞争对手的挑战，编程方式，硬件，网络技术，以及众多新兴的大数据供应商提供的服务。在可以预见的将来，在下述实现方法中寻找平衡：Hadoop，传统网格计算，关系型数据库中的下推优化，定制化计算，云计算，抑或是大型主机。长远来看，没有任何一个单独的方法会是唯一的赢家。平台即服务（Platform as a Service，PaaS）服务商提供了有吸引力的选择，使得你可以构建一套包括多种工具的集合。同样，系统架构和程序实现的大部分可以在具体的部署环境之上一层被确认，这就是元数据驱动的开发环境的特殊优势。

例如：在Hadoop环境中使用HCatalog来提供在特定的存储位置和数据格式之上的抽象层。这就使得诸如Pig脚本不需跟着位置和格式的改变而改变。

例如：考虑把Hadoop作为一个灵活通用的环境来处理各种形式的ETL，用于给大数据补充足够的结构和上下文，使其可以被加载到关系型数据库中。这些Hadoop中的数据也可以被各种语言编写的Hive，Pig，HBase，MapReduce代码访问和转换，甚至可以做到同时访问和转换。

最重要的，就是灵活性。假设，你需要在两年内对所有的大数据进行重新编程和重新托管，这需要选择正确的方法。考虑使用元数据驱动的无代码开发环境，以提高生产效率，并可帮助你隔离底层技术的变化。

建立孤立的测试沙盒，并基于可以应用于生产环境的沙盒结果来构建实践。允许数据科学家们使用它们倾向的语言和编程环境来进行数据试验和原型构建。然后再概念验证后，系统化地进行重新编程，并且/或者使用“IT转化团队”来重新配置这些实现。

例如：用于自定义分析的编程生产环境有可能是使用Matlab搭配PostgreSQL或者SAS搭配Teradata，但是数据科学家可能在自己选择的语言和架构上进行概念验证。关键在于：IT必须前所未有地容忍数据科学家使用任何技术，并且经常需要准备好在可被远程支持的标准技术环境中重新实现数据科学家的工作。

例如：用于开发的沙盒环境可能使用ETL转换和自定义的R代码来直接访问Hadoop，但是由Informatica PowerCenter控制。当数据科学家准备好移交概念验证时，其中的众多逻辑可以即刻被重新部署到Informatica上，而Informatica是运行在高扩展、高可用、高安全的网格计算环境中。

用备份和归档这样简单的大数据应用进行试水。在开始大数据规划并寻找有价值且低风险的业务用例以及形成大数据能力时，考虑Hadoop作为一种低成本且灵活的备份和归档技术。Hadoop可以存储和检索各种类型的数据，从完全非结构化的数据到高度结构化的特定形式数据。这种方法也可以帮助解决在将来结束应用服务时（也许是许可证限制）带来的挑战，但是你可以把数据从应用程序转储到自己的文档格式。最后，请记住，Hadoop也会消耗资源和成本，所以，在把任何数据存储在Hadoop之前都应提前考虑数据保留问题，诸如，在保留期限届满后把HDFS文件夹和数据集清除掉或者归档到HDFS之外或者低成本的存储上。

大数据架构最佳实践

下面的最佳实践将会影响你的大数据环境的整体组织结构。

规划逻辑的“数据高速公路”，它包含若干延迟逐步增加的缓存。物理实现适用于你的环境的缓存。数据高速公路由延迟逐步递增的五种缓存构成，用于分析时它们有各自独特的优势和不足。

• 应用源系统应用：信用卡欺诈检测，包括网络稳定性检测和网络攻击检测的即时复杂事件处理。
• 实时应用：网页广告选择，个性化促销，在线游戏监测，各种形式的可预测和主动监控。
• 业务活动应用：推送给用户的低延时KPI仪表盘，故障工单跟踪，流程完成度跟踪，融合的即时复杂事件处理报告，客户服务门户和仪表盘，移动销售应用程序。
• 高层应用：战术报表，促销跟踪，给予社交媒体信息的中途修正。高层应用是指高层管理人员通常采用的能够快速得知企业在过去24小时都发生了什么的应用。
• 企业数据仓库和长远应用：各种形式的报表，即席查询，历史数据分析，主数据管理，大规模时间动态，Markov链分析。

每种缓存在指定的环境中都是物理存在的，和其它类型缓存截然不同。数据被抽取/转换/装载过程沿着数据高速公路从应用源系统开始移动。从应用源系统到中间缓存可能有多个路径。例如，数据可以直接移动到实时应用缓存以用于零延迟的用户应用，同时也可以被直接抽取到每天的高层应用缓存，这看起来有些像传统的操作数据存储（Operational Data Store, ODS）。然后操作数据存储区的数据可用于为企业数据仓库提供数据。数据也可以在相反的方向沿着高速公路移动。参见本节稍后的“实现回流”。

这条数据高速公路上的大部分数据必须保持非关系型格式，从非结构化文本到复杂的多结构数据，诸如图像，殊足，图形，链接，矩阵，以及名称-值集合。

使用大数据分析作为移动数据到下一个缓存的“事实提取器”。例如，对非结构化文本twitter消息分析可以产生一整套的数字化的可趋势化的情绪评估，包括语音分享，听众参与，谈论范围，积极的声音，主张的影响力，宣传效果，解析度，解析时间，满意度评分，话题趋势，市场情绪，观点影响力等。此外，诸如Splunk，是一种从众多形式的非结构化机器数据中抽取特点和构建索引的技术；Kapow，是一种从包括博客/论坛/网站/门户等网页数据中抽取数据的技术；当然，还有Informatica的HParser，它可以抽取事实和纬度数据，而数据可以来自于非结构化的文本文档，多结构的XML文档，页面日志，以及诸如市场数据/SWIFT/FIX/CDR/HL7/HIPAA等等业界标准结构数据。

使用大数据整合，建立全面的生态系统，来整合传统的结构化关系型数据库数据，纸张文件，电子邮件，以及内部的面向业务应用的社交网络数据。大数据传递的一个强有力的信息是其以各种不同的方式整合不同的数据源的能力。我们正在从新的数据产生渠道获取数据：社交网络，移动设备，自动警报过程。想象一下，一个大型金融机构需要处理数百万个账户，数千万份纸质文件，以及数千组织内以合作伙伴或者客户身份存在的专业人士。建立安全的用于受信任的各方沟通的社交网络以用于商务目的，这是目前在发生的。这种沟通非常重要，而且需要以可以被查询的方式被保存下来。使用Hadoop捕获所有这些信息，对其进行纬度化（参考后文的数据建模最佳实践），在业务过程中使用，然后进行备份和归档。

做好数据质量规划，以便更好地服务于数据高速公路。这是一个非常典型的处理延迟和质量的权衡。由于在短时间内只能进行有限的数据清洗和数据诊断，所以低延时的数据不可避免的包涵脏数据，这是分析人员和业务人员必须面对的现实。对单个字段内容的测试和修正可以以最快的数据传输速率完成。对包涵结构化关系的和来自多数据源的字段，其测试和修正必然会慢。对涉及复杂业务逻辑，其测试和修正有可能从即刻完成（诸如按照一定顺序的一组日期）到任意长时间（诸如等待检查非正常事件是否已超过阈值）。最后，包括为高层应用提供数据的这些速度较慢的数据抽取/转换/装载过程通常是建立在更完整的数据之上，其中不会包含不完整的交易信息和已撤销的交易信息。在这种情况下，即刻的数据源根本就不会提供正确的信息。

尽可能早地进行过滤，清洗，修正，一致化，匹配，关联和诊断。这是前述最佳实践的必然结果。数据高速公路上的每一步都会有更多的时间来使得数据更有价值。通过过滤/清洗/修正，减少传送到下一个缓存的数据量，并消除不相关的或者损坏的数据。公平地说，大量的理论坚持认为只应该在分析时刻再进行清洗，这样可以避免删除“有趣的异常”。一致化采用积极的步骤来把被高度管理的企业属性放到主要的实体中，诸如客户实体，产品实体，日期。这些一致化的属性的存在使得跨多个应用领域的数据值关联成为可能。这一步会被简单地称为“整合”。诊断可以把很多有趣的属性添加到数据上，包括特别的信心标签，数据挖掘专家用来标示行为聚合的文字标签。数据发现和数据剖析用于确认数据的领域，关系，便于搜索的元数据标签，敏感数据，以及数据质量问题。

在数据高速公路实现从企业数据仓库到早期缓存回流。在企业数据仓库中被高度管理的主数据/主纬度，例如客户，产品，日期，应该关联回流到较早的缓存。理想的情况是在所有的缓存中为这些实体实现统一的唯一持久标识键。这样做的结果就是，每个从一个缓存到另一个缓存的抽取/转换/装载过程的第一步都是使用唯一持久标示键来替换掉特有的专用键，从而在每一个缓存的分析都可以通过基于唯一持久标示键的简单关联来充分利用上游缓存的丰富内容。那在把源系统数据转移到实时缓存时，这个抽取/转换/装载步骤能够在一秒钟内完成吗？答案是，也许……

维度数据不是唯一的沿着数据高速公路被回流到源的数据。从事实表衍生出来的数据，诸如历史汇总以及复杂的数据挖掘结果，都可以被包装为简单的指标或者汇总，然后被回流到早期的缓存。最后，诸如有用的键值或者代码这样的引用链接都可以被嵌入低延时的缓存，从而使得分析师们通过简单的点击就可以连接到相关的数据。

在选定的数据流中实现流数据分析。低延时的数据有意思的一点是，分析在数据流入时就开始，但是有可能在数据传输结束前就中止。流分析系统通过类似于SQL的查询来在数据流入的时候处理数据。在有些应用中，分析过程可以在流查询结果超过某个阈值时暂停，而不用等到所有的数据传输完成。在学术研究中，被称为连续查询语言（Continuous Query Language，CQL）的成果已经取得了令人印象深刻的进步，它可以定义流数据查询需求，包括非常巧妙的应用于流数据动态移动时间窗口处理的语义。对于关系型数据库和HDFS数据集，选择对应的数据装载工具时，要考虑支持CQL扩展和流数据查询。理想的情况要允许流数据分析能够处理每秒数G的数据。

在可扩展性方面减少限制，避免出现边界崩溃。在计算机程序开发的早期，计算机只有小的可怜的硬盘空间和实时内存空间，边界崩溃是非常常见的，称为程序开发的克星。当应用程序运行时出现磁盘或者内存空间不足时，开发人员必须采取非常复杂的措施，通常需要大量的编程来添加于主要应用无关的内容。对于普通的数据库应用，边界崩溃基本上不再存在，但是大数据应用又抛出了这个问题。Hadoop架构能够显著地减少编程时对数据规模的担心，因为它可以通过无限制地扩展硬件来解决。当然，硬件扩展也需要准备，上线，有高带宽的网络连接支持。关键在于，必须非常有远见地规划，以应对巨大的数据存储量和数据流量。

在公有云环境进行大数据原型构建，然后再移植到私有云环境。共有云的优势在于，它可以非常迅速地被配置和扩展。诸如Amazon EMR和Google BigQuery。在这些情况中，可以对这些数据进行快速的原型设计，效率很高。只需记住不要在公有云服务商的程序员们下班的周末把海量的数据扔到线上。然而，请记住，如果你想要使用机架感知的MapReduce过程来使用本地数据时，你也许不能使用公有云服务，因为服务商不能给你所需要的对存储的控制。

寻找并期待随着时间的推移可以实现10倍到100倍的性能提升，认识到分析模式会非常快地改变。大数据市场的开放性带来了数百个针对特定分析类型的定制的解决方案。进展和问题同在。聪明的开发人员在摆脱了来自于供应商的关系型数据库优化器和内循环的限制后，他们实现的方案能够比使用标准技术快上百倍。例如，对于处理臭名昭著的“大连接”，也就是关联一个有数十亿行的维度表和一个有万亿行的事实表，已经取得了重大的进展。再例如，Yahoo处理海量数据稀疏关联的方法，Google的Dremel和BigQuery项目。问题在于，这些孤立的解决方案还没有形成一套统一的单一架构。

一个非常明显大数据主题是数据可视化（Data Visualization）。玩转PB级的数据需要卓越的处理性能。数据可视化是一个令人兴奋的新的开发领域，在这里，对数据的分析，以及对未知特性的发掘和数据剖析，都成为可能。

另一个对性能有巨大要求的令人兴奋的应用是无需预聚合的语义对焦（Semantic Zooming），它允许分析师可以以类似于在地图上缩放的方式来对非结构化或者板结构化数据进行分析，从高聚合到逐渐更详细的级别。

这个最佳实践教会我们最重要的是，我们消费和分析大数据的能力将会出现革命性的进步，数十倍甚至数百倍的性能提升，我们必须时刻准备好把这些开发方法整合到我们使用的工具中。

把大数据分析工作重心从传统的企业数据仓库转换到保证企业数据仓库的服务质量上。如果你的大数据存储在Hadoop中，那么它也许不会与基于传统关系型数据库构建的企业数据仓库争夺资源。但是，如果你的大数据分析是运行在企业数据仓库平台上，那么你要当心，因为大数据需求变化非常迅速，而且不可避免的越来越需要更多的计算资源。

利用数据库内分析这个独特的功能。主要的关系型数据库厂商都在明显地向数据库内（In-Database）分析投入资源。一旦你花费精力把数据装载到关系数据库的表中以后，SQL可以结合分析扩展来发挥巨大的威力。近来值得关注的数据库内分析开发包括：IBM收购了Netezza和SPSS，Teradata和Greenplum内嵌SAS，Oracle的Exadata R Enterprise，PostgresSQL针对分析和利用数据库内循环（Database Inner Loop）的任意函数程序设计语法。他们都提供经过测试的包括数百分析路径的库。一些数据整合平台提供下推（Pushdown Optimization）优化，来充分利用库内分析作为数据流或者抽取/装载/转换处理。

大数据数据建模最佳实践

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

维度思考：把把所有的一切拆分为维度（Dimension）和事实（Fact）。业务人员找到了纬度的概念，这是很自然且明显的。不管是什么格式的数据，总能发现一些相关的基本实体：客户，产品，服务，位置，以及时间。在接下来的最佳实践中，我们将会看到如何在施加一些要求的前提下使用维度来对不同源的数据进行整合。但是在整合之前，我们必须确定每个数据源中的维度，并和最低粒度的数据关联起来。这个纬度化的过程就是大数据分析的很好的应用。例如，Twitter一条简单的消息“哇，这个真棒！”，看起来它并不包含任何可以维度化的信息，但是在其他的一些分析中，我们通常可以可以得到客户（公民或者病人），位置，产品（服务或者合同或者事件），市场条件，供应商，天气，群组（人口族群），会话，触发条件，最终产出，以及列表等。一些形式的自动维度化需要在快速的数据流开始前就被建立起来。正如在随后的最佳实践中指出的，应尽早地对传入的数据进行维度化。

使用一致性维度（Conformed Dimension）来集成不同数据源的数据。一致性维度是能够把多数据源的数据粘合在一起，从而被一起分析。一致性维度也许是来自于传统企业数据仓库最强大的最佳实践，应该被大数据继承。

一致性维度背后基本思想是，在若干个维度中维护一个或者多个企业属性（字段），它们与多个独立的数据源相关。例如，在客户相关的流程中，客户维度总会有些不同。这些不同可能体现在不同的键值，不同的字段定义，甚至不同的力度。但是即使在最不匹配的数据中，也可以找到一个或者多个共有的客户维度属性。例如，客户的人口统计类别就是一个合理的选择。可以给几乎每个客户维度添加一个描述字段，即使这个描述字段只能用于粗粒度的聚合。做到这些后，分析人员可以基于各个不同的数据源的查询结果进行排序-合并操作，并进行跨数据源的对客户人口统计类别的操作。最重要的是，可以以渐进的/灵活的/非破坏的方式把企业属性引入单独的数据库中，这在我的关于本主题的白皮书中有详细的描述。在一致性维度发布的基础上，所有的现有的分析应用将依然可以继续发挥作用。

对所有维度使用持久的代理键。如果说我们从企业数据仓库中学会了什么，那就是不要对对诸如客户/产品/时间这样的主要实体使用由特定系统定义的“自然键”。这些自然键是真实世界中的圈套和错觉。它们在不同的应用中互不兼容，没有被有效地管理。对每个数据源，第一步都是给来自于源系统的自然键添加一个企业范围的持久的代理键。持久意味着没有任何业务规则可以改变这个键。持久键由信息部门维护，而不是源系统。代理键意味着键本身是简单的数字，顺序生成或者由强大的哈西算法生成，从而保证唯一性。一个孤立的代理键不包含任何应用内容。它仅仅是个标示符。

大数据的世界充满了明显必须具备持久代理键的维度。在前文提到沿着数据高速公路把数据回推，想要使这个成为现实，必须依赖于持久代理键的存在。我们也提到在从源系统抽取数据时，第一个工作就是给相应的维度嵌入持久代理键。

期待整合结构化和非结构化数据。大数据显著地放大了整合挑战。很多大数据不会存在于关系型数据库中，而是在Hadoop或者网格中。但是当我们拥有了一致性维度和持久代理键后，我们可以在单一的分析中综合使用各种形式的数据。例如，医学研究会选择一组有特定人口特征和健康状态属性的病人，然后把传统企业数据仓库形式的数据和图像数据（照片，X射线，心电图），自由形式的文本数据（医生记录），社交媒体情绪数据（治疗意见），队列组关系（患者类似的情况）相结合。

从结构上说，这种整合的步骤应该在查询而不是数据装载和结构化时进行。通过数据虚拟化进行整合是比较灵活的方式，整合的数据集看起来像是物理表，但实际上是类似于关系数据库中的视图，在查询时来关联互相独立的数据源。如果没有采用数据虚拟化，那么一定要在最终的商业智能层完成整合步骤。

使用缓慢变化维（SCDs，Slowly Change Dimensions）来跟踪随时间的变化。跟踪维度随时间的变化，这是来自于企业数据仓库的历史悠久的最佳实践。基本上，这很好的保证了我们可以准确地跟踪历史。关联一个客户（或者公民，或者病人，或者学生）的当前信息和历史信息是不可接受的。在最坏的情况下，当前的信息和历史信息是完全不同的。缓慢变化维的处理有三种形式。第一种，在变化发生时会发生覆盖，从而会丢失历史信息。在修正数据错误时会如此做。第二种最常用，在变化发生时生成修正的维度记录。第二种要求在生成新的维度记录时保留持久代理键来绑定新记录和旧记录，同时也必须为维度成员的特定快照生成唯一主键。和一致性维度一样，这个过程已被广泛地描述和验证。最后一种，不像其它两种那么常见，用于“可供选择的现实”和当前现实共存的情况。请参考我介绍缓慢变化维的文章和我书中的详细介绍。关键在于，对于大数据，关联主要实体的正确的当前档案和历史档案，和在企业数据仓库中同样重要。

习惯于直到分析时刻再声明数据结构。大数据的魅力之一就是在把数据装载到Hadoop或者数据网格时可以推迟声明数据结构。这带来了众多好处。在装载时数据结构也许未被理解。数据也许包含可变的内容，采用某种数据结构没有意义，或者必须修改数据来适应某种数据结构。例如，如果把数据装载到Hadoop，无须声明数据结构，那么你可以避免消耗资源的步骤。最后，不同的分析师可以合法地从不同的角度来观察数据。当然，有些情况下也有代价，因为未声明结构的数据也许难以甚至不能被索引，不能像关系型数据库中那样快速访问。然而大部分大数据分析算法会对整个数据集进行处理，不期望数据进行精确过滤。

这个最佳实践和传统的关系型数据库方法相冲突，后者非常强调要在数据装载前仔细进行数据建模。但是这并不会带来致命的冲突。对最终要进入关系型数据库的数据，从Hadoop或者数据网格环境或者来自于名称-值集合到关系型数据库中的转换过程可以被认为是一个有价值的抽取/转换/装载步骤。

发展处理名称-值数据源的技术。大数据中处处充满了惊喜。很多情况下，当你打开魔盒，你会发现很多不曾预想的或者没有被说明的数据内容，但是必须被以每秒GB的速度完成装载。摆脱这个问题的方法是采用简单的名称-值对来装载。例如，如果申请人来披露他的财产，他可能会出乎意料地声明诸如“罕见的邮票=$10000”。在一个名称-值对数据集中，这会被从容地装载，即使你从未见过“罕见的邮票”而且在加载时不知道用它做什么。当然，这个实践很好地配合了前一个实践，也就是推迟声明数据结构到装载之后。

MapReduce编程框架要求数据以名称-值对的形式存在，考虑到大数据的种类繁多，这是有道理的。

使用数据虚拟化技术来实现快速的原型设计和数据架构的改变。数据虚拟化是一中强大的技术，用于在物理数据基础上声明不同的逻辑数据结构。SQL中的视图定义是数据虚拟化的好例子。理论上，数据虚拟化能够以分析人员需要的任何形式展示数据源。但是数据虚拟化的代价是在运行时进行计算，而物理表在运行前通过抽取/转换/装载完成。数据虚拟化提供了强大的方式来对数据结构进行原型构建，并可提供快速的转变或者提供不同的备选方案。最佳的数据虚拟化战略是，在虚拟模式得到测试和审核并且分析师希望能够得到真实物理表一样的性能改进时，对其进行物化。

大数据数据治理最佳实践

下述最佳实践可以应用于把数据作为有价值的企业资产进行管理。

大数据治理无先迹可寻。请注意，数据治理必须是针对你所有数据生态系统的全面方法，而不是仅仅针对大数据的独立方案。大数据的数据治理必须是涵盖所有企业数据的治理方法。我们已经介绍了这个令人信服的例子，其中包括大数据如何必须通过整合已有的数据类型，尤其是来自于企业数据仓库的数据，进行加强。但是独立地建立或者忽略大数据治理，对于能否成功地整合数据也会带来很大的风险。数据治理至少要包括隐私，安全，合规，数据质量，元数据管理，主数据管理，以及给业务部门展示定义和背景的业务术语表。这是宏大且艰巨的责任和能力，信息技术部门不应该在没有明确的来自于管理层的支持下进行这些事宜，管理层必须理解工作的范围并支持所需要的跨部门的合作。

在进行治理前进行数据的维度化。大数据带来了一个很有意思的挑战：即使你不知道数据内容是什么，你都必须应用数据治理原则。你可能会以每秒数GB的速度收到数据，其中大部分是内容未知的名称-值对。尽早地对数据进行完整地维度化，这是最佳的分类数据的方法，体现数据治理的责任。在过程中解析之，譬配之，并判定其身份。在讨论数据整合的好处时，我们也谈到了这一点，但是这里我们提倡不要在维度化步骤前使用数据。

如果分析数据集中包括组织或者个人的身份信息，那么这些数据的隐私将是最重要的治理方面。尽管数据治理的每个方面都很关键，但是其中隐私承载了最大的责任和最高的商业风险。严重的泄漏个人或者组织隐私的事件将会损害你的声誉，削弱市场的信任，带来民事诉讼，甚至带来更多的法律麻烦。这些风险也会阻碍在公司/机构/第三方/甚至公司内部分享丰富的数据集，严重地限制了大数据在诸如医疗保健/教育/执法这些行业的威力。当我们能够访问海量的个人数据时，我们的反应已经迟钝，我们的警惕性已经降低。至少在大多数分析中，必须屏蔽个人资料中的详细信息，并提供不可能识别到个体的聚合的数据。当前，必须注意使用Hadoop储存敏感信息，由于Hadoop并不能很好地管理对已写入数据的更新，因此数据必须被加以伪装，或者在写入时加密（例如永久的数据伪装），或者在读出时加以伪装（动态的数据伪装）。

在你急于利用大数据时不要忘了数据治理。即使是试探性的大数据原型项目，也要在进行时维护一个需要考虑的问题清单。你不想要一个无效的机构，那就尽量建立一个灵活的机构！你维护的清单，应该：

• 验证是否有目标和商业用例来提供方向和重点
• 确定人员角色，包括数据管家，资助方，方案驱动方，用户
• 验证组织认可，跨组织的指导委员会，资助方，支持升级和优先级
• 对将要用于支持大数据生命周期管理的已有的和所需的工具以及架构进行资格审查
• 采纳数据使用政策和数据质量标准的一些概念
• 接受本清单上其他点带来的轻量级的组织结构变化
• 对结果，运营，以及业务上的投入产出比进行衡量
• 评估并积极影响相关的流程和上下游，减少进垃圾/出垃圾的困境

总结

对于信息技术来说，大数据带来了巨大的变化和机会，也很容易想到必须建立一整套新的规则。最近十年的经验已经积累了很多最佳实践。许多最佳实践被认为可以从企业数据仓库/商业智能领域继续扩展，诚然也有一些新颖的考虑数据和信息技术使命的新方法。当前层出不穷的数据收集渠道，新的数据类型，新的分析机会，这些都意味着最佳实践列表将会以有趣的方式持续增长。

作者：Dr. Ralph Kimball，自1982年以来一直是数据仓库行业最主要的开拓者，并且是目前最知名的演讲人、咨询师与培训员之一。他是《智能企业（Intelligent Enterprise）》杂志“数据仓库设计者（Data Warehouse Designer）”专栏的撰稿人，同时也是最畅销的《数据仓库生命周期工具箱（The Data Warehouse Lifecycle Toolkit）》与《数据仓库工具箱（The Data Warehouse Toolkit）》两部著作的作者。同时他被列入数据库名人堂（Database Hall of Fame）。

译者：刘彬，关注数据管理领域，致力于通过完善的数据管理来协助组织提升业务绩效。现就职于IBM软件部，从事IBM Business Analytics产品族的售前技术咨询工作。