我领导着一个与电动汽车制造商合作的大数据团队，我已经尝试了市场上可用的OLAP工具。阅读下面的内容，了解我认为您需要了解的关于这些工具的内容，包括许多OLAP工具的优缺点以及我在OLAP方面的经验。

讨论的OLAP工具：

1. Apache Druid (and Apache Kylin)
2. TiDB
3. ClickHouse
4. Apache Doris

Apache Druid（和Apache Kylin）

早在2017年，在市场上寻找OLAP工具就像在非洲大草原上寻找一棵树一样——只有少数。当我们抬头扫视地平线时，我们的目光停留在阿帕奇·德鲁伊和阿帕奇·凯林身上。我们之所以选择Druid，是因为我们已经对它很熟悉了，而Kylin尽管在预计算中具有令人印象深刻的高查询效率，但也有一些缺点。

Kylin的缺点：

• Kylin最好的存储引擎是HBase，但引入HBase会带来新的操作和维护负担。
• Kylin预先计算了维度和度量，但它带来的维度爆炸给存储带来了巨大压力。

至于Apache Druid，它使用了列式存储，支持实时和离线数据接收，并提供了快速查询。

另一方面，Druid：

• 不使用JDBC等标准协议，因此对初学者不友好。
• 对Joins的支持率很低。
• 精确重复数据消除可能较慢，从而降低性能。
• 由于许多组件需要各种安装方法和依赖关系，因此需要大量的维护工作。
• 在数据接收方面，Hadoop集成和JAR包的依赖性需要更改。

TiDB公司

2019年，我们尝试了TiDB。长话短说，以下是它的优点和缺点：

优点：

• 它是一个OLTP+OLAP数据库，支持简单的更新。
• 它具有我们需要的功能，包括聚合和细分查询、度量计算和仪表板。
• 它支持标准SQL，因此很容易掌握。
• 它不需要太多的维护。

缺点：

• TiFlash依赖OLTP这一事实可能会给存储带来更大的压力。作为一个非独立的OLAP，其分析处理能力并不理想。
• 它的性能因场景而异。

ClickHouse与Apache Doris之争

我们对ClickHouse和Apache Doris进行了研究。ClickHouse出色的独立性能给我们留下了深刻印象，但当我们发现：

• 当涉及到多表联接时，它并没有给我们想要的东西，这对我们来说是一个重要的用法。
• 它的并发性相对较低。
• 这可能会带来高昂的运营和维护成本。

另一方面，Apache Doris在我们的需求列表中勾选了很多框：

• 它支持高并发查询，这是我们最关心的问题。
• 它能够同时进行实时和离线数据处理。
• 它同时支持聚合查询和细分查询。
• 它的Unique模型（Doris中的一种数据模型，确保了唯一的密钥）支持更新。
• 它可以通过Materialized View大大加快查询速度。
• 它与MySQL协议兼容，因此在开发和采用方面几乎没有问题。
• 它的查询性能令人满意。
• 它只需要简单的运维。

总之，Apache Doris似乎是Apache Druid+TiDB的理想替代品。

我们的OLAP实践经验

以下是一张图表，向您展示数据是如何在我们的OLAP系统中流动的：

数据源

我们将来自业务系统、事件跟踪、设备和车辆的数据汇集到我们的大数据平台中。

数据导入

我们为我们的业务数据启用CDC。这些数据中的任何更改都将转换为数据流并存储在Kafka中，为流计算做好准备。对于只能批量导入的数据，它将直接进入我们的分布式存储。

数据处理

我们采用了Lambda架构，而不是集成、流式处理和批处理。我们的业务现状决定了我们的实时和离线数据来自不同的环节。特别地：

• 有些数据是以流的形式出现的。
• 有些数据可以存储在流中，而有些历史数据则不会存储在卡夫卡中；
• 某些场景需要高数据精度。为了实现这一点，我们有一个离线管道，可以重新计算和刷新所有相关数据。

数据仓库

我们没有使用Flink/Spark Doris连接器，而是使用Routine Load方法将数据从Flink传输到Doris，并使用Broker Load将数据从Spark传输到Dors。Flink和Spark批量生成的数据将备份到Hive，以便在其他场景中使用。这是我们提高数据效率的方法。

数据服务

在数据服务方面，我们通过数据源注册和灵活配置实现了API的自动生成，因此我们可以通过API管理流量和权限。与K8s无服务器解决方案相结合，整个过程非常有效。

数据应用程序

在数据应用层，我们有两种类型的场景：

• 面向用户的场景，如仪表板和指标。
• 面向车辆的场景，将车辆数据收集到Apache Doris中进行进一步处理。即使在聚合之后，我们仍然有以亿为单位的数据大小，但总体计算性能达到了标准。

我们的CDP实践

与大多数公司一样，我们建立了自己的客户数据平台（CDP）：

通常，CDP由几个模块组成：

 

• 标签：积木，显然；（我们有基本标签和客户行为标签。我们也可以根据需要定义其他标签。）
• 分组：根据标签将客户分组。
• 见解：每个客户群体的特点。
• 联系：联系客户的方式，包括短信、电话、应用程序通知和即时消息。
• 效果分析：关于CDP如何运行的反馈。

我们希望在CDP中实现实时+离线集成、快速分组、快速聚合、多表联接和联合查询。以下是它们的操作方法：

实时+离线

我们有实时标签和离线标签，我们需要将它们放在一起。此外，同一数据上的列可能会以不同的频率更新。一些基本标签（关于客户身份）应该实时更新，而其他标签（年龄、性别）可以每天更新。我们希望将客户的所有原子标签放在一个表中，因为这样可以带来最少的维护成本，并且在添加自定义标签时可以大大减少所需的表的数量。

那么我们如何实现这一点呢？

我们使用Apache Doris的Routine Load方法更新实时数据，使用Broker Load方法批量导入离线数据。我们还使用这两种方法分别更新同一表中的不同列。

快速分组

基本上，分组就是将某一组标签组合起来，找到重叠的数据。这可能很复杂。Doris通过SIMD优化帮助加快了这一过程。

快速聚合

我们需要更新所有标签，重新计算客户群体的分布，并每天分析影响。这样的处理需要快速而整洁。因此，我们根据时间将数据划分为平板电脑，这样就可以减少数据传输，加快计算速度。在计算客户组的分布时，我们在每个节点预聚合数据，然后收集它们进行进一步聚合。此外，Doris的矢量化执行引擎是一个真正的性能加速器。

多表联接

由于我们的基础数据存储在多个数据表中，当CDP用户自定义他们需要的标签时，他们需要进行多表联接。吸引我们使用ApacheDoris的一个重要因素是它有前途的多表联接功能。

联合查询

目前，我们将Apache Doris与TiDB结合使用。关于客户接触的记录将被放入TiDB中，关于信用点和代金券的数据也将在TiDB中处理，因为它是一个更好的OLTP工具。对于更复杂的分析，例如监控客户运营的有效性，我们需要整合有关任务执行和目标群体的信息。这就是我们在Doris和TiDB之间进行联合查询的时候。

结论

这是我们从Apache Druid、TiDB和Apache Doris的旅程（中间是对ClickHouse的简短介绍）。我们研究了它们的性能、SQL语义、系统兼容性和维护成本，最终得出了我们现在的OLAP体系结构。如果你和我们有同样的担忧，这可能是你的参考。

数据仓库和商业智能在许多（如果不是的话）致力于将数据转化为有意义的商业价值的见解的大型组织中发挥着重要作用。数据仓库是从各种来源收集和管理数据以提供有意义的业务见解的过程。商业智能包括用于提供这些见解的战略和技术。这两个领域都可以被视为数据管理的一部分。它们与其他数据管理领域紧密交织在一起，在很大程度上依赖于数据集成。

简要背景

数据仓库在90年代开始流行，最初是一种收集数据并将其整合为统一形式的常见做法，目的是为组织创造一个一致的真相版本。这种一致的真相成为公司内部商业决策的重要来源。

这种决策得到了另一种趋势——商业智能的支持。Gartner定义的商业智能是“一个总括性术语，包括应用程序、基础架构和工具，以及能够访问和分析信息以改进和优化决策和性能的最佳实践”。商业智能最初是以一种很好的方式生成数据和简单的报告，但在后期引入了自助服务，具有更高级的功能，如内存处理和可预测功能。

许多企业组织严重依赖数据仓库。其中许多是在过去十年中开发的。它们被认为是一种关键资产，用于许多日常流程，并在公司内的数据消耗和分发中发挥着重要作用。在这篇文章中，我将解释一些流行的方法和共同特征，并揭示企业数据仓库的概念，这在规模上是不同的。

警告：在我们继续的过程中，我需要给你一个警告。我坚信，企业数据仓库（EDW）很快就会灭绝。而不是数据仓库本身的基本概念，因为数据统一的必要性，将大量数据带入特定环境的必要性始终存在。但即将消亡的是使用数据仓库进行企业范围的数据集成、消费和分发。我会在这篇文章中解释原因。

数据仓库

许多公司仍在大力投资数据仓库。然而，使用数据仓库体系结构的大小和规模可能存在显著差异。在我告诉你我对这个体系结构的看法之前，让我们退一步，从头开始。

什么是数据仓库？

什么是数据仓库？数据仓库的核心概念是由IBM研究人员Barry Devlin和Paul Murphy于1988年提出的。随着计算机系统变得更加复杂和数据量的增加，需要一个体系结构模型来支持来自操作系统的数据流，以支持决策环境。几年后，Bill Inmon出版了一本书，并对数据仓库的用途给出了更具体的定义：“数据仓库是一种面向主题的、集成的、时变的和非易失性的数据集合，用于支持管理层的决策过程。”

随着数据仓库越来越受欢迎，具有不同定义的模型的变体开始出现，我喜欢将数据仓库定义为“将来自不同来源的（历史）数据协调到中央存储库并进行管理的系统，其主要目标是支持决策过程”。从这句话中，我们可以提取出一些重要的特征。从单词central可以得出结论，在数据仓库中，数据被聚集在一起并集中存储。在许多情况下，这确实是真的，但一些技术趋势允许以其他方式开发数据仓库，例如数据虚拟化。从和谐这个词我们可以得出数据是集成的、统一的和一致的。这意味着需要额外的组件来收集、清理、修复、转换和存储数据。通过声明不同的来源，我们明确了数字是复数，因此数据仓库现在或将来不会只用于从单个来源收集数据。

Bill Inmon曾说过“数据仓库概念的一大吸引力在于存在单一版本的真相”。这个单一版本的真相意味着使用了一个单一的词汇表，所有用户都必须同意数据仓库中使用的所有数据的含义和定义。我们稍后将更详细地介绍这一词汇方面。

这听起来很全面，但为什么你首先想要一个数据仓库？有什么好处？为了更好地理解数据仓库为什么有用，我们需要退后一步，解释一些关键驱动因素，并首先更仔细地了解事务和分析系统是如何工作的。

OLTP（在线事务处理）

传统上，应用程序和数据库的空间被划分为两个世界。许多应用程序开始时是事务性的或可操作的，就像计算机世界开始时需要处理事务和存储记录一样。这些系统使流程更加高效，因为它们能够取代传统的卡片目录和许多手动流程。银行系统、机票预订系统、订单管理系统、客户系统、电信系统、医疗保健系统、购物系统等。这些应用程序因其关键的操作作用而被称为在线交易处理（OLTP）系统。

对于OLTP系统来说，重要的是必须保证一致性和稳定性。想象一下，你经营着一家大型地区电信公司，而电信系统却瘫痪了。影响可能是巨大的。客户无法再拨打电话、接听电话、接收短信等。如果系统停机时间过长，业务模式将受到影响。客户失去信任而离开。因此，OLTP系统是为数据完整性、系统稳定性和可用性而设计的。绝大多数符合ACID。

我们可以从OLTP系统中观察到，（操作）工作负载通常是可以预测的。我们知道OLTP系统是如何使用的，以及预期的典型负载是什么。查询相对简单，检索到的数据量相对较低：读取记录、更新记录、删除记录等。底层物理数据模型是基于这些可预测的查询设计的。OLTP系统中的表通常是标准化的。理想情况下，每个属性只存储一次。

这种规范化的设计有一些缺点：操作系统的设计并不是为了提供领域或业务中正在发生的事情的可代表的全面视图。对于复杂的问题，从高度规范化的数据模型中提取数据往往很困难，而且需要大量的性能。复杂的问题需要更多的数据和数据组合。编写这样的查询需要将许多表连接或分组在一起。这些类型的查询通常相当占用性能，因此执行过多的查询会带来达到性能限制的风险。如果是这样，系统就会变得不可预测，这是我们最不希望看到OLTP系统发生的事情，因为我们需要提供信任。

具有高完整性和高可用性性能的结果是OLTP系统是昂贵的。它们通常无法保留大量数据，因此数据生命周期管理对于保持它们的健康和适用性非常重要。通常，未使用的数据会被删除或移动到辅助位置。从这个辅助位置数据，如果它再次变得相关，总是可以放回原处。

OLTP系统是传统数据库划分方式的一部分。另一部分是OLAP系统，将在下一节中讨论。

OLAP（在线分析处理）

业务用户希望通过检查大型且更复杂的数据集合来分析数据，以便做出业务决策。由于OLTP系统价格昂贵，并且可以实现不同的目的，因此通常的最佳实践总是将数据取出，并将其转移到另一个环境中。其他环境（不同的系统和数据库）将用于在线分析处理（OLAP）：复杂的分析处理。由于离线分析通常不太关键，因此完整性和可用性要求可能不那么严格。考虑到这一点，您可以说OLAP系统通常比OLTP系统便宜。

在OLTP系统中，数据是为了完整性和冗余性而存储和优化的，但在OLAP中，我们会针对分析性能进行优化。由于我们主要进行重复读取，几乎不进行任何写入，因此通常会优化以更密集地读取数据。可以对数据进行复制，以促进各种分析场景的不同读取模式。OLAP数据库中的表通常不是高度规范化的，而是经过预处理和非规范化的结构：表是扁平的、稀疏的，并且包含更多的冗余副本。重复存储数据。这听起来无效，但当数据在逻辑上分组并物理存储在一起时，系统更容易处理数据并更快地交付结果。由于OLAP系统价格较低，我们可以使用更多的数据存储。

注意：有些系统结合了OLTP和OLAP。这些系统被称为混合事务/分析处理，这是Gartner创建的一个术语。尽管这些系统在外部看起来像是新兴的体系结构，但在内部，通常仍然有两个数据库。一个数据库是为许多具有高更新率的小型事务而设计的。另一个（内存中）数据库处理分析工作负载的复杂查询。这种将命令与查询分离的方法与CQRS非常相似。

OLAP系统通常还用于通过存储来自OLTP系统的未使用或不太频繁使用的数据来促进数据生命周期管理。这样做有两个原因。第一个原因是历史数据很有价值，因为为了进行分析，我们经常会回顾过去。性能是第二个原因。OLTP系统将其数据复制到OLAP系统后，通过删除冗余副本进行清理。这种维护活动使OLTP系统更有效，因为如果表包含的数据更少，查找和查询将运行得更快。

在OLAP系统中，来自多个OLTP系统的数据通常被汇集在一起，因为业务用户或数据分析师通常希望对数据进行组合。这需要一种协调或统一的形式，因为系统使用不同的上下文，具有不同的数据结构。

什么是操作数据存储？业务数据存储（ODS）通常用于业务分析和报告。ODS具有OLTP和OLAP系统的一些特性。“操作”一词使ODS更接近OLTP系统，因为它们的目的是深入了解操作性能和活动。它们主要继承OLTP系统的上下文。

OLAP系统的特点是ODS旨在消除分析工作负载，而分析工作负载是由专门的、预测性较差的分析和报告引起的。另一个特征是ODS通常比OLTP系统保留更多的历史数据。还有一个特点是ODS可以集成来自其他系统的小部分数据。这意味着在设计消耗臭氧层物质时也可能涉及到一体化或协调方面。

然而，一般来说，ODS更接近于它们所处的主要OLTP系统的设计。表格结构通常是相似的。因此，ODS与数据仓库不同，因为它们通常只使用来自一个OLTP系统的数据，而不像数据仓库那样容纳来自多个来源的数据。

多源系统的协调是通往数据仓库的一座很好的桥梁，因为它们还考虑到了历史需求，将数据整合成一种协调的形式，并促进了分析活动。因此，数据仓库也可以归类为OLAP。

 

数据仓库是如何工作的？

现在我们知道数据仓库将来自多个来源的数据统一为一个集成的数据模型（事实的单一版本），是时候更深入一点了。在接下来的部分中，我想讨论构建和操作数据仓库的一些常见特征和样式。最流行的款式是由行业领袖Bill Inmon和Ralph Kimball开发的。

Inmon风格

Bill Inmon的观点是，任何可能有用的数据都应该存储在一个单一的通用数据模型中，该模型将是企业的“单一真相来源”。这个真相来源使用了一个整数和有效的存储模型，通常是3NF结构。从这个单一的真相来源，为特定的项目、用例或部门做出选择（子集）。这个选择的子集被称为数据集市，它针对用例的读取性能进行了优化。

Kimball风格

Ralph Kimball的观点是，数据仓库必须是维度数据的集合或集合，这些数据是来自源系统的事务数据的副本。由于数据仓库用于各种用例，Kimball有“一致维度”的概念，这是不同消费者共享和使用的关键维度。

在接下来的部分中，我们将更仔细地研究这两种样式，以及设计和构建数据仓库时始终需要的一些通用组件。我们将从暂存层开始，然后讨论数据仓库的其余部分。

暂存区

要设计数据仓库，需要一些额外的组件。在Inmon和Kimball方法中，必须首先提取数据并将其存储（暂存）在中间存储区域中，然后才能进行处理。这种让数据首先“着陆”的环境被称为暂存区，如下图所示。

暂存区总是位于数据源和数据目标之间，这些数据源和目标通常是数据仓库。它们用于解耦系统，并在提取、转换和加载（ETL）过程中发挥重要作用。暂存区可以通过不同的方式实现，不同于关系数据库和文件存储。此外，数据捕获方式的实现也可能有所不同：推送数据、提取数据或使用CDC。数据通常以原始操作格式提供，尽管在此模型也可能存在变化。我稍后再谈这个。

暂存区域通常也用于保留历史副本。这对于重新处理场景非常有用，在数据仓库损坏并且需要从更长的时间段重建的情况下。较旧数据传递（历史副本）的数量可能因暂存区域而异。我见过一些用例，其中所有的数据交付，包括更正，都必须保存数年以供审计。在其他用例中，我看到在成功处理或经过一段固定时间后，暂存区域被清空（非持久性）。清理可以节省存储空间和成本。

暂存区在数据质量领域也发挥着重要作用。在开始将数据摄入数据仓库之前，建议首先验证所有数据。如果任何源丢失或数据无效，则可以暂时停止或暂停处理。可以要求来源再次提交或对数据进行更正。一旦满足所有验收标准，就可以真正开始处理数据并将其引入数据仓库的集成层。

集成层

在成功检查所有数据并满足暂存层的所有验收标准后，数据就可以集成到集成层中了。在这里，所有经过清理、更正、丰富和转换的数据都使用统一的上下文存储在一个集成的通用模型中。它是统一的，这意味着统一已经应用于格式、类型、命名、结构和关系。此外，历史数据预计将在该层中，尽管与暂存区的不同之处在于数据已转换，不再是原始数据。

集成层以及数据的存储和结构化方式也是Inmon和Kimball样式不同的地方。

Inmon风格

在Inmon风格中，所有数据首先进入（中心）集成层，该集成层具有标准化的关系模型。这意味着数据已针对冗余进行了优化。您可以争辩说，这一层与我们在OLTP中讨论的数据模型相似，您是对的。它代表了交易系统，但以一种协调的方式，这意味着统一应用于格式、字段名称、数据类型、关系等。这一实现需要进行大规模的前期数据建模，以调整所有不同的源系统结构，并将其转换为一个协调统一的数据模型。从阶段到集成层的步骤通常会导致特定而复杂的ETL逻辑。

Inmon样式还引入了数据集市。在数据存储在集成层中之后，将为消费者创建额外的层。这些（表示）层被称为数据集市或维度数据集市。它们通常只包含集成层数据的一个子集。它们也特定于一个用例、一组或一组用户。数据集市中的数据通常是按维度结构组织的，因为它已经针对读取性能进行了优化。数据集市通常使用多维数据集来实现，尽管它们也可以使用关系数据库（使用星形和雪花模式）来实现。数据集市的附加层有一个好处：数据集市与集成层解耦。如果谨慎地对集成层进行更改，则不应影响数据集市，从而影响数据消费者。

Inmon的风格有几个缺点。第一个缺点是开发时间通常很长。设计一个整数和规范化模型需要时间，因为所有不同的源系统都需要仔细映射。完整性和一致性是重要的驱动因素。随着源的大小和数量开始增加，具有依赖关系的关系数量也会大幅增加。这可能会导致设计中的级联效应：无尽的父子复杂性或结构。

另一个缺点是，如果必须将新数据添加到数据集市，那么数据总是必须首先添加到集成层。由于开发需要时间，并且必须小心地对集成层进行更改，因此需要新数据的用户必须等待（很长时间）。下面的列表总结了Inmon风格的优点和缺点。

好处

• 由于集成层的（高度）规范化模型，数据冗余度非常低。
• 数据集市与集成层解耦。
• 一致的设计，非常适合历史数据。
• 大多数工程师都熟悉3NF规范化原理。

不利因素

• 开发时间更长。需要复杂的ETL逻辑来将数据映射到集成层的重规范化模型。
• 数据摄取的更高耦合性引入了依赖性，要求同时摄取所有源。这降低了摄入的并行性和灵活性。
• 新关系的发展。由于所有表的引用完整性，因此存在大量ETL负载依赖关系。
• 如果来源消失或发生重大变化，引用完整性将成为一个问题。

Inmon样式与Kimball样式的区别主要在于集成层。

Kimball风格

在Kimball样式中，集成层中的数据与事务系统中存储数据的方式不同。当数据被复制到集成层时，它已经针对读取性能进行了优化。数据更加扁平、稀疏，因此与Inmon风格的数据集市结构有相似之处。与Inmon相比，这里的区别在于集成层是维度表的集合，这些维度表是数据集市的组成部分。数据集市只是不同表与一些附加表的逻辑区分或选择，以将所有内容链接在一起。在这种方法中，数据仓库是所有单个数据集市的组合。这样做的好处是可以更好地理解这些维度表，因为绝大多数的父子结构都减少了。

Kimball风格的一个重要方面是数据在逻辑上被分组为所谓的事实和维度。事实是定量的数字：销售数字、金额、计数等。维度代表业务实体，因此客户、产品、员工、合同等。通过将事实和维度联系在一起，创建了一个星形模式。从概念上讲，这些与数据集市相同，不同之处在于它们位于同一集成层，并共享相同的底层数据库技术。Kimball模型的好处是，这种风格比Inmon具有更高的短期灵活性。通常，用户不需要等待数月或数年才能开始消费。

尽管数据是有组织的主题区域，用户更容易理解，但Kimball风格也有一些缺点。由于每个数据集市都是为特定的用户组创建的，因此通常需要许多额外的表来创建更具体的星形模式。由于用户将有更多相互冲突的需求，因此将需要更多的“辅助”表。

在Kimball中，更多耦合的可能性也更高：用户可以开始重用其他用例或用户的集成逻辑或辅助表。因此，随着规模的增长和用户数量的增加，复杂性也在增长。因此，即使是结构的微小变化也会对所有用户产生很大影响。

另一个含义是，在加载数据时，在加载维度之前出现的事务（事实）可能会出现问题。最后，由于表上应用了高级别的非规范化，更新和删除可能会占用大量性能。在下表中，我列出了Kimball风格的所有高级优点和缺点。

好处

• 更适合于多维分析。
• 按照业务主题领域进行组织，这使得非it用户更容易理解。
• 与Inmon相比，开发时间更快，因为只有一个ETL过程可以将数据加载到最终的数据模型中。
• 在链接聚合点方面具有更大的灵活性。

不利因素

• 表示层没有解耦。重用或共享辅助表会导致更紧密的耦合。
• 在维度表之前加载事务（事实）时存在引用完整性问题。
• 由于非规范化，更新和删除的成本更高。如果数据更新不正确，完整性也可能成为问题。
• 更大的数据量（与Inmon相比）。

基于这两种方式的优缺点，工程师们开始试验并结合不同的方法。一个例子可以是核心数据仓库模型，它是基于Inmon的，但扩展了基于Kimball的维度表。Data Vault技术是对这些替代方法的补充。

Data Vault样式

Data Vault最初由Dan Linstedt创建，在北欧特别流行。Linstedt将数据仓库定义为一组面向细节的、历史跟踪的、唯一链接的规范化表，这些表支持一个或多个业务功能领域。此定义中没有尝试将数据保管库用于清理或集成的数据。没有做出任何努力来协调源系统之间的数据模型差异。相反，数据保管库依赖于下游体系结构组件来显示可用于分析的数据。

数据保险库通过集线器、卫星和链接表解决了Inmon和Kimball的灵活性问题。通过分离的表，数据存储更加解耦，允许并行数据加载，并在执行更改时具有更大的灵活性。关系可以很容易地被丢弃并在运行中重新创建，新系统可以在没有任何中断的情况下集成到现有模型中。

这些灵活性的改进也有一个缺点：数据保险库本身并不直接适用于特定的查询和分析，因为查询所有的集线器、卫星和链路，将它们连接在一起，是性能密集型的。在大多数情况下，它需要一个额外的表示层或数据集市层。

Data Vault中的表数明显高于3NF建模。它要求需要更多的ETL作业来确保不同表之间的隔离和引用完整性。这增加了复杂性，使工程师更难理解数据仓库是如何设计的。像Wherescape这样的公司可以通过元数据生成ETL作业来帮助解决这些问题。

最后一个方面是没有严格或正式的标准。Data vault在概念上描述得很好，但人们使用的是实现变体。Dan Linstedt、Kent Graziano和Hans Hultgren都是该领域的专家，他们都主张数据库的不同性，这会带来在大型项目中应用冲突风格的风险。

下面的列表包含data vault的高级优点和缺点。

好处

• 更能适应变化。更高的灵活性
• 适合实时使用。解耦实现并行处理
• 可以使用更灵活和增量的开发方法

不利因素

• 使用Data Vault建模技术时需要大量连接。这可能是一个真正的性能打击。需要额外的“表示层”或“数据集市层”。
• 由于最佳实践和方法各不相同，需要更有经验的工程师和就指导方针达成强有力的一致意见
• 需要更多的ETL作业和表。这可能会增加复杂性并减少概述。混合方法也会让工程师更有创造力，从长远来看，这会带来额外的复杂性和不一致性

数据仓库因其集成层和复杂的数据模型而区别于其他应用程序。它们消耗、组合、协调和集成数据。这些集成技术需要数据建模专业知识，这通常与设计和开发常规应用程序不同。

获取数据

如果不从不同来源提取数据，就无法创建数据仓库。在前面的部分中，我们了解了暂存区的作用，以便于数据以不同的格式汇集在一起。我们没有讨论的是这些数据源的格式或结构。

一种常见的传递数据的格式是使用源系统的原始（相同）格式。通常会提供完整的数据集合，因此最终得到的是平面文件形式的所有表的完整原始提取。这种交付风格的一个缺点是与源系统的内部数据结构高度耦合，因为它们是相同的表示。如果源系统更改其结构，则处理数据可能不再有效。

向数据仓库交付数据的另一种方法是商定某种形式的抽象，以降低耦合风险。结构可以约定得更简单，可以有固定的格式。这些更改至少消除了每当源系统更改其结构时进程中断的情况。

一种更极端的抽象形式是要求源系统使其数据交付符合集成层的格式。此方法中来自源系统的文件必须以与数据仓库完全相同的格式交付。我认为这种抽象形式也是高度耦合的，因为当集成层发生变化时，它要求所有源同时发生变化。

注意：大多数商业供应商（Oracle、SAP、Siebel等）的操作系统都使用高度专业化和规范化的数据模型，这些模型会随着每个发布周期的变化而变化。这些数据模型很难解释。人们知道如何解释这些数据模型并将其映射到数据仓库中，从而过上了体面的生活。

为了使数据集成更容易，通常会选择标准化的格式。逗号分隔值（CSV）和Parquet是最受欢迎的两种选择，因为大多数数据库和ETL工具都可以使用这种格式。XML和JSON也可以使用，但这些格式通常会产生更多的开销，因为其中包含了大量元数据。

使用完整提取的另一种选择是根据数据更改或增量请求或提取数据。这种方法只提供更改后的数据。一种流行的设计模式是使用变更数据捕获（CDC），它得到了不同供应商的良好支持，可以使用各种机制：基于时间戳、基于版本、基于指标等等。

ETL功能

收集完所有数据后，下一步是将数据集成到集成层中。数据需要被清理、映射并转换到数据仓库的统一数据模型中。这需要ETL工具，并且可以通过几种方法来实现。

最常见的方法是使用商业ETL工具从暂存区提取数据，转换并加载到集成层。Informatica、SQL Server Integration Services、Ab Initio、Infosphere Information Server、Talend、Pentaho和Oracle Data Integrator是许多大型企业的热门选择。这些工具具有广泛的功能、大量的数据库连接器、调试和测试功能，通常具有直观的外观。他们可以将数据提取到自己的本地环境中，也可以将工作委托给目标数据库。这些商用工具的一个常见缺点是紧密耦合。一旦您为数据仓库选择了ETL供应商，您就与该供应商结下了不解之缘。

ETL工具的另一种选择是自己构建一个ETL框架。我见过很多公司，他们从元数据存储库中生成ETL代码（Java、Oracle的PL/SQL、Teradata的SQL等）。将所有集成逻辑编码并存储在源代码存储库（如git）中也并不罕见。一些公司试图实现商业供应商所提供的功能，包括直观的基于web的前端、调试功能、数据跟踪和跟踪、沿袭等。自己构建ETL工具的好处是松耦合。只要您遵守常用的开放标准ANSI SQL，您就可以随时取代数据仓库的数据库技术。“自己动手”的场景需要高技能的工程师进行维护和开发。随着时间的推移，工程师可能会离职。具有ETL知识的商业供应商的资源通常更容易吸引。

数据仓库生态系统中的ETL处理通常不允许有很多变化。通常使用单个产品或框架。由于复杂性，ETL工具也很可能被安排在固定的时间窗口中运行。由于性能原因，处理时间通常很长。生态系统是静态的另一个原因是，许多企业害怕对ETL进行重大更改：代码通常很大，非常复杂，因为它是经过多年开发而演变而来的。

数据虚拟化

在介绍了这篇博文之后，我提到了一些技术趋势改变了数据仓库的构建方式。其中一项技术是数据虚拟化：数据保持不变，源可以作为一个数据库进行访问和查看，而无需以批处理为导向来物理提取和复制数据。详细地说，有一个数据虚拟化层，它将自己呈现为一个集成层，通过虚拟地和运行时提取、转换和集成数据来缓存数据。这项技术附带了一个应用程序组件：一个虚拟化引擎，它处理所有传入的查询，确定最佳缓存策略，知道如何访问不同的数据存储技术，知道如何集成数据等等。在引擎盖下，有很多元数据用于构建抽象。我在下面的图片中看到了这种技术。

尽管这种技术看起来很有吸引力，但它也有潜在的缺点：

取出过多的数据可能会导致OLTP系统故障或变得不稳定。数据虚拟化通过“缓存”数据来解决这一风险，这意味着一个副本被保存到虚拟化引擎中，但这种模式并不能完全消除风险。当路由过多的查询时，仍然可能会损害OLTP系统。或者，你可以加快这些速度，但这可能非常昂贵，因为操作系统比分析系统相对更昂贵。

数据虚拟化层导致了更紧密的耦合。如果源系统发生更改，也需要立即更改数据虚拟化层。视图或其他层可能会有所帮助，但任何更改仍然需要源系统所有者和维护数据虚拟化层的工程师之间的交叉协调。

消费者直接受到数据质量的影响，数据虚拟化不允许您创建新数据，如果您想进行更正，则需要创建新数据。

数据虚拟化依赖于网络。在具有大量网络和跳数（通过额外的网络设备）的高度分布式环境中，延迟预计会增加。此外，还有耦合，因此如果网络出现故障，集成层就会断开。

数据虚拟化不是对数据生命周期管理的补充。它无法将不相关的数据移出底层系统。它要求所有历史数据都保留在OLTP系统中，从长远来看，这使得数据虚拟化成为一种昂贵的解决方案。或者，您可以将数据移到辅助位置，然后在虚拟化层中再次组合，但这种方法会增加复杂性，因为您需要开发和维护几个抽象层。

数据虚拟化受到底层支持技术的限制，该技术通常是关系数据库管理系统。尽管数据虚拟化可以读取许多数据库系统，但如果需要，它通常不允许创建文档、键值、列式和图形数据库端点。

对于密集和可重复的查询，数据虚拟化使用更多的计算能力，因为在查询数据时会实时进行转换。缓存技术可以减少这种情况，但在对数据进行物理转换和存储后使用数据时，计算能力总是更具可比性。

注意：一些数据库供应商提供数据库（虚拟）查询层，也称为数据虚拟化层。该层对数据库进行抽象并优化数据以获得更好的读取性能。另一个抽象的原因是为了更好的安全性而拦截查询。亚马逊雅典娜就是一个例子。

尽管存在这些缺点，但数据虚拟化可以帮助迁移场景。使数据库虚拟化并成为新功能的一部分可以减轻痛苦。数据虚拟化也是实时的，因此与ETL工具相比，对于相对少量的数据来说速度更快，ETL工具需要在消费发生之前处理和持久化所有数据。

商业智能

我们还没有过多详细讨论的最后一个功能是商业智能（BI）工具，它用于生成见解并呈现结果，以实现平稳的商业决策。随着数据仓库随着越来越多的数据开始出现，它们变得相当流行。这些年来，他们还扩大了自己的能力。最初的版本只包括简单的报告和仪表板功能，但后来的版本提供了强大的可视化功能，支持自助服务、智能缓存技术和预测分析。因此，商业智能并不排除（预测性和规范性）高级分析：这两个学科都是互补的，可以相互加强。

现代商业智能工具在可使用的来源数量方面也相当灵活。传统上，BI工具与数据仓库的耦合更紧密，但以后的几代工具能够从多个更高种类的源系统中提取和组合数据。BI工具也可以只提取更改，并将数据保存更长时间到所谓的立方体中。这些多维数据集与数据虚拟化有一些相似之处，因为它们还抽象了底层源，可以直接提取数据或缓存数据。

OLAP、ROLAP、MOLAP和HOLAP之间有什么区别？多维数据集也称为OLAP多维数据集，是对数据进行预处理和预汇总的集合，可大大缩短查询时间。OLAP（在线分析处理）是指使数据易于访问以进行分析决策的专用系统或工具。OLAP多维数据集是由元数据定义的逻辑结构。多维表达式（MDX）是一种流行的基于元数据的查询语言，支持您查询这些OLAP多维数据集。供应商提供各种OLAP产品，您可以将其分为三类：

• ROLAP（关系在线分析处理）：ROLAP产品和关系数据库紧密合作，支持OLAP。星型模式结构通常用于扩展和调整底层关系数据库结构，以将其自身呈现为OLAP服务器。
• MOLAP（多维在线分析处理）：MOLAP产品通过将数据放入立方体结构中来提供多维数据分析。此模型中的数据经过高度优化，以最大限度地提高查询性能。
• HOLAP（混合在线分析处理）：HOLAP产品将MOLAP和ROLAP结合在一起，对大多数数据使用关系数据库，对最密集的数据（通常是数据的一小部分）使用单独的多维数据库。

现代BI工具还可以通过允许您在其“存储层”中集成（ETL）和持久化数据，而不是在数据仓库中集成和存储数据，使数据与它们保持紧密联系。我个人的建议是，当数据需要重用时，只将数据存储在数据仓库中。对于短期和一次性的集成练习，更建议在业务智能解决方案内部进行集成。

您已经了解了很多关于数据仓库如何工作、集成层的组织以及数据是如何获取和使用的。在下一节中，我们将讨论数据湖，有些人称之为第二代数据存储库。

Data Lake

随着数据量和对更快见解的需求的增长，工程师们开始研究其他概念。数据湖开始成为访问原始数据和更大数据量的替代方案。通过按原样提供数据，无需首先构建数据，任何消费者都可以决定如何使用数据，以及如何转换和集成数据。

数据湖和数据仓库都被认为是集中的（整体的）数据存储库，但它们不同，因为数据湖在数据转换、清理和结构化之前存储数据。因此，模式通常是在读取数据时确定的，而不是在固定结构中加载数据。它们还支持多种格式：结构化、半结构化和非结构化。

数据仓库和数据湖之间更大的区别在于所使用的底层技术。数据仓库通常使用关系数据库系统进行设计，而数据湖通常使用分布式数据库或NoSQL系统进行设计。Hadoop是一个受欢迎的选择，因为它运行在商品硬件上，因此具有成本效益。它还具有高度的可扩展性、开源和模块化，具有多种数据库类型和分析框架。

使用公共云服务也是构建数据湖的热门选择。最近，在容器基础设施之上的分布式和完全管理的云规模数据库简化了大规模管理集中式数据存储库的任务，同时增加了弹性和成本优势。

如上图所示，许多数据湖从原始源系统收集纯的、未经修改的原始数据。转储原始数据（确切的数据副本）速度很快，使数据分析师和科学家能够快速访问。然而，原始数据的复杂性在于，用例总是需要重新处理数据。必须解决数据质量问题，需要进行聚合，并需要与其他数据进行富集，以将数据带入新的环境。这引入了大量可重复的工作，也是数据湖通常与数据仓库相结合的原因。

在这种数据湖组合中，数据仓库充当净化和协调数据的高质量存储库，而数据湖充当分析环境，保存各种原始数据以便于分析，如数据发现、数据科学和处理非结构化数据。当组合在一起时，结果或见解会流回数据仓库，而数据湖是为原始数据构建并（手动）操作的。

通过了解什么是数据湖，我们可以进入下一节，在这一节中，我想讨论数据仓库和数据湖在组织中的应用规模。

企业数据仓库和数据湖的陷阱

随着人们开始看到数据仓库的好处，计划和范围变得越来越大。公司指示人们去培训设施，准备开始建造一些大型建筑。业务用户被要求将他们的所有需求交付给中央数据仓库工程团队。启动了提供企业数据仓库（EDW）的大型项目。EDW是一个中央数据仓库，其目标是创建单一版本的真相，并为整个组织的所有报告和数据分析需求提供服务。

尽管下图是企业数据仓库的高级表示，但您可以看到许多集成点、集成步骤和依赖关系的复杂性。一旦企业数据仓库开始增长，其复杂性就会呈指数级增长。在你知道之前，你最终会陷入一种不舒服的境地，变化被视为瓶颈。

在接下来的部分中，我想讨论一些广泛的观察结果和故障模式。在我们继续之前，我想请你深呼吸，把你的偏见放在一边。将大量数据纳入特定环境的数据统一需求始终存在，但我们必须考虑的是我们希望应用这一学科的规模。这真的是在任何用户或应用程序使用所有数据之前集中处理所有数据的最佳方式吗？

单一规范模型和不必要的模式翻译

EDW要求数据提供者和数据消费者就单个（企业）规范数据模型达成一致。在我看来，这一单一版本的真相是公司无法扩大规模的最大问题。在大型生态系统中，存在许多不同的环境。构建一个能满足每个人需求的集成层是一个巨大的挑战，因为它需要每个人都同意。公司越大，你看到的冲突就越多，达成一致和保持一致所需的时间就越长。

我对规模协调的第二大问题是价值的丧失。工程师在建立数据仓库时需要做出解释。例如，合同的开始日期是什么？有很多可能的答案。开始日期可以是合同的合法签署日期，也可以是系统的预订数据。开始日期也可以是法律部门给出的批准日期。它可以是开始使用的日期，也可以是第一次付款的开始日期。这些定义的含义在不同部门之间存在差异，并且在系统中具体实现的可能性相对较高。我们要么最终制造了许多变化，要么接受了差异和不一致。我们添加的数据越多，定义中出现的冲突和不一致越多，协调就越困难。很有可能你最终会得到一个对每个人都毫无意义的统一环境。

另一个问题是，数据和上下文在集成过程中被丢弃。一个域中非常特定的值范围被映射到具有较少详细信息的范围，以支持另一个域，聚合由详细信息组成，或者省略字段。对于机器学习等高级分析来说，忽略这些细节是一个大问题。分析模型，如机器学习，可以更精确地处理详细的数据。

附加转换步骤

当大规模使用数据仓库时，第二个问题是需要额外的转换步骤。数据总是必须首先集成到数据仓库中，然后才能使用。这一步骤意味着需要大量的等待时间，因为在数据仓库中，几乎所有组件之间都存在继承耦合。表具有对其他表的引用，表具有对ETL作业的依赖关系。一个表中的更改通常会强制其他表和ETL作业中的更改产生连锁反应。这种复杂性需要大量的工作和增加等待时间，这开始让人们富有创造力。

什么是一个大泥球？一个“大泥团”是一个结构随意、杂乱、邋遢、胶带和打包线的意大利面条代码丛林。这是一个普及的术语，最早由布莱恩·富特和约瑟夫·约德创造。一个巨大的泥球描述了一个系统体系结构，它是单片的，难以理解，难以维护，并且由于其许多依赖性而紧密耦合。下图显示了说明这一点的依赖关系图。每一行表示两个软件组件之间的关系。

数据仓库及其集成层、无数的表、关系、脚本、ETL作业和调度流，往往以混乱的依赖关系网告终。这些复杂性使得你经常会在一段时间后陷入他们所说的一个大泥团。

为了节省时间，工程师可能会建议绕过集成层，将数据从源系统直接映射到数据集市。另一种可能建议在两个不同的、已经存在的数据集市之上构建一个数据集市，因为更改集成层需要太多时间。这种技术债务（未来返工）将在以后造成问题。建筑变得更加复杂，人们对为了按时交付而创造的所有创造力和快捷方式都失去了洞察力。

引爆点

数据仓库的特点是其来源和消费者数量呈指数级复杂度。添加的源越多，进行更改就越困难。这一原则同样适用于数据消费者入口点的数量。如果您有许多数据集市位于集成层的顶部，那么对集成层进行更改可能会产生很大的影响，因为它的更改会对数据集市产生影响，而数据集市需要与所有数据消费者密切协调。

我还看到了一个“临界点”：一旦你到达一定数量的源和数据集市，敏捷性就会降至几乎为零。整合大量的资源需要巨大的协调和统一。几个月的发布周期对于复杂的数据仓库系统来说并不是例外。

无休止的利益相关者讨论

由于变更的紧密耦合和漫长的发布周期，利益相关者排队等候，必须就优先级达成一致。我看到工程师和业务用户之间进行了长时间的讨论，以就数据仓库中新数据的优先级或集成层的更改达成一致。这些讨论不会增加任何直接的商业价值。

苛刻的消费者

单片平台的灵活性问题引入了消费者不耐烦的习惯。向EDW和数据湖添加数据可能需要很长时间，因此用户开始要求消耗所有数据。访问所有数据可以消除等待时间过长的风险。我见过数据集市，其中几乎包含来自集成层的所有数据。所有数据集市的存储空间总和成为集成层所需的所有存储的倍数。这并不能使体系结构具有成本效益。

我还看到业务和IT用户同时访问数据集市和集成层。用户在数据集市和集成层之上构建视图，以快速满足他们的需求。这些视图再次暴露给其他用户。最终，可以看到无尽的层叠效应。用户在不知道数据的确切来源的情况下提取数据。

消费者通常没有设定任何要求。提供数据是因为业务用户有要求，否则将进行升级。如果没有达到时间线，通常会创建点对点接口。

协调压力

大规模运营数据仓库和数据湖的另一个问题是，需要工程师和IT用户协调数据交付。源可能会更改，接口可能会断开，这需要升级以修复问题。我也见过工程师自己处理问题的情况。例如，修复暂存层中的数据，以便将数据正确加载到数据仓库中。这些修复是永久性的，随着时间的推移，在数据处理开始之前，必须应用数百个额外的脚本。这些脚本不是值得信赖的ETL过程的一部分，也无法追溯。预计这将对血统和透明度产生重大影响。

数据质量和治理

数据治理通常也是一个问题，因为谁拥有数据仓库中的数据？如果源系统出现故障，数据被破坏，谁负责？当出现问题时，许多源系统工程师会指向数据仓库工程师，因为他们会将数据转换为系统所有者不知道的东西。反之亦然，数据仓库工程师指责源系统所有者提供了不正确的数据。

数据质量，所有权讨论的另一个要点。因为在数据被转换后，源系统所有者无法识别它。源系统所有者将糟糕的数据质量归咎于DWH工程师。在许多实现中，我看到数据仓库工程师负责数据质量。数据在加载到数据仓库之前或之后是固定的。特别是出于完整性的原因，正确设置表之间的关系非常重要。但事实是什么数据？用户开始将操作系统的数据和结果与数据仓库的数据进行比较。没有人知道真相到底是什么。操作系统和数据仓库之间的数据质量可能会出现严重差异，以至于没有人信任数据。

历史数据

历史数据的数据生命周期管理也是一个问题。因为EDW被视为真相的档案，操作系统在知道数据将保留在仓库中的情况下，会清理不相关的数据。如果运营系统需要根据自己的历史数据制作分析报告，会发生什么？在许多情况下，ODS可以满足这一需求，但我也看到一些公司为此目的使用EDW。这带来了一个有趣的模式。首先，业务数据被移动并转换为一个统一的模型。其次，相同的数据被传输并转换回（逆向工程）其原始上下文。

对于操作高级分析，通常需要历史数据。由于机会之窗往往转瞬即逝，预计它会很快出现。为此目的使用数据仓库通常是一个问题，因为它们通常要处理数小时的数据。

数据离开集中式平台

集中保存和管理数据是一个问题，因为组织的需求非常多样化，种类繁多：不同类型的解决方案、不同规模的团队、不同类型的知识、从防御到进攻的不同需求等等。由于激增，将所有东西放在一起是一个大问题。

EDW和数据湖与所选的底层解决方案或技术紧密相连，这意味着需要不同读取模式的消费者总是需要将数据导出到其他环境。随着供应商环境的变化和新型数据库的出现，这些单一平台变得越来越分散，总是被迫导出数据。这一趋势破坏了高效使用“单一中央存储库”的概念。因此，创建了点解决方案，并且数据仓库的底层硬件仅用于ETL处理和数据持久性。这是一种真正的浪费，因为数据仓库系统通常使用非常昂贵的硬件，并针对密集的查询进行了优化。

在数据被携带并被丰富之后，它通常也被进一步分发。这意味着数据消费者开始充当数据提供者。对于大规模环境中的数据消费者来说，这种情况可能会非常令人困惑，因为数据来源于哪里？一些消费者在没有意识到数据也被间接消费的情况下开始消费。这使得链条更长，因此更脆弱。

数据的进一步分布和扩散也带来了另一个问题。许多数据消费者不知道在哪里可以找到正确的数据，因为数据分布分散在整个组织中。操作系统是否适合查找？企业数据仓库？数据湖？或者可能是另一个数据消费者，他们可能已经对数据做了稍微更好的准备？用户对数据使用最快的路线，即距离最短、阻力最小的路线。EDW和数据湖变成了意大利面条式的建筑。其他人则称之为一个大泥球。不协调的更改、不受监管的增长和数据分发会损害整个企业数据体系结构。一致性、洞察力和最重要的灵活性都会丧失。

数据提供商没有洞察力

EDW和数据湖往往缺乏对特定消费和进一步分发的洞察力，尤其是当数据是在DWH生态系统中进行时。有了新的监管，如GDPR或CCPA，深入了解消费和分发是很重要的，因为你想解释哪些个人数据被谁消费以及用于什么目的。从逻辑上讲，数据的创建和来源应该从哪里开始，责任就从哪里开始。企业数据仓库的问题在于，数据提供者没有控制权，洞察力有限。无法控制数据消耗，也无法深入了解数据的进一步分布或数据的用途。

服务导向单独实施

在许多组织中，面向服务的API的创建是由一个独立的团队通过企业规范模型来处理的。这很奇怪，因为面向服务和EDW都使用和依赖相同的操作系统。一个单独的实现创建了两个不同版本的真相。这可能导致组织中的两个阵营和两个不同的词汇表，它们具有不同的数据含义。然而，最初的来源和它们的背景仍然是一样的。

痴迷的福音派与古典思想家

这似乎有点夸张，但企业数据仓库也有传道者。大多数数据计划一开始都有很多好的意图，但当时间不那么繁忙时，工程师们会继续绘制数据。整合数据不再是为了数据消耗，而只是为了数据本身。数据集成成了一种爱好。副作用是，各种数据仓库变得不必要的复杂，而且太难维护。其中一些传道者只是在讨论建模技术，而不是关注业务用户及其需求。业务用户感觉没有被完全理解，因此造成了缺乏信任。

另一个问题是企业数据仓库和数据湖团队如何与传统的软件工程师组装在一起。许多都具有数据库管理员（DBA）背景，用于设计整体结构。他们被困在过去，缺乏当今的现代技能，如数据操作、领域驱动设计、分布式和进化设计思维、数据版本控制、CI/CD和自动化测试经验等。因此，扩大和满足当今的现代需求是一个挑战。

参考模型

许多EDW通常建立在“预制”、现成的行业特定数据模型之上。例如，IBM、Teradata、Oracle和Microsoft为不同的行业提供这些数据模型。我对这些特定于行业的数据模型的问题是，它们是供应商的真相版本，而不是您的。其中许多模型过于详细和充满了假设。这些细节要求您只使用键来填充许多空表。因此，集成层变得非常大和复杂。

逻辑数据仓库

还有一种将EDW（数据湖）与数据虚拟化相结合的方法。它们被一个额外的虚拟抽象层“补充”。对底层集成复杂性进行了抽象，并创建了新的集成数据视图。这些可以跨越操作系统和许多其他应用程序。Gartner研究总监Henry Cook称这种设计模式为逻辑数据仓库。尽管不必向企业数据仓库添加新数据在短期内会带来灵活性方面的好处，但从长远来看，这将是一个灾难性的失败。

首先，通过抽象来替代复杂的集成逻辑是很诱人的，但所有潜在的复杂性仍然存在，包括所有的操作和技术开销。其次，它通过直接旁路将数据平台扩展到操作系统和特定数据源，同时直接重用数据平台的部分内容。正如您所了解到的，这些操作系统中的许多都没有针对密集的读取访问进行优化，也无法保留大量的历史数据。第三，与操作系统、数据平台和虚拟化产品都存在紧密耦合。对数据平台或操作系统的底层物理结构的更改，如果没有仔细协调，将立即破坏逻辑层。最后，所有的数据集成仍然是“漏斗式”的，因为数据虚拟化只是维护企业数据模型的另一个ETL工具。

尽管技术已经发生了变化，但将数据虚拟化与数据湖、企业数据仓库以及所有ETL相结合的整个概念才是问题的根源。数据被移动到一个整体，需要每个人都等待，所有的更改都要精确协调，而不允许用例进行优化，也不允许选择最适合用例需求的适合用途的技术。

从数据湖操作用例

许多公司都把所有的希望都放在了大数据生态系统上，它将来自各种源系统的原始和非结构化数据汇集在一起，可能还附带了EDW。分析用例预计将在湖中运行，综合视图预计将在EDW中着陆。这种方法带来了许多挑战：

• 被拉入数据湖的数据通常是原始的，很可能是所有不同应用程序的复杂表示。它可以包括（一万）个表，不可理解的值和封装在数据中的应用程序逻辑。此外，由于继承的结构是相同的副本，因此与源系统之间存在紧密耦合。应用程序更改风险会立即破坏数据湖环境。
• 数据湖中的分析模型通常在原始（非结构化）和协调数据上进行训练。数据科学家在技术上通过手工或在他们的数据科学项目中筛选、创建数据并操作这些数据管道和模型，这并非不可想象。因此，数据湖具有巨大的风险。
• 在许多情况下，需要将分析结果带回EDW进行报告。这要求我们处理两种不同的数据模型：原始数据模型和统一、协调的EDW版本。由于这些结构完全不同，因此需要另一条管道来修复所有不一致之处。
• 数据湖通常是一个单一的平台，由许多不同的（其他）用例共享。由于其与硬件的紧密耦合、兼容性挑战、共享库和配置，这些平台很难维护。

我总结的挑战只是大数据项目失败率如此之高的几个原因。管理阻力、内部政治、缺乏专业知识以及安全和治理挑战是分析从未投入生产的其他一些原因。

知识隔离和集中设计

构建集中式数据平台（如EDW或数据湖）的最大问题之一是团队的组织方式：具有数据工程技能的人与具有领域和业务知识的人是分开的。在许多情况下，这些人也是产生和了解数据的人。

通过孤立所有的数据专业人员，创建了一个烟囱。所有的知识都是孤立的，不允许其他团队利用数据。数据生命周期和心跳必须进行调整，以满足中央规定的要求。一个团队拥有所有基础设施，而这些基础设施仅对该中心团队可用。一个团队必须改变一切，运行一切，维护一切，修复一切等等。正是这种炉灶阻碍了组织的规模扩大。

总结

数据仓库将继续存在，因为在特定环境下协调来自不同来源的数据的需求将始终存在。通过暂存数据进行解耦的模式不会消失。就像清理、修复和转换模式的步骤一样。根据用例的需要，任何风格的Inmon或Kimball都可以很好地应用。技术趋势，如元数据驱动的ELT、数据虚拟化、云、分布式处理、用于富集的机器学习，将改变数据仓库，但不会带来负面影响。

我们必须考虑管理数据的方式。像企业数据仓库这样的大筒仓将灭绝，因为它们无法扩展。紧密耦合的集成层、上下文丢失和密集的数据消耗将迫使公司寻找替代方案。数据湖架构是另一个极端，它引入了原始数据。原始的、被污染的数据随时可能改变，这将迫使实验和用例永远无法投入生产。Raw本身承载了大量可重复的工作。

此外，孤立和单一的思维也是一个问题，这不允许公司扩大规模。孤立的数据专业人员创建烟囱。与具有领域和业务知识的人员分离会导致协调问题。

所需要的是一个平衡且管理良好的数据管理环境，该环境允许通过使用多种技术进行变化。它必须为域提供洞察力和灵活性，以适应和分发数据，同时保持解耦。我在一系列文章中概述了现代趋势如何影响数据集成以及您需要什么类型的体系结构来实现可扩展性(https://medium.com/@piein/data-management-at-scale-91111a1a7d83）和《规模数据管理》一书第2版。

随着技术的进步，提供类似产品的公司之间的竞争日益激烈。在提供数据相关技术的公司中，这种竞争相对较高。当谈到数据库管理时，在Greenplum和Snowflake之间的选择相当棘手。

Greenplum数据库是一个基于PostgreSQL构建的大规模并行处理（MPP）SQL数据库。它可以毫无障碍地扩展到数PB的数据负担。它提供了对功能强大的服务器集群的访问，这些服务器将在一个SQL接口内协作，您可以在该接口中检查所有数据。Snowflake是一家数据仓库公司，提供跨云平台的统一访问和存储。它加强了其作为一项几乎不需要维护就能安全访问您的数据的服务的地位。

在这个博客中，你将通过了解5个关键的差异来探索Greenplum vs Snowflake。在探究差异之前，它还解释了Greenplum和Snowflake的基本原理。

目录

• Greenplum简介
• Snowflake简介
• 青梅与雪花的主要区别
• Greenplum vs Snowflake：功能
• Greenplum vs Snowflake：定价
• Greenplum vs Snowflake：安全
• Greenplum vs Snowflake：支持
• Greenplum vs Snowflake：支持集成
• 结论

Greenplum 简介

 

Greenplum数据库是一个大规模并行处理（MPP）数据库服务器，主要构建用于管理大规模分析数据仓库和商业智能工作负载的架构。

Greenplum基于PostgreSQL 8.3.23架构，本质上在一个Greenplum集群中同时使用多个PostgreSQL数据库实例。PostgreSQL用户将很快熟悉Greenplum，因为许多功能、设置和功能都是相同的，并且包含旨在最大限度地提高PostgreSQL在商业智能（BI）工作和工作负载中的工作效率的功能。

Greenplum还提供了PostgreSQL所没有的高级功能，如并行数据加载、资源管理、存储升级和复杂的查询优化。

Greenplum提供以下主要功能：

• 独立于云的灵活部署：Greenplum可以在流行的公共云市场上使用“自带许可证”和小时消费模式，包括亚马逊网络服务、微软Azure和谷歌云平台。它还可用于由VMware vSphere和OpenStack提供支持的私有云。最棒的是，所有云都使用相同的Greenplum版本和工具来获得一致的体验。
• 轻松处理流数据和云数据：Greenplum提供与Kafka生态系统的Confluent认证交互。Greenplum为流媒体使用场景提供了快速事件处理，同时增加了低延迟写入。能够在现场查询AmazonS3项目，从而实现更大的云数据集成。
• 从商业智能到人工智能的分析：从商业智能和人工智能的各种分析都可以在一个扩展的MPP数据库中获得，该数据库包括机器学习、深度学习、图形、文本和统计方法。对R和Python分析库以及Keras和Tensorflow的支持非常广泛。
• 最大限度地提高正常运行时间并保护数据完整性：Greenplum具有高可用性、智能故障检测、快速在线差异恢复以及完整和增量备份和灾难恢复的能力。通过安全和身份验证功能来满足企业策略和管理需求。

Greenplum的一些重要用例如下：

• 机器学习：Greenplum是机器学习的有效数据库，机器学习是对随着时间的推移自动改进的计算机系统的研究。ApacheMADLib是一个开源的、基于SQL的机器学习库，适用于Greenplum和PostgreSQL数据库。这种组合提高了Greenplum机器学习部署的并行性、可扩展性和预测准确性。MADlib还为机器学习提供了数据转换和特征工程工具，如描述性和推断统计学、数据透视、会话化和分类编码变量。
• 人工智能：Greenplum是一个优秀的数据库，适用于希望使用智能计算机模仿人类人才的应用程序。Greenplum能够快速获取大量数据，这使其成为需要基于无限多不同环境的智能交互的智能应用程序的宝贵工具。

 

Snowflake简介

Snowflake是一种基于云的数据仓库技术，为企业提供可扩展和灵活的存储系统。它非常适合存储商业智能系统随后可以搜索和检索的数据。尽管它完全是在云中创建和托管的，但它可以很好地与云和内部BI系统配合使用。

存储和计算资源可以使用基于订阅的策略单独获取。它还提供了弹性存储，同时使用热存储和冷存储策略来节省开支和可扩展计算，避免了其他数据仓库系统通常的并发限制。

Snowflake独特的体系结构将计算和存储原生地融合在一起。此体系结构使您的用户和数据工作负载能够在保持性能的同时虚拟地访问数据的单个副本。Snowflake将允许您在多个位置和云上执行数据解决方案，以提供一致的体验。Snowflake通过抽象云基础设施的潜在复杂性使其变得可行。

雪花具有以下主要功能：

• 更好的决策：Snowflake使您能够消除数据孤岛，并在整个业务中提供相关见解。这是改善合作伙伴关系、优化定价、降低运营费用、提高销售效率等方面必不可少的第一步。
• 改善用户体验：使用Snowflake，您可以更好地了解用户行为和产品使用情况。您还可以使用数据为客户提供成功，增加产品供应，并刺激数据科学创新。
• 强大的安全性：您可以使用安全的数据湖作为所有合规和网络安全数据的中央存储库。雪花数据湖提供快速的事件响应。通过将大量日志数据聚集在一个位置，并在几秒钟内评估多年的日志数据，您可以看到事件的全貌。半结构化日志和结构化公司数据现在可以组合在一个数据湖中。Snowflake可以让你在不索引的情况下进门，一旦数据出现，就可以更改数据。
• 更好的分析：通过从夜间批量加载过渡到实时数据流，Snowflake使您能够增强分析管道。通过允许在整个企业中安全、并发和受控地访问数据仓库，您可以提高业务分析的质量。这使企业能够优化资源配置，最大限度地提高收入，同时减少开支和人力劳动。

Snowflake的一些重要用例如下：

• 报告：数据仓库使您的团队能够更大规模、更快地执行更多的业务报告。将数据移动到云中可以更简单地重新排列信息，使其对业务用户更有价值和更容易理解。
• 分析：Snowflake允许您以任何规模执行数据分析，以获得您想要的见解。将其纳入更大的系统将为运营业务应用程序带来价值。

Greenplum 与Snowflake的主要区别

既然您已经对Greenplum和Snowflake有了扎实的了解，让我们来看看区分这些想法的基本特征。考虑将Greenplum与Snowflake区分开来的以下5个元素：

• Greenplum vs Snowflake：功能
• Greenplum vs Snowflake：定价
• Greenplum vs Snowflake：安全
• Greenplum vs Snowflake：支持
• Greenplum vs Snowflake：支持集成

1.Greenplum vs Snowflake：功能

Greenplum是一个基于PostgreSQL的开源数据库，用于管理大规模分析数据仓库和商业智能工作负载。Snowflake是一种商业许可的基于云的数据仓库解决方案，适用于半结构化和结构化数据。然而，Greenplum和Snowflake都符合ACID。Snowflake比Greenplum有优势，因为它能够通过虚拟数据仓库划分计算和存储。

2.Greenplum vs Snowflake：定价

Greenplum是一个开源数据库，社区版本可以免费下载和使用。相比之下，Snowflake的定价是基于存储的数据量和您使用的计算时间。您可以试用Snowflake 30天免费试用，稍后可以根据您的业务需求选择计划，如下所示：

 

3.Greenplum vs Snowflake：安全

Greenplum提供高可用性、智能故障检测、快速在线差异恢复以及完整和增量的备份和灾难恢复。通过安全和身份验证功能来满足企业策略和管理需求。相比之下，保存在Snowflake表中的所有导入数据都是经过AES-256强加密的。所有保存在内部阶段用于数据加载和卸载的文件都使用强大的AES-256加密进行自动保护。

4.Greenplum vs Snowflake：支持

在支持方面，Greenplum和Snowflake都有一个全天候可用的社区来帮助他们的客户。Greenplum在培训方面优于Snowflake，因为他们为用户提供免费视频教程。

5.Greenplum vs Snowflake：支持集成

Greenplum是一个开源数据库，提供来自25个来源的集成，包括Apache Superset、DataGrip、Preset等。相比之下，Snowflake允许来自200多个来源的数据集成，这是一个更好的选择。

结论

本博客深入比较了Greenplum和Snowflake，显示了两者之间的5个显著差异，即功能、定价、安全性、支持和支持的集成。在深入研究区别之前，它还介绍了这些工具的基本原理，例如它们的特性和用例。因此，本博客旨在帮助您根据个人需求就Greenplum与Snowflake的比赛做出明智的决定，同时牢记这五个关键差异。

Azure Synapse Analytics 是一项针对大型公司的无限信息分析服务，它被呈现为 Azure SQL 数据仓库 (SQL DW) 的演变，将业务数据存储和宏或大数据分析结合在一起。

在处理、管理和提供数据以满足即时商业智能和数据预测需求时，Synapse 为所有工作负载提供单一服务。后者通过与 Power BI 和 Azure 机器学习的集成而成为可能，因为 Synapse 能够使用 ONNX 格式集成数学机器学习模型。它提供了处理和查询大量信息的自由度.作为微软在西班牙为数不多的 Power BI 合作伙伴之一，在 Bismart，我们在使用 Power BI 和 Azure Synapse 方面拥有丰富的经验。

Azure Synapse 分析如何工作？

微软的服务是SaaS（软件即服务），可以按需使用，只在需要的时候运行（这对成本节约有影响）。它有四个组成部分：

• 具有完整基于 T-SQL 的分析的 SQL 分析：SQL 集群（按计算单位付费）和 SQL 按需（按处理的 TB 付费）。
• Apache Spark 完全集成。
• 具有多个数据源的连接器。

Azure Synapse 使用 Azure Data Lake Storage Gen2 作为数据仓库和包含管理、监视和元数​​据管理部分的一致数据模型。在安全领域，它允许您保护、监视和管理您的数据和分析解决方案，例如使用单点登录和 Azure Active Directory 集成。基本上，Azure Synapse 完成了整个数据集成和 ETL 过程，它不仅仅是一个普通的数据仓库，因为它包括该过程的进一步阶段，使用户还可以创建报告和可视化。

在编程语言支持方面，它提供了 SQL、Python、.NET、Java、Scala 和 R 等多种语言的选择。这使其非常适合不同的分析工作负载和不同的工程配置文件。

一切都包含在 Synapse Analytics Studio 中，可以轻松地将人工智能、机器学习、物联网、智能应用程序或商业智能集成到同一个统一平台中。

使用 T-SQL 和 Spark

关于执行时间，它允许两个引擎。一方面是传统的 SQL 引擎 (T-SQL)，另一方面是 Spark 引擎。通过这种方式，可以将 T-SQL 用于批处理、流式处理和交互式处理，或者在需要使用 Python、Scala、R 或 .NET 进行大数据处理时使用 Spark。

在这里，它直接链接到 Azure Databricks，这是一种基于 Apache Spark 的人工智能和宏数据分析服务，允许在交互式工作区中对共享项目进行自动可扩展性和协作。 Azure Synapse 在两种服务之间提供了一个高性能连接器，可实现快速数据传输。这意味着可以继续使用 Azure Databricks（Apache Spark 的优化）和专门用于提取、转换和加载 (ETL) 工作负载的数据架构，以大规模准备和塑造数据。反过来，Azure Synapse 和 Azure Databricks 可以对 Azure Data Lake Storage 中的相同数据运行分析。

Azure Synapse 和 Azure Databricks 为我们提供了更大的机会，可以将分析、商业智能和数据科学解决方案与服务之间的共享数据湖相结合。

在实现最大兼容性和功率的道路上

最初，Microsoft 服务是作为公司必须面对的两个基本问题的解决方案而提出的。首先是兼容性。它集成的数据分析系统能够同时处理传统系统和非结构化数据以及各种数据源。因此，它能够分析存储在系统中的数据，例如客户数据库（姓名和地址位于像电子表格一样排列的行和列中）以及存储在数据湖中的镶木地板格式的数据。

但它还在自动处理任务以构建用于分析数据的系统方面提供了更大的多功能性。这种增强的功能直接导致减少了程序员所需的工作量，并延长了项目开发时间（它是第一个也是唯一一个以 PB 级执行所有 TPC-H 查询的分析系统）。

Azure Synapse 实现了需要几个月的项目可以在几天内完成，或者需要几分钟或几小时的复杂数据库查询现在只需几秒钟。

毫秒内成功协商

除了单独扩展进程和存储资源之外，Azure Synapse Analytics 还因其结果缓存功能而脱颖而出（它具有完全托管的 1 TB 缓存）。因此，当进行查询时，它会存储在此缓存中，以加快使用相同类型数据的下一个查询。

这是它能够在毫秒内引发响应的关键之一。这是因为缓存在暂停、恢复和扩展操作（可以通过为云设计的大规模并行处理架构非常快速地激活）中幸存下来。

工作负载和性能

同样值得注意的是它对 JSON 的全面支持、数据屏蔽以确保高水平的安全性、对 SSDT（SQL Server 数据工具）的支持，尤其是工作负载管理以及如何对其进行优化和隔离。在这里，多个工作负载共享实现的资源。这使得创建工作负载并为其分配 CPU 数量和并发性成为可能。

例如，在拥有 1000 个 DWU（数据仓库单元）的情况下，Azure Synapse 有助于将工作的一部分分配给销售，另一部分分配给市场营销（例如 60% 分配给一个，40% 分配给另一个）。这个想法是为了便于管理和优先考虑数据库查询。

在数据准备和摄取方面，它支持以集成方式流式传输（Native SQL Streaming）以生成分析，例如与事件中心或物联网中心集成。它通过实现高达 200MB/秒的高性能、以秒为单位的交付延迟、随计算规模扩展的摄取性能以及使用基于 Microsoft SQL 的组合、聚合、过滤器查询的分析能力来实现这一目标……

一些附加功能

最后，我们必须强调 Azure Synapse Analytics 的其他有趣方面，这些方面有助于加快数据加载和促进流程。其中有：

• 对于数据准备和加载，复制命令不再需要外部表，因为它允许您将表直接加载到数据库中。
• 它提供对标准 CSV 的全面支持：换行符和自定义分隔符以及 SQL 日期。
• 提供用户控制的文件选择（通配符支持）
• 机器学习支持：可以以 ONNX 格式创建和保存机器学习模型，这些模型存储在 Azure Synapse 数据存储中并与本机 PREDICT 指令一起使用。
• 与 Data Lake 集成：来自 Azure Synapse，文件以 Parquet 格式在 Data Lake 中读取，从而实现了更高的性能，将 Polybase 执行提高了 13 倍以上。

简而言之，一种保证开发线的服务，以确保 SQL DW 客户可以继续在生产中运行现有的数据存储工作负载并自动受益于新功能。

原文：https://blog.bismart.com/en/azure-synapse-difference-from-azure-data-br…

本文：https://jiagoushi.pro/node/1771

什么是数据仓库？

数据仓库（DW）是从各种来源收集和管理数据的过程，以提供有意义的业务见解。数据仓库通常用于连接和分析来自异构源的业务数据。数据仓库是BI系统的核心，该系统是为数据分析和报告而构建的。

它融合了技术和组件，有助于数据的战略使用。它是企业对大量信息的电子存储，旨在进行查询和分析，而不是交易处理。这是一个将数据转换为信息并及时向用户提供信息以发挥作用的过程。

在本数据仓库（DWH）教程中，您将了解有关-

• 数据仓库的历史
• 数据仓库是如何工作的？
• 数据仓库（DWH）的类型
• 数据仓库的一般阶段
• 数据仓库组件
• 谁需要数据仓库？
• 数据仓库的用途是什么？
• 实施数据仓库的步骤
• 实施数据仓库的最佳实践
• 为什么我们需要数据仓库？优点和缺点
• 数据仓库的未来
• 数据仓库工具

决策支持数据库（数据仓库）与组织的运营数据库分开维护。然而，数据仓库不是一种产品，而是一种环境。它是一种信息系统的体系结构，为用户提供当前和历史决策支持信息，这些信息很难访问或出现在传统的操作数据存储中。

大家都知道，3NF为库存系统设计的数据库中有很多表是相互关联的。例如，关于当前库存信息的报告可以包括12个以上的联接条件。这样可以快速降低查询和报告的响应时间。数据仓库提供了一种新的设计，可以帮助减少响应时间，并有助于提高报告和分析查询的性能。

数据仓库系统也称为以下名称：

• 决策支持系统
• 高管信息系统
• 管理信息系统
• 商业智能解决方案
• 分析应用程序
• 数据仓库

数据仓库的历史

数据仓库有利于用户了解并提高其组织的性能。随着计算机系统变得越来越复杂，需要处理越来越多的信息，对数据仓库的需求也在不断发展。然而，数据仓库并不是一件新鲜事。

以下是数据仓库发展过程中的一些关键事件-

• 1960年的今天，达特茅斯和通用磨坊在一个联合研究项目中，开发了术语维度和事实。
• 1970年的今天，尼尔森和IRI为零售销售引入了维度数据集市。
• 1983年的今天，Tera Data Corporation推出了一个专门为决策支持而设计的数据库管理系统
• 数据仓库始于20世纪80年代末，当时IBM员工Paul Murphy和Barry Devlin开发了业务数据仓库。
• 然而，真正的概念是由伊蒙·比尔提出的。他被认为是数据仓库之父。他写过关于仓库和企业信息工厂的建设、使用和维护的各种主题。

数据仓库是如何工作的？

数据仓库作为一个中央存储库，其中信息来自一个或多个数据源。数据从事务系统和其他关系数据库流入数据仓库。

数据可能是：

• 结构化的
• 半结构化
• 非结构化数据

数据经过处理、转换和摄取，以便用户可以通过业务智能工具、SQL客户端和电子表格访问数据仓库中经过处理的数据。数据仓库将来自不同来源的信息合并到一个综合数据库中。

通过将所有这些信息合并在一个地方，组织可以更全面地分析其客户。这有助于确保它考虑了所有可用的信息。数据仓库使数据挖掘成为可能。数据挖掘正在寻找可能导致更高销售额和利润的数据模式。

数据仓库的类型

三种主要类型的数据仓库（DWH）是：

1.企业数据仓库（EDW）：

企业数据仓库（EDW）是一种集中式仓库。它为整个企业提供决策支持服务。它为组织和表示数据提供了一种统一的方法。它还提供了根据主题对数据进行分类的能力，并根据这些划分提供访问权限。

2.操作数据存储：

操作数据存储，也称为 ODS，只是当数据仓库和 OLTP 系统都不支持组织报告需求时所需的数据存储。 在ODS中，数据仓库是实时刷新的。 因此，它被广泛用于例行活动，例如存储员工的记录。

3.数据集市：

数据集市是数据仓库的一个子集。它是专门为特定业务线设计的，如销售、财务、销售或金融。在独立的数据集市中，数据可以直接从来源收集。

数据仓库的一般阶段

早些时候，组织开始相对简单地使用数据仓库。然而，随着时间的推移，数据仓库的使用开始变得更加复杂。

以下是数据仓库（DWH）使用的一般阶段：

脱机操作数据库(Offline Operational Database:)：

在这个阶段，数据只是从一个操作系统复制到另一个服务器。这样，复制数据的加载、处理和报告就不会影响操作系统的性能。

离线数据仓库(Offline Data Warehouse）：

数据仓库中的数据定期从操作数据库中更新。对数据仓库中的数据进行映射和转换，以满足数据仓库的目标。

实时数据仓库：

在此阶段，每当操作数据库中发生任何事务时，都会更新数据仓库。例如，航空公司或铁路订票系统。

集成数据仓库：

在这个阶段，当运营系统执行事务时，数据仓库会不断更新。数据仓库随后生成事务，这些事务被传递回运营系统。

数据仓库组件

数据仓库的四个组成部分是：

• 负载管理器：负载管理器也称为前端组件。它执行与数据提取和加载到仓库中相关的所有操作。这些操作包括转换，以准备数据进入数据仓库。
• 仓库管理员：仓库管理员执行与仓库中的数据管理相关的操作。它执行诸如分析数据以确保一致性、创建索引和视图、生成非规范化和聚合、转换和合并源数据以及归档和烘焙数据等操作。
• 查询管理器：查询管理器也称为后端组件。它执行与用户查询管理相关的所有操作。此数据仓库组件的操作是对适当表的直接查询，用于调度查询的执行。
• 最终用户访问工具：

这被分为五个不同的组，如1。数据报告2。查询工具3。应用程序开发工具4。EIS工具，5。OLAP工具和数据挖掘工具。

谁需要数据仓库？

所有类型的用户都需要DWH（数据仓库），如：

• 依赖大量数据的决策者
• 使用定制的复杂流程从多个数据源获取信息的用户。
• 它也被那些想要简单技术来访问数据的人使用
• 对于那些想要系统化决策方法的人来说，这也是至关重要的。
• 如果用户想要在大量数据上实现快速性能，而这些数据是报表、网格或图表所必需的，那么数据仓库证明是有用的。
• 如果您想发现数据流和分组的“隐藏模式”，数据仓库是第一步。

数据仓库的用途是什么？

以下是使用数据仓库的最常见行业：

航空公司：

在航空公司系统中，它用于机组人员分配、航线盈利能力分析、飞行常客计划促销等运营目的。

银行业务：

它在银行业被广泛用于有效管理桌面上的可用资源。很少有银行同时用于市场研究、产品业绩分析和运营。

医疗保健：

医疗保健部门还使用数据仓库制定战略和预测结果，生成患者的治疗报告，与配套保险公司、医疗援助服务等共享数据。

公共部门：

在公共部门，数据仓库用于收集情报。它帮助政府机构维护和分析每个人的税务记录、健康政策记录。

投资和保险行业：

在这个行业，仓库主要用于分析数据模式、客户趋势和跟踪市场动向。

零售链：

在零售链中，数据仓库被广泛用于分销和营销。它还有助于跟踪商品、客户购买模式、促销活动，也用于确定定价政策。

电信：

数据仓库用于该行业的产品促销、销售决策和分销决策。

酒店业：

该行业利用仓库服务，根据客户的反馈和旅行模式，设计和评估他们想要针对客户的广告和促销活动。

实施数据仓库的步骤

解决与数据仓库实现相关的业务风险的最佳方法是采用以下三个方面的策略

• 企业战略：在这里，我们确定了包括当前架构和工具在内的技术。我们还识别事实、维度和属性。还通过了数据映射和转换。
• 分阶段交付：数据仓库的实施应根据主题领域分阶段进行。应首先实现预订和计费等相关业务实体，然后相互集成。
• 迭代原型：数据仓库应该迭代开发和测试，而不是一种大爆炸的实现方法。

以下是数据仓库实现的关键步骤及其可交付成果。

Step	Tasks	Deliverables
1	Need to define project scope	Scope Definition
2	Need to determine business needs	Logical Data Model
3	Define Operational Datastore requirements	Operational Data Store Model
4	Acquire or develop Extraction tools	Extract tools and Software
5	Define Data Warehouse Data requirements	Transition Data Model
6	Document missing data	To Do Project List
7	Maps Operational Data Store to Data Warehouse	D/W Data Integration Map
8	Develop Data Warehouse Database design	D/W Database Design
9	Extract Data from Operational Data Store	Integrated D/W Data Extracts
10	Load Data Warehouse	Initial Data Load
11	Maintain Data Warehouse	On-going Data Access and Subsequent Loads

实施数据仓库的最佳实践

• 决定一个测试数据一致性、准确性和完整性的计划。
• 数据仓库必须具有良好的集成性、良好的定义和时间戳。
• 在设计数据仓库时，请确保使用正确的工具，坚持生命周期，注意数据冲突，并准备好吸取教训。
• 永远不要更换运营系统和报告
• 不要在提取、清理和加载数据上花费太多时间。
• 确保包括业务人员在内的所有利益相关者参与数据仓库的实施过程。确定数据仓库是一个联合/团队项目。您不希望创建对最终用户没有用处的数据仓库。
• 为最终用户制定培训计划。

为什么我们需要数据仓库？优点和缺点

数据仓库（DWH）的优势：

• 数据仓库允许业务用户在一个地方快速访问来自某些来源的关键数据。
• 数据仓库提供关于各种跨职能活动的一致信息。它还支持临时报告和查询。
• 数据仓库有助于集成许多数据源，以减轻生产系统的压力。
• 数据仓库有助于减少分析和报告的总周转时间。
• 重组和集成使用户更容易用于报告和分析。
• 数据仓库允许用户在一个地方访问来自多个来源的关键数据。因此，它节省了用户从多个来源检索数据的时间。
• 数据仓库存储了大量的历史数据。这有助于用户分析不同的时间段和趋势，以做出未来的预测。

数据仓库的缺点：

• 对于非结构化数据来说，这不是一个理想的选择。
• 数据仓库的创建和实现无疑是一件时间混乱的事情。
• 数据仓库可能会相对较快地过时
• 很难更改数据类型和范围、数据源架构、索引和查询。
• 数据仓库可能看起来很简单，但实际上，它对普通用户来说太复杂了。
• 尽管在项目管理方面尽了最大努力，但数据仓库项目的范围仍将不断扩大。
• 有时仓库用户会开发不同的业务规则。
• 组织需要花费大量资源进行培训和实施。

数据仓库的未来

• 监管约束的变化可能会限制组合不同数据源的能力。这些不同的源可能包括难以存储的非结构化数据。
• 随着数据库规模的增长，对什么构成一个非常大的数据库的估计也在继续增长。构建和运行数据仓库系统是很复杂的，这些系统的大小总是在增加。目前可用的硬件和软件资源不允许保持大量数据在线。
• 多媒体数据不能很容易地作为文本数据进行操作，而文本信息可以通过当今可用的关系软件来检索。这可能是一个研究课题。

数据仓库工具

市场上有许多数据仓库工具。下面是一些最突出的例子：

1.MarkLogic：

MarkLogic是一个有用的数据仓库解决方案，它使用一系列企业功能使数据集成更容易、更快。此工具有助于执行非常复杂的搜索操作。它可以查询不同类型的数据，如文档、关系和元数据。

https://www.marklogic.com/product/getting-started/

2.Oracle：

Oracle是业界领先的数据库。它为本地和云中提供了广泛的数据仓库解决方案选择。它有助于通过提高运营效率来优化客户体验。

https://www.oracle.com/index.html

3.AmazonRedshift：

AmazonRedshift是数据仓库工具。它是一种简单且经济高效的工具，可以使用标准SQL和现有的BI工具分析所有类型的数据。它还允许使用查询优化技术对PB的结构化数据运行复杂的查询。

https://aws.amazon.com/redshift/?nc2=h_m1

以下是有用的数据仓库工具的完整列表。

关键学习

• 数据仓库（DWH）也称为企业数据仓库（EDW）。
• 数据仓库被定义为一个中央存储库，其中的信息来自一个或多个数据源。
• 三种主要类型的数据仓库是企业数据仓库（EDW）、运营数据存储和数据集市。
• 数据仓库的一般状态是离线操作数据库、离线数据仓库、实时数据仓库和集成数据仓库。
• 数据仓库的四个主要组件是加载管理器、仓库管理器、查询管理器和最终用户访问工具
• 数据仓库用于航空、银行、医疗、保险、零售等不同行业。
• 实施Datawarehosue是一种三方面战略，即企业战略、分阶段交付和迭代原型。
• 数据仓库允许业务用户在一个地方快速访问来自某些来源的关键数据。

您可能喜欢：

• Qlikview Tutorial: What is QlikView? How to Install QlikView Tool
• MicroStrategy Tutorial: What is MSTR Reporting Tool?
• Power BI Tutorial: What is Power BI? Why Use? DAX Examples
• Database vs Data Warehouse – Difference Between Them
• 15 BEST ETL Tools in 2023

 

数据仓库（也称为企业数据仓库，或EDW）是一种将来自多个源的数据组合到中央一致数据存储中的系统。这种存储有助于数据挖掘、机器学习、人工智能（AI）和数据分析。与常规数据库不同，数据仓库系统使企业能够对大量历史数据进行高级分析。

30多年来，商业智能（BI）工具一直包括数据仓库系统，但近年来，新的数据类型和托管技术导致这些系统发生了变化。传统上，任何数据仓库的功能都集中在从外部源提取数据、清理和组织数据，以及将数据加载和存储在关系数据库中。这种托管通常是在本地进行的，通常是在大型计算机上进行的。数据仓库现在位于专用设备或云中，大多数数据仓库现在都包括用于数据可视化和表示的分析功能和工具。

数据仓库如何使用机器学习

目前的数据仓库越来越普遍，它从各种来源和设备收集大量数据，并将其存储在一个统一的平台上，用于简单的检索和分析。数据仓库在机器学习方面的用途很简单：应用于问题的数据越多，机器学习模型的性能就越好。机器学习模型根据存储在数据仓库中的数据进行预测并提出行动建议。

数据仓库和人工智能：它们的适用范围

数据仓库是存储和分析来自多个来源的公司数据的集中存储库，在历史上对商业智能至关重要。他们在数据成熟度曲线的每个阶段都帮助企业组织和理解大量数据。但由于人工智能，游戏现在已经发生了变化。除了作为传统数据管理需求的解决方案外，现代数据仓库已发展成为人工智能的催化剂。它所做的不仅仅是提供报告和仪表盘，或者只解决数据量和质量方面的问题。相反，它现在是利用人工智能突破帮助企业实现运营数字化转型的重要第一步。现代EDW（企业数据仓库）已经发展成为所谓的“洞察系统”，通过自动化数据输入和分析来闭合数据、洞察和行动之间的循环。

它旨在处理可能分布到几个人工智能工具的复杂问题，促进平滑的机器学习（ML）和更精确的预测。当前的数据仓库汇集了任何规模的所有企业数据，以提供可操作的见解，使企业能够更快地做出更好的决策。

数据仓库体系结构

数据仓库通常使用三层体系结构，它包括：

底层

属于数据仓库的服务器包括底层。底层通常是一个关系数据库系统，它使用提取、转换和加载（ETL）来收集、净化和转换来自不同数据源的数据。

中间层

在线分析处理，通常缩写为OLAP服务器，允许快速查询，构成了中间层。可以在该层中应用的三种不同的OLAP模型类型是MOLAP、ROLAP和HOLAP。这取决于所使用的数据库系统以及所使用的OLAP模型。

顶级

顶层由报告工具或前端用户界面表示，该界面允许最终用户对其公司数据执行即席分析。

了解OLAP和OLTP在数据仓库中的工作方式

OLAP软件用于以多维方式快速分析来自单个集中数据源（如数据仓库）的大量数据。在线事务处理，通常被称为OLTP，允许许多用户实时执行许多数据库事务，通常是通过互联网。每种技术的名称都区分了其主要功能：OLTP是事务性的，OLAP是分析性的。

包含历史数据和事务数据的数据仓库是用于多维数据分析的OLAP技术应用的地方。许多公司报告流程，如预算编制、财务分析、预测规划、数据挖掘、其他商业智能（BI）应用程序、复杂的分析计算和预测场景，都是OLAP的常见用途。

创建OLTP是为了通过可靠、快速地处理最近的事务来支持面向事务的应用程序。除了记录保存工具外，OLTP还经常用于ATM、信用卡支付处理、电子商务软件、在线预订和预订系统。

数据仓库架构（schemas）

数据仓库可以使用模式进行结构化。雪花模式和星形模式是主要的模式结构，它们将影响数据模型的设计方式。

星形模式

几个非规范化的维度表可以耦合到构成该模式的一个事实表。它被认为是最直接、最典型的模式，其用户受益于其更快的查询速度。

雪花架构

数据仓库中使用的另一种组织风格是雪花模式，虽然不太常见。在本例中，事实表链接到许多规格化的维度表，这些维度表具有子表。尽管雪花结构中最小级别的数据冗余对用户有利，但查询性能因此受到影响。

数据库与数据仓库

数据库不同于数据仓库；数据库是已保存信息的结构化集合，而数据仓库用于存储来自不同数据源的大量数据。

以下列出了在高级别上分离数据库和数据仓库的其他区别：

• 数据仓库是OLAP解决方案的理想选择，而数据库最好与OLTP解决方案一起使用。
• 成千上万的用户可以同时访问数据库。数据仓库可以处理的请求数量是有限的。
• 对于快速、离散的事务，数据库是最有帮助的。对于需要更深入分析的更强大的查询，数据仓库是最合适的解决方案。
• 停机时间很昂贵，因为数据库必须一年365天都可以访问。停机时间对数据仓库的影响较小。
• 对于CRUD（创建、读取、更新和删除）活动，数据库的设计速度非常快。数据仓库旨在处理来自许多大数据存储库的更少、更困难的查询。
• 由于没有信息在多个表中重复，数据库的组织尽可能有效。为了使读取活动优先于写入操作，数据仓库通常会取消其数据的规范化。
• 历史查询在数据库中是不可能的，因为它们通常只包含最新的数据。为了进行报告和分析，从头开始创建了数据仓库，保存历史数据。

数据仓库类型

云数据仓库

客户可以购买被称为云数据仓库的托管服务，这是一种专门为在云中操作而设计的数据仓库。在过去的五到七年里，随着越来越多的企业采用云服务并试图缩小其内部数据中心的占地面积，基于云的数据仓库变得越来越普遍。

由于云数据仓库的实际基础设施由云提供商管理，因此客户无需支付购买硬件和软件的前期成本以及管理和维护数据仓库系统的负担。

数据仓库软件（许可证/内部部署）

公司可以获得数据仓库的许可证，然后在其内部设备上建立数据仓库。政府机构、金融机构和其他需要遵守数据隐私或严格安全标准或规则的公司可能会发现，这是一个更好的选择，即使与基于云的数据仓库服务相比，成本往往更高。

数据仓库设备

公司可以将数据仓库设备连接到其网络，并立即开始使用它。数据仓库设备是一组预先集成的硬件和软件，包括CPU、存储器、操作系统和数据仓库应用程序。就初始成本、部署速度、可扩展性的简单性和管理控制而言，数据仓库设备介于云系统和内部部署系统之间。

数据仓库的优势

数据仓库具有以下优势：

提高了数据质量

事务系统、平面文件、操作数据库和其他数据源都集中在数据仓库中。然后，它净化、消除重复，并将其系统化，以产生一个单一的真相库。

更快的业务洞察力

来自太多不同来源的数据阻碍了决策者自信地定义公司战略的能力。数据仓库使数据集成成为可能，使业务用户能够在每个业务决策中包含公司的所有数据。

做出更明智的选择

数据仓库实现了大规模的商业智能（BI）服务，包括数据挖掘（识别数据之间的隐藏关系）、人工智能（AI）以及机器学习（ML）——商业领袖和数据专业人士可以使用这些工具来获得具体证据，以便在组织的任何方面做出更好的决策。

增加和建立竞争优势

上述因素共同作用，有助于组织比其他数据存储库更快地发现数据中的更多可能性，从而产生竞争优势。

结论

从各种来源获得的数据在数据仓库中遵循行业开发的标准（如格式化程序）。这保证了所有数据都是准确的，没有可能影响分析的重复或错误。数据仓库提供了许多额外的好处，可以用来最终帮助公司提高利润。

这篇文章是我和我的同事戴凯共同撰写的。我们都是腾讯音乐（NYSE:TME）的数据平台工程师，腾讯音乐是一家音乐流媒体服务提供商，月活跃用户高达8亿。把这个数字放在这里并不是为了吹嘘，而是为了暗示我和我可怜的同事每天都要处理的海量数据。

我们使用ClickHouse的目的

腾讯音乐的音乐库包含各种形式和类型的数据：录音音乐、现场音乐、音频、视频等。作为数据平台工程师，我们的工作是从数据中提取信息，在此基础上，我们的队友可以做出更好的决策，支持我们的用户和音乐合作伙伴。

具体而言，我们对歌曲、歌词、旋律、专辑和艺术家进行全方位分析，将所有这些信息转化为数据资产，并将其传递给我们的内部数据用户，以进行库存盘点、用户分析、指标分析和群体定位。

我们将大部分数据存储和处理在腾讯数据仓库（TDW）中，这是一个离线数据平台，我们将数据放入各种标签和度量系统中，然后创建以每个对象（歌曲、艺术家等）为中心的平面表。

然后，我们将平面表导入ClickHouse进行分析，并将Elasticsearch导入数据搜索和组定位。

之后，我们的数据分析师使用他们需要的标签和指标下的数据来形成不同使用场景的数据集，在此期间，他们可以创建自己的标签和标准。

数据处理管道如下所示：

ClickHouse的问题

在使用上述管道时，我们遇到了一些困难：

 

• 部分更新：不支持对列进行部分更新。因此，任何一个数据源的任何延迟都可能延迟平面表的创建，从而破坏数据的及时性。
• 高存储成本：不同标签和指标下的数据以不同的频率更新。尽管ClickHouse在处理平表方面表现出色，但将所有数据倒入平表并按天进行分区是对存储资源的巨大浪费，更不用说随之而来的维护成本了。
• 高维护成本：从架构上讲，ClickHouse的特点是存储节点和计算节点的强耦合。其组成部分相互依存程度很高，增加了集群不稳定的风险。此外，对于ClickHouse和Elasticsearch之间的联合查询，我们必须处理大量的连接问题。那太乏味了。

过渡到Apache Doris

Apache Doris是一个实时分析数据库，它拥有一些功能，正是我们解决问题所需要的：

 

• 部分更新：Doris支持多种数据模型，其中Aggregate Model支持列的实时部分更新。在此基础上，我们可以直接将原始数据摄取到Doris中，并在那里创建平面表。摄取过程如下：首先，我们使用Spark将数据加载到Kafka中；然后，任何增量数据都将通过Flink更新到Doris和Elasticsearch。同时，Flink将对数据进行预聚合，以减轻Doris和Elasticsearch的负担。
• 存储成本：Doris支持跨Hive、Iceberg、Hudi、MySQL和Elasticsearch的多表联接查询和联合查询。这使我们能够将大的平面表拆分为小的平面表，并根据更新频率对其进行分区。这样做的好处包括减轻存储负担和提高查询吞吐量。
• 维护成本：Doris架构简单，兼容MySQL协议。部署Doris只涉及两个过程（FE和BE），不依赖于其他系统，因此易于操作和维护。此外，Doris支持查询外部ES数据表。它可以很容易地与ES中的元数据接口，并自动映射ES中的表模式，这样我们就可以通过Doris对Elasticsearch数据进行查询，而无需处理复杂的连接。

此外，Doris支持多种数据接收方法，包括从HDFS和S3等远程存储批量导入，从MySQL binlog和Kafka读取数据，以及从MySQL、Oracle和PostgreSQL实时同步或批量导入数据。它通过一致性协议确保服务可用性和数据可靠性，并能够自动调试。这对我们的操作员和维护人员来说是个好消息。

从统计数据来看，这些功能使我们的存储成本降低了42%，开发成本降低了40%。

在我们使用Doris的过程中，我们得到了开源Apache Doris社区的大量支持，以及SelectDB团队的及时帮助，该团队目前正在运行Apache Doris的商业版本。

进一步改进以满足我们的需求

引入语义层

说到数据集，从好的方面来看，我们的数据分析师可以自由地重新定义和组合标签和指标。但在黑暗的一面，标签和度量系统的高度异质性导致了它们的使用和管理更加困难。

我们的解决方案是在数据处理管道中引入语义层。语义层是将所有技术术语翻译成我们内部数据用户更容易理解的概念的地方。换句话说，我们正在将标签和指标转变为数据定义和管理的一流公民。

为什么这会有帮助？

对于数据分析师来说，所有标签和度量都将在语义层创建和共享，这样就可以减少混乱，提高效率。

对于数据用户来说，他们不再需要创建自己的数据集或确定哪一个数据集适用于每个场景，而是可以简单地对指定的标签集和度量集进行查询。

升级语义层

仅仅在语义层明确定义标记和度量是不够的。为了建立一个标准化的数据处理系统，我们的下一个目标是确保在整个数据处理管道中标签和度量的定义一致。

为此，我们将语义层作为数据管理系统的核心：

它是如何工作的？

TDW中的所有计算逻辑将以单个标签或度量的形式在语义层定义。

语义层接收来自应用程序端的逻辑查询，相应地选择引擎，并生成SQL。然后，它将SQL命令发送到TDW以供执行。同时，它也可能向Doris发送配置和数据接收任务，并决定应该加速哪些度量和标签。

通过这种方式，我们使标签和度量更加易于管理。美中不足的是，由于每个标记和度量都是单独定义的，我们正在努力为查询自动生成有效的SQL语句。如果你对此有任何想法，欢迎你与我们交谈。

充分发挥Apache Doris的作用

正如您所看到的，ApacheDoris在我们的解决方案中发挥了关键作用。优化Doris的使用可以在很大程度上提高我们的整体数据处理效率。因此，在这一部分中，我们将与您分享我们如何使用Doris来加速数据接收和查询，并降低成本。

我们想要什么？

目前，我们有800多个标签和1300多个度量，它们来自TDW中的80多个源表。将数据从TDW导入Doris时，我们希望实现：

 

• 实时可用性：除了传统的T+1离线数据接收外，我们还需要实时标记。
• 部分更新：每个源表通过其自己的ETL任务以不同的速度生成数据，并且只涉及部分标记和度量，因此我们需要支持列的部分更新。
• 高性能：在群体定位、分析和报告场景中，我们只需要几秒钟的响应时间。
• 低成本：我们希望尽可能降低成本。

我们做什么？

1.用Flink而不是TDW生成平面表

在TDW中生成平面表有几个缺点：

• 高存储成本：除了离散的80多个源表之外，TDW还必须维护一个额外的平面表。这是巨大的冗余。
• 实时性低：源表中的任何延迟都将被增加并延迟整个数据链路。
• 开发成本高：要实现真正的及时性，需要额外的开发努力和资源。

相反，用多丽丝制作平板桌子要容易得多，也要便宜得多。过程如下：

 

• 使用Spark以离线方式将新数据导入Kafka。
• 使用Flink消费Kafka数据。
• 通过主键ID创建一个平面表。
• 将平面桌子导入Doris。如下所示，Flink将其中“ID”=1的五行数据聚合为Doris中的一行，从而减轻了Doris的数据写入压力。

这可以在很大程度上降低存储成本，因为TDW不再需要维护两个数据副本，并且KafKa只需要存储等待接收的新数据。更重要的是，我们可以将我们想要的任何ETL逻辑添加到Flink中，并将大量开发逻辑用于离线和实时数据接收。

2.明智地命名列

正如我们提到的，Doris的聚合模型允许对列进行部分更新。在这里，我们简单介绍了Doris中的其他数据模型，供您参考：

 

• 唯一模型：适用于需要主键唯一性的场景。它只保留相同主键ID的最新数据。（据我们所知，Apache Doris社区也计划在Unique Model中包含列的部分更新。）
• 重复模型：此模型完全按原样存储所有原始数据，无需任何预聚合或重复数据消除。

在确定了数据模型之后，我们必须考虑如何命名列。不能选择使用标记或度量作为列名，因为：

 

1. 一我们的内部数据用户可能需要重命名度量或标记，但Doris 1.1.3不支持修改列名。
2. 二标签可能会经常在线和离线获取。如果这涉及到添加和删除列，那么这不仅耗时，而且对查询性能也不利。相反，我们会执行以下操作：
3. 为了灵活地重命名标签和度量，我们使用MySQL表来存储元数据（名称、全局唯一ID、状态等）。名称的任何更改都只会发生在元数据中，但不会影响Doris中的表模式。例如，如果一个song_name的ID为4，那么它将以Doris中的列名a4存储。然后，如果查询中涉及到song_name，那么它将在SQL中转换为a4。

对于标签的上线和下线，我们根据标签的使用频率对标签进行分类。使用最少的将在其元数据中给予离线标记。脱机标签下不会有新数据，但这些标签下的现有数据仍然可用。

为了实时获得新添加的标签和度量，我们在Doris表中基于名称ID的映射预构建了一些ID列。这些保留的ID列将被分配给新添加的标签和度量。因此，我们可以避免表模式的更改和随之而来的开销。我们的经验表明，添加标签和指标后仅10分钟，其下的数据就可以使用。

值得注意的是，最近发布的Doris 1.2.0支持Light Schema Change，这意味着要添加或删除列，只需要修改FE中的元数据。此外，只要为数据表启用了“Light Schema Change”，就可以重命名数据表中的列。这对我们来说是个大麻烦。

3.优化日期写入

以下是一些实践，这些实践将我们的每日离线数据摄入时间减少了75%，CUMU压缩得分从600+降低到100。

 

• Flink预聚合：如上所述。
• 写入批量的自动调整：为了减少Flink资源的使用，我们允许将一个Kafka Topic中的数据写入各种Doris表，并实现基于数据量的批量大小自动更改。
• Doris数据写入的优化：微调平板电脑和水桶的尺寸以及每个场景的压实参数：

max_XXXX_compaction_thread
max_cumulative_compaction_num_singleton_deltas

• BE提交逻辑优化：定期缓存BE列表，逐批提交到BE节点，使用更精细的负载均衡粒度。

4.在查询中使用Dori on ES

我们大约60%的数据查询涉及群体定位。群组定位是通过使用一组标签作为过滤器来查找我们的目标数据。它对我们的数据处理架构提出了一些要求：

 

• 与APP用户相关的群体定位可能涉及非常复杂的逻辑。这意味着系统必须同时支持数百个标签作为过滤器。
• 大多数群体定位场景只需要最新的标签数据。但是，度量查询需要支持历史数据。
• 数据用户可能需要在确定组目标后对度量数据进行进一步的汇总分析。
• 在确定组目标后，数据用户可能还需要对标签和度量进行详细查询。

经过考虑，我们决定在ES上采用Doris。Doris是我们将每个场景的度量数据存储为分区表的地方，而Elasticsearch存储所有标记数据。Doris on ES解决方案结合了Doris的分布式查询规划能力和Elasticsearch的全文搜索能力。查询模式如下：

SELECT tag, agg(metric) 
   FROM Doris 
   WHERE id in (select id from Es where tagFilter)
   GROUP BY tag

如图所示，Elasticsearch中的ID数据将用于Doris中的子查询，用于度量分析。在实践中，我们发现查询响应时间与目标组的大小有关。如果目标组包含超过一百万个对象，则查询将耗时60秒。如果它更大，可能会发生超时错误。经过调查，我们确定了两个最大的时间浪费者：

 

• 当Doris BE从Elasticsearch中提取数据（默认情况下一次1024行）时，对于超过一百万个对象的目标组，网络I/O开销可能是巨大的。

 

• 数据提取后，Doris BE需要通过SHUFFREE/BROADCAST对本地度量表进行Join操作，这可能会花费大量成本。

因此，我们进行了以下优化：

 

• 添加一个查询会话变量es_optimize，用于指定是否启用优化。
• 在向ES写入数据时，在对主键ID进行散列后，添加一个BK列来存储存储桶编号。该算法与Doris（CRC32）中的bucketing算法相同。
• 使用Doris BE生成Bucket Join执行计划，将Bucket编号发送到BE ScanNode并将其下推到ES。
• 使用ES压缩查询到的数据；将多个数据提取转换为一个数据提取，并减少网络I/O开销。
• 确保Doris BE只提取与本地度量表相关的bucket的数据，并直接进行本地Join操作，以避免Doris BE之间的数据混洗。

因此，我们将大型群定位的查询响应时间从60秒减少到了令人惊讶的3.7秒。社区信息显示，Doris将从即将发布的2.0.0版本开始支持反向索引。有了这个新版本，我们将能够对文本类型进行全文搜索，对文本、数字和日期时间进行等价或范围过滤，并在过滤中方便地组合and、or、NOT逻辑，因为反向索引支持数组类型。Doris的这一新功能预计在同一任务上的性能将比Elasticsearch高3~5倍。

5.完善数据管理

Doris的冷热数据分离能力为我们的数据处理成本降低策略奠定了基础。

 

• 基于Doris的TTL机制，我们只将当年的数据存储在Doris中，并将之前的历史数据放在TDW中，以降低存储成本。
• 我们会为不同的数据分区更改拷贝数。例如，我们为最近三个月的数据设置了三个副本，这是经常使用的，一个副本用于六个月以上的数据，两个副本用于其间的数据。

Doris支持将热数据转换为冷数据，因此我们只将过去七天的数据存储在SSD中，并将较旧的数据传输到HDD，以获得更便宜的存储。

结论

感谢您一直滚动到这里并完成这篇长篇阅读。在我们从ClickHouse过渡到Doris的过程中，我们分享了我们的欢呼和泪水、经验教训，以及一些可能对您有价值的实践。我们非常感谢Apache Doris社区和SelectDB团队的帮助，但由于我们试图实现冷数据和热数据的自动识别、常用标签/度量的预计算、使用物化视图简化代码逻辑等等，我们可能仍在追逐他们一段时间。

数据仓库是一种关系数据库管理系统（RDBMS）结构，以满足事务处理系统的要求。它可以松散地描述为任何可以查询业务利益的集中式数据存储库。它是一个存储信息的数据库，以满足决策要求。它是一组决策支持技术，旨在使知识工作者（高管、经理和分析师）能够做出卓越和更高的决策。因此，数据仓库支持架构和工具，使业务主管能够系统地组织、理解和使用他们的信息来做出战略决策。

数据仓库环境包含一个提取、传输和加载（ETL）解决方案、一个在线分析处理（OLAP）引擎、客户分析工具以及其他处理收集信息并将其传递给业务用户的过程的应用程序。

什么是数据仓库？

数据仓库（DW）是一种关系数据库，它是为查询和分析而不是事务处理而设计的。它包括从单个和多个来源的交易数据派生的历史数据。

数据仓库提供集成的、企业范围的历史数据，并专注于为决策者提供数据建模和分析支持。

数据仓库是一组特定于整个组织的数据，而不仅仅是特定于特定用户组的数据。

它不用于日常操作和事务处理，而是用于决策。

数据仓库可以被视为具有以下属性的数据系统：

• 它是一个专为调查任务设计的数据库，使用来自各种应用程序的数据。
• 它支持数量相对较少、交互时间相对较长的客户端。
• 它包括当前和历史数据，以提供信息的历史视角。
• 它的使用是阅读密集型的。
• 里面有几张表。
• “数据仓库是一种面向主题的、集成的、时变的信息存储，用于支持管理层的决策。”

数据仓库的特点

以主题为导向

数据仓库的目标是为决策者建模和分析数据。因此，数据仓库通常围绕特定主题（如客户、产品或销售）提供简洁明了的视图，而不是全球组织的持续运营。这是通过排除与受试者无关的数据，并包括用户理解受试者所需的所有数据来实现的。

集成的

数据仓库集成了各种异构数据源，如RDBMS、平面文件和在线事务记录。它需要在数据仓库期间执行数据清理和集成，以确保不同数据源之间的命名约定、属性类型等的一致性。

时间变量

历史信息保存在数据仓库中。例如，可以从数据仓库中检索3个月、6个月、12个月甚至以前的数据中的文件。事务系统的这些变体，通常只保存最新的文件。

稳定的（Non-Volatile）

数据仓库是一个物理上独立的数据存储，它是从源操作RDBMS转换而来的。数据仓库中不会发生数据的操作更新，即不执行更新、插入和删除操作。数据访问通常只需要两个过程：数据的初始加载和数据访问。因此，DW不需要事务处理、恢复和并发能力，这可以大大加快数据检索的速度。非易失性定义了一旦进入仓库，数据就不应更改。

数据仓库的历史

数据仓库的想法出现在20世纪80年代末，当时IBM研究人员Barry Devlin和Paul Murphy建立了“商业数据仓库”

从本质上讲，数据仓库的想法是为了支持从操作系统到决策支持环境的信息流的体系结构模型。该概念试图解决与流程相关的各种问题，主要是与流程相关联的高成本。

在缺乏数据仓库体系结构的情况下，需要大量的空间来支持多个决策支持环境。在大公司中，各种决策支持环境独立运行是很常见的。

数据仓库的目标

• 帮助报告和分析
• 维护组织的历史信息
• 成为决策的基础。

对数据仓库的需求

需要数据仓库的原因如下：

1. 业务用户：业务用户需要一个数据仓库来查看过去的汇总数据。由于这些人是非技术性的，数据可能以基本的形式呈现给他们。
2. 存储历史数据：需要数据仓库来存储过去的时间变量数据。该输入用于各种目的。
3. 做出战略决策：有些策略可能取决于数据仓库中的数据。因此，数据仓库有助于做出战略决策。
4. 对于数据一致性和质量：将来自不同来源的数据集中在一起，用户可以有效地保证数据的一致性和一致性。
5. 高响应时间：数据仓库必须为一些意外的负载和查询类型做好准备，这需要很大程度的灵活性和快速响应时间。

数据仓库的好处

1. 了解业务趋势并做出更好的预测决策。
2. 数据仓库被设计成能够很好地执行大量数据。
3. 最终用户更容易访问数据仓库的结构以进行导航、理解和查询。
4. 在许多规范化数据库中复杂的查询可以更容易地在数据仓库中构建和维护。
5. 数据仓库是管理大量用户对大量信息需求的有效方法。
6. 数据仓库提供了分析大量历史数据的能力。

先决条件

在学习数据仓库之前，您必须具备基本数据库概念的基础知识，如模式、ER模型、结构化查询语言等。

观众

本教程将帮助计算机科学学生理解与数据仓库相关的基本到高级概念。

问题

我们保证您不会发现此数据仓库教程有任何问题。但如果有任何错误，请将问题张贴在联系表格中。

 

数据已成为企业的命脉。为了理解和利用所有这些数据，数据仓库已经成为现代商业的重要组成部分。今天，我们在比较Redshift和Snowflake时继续讨论现代数据仓库，以及集成数据仓库时的一些核心考虑事项。

Snowflake和Redshift：基础

两者都是功能强大的关系型DBMS数据库模型，并且都提供了一些在管理数据方面非常有趣的选项。Redshift作为一个支持云的大规模数据仓库服务提供给我们，可与商业智能工具一起使用。同样，Snowflake为结构化和半结构化数据提供基于云的数据仓库服务。

为了开始区分两者，Amazon Redshift是一个在云中完全管理的、PB级的数据仓库服务。这里最酷的一点是，您可以从几百GB的数据开始，并随着需求的增长扩展到一PB或更多。

Snowflake Computing销售一种基于云的数据存储和分析服务，称为Snowflake 弹性数据仓库。有了这个解决方案，企业用户可以使用基于云的硬件和软件来存储和分析数据。从那里开始，数据存储在Amazon S3中。Snowflake实际上利用了公共云生态系统，而不是像Hadoop这样的技术。

如前所述，这两种解决方案都非常强大，在管理数据方面都提供了一些独特的功能。但是，肯定有区别。有了这个，我们就进去吧。

生态系统与整合

如果你在亚马逊生态系统工作，Redshift 应该在你的列表上。Redshift集成了多种AWS服务，如kinisis Data Firehose、SageMaker、EMR、Glue、DynamoDB、Athena、数据库迁移服务（DMS）、模式转换工具（SCT）、CloudWatch等。

另一方面，你绝对可以在AWS市场上找到具有非常酷的按需的Snowflake。然而，Snowflake没有等效的集成，这使得客户在尝试将其数据仓库与数据湖架构集成时，更难使用诸如Kinisis、Glue、Athena等工具。不过，Snowflake还提供了其他一些有趣的集成点，包括IBM Cognos、Informatica、Power BI、Qlik、Apache Spark、Tableau和其他一些集成点。

这两种选择都提供了广泛的集成，并拥有健康的生态系统合作伙伴。随着Redshift的建立，你会有一点点的腿，但雪花已经来了很长的路。

如果您希望简化数据仓库，Panoply提供了一个智能云数据仓库，其中包含100多个预先构建的数据集成。除此之外，Panoply还通过机器学习优化自动接收并提高查询性能。

考虑到这一点，让我们看看运行这一切需要多少成本。

价格：Redshift Vs Snowflake

在很高的层次上，我们研究了Redshift和Snowflake的定价模型，发现Redshift在按需定价方面通常比Snowflake便宜。此外，与标准的按需收费相比，使用1年和3年保留实例（RI）定价的客户可以获得额外的节省。

也就是说，需要注意的是，像BigQuery、Redshift、Snowflake和Panoply这样的主要数据仓库参与者都有不同的定价模型。许多数据仓库提供按需定价和批量折扣。Redshift和Snowflake提供30%到70%的预付费折扣。

每个节点每小时的Redshift费用，包括计算能力和数据存储。使用Redshift，您可以通过将每小时的价格乘以集群的大小和一个月的小时数来计算每月价格。

Redshift月价格=[每小时价格]x[集群大小]x[每月小时数]

Snowflake为每个虚拟仓库按小时粒度定价，这在很大程度上取决于您的使用模式。由于数据存储与计算仓库分离，因此它是单独计费的。举个例子，以美国为参照，Snowflake的存储成本可以从每月23美元/TB（平均压缩量）开始，每天累积。计算成本为0.00056美元/秒，每学分，他们的Snowflake On Demand Standard Edition。在这一点上，这会让人有点困惑。Snowflake提供了七层不同的计算仓库。最小的集群，X-Small，每小时一个学分，或者每小时2美元。在每个级别上，每小时的学分数加倍。Snowflake提供了一个动态定价模型——当没有查询运行时集群将停止，当查询运行时集群将自动恢复，并且它们可以根据不断变化的工作负载灵活地调整自己的大小。当查询负载减少时，这可能会节省您的钱。

在成本方面，当将Amazon Redshift的2、4和8节点DC2.8XL群集与同等大小的中、大和X大Snowflake配置进行比较时，Redshift比Snowflake On Demand Standard Edition便宜1.3倍。当客户购买一个1年或3年的保留实例（RI）时，Redshift的价格比Snowflake便宜1.9倍和3.7倍。

使用Panoply，您可以根据所需的存储、数据源和支持级别，获得可预测的透明定价。所有计划包括无限的查询和访问实时聊天支持。

安全：Redshift Vs Snowflake

当涉及到数据时，安全是一个重要的基础。我们从新来源创建的所有这些数据都为私有和敏感信息打开了新的漏洞。今天需要安全的数据量和实际安全的数据量之间存在着巨大的差距，而且这种差距将会扩大——这是我们数据驱动世界的现实。

正如IDC指出的，到2025年，全球数据圈中创建的所有数据中，几乎90%都需要某种程度的安全性，但只有不到一半的数据是安全的。

Redshift和Snowflake都非常重视安全。Amazon Redshift 数据库安全不同于其他类型的AmazonRedshift 安全。除了数据库安全之外，Amazon Redshift还提供以下功能来管理安全性：

1. 登录凭据-访问您的Amazon Redshift管理控制台由您的AWS帐户权限控制。
2. 访问管理-要控制对特定Amazon Redshift资源的访问，可以定义AWS标识和访问管理（IAM）帐户。
3. 群集安全组-要授予其他用户对Amazon Redshift群集的入站访问权限，可以定义群集安全组并将其与群集关联。
4. VPC-要使用虚拟网络环境保护对集群的访问，可以在Amazon虚拟私有云（VPC）中启动集群。
5. 群集加密-要加密所有用户创建的表中的数据，可以在启动群集时启用群集加密。
6. SSL连接-要加密SQL客户端和群集之间的连接，可以使用安全套接字层（SSL）加密。
7. 加载数据加密-要加密表，请在将数据文件上载到Amazon S3时加载数据文件，可以使用服务器端加密或客户端加密。当您从服务器端加载加密数据时，Amazon S3会透明地处理解密。从客户端加载加密数据时，Amazon Redshift COPY命令在加载表时解密数据。
8. 传输中的数据-为了保护您在AWS云中传输的数据，Amazon Redshift使用硬件加速的SSL与Amazon S3或Amazon DynamoDB进行复制、卸载、备份和恢复操作。

另一个需要考虑的关键方面是遵从性。Redshift合规认证的完整列表可以在这里找到。

类似地，Snowflake提供业界领先的功能，确保您的帐户和用户以及存储在Snowflake中的所有数据的最高安全级别。

以下是按类别分组的功能的高级摘要：

• 网络/站点访问-通过IP白名单和黑名单控制的站点访问，通过网络策略管理。Snowflake与其他VPC之间通过AWS PrivateLink进行私人/直接通信。
• 帐户/用户身份验证-MFA（多因素身份验证），用于增强用户访问帐户的安全性。通过联合身份验证支持用户SSO（单点登录）。
• 对象安全-通过DAC（自主访问控制）和RBAC（基于角色的访问控制）的混合模型对帐户中的所有对象（用户、仓库、数据库、表等）进行控制访问。
• 数据安全-所有数据自动加密（使用AES 256强加密）。存储在阶段（用于数据加载/卸载）中的所有文件都会自动加密（使用AES 128标准或256强加密）。加密数据的周期性重新加密。支持使用客户管理的密钥加密数据。
• 安全验证-符合Soc 2 II类。支持HIPAA法规遵从性。PCI DSS合规性。

在处理安全问题时，我唯一要注意的是确保您知道使用的是哪一个Snowflake版本。并非所有这些安全功能在每个版本中都可用。例如，如果要利用安全验证功能并使用HIPAA或PCI DSS，则需要使用Snowflake的企业版敏感数据（ESD）。

数据仓库决策

无论何时处理数据，您的目标都是尽快获得结果。记住，数据是推动业务发展的引擎。一个好的数据仓库平台，简单的设置和操作，将大大提高您的业务竞争力。理想情况下，您总是希望寻找提供自动资源调配、自动备份和容错的平台。从那时起，像Panoply这样的解决方案通过透明定价和24/7聊天支持，自动化和优化数据管理生命周期，为您提供帮助。

在选择合适的平台时，花点时间做适当的研究。如前所述，如果您真的担心法规遵从性，那么您可能会在Redshift上获得更多的操作选项。从那里，知道你需要融入什么。也就是说，您是在利用其他云服务，还是在尝试与数据可视化技术合作？进行试验或PoC是一个很好的开始和测试的方法。另外，它将帮助您了解集成点以及如何管理整个平台。

他们的关键是真正开始。我们今天讨论的内容围绕功能强大的数据仓库系统展开，这些系统是专门为快速、可扩展和帮助您的业务而设计的。从提出正确的问题开始，进行一些研究，并与合作伙伴合作，帮助您导航数据旅程。

讨论：请加入知识星球【首席架构师圈】

数据仓库是一个单一的数据存储库，其中来自多个数据源的记录被集成用于在线业务分析处理（OLAP）。这意味着数据仓库需要满足整个组织内所有业务阶段的需求。因此，数据仓库的设计是一个非常复杂、漫长的过程，因此容易出错。此外，业务分析功能会随着时间的推移而变化，这会导致系统需求的变化。因此，数据仓库和OLAP系统是动态的，设计过程是连续的。

数据仓库的设计采用了一种不同于行业中视图物化的方法。它将数据仓库视为具有特定需求的数据库系统，例如回答与管理相关的查询。设计的目标是如何提取、转换和加载来自多个数据源的记录（ETL），以将其组织在数据库中作为数据仓库。

有两种方法

• “自上而下”的方法
• “自下而上”的方法

自上而下的设计方法

在“自上而下”的设计方法中，数据仓库被描述为一个面向主题、时变、非易失性和集成的数据存储库，用于整个企业。来自不同来源的数据被验证、重新格式化并保存在标准化（最高3NF）数据库中作为数据仓库。数据仓库存储“原子”信息，即最低粒度级别的数据，从中可以通过选择特定业务主题或特定部门所需的数据来构建维度数据集市。方法是一种数据驱动的方法，因为首先收集和集成信息，然后制定构建数据集市的主体的业务需求。这种方法的优点是它支持单个集成数据源。因此，由它构建的数据集市在重叠时将具有一致性。

自上而下设计的优点

• 数据集市是从数据仓库中加载的。
• 从数据仓库开发新的数据集市非常容易。

自上而下设计的缺点

• 这种技术对于不断变化的部门需求是不灵活的。
• 实施该项目的成本很高。

自下而上的设计方法

在“自下而上”的方法中，数据仓库被描述为“用于查询和分析的事务数据特定架构的副本”，术语为星形模式。在这种方法中，首先创建一个数据集市，以便为特定的业务流程（或主题）提供必要的报告和分析功能。因此，与Inmon的数据驱动方法相比，它需要是一种业务驱动的方法。

数据集市包括最低粒度的数据，如果需要，还包括聚合数据。非规范化维度数据库取代了数据仓库的规范化数据库，以满足数据仓库的数据交付要求。使用这种方法，要使用数据集市集作为企业数据仓库，数据集市的构建应考虑到一致的维度，定义普通对象在不同的数据集市中表示相同。一致的维度将数据集市连接起来，形成一个数据仓库，通常称为虚拟数据仓库。

“自下而上”设计方法的优点是它具有快速的ROI，因为开发一个数据集市，一个针对单个主题的数据仓库，比开发一个企业范围的数据仓库花费的时间和精力要少得多。此外，失败的风险甚至更小。这种方法本质上是渐进的。这种方法可以让项目团队学习和成长。

自下而上设计的优点

• 可以快速生成文档。
• 数据仓库可以扩展以适应新的业务单元。
• 它只是开发新的数据集市，然后与其他数据集市集成。

自下而上设计的缺点

• 在自下而上的方法设计中，数据仓库和数据集市的位置是颠倒的。

区分自上而下的设计方法和自下而上的设计方法

自上而下的设计方法	自下而上的设计方法
将大问题分解为更小的子问题。	解决了基本的低级问题，并将它们集成到更高的问题中。
固有的架构，而不是几个数据集市的联合。	内在递增的；可以首先调度重要的数据集市。
内容信息的单一中央存储。	存储的部门信息。
集中的规则和控制。	部门规则和控制。
它包括冗余信息。	可以删除冗余。
如果重复实施，可能会很快看到效果。	失败风险更小，投资回报率高，技术证明。

 

Data Vault从其第一版“1.0”作为一种数据建模规范发展到了更精细的“2.0”版本。Data Vault 2.0超越了建模规范，还涵盖了企业数据体系结构和创建和维护体系结构的标准方法（人员、流程和平台）。

作为官方管理机构，Data Vault Alliance提供了对其内容的全面了解：

Data Vault 2.0是一个完整的商业智能系统，它建立在建模规范、体系结构模式和敏捷交付方法论的基础支柱上。该方法还谈到了实施规则、最佳实践和标准。

总体目标是创建和扩展一个可审计、可扩展、可跟踪、一致的企业数据仓库，该仓库足够灵活，可以支持频繁的业务更改，而不会导致重大的级联变化。

本文主要关注Data Vault 2.0作为一种数据建模技术，并提供了与传统关系（3NF）建模的简单比较。

比较

首先，所有建模技术都以实体及其关系的形式表示真实世界。

*不同之处在于，有关这些实体及其关系的数据的组织、拆分和存储方式，以实现一致性、准确性、速度、可扩展性等实际目标。他们能够根据这些质量的优先级做出组织决策。

让我们并排来看一下DV2和3NF建模，以了解这一点。

3NF是将业务的ER图表示（实体、属性、关系）本质上转换为关系对象（表或视图）的基础规范。

实体构成了整个模型的大部分关系对象，每个实体的每个实例都有明确的标识符（业务键）。如果这些实体是一对一或一对多类型的，则这些实体之间的相互关系作为外键（参与实体的标识符）嵌入其中。多对多关系得到各自的表，参与实体各自贡献外键。通过这种方式，关系信息与企业实体信息位于同一位置，使模型成为一个非常紧密的家族。

另一方面，DV2建模技术采用了实体和关系概念的不同应用风格，始终将实体及其关系表示为单独的关系对象*每个孩子都有自己的房间！

在其术语中，实体成为HUB，每个实例的业务密钥都有明确的标识，存储在各自的表/视图中。

它们的关系成为默认情况下被视为多对多的链接，因此存储为另一组表/视图。他们的数据没有嵌入HUB中。

卫星

实体或关系的属性由卫星捕获，卫星只负责保存这些描述性数据。HUB或LINK可能有一个或多个卫星，这取决于在其使用寿命内需要如何维护这些描述性数据。

由于这种明确的组织，HUB和LINK只负责存储有关其自身的身份和可追溯性信息，而将详细信息留给其卫星管理。

HUB和LINK仍然通过散列键连接，但在各自捕获的内容上有明确的职责分工（如上所述），因此可以独立发展。

相反，在3NF方法中，信息分布在关系对象之间，这些关系对象彼此紧密耦合，并且具有非常一致的结构（应用了约束）。总体而言，它有助于实现保持数据一致性、准确性和最新性的主要目标。由于这个原因，3NF非常适合捕获事务性信息，在任何给定时间只需要维护最新的数据副本。

然而，不利的一面是，面对业务方式的频繁变化，3NF也会使整个系统变得脆弱。

另一方面，DV2稍微放松了关系对象之间的耦合，从而通过将它们定位到需要更新的特定区域（HUB、LINK或SATELLITE）来更容易地吸收更改。此外，扩展这样的分布式模型，以包括较新的实体或改变实体之间的现有关系，成为添加（而不是中断）的任务，其中较新的HUB/LINKs/SATELLITE被构造为对这种变化进行建模，然后连接到现有网络。

DV2的设计目标优先考虑灵活性、可扩展性、可追溯性和一致性，通过这样组织数据可以很好地满足这些要求。

此外，DV2是专门为存储大量历史信息（而不仅仅是当前信息）的仓库建模而构建的，这些信息能够在下游进行挖掘和分析。

那么，外卖是什么呢？

从比较来看，3NF似乎是一种非常古老的技术，在今天几乎没有什么相关性，但这将是一种谬论，因为它仍然是一种基本的数据捕获方式，可以在最细粒度的层面上实现清晰的同一性和一致性。DV2对象本身在单个级别上进行规范化，以满足这些需求。

Additional Resources

Digging into Data Governance and Data Modeling

Testing and validation are where data governance begins to play a massively important role. If you’ve documented where…

medium.com

SqlDBM: No Code Data Modeling for Cloud Data Warehouses with Anna Abramova

Hashmap On Tap, Ep. 79

medium.com

Why You Should Use Snowflake’s External Tables

A practical example showcasing the value of Snowflake’s external tables for building a Data Lake

medium.com

让我们一起做数据和云！

在Hashmap，一家NTT数据公司，我们与客户合作，共同打造更好的产品。我们正与各行各业的公司合作，以解决最严峻的数据挑战——我们可以帮助您缩短实现价值的时间！

作为我们服务的一部分，我们提供一系列启用研讨会和评估服务、数据现代化和迁移服务，以及设计和构建新数据产品的咨询服务包。我们很乐意满足您的具体要求。在这里与我们联系。

 

数据建模是任何稳健数据体系结构的基石。但是，当谈到选择正确的方法时，感觉就像站在十字路口。Kimball、Inmon和Data Vault是三种流行的方法，每种方法都有其独特的优势。

让我们试着了解它们之间的区别

1.Kimball建模——构建数据集市

金博尔就像是把一块拼图拼得恰到好处。它专注于创建数据集市，数据集市是数据仓库的子集。每个数据集市都服务于特定的业务领域，使其灵活且量身定制。

用例示例--销售数据：想象一下你为一家零售巨头工作。使用Kimball，您可以为销售、库存和客户数据构建单独的数据集市。这使您的销售团队能够快速访问和分析他们的数据，而无需担心并将时间浪费在不必要的信息上。

这是一种更传统的方法，可以很好地满足特定团队的运营需求。

2.Inmon建模——一种集中式方法

另一方面，Inmon就像建造一座宏伟的图书馆。它将数据集中到一个庞大的数据仓库中，确保了真相的单一版本。当您的组织需要一致性和整体观点时，这种方法非常理想。

用例示例——财务分析：在金融机构中，Inmon建模将把与账户、交易和客户档案相关的所有数据合并到一个仓库中。这种统一的数据源有助于财务团队确保法规遵从性，并全面分析财务健康状况。

3.数据仓库建模——敏捷性和可扩展性

Data Vault类似于建造模块化摩天大楼。它是为灵活性和可扩展性而设计的。数据以原始形式存储，因此可以轻松添加新的来源并适应不断变化的业务需求。

用例示例——医疗保健分析：在医疗保健组织中，患者数据可以来自各种来源，如医院、诊所和可穿戴设备。Data Vault使您能够快速集成这些不同的数据源，并在此基础上构建分析，确保及时深入了解，以获得更好的患者护理。

那么，你如何选择呢？

• 当您需要快速访问特定业务部门的定制数据时，Kimball会大放异彩。
• Inmon是需要单一真相来源和强大数据治理的组织的选择。
• Data Vault在灵活性和可扩展性至关重要的场景中表现出色，非常适合快速发展的行业。

请记住，没有一刀切的解决方案。您的选择取决于组织的独特需求和目标。有时，结合这些方法的优势的混合方法可能是最佳的前进道路。

 

在本文中，我们将讨论 Microsoft 的 Azure Synapse Analytics 框架。 具体来说，我们关注如何在其中看到数据仓库和数据湖范式的区别。

为了熟悉这个主题，我建议你先阅读本系列的前几篇文章。

• 数据湖和仓库第 1 部分：范式简介
• 数据湖和仓库第 2 部分：Databricks 和Showflake
• 数据湖和仓库第 3 部分：Azure Synapse 观点

我们现在考虑一个更新颖的解决方案，该解决方案与该主题的角度略有不同。 也就是说，我们将讨论 Microsoft Azure Synapse Analytics 环境。 事实上，这篇文章的动机是“我们应该采用 Snowflake、Databricks 还是 Synapse？”这一行中的问题数量。 看完这篇文章，我希望你明白为什么这个问题很难回答。

 

Azure Synapse 在同一个保护伞下收集多个产品

在之前的文章中，我们注意到数据分析平台可以分为几个阶段。在上图中，绿色表示处理，蓝色表示存储工具。我们可以看到 Azure Synapse 环境如何涵盖处理和存储。对于其他提到的产品，请查看以前的帖子。

确切地说，Synapse 不是一个单一的产品，而是一个提供一组工具作为组件的框架。这样一来，我们就有了多个云数据产品，一个品牌和一个界面，涵盖了云大数据分析平台的所有阶段。此外，Synapse 环境为数据仓库构建和数据湖开发提供了工具。

现在，第一个问题是我们是否在再次为多种工具品牌化方面获得了任何好处。为什么我们不单独使用这些工具？就个人而言，我开始认为 Synapse 伞产品是有意义的。我们稍后会回到这个问题。首先让我们从 Azure Synapse 环境的概述开始

Azure Synapse 组件

让我们简要介绍一下我所理解的 Azure Synapse Analytics 环境。 Azure Synapse Analytics 平台可以描述为具有以下组件：

• 图形 ELT/ETL 工具，名为 Pipelines，用于数据摄取和处理。实际上，该组件与旧的 Azure 数据工厂服务(Azure Data Factory service) 相同。
• 用于数据结构化的专用 SQL 池数据仓库(Dedicated SQL pool data warehouse )。与此相关的是，微软在推出 Synapse 时犯了一个错误。最初，引入此组件以涵盖所有 Synapse 环境。我仍然误认为 Synapse 只是数据仓库的新名称。
• 基于编程语言的 Apache Spark 池(Apache Spark pool )和无服务器 SQL 池(Serverless SQL pool )，用于云中的数据查询和处理。这些组件是新颖的，仅在 Synapse 环境中可用。

除此之外，环境在组件之间提供以下功能：

• 一个集中的图形工作区用户界面，可以访问所有工具
• 光可视化(Light visualization)功能和与 Power BI 报告的集成
• 可在所有工具中使用的通用数据湖表模式存储库
• 与 Azure Data Lake Storage Gen2 云存储服务和 Azure AD 权限管理的自然连接

据我所知，类似的整体框架是独一无二的，尚未由任何其他云提供商提供。

那么，分析(Synapse Analytics)的新功能是什么？

一些工具，尤其是数据工厂( Data Factory) 和数据仓库，在 Synapse 环境之前就已经可用。因此，它们并没有真正带来新的价值。在没有完整框架的情况下单独使用组件可能非常有意义。

但是，例如，无服务器 SQL 池是 Azure 大数据产品中的一项很棒的新功能。它是一种可作为服务使用的 SQL 查询工具：您无需构建任何基础架构。它立即可用，您按使用量付费。最好的比较点是 AWS 云环境 Athena 服务。此外，Apache Spark 池是一种工具，可以简称为 Databricks 的轻量级版本。

结论——工具包装有帮助

总而言之，我们是否通过 Synapse 框架有所收获？我必须承认我最初对此持怀疑态度。但是，在获得一些经验之后，我个人的回答是肯定的，至少在某种程度上是肯定的。首先，组件之间存在真正的集成。例如，可以定义可从多个工具访问的通用关系数据库类型表。

另一方面，将单个工作区用作图形用户界面是有益的。通常，在构建新的分析平台时，您需要对云大数据组件有相当广泛的了解。使用 Synapse，它们可以很容易地作为一个包提供。这既有助于新开发人员开始工作，也可能有助于处理整体解决方案的安全性。因此，我想说 Synapse 框架对微软来说是一项相当成功的投资，至少从技术角度来看是这样。

当我们回到本系列第一篇文章中介绍的数据仓库和数据湖范式区别时，会出现一个有趣的细节。从费用的角度来看，这两种范式可以在 Synapse 环境组件中看到。除 Synapse 专用 SQL 池数据仓库外，所有处理组件均按数据湖范例的典型使用量付费。所有工具甚至都有自动关机功能。因此，如果您尝试使用 Synapse 环境，请记住关闭数据仓库以阻止其收取费用。其他组件会自行处理。

Azure Synapse 环境非常独特，因为所有相关的大数据湖和数据仓库工具都集中在同一个包中。即使您可以单独使用其中的一些，将它们组合起来也有其优势。

原文：https://www.tietoevry.com/en/blog/2021/10/data-lakes-and-warehouses-azu…

本文：https://jiagoushi.pro/node/1764

数据分析平台正在转向云环境，例如亚马逊网络服务、微软 Azure 和谷歌云。

云环境提供了多种好处，例如可扩展性、可用性和可靠性。此外，云提供商有大量的原生组件可供构建。还有多种第三方工具可供选择，其中一些是专门为云设计的，可通过云市场获得。

工具自然倾向于强调自己在分析集成中的作用。当您尝试选择最佳工具集时，这通常会令人困惑。在这篇文章中，我们将详细介绍许多工具的优缺点。

这是一个由三部分组成的系列文章的第一篇，我们评估了基于数据仓库和数据湖的解决方案的基本方法或范式的差异。

博客系列

 

• 数据湖和仓库第 1 部分：范式简介
• 数据湖和仓库第 2 部分：Databricks 和雪花
• 数据湖和仓库第 3 部分：Azure Synapse 观点

两种范式：数据湖与数据仓库

基于一些主要组件的选择，云分析解决方案可以分为两类：数据湖和数据仓库。简而言之，数据仓库解决方案传统上是集中式的，而数据湖解决方案则分散到核心。这两种方法都有其优势，并且通常用于略有不同的目的。如今，产品具有这两个类别的典型特征是很常见的。即便如此，产品仍然展示其原始类别及其观点。

让我们将这种基本类别方法称为范式。理解范式的基本哲学有助于理解全局。

在这篇文章中，我们深入挖掘了范式的特征和差异。我们首先将分析平台划分为典型的组件阶段。在此之后，我们讨论从两种范式的角度选择组件的方法。

在本系列的下一篇文章中，我们将讨论如何在一些流行的产品中看到范式。

数据分析平台通常根据它们所涵盖的过程部分分为多个阶段。典型的批量数据流水线平台如上图所示。但是，文章分析也适用于实时平台。这些工具可以从处理（绿色）或存储（蓝色）的角度进行分类。下面的工具行对应于它们在平台不同阶段的可用性。

例如，典型的数据湖解决方案由单独的处理和存储工具组成。在数据仓库的情况下，一个单一的解决方案通常同时兼顾处理和存储功能。让我们更清楚一点。

从处理（绿色）的角度来看，数据平台阶段是：

• 摄取 （Ingest ）- 使用 API 接口或 ELT/ETL 工具从源系统读取数据
• 准备（Prepare）——数据将进行初步清理和检查
• 转换和丰富（Transform & Enrich）——根据用例丰富和修改数据
• 服务 （Serve）- 准备好的数据提供给选择的工具以供实际使用
• 可视化和报告（Visualize & Report ）——信息以可视化或报告的形式提供给最终用户

此外，大数据世界的当前趋势是根据应用的处理级别将数据存储在多个层中。数据存储层（蓝色）通常至少包括：

• 原始（也称为青铜）——未处理的源数据，按原样存储
• 精炼（银）——经过初步清理和标准化的质量验证数据。数据通常尚未修剪。
• 已发布（金）——经过处理、组合和丰富的数据。通常，数据也已针对特定用例进行聚合和修剪。

数据存储层的确切覆盖范围因源而异，但此处的细节无关紧要。但是，重要的是要注意，尤其是在银层和金层中，数据可以存储不止一次。例如，黄金层通常为不同的使用场景提供多个版本的数据。

比较数据分析平台

传统上，数据分析平台是用于公司报告目的的解决方案。对于这个用例，基于关系数据库的数据仓库是事实上的标准。但是，数据仓库不太适合处理新类型的数据，通常称为大数据。问题是由于数据量、实时要求和类型多样性造成的，其中包括非结构化和半结构化数据。为了补充工具集，在过去十年左右开发了数据湖类型的解决方案。

根据 Wikipedia 中的一个非常广泛的定义，数据湖是一种可以以原始形式存储数据的解决方案。一般来说，这意味着任何文件格式的潜在存储容量都是无限的。在实践中，该术语还涵盖处理存储数据的工具。

市场上倾向于将产品展示为“整体数据湖解决方案”。通常他们是对的：理论上，即使是具有大硬盘驱动器的虚拟机也能让有能力的编码人员创建数据湖解决方案。自然，这种极简主义的定义不是很有用。

相反，考虑范式的差异更有意义：数据仓库的基本原则和基于数据湖的解决方案。

数据仓库：以有组织的结构提供的已清理数据

对于数据仓库范式，基本方法是提供一个集中式产品，使数据能够存储在有组织的层次结构中，通常以数据库表的形式。该解决方案包括表之间的外键引用、细粒度数据加密和详细的用户访问管理等内容。对数据的访问主要通过特定的数据仓库产品处理，通常使用 SQL 语言。

数据仓库范式的优点是能够定义向用户提供的数据和格式。通常，数据以经过处理和干净的格式提供。例如，这样我们就可以保证数据的有效性。此外，源系统和数据的变化至少在某种程度上对用户是隐藏的。

另一方面，作为限制，我们依赖单一的产品供应商。例如，只能以产品支持的方式从数据仓库解决方案中检索数据。此外，我们需要以一种或另一种方式为数据的检索付费。数据仓库解决方案也可能成为数据处理的资源瓶颈。最近，在解决后一个限制方面取得了重大进展。

数据湖：去中心化带来的自由

数据湖范式的核心原则是责任分散。借助大量工具，任何人都可以在访问管理的范围内使用任何数据层中的数据：青铜、白银和黄金。组织数据和表的关系是可以的，但是通常不强制使用，我们可以很容易地绕过它们。

数据湖解决方案的一个主要优势是计算和处理工具的去中心化。数据科学家可以在自己的机器上使用青铜层数据进行 Python 图像分析，数据工程师可以使用 Apache Spark 修改银层数据，分析师可以通过报告工具利用黄金层数据。 SQL 语言通常作为一种可能性提供。此外，计算是分散的，几乎没有瓶颈。

数据湖范式解决方案的一个主要弱点是缺乏数据组织，包括集中的元数据存储库。如果由于纠错或源系统修改而导致处理的数据更改，则可能非常难以跟踪。此外，不能始终保证数据的有效性或结构。集中式数据湖元数据管理工具越来越多，但使用它们取决于开发过程。技术很少强制这样做。

结论：数据湖和数据仓库

在这篇文章中，我们讨论了数据仓库和基于数据湖的解决方案的基本方法或范式的差异。基于数据仓库的解决方案通常是集中式的，而数据湖解决方案则分散到核心。然而，这两个类别的工具都在发展，并且划分变得越来越不清晰。然而，理解范式方法有助于理解全局。

原则上，您可以纯粹在数据湖或基于数据仓库的解决方案上构建云数据分析平台。

我见过大量基于数据湖工具的功能齐全的平台。在这些情况下，可以使用特定于用例的数据库数据集市来提供信息，而根本不需要数据仓库。

另一方面，也有成功的解决方案，其中整个平台都建立在数据仓库产品之上。数据直接读入数据仓库，在那里进行处理和服务。

但是，由于此处解释的差异，基于其中一种范例的解决方案不一定在所有情况下都是最佳的。他们的优势和基本理念是不同的。在处理青铜级和白银级数据时，在早期阶段利用基于数据湖的方法可能是有意义的。然后可以将数据存储在数据仓库中，以进一步组织成白银和黄金数据。通过这种方式，所有数据既可以用于快速实验的原始格式，也可以用于报告的结构格式。

这样，我们可以利用这两种方法的优势。

原文：https://www.tietoevry.com/en/blog/2021/08/data-lakes-and-warehouses-int…

本文：https://jiagoushi.pro/node/1766