大数据一体机能融入数据仓库架构

ZDNet至顶网服务器频道 01月24日 ： 随着我们可以访问的数据越来越多，企业已经开始将大数据存储到企业数据仓库（EDW）中。它要求数据库管理员（DBA）和相关支持人员对数据仓库架构进行重新设计。

使用高级分析工具来对业务数据进行分析是很常见的，特别是对于有很多面向客户系统的大型企业。随着我们可以访问的数据越来越多，企业已经开始将大数据存储到企业数据仓库（EDW）中。然而，这些大数据部署带来一系列的问题，它要求数据库管理员（DBA）和相关支持人员对数据仓库架构进行重新设计。

大数据时代

在当今的商业化的IT系统中，我们会收集存储越来越大量的数据。同时要能够获取、分析这些数据，大多数企业开始转向专有硬件、软件解决方案。这也是一体化设备开始流行的一个原因，针对特定应用场景的硬件数据存储与业务分析软件的耦合度越来越高。比如IBM的DB2 Analytics Accelerator（IDAA），即IBM DB2分析加速器。

这样的解决方案通常十分昂贵。大数据存储需要扩展磁盘和内存阵列，高性能访问则需要大量CPU资源加上复杂的数据访问以允许多个进程并行访问数据集的各个部分。

在实现这样一个解决方案之前，企业需要确认并解决以下问题。

基础设施需求

就拿IDAA来举例，它是一个软硬件解决方案的混合产物。其硬件包括一个大型磁盘存储阵列并结合可进行大规模并行处理的软件。技术支持人员要指定哪些DB2表要在设备中加以复制和存储，及其刷新机制。然后软件会与DB2数据库引擎相连接，使得查询可以访问设备中的表备份，这可以提供更快的访问速度。

除了电力和冷却这些标准问题，在部署这样一个设备之前，IT人员必须考虑多个架构方面的问题。

IDAA只会存储生产系统的数据吗？还是说也可以存储测试数据？换句话说，DBA和业务分析人员要怎样开发并测试他们的数据分析查询。

究竟需要多少设备呢？例如，如果在IDAA上正在执行的数据分析是公司关键任务，那么是不是需要额外的设备进行灾备？

虽然IDAA可以存储大量数据，但只能对访问设备中存储数据的查询进行提速。那么系统中要存储哪些表呢？

特定的用例

超快的数据分析听上去不错，但很多企业尚没有为分析开发特定的查询或系统。这就导致了很多时间花费在数据加载和查询测试上，而没有产生切实的成果。

合理成本会迅速转化为效益吗？

大多数业务数据分析包括以下一系列步骤：

1. 业务分析人员审查报表，查询以及其他数据并形成基于他们分析的逻辑问题；
2. 然后开发一个或多个查询用来分析大型数据存储；
3. 执行查询；
4. 分析人员审查并阐释结果。

一体化的解决方案可以显著减少步骤3的执行时间。但是，其他步骤依然存在。例如，假设以上的每个步骤要耗费一小时，那么总的消耗时间就是四小时。部署一体机可能会将查询执行时间减少为几分钟。虽然这是一个非常显著的时间降低，但是总时间也只缩减为三个小时多一点。

总之，减少查询执行时间肯定是有好处的，但是可能不像之前所认为的那样效果明显。

业务数据“消费”群体

大多数业务数据“消费者”可分为以下三类：

1. 技术用户直接运行查询。这些用户会使用SQL针对数据表创建查询，然后使用一个在线SQL执行工具来运行查询并在原始数据表格中生成结果，这样他们便可以直接观察或是下载到一个电子表格以供进一步分析之用。这些用户熟悉这些数据表，拥有SQL相关知识，并且会用简单工具来提炼结果。
2. 复杂报表分析人员。这些消费者通常会使用一个复杂的报表工具来显示数据的一个图形数据模型。然后他们会通过拖拽表和字段到一个报表窗口来操纵此模型。此工具接着会创建基于模型和其他参数的适当SQL语句，执行此查询，并显示结果。这些用户熟悉数据，通常不具备SQL专长，而且需要一些高级查询和统计报告的技术。
3. 数据集市的消费者。这些用户拥有他们自己的高度专业化的业务数据分析软件。他们会直接从源头提取业务数据并将之存储在一个本地服务器上。然后他们会使用专门的软件来分析数据

任何一个大数据解决方案都必须将这些不同的群体需求考虑进来。

部署过程中的问题

在部署一体机的过程中，IT人员通常会遇到一些常见问题。

• 相互矛盾的问题

如果我们尚未对其进行分析那么我们要存储些什么呢？如果我们还没有数据那么我们要分析什么呢？业务并不会完整的理解什么数据会是可用的，并且IT支持人员并不了解在一个大数据解决方案中什么样的业务数据对于整个部署来说是最为有用的。

这两个问题通常是缺乏特定用例或是IT与业务部门间缺乏交流所导致。

• 批量数据加载问题

大多数一体机支持大数据解决方案并能承受超大量的数据。最常见的问题之一就是究竟要花多长时间将那些数据加载到一体机中？

一旦数据被加载，其他批量数据问题就出现了：我们要如何才能保持数据是最新的？我们要如何清除大量过期和无用数据？

这些并非新问题。有经验的IT人员一定不会陌生，其中之一便是灾难恢复（DR）准备。如果突发灾难（火灾，洪水等）在主站点发生，那么典型的灾难恢复站点就必须在数小时内准备好，来顶替主站点。对于当今大量的业务数据来说，最为常见的技术解决方案就是去维护一个在DR站点当前业务数据的完全备份，而此DR站点是通过网络连接和软件将主站数据“镜像”到DR站点的。

有了一个大数据解决方案，IT人员就必须找出一种方法通过数据镜像，定期数据加载和定期数据归档工作的组合来让一体机中的数据保持新鲜。

• 灾难恢复问题

大多数数据仓库是用来进行分析和报表之用，并非用来处理客户事务之类的业务数据。一个大数据一体机通常会连接到数据仓库，所以这并不是通常所认为的在DR站点所需要的东西。但是，在此之前，让我们来考虑以下场景：

1. 你的公司已经部署了大数据一体机；
2. 业务分析人员和用户开始查询数据；
3. 很多查询产生的结果导致更低的成本和更合适的价格；
4. 查询运行迅速，如此之多的分析人员开始执行很多查询；
5. 随着更多的查询产生可执行结果，管理方认同它们的价值；
6. 每周一次性的查询开始运行；某些查询成为日常报表；
7. 在管理中有价值的日常报表结果数量指定大数据解决方案并分析为“关键任务”。

然而，IT人员会突然被告知如果灾难发生，大数据存储必须是可用的。

要为企业中所发生的这些做好准备，需要在部署的开始阶段审查存储需求，网络容量，硬件能力和容量以及软件许可需求。要让这些数据在变得关键之前进行发布并使之可用于管理。这会让你的企业提前为其需要做好预算和规划。

• 最初的部署问题

你也许要部署一台进行大数据分析的一体机。通常来说，这些数据并非在当前收集或存储在数据仓库中，因为这些数据太大了。相反，这些数据是作为当前可操作数据的一部分来存储的。一些例子包括语音响应记录和点击数据，在线互动和设备传感器数据。

这就引出了一个有趣的想法：首个分析会是在原始生产系统数据上，而非在数据仓库中。这是一个诱人的想法。你可以摈弃在数据仓库中进行获取，转换，以及存储大量数据所耗费的成本和时间。数据可以马上被访问，而不用忍受相关的正常数据仓库的数据暂存和加载所带来的延迟。

然而，直接的生产系统数据访问会产生问题。某些生产数据可能是非完整的或是缺失的，亦或是一种不易访问的形式。某些数据可能是无效的，就像一个类似“99-99-9999”的日期数据，或是一个金额字段包含字母。其他数据可能会需要解释，例如一个代码字段包含0，A或C。

另一个问题是，大部分的大数据分析取决于称之为维度的跨类型数据聚合。例如，客户订单数据可能会由地理区域和产品类型加以归纳。这些维度存在于数据仓库的表中。为了成功执行这些查询，它们必须对完全在一体机中的数据加以操作。这就意味着数据仓库数据必须存在于一体机中为查询而工作。

总结

目前大多数高级分析解决方案都能够应对大数据挑战。高速一体机会通过显著缩短查询时间来为业务用户创造价值。但是，最好的架构解决方案会要求一体机作为数据仓库的一部分。

将大数据一体机整合到一个数据仓库需要充分准备和深谋远虑。DBA和业务数据客户必须协同工作一起确认以上实现过程中的问题并来满足多种业务数据客户的需求。