我正在学习 Hadoop 并遇到了 HIVE。我了解到 HIVE 充当分析查询的数据仓库。
如果数据仓库是多个数据源的聚合,那么企业为什么要使用多个数据源并聚合它们呢?为什么他们不能直接写入数据仓库,因为它会减少聚合和处理的开销?
是因为如果所有用户都从同一个数据仓库读取会产生开销吗?
我想了解如果我们拥有高度可扩展的数据仓库,为什么还需要数据库?
(仅在产生大量数据的大公司的情况下。因为我可以理解大多数公司甚至可以使用 2 个数据库进行管理。)
我正在学习 Hadoop 并遇到了 HIVE。我了解到 HIVE 充当分析查询的数据仓库。
如果数据仓库是多个数据源的聚合,那么企业为什么要使用多个数据源并聚合它们呢?为什么他们不能直接写入数据仓库,因为它会减少聚合和处理的开销?
是因为如果所有用户都从同一个数据仓库读取会产生开销吗?
我想了解如果我们拥有高度可扩展的数据仓库,为什么还需要数据库?
(仅在产生大量数据的大公司的情况下。因为我可以理解大多数公司甚至可以使用 2 个数据库进行管理。)
数据仓库(DWH)是不同数据库之上的一个更大的层,而数据库是一个命名空间+存储,用于存储与某些 DWH 阶段相对应的一些表/对象/过程。
分析 DWH 的最终目的是提供可用于不同分析/报告工具的分析数据集市:Tableu、QulickView 等
DWH 包含不同阶段(数据库)不同聚合的数据,例如 LZ - 存储从不同来源加载的数据的着陆区,ODS - 运营数据存储,将来自不同来源的数据组合成事实表和维度,清除,转换,通常使用 3NF 和从不同来源丰富的一致维度。最后是 DM - 一个数据集市,其中聚合数据存储在维度模型中:事实表(可以聚合)和在星形/雪花模式中使用的维度。也可以使用其他一些数据库,例如用于中间数据处理的 STG。
DWH 不仅是由多个数据库组成的存储,它还是每个阶段的数据加载、提取、转换、通用架构和策略的 ETL 过程。
您决定 DWH 将包含哪些层以及应如何设计:使用自上而下的方法(从源系统开始)或自下而上的方法(从数据集市维度建模开始)或两者兼而有之。
DWH 本身不聚合(处理)任何数据。对于每个步骤和实体,您创建一个 ETL 流程,该流程在不同阶段(数据库)之间加载、提取、转换数据。
一致的维度(不同数据集市/事实表中使用的相同维度)用作 DWH 中的单一事实点。
例如,如果您User
从不同的源系统(如 Salesforce、GoogleAnalytics 等)增量加载表,然后不同的 ETL 进程将数据加载到 LZ,然后另一个 ETL 进程将其合并并重复到 ODS 表中,然后另一个进程将其加载到DM 与 Transactions 数据一起进入月/日聚合 Transaction 数据集市,这是一个日或月聚合星型模式,以User
表为维度。
还有另一个现代概念 - a data lake
,它还包含半结构化或非结构化数据以及 3NF 和数据集市中的结构化数据,这允许数据工程师/数据挖掘者挖掘非结构化数据并进行分析,找到一些相关性并最终构建新的数据集市。