争议 | 数据仓库的融合：实时数据仓库与历史数据仓库，应统一建模还是分开建模？

Posted 2021-04-24 twt企业IT社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了争议 | 数据仓库的融合：实时数据仓库与历史数据仓库，应统一建模还是分开建模？相关的知识，希望对你有一定的参考价值。

以下内容来自社区探讨，欢迎点击阅读原文到社区与同行交流本话题

实时数据仓库与传统数据仓库的融合：实时数据仓库与历史数据仓库是否考虑统一建模还是分开建模?

实时数据仓库与传统数据仓库的融合：

1)实时数据仓库与历史数据仓库是否考虑统一建模还是分开建模?

2)实时数据仓库的实时数据与历史数据仓库的历史数据是统一存储还是分开存储?

（问题来自社区会员）

@王奇阜新银行项目经理：

所谓的实时数仓，最主要的就是当天的数据。银行最重要的是当天的流水，所以更多的需求都应该是银行的流水数据产生的。实时的数据量很少，只有当天或几天的数据（保存几天的数据可以增加容错的机制），个人理解实时数仓关注的应该是指标，而非各种各样的数据，模型也应该是轻量级的。而非传统的数仓是非常沉重而沉淀的数据。

@gengyang 民生银行数据仓库工程师：

1、关于建模

首先传统数仓的建模已经很成熟，而实时数仓才刚刚起步处于探索阶段，如果盲目效仿传统数仓，可能会因为复杂度过高而阻碍探索的步伐。我个人认为实时数仓的建模应该根据实际应用场景尽量简化，在实际应用的探索过程中逐步完善并形成标准。

2、关于存储

这个就更没必要统一了，传统数仓接入的数据基本都是格式化数据，而实时数据有日志有报文有格式化数据形式不一，如果有必要两者完全可以在服务层合并，而不是在仓库层。

@周光明 PBOC 软件架构设计师：

1）无论实时数据仓库还是历史数据仓库，感觉建立模型是非常关键的，以模型为中心，以模型为驱动。数据分析本质上还是模型+算法。

2）实时数据仓库与历史数据仓库，在数据采集技术和数据传播技术等技术实现会有较大差别，但是模型上应该统一、融合的。

3）实时数据与历史数据，最好考虑统一规划、统一存储，方便以后各种粒度数据的分析利用。

@jamiee 某股份制银行数据库架构师：

1）实时数据更加强调数据采集、数据加工、数据应用的实时性，实时数据处理的技术实现上与历史数据有比较大的差异，数据模型要统一比较困难，是否可从以下两点去尝试。

1.数据分层体系上可以借鉴传统数仓，比如数据数据采集是否可与贴源数据对应，实时的数据清洗和标准化是否可以整合层对应起来。

2.实时数据采集和加工结果可以批量持久化到存储中，用于仓库的贴源数据采集和整合层加工。

2）实时数据处理过程由于时效性的考虑，应该使用访问效率比较高的存储，比如SSD、内存，我认为两者的存储是要独立的。结合上面的第2点如果可以实现的话，最终采集和加工也可以与历史数仓整合到一起。

@foreverisold 软件开发工程师：

维度与指标相同的话，统一建模，但底层数据库可以两个表，使用视图合并起来再建模。如果建模建在数据库表上，也是建议两个表，但对外提供数据源时通过视图合并再提供。

@Ott 科技部项目经理：

数据要融合才能价值最大化，企业级数据仓库建设的一个主要目的也是实现企业业务数据的大集中。实时的数据信息有限，存量的数据信息丰富但时效性不足，二者结合才能构建更贴合实际及复杂的业务场景，避免数据利用的单一化及简单化。

@黑民湖南农信软件开发工程师：

1.关于建模。个人认为银行业实时数据的处理目前常用的场景还是对账户和流水的应用，相对来说账户和流水的模型应采用比较简单的模型，快速处理、高效处理，用来适应场景。

2.关于存储。个人偏向于分开存储，实时数据一般只用于当天，历史数据在T+1日后会再次同步，因此分开存储更有利于架构上的清晰和数据的应用。

@chailei_8306 城商行研发工程师：

这其实是一个问题。传统数据仓库反映长时间的变化，最细区分粒度是以天为周期的。历史库只不过是将久远的，利用率低的数据单独剥离存放了。

实时数仓是为了对当前时刻的业务进行一系列统计，其初衷是为了解决两个基本问题。一是将复杂的统计计算从业务系统剥离，给业务系统减负；二是实现跨系统数据加总和关联。

实时数仓解决问题的重点在汇总或关联，其对效率的要求比较高。所以需要用与传统数仓不同的策略进行设计。也就是分开模型，分开存储比较合适。

欢迎点击文末阅读原文到社区讨论交流