现代企业及各组织持续致力于尽可能快速集成数据，旨在满足业务利益相关者日渐升温的数据集成提速需求。传统数据集成技术均按照既定计划分批交付数据，且无法支持当今花样翻新的数据类型，因而并不能从根本上处理问题。数据虚拟化是一种现代数据集成方法，业已着手化解当今的数据集成挑战，为未来的数据集成奠定基础

  c.IT基础设施，数据架构升级（存储系统、数据库系统、大数据系统、数据湖仓等、云数据迁移）

  d.数据管理与运维平台效率提升（数据主权/数据自治，数据资产管理、数据治理系统）

  在不物理复制数据的情况下，连接不同来源和类型的数据，创建具有业务语义的逻辑视图（数据虚拟化层），为各种业务系统和人员提供统一的数据访问于交互

  一种先进的数据架构和管理方法，借助数据集成、数据虚拟化、增强型数据目录、主动元数据、AI/ML等技术实现数据统一管理，提供一致的数据服务，支持更快的业务决策创新

  将分散的各种异构数据元以物理复制/集中的方式来进行管理和治理，通过数据收集、整合、治理和分析的过程，将数据结果服务企业各业务部门和场景

  政企数字化转型过程中，对各业务单元业务与数据沉淀，构建包括数据技术、数据治理、数据运营等数据建设、管理、使用体系，实现数据赋能；区别于数据管理平台，数据中台强调更全面的数据集成，包括非机构化数据来源

  企业级数据资产化管理，实现IT及业务人员对数据资产的追踪和监控，为数据分析应用提供质量的数据服务，包括数据资产搜索、元数据管理、血缘分析、数据资产共享

  数据虚拟化作为一种数据集成策略，所用方法全然不同：数据虚拟化并非物理上将数据移至新的整合位置，而是提供整合式数据的实时视图，源数据则保留在原处。

  先进的数据虚拟化解决方案还会更进一步：建立企业数据访问层，提供对组织所有关键数据源的通用访问。在需要访问数据时，业务用户都能够查询数据虚拟化层，该层继而从相应数据源获取数据。数据访问组件归数据虚拟化层负责，因此这些用户不必受困于访问的复杂性，例如数据存储位置或数据格式。依据数据虚拟化层的实施方式，业务用户只需提出问题并获取答案，将底层复杂给数据虚拟化层处理即可。

  大多数情况下，这些无缝的“自助式”场景不会涉及业务用户直接查询数据虚拟化层的情况；相反，其可能与应用程序、Web 门户或以用户为中心的其他界面交互，继而从数据虚拟化层获取所需数据。基本架构为数据虚拟化层位于中间，所有数据源和所有数据使用者（无论个人还是应用程序）分居两端，如下图所示：

  由于数据虚拟化不复制任何数据，故而数据虚拟化层本身不包含任何数据，相反地，仅会包含访问各种来源所需的元数据。数据虚拟化层“轻量化”且易于实施，除此之外还拥有诸多优势。比如，该架构意味着企业范围的访问控制可轻松应用于数据虚拟化层，而非逐一应用至每个源系统。它还提供让研发人员用来连接 API的中心位置，兼顾结构化程度各异的数据源。因此，数据虚拟化是一种现代数据集成策略。它在转换和质量控制功能方面与传统数据集成解决方案大同小异，但能以更低的成本提供实时数据集成，并且速度更快，敏捷性也更高。它可以取代传统数据集成流程及其关联的数据集市和数据仓库，也可简单地对其进行强化以扩展功能。

  作为抽象层和数据服务层，数据虚拟化可以轻松驾驭原始和派生数据源、ETL 流程、客户服务总线 (ESB) 及其他中间件、应用程序和设备（无论本地部署还是基于云端），进而在业务技术和信息层之间提供灵活性。

  1. 数据混合功能：通常包含在商业智能工具中。数据混合能结合多个来源共同向 BI 工具提供数据，不过输出内容的使用权限仅限于该工具，其他外部应用程序均无法访问。

  2．数据服务模块：通常由数据集成套件或数据仓库供应商提供，需要额外付费。这些模块提供强大的数据建模和转换功能，但其查询优化、缓存、虚拟安全层、对非结构化来源的支持及整体性能往往较弱，因为这些模块通常设计为原型 ETL 流程或主数据管理工具。

  3．“SQL 化”产品：这一新兴类别在大数据和hadoop供应商中尤为多见。这一些产品可对底层大数据技术进行虚拟化，使其能与关系数据源和平面文件相结合，以便使用标准 SQL 进行查询。这可在大数据堆栈方面发挥效用，但也只能止步于此

  4. 云数据服务：通常部署在云端，并具有与 SaaS 和云应用程序、云数据库及 Microsoft Excel 等少数桌面和本地部署工具的预封装集成。不过，与真正的数据虚拟化产品不同，这一些产品具有分层视图并可委托执行查询，可以跨云来源公开标准化 API，以便在中等规模项目中轻松进行数据交换。涉及大数据分析、大规模的公司系统、大型机、大型数据库、平面文件和非结构化数据的项目不在此类服务范围以内。

  5. 数据虚拟化系统：这类系统从头开始构建，旨在通过统一的虚拟数据层以多对多方式为公司可以提供数据虚拟化功能。数据虚拟化平台专为跨各种应用场景（与来源和使用者无关）的敏捷性和速度而设计，优于其他中间件解决方案并能与之协作。

  数据源连接： 首先建立与各种数据源的连接，这些数据源可以包括关系数据库、数据仓库、云端数据存储、Web服务、API等。通过这一些连接，可以访问和撷取不同数据源的数据。

  元数据管理：元数据管理收集和维护与数据源有关信息，以逻辑基本视图呈现数据(抽象化)。

  虚拟层建模(业务层)： 建立虚拟层，以SQL整合和访问数据，允许您创建用户友好的数据结构，无需实际复制数据。数据模型是按照业务需求来创建的，以便用户能以业务术语和逻辑方式访问数据。这在某种程度上预示着业务用户都能够使用他们熟悉的业务术语查询和操作数据，而无需进一步探索底层数据源的技术细节。

  虚拟层建模(应用层)：它为不同的应用程序提供了访问虚拟数据的接口。这些应用程序能包括商业智能工具、数据仓库、报表和分析工具等。应用程序层允许不同的应用程序以一致的方式访问和利用虚拟数据，无论这一些数据源位于何处。

  数据访问：虚拟层建模完成，用户都能够通过SQL或API访问数据，动态地整合和联合来自不同数据源的数据，这使得用户能够以一致的方式查询和操作数据，无论数据来源在何处。

  性能优化： 虚拟化引擎具有性能优化功能，可以大程度地提高查询性能。它可以自动缓存结果，并通过智能查询计划来优化查询的执行。

  数据缓存&预计算： 创建缓存层存储需要预先计算或查询过的数据的副本，以提高查询性能。创建摘要、报告和汇总数据，以便更轻松地了解数据的全貌。

  通过数据建模工具连接企业的各种不同异构数据源，包括结构化数据（关系数据库Oracle、MySQL、PostgresSQL等）及非结构化数据、大数据系统（Hadoop、Hive）、文件及云存储系统（HDFS、AWS S3, OSS等）。基于原始数据的物理视图（Base View）构建面向业务用户的逻辑视图（Derived View）及业务视图（Business View）。并在虚拟建模过程中完成对各种异构的数据的整合、加工、逻辑建模等过程。

  执行引擎的优化器分析选项并根据源的能力选择佳计划，根据数量和所涉及的操作重写规则和成本估算（CBO）

  2）Presto 集群(Coordinator + Worker): 将Presto集群拆分成多个Presto小集群，每个小集群由单个Presto coordinator以及多个Presto worker组成，多个小集群结合Alluxio Presto Intelligent Gateway可以实现高可用以解决Presto Coordinator固有的单点问题。同时，通过分集群的方式可以更细粒度地对任务进行划分，比如，可以将查询频繁的小任务分配到节点数较少的集群，而将ETL等需要消耗较多资源的任务分配到节点数较多、机器性能配置较高的集群。

  a.SQL结果的缓存。多用户的场景下，同样的BI报表以及部分SQL的即席分析，往往需要反复查询，SQL结果缓存能够让用户快速获得已查询结果，节省查询的时间和资源开销。在离线入库的场景下，能进一步通过缓存预加载的方式，使用户在查看报表时快速获取到结果。

  b.Presto集群高可用。根据Presto小集群的负载情况，对查询任务进行路由，实现Presto小集群之间的负载均衡。同时，当某一个Presto小集群发生故障时，可以将新任务路由到其它Presto小集群，避免整个Presto服务不可用，从而达到Presto高可用的目的。Gateway作为一个无状态服务组件，自身的高可用能够最终靠Nginx组合实现，如下图所示：

  c.基于用户资源配额的优先队列。Presto集群资源不充足的情况下，大量查询任务提交到Presto集群容易造成任务堆积，导致集群崩溃。根据实际情况需要，基于用户进行资源分配，通过优先队列实现Presto的流量控制，同时能够有效监控某一时刻用户的使用情况，适当手工进行优先级调整，使得对集群的运维更加可控。

  d.审计日志分析。Gateway作为查询任务的统一入口，能够收集到所有用户的SQL请求作为审计日志，在此基础上，可以进一步对SQL查询的情况进行归档，以便后续分析并进行优化。比如，通过审计日志可以得出每天SQL查询的P99、P95、P80等指标，以便于对集群的性能状况进行监控，找出一些热SQL或慢SQL进行针对性的优化。又如，可以分析得到用户的使用时段，在空闲时段进行弹性缩容，将资源用于别的组件，以达到降本增效的目的。

  3)使业务用户能创建自己的查询并使用拖放界面从目录中执行它们，而无需了解 SQL。

  4)将查询保存为收藏夹，并将其导出为新的新视图，允许其他工具或用户重用。

  5)使用描述、标签、沿袭、背书和使用活动情况（谁访问了什么、何时以及怎么样去使用）将数据集置于上下文中。

  6)包括预期的执行时间、数据集常用的查询以及频繁使用数据集的用户和应用程序。

  8)与 各种BI工具直接集成，并能够将结果导出为 CSV 和 Excel 等格式。

  在多数据源、多数据格式的情况下，从数据集成到数据消费的过程，企业传统有两种方式，一种由数据研发人员，创建一个数据处理程序。把数据从原数据系统中取出来，数据清理后再把它存到另外一个数据库中，最后开放给到业务用户去使用。另一种是把数据导出为 Excel 文件，再由熟悉数据源的业务专家或 IT 人员对 Excel文件进行手动数据处理，然后给到业务用户做多元化的分析。这两种方式都是非常低效的，不仅从时间成本上来说非常不合理，而且对数据准备人员的能力要求也很高。我们尝试使用数据虚拟化平台更好地解决这样一些问题吧！

  示例场景会有三个数据连接：两部分数据来自 Web api（分别是 Json 和 Soap），另一部分数据来自 Oracle。

  Step 2. 创建基础视图，用于呈现数据虚拟化平台和源数据表的匹配关系；

  Step 5. 构建报告视图模型，将多个业务视图关联起来，模型可以输出保存，且很方便修改。

  使用数据虚拟化平台构建一个逻辑报告视图后，就可以关联各种BI工具进行自助分析了。

  业务人员的普遍挑战是：很难了解到企业究竟有多少数据资产，有哪些数据资产能够适用于数据分析和探索。针对这个难题，数据虚拟化平台提供了数据目录工具。可以在用户建立整个元数据系统的时候，主动地读取元数据的一些信息，构建其数据目录。另外还提供了一个搜索引擎，能够迅速地帮助用户找到相应的数据资产，确认其是否想要，是否可用。

  通过这个场景，不难发现：从数据目录去寻找需要的数据，然后再用 BI 工具分析数据，整一个完整的过程变得很简单！

  数据消费不单单是用于数据分析，还会有共享到第三方或业务系统的场景。例如：很多有数据中台的企业，经常会在中台创建很多 Web api，实现数据的共享，需要写很多代码，整一个完整的过程费时费力。其实，通过数据虚拟化平台能快速实现共享数据需要的 api，只需要简单的点击操作。如下示例，若需要把业务视图中的信息进行共享，只需新建一个 REST web 服务，设置好数据格式，然后保存，最后对这个 Web api 进行部署即可。

  部署好之后，用户就可以直接通过AIP访问共享的数据了。整个共享的过程很方便快捷及高效。

  张青锋 StarNET（辰星网科）CTO及联合发起人。毕业于新加坡国立大学（硕士）及西安交通大学；曾在Oracle, Sybase, StarNET等公司长期从事解决方案架构、技术咨询、产品研制等工作；在大数据/数据湖、数据虚拟化、图数据库/知识图谱等领域具有多年技术架构及产品研制经验。