企业数据仓库概念、架构和组件
1
文章翻译自：
https://www.altexsoft.com/blog/enterprise-data-warehouse-concepts/（20191024）
我们每天都依靠历史经验做许多决策。大脑存储了关于我们以往经历的大量数据（即我们的记忆），当我们面对决策时都在利用这些数据。跟人类一样，企业生产并收集历史数据可以帮助它们更好的做出决策。
大脑同时负责存储和处理，而对于企业来说，则需要更多的工具来应对数据。数据仓库则是最重要的工具之一。
在这篇文章里，我们将讨论什么是企业数据仓库、它的类型和功能、以及如何在数据处理过程中使用它。我们将明确企业数据仓库和普通数据库的不同之处、数据仓库的不同类型以及它们如何工作。文章重点在于提供一些关于通过不同架构、概念、方法构建数据仓库的商业价值。
2
什么是企业数据仓库
如果你知道 TB 有多大，你可能对奈非（Netflix）的数据仓库在 2016 年拥有 44 TB 数据印象深刻。单看数据大小就暗示了我们为什么称它数据仓库而非数据库。所以，让我们从基础开始。
企业数据仓库（Enterprise Data Warehouse，EDW）是存储和管理企业所有历史业务数据的企业资料库。数据通常来自于 ERP（Enterprise Resource Planning，企业资源管理系统）、CRM（Customer RelationShip Management，客户关系管理系统），物理记录或其他平面文件等。为未来的分析准备数据，它必须存放在单一的存储设备中。这样，不同的业务部门可以从不同角度查询和分析数据信息。
借助数据仓库，企业可以管理庞大的数据集，而不再需要管理多个数据库。为 BI（Business Intelligence，商业智能） 存储数据是一种面向未来的方式，BI 是一种将原始数据转换成可行见解的技术、方法。EDW 是 BI 系统中重要的一部分，它类似于人类存储信息的大脑。
2.1
企业数据仓库与常规数据仓库的不同
任何数据仓库都是通过数据集成工具连接一端的原始数据和另一端的分析接口的数据库。既然如此，我们为什么避开企业形式来讨论？任何仓库都提供转换数据、移动数据并将其呈现给终端用户的机制。企业数据仓库与常规数据仓库的区别在于其广泛的体系结构多样性和功能性。由于复杂的架构和巨大的数据规模，企业数据仓库通常会再分解为多个较小的数据库，而终端用户更容易查询这些更小的数据库。考虑到这一点，我们将专注于涵盖所有功能的企业数据仓库上。然而，仓库的大小并不决定它的技术复杂性，而是由分析需求、报告能力，数据模型数量和数据本身决定。因此，要理解什么使得常规数据仓库变成企业数据仓库，让我们深入了解它的核心概念和功能。
2.2
企业数据仓库概念和功能
通常，根据数据仓库的基本概念和功能，定义如下几种技术特性：
最终的存储，EDW 是企业内已经发生过的业务数据的统一存储库。
反应原始数据，EDW 的数据资源来自原始数据存储空间，例如谷歌分析（Google Analytics）、CRM、IoT 设备等，如果它们分散在多个系统中就会难于管理。因此，EDW 的目的是在单个存储库中提供类似原始数据库的数据。由于公司内外部总会产生新的相关数据，所以数据流在进入数据仓库之前需要专用的基础架构进行管理。
存储结构化数据，数据在 EDW 中总是按标准化、结构化存储，这使得终端用户可以通过 BI 界面和报表进行查看，这也是它与数据湖的不同之处。数据湖通常存储用于分析为目的的非结构化数据。不同于数据仓库，数据湖更多的被数据工程师、科学家处理大量的原始数据。
面向主题的数据，EDW 主要关注点是不同域的相关业务数据。为了理解数据与什么相关，它总是围绕特定主体构建数据模型。例如主题可以是「指定商品的销售区域、销售额等」。此外，添加元数据来详细说明每份数据的来源。
时间相关，EDW 收集的数据通常是历史数据，因为它们反应历史事件。为了了解某一趋势的发生和持续的时间，大多数数据按时间周期分段存储。
相对稳定，数据一旦放入数据仓库，就永远不会被抹除。数据可以更加源头的变化被操作、修改或删除，但不意味着可以被抹去，至少终端用户不可以。当我们谈到历史数据时，删除操作对于分析来说是适得其反的。然而，为了删除不相关的数据，一般的修订可能在几年内发生一次。
考虑到这些基本原则，我们将研究企业数据仓库的实现类型。
3
企业数据仓库类型
考虑到企业数据仓库的功能，如何设计比较专业总会有一定的讨论空间。在数据存储和处理方面，不同种类的业务有不同的特性和区别，考虑范围包括数据量的大小、分析的复杂度、安全问题甚至预算。当然，如何构建你的系统总有一个选项。
3.1
传统企业数据仓库
拥有专用软硬件的统一存储被认为是 EDW 的传统形式。通过物理存储，你不需要设置多个数据库之间的数据集成工具。相反，EDW 可以通过 API 与数据源连接并在此过程中进行转换。因此，所有工作要么在传输区域（数据加载到 DW 之前）完成，要么在数据仓库中完成。传统数据仓库因为没有额外的抽象层，被认为比虚拟数据仓库（下节讨论）更加优秀。它简化是数据工程师的工作，让它很容易在预处理端管理数据流，更好的实现报告。传统数据仓库的缺点取决于实际的实现，对于大多数业务来说的缺点如下：
昂贵的软硬件技术基础设施
雇佣数据工程师、开发运营专家建设和维护整个数据平台
适用场景：适用于想处理和使用数据的各种规模的企业。传统数据仓库可以演变为不同架构风格的数据平台，以更好的根据目标实现调整。
3.2
虚拟数据仓库
虚拟数据仓库是一类可以替代传统数据仓库的 EDW，本质上，它是虚拟连接的多个数据库，但可以作为单个系统进行查询。
这种方案允许组织保持简单：数据保存在原始数据库中，但它仍然可以在分析工具的帮助下提取。如果你不想破坏所有的底层基础设施，或者你拥有的数据易于管理，可以使用虚拟数据仓库。但是，这种方法有许多缺陷：
多个数据库要求持续的软硬件维护成本
存储在虚拟数据仓库的数据仍然要求转换软件能易于终端用户和报表工具理解
复杂数据查询可能花费太多时间，因为请求的数据可能分布在两个单独的数据库中
适用场景：适用于不需要复杂分析并且原始数据是标准化格式的业务，也适用想使用但尚未使用 BI 系统的企业。
3.3
云数据仓库
近十年来，云/无云 科技已经变成了建立企业级技术的标准，你会发现市面上有无数的供应商提供仓库即服务（warehousing-as-a-service）。这里列举一些：
Amazon Redshift
IBM Db2
Google BigQuery
Snowflake
Microsoft SQL Data Warehouse
以上所有供应商都提供完整的管理、可伸缩的数据仓库，并将其作为 BI 工具的一部分，也有像 Snowflake 一样单独提供 EDW 作为独立的服务。在这种情况下，云仓库架构与其他云服务具有一样的优点，服务提供商为你维护基础设施意味着你不需要配置装配自己的服务器、数据库和其他工具并且管理它们。这种服务的价格取决于所需的内存量和查询所需的计算能力。在云数据仓库中你唯一可能关心的是数据安全性。你的业务数据是敏感的，所以你需要核查你选择的供应商是否可信以避免违约。这并不意味着企业自建仓库更安全，但这种情况下，你的数据安全掌握在自己手中。
适用场景：对任何规模的企业来说，云平台都是很好的选择。它会帮你准备好你要的一切，包括数据集成管理、数据仓库运维和 BI 支持。
4
企业数据仓库架构
许多架构方法以这样或那样的方式扩展数据仓库的能力，我们讲集中讨论最本质的问题，在不考虑过多技术细节的情况下，整个数据管道可以被划分为三层：
原始数据层（数据源）
数据仓库及其生态系统
用户界面（分析工具）
数据提取、转换以及装载到数据仓库是一个单独的工具类别，称作 ETL 。另外，在 ETL 的框架下，数据集成工具在数据放入数据仓库前对其执行转换操作，这些工具运行在原始数据层与数据仓库之间。当数据被装载到数据仓库之后，仍然可能被转换。因此，数据仓库要有某些功能来对数据进行清洗、标准化、维度化，这些因素将决定架构复杂度。我们将从企业需求不断增长的立场来考虑 EDW 架构。
4.1
单层架构
鉴于数据集成配置合理，我们可以选择数据仓库。在大多数情况下，数据仓库是一个关系型数据库，包含了允许多维数据的模块，或者分为多个易于访问的主题信息域。在最原始形式中，数据仓库只有一层架构。
单层架构的 EDW 意味着数据仓库与分析接口直接连接，终端用户可以直接查询。在 EDW 与分析工具之间直接连接带来了几个挑战：
传统上，数据仓库的存储从 100GB 起，直接连接可能导致杂乱的查询结果以及低处理速度
从数据仓库查询准确的数据要求精确的输入，因此系统需要能过滤掉非必要数据，这使得处理这种情况的工具有些困难
有限的灵活性、分析能力
另外，单层架构在分析复杂度方面有一些限制。由于它的缓慢性和不可预测性，它很少应用在大型数据平台。要执行高级数据查询，数据仓库应该在低层次实例下被扩展从而简化数据查询。
4.2
两层数据架构（数据集市层）
在两层架构中，在用户界面和 EDW 层增加了数据集市层级。数据集市是包含特定主题域信息的低层级存储库。简而言之，它是一个在特定主题（例如销售、运营、市场等）下延伸了 EDW 的较小数据库。
创建数据集市层需要额外的硬件资源，并集成它与数据平台其他的数据库。但是，这种方法解决了查询问题：每个部门都更容易访问到所需数据，因为每个集市仅包含给定域信息。另外，数据集市限制了终端用户对数据的访问范围，提高了 EDW 的安全性。
4.3
三层架构（在线分析处理）
在数据集市层之上，企业通常使用联机分析（OLAP, Online Analytical Processing）处理多维数据集（cube）。OLAP 数据集是一类从多维度描述数据的特定数据集。关系型数据库只能表示二维数据（如 Excel 或 Google Sheets），而 OLAP 允许在多维度下编译数据并且在维度之间移动。
很难用语言解释多维数据集，所以让我们通过一个简单的例子看。所以如上图，cube 为数据添加了维度，你可以看做多个 Excel 数据表的彼此合并。cube 的前部是普通的二维表，区域（Africa、Asian 等）在垂直面指定，而销售数据和日期则写在水平面。当我们看到 cube 上部时，神奇的事情开始了，销售按路线划分、底部指定时间周期。这就是所谓的多维数据集。OLAP 的业务价值在于允许用户对数据进行切片、切块以编译出详细的报告。只要 cube 通过数据仓库进行优化，他们就可以和 EDW 一起使用，以提供对所有企业数据或特定数据集市的访问。在实施方面，几乎所有的数据仓库供应商都提供 OLAP 作为一项服务。在这一点，我们讨论了应用企业需求的 EDW 高级设计。现在我们将深入研究数据仓库包含的技术组件。
5
数据仓库 VS 数据湖 VS 数据集市
说数据存储体系结构，我们不得不提数据集市和数据湖代替数据仓库的选项，经常混淆，我们将详细阐述这些定义。
数据仓库 意味着存储结构化数据，因此查询工具和终端用户可以获得较为全面的结果。数据仓库最常用于 BI ，存储大小通常为 100GB 以上。
数据湖 主要用于存储原始数据或混合数据，它们通常用于机器学习、大数据、数据挖掘等领域。近几年，数据湖被用于 BI：原始数据加载到数据湖并且进行转换，是 ETL 的一个替代方案。虽然这种方法有它的优点和缺点，但数据湖对于获取结构化数据来说太杂乱了。
数据集市 它也可以用来代替数据仓库，一些模型（例如 Kimball's Model）设想使用多个数据集市按主题域分布信息并相互连接。但是，数据集市很小（通常小于 100GB），很难被企业使用。更常见的做法是，数据集市将大型数据仓库分割成多个操作性更高的数据库。
6
企业数据仓库组件
有很多工具可以用来建立数据仓库平台，我们已经提到了大多数，包括数据仓库本身。所以，让我们看看每个组件的用途及其功能。
数据源：最简单的，存储原始数据的数据库。
ETL/ELT 层（Extract、Transform、Load）：这些是与原始数据进行实际连接的工具，它们抽取，并装载到需要转换的区域，转换为统一的数据格式。ETL 和 ELT 的不同之处在于， ETL 在装载进数据仓库前进行转换操作，转换在暂存区完成的，而 ELT 是一种更现代的方法，它在数据仓库进行所有的转换。
暂存区：在 ETL 的情况下，暂存区是数据装载到数据仓库之前的存放区域，在这里，数据被清洗、转换为给定的数据模型。暂存区可能同时包括数据查询管理工具。
数据仓库：数据最终装载的存储空间。在 ELT 的情况下，它仍然包含一些转换。但是，在这个阶段，所有的一般转换都将被应用，数据将被装载到最终模型。如前所述，数据仓库通常是关系型数据库，数据仓库还包括数据库管理系统和额外的元数据存储。
元数据模块：简而言之，元数据就是描述数据的数据。这些描述为用户、管理员提供了关于这些信息相关的主题、域的提示。这些数据可以是技术元数据（如：初始数据源），也可以是业务元数据（如：销售区域），所有的元数据存储在数据仓库中的独立模块中，通过元数据管理工具进行管理。
报表层：这是一些让终端用户访问数据的工具，也称为 BI 接口。这一层通常作为数据可视化、报表以及提取各类信息的服务仪表台。
7
最后的思考
了解传递数据的工具链可以帮助你确定什么才的真正适合你需求的数据平台。准备建立一个数据仓库平台可能需要几年时间计划和测试，其取决于它的基本形态和规模。作为一个企业主，你可能会被所使用的选项和技术数量困扰，因此咨询数仓、ETL、BI 领域的专家非常重要。虽然专家可以在技术方面帮助你，但定义业务目标，请跟将在实际工作中使用数据的人交谈。