1. 业务敏捷 or 数据有序的二选一困境

随着业务数据化的日益深入和大量数据工具的应用，数据驱动型企业收集数据变得更容易、存储数据变得更便宜、分析数据变得更简单，直接催生了业务敏捷自助用数在企业内部的兴起。但由此带来的数据无序增长直接导致了数据架构不可挽回地滑向腐朽深渊，大量的重复数据以及数不尽的数据烟囱成为数据“不好找、不敢用、风险大、成本高”的元凶。

业务敏捷和数据有序代表了数据驱动型业务的两个根本性诉求，即数据需求的交付效率和质量，两者不可偏废，然而现实情况是两者往往无法兼得。我们通常认为数据架构腐坏是研发人员和研发规范的管理问题，招聘优秀的数据架构师，采购或研发优秀的元数据管理平台和指标管理平台，重构一份好的中间层数据，并设定一系列数据研发规范和治理制度就能够轻松解决。然而实际上虽然这些措施短期有一定效果，但是随着业务的迅捷发展，往往老中间层还未完全迁移下线，新中间层就已经开始腐朽。

2. 无序增长的到底是什么数据？

在对多家数据驱动型企业的数据情况进行深入分析后，我们发现，这些快速增长的数据大多集中在轻粒度汇总层和应用层，这些数据由于离业务实际应用很近，大多需求各异，且数据随着业务变化而很快无人问津，这些表通常需要考虑业务使用的友好性和查询性能，因此往往以大宽表以及不同粒度、不同周期的汇总表形式出现。具体而言，分成以下几类：

1、同一逻辑模型拆分存储：因为数据来源不同、研发者不同、消费端对于数据产出时间的要求不同等原因，将原本面向消费侧应该归属一个概念模型的字段拆分到了不同表中去实现。比较典型的有：

维度模型场景：研发会员维表，由于数据来源不同、研发者不同、上游数据产出时效不同等原因，将会员基本信息、会员账号信息、资产标签信息、访问标签信息分别放在不同表中。

汇总模型场景：研发会员粒度指标，由于数据来源不同、研发者不同、上游数据产出时效不同等原因，将1天交易相关指标、n天交易相关指标（n天表往往基于1天表加工）、1天流量访问相关指标、n天流量访问相关指标分别放在不同表中。

这种方式下，由于缺乏一个统一可执行的拆分规范和标准，数据生产者往往会基于短期业务需求，随意拆分或拼装物理模型、各自按需建设，形成了大量相似表。

而对于数据消费者来说，要想找到或找全的自己需要的数据，需要一张张去查找和理解大量相似物理表，这就导致了沟通和理解成本成倍上升。

2、冗余维度属性的宽表：为了消费方使用数据时避免 join 从而提高查询效率、以及让数据消费者使用便捷无需查找关联维表等，经常会将关联维度的信息直接退化（冗余）到事实表、汇总表或其它维度表中，形成一张面向场景需求的统一的业务表，例如下方场景：

这种方式看上去很好地解决了下游查询性能以及业务消费的友好性问题，但是由于不同团队有着不同的业务目标和业务思路，且业务往往处在不断变化之中，因此所需分析的维度属性各有不同。而把所有新增的维度都拼接到同一张宽表上来显然是不现实的（这样会大幅拖慢数据产出时效），因此一般数据生产者会选择根据各自所需来构建自己的小宽表，随着业务发展，小宽表又慢慢变成了大宽表，又需要做进一步拆分，由此引发了宽表爆炸问题。

3、不同统计粒度的汇总表：当中间层的轻粒度汇总表（维度多，数据量接近明细）提供接给BI和业务人员做OLAP分析或报表构建时，往往需要按消费场景所使用的维度进行上卷生成重粒度的汇总表或应用表（维度较少，数据量少）再交付出去，否则表的查询性能满足不了业务期望。例如下方场景：

由于消费侧需求的差异性，这些汇总表或应用表往往需要定制化研发，这就会导致大量不同粒度的汇总表被生产，同时与维度冗余问题相互叠加，更进一步放大了数据无序增长的问题。与此同时，一旦涉及某个指标的口径修改或数据订正，那么需要保持来源轻粒度表数据和下游重粒度和应用表数据的一致性，维护成本大的同时，极易产生遗漏，引发数据不一致问题。

综上，我们不难发现，为了解决数据消费的查询性能、产出时效等问题，我们在ETL端定制了大量物理模型，而在业务快速发展变化的今天，这种以物理模型为交付物的数据需求交付方式，在生产效率和维护成本上已经变得难以为继，是数据无序增长的关键症结，是诱发数据研发效率低下、大量数据二义性、企业成本高的本质原因。

因此我们对数据模型的虚拟化技术进行了大量探索，尝试通过数据模型虚拟化技术，实现逻辑数据模型与物理模型既统一、又解耦，从而彻底根治数据无序增长的问题。

3. 数据模型虚拟化如何解决这些问题？

3.1 什么是数据模型的虚拟化

虚拟化是一种设计思路，它尽可能对使用者屏蔽物理运转细节，将原先需要使用者给出的指令，由机器通过恰当的规则和算法进行自动化实现。下图为虚拟化的概念表达：

虚拟化本质就是在绝大部分场景中让用户可以按业务本身的需求去操作，而不需要为物理引擎的特性去做额外的优化操作。

例如在进行汽车驾驶的时候，驾驶员在绝大部分场景中只关心要前进还是倒退，以及所需的速度和加速度。而具体的档位和离合器其实与驾驶需求无关，它们仅仅是传动优化的内部物理细节。因此自动变速箱诞生出来屏蔽了这些物理细节，让驾驶效率的提升和驾驶门槛的降低有了质的变化。

在大数据领域，数据虚拟化技术并不是一个新的概念。Gartner将数据虚拟化定义为了一种先进的数据集成技术，它将不同来源不同格式的数据统一管理起来，让用户可以通过SQL、Python等脚本灵活地对这些数据进行访问甚至联邦查询。

Aloudata AIR Engine（以下简称AIR Engine）包含上述数据集成虚拟化的能力，并在此之上定义了数据模型虚拟化的概念。数据模型虚拟化与数据集成虚拟化完全不同，它专注于让用户可以直接按概念模型对实际研发的模型进行定义，AIR Engine会按一定的规则和算法对虚拟数据模型进行合适的物化链路编排，以满足消费端对产出时效、查询速度以及成本的要求。同时用户定义的虚拟数据模型可以直接交付给下游使用，AIR Engine会自动翻译为最为高效的物理计划去执行。

在我们探索数据研发消费提效的过程中，可能还会遇到DBT、MetricFlow、DAX等数据语义层工具。它们专注于在各自的领域中抽象出一种领域特定语言（DSL），让使用者可以在此领域更加高效的进行工作，并将此DSL自动翻译为SQL去下层引擎执行。虽然语义层工具和AIR Engine都有查询翻译的流程，且都能让数据研发和消费提效，但他们并不属于同一个层面。语义层工具专注与特定领域的语法抽象和执行优化，是数据消费者和数据模型的衔接者。AIR Engine则专注于逻辑概念数据模型和物理实现数据模型之间的衔接和执行优化。

我们认为数据集成虚拟化、数据模型虚拟化、领域语义层三种技术的有效结合，会是未来的大数据技术栈的架构趋势。

本文重点讲述的AIR Engine数据虚拟化技术的整体设计思路如下图所示（包含数据集成虚拟化和数据模型虚拟化能力）：

物理数据源层：企业的数据存储系统，可以为TP数据库、AP数据库、文件系统、对象存储等。

物理数据模型层：AIR Engine将异构物理数据源中的table、view、file映射为统一的表格式数据模型，并进行统一的元数据管理。AIR Engine通过物理数据模型，对使用者屏蔽了底层数据源信息和存储格式等细节。

虚拟数据模型层：用户可以基于物理数据模型和存量的虚拟数据模型，定义新的虚拟数据模型。用户可以完全按实际业务诉求进行虚拟数据模型的定义即可，而无需关注大部分场景下的作业运维、性能优化和成本治理。

3.2 数据模型虚拟化如何优化大数据系统的效率、成本和质量

1、让模型无需拆分

虚拟数据模型的研发思路与物理模型研发完全不同，研发者无需考虑概念模型拆分，可以自由按字段进行概念数据模型的逻辑定义，让消费端以完整的数据模型进行使用。例如下图所示：

与直接将dim_user定义为传统视图再给下游使用的差别是，若将dim_user定义为视图，那么其逻辑必然为dim_user_info、dim_user_account、dim_user_asset_tag、dim_user_visit_tag几张表的关联查询。那么对视图的查询就相当于对其计算逻辑的查询，即使只查1～2个字段也会对所有底表进行关联，大数据场景计算效率非常差。若按上图通过虚拟模型来实现dim_user，当用户只查询dim_user的user_id、name、city字段时，AIR Engine虚拟化引擎会直接翻译为对dim_user_info的查询而不会进行关联查询。

另外下游难以进行字段级别的产出信息监听。例如下游有个邮件期望在is_high_consume字段产出新分区后就发出，那么无论是大宽表还是视图的dim_user实现形式都无法提供此元数据。而虚拟模型则可以提供字段级别的分区更新元数据。

以上两点是虚拟数据模型可以任意宽的基础。

2、让维度属性无需冗余

通过对虚拟模型设置关联，形成雪花模型，当消费端在访问某个虚拟模型时还可以直接访问其关联模型的属性。我们将虚拟模型及其关联模型的所有属性所形成的超大宽表命名为全息虚拟模型（Holographic Virtual Data Model）。下图为一个全息虚拟模型的案例：

当用户查询全息模型的字段时，虚拟化引擎会自动展开为对应的join查询。例如：

同时虚拟化引擎还会根据下游的查询情况按需将关联属性冗余到dws_trade_buyer_merchant虚拟表的物化视图存储中，避免底层进行join，达到提升查询时效的效果。

通过全息模型，我们可以让研发者无需进行维度退化，即可让消费端达到面向一张完整大宽表进行使用的效果。

3、让轻粒度表可以直接面向消费

虚拟化引擎会根据虚拟模型下游的查询需求，按需自动构建加速物化数据。它本质是通过物化视图来实现的，当合适的物化视图构建完成后，对虚拟模型进行特定维度组合的查询就会命中具体的物化视图。 让虚拟模型自身就可以满足业务所预期的查询时效，而不需要重新研发（让企业的元数据资产平台上多出一系列让人困惑的表和指标），同时当查询需求变化后，也会自适应调整或回收物化数据，降低成本。

4、智能数据优化和维护

数据模型虚拟化引擎在大部分场景中可以代持此类优化工作。它很像一个自动挡变速箱，在汽车驾驶中，人进行速度控制，自动变速箱按各种参数和内置策略进行合适的发动机传动控制，同时驾驶员还可以设置经济优先还是动力优先的驾驶感受，自动变速箱根据不同驾驶需求，灵活进行变速策略的优化。

数据模型虚拟化引擎也一样，用户定义完虚拟数据模型的业务逻辑后，引擎不会直接将其物化，而是按消费端对模型字段的产出时间和查询速度的要求，分析全局数据的查询情况，选择性按全局最优的策略进行物化编排（通过物化视图实现），并持续HBO优化。物化目标是在满足消费端性能要求的前提下，尽可能节省计算存储成本。最终可能有的模型不会物化、有的模型只物化部分字段、有些模型会将公共逻辑抽取出来物化、有的模型不仅物化自身还会进行聚合cube的构建。例如下图：

4. 总结

以基于性能和时效需求定制物理表来交付数据的方式，已经无法适应快速变化的业务，成为数据无序增长的关键症结。数据模型的虚拟化技术可以让数据生产者更好地专注于业务逻辑的抽象和设计，而将性能、时效优化以及保持数据一致性等工作交给系统完成；让BI和业务人员能基于更完整、更丰富、无二义性的数据模型进行分析和看数；让企业数据架构能够有序演进、可持续发展。

Aloudata AIR Engine作为数据模型虚拟化技术和Data Fabric理念的先行者，会持续在业务场景适配性、自适应物化数据编排、数据查询性能等方面进行研究和实践，目前已经在多家头部金融机构和互联网公司得到深度应用。后续文章会持续介绍AIR Engine数据模型虚拟化技术的部分实现原理和最佳实践，请大家关注“Aloudata技术团队”公众号。

✎ 本文作者/ 宇贤，毕业于浙江大学，曾就职于蚂蚁、IBM，作为技术负责人完成了蚂蚁数据平台技术架构升级，在数据智能研发、数据语义层、数据治理、数据架构等技术领域有多年经验。目前负责Aloudata数据虚拟化引擎的研究和落地工作。