大数据一体机融入数据仓库架构的解决技巧(3)

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

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

    灾难恢复问题

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

    1.你的公司已经部署了大数据一体机；

    2.业务分析人员和用户开始查询数据；

    3.很多查询产生的结果导致更低的成本和更合适的价格；

    4.查询运行迅速，如此之多的分析人员开始执行很多查询；

    5.随着更多的查询产生可执行结果，管理方认同它们的价值；

    6.每周一次性的查询开始运行；某些查询成为日常报表；

    7.在管理中有价值的日常报表结果数量指定大数据解决方案并分析为“关键任务”。

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

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

    最初的部署问题

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

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

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

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

    总结

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

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

（编辑：ASP站长网）