|
数据集市、数据仓库、大数据、数据湖等概念层出不穷，组织在开发利用数据的时候如何气定神闲的考虑数据应用本身的问题，如何发挥数据价值的问题，那么今天我们从数据仓库谈起，说说数据仓库和数据湖的差异、数据仓库的治理、元数据问题、数据仓库建模、数据仓库集成、ETL的作用、数据仓库安全等问题。一览数据仓库建设可能碰到的一揽子问题，下面咱们就一一分解。术语太多，理解太少。随着数据和分析的普及，IT词汇正在迅速扩展，像数据集市、数据湖和数据仓库这样的术语正在被交替使用。虽然它们来自相同的领域，但在构建数据存储库时，它们的含义是非常不同的。我们重于从技术和业务的角度，清晰地理解数据集市、湖泊和仓库的定义。咱们从最熟悉的术语开始，一个已经存在了几十年的术语:数据仓库。
数据仓库是一个中央数据存储库，在其中可以集成来自企业不同系统的数据，为报告进行优化，并可用于商业智能。因此，数据仓库是企业数据分析和报告需求的基础。数据仓库本质上是数据库的集合。大型组织通常使用多种系统，每个系统在后端都有一个用于内容存储和管理的数据库。提取-转换-加载(extract - transform - load, ETL)过程用于从遍布整个企业的单个数据库中提取数据，将数据转换为目标数据仓库的单一、一致格式，并最终将其加载到数据仓库中。来自不同系统的数据在这里同时存在，这使得分析师可以在企业的任何地方查询数据，并获得他们需要的答案，而不必跨多个事务数据库查询数据片段，然后手工将它们拼接在一起。这是一个商业智能系统，每个报告和分析应用程序或系统都是从它派生出来的。使用 | 主存储库支持操作和性能分析 | 上市时间 | 数周，数天，数小时——取决于方法 | 用户 | 高 | 数据增长 | 低到中等 | 成本 | 中级到高级 |
数据集市是数据仓库的一个子集，旨在满足特定操作部门或主题的报告需求。数据仓库也可以被称为数据集市的集合。为了更好地理解这个概念，让我们看一个场景。如果数据仓库是一个包含组织所需的所有可能图书的库，那么数据集市就是该库的一部分，其中将有关特定主题的图书分组在一起。只关心特定主题的读者可以简单地到相关的图书馆部分，或者在本例中是数据集市，并更快地获得他们需要的信息，因为他们不必搜索整个图书馆来找到这些信息。在决定数据仓库设计方法时，数据集市也是一个核心考虑因素。构建数据仓库的一种方法是在部门级整合数据，对数据建模并创建单独的数据集市，然后将这些数据集市组合在一起形成企业数据仓库。这是一种更加敏捷的数据仓库方法，它允许您专注于特定的需求，而不是花费数周时间深入理解企业规模的业务流程，然后构建一个全面的数据仓库来派生单个数据集市。使用场景 | 一线业务报告 | 上市时间 | 分钟,小时 | 花费成本 | 低 | 用户要求 | 低 | 数据增长 | 低 |
数据仓库和数据湖有完全不同的用途。在数据仓库中，我们首先分析需求、规划架构、识别源、确定转换、为报告模式建模数据，并执行移动数据的ETL过程，到目前为止，该过程已为报告和分析进行了优化。与之形成鲜明对比的是，数据被“倾倒”进了数据湖。数据湖用于维护所有类型的数据，数据仓库和数据集市用于存储结构化数据。当您的组织大规模生成不同类型的数据时，您知道需要对数据进行分析以获得战略见解，但还不确定如何分析时，使用数据湖可能是首选方法。数据湖可以存储文本、图像、博客、社交网络活动或任何其他非传统数据源，而不需要首先清理或转换数据。传统数据库既不支持这些非传统的数据类型，也不支持在非常大的数据集上进行查询。因此，如果数据没有被清理和转换，或者没有为报告数据湖而进行优化，那么如何将它们用于商业智能呢?这就是数据科学家的作用所在，他们使用先进的预测建模和统计分析工具来理解大型数据集并识别模式。这本身就是一个完全不同的学科。与所有问题一样，答案取决于您希望如何使数据对业务用户可用。如果您不需要统一的存储库，而只是想在组织中打开一个特定的主题区域来进行报告，那么独立的数据集市是有意义的。另一方面，如果您需要包含所有企业系统的报告功能，那么就使用数据仓库。您还可以根据组织中出现的需要创建许多独立的数据集市，然后将它们放在一起，分阶段创建数据仓库。但是，如果您的组织正在生成大量的过多类型的数据，并且您需要一种方法来维护所有这些数据以便最终进行分析，那么数据湖将是一个不错的选择。数据湖和数据仓库是一个古老的争论，数据湖的支持者通常认为，数据仓库的设计不允许轻易更改，而且在开发成本和时间方面需要密集的资源。现代数据仓库自动化平台正在改变这一点，允许敏捷的数据建模，并在几分钟内创建新的数据集市。在短短的几年中，数据仓库已经成为所有业务活动中不可缺少和不可分割的一部分。为了确保它保持有效并继续服务于其主要目标，同样重要的是通过一套标准规则和程序对其进行适当的监管。这些规则和过程的集合可以称为“数据仓库治理”。由于每个数据仓库都不同，因此需要相应地制定它们的治理策略，但关键的操作元素支持、组织和过程仍然无处不在。现将这三个要素阐述如下:没有高级管理人员的赞助和支持，任何治理计划都不可能实现。从层次结构的角度来看，高级管理层有能力为数据计划提供资金、执行法规遵循和资源。也就是说，支持治理计划的高层管理人员应该意识到，这是一个正在进行的项目，需要所有高层涉众的积极作用和参与。该计划的目标和目的应该被清楚地定义，以衡量该计划的整体功效，并定义KPI。下一个重要步骤是建立一个监督、指导委员会或治理委员会，由组织内部精通技术的高层人员组成。这个委员会需要来自业务、IT和业务两个半球的人员。赞助委员会是另一个实体，不要与治理机构混淆，它不应该单独负责数据仓库项目。在治理主体中拥有业务人员的目的是确保整个数据仓库体系结构与业务目标保持一致，设置操作优先级，并在每个级别上接受项目。·根据法律限制和数据安全法规，定义最终用户的数据处理权限和访问权限。·确保关键业务决策是基于来自数据仓库的信息做出的。·确保数据仓库设计中的可伸缩性和灵活性，以适应操作范式中的剧烈变化。这也与变更管理程序密切相关，变更管理程序规定数据仓库应该完全兼容业务用户不断增加的、在时间上压倒一切的变更请求。也就是说，每个变更请求都应该正式提交给治理委员会，并具有逻辑业务推理。在审查后，委员会将有权批准或拒绝这一请求。有了组织的支持，数据仓库治理的最后一个方面是确保基本的过程，如资金分配、规划管理/验收，以及为长期运行建立度量。这些过程一旦被灌输并遵循众所周知的“T”，就可以确保数据仓库能够满足它的主要、次要、近期和长期目标。将运行良好的数据仓库与未达到预期目标的数据仓库区分开来的关键因素通常是流程管理的松散。建立数据仓库治理计划可以获得许多好处。以下是一些显著的好处:当适当地实施并根据上面提到的指导方针时，治理程序允许企业做出更好、更快的决策，而且更加确定和不受惩罚。它减少了错误，比如由于安全性不佳而导致的数据泄露，以及向接收者传输缓慢的数据，节省了大量资金，这些资金可以用于进一步的业务运营。每个组织都有意或无意地存储数据。精心设计和实现的数据仓库治理策略可以确保数据在整个组织中共享，决策者可以访问所需的相关资源。数据仓库中的数据治理显然会促进问责制。谁可以访问数据，何时访问数据都要报告和记录。这确保了最大的透明度，并允许跟踪数据中的任何更改。另一方面，治理还为组织的不同部门提供了一个汇聚和协作点。元数据有助于数据管理，并充当保存某些数据或信息的对象的描述。在数据仓库中，它被集体组织在一个称为元数据存储库的目录中。1968年，Philip Bagley在他的《编程语言概念的扩展》一书中正式提出了“元数据”这个术语。最初，这个短语主要用于详细描述数据存储库的信息。随着存储大量数据需求的增加，元数据开始引用数据仓库中存在的单个根级对象。元数据下的信息完全依赖于数据仓库的需求。元数据一般分为三种类型:·技术元数据提供有关数据结构、数据所在位置的信息，以及与在其本地数据库中查找数据相关的其他技术细节。·业务元数据以通俗的术语描述实际数据，从业务的角度来看，这可能是至关重要的。它可以深入了解数据的类型、起源以及数据仓库中其他实体之间的关系。·流程元数据存储关于数据仓库中发生的所有操作的发生情况和结果的信息。在进行ETL流程和其他查询执行的故障排除时，这种元数据非常方便。每一种类型都包含描述数据所需的重要元素。当数据量很大并且在数百万参与者之间共享时，一个好的实践是遵循一些关于这些元素的标准程序。因此设计了特殊的协议，称为模式，它定义将添加到元数据中的数据元素。我们总是可以为数据仓库创建一个自定义模式，但是在用户的能力和理想的数据描述符之间存在权衡(数据将以更好的方式描述，但学习曲线将比标准模式更陡峭)。元数据模式定义了显示元数据元素和每个元素抽象级别之间的连接的语法。这些组合在一起构成了创建元数据所遵循的不同标准。某种标准的使用取决于要描述的数据的性质。元数据建模有30多个标准，但数据仓库最常见的标准是公共仓库元模型(common Warehouse metadata, CWM)和资源描述框架(Resource Description Framework, RDF)。这两种模型都有助于创建数据仓库管理和正确执行的元数据。关于数据仓库对象的所有元数据都作为条目存储在元数据存储库中。每个数据仓库都有一个或多个存储库，其中包含以下元数据。在元数据存储库的帮助下，OLAP服务器、数据集市和ETL流程都得到了成功的管理。由于存储库有效地集成了数据仓库组件，因此标准化实践非常容易。这有助于为使用数据仓库的组织设计战略策略。元数据的产生和存在必然提出了元数据利用的问题。在数据仓库的使用、构建和管理过程中涉及到元数据。它描述了仓库的组成实体，如报表、多维数据集、表、键等。元数据还描述规则和操作，比如数据的转换和映射。由于它拥有关于数据和所有相关操作的信息，因此它支持并改进数据的使用。合理的元数据语法和模式可以弥补常见的人为错误。它有助于系统的自动化，这意味着更低的出错几率。元数据的存在可以保护数据，并且几乎总是可以保证用户将来能够找到、操作、保护和重用数据。仓库中的数据达到tb级别。元数据在数据仓库的开发过程中充当路标，使查找相关对象的过程变得相当容易。由于体积小，搜索数据速度更快。元数据有助于在不使用实际数据集的情况下利用数据仓库中的大量数据。好的元数据将恰当地描述各自容器中的信息。它提供关于数据仓库的检索、结构、术语和管理规则的信息。因此，可以有效地对数据进行分类和利用。由于数据仓库的过程导致了tb级数据的积累，因此创建和发现新的关系并重用数据是最合适的。元数据存储库中定义的角色和策略使研究人员能够在不影响安全协议的情况下重用数据。处理元数据可以提高系统的效率，使其更加健壮。除此之外，控制数据仓库的过程变得非常容易，因为业务用户不需要专门的编程语言来利用元数据开发和使用系统。所有这些因素在数据仓库的初始设置和工作中都节省了时间和金钱资源。管理元数据对于成功操作数据仓库至关重要，因为它对数据相关流程的正确性起着至关重要的作用。应该始终以一种既适合所涉及的技术工作，又能满足业务最终用户需求的方式生成元数据。
数据建模指的是对面向数据结构的探索。这是一个过程，涉及到在一个全面的图表中记录一个复杂的软件设计，使用符号和文本，来表示数据需要流动的方式。然后，这个面向细节的图充当了重新设计遗留应用程序或构建新软件的蓝图。数据模型适用于任何可能涉及创建数据库对象以存储和操作数据的软件开发。就像所有其他建模工件一样，数据模型设计可以用于各种目的，从概念模型(高级)到物理模型。从概念上讲，数据建模与类建模非常相似。类模型用于识别类，而数据建模有助于识别实体类型。通常，数据模型是在项目的设计和分析阶段构建的，这允许用户完全理解新应用程序的需求。数据模型设计就像一个流程图，用来说明不同数据实体之间的关系。当提供准备充分的概念性、逻辑性和物理数据模型时，它们允许涉众在编写编程代码之前捕获错误并进行相关更改。数据建模强调的是应该如何组织数据以及需要哪些数据，而不是应该对数据执行哪些操作。它就像建筑师的建筑计划，在建立数据项之间的关系的同时，帮助构建更多的概念模型。一个完整的数据库管理系统(DBMS)是基于许多数据模型的-最常用的是:·提供数据库所需要的所有数据对象的准确表示。否则，遗漏任何数据可能导致错误的报告和错误的结果。·获取最相关数据的清晰图像，以帮助开发人员设计物理数据库。此数据模型确定不同实体之间的最高级关系。它定义了系统包含的内容，通常由数据架构师和业务涉众设计。主要目标是定义范围并组织业务规则和概念。它着重于建立实体、它们的关系和属性。在概念数据建模中，不存在与实际数据库结构相关的细节。该数据模型的三个基本租户包括:产品和客户是两个实体，客户的名字和ID是客户的属性。类似地，产品的价格和名称是产品的属性。销售是产品和客户之间的关系。概念数据模型或领域模型通过创建基本范围和概念为每个涉众建立公共词汇表。组织范围内的所有业务概念的覆盖，开发和设计以迎合目标受众，它的开发独立于任何硬件规格，如技术或数据存储容量。其目的是像用户在现实世界中看到的那样表示数据。这个数据模型设计定义了系统必须如何实现，而没有考虑在DBMS中如何物理实现。通常，它是由业务分析师和数据架构师创建的。其目的是开发数据结构和规则的技术地图。逻辑数据模型有助于向概念模型元素添加额外的信息。它说明了数据元素的结构，同时建立了它们之间的关系。该数据模型提供了一个很大的好处，即为形成物理数据模型的基础提供了一个强大的基础。然而，基本的建模结构仍然是通用的。它有助于描述一个项目的数据需求，但可以根据项目范围与各种其他数据模型集成。该模型是与数据库管理系统(DBMS)分开开发和设计的。在这个级别上，没有定义键(主键或辅助键)，您必须调整和验证连接器详细信息，这是之前为关系设置的。此数据模型表示特定于数据库的实现和逻辑数据模型的应用程序。它帮助生成模式并提供数据库抽象。这是因为物理数据模型提供了丰富的元数据。这个数据模型有助于可视化数据库结构。它有助于对各种关系数据库管理系统(RDBMS)的约束、数据库列键、触发器、索引和特征进行建模。物理数据库模型描述一个应用程序或项目所需的数据，这些数据还可以在项目范围的基础上与各种其他模型集成。该模型是为项目所需的特定DBMS版本、技术或数据存储而开发的。定义了外键和主键、索引、视图、授权和访问配置文件。随着我们从概念建模阶段转移到逻辑建模阶段，然后再转移到物理建模阶段，数据模型的复杂性也在增加。最好总是从了解数据库中的不同实体以及它们如何在更高级别(概念模型)上相互关联开始。然后，理解数据细节，而不强调它们的实现(逻辑模型)。最后，在特定的数据库中实现您的数据模型，即物理数据模型。然而，考虑一个数据仓库项目，概念数据模型和逻辑数据模型都可以被认为是一个可交付的。多维建模是数据仓库设计中的关键概念之一。本质上，它是用于构造数据库表的技术集合。使用维度建模的主要好处是简单性、优化的查询性能和更快的数据检索。它主要用于业务报告，因为它的结构简单，由非规范化数据组成。此外，根据业务的变化，多维建模具有适应性和可扩展性;它通常与添加一个新列或创建一个新表一样简单。维度表是数据仓库星型模式的组成部分。它可以被称为存储属性和维度的参考点，这些属性和维度用于定义事实表的元素。高级维度表技术用于建模、检索和修改维度表中的数据。在这一类别下的一些主要技术如下:文本注释的内在性质使它们具有模糊性，并对其建模产生了怀疑。争论的是，文本注释是应该在文本事实中建模，还是应该在单独的维度中建模?然而，最普遍认同和最有效的方法是将事实表之外的文本注释存储在一个单独的维度中。事实表中应该有一个与之对应的外键。在理想的维度模式中，事实表只支持单个维度，且相对于事实表的粒度只有一个值。但是在某些情况下，事实表必须默认具有多个值的维度。这会使整个事实和维度关系以及维度表和事实表之间已建立的主键-外键关系失去平衡。一个很好的例子就是拥有多个账户持有人的联名银行账户。这样一个帐户的余额不能存储在以客户ID为维度的事实表中，因为有多个客户(帐户持有人)。这就是桥接表的作用。从名称中可以明显看出，桥接表位于事实表和维度表之间，并解决事实和维度之间的多对多关系(如上面示例中所述的多个帐户持有人)。事实表应该有指向相关维度的外键，这是事实，但也有在关联维度记录之前填充或知道事实表的情况。这个场景被称为晚到维度或早到事实。举个例子，一个新员工加入了一个组织的医疗保险计划。员工从第一天起就有权要求保险索赔，但所有必要的文件可能需要数周时间才能完成，因此移交给保险公司的时间将会延迟。与此同时，如果员工购买了保险，记录将被归类为事实记录，但由于文书工作还没有到达，因此没有相应的患者维度细节。为了解决这种情况，使用了“推断成员”。这需要采用多管齐下的方法，将新记录和新列添加到维度表中。从保险公司的角度来看，我们考虑上述例子并把它作为一个例证，它应该是这样的:由于尚未收到员工的文书工作，客户ID将不存在于客户维度表中，因此它的外键在事实表中也不可用。为了处理这个问题，已经向客户维度表添加了一条新记录，其中放置了客户ID 521，并为其分配了代理ID 17。这个代理值17将作为外键放置在事实表中。另一个标题为“推断”的列被添加到客户维度，其位值为“1”，这实际上意味着这是一个“推断字段”。ID | 客户ID | 推断 | 名字 | 15 | 423 | 0 | John | 16 | 478 | 0 | Adam | 17 | 521 | 1 | Unknown |
这种方法满足事实和维度表关系需求，并允许适应晚到达的维度。稍后，当记录被更新时，源系统提供属性的值，如姓名，它被更新，推断字段位被更改为0，如下所示:ID | 客户ID | 推断 | 名字 | 15 | 423 | 0 | John | 16 | 478 | 0 | Adam | 17 | 521 | 0 | Ian |
数据库必须适应国际标准时间和当地时区。当存在多个当地时区时，就会出现问题。建模此类数据需要一种简单的技术，即在连接两个相关日期维度表的受影响事实表中放置双外键。高级维度建模还有其他方面，使工作更简单，数据更全面和可读。
在使用企业数据仓库或生产数据库作为源构建业务智能应用程序时，需要相当小心地处理属性更改。对维度和事实建模的方式取决于如何在应用程序中反映更改，或者业务是否需要更改历史来进行报告。处理随时间缓慢和不规则变化的维度(称为缓慢变化维度(SCD))尤其具有挑战性。在缓慢更改维度上维护历史记录需要对维度进行建模，以捕获数据的每个状态，并将其与时间戳、版本或当前状态关联起来，以便正确地标识最近的数据，直至原始属性副本。保存这些信息允许企业创建报告，例如，销售人员在两年内被调到3个不同的地点时所产生的销售影响。由于销售代表的位置是一个不经常更改的属性，因此必须对关联的维度建模，以维护指定属性的历史记录。在这篇博客中，我们将详细讨论数据仓库中缓慢变化维度的可能实现、维护SCD历史的不同方法、所涉及的工作，以及企业如何自动设置SCD。顾名思义，缓慢变化维度是指随着时间的推移而缓慢变化的维度，并且缺乏固定的更改时间表。区域或产品名称是不太可能频繁更改的维度属性的示例，因此如果企业希望记录这些属性的更改历史，可以将其指定为SCD。为了更好地说明这个概念，我们将在整个博客中使用一个假设的数据仓库场景，其中业务必须跟踪Product维度中的历史更改。数据仓库领域最重要的远见者之一Ralph Kimball将SCD划分为3种主要类型，声称数据仓库中的每个时间变化实例都可以使用上述3种类型或最初3种类型的组合来处理。如果您正在使用或计划使用任何现代数据仓库工具,像微软ssi或Astera数据仓库的自动化工具,你会发现一个SCD组件允许您指定您想要使用哪种类型的SCD的字段,需要跟踪会随着时间而改变。这种类型的SCD不是跟踪历史记录，而是简单地用新值替换旧值，从而有效地覆盖字段。虽然这是维度中最简单的更改，但SCD Type 1会丢失先前值的记录。·这种变化是一种修正，而不是实际的变化。例如，“产品类别”错误，必须在产品上市前进行更新。·当业务看不到维护特定领域的历史记录有任何战略优势时，就会有意识地选择不跟踪历史记录。在SCD Type 2中，每当在跟踪字段中进行更改时，就会创建一个新的行(或记录)。此记录包含与原始记录相同的元素，但更改的字段被更新，而其他字段保持不变。如果使用的是SCD Type 2，则需要删除并重新创建数据库表，以添加一些必要的列，其中包含允许业务跟踪哪个记录是最近的记录的信息。通常用于此目的的列有:例如，当Product维度表中的Product Price发生更改时，将使用新Price创建一条新记录。原始记录中的“结束日期”列更新，而新记录中的“开始日期”列更新相同的日期。“当前状态”和“版本”以相同的方式更新。然后，根据查询历史数据的方式，可以使用这些参数中的任何一个来标识最新的记录。SCD Type 2是跟踪数据仓库中的历史更改最常用的方法。在SCD Type 3中，不是添加一行，而是将一个新列添加到包含先前值的表中。默认情况下，Previous Value列将只包含最近的历史值。如果业务需要维护过去更改的进一步历史数据，则必须为每个过去值创建一个新列。这需要的数据库操作量通常对企业来说是不可行的，因此SCD Type 3的应用受到了限制。构建数据仓库背后的理念是让报表和分析更容易、更快地跨业务进行。实现SCD虽然很重要，但可能需要您的开发和业务分析团队的大量参与。在某些情况下，您的业务可能会面临构建混合SCD的需求，例如SCD Type 6，它是SCD Type 1、2和3 (1+2+3 = Type 6)的组合。这将需要额外的开发相关工作和对ETL流程的重新思考。应对这一挑战的一种新方法是使用数据仓库自动化解决方案，在业务的后端自动构建SCD配置。用户只需选择在特定字段上实现的选项和SCD类型，就可以了。您是否开始了数据仓库计划的清理之旅?下面我们将介绍数据清理的3个阶段，以帮助您在组织中定义流程。这个故事开始于数据分析。你不知道的事情是无法解决的。首先分析数据中的模式和实例相关问题，以确定数据清理的规模和需要修复的不一致性。在大多数情况下，必须进行手工和编程分析，以发现所有数据质量问题。当使用自动的数据分析方法时，可能会倾向于使用元数据来评估数据质量。您会发现，格式元数据不足以单独度量数据质量，当完整性约束非常少时更是如此。不过，仍然可以使用元数据，只是不是最初在格式中反映的元数据。深入研究数据实例，以基于不寻常值或数据特征的模式设计“新的”元数据。我们已经讨论了在实例级分析数据。这种方法称为数据剖析。通过选择数据分析路径，可以导出数据类型、值范围、长度、离散值以及它们的频率、惟一性、方差、空值出现次数和常见的字符串模式，如电话号码等。此元数据有助于更深入地了解源系统中的属性质量。另一方面，当使用大数据来识别模式时，需要使用数据挖掘。用于此目的的技术包括摘要、集群和关联发现。通过识别模式，该技术获得完整性约束，用于填充记录中的缺失值、修复非法值和指出跨多个数据源的重复值。在数据转换阶段，必须决定需要对数据执行的操作类型，以清理数据并获得所需的数据质量。在每个步骤中，将对源系统中的实例和格式相关问题应用不同的数据转换。但是如何指定数据转换呢?在用于数据集成的提取-转换-加载(Extract-Transform-Load, ETL)过程普及之前，ETL工具支持几种基于规则的语言。用户可以指定规则，ETL工具将用一种受支持的专有语言生成转换代码。随着SQL的更新版本的出现，这种方法已经过时了，取而代之的是一种高度灵活和适应性强的方法来编写转换代码。目前，可以编写SQL代码对源数据应用数据转换以进行数据清理，也可以使用数据管理工具可视化地定义业务规则并选择数据转换。该工具将自动生成相关的SQL代码来自动处理您的数据。这类工具通常具有内置的数据质量和数据分析模块。因此，可以从下拉列表中选择应用于源的质量约束，并自动将错误状态分配给未通过您定义的检查的记录。这种方法几乎消除了手工数据分析，同时允许从可用的库中选择数据转换。例如，如果要对数据进行规范化，可以选择一个数据源，可视化地将其与规范化规则图连接，然后选择目标。集成流程现在已经完成。从选择的工具中选择可用库中的任何数据转换，并以类似的方式应用它。在集成来自多个数据源的数据时，将面临多个与格式相关的冲突。通常，这将要求您重构单个源格式，以获得适用于所有不同表示形式的统一的、集成的格式。为此，可能需要对表和属性执行合并、拆分和折叠/展开。这些操作可能看起来很复杂，但如果在构建数据仓库时选择了正确的工具来管理和清理数据，则可以轻松地执行这些操作。在实例级，需要应用进一步的数据转换来处理冲突的记录。解决冲突并消除不同源系统之间的记录重复。理想情况下，在继续消除多个系统中的重复之前，应该已经清理了单个源数据。为此，首先需要标识指向同一实体的所有记录，然后将它们合并到一个包含所有记录属性但没有冗余的记录中。这有助于丰富实体，同时最小化数据冗余。在规划数据仓库体系结构时，集成、重组和合并来自各种不同来源的大量数据是一个关键考虑因素。提取-转换-加载(extract - transform - load, ETL)流程用于从源系统中提取、清理、转换和加载数据，以进行内聚集成，将所有数据组合在一起，为业务智能构建统一的信息源。ETL是一个关键的设计概念，是数据仓库体系结构的核心。它确保所有流程无缝连接，数据继续按照业务的定义流动，根据工作流程在需要的地方和时间塑造和修改自己。当从ETL的角度考虑数据仓库架构时，你应该做以下五件事:让我们看看一个典型的数据仓库环境，以理解基本架构，并深入研究以下5个步骤:
在决定数据仓库架构时，必须确保数据仓库的输出与组织目标完全一致。这一步至关重要，因为它可以决定您的商业智能计划的成功与否。弄清楚您的业务用户和涉众希望从数据仓库获得什么，并了解每个特定用户组的需求。请他们清楚地列出“为什么”，这样您就可以筛选数据仓库需求并对其进行优先级排序，确定满足这些需求所需的源系统，并考虑企业数据仓库将如何以及何时使用这些数据。像这样的问题应该从尽可能多的角度和尽可能多的深度提出和回答。这些答案将决定您在构建数据仓库时需要如何构建解决方案和执行ETL。在上面的架构图中，您可以在左侧看到一个典型数据源的列表。数据仓库很自然地抵抗结构变化，因此，在数据仓库开发期间必须仔细分析和选择源数据系统。根据TDWI，系统构建完成后，添加一个新的数据仓库源平均需要7.1周。根据数据源的类型分析数据源。例如，你可以先列出你的生产数据库，如MS SQL或PostgreSQL，销售和营销SaaS应用程序，如HubSpot或谷歌AdWords，客户支持数据源，如ZenDesk，电子商务源，如Shopify和Stripe，传统数据源，如COBOL copybook和IBM大型机，以及pdf和Word文件等非结构化的报告源。确定来源将使您能够更好地确定优先级，并考虑必须如何从每个来源提取数据。如果不理解源数据，就无法执行ETL。列出了数据源后，考虑每个数据源的独特数据提取挑战。传统上，使用ETL的数据提取与事务性数据库相关联，但企业越来越多地使用SaaS应用程序，同时也从纸质报告转向数字报告。所有这些数据都必须输入数据仓库，如果它有助于决策制定的话。这意味着业务智能团队必须考虑如何使用报表挖掘工具从非结构化源中提取数据，将其转换为结构化格式，如何执行基于api的集成，从SaaS应用程序中提取数据，以及如何与COBOL等遗留系统集成，并从copybook中提取数据，除了确定从常规关系数据库中提取的方法。除了提取方法之外，您还必须在系统就位之前和之后设计一个提取策略。数据仓库设计应该同时容纳完整和增量数据提取。当第一次加载数据时，需要完整的提取，但在那之后，您可以使用增量数据提取技术，如Change data Capture (CDC)，定期更新已修改的记录。在考虑数据提取时，确定提取的数据是否需要首先复制到暂存数据库(如上图所示)，还是直接复制到数据仓库。在同一时间提取所有需要的数据并不总是可能的。原因可能包括不同的商业周期、地理因素、加工资源的限制等。一个例子是财务数据，通常需要在月末对其进行调整，以便对终端用户有意义，而销售数据则可以每天提取和加载。在这种情况下，业务可以将数据合并到暂存数据库中，然后使用数据仓库工具的工作流编排功能，以预先指定的时间和频率将其加载到数据仓库中。与数据提取阶段密切相关的是，数据通常需要进行转换，以使其符合数据仓库用于存储的标准模式。在考虑数据仓库体系结构中的ETL转换阶段时，数据重组和数据清理以修复不一致性是关键。这需要的工作量需要一定程度的自动化。在考虑数据仓库设计时，请考虑各种验证、清理和转换源数据的方法，以便将其转换为加载到数据仓库的最终产品。正如在体系结构图中所看到的，源数据在几个阶段经历了许多转换，这些转换必须在数据仓库工作流中预定义。我们已经讨论了为数据仓库构建ETL体系结构的不同阶段，但所有这些都归结为如何协调每个阶段并开发所需的功能。在您弄清楚如何将所有组件组装在一起并确保数据可靠而准确地交付给最终用户之前，您的数据仓库架构设计还没有完成。选择具有内置作业调度、数据质量、沿袭分析和监视特性的数据仓库自动化工具，使您能够轻松地编排ETL流程。虽然这将确保ETL在您的数据仓库体系结构中正确地扮演它的角色，但尝试选择一个提供端到端自动化的数据仓库解决方案，允许可视化地建模数据仓库并编排集成流，同时相关的ETL代码在后台自动生成。一个大型企业平均使用928个应用程序，以及许多其他内部系统。这意味着企业可以拥有来自不同供应商的大约一千个源系统，每个系统都以不同的方式存储数据。当数据分散在企业中如此多的系统中时，如何理解它呢?如果对数据管理领域有一点了解，那么我们已经知道数据集成是解决问题的方法。但真正的问题是，哪种类型的数据集成最适合组织的商业智能需求?
让我们看一看四种常见的数据集成方法，以及每种方法的优缺点，以了解它们最适合在哪些场景中使用。最简单和最早的数据集成方法是将数据从源系统导出到文件中，然后将其导入到目标系统。假设您需要将营销活动数据带到销售应用程序中。您可以将单个活动的数据以. csv文件的形式导出，并手动导入到您的销售应用程序中。另一种选择是开发自定义程序，自动从指定的活动导出数据，并在预先配置的时间导入数据。无论哪种方式，都需要大量的手工工作——即使用前一个选项进行导入/导出，使用后一个选项进行定制开发。即使是手工操作，源和目标也可能有不同的字段。也许你的营销系统有单独的FirstName和LastName字段，而销售应用程序只有FullName字段。在导入之前，您需要转换数据以使其保持一致。另一个主要限制是一次只能在两个系统之间导出和导入数据。在企业环境中，您可能需要集成来自数百个应用程序的数据。一旦开始考虑大规模的数据集成，ETL就成为一个可行的选择，由于其实用性和可伸缩性，ETL已经存在了几十年。从缩写中可以清楚地看出，ETL过程围绕着从源系统中提取所需的数据，进行转换以混合并将其转换为一致的格式，最后将其加载到目标系统。整个过程在很大程度上是自动化的，现代工具提供了工作流创建实用程序，您可以在其中指定源和目标系统，定义要应用的转换和业务规则，并配置您希望如何读取和写入数据。工作流可以包括来自各种源系统的多个集成。一旦完成，您就可以在后台执行工作流来运行ETL作业。虽然ETL确实有它自己的一组挑战，但其中许多都没有被正确理解。一个主要的误解是，如果您在两个系统之间集成数据，ETL是理想的。实际上，这取决于您如何创建ETL代码。如果您手工编写代码，那么集成多个系统将成为一项繁琐的工作，但您可以使用一种工具，允许您可视化地构建集成流，因此在您使用拖放操作继续构建时，它们可以按照您需要的那样复杂。深入您的工作流，甚至可以创建企业数据仓库或数据集市，如果您开始在宏观级别考虑集成流程的话。ETL的另一个误解是，它只允许以固定的每小时、每天或每周频率批量加载数据。然而，今天的数据集成软件提供了先进的变更数据捕获(CDC)功能，允许实时进行数据集成，因此您的商业智能平台保持最新，并允许对当前数据进行决策。虽然ETL在70年代就出现了，但点对点集成一直很流行，直到21世纪初，随着企业应用程序数量的增加，这种方法变得不可持续。如果希望所有企业应用程序能够相互通信，则需要构建(n*(n-1))/2个双向点对点集成，其中“n”表示企业应用程序的数量。让我们使用我们在开始时提到的平均928个应用程序数量来透视这个问题。如果您的企业有928个应用程序，并且每个应用程序都需要相互通信，那么您需要为430,128个点对点连接开发代码。这显然是不切实际的，当您考虑到维护时更是如此。对于每个新的应用程序发行版，您都需要进行回归测试并不断地修复问题，从而使您陷入无休止的测试和维护循环中。与ETL一样，点对点集成也得到了发展，在数据集成空间中使用现代变体开辟了自己的实用工具，例如企业应用程序集成(Enterprise Application integration, EAI)，它使用企业服务总线(Enterprise Service Bus, ESB)作为解决方案。该模型以中心辐射式方法为中心来构建点对点集成。ESB软件提供了一个预构建的环境，该环境允许在企业中快速开发点对点连接，同时允许在同一环境中开发转换、错误处理和性能指标。其结果是一个集成的服务层，业务智能应用程序从主层调用服务。对于复杂的集成，此解决方案使点对点集成再次可行，但仍然需要IT参与。数据虚拟化方法正变得越来越流行，因为它完全消除了物理数据移动。数据位于源系统中创建数据的位置，查询运行在虚拟化层上，该层将用户与访问数据的技术细节隔离开来。查询可以来自您的报表应用程序，也可以来自检索数据、混合数据并向用户显示结果的任何商业智能系统。对于连接的应用程序，虚拟化层看起来像一个单一的、统一的数据库，但实际上，数据是从不同的源系统访问的。这就是为什么数据虚拟化层也被称为“逻辑数据仓库”。现在的数据虚拟化软件也支持缓存机制，所以当您在同一组数据上运行多个查询时，可以使用缓存机制，这减少了时间和精力。这种方法的主要好处是不需要单独的数据库来整合来自不同数据源的数据，也不需要应用复杂的转换来使每个数据源的格式一致。请记住，数据虚拟化不是企业数据仓库(Enterprise data Warehouse, EDW)的替代品。相反，它通过提供对非结构化数据类型的方便访问来补充数据仓库。EDW和数据虚拟化可以作为BI的“单一真相来源”。理想情况下，您所选择的解决方案应该支持多种数据集成类型，以便根据您的业务需求构建集成，并具有支持自动化功能来提升流程。如果撇开技术细节不谈，用外行人的话说，这个主题应该是“没有面团，饼干模具也能存在吗?”在这个场景中，业务智能将是切割机，而数据仓库则是面团。这两者当然可以独立存在，但对任何人都没有多大用处。可以这样想，公司在数据仓库中有许多原始的、未经提炼的信息，但为了使这些信息有用和相关，公司需要一组工具来帮助他们分析数据。商业智能提供了那些可以帮助企业理解数据的工具和策略。因此，组织同时使用这两种技术来增加收入和做出明智的决定。科技界有关于这种关系的轶事，数据仓库被称为商业智能背后的管道或引擎。如果没有适当的数据仓库，所有的数据都首先标准化以供使用，最终用户很可能会添加冗余、不一致和不相关的数据。这样的数据会造成性能瓶颈，危及数据流的完整性，阻碍关键和及时的决策过程。如果没有商业智能工具，跟踪不断动荡的商业趋势和快速适应环境变化将是不可能的。这些工具改进了所有级别和组织层次的战术、战略管理过程。它们保护企业不受“信息过载”的影响，并提供了一条从组织数据中深入理解和获取智慧的途径。是时候再举一个外行人的例子了!将数据仓库视为一座金矿。因此，商业智能将成为开采黄金的采矿设备，将黄金从纯粹的金块变成金条。有些支持者认为，随着时间的推移和技术世界中快速创新的出现，这种共生关系可能会失去吸引力。举例说明了在没有数据仓库的情况下实现商业智能的思想。这种方法背后的基本原理表明，今天的现代BI工具(如OLAP和报告编写器)已经足够成熟，可以提供对操作源数据的近实时访问。为了标准化，可以建立一系列数据竖井，这将有助于生成一组新的报告需求。此外，如果将数据仓库从等式中删除，则可以获得更低的基础设施成本、更快的开发速度和实时监控等好处。这个推论有一个普遍的缺陷!整个体系结构充其量只能被归类为偶然性。它将限制业务对功能和扩展所需数据的可见性。至于节省基础设施成本，建立任意的数据竖井，以及持续维护它们的成本远远超过数据仓库。另一个威胁到BI和DW对称结构的竞争力量是数据湖现象的兴起。这是否意味着商业智能和数据仓库将不再是同义词?数据湖需要以原生格式存储的异构数据分类。对于分析和数据科学家来说，它是一个极其强大的工具，主要适用于那些想深入研究原始数据并从中获得见解的人。但每家企业都负担不起聘请数据科学家的费用。有些人需要预先聚合的、预定义的和标准化形式的数据——可以使用的数据。对于这些人来说，数据仓库及其便利总是必不可少的。从商业智能和数据仓库的可行性到数据湖现象，数据仓库似乎总是处于过时和冗余的边缘。而商业智能在时间和进化的冲击下保持着自己的优势。然而，事实并非如此。商业智能也受到过威胁(找不到更好的词来形容了)。根据一份报告，“分析的民主化已经从根本上改变了BI交付的范式。用户现在可以在不需要IT人员的情况下，在现有数据结构的上下文中创建数据模型并测试新的数据源。”那么，这是否意味着商业智能的未来是暗淡的呢?不!这意味着BI正在发展，它正在经历快速的变化，但由于以下几个原因，它仍然对组织来说是无价的:1.哪里有业务，哪里就有大量的新老数据。BI报告总是需要提供可操作的和有价值的洞察，以了解是否需要进一步的分析。2.内容创建已经从纯粹的以IT为中心转变为以业务为中心，但成功的关键仍然是将报告和仪表板融合到一个可以被最终用户广泛使用的单一界面中。因此，BI仍然是不可或缺的。数据仓库优化虽然很难实现，但却是每个进步组织的目标。这主要是因为使用困难数据仓库的商业智能(BI)系统类似于基础薄弱的建筑;没有坚实的基础，两者都是无用的。由于BI系统在很大程度上依赖于稳定的基础，因此拥有一个强大的企业数据仓库体系结构是至关重要的。如今，许多企业都在不断地构建其遗留数据仓库系统;一层接一层地添加，这样DW模型就可以满足它们不断变化的需求。这导致了一个复杂的数据基础设施，在其中挖掘数据仓库体系结构的各个层成为一项劳动密集型任务。增加复杂性的是数据量和多样性，自这些系统设计以来，数据量成倍增加。那么，在过去的15年里发生了什么让那个时代最先进的系统开始崩溃?业务已经发展，他们的数据架构也在发展。结果，数据仓库团队处于一堆请求之下，无法及时完成这些请求。在建模数据仓库基础设施时，很难预测不断增长的数据复杂性和无穷无尽的用户需求。现在，经常需要将不同的数据添加到现有的体系结构中，由于所有内容都紧密结合在一起，因此它每天都变得越来越复杂。在测试和原型之后替换这些遗留系统并构建新的数据仓库也不是一个容易的选择。企业现在正在寻找优化数据仓库的方法作为替代方案——通常诉诸于不准确的解决方案。在这里，我们总结了常见的数据仓库优化错误，这些错误导致公司使用价格过高的解决方案，但仍然无法满足他们的BI需求。IDC预测，到2025年，数据总量将增至163 ZB (zettabytes)，这迫使企业重新思考他们的数据仓库战略。正在出现的替代方案之一是将数据仓库转移到云，因为它能够有效地解决许多数据量和数据计算问题。但将大量数据转移到云并不是那么容易。您需要移动数据库模式和数据，并在云中执行费力的ETL功能。特别是对于数据仓库优化目的，经常需要进行体系结构现代化、重构数据库模式，有时还需要重建数据管道。这些因素使整个进程进一步复杂化。此外，即使是在金钱方面，也没有多少好处。选择将数据仓库转移到云计算上的公司，最终的支出总额通常会远远高于他们最初的预期。现在，许多公司已经开始将数据仓库设备作为数据仓库建模问题的解决方案。数据仓库设备是一组硬件和软件解决方案，企业使用它们来容纳大量数据(通常以tb为单位)。Netezza和DATAllegro是一些最常见的数据仓库设备。尽管数据仓库设备将提高对数百万条记录的查询性能速度，但它只能通过广泛的硬件和内存配置来实现。因此，即使在数据经历了漫长的迁移之后，主要的数据仓库体系结构问题也是相同的。这主要是因为数据仓库设备不分析数据仓库模式和结构的核心、底层问题。相反，它使用重型硬件用于大规模并行处理(MPP)架构，以提高速度和平台可伸缩性。公司，即使在这些设备上大量投资，也不能产生预期的结果。大数据解决方案，如用于数据仓库优化的Hadoop，未能提供BI系统所需的性能和分析。这是因为这些系统不是为了充当数据仓库而构建的。架构师和科学家,他们试图完成这样的壮举,没有见过很多成功由于若干原因,如:虽然在某些情况下，像Hadoop这样的系统是可以负担得起的，但运行整个数据仓库却不在其中。事实上，编写和执行复杂的查询是非常昂贵的。因此，尽管这个想法可能会吸引您，但请记住，没有任何保证由大数据解决方案驱动的复杂架构将完美地适用于您的数据仓库过程。的确，分析专家已经使用雪花模式和星型模式来提高数据仓库的可见性，但在某些级别上，特别是对于不同的数据，它们并不能很好地工作。有时，这些模式无法提供实际需要的深度。这是因为它们限制了分析的结果，导致用户使用错误的数据。这迫使DW架构师再次回到基础，这似乎不是一个吸引人的想法。除此之外，我们还有著名的ETL。这是一个复杂的过程，需要根据不断变化的业务需求进行微调。然而，这个过程对数据仓库的整体感觉和维护是有好处的。相反，期望这些严格的周期通过提高整体性能来帮助数据仓库优化，那就要求太多了。由于分析是一个过程，而不是一次性的IT项目，因此数据库调优成为一项例行任务。造成这种情况的原因是数据量的大量增加，导致复杂性的增加，所有这些都需要考虑。为了实现这一点，公司需要扩大平台的性能。仅仅基于ETL或通过精细化的数据仓库建模来期待积极的结果是不会有结果的，因为它将无法应对企业数据日益增加的复杂性。有这么多建议的方法试图优化遗留数据仓库的故障，替代方法，如数据仓库自动化和数据虚拟化可能会更好地工作。数据仓库自动化(DWA)是简化传统数据仓库流程的有效方法。作为下一代技术，它依赖于高级方法来自动化数据仓库生命周期的规划、建模和集成步骤。DWA解决方案经过几十年的发展，从手工编码到完全自动化的系统。这种持续增长的主要原因是数据量的快速增长和不断变化的集成需求。它使用一种无需代码的方法来聚合结构化和非结构化数据，然后将转换后的源数据移动到数据仓库。数据仓库自动化提供了几个优于市场上其他数据仓库优化方法的优势，包括:·避免手动的ETL错误，更快的查询处理，以及改进的时间洞察力。·以前所未有的速度将数据转移到其他平台，如云或数据可视化工具。·对最新数据的近乎实时访问使用户能够迅速响应不断变化的市场需求。·减少开发各种数据流程所需的手工工作，改善结果，节省开发人员资源;从而降低了总成本。为了改善为数据仓库准备数据所涉及的数据集成过程，数据虚拟化工具已经获得了吸引力，因为它们能够加速数据到洞察力的旅程。在流程中添加一层数据虚拟化工具可以提供对源数据复杂性的完全抽象，并将其表示为包含所有数据的数据库表。因此，无论您从多少数据源调用数据，数据虚拟化工具都可以将任何结构化或非结构化数据转换为简单、可读的格式。这个抽象层极大地简化了基本的数据仓库过程，如ETL和ELT。此外，它还为BI和分析、报告和应用程序开发提供了就绪状态的数据。它还可以通过各种前端应用程序(如门户和仪表板)访问数据。数据虚拟化提供了额外的数据安全性好处，因为前端用户不再需要了解与源数据相关的技术。因此，组织只能限制相关人员访问数据。·它可以从不同的来源收集数据并在一个地方进行集成。·它减少了为分析不同产品的成功/失败而收集数据所需的停机时间。·如果使用得当，数据虚拟化可以从关系数据库和非关系数据库(如NoSQL)访问数据。该特·性使企业能够从这些源创建组合结果，而在关系数据仓库中是不可能的。·有时，当企业数据仓库关闭时，数据虚拟化合并的源可以用于分析和报告。数据虚拟化工具通过以下方式帮助增强数据仓库的性能:·集成来自其他数据源(甚至是Hadoop)的数据，这将最小化在分析之前将数据加载到仓库的需要。这减少了执行新BI请求的时间。·通过减少数据复制成本，限制网络带宽的使用和利用内存缓存提高执行速度，降低数据集成和加载的编程和硬件/软件成本。数据仓库优化对于确保可信数据可用于分析和决策至关重要。随着数据规模和复杂性的不断增加，如果应用不正确，应用其他所有优化技术都可能出现严重的错误。数据仓库自动化和数据虚拟化等解决方案组合使用时，可以有效地优化数据仓库的性能。但是，在实现之前，您应该根据您的特定数据仓库环境仔细评估这些解决方案。
在当今世界，“数据”是任何业务背后的驱动力。将这些数据存储在一个安全的地方，以防止未经授权的访问，无论是物理的还是在线的，这不仅是希望的，而且是强制性的!随着数据仓库概念变得越来越先进和复杂，那些总是在寻找众所周知的“盔甲上的裂缝”以获得非法访问的不法分子的方法也越来越先进和复杂。不用说，这样的安全漏洞可能会带来毁灭性的后果，从暴露关键和关键的业务信息到被泄露的客户数据库。因此，数据仓库的安全措施是必不可少的，必须严格执行，以确保各级数据的完整性。幸运的是，有一些著名的、经过测试的最佳实践可以用来遏制和减少数据盗窃。但首先让我们解决一些在尝试合并这些实践时经常出现的问题:数据仓库的共享范围和规模可能是实现安全措施的最大障碍。大型数据仓库通常由来自全球不同半球的众多员工访问，以进行分析、商业智能操作、数据挖掘等。我们面临的挑战是在为员工提供不受限制和随时可用的访问与维护数据安全和完整性之间保持平衡。用户的进一步分类和他们对数据的访问级别也是一个问题。最后，安全措施本身有时会变得令人窒息，并可能对数据仓库的整体性能产生不利影响。所有这些挑战的答案是安全措施的实现，这些安全措施是定制的，并与组织的结构紧密结合。在我们深入研究最佳实践的细节之前，有必要将它们进一步细分为物理和在线方面。这两个方面一起工作，使数据仓库不可渗透和安全的入侵。由于生物识别阅读器、反尾随系统和其他物理访问控制机制等技术创新，限制和控制数据仓库的物理访问变得很容易。这些可能看起来过多，而且是开销，但它们在确保宝贵的企业数据的完整性和安全性方面发挥着关键作用。传递有关安全协议的信息，并确保数据仓库附近的所有人员都严格遵守这些规则，是成功的关键之一。入侵者可以利用员工来获取访问权限，这是可以理解的，但如果该员工严格遵守指定的指导方针，情况就大不相同了。由于明显的原因，数据仓库的结构信息也应该谨慎地保守秘密。数据加密是防止数据盗窃的主要措施之一。所有数据都应该使用AES(高级加密标准)或FIPS 140-2认证的数据加密软件等算法进行加密，无论是在事务数据库中还是在数据仓库中。一些支持者认为，数据加密会对数据中心的性能和数据访问速度产生负面影响，但考虑到替代方案，它是首选。数据加密虽然是一种额外的安全措施，但如果不使用分段和分区，则会非常麻烦。分割和分区需要将数据分类或分割为敏感信息和非敏感信息。在进行分区之后，应该对数据进行相应的加密，并将数据放入准备使用的单独的表中。语义学者对此做了一个非常可行的研究，值得一读。在一个地方保护数据和传输数据是两码事。在这里，传输中的数据是指从事务性数据库实时传输到数据仓库的数据。这些事务数据库可以位于地理位置上的任何地方，因此强烈建议使用SSL或TSL等保护协议。如今，基于云的数据仓库在数据库和云存储之间提供了一条安全且不可穿透的通道，这一点应该加以利用。正如前面提到的，如今的黑客和入侵者已经变得和他们所面对的安全措施一样熟练和复杂。实现一个可信的见证服务器类似于雇佣一个看门狗对您的数据访问点进行密切监视。它可以检测到不正当和可疑的访问数据的尝试，并立即生成警报。这使得负责数据仓库安全的人员能够阻止入侵者。
|
