2024年数据编织价值评估指南白皮书

Data Fabric Value Appraisal: Methodologies and Best Practices CONTENTS 引言01 为什么需要关注数据编织 02 数据编织价值实现机制 06 数据编织价值评估方法 16 数据编织价值案例介绍 19 总结与展望 24 引言 数据编织（Data Fabric）作为一种新兴的数据管理架构理念，近年来获得广泛的关注，一方面 ，Gartner 不仅从 2019 年开始多次在数据技术趋势中提及数据编织，更在 2024 年的数据管理技术成熟度曲线里大幅提升数据编织的成熟度，预测该技术在未来 2-5 年内会获得广泛应用；另一方面，不少企业也在积极理解、探索和应用数据编织这一管理理念，寻求在“数据中台”之外的另一种数据管理架构。结合上述现状，本文从过往数据中台实践的复盘总结入手，牵引出数据编织的价值主张，并对数据编织的核心机制进行剖析，对数据编织的产品和案例进行介绍，让您从里而外真正具备数据编织的价值评估能力，从而推动数据编织在企业组织内的成功落地，最大化释放数据价值。 https://aloudata.com/white_papers/2ef9756e3beaef621f24fc4adaae8216*提 示 ： 如 果 您 对 数 据 编 织 这 一 数 据 管 理 架 构 理 念 缺 乏 基 本 的 概 念 了 解 ， 建 议 先 行 从Aloudata官网下载阅读白皮书《Data Fabric，面向未来的数据管理架构》 为什么需要关注数据编织 随着企业经历多年的信息化建设，企业信息化水平不断提升，数字化思维不断形成，企业科学管理、智能运营、精准服务等数据分析和数据决策需求自然涌现，越来越多的企业开始采购、建设或升级数据底座，统一建设以数据湖仓为核心的一套数据中台，提升数据开发效率与数据治理能力是 CIO 们的第一反应。 和教训，我们对数据中台体系的价值评估有 3 点认知升级： 首先，需要评估技术的业务匹配度。一方面，我们强调“技术服务于业务”，数据体系建设最简单朴素的目标是“让业务及时用上好数据”；另一方面，我们又承认“技术落后于业务”，“业务在天上飞，技术在 地 上 追 ”是 常 态 ， 业 务 变 化 越 快 ， 技 术 响 应 越慢。具体到数据领域，为了实现全域及时一致的数据分析体验，需要对全域数据进行盘点，对数据仓库进行分层建模，比如： 数据中台作为一种企业数据战略和组织设计，自2015 年由阿里巴巴首次提出至今也有近 10 年的时间，回顾和复盘过去 10 年企业数据中台建设的经验 可以发现，上述这套成熟的数据仓库的开发模式每一层都需要有物理的数据搬运和加工，存在高昂的数据开发、任务运维和计存成本，这天然要求实施上述方案的企业的业务模式要相对稳定，看数用数场景要比较清晰明确，否则业务需求的灵活变化会导致前期数据模型建设成本的浪费。 导致企业 CIO 选型数据中台的第一步也许就错了。 其次，需要评估技术的组织就绪度。基于数据中台的解决方案存在众多的产品供应商和服务实施商，很容易让人误以为数据体系建设等同于数据中台的一次性部署和不定期的数据代码外包开发。很显然，这种想法过于简单了。 这就存在一个明显的矛盾：企业期望数智化建设赋能业务灵活创新，而数据中台的这套开发模式天然要求业务伙伴思路要清晰，需求要明确，可以“打固定靶”。但现实并非如此，数据中台打数字化管理场景相对容易，打数智化运营场景就非常困难，这个矛盾 数据开发与管理可以划分为数据集成、数据加工和数据服务三大步骤，相关的工作内容、工具对象与所需知识技能如下表： 如上表所示，数据开发与管理是一项综合工程，涵盖了从数据的采集、存储、处理、分析到应用的全过程，具有很高的专业复杂度和组织复杂度，这也意味着需要具有一定人数的专业团队才能建设与管理企业的数据体系。操作和管理一个复杂的数据中台体系无论是供应商还是企业自身都是一件人力成本高昂的事。 数据中台建设通常强调数据的“应存尽存”，通过 ETL将全域数据进行物理集中存储，并采用面向数据建模的方法构建数据中间层和采用面向业务建模的方法构建数据应用层，层与层之间以及层的内部都有相应的数据搬运和拷贝，存在数据快速膨胀的现象。这意味着数据中台建设成本不仅包括硬件相关的存算基础设施，也包括一系列的数据开发与管理工具，还包括建模 、 开 发 、 运维与管 理 的大 量 人 力 投 入，前 期TCO（Total Cost of Ownership，总拥有成本 ） 至少百万元。随着企业数智化的深入，数据源、数据类型、数据规模、数据需求在快速变化，数据链路和数据工程的复杂度在持续增加，任务运维和数据治理的工作量在指数级增长，数据体系的成本投入随之也水涨船高，成为 CIO 无法绕开的难题。 从更高的维度来看，单纯依赖供应商服务的项目管理方式无法帮助企业实现数据架构的长远规划和迭代，也无法从外向内推动企业内部的数据治理变革，更无法代替企业自身从组织内部形成数据意识和培养数据文化，企业能否相对容易地建立一支自有员工组成的数据团队也是 CIO 必须要回答的课题。 最后，需要评估技术的 ROI。为了消除数据孤岛， 过数据虚拟化技术创建逻辑数据层，在单点逻辑集成了分散在不同系统中的数据，为数据使用者提供一个统一的、抽象的和封装的逻辑数据视图，用户通过这个逻辑数据视图能够查询和操作存储在异构数据源中的数据，把多个异构数据源当成一个同构数据源使用，而无需关心数据位置、数据类型和数据格式，实现了类似数据中台的统一集中化的数据访问与管理，其最大的差异点是无需事前搬运数据、无需事中运维ETL任务、无需事后计存治理（零搬运、免运维、自治理），为数据体系建设和数据管理架构提供了一种全新的思路。 传统数据中台建设是一个IT先行投资、持续投入，但收益不确定的模式，哪怕在项目启动之初绑定数据应用场景，前期的应用场景也很难分摊数据中台的整体启动成本。那么有没有更敏捷更灵活的数据管理架构，既可以从0到1构建企业数据平台，也可以从1到10帮助企业升级现有数据底座？答案是肯定的，基于数据虚拟化技术的数据编织（DataFabric）为企业数据体系建设提供了全新的思路。 正如引言所述，数据编织（DataFabric）是一种全新的数据管理架构理念，其核心理念是通过优化跨源异构数据的发现与访问，将可信数据以灵活且业务可理解的方式交付给所有相关数据消费者，让数据消费者自助服务和高效协作，实现极致敏捷的数据交付。 经过国内外众多企业的实践验证，数据编织具有下述优势： 与传统数据中台体系相比，数据编织的关键突破是通 提高数据访问效率 数据虚拟化为用户提供了一个统一的数据访问平面，无需先完成数据的物理搬运和统一集中即可访问数据，简化了数据访问过程。 提高数据交付效率 数据虚拟化支持逻辑数据视图的灵活定义与实时变更，通过自适应性能优化技术可以告别繁杂的 ETL 操作，极大地提升数据交付效率。 降低数据存算成本 相比传统的数据物理集成，数据虚拟化通过创建虚拟数据层，并只按需物化加速少部分数据以优化查询性能，省去了多次物理复制、移动和存储数据的高昂费用。 降低数据运维成本 相比传统 ETL 技术构建和运维复杂的数据管道，数据虚拟化提供更多简化数据管道设计与运维的工具，提升自动化运维水平。 增强数据管控能力 通过数据虚拟化构建全域统一的数据访问、共享与服务平台，进行集中化的数据管理，可以更好地实现数据安全与数据合规的统一控制和治理。 近年来，在数据源高度分散、数据量和数据需求爆发式增长的背景下，数据编织中的关键技术——数据虚拟化技术得到了快速发展，数据编织这一全新的数据管理架构也获得了广泛的关注，数据编织正在成为企业下一代数据基建的重点投资方向。 02 数据编织价值实现机制 正如 2000 年左右电子商务刚诞生的时候，大家对线上购物“先付款后收货”的模式充满观望，因为电子商务改变了线下“一手交钱一手交货”的常规模式；正如电动汽车刚诞生的时候，大家对电动汽车的行驶里程充满焦虑，因为电动车改变了燃油车“加油 5 分钟续航 500 公里”的驾驶体验；同样的情形也出现在数据编织这一新事物上，大家对数据编织的数据虚拟化技术的实际效果充满怀疑，因为数据虚拟化改变了数据仓库物理搬运数据的传统模式，破坏了传统数仓通过“空间换时间”实现历史数据保存和查询性能优化这 一机制，从而不敢积极采纳数据编织来提升数据交付效率和降低数据管理成本。 为了更好地推动数据编织的普及，除了更多的数据编织应用案例介绍，我们觉得很有必要通过一个简单的场景说明数据编织这一技术的价值实现机制，让一部分技术创新者通过深入理解这一技术从而敢于积极应用这一技术。 让我们尝试通过一个简单的数据报表场景来说明数据编织的价值是如何实现的。 业务需求描述 假设业务需求如下： 1.不同的的，并做成； 统计 每日会员等级订单金额报表 a 2.不同的的，并做成；统计 每日产品类别订单金额报表 b 业务需求理解 ETL 需求理解 03 为报表 a 和报表 b 编写 ETL 脚本，生成目标表表 a 和表 b 3 为报表 a 和报表 b 构建每日运行的 ETL 管道，保障目标表表 a 和表 b 的数据更新； ETL 数据探查 03 会员等级 member_level （10 个等级）来源于 Oracle 数据库中的会员表 member（1 亿数据量{ 3 产品类别 product_catalog（200 个类别）来源于 MySQL 数据库中的产品表 product（100 万数据量{ >3 订单金额 order_amount 来源于 MySQL 数据库中的订单表 order（10 亿数据量） ETL 链路设计 03 构建一张含和的wide_order会员等级产品等级订单宽表 3 构建一张的数据汇总表 t_rpt_a ，统计wide_order中不同的订单金额，每日更新记录到汇总表 t_rpt_a报表 a订单宽表会员等级 >3 构建一张的数据汇总表 t_rpt_b，统计wide_order中不同的订单金额，每日更新记录到汇总表 t_rpt_b；报表 b订单宽表产品类别 传统 ETL 需求实现 1--通过数据同步工具配置member、product、order这三张表的数据同步过程在此忽略2--假设上述三张表已经采集到数据仓库内部34--定义含会员等级和产品类别的订单宽表wide_order5CREATE TABLEwide_order(6stat_dateDATE,7order_idVARCHAR 64(),8member_idVARCHAR 64(),9member_level--增加会员等级VARCHAR 64(),10product_idVARCHAR 64(),11product_category--增加产品类别VARCHAR 64(),12order_amount NUMBER(, )18 013);1415--每日更新订单宽表wide_order的数据16INSERT INTOwide_order order_id member_id member_level product_id product_category order_amount(,,,,,)17SELECTa order_id a member_id b member_level a product_id a product_category a order_amount., ., ., ., ., .18FROMorder LEFTJOINONamember ba member_idb member_id..=19LEFTJOINONproduct ca product_idc product_id..=20WHEREcurrent_datea stat_d