关于数据仓库建设，了解这7点就够了

编辑导读：在数据分析中，实时数据仓库很重要，它决定了报表和BI到底能不能实时展现数据。但很多人可能都对它不够了解，本文作者结合自己的工作实践，从7个方面分享了数据仓库建设的相关步骤和需要注意的问题，一起来看看~

之前发了一篇数据仓库的文章，发现大家对数据仓库还是非常感兴趣的。今天再和大家一起聊聊实时数仓吧！

实时数仓可谓是决定性的东西，能决定什么？决定你的报表和BI到底能不能实时展现数据。

01 数据仓库的发展趋势 1.1 数据仓库的趋势

关于数据仓库的概念就不多介绍了。

数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变得越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展。

数据仓库的趋势：

实时数据仓库以满足实时化&自动化决策需求

大数据&数据可以支持大量&复杂数据类型

1.2 数据仓库的发展

数据仓库有两个环节：数据仓库的构建与数据仓库的应用。

早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略性决策）。

随着业务和环境的发展，这两方面都在发生着剧烈变化。

随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站 log，IoT 设备数据，APP 埋点数据等，这些数据量比以往结构化的数据大了几个量级，对 ETL 过程、存储都提出了更高的要求。

互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策，比如欺诈检测和用户审核。

总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。

02 数据仓库架构的演变

从1990年 Inmon 提出数据仓库概念到今天，数据架构经历了最初的传统数仓架构——离线数仓库——离线大数据架构、Lambda 架构、Kappa 架构以及 Flink 的火热带出的流批一体架构，数据架构技术不断演进，本质是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算。

2.1 传统数仓架构

这是比较传统的一种方式，结构或半结构化数据通过离线ETL定期加载到离线数据，之后通过计算引擎取得结果，供前端使用。这里的离线数仓+计算引擎，通常是使用大型商业数据库来承担，例如Oracle、DB2、Teradata等。

2.2 离线大数据架构

随着数据规模的不断增大，传统数仓方式难以承载海量数据。随着大数据技术的普及，采用大数据技术来承载存储与计算任务。当然，也可以使用传传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。

2.3 Lambda架构

随着业务的发展，随着业务的发展，人们对数据实时性提出了更高的要求。此时，出现了Lambda架构，其将对实时性要求高的部分拆分出来，增加条实时计算链路。从源头开始做流式改造，将数据发送到消息队列中，实时计算引擎消费队列数据，完成实时数据的增量计算。

与此同时，批量处理部分依然存在，实时与批量并行运行。最终由统一的数据服务层合并结果给予前端。一般是以批量处理结果为准，实时结果主要为快速响应。

2.4 Kappa架构

Lambda架构，一个比较严重的问题就是需要维护两套逻辑。一部分在批量引擎实现，一部分在流式引擎实现，维护成本很高。此外，对资源消耗也较大。而后面诞生的Kappa架构，正是为了解决上述问题。其在数据需要重新处理或数据变更时，可通过历史数据重新处理来完成。

方式是通过上游重放完成(从数据源拉取数据重新计算)。Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

2.5混合架构