作者：董凯

集中式数据管理

从企业级数据仓库(EDW)概念诞生以来的数十年间，为了减少数据孤岛，提升数据可用性，赋能企业管理层，企业通常会将不同业务部门产生的数据交由一个中央的数据平台团队做统一的ETL处理并输出可用的数据产品。其优点是减少冗余的数据加工人员，提升数据可信度（数据一致+口径一致），提高数据处理专业性，以及提供额外的灾备冗余。缺点也较为明显，由于中心化数据团队人员远离业务一线，对于业务数据的含义并不清晰，跨部门沟通所产生的时间成本也非常明显。这也就导致了中心化数仓团队往往拥有并沉积了许多数据，但是却很难设计并推出很好的数据产品，而反观业务条线却对数据产品的渴求日益提升但是却受限于技术能力、数据获取权限和数据平台团队的交付效率，庞大的数据湖也成为了数据的堰塞湖。而作为集中式数据管理的集大成者，数据中台也饱受诟病，根据gartner 2023 数据、分析、AI技术成熟度曲线看，数据中台在幻灭期定位为过时技术。

集团在2012年就开始尝试数据中台，直到2015年发布“大中台，小前台“后数据中台这个词正式确立，数据中台的核心任务是建设全域大数据，解决跨业务线数据使用、避免数据烟囱式开发和重复建设。为此集团沉淀了包括OneData方法论和一系列相关工具产品，这方面的材料很多，大家可以在内网搜索了解。这里我主要讲下我看到的数据中台建设失败的主要原因：

首先，数据中台的建设需要消耗大量成本。对于企业而言，投入产出比是平台建设的首要衡量指标，数据中台的建设和运营需要大量的资金、人力和技术投入，并且短期内可能看不到明显的经济效益（当然这不仅仅是数据中台的问题，数据部门都有类似的问题），这就使得企业要么考虑投入持谨慎态度，要么对于投入没有预期导致建设烂尾，我见过不少数据中台建设后就当成数据仓库用了，毕竟没有几家公司能够像阿里这样持续的投入的。

其次，为了建中台而建中台。企业因为多种原因尝试构建数据中台（我真的遇到不少就是为了权和利），缺乏战略、设计、组织支持，错把中台当成项目去做或者存在场景错配、高配（比如明明构建个数仓就能解决的问题也硬上中台），这种失败可就太正常了。

最后，也是我最想说的，集中式的管理模式（这里说的是管理模式，不是技术架构）并不适合大多数企业。以我自身看到的企业实际情况，一般在集中式管理模式下会经历三个阶段：

• 阶段一：资源不足导致管理失控。因为集中式管理模式对于数据的一致性和可复用性的要求会使得数据需求响应的时长变长，业务越复杂情况越严重，即使有主题域的建设也无法避免，这里面还有业务理解问题导致的重复沟通、不同部门的需求排期等问题，数据价值交付时长以周或月为单位计算，中央团队彻底沦为取数机器，为了解决这一问题，企业会尝试开放部分公共数据给业务部门自主开发取数，因为数据理解、信任、人性等一系列问题最终导致原本的分层建模逻辑彻底被打破，ADS数据冗余问题严重，各种取数任务又导致大量资源的浪费，数据管理彻底失控。
  
• 阶段二：数据治理。按照集中化管理模式的逻辑，出现阶段一的问题后就自然而然进入数据治理阶段，这也是近些年数据治理火的原因，也是企业降本的一种方式，此时中央团队借助于元数据（使用情况、血缘等）来进行治理，这个活不像大家想象中那么轻松，涉及到各个部门的博弈，还容易出现故障，各类替代性的开发工作也无可避免。
  
• 阶段三：陷入管理死循环。中央团队披荆斩棘，好不容易完成当前的数据治理工作（其实多数在第二阶段就躺平了，治理还不如重建），业务变更、数据量增长、堆积如山的数据需求再次排山倒海而来，中央团队再次疲于奔命，更不用说因为无法对业务产生直接价值成为成本优化的首要对象，人手的减少再度加剧管理的混乱，正式进入死循环。
  

这里小结下集中式数据管理的价值和问题

价值：保障数据一致性和质量、共享和复用、降低管理成本，避免孤岛和冗余、集中治理

问题：业务理解和排期问题、复用导致的效率问题、可持续性维护问题

分布式数据管理

爱因斯坦说：复杂的问题不能用产生它的思维方式来解决

既然集中式的管理模式不适合大多数企业，那按照“天下大势，合久必分”的逻辑采用分布式的管理模式是否可行？

2019年Thoughtworks提出Data Mesh，是一种描述基于分布式软件架构和面向领域设计的数据平台模型，这里的“面向领域”源于软件工程学科的领域驱动设计（Domain Driven Design -DDD）, 其思想便是由业务部门来驱动软件架构搭建，这样可以让领域专家经验更好的和技术进行融合。Data Mesh中每个业务团队负责自己的数据域，由业务团队实现数据的管理、开发、数据产品的生成和发布。

为了确保Data Mesh的高效运作和成功实施，Thoughtworks提出了四项基本原则

• Domain Ownership（领域所有权）：每个业务团队负责自己的数据域，负责数据产品的质量和维护，该原则的设计关键是通过业务领域上下文来进行划分，以领域团队为核心组织，技术上主要面向运营和分析数据
  
• Data as a product（数据即产品）：数据被视为与任何其他业务产品一样重要的资产，需要经过设计、构建、文档化、维护和改进。该原则的设计关键是以产品思维为主导，以领域团队开发的数据产品为核心组织，技术上主要关注互操作性（即数据产品需要具备可发现、可寻址、可理解、可信赖、原生可访问、可互操作/组合、具有价值、安全等特性）
  
• Self-serve Data Platform（自助式数据平台）：提倡构建一个自助式的数据平台，使得数据消费者能够轻松的发现、理解和使用所需要的数据，而无需依赖专门的数据团队。该原则的设计关键是跨领域思考，以数据团队为核心组织，以自助数据平台作为技术支持
  
• Federated Governance（联邦数据治理）：治理不是集中在一个中心点上，而是分布在各个业务领域团队中，通过建立一套统一的标准、政策和流程，以及共享的治理框架，确保数据一致性和合规的同时保持灵活和敏捷性。该原则的设计关键是上下文映射（实现数据的一致性、完整性和互操作性），以领域代表为核心组织，以自动化的数据治理作为技术支持
  

上图是Data Mesh的标准架构图，该架构图以Data Mesh的四项基本原则为核心进行了架构化的拆解，从架构图里可以看到Domain Team（领域团队）拥有领域所有权，并对领域内的数据进行处理实现数据产品交付，同时可以发布出Data Contract（数据合约），满足数据产品的各项特性诉求。消费者可以通过订阅的方式获得数据产品进行消费，而数据生产和消费的过程都是由自助的数据平台提供服务，同时由联邦治理平台提供各项标准、政策和流程。

国外客户案例（55+）

集中式管理 vs 分布式管理

目前企业虽然初始多采用集中式管理模式，但因为集中式管理存在的问题对业务产生制约使得企业已经被迫或主动走向分布式管理模式，比如建设数据集市、开放ODS表等方式供业务侧自主进行数据开发提升数据价值交付效率。以下为集中式管理和分布式管理的简单对比，从中可以看到企业走向分布式管理模式时在方法论、技术架构核心、核心功能方面的不同，同时提供了可行的落地策略。分布式管理模式和集中式管理模式可以共存，分布式管理可以有效解决过度集中带来的问题，而适度的集中化又能够较好的解决分布式管理存在的一致性、可复用问题。

DMS对于Data Mesh的思考

Gartner分析师认为Data Mesh对企业提升数据价值交付效率具有重要意义，但在实际落地中发现与Data Mesh的理论还有一定差距，主要问题在于业务团队的数据素养和意愿方面，可行的落地方式是以Data Mesh为方法论，结合Data Fabric来提升自动化水平辅助Data Mesh方案落地（数据编织，简单说就是你想要啥数据，无论数据在哪都能按照你的要求给你组装出来。其实这个技术的要求很高，首先要知道你的需求，进而了解下你需要的底层数据在哪，还能够以最正确的方式把数据组装好给你，这里面就涉及了主动元数据、数据虚拟化等技术，有时间单独给大家介绍）

基于对Data Mesh深度的调研和分析，DMS也给出了对于Data Mesh的核心思考，包括企业什么时候应该考虑实施Data Mesh，如何解决业务团队素养和意愿问题。结合这些思考，DMS提出了企业可行的落地策略，即企业应以数据价值不断提升为导向，基于元数据驱动的Fabric、AI等能力实现智能Data Mesh，最终形成分布式和集中化的动态平衡，以达到企业数据驱动的最佳状态（DMS认为理想的状态是中央团队掌控企业20%核心数据资产，业务团队负责剩余80%）

DMS助力企业实现智能Data Mesh

智能Data Mesh核心能力介绍

为了能够更好的赋能企业构建智能Data Mesh，DMS对现有平台进行全面升级，构建了Ameta+智能引擎+Data+AI开发三层架构，并以Domain为基本开发协作单元，面向业务团队提供以Notebook为核心的Data+AI全链路开发和调度流程。

统一、开放、跨云的元数据服务Ameta

目前企业在数据平台建设时考虑更高的灵活性、避免厂商锁定、增强业务连续性以及成本优化，同时考虑到各种合规性和数据本地化的问题，多云和混合云的策略是企业首选。根据Flexera的2021年云计算趋势报告，92%的企业采用多云策略，82%的企业采用了混合云策略。在这个前提下多云环境就需要强大的元数据管理功能来协调在不同云平台上的资源，为企业提供一个单一的“事实源”（source of truth）。因为元数据定义了数据本身的结构、用途和处理方式，有效的统一、开放、跨云的元数据管理策略对于确保多云环境下企业数据的连贯性、唯一性、安全性和合规性具有重要意义。

随着AI规模化增长，对元数据管理又提出了新的要求，包括增强数据发现和利用、改善数据理解和预处理、加速模型训练、提高数据质量和可靠性、促进数据治理和合规性，通过元数据服务能力的增强来应对多种Data+AI的用数需求。

DMS在规模化的元数据管理和精细化的元数据服务上具备领先优势，结合上述趋势和需求，DMS今年重点打造统一、开放、跨云的元数据服务Ameta，其主要有三大能力：

1、统一数据治理

• 统一Data+AI治理模型，通过一套治理模型对各类跨云数据源进行统一管理
  
• 全链路Data+AI血缘，实现从数据生产到数据价值交付全链路的血缘采集和解析
  
• 元数据驱动的安全&质量规范治理，基于元数据采集、识别和解析实现细粒度的规则、规范管理，进而实现统一的安全&质量规范治理
  

2、开放元数据服务

• 支持以HMS、API对外开放（兼容Unity API、Iceberg API）
  
• 支持Unity Catalog和DLF的接入
  
• 支持Delta lake、Hudi、Iceberg、Parquet等数据格式
  

3、跨云数据源支持

• 支持35+数据源（关系型数据库、NoSQL数据库、企业数据仓库、数据湖、大数据平台等）
  
• 阿里云数据生态全覆盖
  
• 他云、自建数据源支持无缝对接（如：S3、Glue、Hive、DLF等）
  

Data Fabric和AI构建的智能引擎

DMS是一款面向业务团队支撑企业Data+AI全生命周期的一站式数据管理平台，为了解决业务团队自助用数问题的同时避免数据不一致、孤岛和重复建设，引入Data Fabric技术架构，同时结合大模型构建了DMS智能引擎。

DMS基于Data Fabric技术架构构建了新的产品形态逻辑数仓，该形态不仅能够实现在不移动数据的情况下实现数据准备，同时还能够通过虚拟ADS和数据重定向的能力有效缓解数据平台管理压力。

DMS结合通义大模型和SQLbridge小模型构建分析Copilot和问数Agent，面向数据开发、分析师大幅提升找数、数据开发效率的同时提升数据交付效率，避免开发人员沦为“取数机器”。

以Notebook为核心的Data+AI全链路开发

为了实现业务团队用数人员（业务开发、数据开发、数据分析师、数据科学家、产品、运营）能够在一个开发入口进行协作，DMS上线了以Notebook为核心的Data+AI全链路开发能力，包括多引擎开发与调度支持、Spark深度集成、统一的安全保障和Databricks兼容等能力，同时实现从数据生产到价值交付的全链路协同，能够在一个产品、一个领域内形成闭环。

智能Data Mesh

借助于统一、开放、跨云的元数据服务Ameta，Data Fabric和AI构建的智能引擎，以Notebook为核心的Data+AI全链路开发能力，DMS能够助力企业实现智能Data Mesh。在智能Data Mesh中，通过Ameta提供统一数据治理、领域知识赋能，以工作空间的方式实现领域相关人员Data+AI的全链路开发和协作，结合Fabric和AI提升自助能力，最终帮助企业实现分布式数据管理，降低数据管理成本，提升数据价值交付效率。

客户案例

某大型银行

该银行存在独立于中央平台的孤岛集市，为了解决管理混乱的问题，该行以资产盘点提升找数、用数效率为出发点，借助DMS Ameta构建全量资产图谱，通过资产图谱实现对现有数据资产的盘点，提升找数、用数效率的同时完成孤岛集市的元数据采集，并通过资产盘点和DMS主动元数据管理能力对全量资产进行打标和目录化，解决孤岛集市中存在的数据不一致、重复建设问题，同时借助于Data Mesh方法论进一步做轻中台，构建良性的数据管理生态循环。

某头部视频网站

该公司一直采取分布式管理模式，但缺少产品能够帮助解决业务侧领域管理和自助用数问题，进而导致分布式管理模式落地缓慢，中央平台的压力也没有得到缓解。引入DMS平台后，借助Ameta、Fabric&AI以及Notebook为核心的Data+AI全链路开发能力实现智能的业务域管理，解决自助用数问题，数据价值交付效率较之前提升10倍。

快来关注

使用钉钉扫描下方二维码，加入「数据管理交流群」。我们欢迎并期待您的加入！