共计 4954 个字符，预计需要花费 13 分钟才能阅读完成。
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 数据虚拟化引擎的钻研和落地工作。
