为什么不能直接用数据仓库代替数据库呢？
Why can't we use data warehouse directly instead of database?
我正在学习 Hadoop 并遇到了 HIVE。我了解到 HIVE 充当分析查询的数据仓库。
如果数据仓库是多个数据源的聚合，为什么企业要使用多个数据源并进行聚合呢？为什么他们不能直接写入数据仓库，因为这样可以减少聚合和处理的开销？
是否因为所有用户从同一个数据仓库读取会产生开销？
我想了解如果我们拥有高度可扩展的数据仓库，为什么还需要数据库？
（仅限于产生大量数据的大公司。因为我可以理解大多数公司甚至可以使用 2 个数据库进行管理。）
数据仓库（DWH）是在不同数据库之上的一个更大的层，而数据库是一个命名空间+存储，用于存储一些tables/objects/procedures对应于一些DWH阶段。
分析型 DWH 的最终目的是提供可用于不同analytics/reporting 工具的分析数据集市：Tableu、QulickView 等
DWH 包含不同阶段（数据库）中不同聚合的数据，例如 LZ - 存储从不同来源加载的数据的着陆区，ODS - 操作数据存储，其中来自不同来源的数据组合成事实table 和维度，清除，转换，通常使用 3NF 和从不同来源丰富的符合维度。
最后是 DM - 一个数据集市，其中聚合数据存储在维度模型中：事实 tables（可以聚合）和在 star/snowflake 模式中使用的维度。也可以使用其他一些数据库，例如用于中间数据处理的 STG。
DWH不仅仅是一个由多个数据库组成的存储，它也是ETL过程，用于加载、提取、转换每个阶段的数据，公共架构和策略。
您决定 DWH 将包含哪些层以及应该如何设计：使用 top-down 方法（从源系统开始）或 bottom-up（从数据集市维度建模开始）或两者。
DWH 本身不聚合（处理）任何数据。对于每个步骤和实体，您创建一个 ETL 过程，该过程在不同阶段（数据库）之间加载、提取、转换数据。
一致性维度（在不同 datamarts/fact table 中使用的相同维度）在 DWH 中用作单一事实点。
例如，如果您 User table 从不同的源系统（如 Salesforce、GoogleAnalytics 等）增量加载，然后不同的 ETL 进程将数据加载到 LZ，然后另一个 ETL 进程组合并将其复制到 ODS table，然后另一个进程将其与交易数据一起加载到 DM 到 monthly/daily 聚合交易数据集市，这是一个每日或每月聚合星型模式，使用 User table 作为维度。
还有另一个现代概念 - ，它另外包含 semi-structured 或非结构化数据以及 3NF 和数据集市中的结构化数据，这允许数据 engineers/data 矿工挖掘非结构化数据并进行分析，找到一些相关性并最终构建新的数据集市。
我正在学习 Hadoop 并遇到了 HIVE。我了解到 HIVE 充当分析查询的数据仓库。
如果数据仓库是多个数据源的聚合，为什么企业要使用多个数据源并进行聚合呢？为什么他们不能直接写入数据仓库，因为这样可以减少聚合和处理的开销？
是否因为所有用户从同一个数据仓库读取会产生开销？
我想了解如果我们拥有高度可扩展的数据仓库，为什么还需要数据库？
（仅限于产生大量数据的大公司。因为我可以理解大多数公司甚至可以使用 2 个数据库进行管理。）
数据仓库（DWH）是在不同数据库之上的一个更大的层，而数据库是一个命名空间+存储，用于存储一些tables/objects/procedures对应于一些DWH阶段。
分析型 DWH 的最终目的是提供可用于不同analytics/reporting 工具的分析数据集市：Tableu、QulickView 等
DWH 包含不同阶段（数据库）中不同聚合的数据，例如 LZ - 存储从不同来源加载的数据的着陆区，ODS - 操作数据存储，其中来自不同来源的数据组合成事实table 和维度，清除，转换，通常使用 3NF 和从不同来源丰富的符合维度。 最后是 DM - 一个数据集市，其中聚合数据存储在维度模型中：事实 tables（可以聚合）和在 star/snowflake 模式中使用的维度。也可以使用其他一些数据库，例如用于中间数据处理的 STG。
DWH不仅仅是一个由多个数据库组成的存储，它也是ETL过程，用于加载、提取、转换每个阶段的数据，公共架构和策略。
您决定 DWH 将包含哪些层以及应该如何设计：使用 top-down 方法（从源系统开始）或 bottom-up（从数据集市维度建模开始）或两者。
DWH 本身不聚合（处理）任何数据。对于每个步骤和实体，您创建一个 ETL 过程，该过程在不同阶段（数据库）之间加载、提取、转换数据。
一致性维度（在不同 datamarts/fact table 中使用的相同维度）在 DWH 中用作单一事实点。
例如，如果您 User table 从不同的源系统（如 Salesforce、GoogleAnalytics 等）增量加载，然后不同的 ETL 进程将数据加载到 LZ，然后另一个 ETL 进程组合并将其复制到 ODS table，然后另一个进程将其与交易数据一起加载到 DM 到 monthly/daily 聚合交易数据集市，这是一个每日或每月聚合星型模式，使用 User table 作为维度。
还有另一个现代概念 -