实时数仓有必要吗？

传统的数据仓库或者数据集市并没有包括当前最新的数据，其数据是按周甚至按天导入到数仓里面的。然而，有一些公司已经开始着手建设实时或近实时 BI 数据库了。

乍一看，实时 BI 似乎是继传统数仓之后合乎逻辑的下一个阶段，毕竟只要数据越“新鲜”，我们就能从中得到越优质的信息，那为什么不把 BI 系统升级成实时的呢？

答案就是相对于其价值来说，这样做其实更麻烦。试图在 BI 数据库上对数据进行实时更新简直就像是打开一个装满蠕虫的罐子。就算你真的能将这个系统做好，那也是非常困难的，代价也将会非常大，而且还会在原本就已经很复杂的处理流程里引入一堆数据一致性问题。

你的数据仓库真的需要实时数据么？大多数情况下答案是“不需要”。不像操作性数据库必须保证足够实时，数据仓库或者数据集市一般并不需要绝对实时的数据就足以完成数据分析的任务了。当然高频交易的金融交易市场是个例外。

一个主要问题在于现有的 BI 工具并不是为实时数据设计的，几乎所有的 BI 工具都被设计成批处理方式。当然有些比较新的工具可以处理实时或者近实时数据，但也只是极少数，大多数工具还是不行。

这个问题对于那些 ETL 工具来说更是如此。 一般在处理好数据并将数据加载进数据库时都会让数据库暂时不可用，所以一般这种操作都会避开业务高峰时段，这样避免对业务产生营销。

实时 ETL 则会在数据库还在响应查询的时候执行，这会导致一系列数据完整性的问题，并且需要在设计 ETL 工具的时候就必须考虑到这个问题。数据持续的更新也使得我们很难维持数据的实时同步。

一个解决方案就是提高数据加载频率从而实现近实时的更新。周级别的数据加载可以提升到天级别，天级别可以提升到一天两次，相比实时更新，这可能是更加容易同时成本更低的一种方案，至少这样不需要更换一整套 ETL 工具。

如果实时的性能非常必要的话，那么整个系统架构和工具集就一定需要做很大的改变。一个方案就是在数据被加载到主库之前构建一个暂存区，或者也可以在主数据库增加独立的表或者通过在独立服务器上运行独立数据库的方式构建一个影子系统。无论采用那种方式，总之就是让 ETL 操作在一个作为替代的从库上执行，并只将清洗干净的数据加载进主表。

构建一套影子系统的成本将会非常大，因为他本质上相当于复制了一套数仓，当然这样的话对性能的影响就比较小。

请注意，不管怎么样都可能会在主库执行数据加载的时候影响查询性能。

另一个需要考虑的问题是缓存。很多数据仓库都使用了各种各样的缓存来加速查询，但是在一个实时系统里面，这些缓存就会持续不断的被更新已保证数据完整性，而且更新缓存的过程一般来说都相对较慢，所以这样也会使得数据仓库性能受到影响。

基本上构建实时数仓就是一个典型的 “last nine”[注] 问题的例子。结果是令人期待的，但同时在性能优化上面的付出和收益也是不成比例的。这就让实时数仓变成了一个成本-收益问题，所以尽量多研究研究你做实时数仓的收益是否大于你将付出的成本。

---

关于作者

Rick Cook 从打孔机和磁鼓存储器时代就开始从事计算机科学，他撰写过上百篇计算机相关的文章，也写过一系列充满计算机笑话的科幻小说

本文翻译自：Real Time Data Warehouse - Is It Worth It?

[注]：我暂时没查到 “last nine” problem 是个什么梗