背景

在我上一篇文章《搭便车的大数据指南》中，我们探讨了大数据与商业智能的区别和相似之处，以及为什么两者相互正交。

基于这些知识，本文建议开发一个适合大多数用例的架构。它强调灵活性，但也考虑到开发和运营成本。

大数据空间的标志图是FirstMark的"大数据景观"（下图）。它列出了大数据领域各个方面的主要参与者。（全文可在此处找到）

这一概述让我们了解所有工具—它们各自的优缺点和挑战—然后找出何时使用哪些工具以及如何将它们结合起来。

要开始解决这一问题，首先让我们缩小一些术语范围。

报告-数据仓库-数据湖

从数学上讲，分析数据无非是从源中获取一组数据，应用一个函数并将结果可视化：y=f（x）。

示例：数据集"x"应为ERP数据库中的销售数据。函数：一个总和，按客户所在地区分组，结果"y"以条形图的形式显示出来。

这与报告中的情况基本相同——有一个重要问题：ERP系统获得新数据——很好——但数据也经常更新。我的典型例子是，当一个客户从一个地区移动到另一个地区，突然整个过去（！）销售收入归于新地区。当两个相同数据的报告显示不同的结果时，这不是一件好事。

解决方案是建立一个数据仓库，在那里数据被维护并且历史上是正确的，因此将有两个版本的客户记录，其中包含有效的从到日期。复制数据的一个积极的副作用是，可以将函数f（）拆分为经常使用的公共部分和可视化特定部分。销售收入的计算就是一个例子。为什么每一个查询都要执行if-then-else决策树来找出哪些对销售收入有贡献，哪些没有？最好将销售收入存储为附加值，然后BI查询只是一个总和（收入）。另一个优点，虽然纯粹是技术上的，但是数据仓库可以有一个简化的数据模型来提高查询速度。数据结构良好，易于查找（得益于简化的数据模型），快速查询和查询不会减慢ERP系统的速度，因为它们运行在不同的服务器上。

这是数据仓库的价值主张，它仍然有效。

这两种方法都假设源数据集"x"是预先知道的，并且其结构在过去几年中只发生了一点变化。虽然这个假设对数据库是有效的，但在大范围内这是一个严重的限制。从应该匹配但不匹配的Excel工作表开始。以完全非结构化的文本结束，所有内容都不同。在报表和数据仓库的世界里，必须有人创建一个通用的、一致的数据模型，然后将数据压缩成语义优先、内容优先。

数据湖的方法是相反的，首先是内容，然后对其应用语义。或者在更实际的情况下，存储原始数据并提供工具供用户使用。

在实际操作中，由于数据的信息类型多、数据量大、每个消费者都需要知道的规则多，许多数据湖更多的是一堆烂泥。当然，有金子埋藏在深处，大数据风控，当然任何工具都可以使用，但找到它需要大量的挖掘。

这并不一定意味着数据湖是一个失败的提议，尽管它需要更多的资源。它需要更多的元数据来引导用户去感兴趣的地方，更强大的工具，更多的知识和消费者的整体体验。更不用说，由于内容和结构转换都是在查询时完成的，所以处理能力更强。简言之，数据湖通常是为数据科学家而不是普通用户提供的。

另一个区别是两者的存储成本——在数据仓库数据库中存储一TB的数据要贵得多。存储一PB的数据几乎是不可能的。不过，对于大数据系统来说没有问题。

再加上即使是数据仓库系统也往往有一个暂存区，因此将数据仓库作为商业智能平台与大数据存储作为数据湖相结合。DWH暂存区是有意义的。

数据仓库体系结构

概括地说，在经典的数据仓库体系结构中，会有结构化的数据源，如ERP系统、Excel表格等。通过ETL工具每天从源系统读取这些数据，并将其转换为数据仓库模型，以获得DWH的所有优势。数据量过大的数据源（例如web日志）通过预定义的逻辑进行聚合，这些数据也存储在DWH中。

通常不加载非结构化数据。如果有预定义的规则，例如，源是一个网络论坛和文本分析过程提取情感结合字典，那么没有问题。另一方面，如果必须更改文本分析配置或其字典以更好地适应单个查询，则无法实现此目标。

进化1–大数据作为暂存区域

下一个逻辑步骤是保留所有数据并使其可用。在这里，国内大数据，所有的数据源都将其数据贡献到数据湖中，包括日志和非结构化数据，并且有两个消费者：数据仓库和数据科学家。

注意：数据湖不是源系统的副本，它总是附加到数据中。因此它在历史上也是正确的。