数据仓库系列9- 大数据分析
文章目录
- 一. 大数据概览
-
- 1.1 扩展的 RDBMS 结构
- 1.2 MapReduce/Hadoop 结构
- 1.3 大数据结构比较
- 二. 推荐的应用于大数据的最佳实践
-
- 2.1 面向大数据管理的最佳实践
- 2.2 面向大数据结构的最佳实践
- 2.3 应用于大数据的数据建模最佳实践
- 2.4 大数据的数据治理最佳实践
- 参考:
一. 大数据概览
什么是大数据 ？所谓的 “大” 实际上并不是大数据的最有趣的特征 。大数据是结构化、 半结构化、非结构化以及众多不同格式的原始数据 ，某些情况下 ，它看起来与您 30 多年来 在数据仓库 中存储的清楚的标量数字和文本存在巨大差异 。多数大数据不能用任何看起来 类似 SQL 的方法来分析 。但最重要的是 ，大数据是一种模式的转变 ，涉及如何考虑数据资产、从何处获取 、如何分析它们以及如何从分析中获得有价值的知识 。
从大量的用例中积聚了动力的大数据运动，可划分到大数据分析的类别中 。这些用例 包括：
• 搜索排序
• 广告跟踪
• 位置与距离跟踪
• 因果关系发现
• 社会化客户关系管理（CRM)
• 文档相似性测试
• 基因分析
• 群组发现
• 飞机飞行状态
• 智能测量仪表
• 建立传感器
• 卫星图像分析
• CAT扫描比较
• 金融账户欺诈检测与干预
• 计算机系统黑客检测与干预
• 在线游戏姿态跟踪
• 大型科学数据分析
• 通用名称值对分析
• 贷款风险分析及保单承保分析
• 客户流失分析
考虑到潜在用例的广泛程度 ，本章主要关注处理大数据的结构化方法 ，以及我们推荐 使用的最佳实践 ，并不专门考虑每个用例的维度设计 。
传统的 RDBMS 和 SQL 几乎无法存储或分析此类范围广泛的用例 。要实现对大数据的综合处理 ，系统需要具备如下能力 ：
(1） 方便处理 PB(1000TB）数据的能力 。
(2） 包含多达数千个分布的处理器，地理不同，且异构 。
(3） 以原始的获取格式存储数据，支持查询和分析应用而不需要转换或移动数据 。
(4） 以亚秒级响应时间响应高约束的标准 SQL 查询。
(5） 在处理请求中方便地嵌入复杂的用 户自定义函数 （User-Defined Function , UDF） 。
(6） 采用业界标准的过程语 言来实现 UDF 。
(7） 组装跨多数或所有用例的可重用 UDF 扩展库。
(8） 在几分钟内 ，以关系扫描方式对 PB 级别数据集执行用户自定义函数 。
(9） 支持范围广泛的数据类型包括越来越多的图像 、波形 、任意层次的数据结构以及 名称 值对集合 。
(10） 为数据分析高速加载数据 ，至少达到 GB 级别每秒。
(11） 从多个数据源高速（GB/sec）加载数据以集成数据。
(12） 在定义或发现其结构前加载数据 至数据库。
(13） 实现对加载数据的实时数据流分析查询 。
(14） 全速更新数据 。
(15） 不必预先聚类维度表和事实表 ，实现 卡亿级别的维度表与万亿级别事实表的连接 。
(16） 调度和执行复杂的上百个节点的 工作流。
(17） 配置工作不会受到单点故障的影响 。
(18） 在节点发生错误时能够实现容错和不间断过程 。
(19） 支持极端的 、混合的工作负载 ，包含数千个地理分布的在线用户和程序，同时执行即席查询和战略分析，以批处理和流处理方式加载数据 。
为实现这些具有挑战性的问题 ，需要将两种结构融合 ，这两种结构是 ：扩展的 RDBMS和 MapReduce/Hadoop 。
1.1 扩展的 RDBMS 结构
当前 RDBMS 提供商对经典的关系数据类型进行了扩展 ，增加了一些处理大数据需要的新数据类型，如下图所示:
现在的 RDBMS 必须扩展以便能够加载和处理包含复杂结构的广泛的数据类型 ，例如向量、矩阵和自定义超结构数据 。RDBMS 需要支持加载和处理无结构和半结构文本 ，以及图像、视频、名称，值对集合 ，有时将其称为 数据包。
但是支持类似 “ 二进制大数据文件” 这样的仅仅能够在可解释这些数据的 BI应用之后 交付的新数据类型 ，对RDBMS 来说仍然是不够充分的 。要真正拥有大数据 ，RDBMS 必须允许在数据库管理系统内部循环中 ，利用特定的由业务用户分析人员编写的用户自定义函 数（UDF）处理新数据类型 。
最后 ，有意义的用例是通过 RDBMS 处理数据两遍，第 1 遍通过 RDBMS 从原始数据 中获取事实，第2 遍将获取的结果作为传统的关系行 、列和数据类型，自动反馈到RDBMS 。
1.2 MapReduce/Hadoop 结构
另外一种结构是 MapReduce/Hadoop 结构，它是一种开放源代码的 ，包含定量组件的 Apache顶级项目 。MapReduce 是一种 由 Google 在 2000 年初开发的处理框架 ，主要用于从大量不同机器中搜索 Web 页面 。MapReduce 方法具备良好的通用性 。完整的 MapReduce 系统可以用多种语言实现 ，最著名 的实现是通过 Java 实现的 。MapReduce 实际上是一种 UDF 扩展框架 ，其中的 “ 函数” 可 以非常复杂 。目前最常见的 MapReduce 框架是 Apache Hadoop ，简称为 Hadoop 。 Hadoop 项目有大量的参与者 ，并运用于所有的应用中 。Hadoop 运行在其 Hadoop 分布式文件系统 （Hadoop Distributed Fi le System, HDFS）之上 ，也能够被 Amazon S3 和其他系统所理解 。传统的数据库提供商实现了与 Hadoop 的接口，允许大量的Hadoop 任务通过接口在其数据库之上运行大量的分布式实例。
注意：
关于MapReduce/Hadoop 结构更详细的讨论已超出了本书的范围 。有兴趣的读者可以访问网站 www.kimballgroup.com ，以获得更多有 关 大数据的资源 。
1.3 大数据结构比较
上述两种大数据结构都有不同的长期优势 ，并有可能在未来共存 。在本书写作时 ，两 种结构的特征可 以通过下表汇总。
二. 推荐的应用于大数据的最佳实践
尽管大数据市场尚不成熟 ，但从行业来看己经具有 10 年的经验积累 。在这段时间 ，产生了大量针对大数据的最佳实践 。本节试图将这些最佳实践介绍给读者 ，在高级的专 家告诫与针对单 一工具的草根级别的细枝末节之间开辟 一个中间地带 。
话虽如此，还是应该认识到 ，30 年来 ，针对与大数据有关 的关系型数据仓库的设计开 发提出了许多经过实践考验的最佳实践 。以下简单将它们列举出来：
• 从业务需求出发选择构建数据仓库需要的数据源 。
• 始终关注简化用户接口和改善性能。
• 从维度角度考虑问题 ：将世界划分为维度和事实 。
• 以一致性维度集成不同的数据源 。
• 利用缓慢变化维度跟踪时间 变化。
• 使用持久性代理键确定所有维度 。
本节以下内容 ，我们将按照 4 个分类划分大数据最佳实践：管理、结构、数据建模和 治理。
2.1 面向大数据管理的最佳实践
下列最佳实践运用于大数据环境的整体管理 。
-
围绕分析构建大数据环境
考虑围绕分析而不是即席查询或标准报表构建大数据环境 。从原始来源到分析师屏幕这一数据路径上的每个步骤必须支持将复杂的分析例程以UDF方式或通过元数据驱动的能够为所有分析类型编程的开发环境来实现 。其内容包括加载 、清洗、集成 、用户接口，以 及最终的 BI 工具。 -
延迟构建遗留环境
此时试图建立遗留大数据环境不是好的想法 。大数据环境变化太快而无法考虑建立一个长期的遗留基础 。相反，应该从各个方面规划革命性的变革 ：新数据类型 、竞争挑战 、 编程方法 、硬件、网络技术，以及由大量新型大数据提供者提供的服务 。在可预见的未来 ， 需要维护多种实现方法的共存 。这些实现方法包括 Hadoop 、传统网格计算、优化的 RDBMS 、 定制计算 、云计算和大型机 。长远来看 ，每种方法都难以独占整头 ，平台即服务（Platform asa Service, PaaS）提供商通常提供有吸引力的选择 ，用于装配可兼容的工具集合 。
设想将 Hadoop 作为多种格式 ETL 处理的灵活及通用的环境 ，目的是为大数据增加充 分的结构和环境 ，以便能够加载到 RDBMS 中。Hadoop 中同样的数据可以被访问并转换为以各种语言编写的 Hive、Pig 、HBase 和 MapReduce 代码 ，甚至可以同时进行。
实现上述目标需要具备灵活性 。假设您能够在两年内重新编写并重新部署大数据应用。选择适当的方法以重新编程并部署 。可以考虑使用元数据驱动的无代码开发环境以增 加效率井有助于隔绝基本 技术变化所带来的问题 。 -
从沙箱结果中构建
考虑使用沙箱 ，并建立实际可用的沙箱结果 。允许数据科学家构建他们的数据环境并 使用他们熟悉的语言和编程环境构建原型 。然后，完成概念证明后 ，与某个 IT 更新小组系统化地重新编写这些实现。以下将使用一系列案例描述这 一建议：
自定义分析编程的生产环境可以是 MatLab 和 PostgreSQL ，或者是 SAS 和Teradata RDBMS, 但数据科学家可能利用其熟悉的语 言和结构建立其概念证明 。关键的知识是 ：IT 必须非同寻常地容忍数据科学家所使用的技术范畴并在多数情况下需要准备以能够被长期支持的标准技术集重新实现数据科学家的工作 。沙箱开发环境可能会使用自定义R代码直接访问Hadoop ，但由元数据驱动的 ETL 工具所控制。然后 ，当数据科学家准备交付概念证明时 ， 多数逻辑可能需要立 即被重新部署到可扩展的 、高度可用的 、安全的 、运行于网格环境中 的 ETL 工具。 -
首先从尝试简单应用着手
可以先从简单的应用开 始，例如备份与归档 。在开始执行大数据项目时 ，搜索有价值的、风险小的商业用例 ，贮备必要的大数据技能 ，考虑使用 Hadoop 作为成本低 、灵活的备份和归档技术 。Hadoop 可以存储和检索多种格式的数据 ，从完全非结构化的到高度结构化的专用格式 。该方法还能确保解决夕阳问题，所谓夕阳问题是指原先的应用可能在遥远的未来变得不可用（也许因为授权限制） ，您可以将这些应用 的数据转储到您的文件格式中 。
2.2 面向大数据结构的最佳实践
下列最佳实践将影 响整个大数据环境的结构和组织 。
- 规划数据通道
应该为逻辑数据通道规划多个增加延迟的缓存 。仅仅物理上实现那些适合您的环境的缓存 。数据通路可以包括多达 5 个缓存以增加数据延迟 ，每个缓存都具有独特的好处和权衡，如下图所示。
以下是 5 个数据缓存的潜在的示例：
• 原始来源应用：信用卡欺诈检测 ，实时复杂事件处理（Complex Event Processing , CEP),包括网络稳定性和网络攻击检测 。
• 实时应用 ：Web 页广告选择 ，个性化价格促销 ，在线游戏监控 。
• 业务活动应用 ：推送给用户的低延时关键性能指标（KPI）仪表板 ，麻烦跟踪 ，过程完成跟踪 ，综合 CEP 报表 ，客户服务门户与仪表板 ，汽车销售广告 。
• 优先应用 ：战术报表 ，促销跟踪 ，基于社会媒体声音的中途修正 。优先应用指高 级管理人员能够快速观察到 24 小时内企业发生的最重要情况的公共实践 。
• 数据仓库和长时间序列应用 ：所有格式的报表 ，即席查询，历史分析 ，主数据管 理，大容量时间动态 ，马尔科夫链分析 。
存在于给定环境中的每个缓存物理上不同于其他缓存 。从原始来源获得的数据，沿着这条通道通过 ETL 过程 。从原始数据来源到中间缓存可能存在多条路径。例如 ，数据可能会在实时缓存驱动某个零延迟类型用户接口 ，但同时被直接获取到看起来像经典的操作型数据存储（Operational Data Store, ODS）的每日优先缓存 。然后 ODS 数据可能被用于构建数据仓库 。数据也可以沿着通路的相反方向运动 。本章后面将讨论回流的实现。
运动于该通路的多数数据必须保持非关系格式，包括非结构化文本和复杂的多格式数据 ，例如图像 、数组 、图、连接 、矩阵以及名称-值对集 。
-
建立针对大数据的事实获取器
将大数据分析作为一个事实获取器 ，将数据移动到下一个缓存 ，这是一个非常好的想法 。例如，非结构文本信息的分析可以产生大量数字化的、有趋向的情感度量，包括声音的共享、观众参与 、会话到达 、积极的倡导者 、主张的影响、支持影响、分辨率 、分辨时间、满意度 、主题趋势、情感比例和观点影响等 。 -
建立完整的生态系统
可以利用大数据集成建立完整的生态系统 ，集成传统的结构化的 RDBMS数据、文档、 电子邮件，以及内部的面向业务的社会网络 。来自大数据的有效信息之一是集成不同格式的不同的数据源 。可以从新数据制造通道获得数据流 ，例如社会网络、移动设备和自动提醒处理 。假设某个大型金融机构处理几百万账户 ，与之关联的纸质文档数千万 ，组织内部包含数千专业人员以及该领域的合作伙伴和用户 。现在 ，为所有受到信任的团体建立一个安全的社会网络 以进行通信已经成为现实的应用 。多数此类通信显然都 需要以可查询的方式存储 。可以在 Hadoop 中获取此类信息 ，在业务中使用它们，然后对其备份并归档 。
4 . 制定数据质量规划
可以对数据质量制定规划以更好地应用于数据通道中 。这是一种典型的针对延迟与质量的权衡。分析员和用户必须接 受非常低延迟的（也就是说 ，实时）数据所造成的不可避免会出现的脏数据的现实。因为非常短的时间间隔限制了清洗和诊断工作 。针对独立字段内 容的测试和纠正可以以最快的数据转换率执行 。针对字段和跨数据源的结构化关系的测试 和纠正需要花费大量时 间。测试和纠正涉及从瞬时 （例如一定顺序的日期集合）到任意长时间（例如等待观察某 个非寻常事件是否超过门槛值）的复杂业务规则 。最后 ，缓慢的 ETL 工 程 ，例如那些需要满足每日 优先缓存的处理，通常基于更完整的数据建立 ，例如 ，不完整的事务集与拒绝事务集将被删除 。此时 ，简单获得的瞬时数据通常是错误的信息 。
-
尽可能提高数据价值
应该尽可能早地在切入点应用过滤 、清洗、剪枝 、一致性 、匹配、连接和诊断等 。这是前述最佳实践的必然结果 。数据通道中每个步骤提供了更多时间来提高数据价值 。针对数据的过滤 、清洗 、剪枝等操作减少迁移到下一个缓存的数量并消除不相关或损坏的数据 。 公平地说 ，很多人认为只需要在分析运行阶段应用清洗逻辑 ，因为清洗可能会删除了 “ 有 趣的孤立点 ”。一致性 以积极的步骤将高度可管理 的企业属性放入到主要的实体中，例如客户、产品和日期等 。这些一致性属性的存在 允许在不同应用领域执行高价值的连接 。该步骤的简短名称是 “ 集成 ！” 诊断允许将许多有趣 的属性增加到数据中 ，包括特定信任度标识 和由数据挖掘专业人员识别的表示行为聚类的文本标识符 。 -
实现前期缓存的回流
应当实现回流 ，特别是从数据仓库到数据高速路上早期的缓存 。数据仓库中高度可管理的维度，例如客户 、产品和日期，应当与早期缓存中的数据连接 。理想情况下 ，所需要的是在所有缓存中的这些实体的唯一持久性键 。此处的推论是，从一个缓存到下一个缓存的每个 ETL 步骤的首要工作是用具有唯一性的持久键替换特定的专用键 ，以便每个缓存的分析能够通过与唯一性持久键的简单连接来利用丰富的上游内容 。这一 ETL 步骤能将行源 数据 以低于 1 秒的时间转换到实时缓存中执行吗 ？也许能 。
维度数据并不是 唯一将通过高速路回流到源的数据 。从事实表导出的数据 ，例如历史汇总和复杂的数据挖掘结果，可以被当成简单的指标或汇总传播 ，然后传送到数据高速路 上的早期缓存中。 -
实现数据流
您应当针对选择的数据流实现流式数据分析 。低延迟数据的 一个有趣的方面是需要针对流中的数据开始严格的分析 ，但是可能需要在数据转换过程结束前 。对流分析系统的兴趣非常强烈 ，允许执行类似 SQL 查询处理流中的数据。在某些用例中，当流查询的结果超过某个阔值时 ，将停止分析工作 ，不需要将任务执行完 。一种学术方面的工作 ，被称为连续查询语言（Continuous Query Language, CQL） ，目前在定义流数据处理需求方面己取得了 引人注目的成就 ，包括在流数据中动态移动时间窗口的智能化的语义 。在 DBMS 和 HDFS 的加载程序中利用 CQL 语言扩展和流数据查询能力部署数据集合 。理想的实现既能开展流 数据分析工作 ，又能以每秒几 GB 的速度加载数据 。 -
避免无法扩展的限制
您应当实现强大的可扩展能力以避免达到扩展的极限 。在早期计算机编程时 ，那时机器的硬盘和实际的内存都很小 ，边界冲突比较常见 ，是应用开发中令人烦恼的事情 。当应 用用尽了磁盘空间或实际内存时 ，开发者需要采取具体的措施 ，通常需要大量的编程工作 ， 这些工作并未增强应用的主要功能 。一般的数据库应用的边界冲突己经没有什么问题了 ， 但是大数据再次将这 一问题推向前台 。 Hadoop 是一种极大地减少了编程可扩展性问题的结构，因为在大多数情况下 ，可以无限制地增加商业化硬件 。当然，即使是商业化硬件也需 要配置 、连接和具备高带宽的网络连接 。需要为未来规划这一问题，要能够扩展到巨大的 容量和吞吐率 。 -
将原型移动到私有云
考虑在公有云上完成大数据原型然后将其移动到私有云上 。公有云的好处是具有可配置能力和立即扩展的能力。对那些存在数据敏感性问题需要快速进出的原型 ，公有云非常有效 。记住在周末程序员们都离开的情况下 ，不要让巨大的数据集在公有云在线可用 。然而，需要记住的是 ，某些情况下 ，当您试图利用局部数据及可预知机架的 MapReduce 过程 时，可以不使用公有云服务 ，因为它不存在对数据存储控制的需要 。 -
尽力改进性能
不断寻找并希望得到十倍到百倍的性能改进 ，认识那些能够提高 分析速度的案例 。大数据市场的开放将遇到大量的特定目标，这些目标与特定分析的解决方案紧紧关联 。这既带来好处 ，也存在问题 。如果未受到大型提供商的 RDBMS 优化器和内部循环的控制 ，聪明的开发人员可以实现具体的比标准技术快 100 倍的解决方案。例如 ，针对臭名昭著的“ 大型连接” 操作方面 ，取得了一些令人激动的进步 。这些大型连接需要将具有 10 亿行的维度 与一个包含 10 000 亿行的事实表连接 。存在的困难是这些单独的特定解决方案可能不是统 一的体系结构中的一部分。
当前非常重要的一个大数据主题是数据集合的可视化 。“围绕” PB 级别的数据需要特 殊的性能 ！大数据可视化是一个令人激动的新开发领域 ，利用它可保证分析和发现未知特征以及数据分析 。
另外一个令人激动的将带来巨大性能需求的应用是 “ 不需要预先聚集的语义缩放” ， 分析师可以分析非结构化和半结构化数据的高度聚集的级别直到逐步细节化的层次 ，类似于在图上缩放 。
该最佳实践之后隐藏的重要课题是您拥有的具有分析和使用大数据的革命性进步的 能力将带来 10-100 倍的性能增益 ，您需要为工具套件准备这些开发能力 。 -
监视计算资源
应当将大数据分析工作与传统的数据仓库分开以保持服务级别的协议 。如果大数据驻留在 Hadoop 上，则可能不会与传统的基于 RDBMS 的数据仓库竞争资源 。然而 ，如果大数据分析运行在数据仓库机器上 ，则要引起高度的注意 ，因为大数据需求变化快速且对计 算资源的需求不断增长这 一趋势是不可避免的 。 -
利用内置数据库分析
记住要利用内置数据库分析的独特能力 。主要的 RDBMS 厂商都在 内置数据库分析方面投入巨大 。在您花费大量成本将数据加载到关系数据库表中后 ，可 以对 SQL与分析扩展合并 ，获得极其强大的能力 。特别是 PostgreSQL ，它是一种开放源数据库 ，包含的扩展语法可用于在内循环中增加强大的用户定义功能 。
2.3 应用于大数据的数据建模最佳实践
以下最佳实践影响数据的逻辑和物理结构 。
-
维度思考
从维度角度考虑 ，我们将世界划分为维度和事实 。业务用户可自然且直接地发现维度概念 。无论数据的形式如何 ，基本的关联实体 ，例如客户 、产品 、服务、位置或时间 ，都能被发现。在后续的最佳实践中 ，经过一些训练 ，您将发现维度可用于集成数据源 。但在达到集成的终点线前，必须识别每个数据源中的维度并将它们与每个低层的原子级别的数 据观察关联。这一维度化的过程是大数据分析的很好应用 。例如 ，简单的推特语句 “ 哇 ！ 这太可怕了 ！” 也许没有包含有价值的维度特性 ，但是在某些分析中 ，您可能会得到客户（或 市民或病人）、位置 、产品（或服务或合同或事件）、市场条件 、提供商 、天气、支持者组（或 统计聚类）、会话、触发先前的事件 、最终结果以及其他结果 。保持领先的数据流需要某些 形式的自动维度化 。正如我们将 在后续 的最佳实践中指出的那样，输入数据应当在最早的 获取步骤 中尽可能实时地被完全维度化。 -
集成不同的包含一致性维度的数据源
一致性维度是将不同数据源捏合到一起的粘合剂 ，确保合并不同的数据源并用于单一的分析。一致性维度也许是大数据从传统的 DW/BI 世界中可继承的最强有力的最佳实践 。
隐藏在一致性维度之后的基本思想是维度不同版本中的一个或多个企业属性 （字段）与不同数据源的关联 。例如 ，企业中每个面向客户的过程将包含一些变化的客户维度 。客户维度的这些变化可能涉及不同的键，不同的字段定义，甚至不同的粒度 。即使数据不兼容的情况非常显著 ，一个或多个企业属性仍可被嵌入到所 有不同的客户维度中 。例如 ，客户统计分类是一个合理的选择 。这类描述符可以被定义到差不多句个客户维度中，即使在那些高级别的聚集维度中。在实现该设计后 ，针对这样的客户统计维度的分析，可以在针对不同数据源分别运行不同的查询后 ，.通过排序融合过程跨多个数据源开展 。最好的情况 1 引入不同的企业属性到不同 的数据库中的步骤，增量的、敏捷的 、非破坏性的方式完成 。当一致性维度内容可用后 ，所有己有的分析应用可以继续运行。 -
使用持久性代理键定位维度
如果说在数据仓库世界中包含一个我们需要吸取的教训的话 ，这个教训就是，不是采用特定应用所定义的自然键来定位客户 、产品及时间。这些自然键将成为现实世界中 一个 骗人的圈套 。多个应用之间的自然键是不兼容的且难于管理 ，这些自然键是由那些不关心数据仓库应用的其他人员所管理的。在每个数据源中，首要的步骤是使用企业范围的持久性代理键来扩展来自于源的自然键 。持久性的意思是业务规则无法对该键做出改变 。持久性键属于 DW/BI 系统 ，而不属于数据源 。代理意味着该键本身是简单的整数，该数要么是按顺序分配的 ，要么是通过能够保证唯 一性的健壮的哈希算法建立的 。孤立的代理键不涉及与应用有关的内容 ，它仅仅是一个标识符 。
大数据世界充满了各种各样的维度 ，这些维度必须拥有持久性代理键 。在本章前面的 内容中，当提出将数据推入数据高速公路时 ，我们依靠持久性代理键来实现这 一过程 。我 们还指出 ，每个从源数据获取的过程 ，其首要的任务是在适当的维度中嵌入持久性代理键 。 -
期望集成结构化与非结构化数据
大数据极大地拓宽了集成面临的挑战 。许多大数据不会存储在关系数据库中，一般会存储在 Hadoop 或网格中 。但在您考虑并实现了 一致性维度和代理键后 ，在单一分析中可 以分析所有形式的数据 。例如 ，医学研究可以选择 一组具有统计特征和身体状况属性的病 人，然后将其传统的 DW/BI 数据与图像数据（图片 、X 射线影像 、心电图等等）、自由文本 数据（医嘱）、社会媒介的意见（治疗建议） 、队列组分类（具有类似情况的病人）以及 具有类似病人的医生等信息合并 。 -
使用缓慢变化维度
应当跟踪随时间变化的 缓慢变化维度（SCD）情况 。跟踪维度 随时间变化的情况是一种 己有的受到广泛赞誉的数据仓库世界中的最佳实践 。第 5 章讨论了使用 SCD 技术处理时间 差异的完整案例 。与在传统的数据仓库世界中 一样 ，该技术在大数据世界中也非 常重要。 -
在分析时定义数据结构
您必须习惯在分析时定义数据结构 。大数据的魅力之一是将数据结构定义推迟到加载 到 Hadoop 或网格时进行 。这样做会带来很多好 处。数据结构在加载时尚未被理解 。数据具有如此富有变化的内容 ，以至于单一的数据结构要么没有意 义，要么迫使您修改数据以 适合某一结构 。例如 ，如果可以将数据加载到 Hadoop ，不定义结构，则可以避免资源密集的步骤。最后 ，不同的分析师可以合法地以不同的方式 看到同样的数据。当然，某些情况 下会存在一些问题 ，因为没有明确定义的结构可能比较困难或者难以为 RDBMS 中快速查询建立索引。然而 ，多数大数据分析算法处理完整的数据集 ，不需要精确地过滤数据子集 。
这一最佳实践与传统的 RDBMS 方法论冲突，传统方法强调在加载前细致地建模数据 。 但这样做不会导致产生致命的冲突。对那些将去往 RDBMS 中的数据，从Hadoop 或网格环境或者从名称值对结构转换到 RDBMS 命名列中可以当作是有价值的 ETL 步骤。 -
以简单的名称值对加载数据
考虑围绕名称•值对数据源的建立技术 。大数据源充满惊喜 。多数情况下 ，您打开消防水管将发现意想不到的或未文档化的数据内容 ，尽管如此 ，您必须以每秒几 GB 的速度加载 。避免产生这一问题的方法是以简单的名称，值对方式加载数据 。例如 ，如果某个申请者暴露了其金融财产 ，他可能会定义某些意想不到的事情 ，例如 “ 稀有邮票 $ 1000 ”。在名称值对数据集中 ，这一信息将被轻 松地加载 ，即使您决不会看见 “ 稀有邮票 ” 且不知道加载时会对其做些什么工作 。当然，这一实践与前述 的推迟到数据 加载时定义数据结构的实践结合得很好 。
多数 MapReduce 编程环境需要将数据展现为名称值对 ，这样做使大数据具有完全可能的一般性 。 -
利用数据虚拟化的快速原型
考虑采用数据虚拟化以获得快速原型开发和模式转换 。数据虚拟化是 一种针对基本物理数据定义不同逻辑数据结构的强有力技术 。以SQL 方式定义的标准视图是数据虚拟化的良好实例 。理论上讲，数据虚拟化可以以任何分析需要的格式展现数据 ，但是使用数据虚 拟化要考虑权衡 运行时计算的开销与运行前建立物理表的 ETL 开销 。数据虚拟化是构建原 型数据结构 、快速建立可 选方法或提供不同选择的强有力的方法 。最好的数据虚拟化策略 是在需要测试和审查以及分析 人员希望改进实际物理表性能时物化虚拟模式 。
2.4 大数据的数据治理最佳实践
以下最佳实践应用于管理大数据 ，以使其成为有价值的企业资产 。
-
没有作为大数据治理这样的事情
数据治理必须是一种针对企业整个数据生态的综合处理方法 ，不是大数据某个孤立点的解决方案 。大数据的数据治理应当是用于管理所有企业数据的扩展方法 。至少，数据治理包含隐私、安全、兼容性 、数据质量 、元数据管理 、主数据管理以及向业务团体提供定义和环境的业务术语表 。 -
应用治理前的数据维度化
以下是一个有跑的挑战大数据的介绍 ：即使您尚不知道希望从数据内容中得到什么 ， 也必须应用数据治理原则 。您可能每分钟接收几 GB 的数据 ，通常都是以名称值对方式的意料之外的内容 。对您所承担的数据治理责任来说 ，最好的分类数据的方法是尽可能在数据流水线的早期阶段将其维度化。分析内容、匹配内容并同时应用身份识别 。在争论数据集成的效益时我们给出了同样的策略 ，但这里主张在维度化步骤前反对使用数据 。 -
隐私是最重要的治理考虑
如果您分析的数据集包括有关个人或企业的辨识信息 ，则隐私是最重要的治理考虑。尽管数据治理的每个方面交织在 一起都显得非常重要 ，但在这些情况下 ，隐私富有最重要 的责任和业务风险 。个人或小组的隐私如果发生令人震惊的事件 ，其影响可能会破坏您的名誉，降低市场的信任 ，导致民事诉讼 ，使您陷入违犯法律的困境 。至少，对多数分析形式来说 ，个人细节必须被屏蔽 ，数据将会被聚集以便无法区分个人的情况 。在将敏感数据存储到 Hadoop 时，必须特别注意，因为数据在被写入Hadoop 后 ，Hadoop 不能很好地管理数据更新 。在写数据时 ，数据应该被屏蔽或加密（持久性数据 屏敲），在读取数据时 ，数据应当被屏蔽（动态数据屏蔽） 。 -
不要选择大数据治理
不要将大数据治理推迟到使用大数据的高峰期开展 。即使是开展大数据原型项目 ，也要维护问题列表，用于考虑什么时候 需要进行下一步工作 。您不想成为低效的官僚机构 ， 但也许您能够提供一个灵活的官僚机构 。
参考:
- 《数据仓库工具箱 维度建模权威指南》第三版