哈Ha！ 关于数据仓库体系结构的文章已经写了很多，但是还没有像我偶然遇到的一篇文章那样简洁。
我邀请您熟悉我的翻译中的这篇文章。 欢迎评论和添加！
（图片来源）引言
因此，数据仓库的架构正在发生变化。 在本文中，我们将比较传统企业数据仓库和云解决方案具有较低的初始成本，改进的可伸缩性和性能。
数据仓库是一个系统，其中从公司内的各种来源收集数据，并且该数据用于支持管理决策。
公司越来越多地转向基于云的数据仓库，而不是传统的本地系统。 云数据存储与传统存储有几个区别：
- 无需购买物理设备；
- 云数据仓库配置和扩展更快，更便宜。
- 云数据仓库通常使用复杂的并行处理，因此可以更快地执行复杂的分析查询。
传统数据仓库架构
以下概念重点介绍了一些用于创建传统数据仓库的既定设计思想和原则。
三层架构
通常，传统的数据仓库体系结构具有三层结构，包括以下几层：
- 较低级别 ：此级别包含用于从许多不同来源（例如，从用于前端应用程序的事务性数据库）检索数据的数据库服务器。
- 中间层 ：中间层包含一个OLAP服务器，该服务器将数据转换为更适合于分析和复杂查询的结构。 OLAP服务器可以通过两种方式工作：作为将多维数据操作映射到标准关系OLAP操作的高级关系数据库管理系统，或者使用直接实现多维数据和操作的多维OLAP模型。
- 最高层 ：最高层是客户层。 此级别包含用于高级数据分析，报告和数据分析的工具。
金博尔vs. 因门
数据仓库的两位先驱：Bill Inmon和Ralph Kimball，提供了不同的设计方法。
Ralph Kimball的方法基于数据集市的重要性，数据集市是属于特定业务的数据仓库。 数据仓库只是
各种便于报告和分析的
数据集市的
组合 。 基于Kimball的数据仓库项目使用自下而上的方法。
Bill Inmon的方法基于这样一个事实，即数据仓库是所有公司数据的集中存储。 使用这种方法，组织首先创建
标准化的数据仓库
模型 。 然后，基于仓库模型创建维度数据集市。 这被称为自上而下的数据仓库方法。
数据仓库模型
在传统体系结构中，数据仓库有三种通用模型：虚拟存储，数据展示和公司数据仓库：
- 虚拟数据仓库是一组可以共享的独立数据库，因此用户可以有效地访问所有数据，就像它们存储在一个数据仓库中一样。
- 数据展示模型用于报告和分析特定业务线。 在此存储模型中，来自与特定业务领域（例如销售或财务）相关的多个源系统的聚合数据；
- 公司数据仓库模型涉及存储跨越整个组织的聚合数据。 该模型将数据仓库视为企业信息系统的核心，其中包含来自所有业务部门的集成数据。
星与 雪花
星型和雪花方案是构建数据仓库的两种方法。
星型模式具有集中的数据仓库，该数据仓库存储在事实表中。 该图表将事实表分为一系列非规格化的维表。 事实表包含将用于报告的聚合数据，维度表描述了存储的数据。
因为数据是分组的，所以非规范化项目的复杂性较低。 事实表仅使用一个链接来附加到每个维度表。 较简单的星形设计极大地简化了复杂查询的编写。
雪花模式的不同之处在于它使用规范化的数据。 规范化意味着有效的数据组织，以便定义所有数据相关性，并且每个表都包含最少的冗余。 因此，将各个测量表分叉到单独的测量表中。
雪花方案使用更少的磁盘空间并更好地维护数据完整性。 主要缺点是访问数据所需的查询很复杂-每个查询都必须经过几个表联接才能获取相应的数据。
ETL与 电报
ETL和ELT是将数据加载到存储中的两种不同方式。
ETL（提取，转换，加载）首先从数据源池中检索数据。 数据存储在临时登台数据库中。 然后，执行转换操作以将数据结构化并转换为适用于目标数据仓库系统的形式。 然后将结构化数据加载到存储中并准备进行分析。
对于
ELT（提取，加载，转换），从源数据池中提取数据后立即加载数据。 没有中间数据库，这意味着数据会立即上传到单个集中式存储库。
数据将转换为数据仓库系统，以用于商业智能和分析工具。
组织成熟度
该组织的数据仓库结构还取决于其当前状况和需求。
基本结构允许存储最终用户直接从源系统访问摘要数据，创建报告并分析此数据。 对于数据源来自相同类型的数据库系统的情况，此结构很有用。
具有中间区域的存储是具有异构数据源的组织中下一步的逻辑步骤，该异构数据源具有许多不同类型和格式的数据。 暂存区将数据转换为通用的结构化格式，使用分析和报告工具更易于请求。
中间结构的一种变体是在数据仓库中添加了数据集市。 数据集市将摘要数据存储在特定的活动领域中，这使这些数据易于用于特定形式的分析。
例如，添加数据集市可以使财务分析师更轻松地对销售数据执行详细查询并预测客户行为。 数据集市通过专门为满足最终用户需求而定制数据来促进分析。
新的数据仓库架构
近年来，数据仓库正在迁移到云中。 新的云数据仓库不遵循传统架构，并且每个仓库都提供自己的独特架构。
本节简要介绍两个最受欢迎的云存储所使用的架构：Amazon Redshift和Google BigQuery。
亚马逊红移
Amazon Redshift是传统数据仓库的基于云的视图。
Redshift要求准备计算资源并将其配置为包含一个或多个节点的集合的群集。 每个节点都有自己的处理器，内存和RAM。 领导者节点编译请求并将其传递给执行请求的计算节点。
在每个节点上，数据存储在称为
slices的块中。 Redshift使用列存储，也就是说，每个数据块都包含多行中一列的值，而不是包含多列中的值的一行。
Redshift使用MPP（大规模并行处理）架构，将大型数据集分解为块，并分配给每个节点中的切片。 由于计算节点同时处理每个片中的请求，因此请求速度更快。 “领导者节点”节点合并结果并将其返回到客户端应用程序。
诸如BI和分析工具之类的客户端应用程序可以使用开源PostgreSQL JDBC和ODBC驱动程序直接连接到Redshift。 这样，分析人员可以直接在Redshift数据上执行任务。
Redshift只能加载结构化数据。 您可以使用包括Amazon S3和DynamoDB在内的预集成系统，通过SSH连接从任何本地主机传输数据或通过使用Redshift API集成其他数据源，将数据加载到Redshift中。
谷歌bigquery
BigQuery架构不需要服务器，这意味着Google可动态控制计算机资源的分配。 因此，所有资源管理决策对用户都是隐藏的。
BigQuery允许客户从Google Cloud Storage和其他可读数据源下载数据。 另一种选择是流数据，它允许开发人员在可用时将数据实时逐行实时添加到数据仓库中。
BigQuery使用称为Dremel的查询引擎，该引擎可以在几秒钟内扫描数十亿行数据。 Dremel使用大规模并行查询来扫描Colossus基本文件管理系统中的数据。 Colossus在称为节点的各种计算资源之间将文件分配为64兆字节的片段，这些资源按群集分组。
Dremel使用类似于Redshift的列数据结构。 树结构在几秒钟内将请求发送到数千台计算机。
简单的SQL命令用于执行数据查询。
全景式
Panoply提供全面的数据管理即服务。 其独特的自我优化架构使用机器学习和自然语言处理（NLP）来建模和简化从源到分析的数据传输，从而将从数据到值的时间尽可能地减少到接近零。
Panoply Intelligent Data Infrastructure包括以下功能：
- 查询和数据分析-确定每种用例的最佳配置，随时间进行调整并创建索引，排序键，磁盘键，数据类型，疏散和分区。
- 识别不遵循最佳实践的查询（例如，包含嵌套循环或隐式强制转换的查询），并将其重写为等效查询，而执行该查询的执行时间或资源很少。
- 根据查询模式并随着时间的推移优化服务器配置，并了解哪种服务器设置最有效。 该平台无缝切换服务器类型并衡量整体性能。
超越云存储
基于云的数据仓库是对传统架构方法的重大改进。 但是，用户在配置它们时仍然遇到许多问题：
- 将数据上传到基于云的数据仓库并非易事，并且大规模数据管道需要配置，测试和支持ETL流程。 该过程的这一部分通常由第三方工具执行；
- 更新，插入和删除可能很复杂，必须仔细进行以防止查询性能下降；
- 半结构化数据很难处理-需要以关系数据库格式进行规范化，这需要自动化大数据流；
- 云数据仓库通常不支持嵌套结构 。 您需要将嵌套表转换为数据仓库可以理解的格式。
- 集群优化 。 有多种选项可配置Redshift群集以运行您的工作负载。 不同的工作负载，数据集甚至不同类型的查询可能需要不同的配置。 为了获得最佳性能，有必要不断检查，并在必要时进行其他配置。
- 查询优化 -用户查询可能未遵循最佳做法，因此需要更长的时间才能完成。 您可以与用户或自动客户端应用程序一起优化查询，以便数据仓库可以按预期工作
- 备份和恢复 -尽管数据仓库提供商提供了许多用于备份数据的选项，但它们并非易事，需要监视和密切注意。
链接到原始文本： panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud