大数据应用现在在大型组织中已经非常普遍。它们通常一开始作为一个信息技术（IT）项目的组成部分，这种项目是通过提取、存储和分析大量现有数据来减少开支、预测客户购买模式、加速产品投放市场速度及预测原料与生产容量需求。

然而，我们很难直接将这些应用直接“丢到”现有IT基础架构中，然后就预期它能正常运行。支持新大数据应用的新硬件需要增加能源与制冷需求，另外还有其他IT领域也需要准备。决定是否需要强化现有应用的主要因素包括大数据存储需求、更大数据传输容量及其对现有硬件软件的要求。

大数据基础知识

大数据包括采集、转换和存储大容量数据，以及后续的分析工作。为此，大多数组织会采购一个或多个成型的供应商解决方案。一个流行的选择是IBM DB2分析加速器（IDAA）——一个来自IBM的硬件软件混合解决方案。硬件（有时候称为设备）包括一个容量为几TB的专用硬件机架式磁盘存储阵列，以及用于传输企业存储数据的高速网络线路。在数据存储到设备之后，我们就可以像访问数据库一样访问这些数据。

在设备安装之后，它就会加载来自生产系统的数据。这个设备与数据管理系统（这里是DB2）将会协调数据查询。如果有一个查询发向存储在设备中的数据，那么这个查询会非常快速。正是这种性能优势促使组织决定购买这种设备。大规模数据需要更长的分析时间。这种分析查询在标准数据库表上可能需要运行几个小时，而访问这种设备的同等规模数据则只需要几分钟（甚至几秒钟）。

这种复杂的大规模硬件解决方案需要消耗大量的电力。基础架构团队必须检查电源需求，确定当前的电路是否有能力处理增加的负载。另外有一点：大多数IT硬件安装过程都会增加一些备用发电机，以减小断电风险。这些发电机也必须经过检查，以确保它们能够给设备提供所需要的额外电源。

架构需求

除了前面提到的电源问题，IT人员还必须解决以下问题。

这个设备是否只存储生产数据？如果是，这是否意味着必须用生产数据去测试这些分析查询？如果不是，那么应该如何测试这些查询，又应该用什么数据进行测试？

如果你的大数据解决方案是（成为）组织的关键任务应用，你是否会考虑在灾难恢复环境中安装一个设备？如果会，那么应该如何保持灾难恢复网站中大容量数据与当前数据的同步？

如果选择一个只存储当前部分生产数据的解决方案，那么应该用哪些条件来将数据加载到设备中？换而言之，如果设备中的数据要支持高速查询，那么设备里应该创建哪些数据表？

其他架构需求围绕在大容量数据的处理与移动需求上。数据必须从源系统提取，经过验证、转换，然后再加载到数据库与设备中。自然地，更大容量的数据迁移会导致以下需求：

1.网络扩容，其中可能包括要增加传输数据的并行数据通道；

2. 新的更大存储介质，通常是磁盘阵列形式，用于存储主数据和备份数据；

3.升级为数据库自动管理流程，如数据库备份、恢复、重组、索引维护等等；

4. 增加人手去管理与监控上面提到的方面。

升级数据仓库架构

有时候，新大数据解决方案的初始分析过程往往会漏掉的是重新检查和升级当前的数据仓库环境。数据仓库业务分析师已经知道这一点：用于分析大容量数据的业务分析查询通常需要按类别或维度去分析数据。这还不足以预测哪些产品可以卖出；你必须按照地理位置、客户类别、产品类别、时间段（如季节）等对数据进行汇总。这些维度已经在数据仓库中；而且，当前的分析环境（其中包括常规报表和特殊用户）已经包含了使用这些维度的许多查询。

任何大数据分析解决方案都需要整合数据仓库，而这种整合会带来一些问题。

设备初始数据。设备保存了许多数据。将数据加载到设备中需要多长时间？后续数据更新是以同步方式执行，还是在一些深夜批处理周期中加载？

老数据存档。数据仓库存档流利的当前状态是什么？老数据、旧数据或无用数据多长时间清理或存档一次？这将如何影响设备中的数据？是否有办法从设备清理大量的数据？

灾难恢复。如何备份设备中的数据？在其他存储介质中是否有足够数据所有数据的空间？在遇到灾难事件时，需要多长时间才能恢复数据？

性能与增长。用户会非常满意查询的快速执行时间。或许他们会因此提交更多对于更大规模数据容量的查询。随着用户对越来越大规模的数据执行越来越多的查询，设备是否能继续保持良好的性能？要如何监控这种性能，现在有什么性能优化方法可以用？

制定一个整合规划

企业准备大数据应用需要一个规划。一个常用的方法是先解决大的整合问题——数据仓库。要考虑数据如何通过数据仓库的。映射这个数据流的常用方法是提取、转换和加载。提取是指从源系统获取数据，转换包括对数据的所有修改、修复和汇总，而加载则是指将数据加载到数据仓库中。

源系统

这些系统包括核心运营系统。这些系统会产生事务数据，其中一些数据会被提取并发送到数据仓库中。一个大数据解决方案可能会在这些提取的数据中加入一些额外信息，或者加入一些全新的数据源。

IT组织可能会决定在这里实现一个大数据解决方案，直接从生产系统提取数据，用于快速存储和分析。然而，这个方法有一些缺点。由于数据还没有转换，所以其中可能有许多数据元素值是无效或缺失的。此外，这些数据可能还没有存储到数据仓库中，所以可能很难将大数据解决方案中的数据匹配到数据仓库中的数据。最后，支持生产应用的人员可能还没有分析数据的专业知识。

如果必须在这里实现一个大数据解决方案，一定要在一开始就吸纳一些生产系统支持人员参与其中。让他们参与讨论和设计决策，其中包括如何将这些数据与当前数据进行比较及合并在一起。一定要将所有域和转换过程记录在一个数据字典中。

数据迁移与转换

数据元素从源系统提取出来后，它们可能需要进行修复或“清理”。这其中可能会有数据缺失或无法数据项的问题。如果一个日期域的值只剩下一些数字0，该如何处理它？这个域不允许出现这些值；分析查询可能是按月份或按日期范围来查询数据的。显然它需要指定一个默认值。其他的问题有数据丢失，或者需要用另一个系统来验证数据有效性。其中一个例子就是包含主键值（如产品编号）的客户订单数据。

另一个问题是外部数据。这其中包括从外部供应商获取的数据、网页数据和表单数据等等。一些常见问题是数据丢失、数字值中出现非零字符及一些需要解析才能获取细节的自由形式文本域（如包含街道、城市、州和邮编的地址域）。这些数据域需要经过一些转换才能解决数据问题和分配默认值。

数据仓库有一个标准的数据转换流程。许多转换都是根据多个数据源的多个数据域进行标准化而得到的。（例如，丢失数据或无效的过期日期域可能会设为12-31-2099.）

在这里实现的任何大数据解决方案都必须有一些映射或复制流程，用来完成已有的标准数据仓库数据域的转换。正确完成这一步的关键是用文档准确记录下当前的逻辑。

将数据加载到数据仓库

这是大多数大数据解决方案实现的位置。IT专家会将设备安装到数据仓库流程可以访问的位置。在数据进入数据仓库之后，当前的数据库加载流程会强化，支持将数据加载到设备中。现在用于分析的数据已经准备妥当。

各个重要流程之间还需要协调一致：数据加载、设备加载和用户分析。即使是高速硬件和大容量数据存储，加载数据也需要一定的时间。在这段时间里，新数据或数据库中的其他数据是否能够保持可用状态？在数据仓库或设备不允许访问的时间里，是否有一个确定的加载“时间窗口”？

小结

前面提到的问题是关于将大数据解决方案整合到现有IT企业的主要问题。虽然规划大数据硬件的物理实现是非常重要的，但是同样重要的条件是要规划现有数据仓库的整合过程。执行分析的用户已经懂得查询数据仓库，所以扩大可能的数据域也自然成为其中一个需求。数据仓库已经存储了大量的数据，所以对于数据库管理人员来说，维护另一个大规模数据存储通常不是一个很困难的问题。

将一个大数据解决方案整合到数据仓库的关键点是大数据解决方案总是需要与现有数据仓库的维度数据（如地理区域和时间周期）进行比较和汇总。实现人员与数据仓库支持人员之间的紧密协作是成功实现企业大数据应用的关键因素。