|
在最初阶段，企业主要采用一种实时计算任务的方式来处理实时数据。随着需求不断增加，计算任务也相应增多。而且，不同任务的开发人员也不同，导致开发风格的差异化。
因此，这一阶段的实时数据处理缺乏统一的规划，代码风格差异化严重，对于维护成本和开发效率造成了很大的障碍。为了避免上述问题，人们参照数据仓库的概念和模型重新规划和设计实时数据处理。在此基础上，构建实时数仓应运而生。
开始之前给大家分享一份《数据仓库建设解决方案》，包含了数仓的技术架构、数仓建设关键动作、数仓载体/工具、配置参考、大数据场景支撑案例等内容。感兴趣的小伙伴，点击下方小程序链接或点击文末阅读原文链接下载完整PDF！
实时数仓（Real-time Data Warehouse）是一个用于存储和处理实时数据的系统。它的主要特点是数据的处理和分析是即时进行的，数据几乎立即进入数仓并可以立即用于分析和决策。
●低延迟：实时数仓能够在数据产生后迅速将其捕捉和处理，通常以秒或亚秒级的速度。
●数据流处理：实时数仓通常使用流式处理技术来处理数据，这允许数据在进入仓库时立即进行转换和计算。
●实时分析：数据可以用于实时监控、仪表板、预测和决策支持。
●高吞吐量：实时数仓需要处理大量的数据流，因此需要具备高吞吐量的性能。
●复杂性：由于需要处理实时数据流，实时数仓的架构和技术通常比较复杂。
数仓架构的演变
从1990年 Inmon 提出数据仓库概念到今天，数仓架构经历了最初的传统数仓架构、离线大数据架构、Lambda 架构、Kappa 架构以及由Flink 的火热带出的流批一体架构，数据架构技术不断演进，本质是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算。
这是比较传统的一种方式，结构或半结构化数据通过离线ETL定期加载到离线数仓，之后通过计算引擎取得结果，供前端使用。这里的离线数仓+计算引擎，通常是使用大型商业数据库来承担，例如Oracle、DB2、Teradata等。
随着数据规模的不断增大，传统数仓方式难以承载海量数据。随着大数据技术的普及，采用大数据技术来承载存储与计算任务。数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis。
●DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据；
●DM，数据集市/轻度汇总层，在 DWD 层的基础之上根据不同的业务需求做轻度汇总。
当然，也可以使用传传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。
随着业务的发展，随着业务的发展，人们对数据实时性提出了更高的要求。此时，出现了Lambda架构，其将对实时性要求高的部分拆分出来，增加条实时计算链路。从源头开始做流式改造，将数据发送到消息队列中，实时计算引擎消费队列数据，完成实时数据的增量计算。与此同时，批量处理部分依然存在，实时与批量并行运行。最终由统一的数据服务层合并结果给于前端。一般是以批量处理结果为准，实时结果主要为快速响应。
而Lambda架构，一个比较严重的问题就是需要维护两套逻辑。一部分在批量引擎实现，一部分在流式引擎实现，维护成本很高。此外，对资源消耗也较大。随后诞生的Kappa架构，正是为了解决上述问题。其在数据需要重新处理或数据变更时，可通过历史数据重新处理来完成。方式是通过上游重放完成(从数据源拉取数据重新计算)。
可Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
上述架构各有其适应场景，有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复杂度。用户应根据自身需求，有所取舍。在一般大多数场景下，是可以使用单一架构解决问题。现在很多产品在流批一体、海量、实时性方面也有非常好的表现，可以考虑这种“全能手”解决问题。、
构建实时数仓需要根据业务需求选择合适的技术架构，并通过ETL工具来实现数据的实时采集、处理和分析，最终将结果存储到实时数据仓库中，并进行数据可视化和应用开发。
综上所述，数仓建设是企业数据管理和决策支持的关键环节，在实践中，企业需要根据自身业务需求和数据规模，选择合适的数仓建设方案和技术方案，以提高企业数据资产的价值和利用效率。
| 
