实时数据集市和商业智能解决方案不再是一件稀奇事或者是奢侈事情了。这些解决方案已经不是处于萌芽状态，他们已经成为一种仪器工具性质的了，对于一些公司组织保持它们在核心业务中保持竞争力起到关键作用。在过去

几年，涌现出了一些工具，不过都是一些不太成熟的解决方案，到现在的一经请求就响应，实时商业智能解决方案看起来似乎是小菜一碟。但是，实际中并不是和我们想象的情景是一样的。

当你为自己的公司设计一个实时商业智能解决方案时，你会遇到什么样的挑战呢？很明显你会遇到下面的一些挑战：

在实时刷新数据集市的同时还要有高性能的提供分析信息的能力

实施实时商业智能成本费用与收益的比较定位

对一个或者更多源应用程序性能的影响

能否实时执行ETL过程中的所有变换

上面仅仅是众多挑战中的一小部分。在实施实时商业智能解决方案是，我们发现的最大的挑战不仅仅是工具和技术。那么什么是最大的挑战？有什么规则我们应该去遵守了？

对实时这个定义要格外小心。在绝对术语中，没有一个真正的实时商业智能解决方案。非常荒谬的是，实时商业智能并不是像有些商业大肆宣传的那样的。实时的定义和一个公司组织的信息需求有关。对于一些组织，实时响应定义或许在一分钟之内，然而其他的一些组织，瞬时响应的需求或许要在几毫秒。对于任何一个给定的方案，不要忘记原系统采集数据变化所需的时间，执行ETL过程和频繁缓存访问报表所需要的时间。在总的响应时间中，生命周期中的每一步都需要计算它的开销的。想想每一步中数据集成和呈现解决方案所需要的时间，还能称之为实时的吗？但是，大多数此类的商业智能解决方案处理信息需求的时间是到分钟的级别，或者延迟到几分钟的级别。对于一些实际的需求，把它标榜为实时的也不为过。

最大的挑战就是从一开始实施就能保证每个人的预期效果都是一样的。本质上说就是确保每个定义实时的标准都是一样的。

一、确定信息的实时需求

如何把握区分必须实时，最好实时，不必全部实时的分寸了？想避免每个单独的信息在实时数据集市中实时刷新的想法是很困难的。大多数的实时商业智能的解决方案可以分成全部实时，非全部实时。你要能，并且必须能区分哪些信息元素要全部实时，执行实时的时间是一天，一周，或者是一个月刷新。

考虑一下一个销售的解决方案，这个方案实质上就是每月生成报表，本年度截止到现在的销售情况。当源应用程序有一些改变时，数据集成引擎将要把这些销售变量加入到实时数据市场，计算出相应的结果。但是，在这个解决方案中，员工这个变量因素的刷新频率有多少了？

让我们假设员工这一因素的一些属性从一个人力资源的应用程序得来，这个人力资源应用程序反应员工的偶尔变化，这些数据元素对销售分析并不是很至关重要。那么在这个解决方案中，或许就可以将员工这一因素分成两个成分。从事务系统中得到一些必要的员工信息（如员工ID等）。至于其它的属性如办公地点就可以放在一边。这中安排就可以减少实时ETL过程加载量。同样的，如果你只需要一些月报告的快照，你就可以每月构建一次。

在实时商业智能解决方案中你需要设计一个瘦的数据集。针对每个刷新频率绘制一条线，决定那些信息应该是实时的，那些能够让其等待是成功实时数据集市解决方案的关键。在进行分析和高水平设计阶段，这些需要尽快解决。

二、不要弄巧成拙

从任何源应用程序捕获数据最简单的方法就是实时读入源系统数据。但是，并不是有很多的应用管理程序允许你这么做。因此访问源应用程序的选择是很有限的。

大多数的实时集成工具有一个实时数据复制引擎。和这个引擎一起有一个单独的价格标签。这个实时数据复制引擎影响到数据库日志。有了这样的一个工具就可以让开发团队的工作轻松，有数据库提供商提供的数据库本地复制器将会是一个简单，有效节约成本的解决方案。

这种实时数据收集的另一种替代方案就是使用数据库触发器。如果这种选择没有使得院系统在性能和维护上负担加重，比起使用单独的工具，这将是一个好的候选办法，因为成本和维护费用更低。在不影响源系统性能的前提下，这种触发器可以提交在源系统的变化信息到一个单独的集结地，而实时数据集成引擎能不间断的从这个集结地去读信息。

一些需要从多种系统整合的数据容量和刷新周期，能够方便的由标准的ETL刷新策略所处理，这些策略包括数据库触发器，复制和其它一些机制。即时这里出现交替机制需要等待几分钟，可以考虑实施单独的实时复制工具。

三、进行信息图像化

商业智能解决方案最紧要的就是实时移交信息。因此提供一个可视化的图案就更好了。由于商业智能中数据可视化重要性越来越受关注，分析仪表板不再认为是一个可有可无的工具了。当可以以数字化，统计来呈现一个事实的时候，有仪表板就会更好，就像企业拥有了一只鸟的眼睛，对事实的把握程度更准确。