数据仓库_佳文推介|逻辑数据仓库全集数据统一视图之路

多年来，传统的EDW（Enterprise Data Warehouse，企业数据仓库）一直是综合商业智能（BI）解决方案的中流砥柱，它可以提供一个所有人都能相信并使用的中央储存库。但在当今信息已然过载的世界中，EDW几乎无法跟上大数据数量及多样性爆炸性的增长，这就导致IT技术人员苦苦寻找其他高度灵活、可扩展、且能够满足不断增长的数据实时分析需求的BI解决方案。

在传统的EDW平台中，数据可能来自事务型数据库、企业内重要的软件应用系统（line-of-business(LOB) applications）、客户关系管理（CRM）系统、企业资源规划（ERP）系统或其他来源。将数据加载到数据仓库之前，需要对其进行清洗和转换，以确保整个企业范围内数据的可靠性、一致性和准确性。提取-转换-加载（ETL）操作精确且高度精炼，它提供了一个稳定且可预测的环境，可以从此环境中访问数据。

有了EDW，数据科学家和信息工作者就拥有了一个集中处理平台，他们可以通过该平台执行复杂的分析并生成信息丰富的报表，供需要的人过滤和钻取数据。理论上，EDW的设计中应该包含一组粒度足够细的历史数据，从中可以获取十分有意义的信息，从而证明执行和维护这个系统所需的时间和资源投入是合理的。

曾几何时，EDW也可以存储足够多的数据，为决策者提供了解趋势和推动业务战略所需的信息。数据经转换之后，被加载到数据仓库中（通常是夜间批量加载），数据分析师便可以利用各种BI工具来分析这些数据，这些数据为少量分析师提供了丰富的信息库，他们可以随时任意分析这些数据。然而，这样的日子一去不复返。

在当今的互联网环境下，数据量正在以惊人的速度增长，这在很大程度上归功于Web2.0时代的到来以及随之诞生的云服务、社交网络、移动设备和物联网（IoT），所有这些都被列为大数据的范畴，或者更确切地说，数据量大而多样的、分散的、以非结构化数据为主的开放性数据，带着无比的荣耀，重新定义了这个信息时代。

信息数量不仅在以20年前无法想象的速度增长，还以各种各样的格式散落在全球的信息孤岛中，在这种情况下，我们依然期望这些信息可访问、有意义，并且可以被呼之欲出的最新自助式BI产品（着眼于多源、多类型、不断倍增的数据的实时分析）消费。

面对这种数据过载的情况，传统EDW的不足之处就显示出来了。EDW因其单一来源/单一事实的承诺而进入全盛时期，现在却又因阅读器、传感器、扫描仪、社交网站、RFID标签和无数其他数据生成器和存储的出现而被迫退位。

EDW提供了一个中央储存库来存储清洗过的、可信任的、结构良好的数据，虽然这样的储存库仍然可以起到重要作用，但毕竟我们生活的世界主要由原始的、混乱的、非结构化的数据组成。随着“混乱数据”的不断升级，人们对它的兴趣也不断增长，想要更好的理解它、从其中获取价值、并根据它做出决策。这就得需要一个灵活、敏捷、经济且相对轻松的解决方案，然而这些都不是EDW的强项。

实现和维护传统的EDW平台需要有完整的规划和大量的投入，需要仔细思考如何对数据进行ETL操作以及投入多少资源来维持其运转。

当新需求出现时，EDW却难以随之变化，这可能会给业务带来损害；对源应用程序的修改也可能会对EDW造成严重破坏。基于EDW做项目，时间往往过长，当项目实现时，通常已经不能满足当前的业务需求。这并不是说我们应该彻底抛弃传统的EDW，而是说，当提到大数据的种种时，EDW已不能与之匹配。

企业想要更好的利用大量涌入的信息，于是开始寻求其他解决方案来满足数据需求，这些解决方案或者是传统EDW的补充，或者是其替代品。这通常意味着企业倾向于转向一种更加逻辑化的架构，去抽象出大数据领域的固有复杂性。这种架构利用一些能够缓解数据访问和数据管控痛点的技术来融入多元环境，例如分布式处理、数据虚拟化以及元数据管理等技术。

2011年，Mark Beyer在参与Gartner公司关于“大数据、极端信息以及信息能力框架”（Big Data, Extreme Information and Information Capabilities Framework）的研究时，研发了这种虚拟的BI分析基础架构，并称之为“逻辑数据仓库（LDW, Logical Data Warehouse）”。他在博文”Mark Beyer, Father of the Logical Data Warehouse, Guest Post,” 中提到，处理分析型数据的方法是关注信息的逻辑，而不是机制：

该架构包括甚至是扩充了企业数据仓库，但还会添加语义数据抽象（semantic data abstraction）和分布式处理，通过数据和数据挖掘在元数据中的维护数据资产信息。

它还会监控自身的性能，首先将性能信息提供给人工管理，然后逐步实现针对服务等级预期（service level expectations）的动态配置和性能评估。这很重大。这不是信口开河。这会发生。

Beyer介绍了LDW的概念后，和Gartner的同事一起将这个想法具体化，最终确定了定义LDW平台的七个主要模块：

• 储存库管理模块 - 储存库管理是对EDW中数据储存库的实现，支持保持最高数据质量标准的特定用例，例如合规问题和监管事项所需的用例。假如我们不考虑数据大小的话，数据越有价值，就越有可能驻留在EDW中。




• 数据虚拟化模块 - 无论数据类型和位置如何，不管是结构化、半结构化还是非结构化数据，数据虚拟化就是来自分布式源的单一数据视图。数据仍保留在源系统中，可以包括Hadoop集群、关系型数据库，NoSQL数据库、云服务、数据湖、文件服务器、社交网络或任意数量的系统。




• 分布式处理模块 - 分布式处理是一种将数据处理下推到数据所在的源系统中进行数据查询和数据分析的方法。如果查询跨越多个数据源，则每个系统都可以处理自己的数据块，并将所有系统的处理结果聚合到一个统一数据集里。




• 元数据管理模块 - 元数据管理系统用于维护跨所有类数据服务的元数据，从而使分布式处理和数据虚拟化更容易进行。元数据还可用于保证数据质量，支持数据治理和主数据管理。




• 分类/本体解析（Taxonomy/ontology resolution）模块 - 分类/本体解析系统是一个将数据资产分类与用例本体相关联的系统，以便有效地联合来自多个源的数据。从这个过程中派生出的元数据有助于在有效数据存储中定位数据资产，以及支持审计和服务级别协议（SLA）服务。




• 审计和性能服务模块 - 此模块用于收集LDW其他模块性能的统计信息，同时也可以记录连接的用户和应用程序的使用方式。




• SLA管理模块 - SLA管理模块用于追踪连接的应用程序和用户的预期，根据审计统计数据监控相关的SLA性能，并据此提出建议或自动优化操作。

虽然数据虚拟化和分布式处理作为单独的模块列出来，但这两种技术通常合并在一起使用。例如已经添加到SQL Server 2016中的Microsoft PolyBase，它允许从数据库表结构内部访问Hadoop集群，提供了数据的虚拟化视图，同时将处理下推到数据所在的集群中进行。

还有就是Denodo，Denodo是一个成熟的数据虚拟化解决方案，与PolyBase一样，它也将处理下推到数据所在的系统，不管这个系统是事务型数据库、EDW解决方案 还是Hadoop集群。

在LDW架构中，Gartner所确定的其他模块跟数据虚拟化和分布式处理两个模块同样重要，要完整的实现LDW架构，就需要全部或者大多数模块相互结合，通过跨数据源来支持自助BI、预测分析和实时决策制定。这并不是说LDW必须以特定的方式实现，而是需要用这些模块有机组合，形成一个逻辑整体。

LDW力求在不把数据从原始数据孤岛中搬运出来的情况下，提供所有数据的单一视图，使查询一个或多个数据源就像是查询关系型数据库一样轻松。只有在逻辑层面上处理数据，才能实现大数据时代所需的灵活性和可扩展性。

技术在发展过程中面临的一种挑战是其概念会让人产生极大的困惑，比如LDW以及Gartner提出过的其他概念。和物联网一样，LDW也需要有一个简明的定义，即使是外行人也能根据其定义对LDW的实现结构有一个相对清晰的认识。它是SQL Server这一类的产品吗？还是像Salesforce这样的云服务？或者它更像是一个数据库抽象层或者说是虚拟化技术？后面这种说法相对更有吸引力，因为LDW通常又被称为虚拟数据仓库（VDW），虽然它还有“数据层”、“数据湖”等许多其他名称。

但VDW毕竟有点曲折的历史，所以这种叫法尤其让人觉得有问题。实际上VDW已经存在了一段时间，并且跟LDW一样，VDW承诺会完成EDW所不能完成的任务，也就是将数据统一到一个通用的虚拟储存库中。

然而，与LDW不同的是，VDW主要关注的是关系型数据库，而不是大量的大数据孤岛。通过将多个数据库串联起来，VDW承诺快速简单的执行项目，不必操心传统EDW所有那些恼人的集成细节。数据保留在各自的存储中，不同的应用程序可以虚拟的连在一起，并且可以避免EDW大量消耗资源的情况。

可惜的是，VDW也有不足之处，比如它的性能就不算很完善。想象一下，假如你尝试利用一个查询同时访问多个数据库，响应时间可能会变化，缓存可能不一致，并且一个系统停机可能会造成整个操作的停止。

VDW更大的问题在于，它也未能解决传统EDW最大的难题，即清洗所有数据。同步多个数据库（每个数据库都有自己真实数据的版本），可能会将最基本的查询变成不可预测和不可靠的分析结果。无论在哪里清洗数据，我们总要在某一时刻对数据进行清洗以获取有价值的信息。

当然，VDW还有很多其他问题，但重点是，我们应该谨慎对待在LDW中加上 VDW的标签，并希望LDW可以避免VDW存在的所有缺陷。

人们也常拿数据湖与LDW作比较，数据湖是一个存储大量非结构化数据的储存库，通常出现在Hadoop基础架构中。数据湖可以支持所有类型的数据，并且有能力对这些数据进行转换，并根据需要定义数据结构。谷歌和雅虎是最先进行“数据湖运动”（data lake movement）的公司，但是之后甚至是微软都带着的AzureData Lake服务加入其中，现在正在公开试运行中。根据Microsoft的说法，你可以利用该服务来存储和分析任何类型或大小的数据。

Azure Data Lake和其他技术一起构建于Hadoop YARN（YetAnother Resource Negotiator）之上。YARN是一个集群管理服务器，是Hadoop 2框架的一部分，它利用Hadoop的线性扩展存储和处理，解耦了许多MapReduce组件，允许多个第三方引擎使用Hadoop作为访问数据的通用标准。

LDW的分布式处理组件很适合应用在数据湖上。实际上，数据湖在处理数据方面非常有效并且可以以相对较低的成本实现，因此LDW平台可以将其大部分数据清洗和转换操作推送到数据湖，甚至对EDW中的数据也可以进行这样的操作。当然，我们需要在进行这些操作与移动数据的成本之间进行权衡，但其潜力是存在的，也必定会是有利的。

Hadoop 2和YARN框架使得数据访问、数据处理和数据联邦比以往更高效，但数据湖不是LDW，也不是EDW的替代品。数据湖通常是LDW解决方案中非常重要的一部分，但也只是一个组成部分。

也就是说，将LDW与VDW或数据湖区分开，并没有给出LDW的具像。实际上，要得出这个“具像”并不容易，因为从整体上看，LDW既是一个概念或是一种倡导，也是一种物理实现。这就是为什么“逻辑”这个词在LDW这个名称中如此突出。

也许我们最好把LDW看作是一个由各个部分相结合组成的逻辑结构，包括EDW、云服务、Hadoop集群、数据湖以及其他元素，某些组成部分有虚拟化数据和分发处理的能力。然而，仅这些元素并不能完成LDW架构。因此，我们还要寻求其他产品。

例如ThoughtWeb提供的Enterprise Analytics Studio，这是一种用于集中管理、设计和构建企业LDW的软件解决方案。该解决方案可以利用结构化和非结构化数据，组织和转换数据，应对SLA管理以及分类/本体解析。

MarkLogic也提供了一个LDW解决方案，将其作为一个可搜索的企业数据层，这个数据层提供了各种数据孤岛的统一视图。MarkLogic解决方案中包括NoSQL数据库、元数据目录和储存库、Web服务以及用于连接远程数据源的工具。它还可以接收大量数据，转换和聚合数据，并将其提供给多个应用程序。

甚至Cisco也携其数据虚拟化平台加入了舞台。据介绍，该平台支持LDW的每个模块，包括储存库管理、分布式处理，当然还有数据虚拟化。

【小编语：当然，还有来自敏捷大数据团队的 Moonbox 计算服务平台，也是支持了数据虚拟化、分布式处理、元数据管理以及审计功能，为用户带来虚拟数据库般使用体验，用户只需通过统一SQL语言，即可透明实现跨异构数据系统混算和写出，可以成为LDW架构中非常重要的一部分。】

这些解决方案看起来似乎很完整，但它们本身并不是整个LDW平台，而是为系统提供动力的组件，目的是使所有数据完美的发挥作用。这些解决方案中的任何一个都不能绝对定义LDW，没有一种架构可以定义LDW应该如何组成。它是可变的、可适的、可塑的，是大数据这道菜中必不可少的成分。