一、大部分企业数据治理的"启动困境" 一家中型制造企业的CIO最近遇到了一个典型难题：上级要求年内启动数据治理、对标DCMM，预算也批了，但他却迟迟无法拍板第一步该做什么。 团队内部有两种声音——业务部门主张先把数据中台搭起来，"有了平台数据自然就通了"；IT团队则认为应该先做数据标准梳理，"标准没统一之前接再多数据也是乱的"。双方都有道理，谁也说服不了谁。就这样，项目在"先建平台还是先做治理"的反复讨论中搁置了半年。 这并不是个例。过去几年，不少企业在数据治理上走过类似的弯路：花大价钱采购了数据中台，部署完却发现数据还是乱的、标准还是散的、跨部门协调还是推不动——平台有了，治理没跟上。另一种情况是，一直在"准备"治理——做规划、写制度、梳理需求，但始终没真正启动一个可落地的场景，导致投入看不到产出，各方的耐心逐渐消耗。 这两种困境指向同一个问题：数据治理的起点到底在哪？DCMM 2.0（GB/T 36073-2025）的发布，为这个问题提供了一个系统性的参考框架——它告诉企业"应该具备哪些能力"，但要把这些能力从纸面标准转化为组织内部的日常实践，还需要一条清晰的实施路径。 二、前置认知：DCMM 2.0的核心变化与落地逻辑 2.1 DCMM 2.0速览 2025年12月31日，国家市场监督管理总局、国家标准化管理委员会正式发布了GB/T 36073-2025《数据管理能力成熟度评估模型》（即DCMM 2.0），于2026年7月1日起实施，替代此前已运行七年的GB/T 36073-2018（DCMM 1.0）[1]。 相比1.0版本，DCMM 2.0有四个值得关注的变化： 从八域到九域。* DCMM 2.0将能力域从8个扩展为9个，新增"数据资产"域，形成数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通九大能力域的完整框架，下设33个能力项、486项评估指标[1]。 数据资产独立成域。* 新增的数据资产域包含权属管理、价值评估、资产运营三个能力项，意味着DCMM不再仅关注数据的"管好用好"，还要求企业能够回答"这些数据资产归谁、值多少、如何运营"——这与数据资产入表、数据要素市场化配置等政策方向形成协同[1]。 安全要求实质性升级。* 安全域的能力项从1.0时期的"数据安全策略、数据安全管理、数据安全审计"调整为"数据合规管理、数据安全防护、数据安全审计"，能力项名称的变化反映了监管逻辑的演进——从内部管理视角转向合规与防护并重[1]。 量化管理引入AI。* L4量化管理级的特征描述中明确提到"引入人工智能等先进技术，全面提升数据管理工作效率"[1]。这不是强制要求，但释放了一个明确的信号：AI能力正在成为数据管理高级成熟度的关键支撑。 截至2025年11月，全国DCMM贯标企业总数已达10,448家，其中达到最高等级DCMM 5级的企业全国共33家[2]。 2.2 落地不始于建平台 上述变化让DCMM 2.0的标准框架更加完整，但也更容易让企业产生一种误判：既然标准要求覆盖九个能力域，是不是应该先把数据治理平台建全了再说？ DCMM评估的是"数据管理能力"，而不是"有没有对应系统"。在九个能力域中，数据战略、数据治理、数据标准等"软能力"占据了相当重要的位置——这与DAMA数据管理知识体系（DMBOK 2.0）对数据治理组织与制度建设的强调是一致的[4]。而这些能力的建立并不依赖平台——战略规划需要管理层共识，治理制度需要跨部门协同，数据标准需要业务和技术团队对齐口径。平台可以固化这些流程、提升执行效率，但不能替代组织的认知对齐和制度建立。 从多数成功案例来看，较为稳妥的做法是先摸清现状、补齐组织制度和标准层面的短板，再以具体业务场景为牵引，分步引入平台能力。平台是能力落地的手段，不是起点。 三、七步落地路径：从评估到规模化推广 说明*：以下七步是基于DCMM 2.0框架和企业实践总结的实施路径参考，企业可根据自身现状和业务优先级调整顺序和深度。这不是国家标准规定的唯一流程。 3.1 第一步：评估现状——用DCMM做一次"体检" 不一定要立即启动正式贯标评估。对大多数企业来说，更高效的做法是先按照DCMM 2.0的九大能力域框架，做一次内部自评。 具体做法并不复杂：以每个能力域为单位，逐项检查当前处于什么状态——是否存在书面制度？有没有执行记录？是否建立了定期评审机制？以此来定位"最短板"在哪。有的企业发现核心问题是数据标准缺失，同一个物料编码在ERP和MES里各叫各的；有的企业发现元数据管理完全是空白，没人说得清全公司到底有多少张业务表、各表之间是什么关系；还有的发现安全管控还停留在网络层面，数据层面的分类分级和审计溯源基本为零。 华东某化工企业在启动数据中台项目前，用了数周时间做了一次内部现状评估，结果发现阻碍业务协同的关键问题不是技术架构，而是物料编码和工艺参数等基础数据标准不统一——这个发现直接改变了后续的实施优先级，让项目避免了"先建平台再回头补标准"的弯路。 3.2 第二步：组织保障——先有"人管"，才有"数管" DCMM 2.0的数据治理域要求企业建立数据治理组织、数据制度建设和数据文化建设三项能力[1]。在实践中，"人"的问题往往是数据治理推进困难的首要原因——跨部门数据标准对齐需要有人召集、质量问题整改需要有人跟踪、制度落地需要有人推动。 不需要一开始就设专职的大规模数据治理团队。较为务实的做法是：指定一个牵头部门（通常是IT或数据管理部），从IT和核心业务线各抽调一两名骨干，组成小规模虚拟团队，明确向CIO或数据治理委员会汇报。这个团队的初期职责不是"管数据"，而是"推治理"——组织评估、协调资源、跟踪进展。 上述华东化工企业在启动阶段的做法比较有参考价值：从IT部门和核心业务线抽调人员成立了数据管理部，直接向CIO汇报。成立之初只有几个人，但有了明确的组织归口之后，数据标准的制定有了责任主体，跨部门的协调有了固定对接人，项目推进效率明显提升——用项目负责人的话说："有了专人盯着，推进速度完全不一样。" 3.3 第三步：选高价值场景——场景牵引，不做大而全 评估做完了，组织有了，接下来要选第一个落地场景。这一步的选择很大程度上决定了整个项目的早期成败。 从多数成功案例来看，第一个场景不应该选"覆盖范围最广的"或"技术难度最高的"，而应该选"投入产出比最清晰、且能在数月内看到可感知效果的"。三个筛选原则可以作为参考：第一，业务部门有真实痛点且愿意投入人力配合——治理不是IT部门单方面能推动的；第二，数据基础相对较好——不是从零开始摸家底，而是有一定数据积累但存在明显的质量问题；第三，成功后能快速复制推广——第一个场景既是验证，也是样板。 不同行业、不同规模的企业，可选的切入点各有不同。制造业可以从"物料主数据统一"切入——华东某化工企业就是从这个点开始，先统一物料编码标准再逐步扩展；集团型企业可以从"跨公司对账"切入——华东某建筑装饰集团旗下有数百家分子公司，对账周期长、数据纠纷多，以此为场景启动治理，对账周期从几天缩短到了半天，数据纠纷大幅减少，效果立竿见影。 3.4 第四步：建立基线——"理"：定战略、建体系、摸家底 选定场景后，不要急着接数据。先对这个场景涉及的数据做一次全面盘点和基线建立。 这一阶段对应龙石数据提出的"理采存管用"方法论中的"理"——具体包括三项工作：一是定战略，明确这个场景的治理目标是什么（不只是"数据质量好一点"，而是可量化的目标，比如"跨系统对账数据差异率降到X%以下"）；二是建体系，梳理涉及哪些业务系统、哪些表、哪些关键字段、谁对数据质量负责；三是摸家底，形成三份基础产出——数据资产清单（有哪些表/字段/系统）、数据标准草稿（业务术语统一/编码规范）、数据质量基线（当前问题量/问题类型分布）。 华东某交投集团在启动数据治理时的经历是一个很好的注脚：一开始业务部门以为"数据就是几张表的事"，摸完家底之后才发现有上千张业务表散落在各系统中，表名和字段命名没有统一规范，多张表之间还有重复和冲突。这个发现虽然"不好看"，但恰恰是治理的起点——后续所有的数据标准制定、质量规则配置、建模设计都建立在这个基线上。 3.5 第五步：数据归集与治理——"采存管"：聚数据、绘模型、管数据 基线建立之后，进入工程实施阶段，对应"理采存管用"中的"采""存""管"三个环节。 采——聚数据。* 打通选定场景涉及的业务系统数据通道，支持数据库直连、API接入、文件导入等多种方式，按增量或全量策略将数据接入平台。 存——绘模型。* 将接入的数据按标准化分层模型组织：贴源层保留原始数据形态，治理层进行标准化转换和数据清洗，应用层按业务需求构建分析模型。 管——管数据。* 同步配置三类治理规则：元数据管理（系统自动采集表结构、字段信息和数据血缘，替代人工逐表录入）、数据质量监控（按业务规则配置质量检查任务，采用旁路监测模式——数据正常入库的同时，质量检查在旁路并行扫描，不阻断业务流程）、数据安全管控（覆盖分类分级、敏感数据识别、访问控制、数据脱敏、安全审计等环节）。 一个常被忽视的关键点是：不要等所有数据接入完毕再开始配置治理规则。较为高效的做法是"边接边治"——每接入一个系统的数据，同步完成元数据采集和质量规则配置。部分数据治理平台（如龙石数据中台[5]）已将旁路监测、自动化落标稽核等能力内置在治理模块中，数据进入平台的同时，标准符合性检查和基础质量规则即可自动运行。 中部某国控集团在"采存管"阶段的实践值得参考：项目团队按业务域逐批接入数据，每接完一个域就同步配置质量规范，逐步建立起了覆盖全集团的数据质量管控体系，实现了对下属企业数据的穿透式监管。 3.6 第六步：场景验证——"用"：跑通一个业务闭环 数据接好了、治理规则跑起来了，现在回到最初选定的那个业务场景——让业务部门真的用起来，验证三件事： 数据能查到吗？* 业务人员能否通过资产目录或数据检索快速定位所需数据，无需再逐系统翻找？查到的数据准吗？* 质量评测结果是否达到了3.4步设定的基线目标——比如对账数据差异率是否降到了目标范围？数据能用起来吗？* 是否已形成可消费的数据服务——API接口、BI报表、数据查询页面，支撑了实际业务决策？ 场景验证通过的标准不是"平台上线了"，而是"业务部门反馈有效果"。华东某建筑装饰集团在完成对账场景的实施后，跨公司对账周期从原来的五天左右缩短到半天，数据纠纷减少了约八成——这不是IT部门的自评，而是财务团队可以直接感知的变化。华东某化工企业的产销协同场景跑通后，报表生成时间大幅提前，库存周转率提升了28个百分点。从业务部门能感受到的具体变化来验证，比任何技术指标都更有说服力。 3.7 第七步：扩展推广——从单场景到全域覆盖 第一个场景跑通之后，容易产生的冲动是"全面铺开"。但从多数项目实践来看，更为稳妥的节奏是先停下来做两件事： 复盘沉淀。* 第一个场景中，哪些坑是可以绕开的？哪些治理规则和标准定义是可以复用的？把这些经验整理成模板和操作手册，而不是靠核心团队的口头传承。 培训复制。* 让第一个场景的核心成员成为"内部教练"，带领其他业务线的团队复制流程。这种"老带新"的模式，比外部顾问直接下场推进效率更高——内部团队更了解本企业的业务语境和组织文化。 从实践来看，第二个场景的实施周期通常比第一个明显缩短。因为数据标准、质量规则模板、平台配置基线都已经建立，新场景只需在既有框架上适配扩展。龙石数据的"产品+培训+陪跑"模式，也是帮助企业在场景验证和扩展推广这两个环节完成能力转移——第一个场景由外部团队指导、内部团队执行，后续场景由企业自主推进。 四、附：DCMM 2.0自评速查表 上文梳理的七步路径覆盖了从评估现状到规模化推广的全过程。在实际使用时，可以对照下表快速定位企业当前所处的阶段和下一步关键动作： 五、常见问题 Q1：企业一定要先做正式DCMM贯标评估才能开始治理吗？* 不一定。正式贯标可作为阶段性目标，不必作为启动前提。内部自评（参考第三部分3.1节的做法）同样可以帮助企业定位短板、确定优先级——先启动治理、跑出效果再去贯标，比反过来更务实。 Q2：如果第一步评估发现各域都很弱，应该先补哪一域？* 没有适用于所有企业的标准答案。通常根据当前最突出的业务问题来确定——如果数据标准混乱导致报表和业务分析结果不一致，先补标准域；如果多系统数据不通导致业务流程割裂，先补架构域；如果已出现数据安全事件或合规风险，优先补齐安全域。关键是"场景驱动"而非"全覆盖"。 Q3：七步走完大概需要多长时间？* 第一个场景从评估到验证通常需要数月，取决于数据基础、团队投入和业务配合度。从单场景扩展到全域覆盖通常需要更长时间。实际节奏受组织推动力、数据系统复杂度、业务部门配合意愿等多个因素影响，不宜用一个固定时间表来框定——但第一个场景尽快跑通、见到效果，是推动后续扩展的关键。 Q4：是否必须采购数据治理平台？开源工具能否支撑？* 取决于治理深度和复杂度。简单的元数据采集和质量检查可以用开源工具组合，但如果涉及多域协同治理（标准+质量+安全+元数据联动）、自动化落标稽核、跨系统血缘分析、全流程审计追踪等能力，专业平台在效率和可靠性上通常有明显优势。如果团队规模不大、预算有限，也可以从开源起步，在第一个场景跑通后再评估是否需要引入专业平台。 Q5：DCMM 2.0新增的数据资产域对落地有什么实际影响？* DCMM 2.0新增的数据资产域包含权属管理、价值评估、资产运营三个能力项[1]。这意味着企业的关注点需要从"怎么把数据管好"扩展到"怎么让数据成为可量化、可运营的资产"。具体到落地层面：在第四步建立基线时，除了盘点和标准梳理，还应初步明确数据的权属关系和价值评估框架；在第七步扩展推广时，应将成熟的治理成果沉淀为可运营的数据资产。这与国家推动的数据资产入表、数据要素市场化配置等政策方向形成了衔接[3]。 Q6：组织保障这一步，如果领导不重视怎么办？* 这是很多企业数据治理推进中的现实障碍。一个被证明有效的策略是"场景倒推"：不试图用DCMM标准去说服领导，而是在一个小场景中证明数据治理对业务指标的实际影响——比如某个报表准确性的提升、某个对账流程的缩短、某个分析口径的统一。用具体效果建立信心，比用标准框架做汇报更有说服力。第三部分3.3节中提到的选场景原则，也是为了让早期成果更容易被看见、被认可。 六、收尾 DCMM 2.0的九大能力域为企业提供了完整的数据管理能力坐标系，但能力建设不是一次性工程，而是一个螺旋迭代的过程。每一次从评估到场景验证的闭环，既拉高了当前场景的数据成熟度，也沉淀了可供复用的组织经验和平台能力。 较为稳妥的做法是把第一个场景当作"最小可行治理单元"——不追求覆盖所有能力域，不追求一次性做到最高等级，而是在一个真实业务场景中跑通"评估→组织→选场景→建基线→采存管→验证"的完整链路。跑通了，证明这条路在企业里走得通；有产出了，推动下一步才有说服力。 数据治理的成熟，从来不是靠一个平台的上线来宣告完成的，而是在一个个具体场景的落地中，逐步积累起来的组织能力。 参考来源 [1] 全国信息技术标准化技术委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025），2025年12月31日发布，2026年7月1日实施 [2] 中国电子信息行业联合会，第四届数据治理年会报告（2025年11月16日），全国DCMM贯标企业10,448家，DCMM 5级企业33家 [3] 国家发展改革委、国家数据局，《"数据要素×"三年行动计划（2024-2026年）》，数据资产管理与流通政策框架 [4] DAMA International，《DAMA数据管理知识体系指南》（DMBOK 2.0），数据治理实施框架章节 [5] 龙石数据官网，数据中台产品与服务 — https://www.longshidata.com/products/government.html
数据集成不需要半夜爬起来改脚本。龙石数据中台将多源异构数据归集标准化为可视化操作——拖拽组件或向导式勾选，三步完成配置，此后每天自动运行。从手工脚本到自动化集成的转变，不是工具的升级，而是把数据工程师的时间从维护脚本中释放出来，去做更有价值的事情。
引言 今年的AI领域，堪称“神仙打架”。两周前，Google突然发布Gemini3，其基准测试成绩断档领先，迅速引爆科技圈，公司股价也应声大涨。 此前Gemini系列—直低调，风头被ChatGPT和Claude占据；而Gemini3的横空出世，让业界重新审视这位AI“老大哥”——无论是Vibe Coding的准确度与审美，还是Nano Banana Pro的精度，都展现出“六边形战士”般的全面能力。 AI浪潮已不可避免地席卷数据行业。最近几周，我们收到不少客户咨询，希望搭建“ AI 数据中台” ，并构建多个 AI 用数场景。然而深入沟通后我们发现，很多企业的基础数据状况并不乐观：信息化系统零散、缺乏统—数据底座……在这样的基础上推进AI，注定困难重重。 类似情况在行业中十分普遍。不少企业过去几年投入大量预算做AI POC（概念验证），却始终难以规模化落地。问题往往不在模型本身，而在于数据治理的根基尚未夯实。无论是AI应用、智能分析，还是行业模型微调，都离不开工业级、可复用、可信赖的数据底座——而这，正是数据治理工作的核心目标。 本文将从数据广度、数据质量、业务理解三个维度，阐述为什么“要做AI，先做数据治理”。 一、如果跳过数据治理，AI的致命缺陷 1.1 数据孤岛 AI=数据+算法+算力， AI应用必须先获取数据才能做场景化处理。真正有价值的AI，需要全方位的数据，而非零散的“单—视角 ”。 大多数企业的信息化建设是离散进行的。客户数据存储在CRM系统中，用户行为数据散落在各类日志中，财务数据则位于ERP系统内。这些数据天然形成隔离，导致唯—标识难以建立，模型无法准确关联用户在跨业务场景中的行为轨迹。 AI模型只能基于单—系统的碎片化数据进行训练，无法关联用户的跨业务行为。 这就是缺少数据治理工作支撑的典型问题：数据广度和深度不足，AI无法形成对业务的全面认知。而系统化的数据治理，正是通过“数据归集+统—建模”，为AI提供全景数据支撑： 数据归集：通过数据集成平台实现跨源数据的汇聚。 数仓规划：基于数仓规划和主题域设计，构建宽而全的数据。 龙石数据中台提供多源异构数据集成、实时与批量同步、低代码可视化配置、多协议转换、高可靠容错及信创适配能力，全面支撑高效、安全、灵活的数据集成需求，打通数据孤岛。 1.2 垃圾进、垃圾出 “垃圾进、垃圾出”由来已久，在AI时代被进—步放大，输入数据的质量，直接决定模型输出的价值。劣质数据喂给再先进的大模型，也只能产出—本正经的“高科技垃圾”。 有些企业认为： “不做数据治理，用开源ETL工具把数据抽出来不就行了？ ” 这是—个典型误区： 数据归集 ≠ 数据治理 。 某零售企业曾试图跳过数据治理，用AI助手统计销售额。由于底层数据中存在大量未剔除的测试订单，且金额单位（元/万元）混乱不统— ，AI输出了严重虚高的业绩，误导了管理层决策。 真正的数据治理除了实现数据汇聚，更关键的是构建全链路的数据治理体系，从源头保障数据质量，为AI项目规避“垃圾进、垃圾出” 的风险。 数据治理：数据标准管理、质量校验、数据血缘。 资产沉淀：指标中心、标签中心、清洗/加工流程标准化。 龙石数据中台-数据治理模块，基于智能化数据探查与大数据旁路监测技术，提供可视化规则配置、自动化质量评测（支持百亿级数据5分钟内完成千万级评测）、问题闭环管理及多维度精细化质量报告，构建不侵入原系统的统—、高效、智能的数据质量管理体系，从源头减少 “垃圾数据”的产生。 1.3 AI不懂业务 无论是中台、 BI还是AI，技术的终极目标都是服务业务。脱离业务理解的AI，即便技术指标再优秀，也难以创造实际价值。数据治理的关键作用之—，就是完成企业业务知识的数字化沉淀，为AI提供“业务认知”基础。 当业务人员用自然语言向AI提问时，使用的是业务术语；而AI底层运行依赖的是技术语言。 例如，电商运营人员问 AI ：“神仙水上周的销量是多少？ ” “神仙水”是消费者端的俗称，实际产品名是“SK-II 护肤精华露”。 如果数据中台未建立业务术语与产品之间的映射关系，AI 在底层就找不到“神仙水”这—字段，自然无法返回准确销量。 有效的数据治理不仅是提供一个技术平台，更是助力企业沉淀业务知识，构建“业务语义层”的管理工程： 业务驱动建模：模型结构与业务流程对齐。 指标/标签体系沉淀：让模型直接使用业务语义。 数据 + 业务知识的双重监督：减少“黑盒错误”。 龙石数据中台-AI用数智能体，通过汇聚多源异构数据并进行清洗、转换与集成，确保数据准确—致；同时依托元数据增强技术构建企业级知识图谱，实现数据语义标注与业务含义补全，让系统更懂业务、更准查询，为智能分析与决策提供高质量、可理解的数据基础。 二、总结 梳理下来，我们可以清晰地看到： AI与数据治理并非“替代关系”，而是 “协同共生”的关系。 AI=数据+算法+算力，数据提供 AI 学习的基础信息；算法决定加工数据的步骤，以及以产生智能的决策；算力支撑算法高效地处理海量数据。 跳过数据治理做AI的代价是惨痛的，短期看似乎节省了数据治理的成本，但长期看，每个AI项目都将陷入重复的数据清洗泥潭，架构越来越乱，维护成本呈指数级上升，最终沦为烂尾工程。 本文仅基于当前小编的行业实践和观察整理，期盼与大家一起深入探讨。龙石数据长期专注于数据管理能力的输出，我们正在将多年实战经验整理成书，新书内容即将在各大平台分享，希望能更好地助力大家的数据治理工作。
引言 在本系列前面的文章中，我们分别介绍了《什么是数据中台》和《为什么数据治理是持续性的？》 也为大家介绍了龙石数据“理采存管用”的数据治理方法论。 不少读者反馈，对“数据仓库”这个词还不太清楚：它和数据中台到底是什么关系？数据中台既然覆盖“理采存管用”，那数据仓库又在其中扮演什么角色？ 在深入探讨“理”（梳理）和“采”（采集）之前，我们可以先把“存”（存储）这个环节讨论一下。 数据中台和数据仓库的区别与联系 数据仓库为什么需要分层 业界常用的分层思路有哪些 龙石数据在实战中总结的分层模型是怎样的 一、数据中台 vs 数据仓库 数据中台：是一个承载“理采存管用”全流程的“工具与管理平台” ，核心是让数据能力可复用、可服务化。 数据仓库：是中台体系中负责 “存”的 “数据地基”。 它们的关系是： 数据经过中台的治理（理）和采集（采）后，存入数据仓库；再通过中台的调度和管理（管），最终以服务形式（用）支撑业务应用。 通俗来讲，数据中台操作数据，负责把数据治好。数据仓库存储数据，负责把数据存好。 二、数据仓库为什么一定要分层？ 数据仓库的命名源于“仓库”的概念，其设计核心在于解决数据管理中的混乱与低效问题。若将原始数据、加工数据及应用数据混杂存储于单一存储层，将导致数据定位困难、管理复杂、查询性能低下。数据仓库分层设计正是为应对这一挑战，通过结构化组织实现数据的高效治理与利用，数据仓库有以下优点： 结构清晰：像“俄罗斯套娃”一样，采用分层架构（如ODS、DWD、DWS、ADS），每层职责单一，将复杂数据流程简化为可管理的模块化处理，复杂问题简单化。 数据复用：沉淀公共指标和宽表，避免“重复造轮子”，极大提升下游开发效率。 任务解耦：复杂任务拆成多个步骤，便于运维和重跑，一层失败不影响全局。 查询加速：空间换时间，通过预处理和汇总，让上层应用（AI用数、BI、大屏）查询更快。 水平扩展：多数数仓基于分布式架构支持弹性扩容，无缝适配数据量增长场景，确保系统在高负载下保持高性能与高可用性。 三、业界主流的分层思路 3.1 经典两大流派 Inmon（自顶向下）： 主张先建企业级数据仓库（EDW），再建数据集市。 Kimball（自底向上） 主张先围绕业务过程建数据集市，再通过一致性维度整合成企业视图。 Inmon（自顶向下）就像先建一个巨型中央仓库，把所有货物标准化后，再分发给各部门小店； 而Kimball（自底向上）则像先为各部门开专业零售店，但使用统一的商品编码和会员体系，让这些店能轻松连锁成一个大超市。 前者强调整合与统一，后者追求速度与实用。现代数据平台通常结合两者思想。 3.2 当前共识：五层模型 融合了经典思想，互联网和大厂普遍采用五层结构： ODS（贴源层） 贴源层顾名思义是从源头粘贴数据，同城使用数据集成工具（ETL），将源头业务系统数据进行归集，保持数据的原貌，不做任何修改，隔离源头业务系统，不影响原系统的运行。 DWD（明细层） 当原始业务数据进入ODS层时，会对数据进行标准、治理的检查，将问题数据进行清洗、转换、去重、标准化等动作，实现数据的自优化。 DWS（服务层） DWS服务层，更多地贴近业务场景，在DWD明细层的基础上进行汇总加工和聚合计算，例如将事实表中的聚合度量值和维度表中的数据进行汇总聚合，借助DIM公共维度层的不同维度，计算分析出多维度的业务信息。 ADS（应用层） ADS层为数据产品、报表和分析服务提供可直接使用的数据，支撑业务决策的数据应用和报表分析。 DIM（维度层） DIM贯穿于ODS、DWD、DWS、ADS，确保各层数据计算中维度的一致性和准确性。提供通用的维度属性，常见的维度包括，时间维度：年、季度、月、日、时等；空间维度：物理位置、网络地址等。 五层结构相互独立又协同工作，形成高效的数据处理与分析体系，支持智能化的业务应用。 数据流向：ODS → DWD → DWS → ADS DIM 贯穿所有层次，确保维度一致性 这种架构兼顾高内聚、低耦合的数据仓库建设思路，但对团队建模能力要求较高，不少中小企业在落地时感到吃力。 四、龙石数据的实战分层模型 如果说 3.2 的五层模型是学院派，龙石数据的数仓分层就是实战派。龙石数据中台目前支持多种常见数仓，也对信创数据库（如达梦、人大金仓）做了良好适配。无论底层选Doris、StarRocks还是PostgreSQL，都将分层思想内嵌到平台中，提出一套更实战、易用、低门槛的分层模型： SRC（来源层） → ODS（贴源层） → DW（治理层） → ADS（应用层） → DS（共享层） 4.1 设计思路：让数据好管好用 1. 可行性与易用性 架构不是为了“炫技”，而是为了更快更好地实施和使用。考虑到数据工作未来会引入更多业务人员，以及“中国式速度”的要求，我们的模型必须“开箱即懂”。 2. 强化“理采”与“用”的映射： 将「SRC-来源层」纳入： 明确映射“理采存管用”中的“理”和“采”的起点，方便从源头理解数据。 将「DS-共享层」纳入： 明确映射“用”的出口，让数据提供者和消费者清晰知道“数据成品”在哪。 3. 降低“存”与“管”的门槛： 弱化DW细化分层： 将业界DWD（明细）和DWS（汇总）合并简化为「DW-治理层」。 解耦DIM维度层： 将「DIM-维度」的管理从数仓ETL中剥离，交由龙石中台的“数据标准、数据清洗”模块进行维护。 让实施人员无需精通复杂的Kimball建模，大幅降低数据工作的门槛。 4. 确保规范（前提）： 简化不等于随意。没有规范的敏捷是“灾难”。龙石模型通过中台工具将规范（如标准、质量等）“嵌入”到数据的归集、清洗、共享流程中，确保“简化”后的数据质量。 4.2 龙石五层模型详解 第 0 层：SRC（来源层） 逻辑层，不存实际数据。作用是梳理数据资产，比如“CRM系统-客户表”，这是数据治理的起点。 第 1 层：ODS（贴源层） 物理层，把源系统数据原样同步过来，只做轻微格式处理，不做业务加工。作用是可回溯、解耦业务库压力。 第 2 层：DW（治理层） 核心层，融合了明细和汇总功能。在这里执行数据清洗、标准化、关联和轻度汇总，产出可信、可复用的数据。 第 3 层：ADS（应用层） 面向具体业务场景做深度加工，比如大屏数据、报表数据、算法样本等。DW 层保持稳定，ADS 层灵活响应需求。 第 4 层：DS（共享层） 逻辑层，将 ADS 的数据包装成 API 或数据目录，供业务系统或人员直接调用。使用者无需关心数据存在哪里。 五、龙石数据的实战分层模型 数据中台是平台，数据仓库是地基。分层是为了让数据更清晰、可复用、易治理。 业界有 Inmon、Kimball 等经典思路，也有通用的五层模型，但对实施能力要求高。龙石数据在此基础上，提出更注重实战的五层模型（SRC/ODS/DW/ADS/DS），通过中台工具降低建模门槛，能更快落地“存好、管好、用好”数据的目标。 本文基于小编当前实践经验整理，数据仓库领域发展迅速，数据湖等新概念也不断涌现，但分层管理的核心思路始终未变。龙石数据长期专注于数据管理能力的输出，目前我们正在将多年实战经验整理成书，未来也会在书中更系统地介绍数据仓库相关内容，希望能更好地助力大家的数据治理工作。
在之前的文章中，我们探讨了什么是数据中台。数据中台本质上是实现数据“汇聚整合”与“服务化输出”的核心载体。
数据标准的宗旨在于为业务、技术及管理提供全方位的服务与支持。数据标准构成了实现数据驱动管理和数据驱动创新的坚实基础，数据治理必须要过数据标准管理这一关！ 一、三个方面认识数据标准 1.业务方面 数据标准是解决数据不一致、不完整、不准确等问题的关键基础。各业务部门对数据形成统一的认知和理解，消除数据的“二义性”，从而提升业务的规范性，降低因数据不一致而产生的沟通成本，进而提高业务处理效率。 2.技术方面 统一标准化的数据及其结构是信息共享的基石。标准的数据模型和标准数据元为新建系统提供有力支撑，显著提升应用系统开发及信息系统集成的实施效率。此外，数据标准为数据质量规则的建立和稽核提供了重要依据，是数据质量管理不可或缺的输入。 3.管理方面 通过对业务术语、主数据、参考数据及指标数据等定义统一的标准，为精准数据分析奠定坚实基础。统一的数据标准使业务人员能够轻松获取数据，从而为数据分析和数据挖掘创造可能。 二、数据标准的四项内容 一套完善的数据标准体系是数据管理和应用的基础，有助于实现数据底层的互联互通，提升数据的可用性，消除数据业务中的歧义。数据标准通常涵盖四个方面的内容： 1.数据模型标准 数据模型标准对每个数据元素的业务描述、数据结构、业务规则、质量规则、管理规则及采集规则进行详尽的定义，以确保数据具备可理解性、可访问性、可获取性和可用性。数据模型不仅体现了对业务的理解和定义，还能有效构建组织内部及组织间的沟通桥梁。此外，数据模型有助于识别缺失和冗余数据，并在ETL过程中精准记录数据映射。 在设计数据模型标准时，需重点考虑以下方面： 首先，是否符合设计规范，如遵循统一命名规则、确保元数据与数据的一致性； 其次，实体和属性的含义是否定义清晰且准确； 第三，术语和标准是否与实际情况相符，包括数据名称、属性和规则等； 最后，是否便于查阅，布局是否合理。 2.基础数据标准 基础数据构成系统的数据字典。在系统初始化阶段即已嵌入系统数据库，扮演着结构性和功能性支撑的角色。基础数据标准通常涉及国际标准、国家标准及行业标准。在定义数据实体或元素时，可引用相关标准，并依据组织部门实际需求持续补充完善、更新优化和积累，从而更有效地支撑业务应用开发、信息系统集成及企业数据管理。 基础数据标准包含业务、技术和管理三大属性： 业务属性:描述基础数据业务信息，供业务人员理解，包括标准主题、分类、编码、中英文名称、业务定义、规则、引用标准、来源及依据等； 技术属性:描述技术信息，支持系统实现，涉及数据类型、格式、长度、编码规则、取值范围等； 管理属性:描述管理信息，便于数据管理操作，涵盖定义者、管理者、使用者，以及版本、应用领域、使用系统等。 3.主数据与参考数据标准 主数据是用于描述核心业务实体的数据，如教师、学生、财务、教学、资产等。它具有高业务价值，能在学校内跨业务部门重复使用的“核心数据”。 参考数据则是用于将其他数据进行分类或目录整编的数据，规定了数据属性的域值范围。主数据标准包括主数据分类、主数据编码和主数据模型。主数据分类依据主数据的属性或特征，按照一定原则和方法进行区分和归类，建立相应的分类体系和排列顺序。主数据编码是为事物或概念（编码对象）赋予具有规律性、易于计算机和人识别处理的符号，形成代码元素集合。 4.指标数据标准 学校各业务域和部门设有业务指标，部分指标名称相同但业务含义不同，部分指标名称差异大却指向同一内容。若不进行指标数据标准化处理，同一指标在不同系统统计结果可能不同且难辨准确结果，构建或变更分析主题时需重新定义指标，耗费大。此外，当前大数据分析倡导业务人员自助分析，若无指标数据标准，业务人员难从不同系统获取所需数据，自助式分析难以实现，数据分析报告沦为空谈！ 指标数据标准是基于实体数据，通过增加统计维度、计算方式、分析规则等信息加工而成的数据。它对业务指标所涉及的指标项进行统一定义和管理。指标数据标准与基础数据标准相似，同样涵盖业务属性、技术属性和管理属性三部分： 业务属性:包括编码、中英文名称、主题、分类、类型、业务定义、业务规则、数据来源、取数规则、统计维度、计算公式、显示精度及相关基础数据标准等。 技术属性:涵盖来源系统、使用系统、数据源表、数据类型、度量单位、取值范围、生成频度、计算周期、取数精度等。 管理属性:涉及归口管理部门、业务和技术负责人、权限范围等。指标数据标准化适用于业务数据描述、管理、分析和可视化，促进业务部门间、业务与技术间形成共识。 三、推进数据标准的六个阶段 数据标准管理从需求发起到落地执行，通常需经过标准梳理、标准编制、标准审查、标准发布和标准贯彻及管理办法的发布六个阶段。 1.数据标准梳理 根据行业标杆经验和本校实际确定实施范围，制定数据标准优先级和难易度。梳理和定义数据标准步骤如下： 首先，依业务划分业务域，识别关键业务活动并梳理定义，处理活动输入输出的业务单据和用户视图，梳理其数据对象； 其次，分析数据对象，明确所含数据项，提炼业务域的数据指标和数据项，定义数据元标准，详尽描述业务逻辑； 第三，梳理抽象数据实体和指标的关联关系，定义数据间关系，明确数据对象的数据关系； 第四，经上述梳理分析定义，确定企业数据标准管理主体范围，基于系统逻辑归纳抽象，形成数据标准模型，此过程可能涉及数据对象的合并或拆分。 2.数据标准编制 数据标准编制是依业务需求和数据管控要求，对数据对象及其数据项明确定义的过程，涵盖数据项名称、编码、类型、长度等方面。编制可参考国际、国家或行业标准，也可依本校业务需求制定校级标准。数据标准制定分三步实施： 标准制定推进会：召集相关干系人开会推进数据标准制定，讨论标准定义，标识记录数据对象、业务术语和关键指标，得出精确定义以达成共识。该方法有助于识别对象、定义标准、提升效率，解决含义不清和歧义问题。 标准差异专项分析：先查询数据标准是否已有定义，若有则结合需求确定附加信息或修改定义，形成完整可接受的元数据定义和规范。若存在多对象标准，分析是否一致，接受、修改或创建定义以达成共识，删除多余定义。 标准影响风险评估：数据标准管理易出现新旧系统、部门和业务冲突，处理不当会致标准化失败。落地时要做好影响评估和干系人沟通，通过业务影响分析识别对业务的影响范围、程度、价值及风险，确定业务人员可接受范围和程度，为后续沟通做准备。 3.数据标准审查 审查数据标准初稿，评估其是否符合应用、管理需求及数据战略要求，直至满足发布条件。数据标准审查从需求符合性、实用性等方面综合判断是否契合需求与管理现状。 数据标准征集意见：拟定初稿广泛征集意见，降低不可用或难落地风险，包括初步培训和宣贯。征求意见设期限（依业务范围定），规定时间无意见则默认接受。 数据标准专家评审：标准制定和执行依赖专家团队，成员需深入了解业务领域，提供权威定义建议、解决歧义。执行中协调解决部门争议，完善标准体系。 4.数据标准发布 数据标准意见征集工作完成后，经过严格审查，正式发布数据标准。数据标准一旦发布，各部门及各业务系统必须严格遵循执行。对于遗留系统的存量数据，存在一定风险，应进行全面的影响评估，以妥善应对潜在问题。 5.数据标准贯彻 数据标准的贯彻是将已发布的数据标准应用于信息系统建设和改造，消除数据不一致性。将数据标准与业务系统映射，明确标准与现状关联，识别受影响应用。对于新建系统，直接采用已定义的数据标准；旧系统则建立数据映射关系、进行转换，逐步落地标准。同时，要加强对业务人员的数据标准培训和宣贯。宣贯方法有： - 文件传阅：以正式文件发布数据标准供各部门传阅，作为数据维护参考。 - 集中培训：制定培训计划，落实场地等开展宣贯培训，学员反馈心得，老师总结经验。 - 专题培训：针对不同业务领域开展专题培训，通过上机实操强化效果，推动标准落地。 6.数据标准管理办法 数据治理应结合实际情况，制定科学的数据标准管理办法。该办法旨在提供规范性的指导和约束，保障前期数据标准的顺利落地与有效执行。 一份完整的数据标准管理办法通常涵盖但不限于以下内容：数据标准的目的、适用范围及具体细则，数据标准的管理组织架构、管理流程、执行要求、考核机制以及附则等。 四、数据标准的四个常见误区 数据标准管理核心目标是确保信息系统建设和集成遵循标准，保障数据标准完整适用并有效执行。贯彻数据标准要在业务部门和信息系统逐步推行，争取管理层与系统开发部门支持配合。 1.业务驱动，不可一意孤行：数据标准源于业务、归于业务，本质是管理问题，应从业务层面解决。建立数据标准是为促进系统数据互通和业务部门共识，制定时要逐个业务域梳理，靠业务人员努力，技术工具用于固化执行。 2.循序渐进，不可急于求成：从价值链和业务流程角度分段实施数据管理标准，结合业务需求、系统改造和新系统建设契机，选合适落地范围和层次，优先解决紧迫问题，明确业务部门数据职责，确保数据与业务流程匹配。 3.动态管理，不可一劳永逸：数据标准管理要保持定义、设计和使用一致，但标准并非固定不变。新业务需增标准，无价值标准要废弃，数据变化时标准要与时俱进、有前瞻性，建立更新体系和治理平台，有序管理版本。 4.应用为王，不可断章取义：数据标准化是信息化建设基石，工作要着眼信息系统规划、应用方向和需求，做到标准统一。高质量标准化为后续分析建模奠基。建设标准要服务业务、提升效率，结合IT 系统现状，以应用为目标，以国标、行标为基础，减少对现有系统影响，确保标准实用有效，回归业务应用。 五、小结 数据治理的成功很大程度上取决于数据标准的合理性和统一实施程度。数据标准体系构建的过程是信息化部门推进技术与管理深度融合的过程，不仅考验信息化部门的专业化水平，更考验工作人员沟通协调能力。 来源（公众号）：数智转型洞察
结论很简单：场景驱动、路径正确，中台就有价值；否则，就是负担。
数据中台的“冰与火之歌” 2024年，Gartner一纸报告将数据中台推上风口浪尖：“数据中台即将消亡”的论断引发行业震荡。但另一边，大模型浪潮席卷全球，企业对数据的需求从未如此迫切。矛盾背后，是无数企业投入千万却陷入“建而不用”的困境——数据中台成了昂贵的“数据仓库”，而非业务增长的“智能引擎”。 “建数据中台易，用数据中台难。技术堆砌的‘台’若无法与业务共舞，终将沦为数字化时代的‘烂尾楼’。” 一、数据中台的困境：为何“建而不用”？ 数据中台的“建而不用”问题，本质上是技术与业务、投入与回报、组织与文化之间矛盾的集中爆发。以下是三大核心症结的深度剖析： 1. 技术至上，忽视业务场景：从“工具崇拜”到“场景荒芜” 问题本质：许多企业将数据中台视为技术能力的“军备竞赛”，盲目堆砌Hadoop、Spark、实时计算引擎等技术组件，却未回答一个根本问题：数据中台要为哪些业务场景服务？ 典型案例： 某零售集团投入800万元建设数据中台，集成了ERP、CRM、POS系统数据，但未与业务部门协同设计核心场景。结果，市场部需要实时竞品价格监控，而中台仅能提供T+1的销售报表；财务部需要动态现金流预测，中台却只输出静态财务报表。最终，业务部门仍依赖手工处理数据，中台沦为“数据展示屏”。 深层原因： • 需求错位：技术团队主导建设，缺乏业务部门的深度参与，导致“技术功能”与“业务痛点”脱钩。 • 指标割裂：未统一关键业务指标（如市场部的“销售额”包含促销赠品，财务部则剔除赠品价值），数据可信度受质疑。 行业数据： Gartner调查显示，2023年全球数据中台项目中，仅35%的企业在建设前明确定义了3个以上核心业务场景，其余项目均存在“为建而建”现象。 2. 大而全的建设模式：成本与敏捷的致命矛盾 问题本质：企业试图一次性构建覆盖全业务链的“完美中台”，却忽略了业务环境的动态变化。这种“重装坦克”式建设模式，往往导致中台尚未完工，业务需求已迭代多次。 典型案例： 某汽车制造企业耗时2年、耗资2000万元打造数据中台，原计划支持供应链优化、质量追溯等六大场景。但在建设过程中，业务需求转向新能源汽车电池回收数据追踪，原有架构因缺乏电池寿命预测模型接口，被迫追加500万元改造费用，项目ROI（投资回报率）从预期1.8骤降至0.6。 技术对比： 传统数据中台 敏捷数据架构（如Data Fabric） 数据需物理集中至中央仓库 通过虚拟化技术实现逻辑层数据整合 改造周期3-6个月 新需求响应速度可达72小时 单次改造成本50万+ 边际成本趋近于零 行业趋势： 根据Forrester报告，2024年采用Data Fabric技术的企业，数据需求响应速度平均提升67%，中台建设总成本降低42%。 3. 组织与文化断层：数据治理的“无人区” 问题本质：数据中台不仅是技术系统，更是组织变革工程。若缺乏跨部门协同机制和数据文化，中台将陷入“有工具无人用”的窘境。 典型案例： 某保险公司部署了自动化数据治理平台，但因未设立专门的数据治理团队，业务部门仍沿用“Excel+邮件”的传统方式： • 销售部手动导出客户数据，导致隐私泄露风险； • 风控部因数据更新延迟，误批高风险保单； • 最终，数据中台因“数据质量差”被业务部门弃用。 组织短板： • 权责模糊：无明确的数据Owner制度，数据质量问题互相推诿； • 能力断层：业务人员缺乏数据素养，无法自主使用中台工具； • 激励缺失：KPI体系未纳入数据贡献度指标，业务部门缺乏参与动力。 调研数据： IDC研究指出，在数据中台失败案例中，68%的企业未建立跨部门数据治理委员会，82%的企业未对业务人员进行系统化数据培训。 二、破局之道：从“建好”到“用好”的三大策略 要让数据中台真正成为业务增长的引擎，需从“场景驱动、技术重构、组织再造”三方面突破： 1. 以业务场景为锚点：从“大而全”到“小而美” 核心逻辑：数据中台的价值必须通过具体业务场景兑现。企业应选择“高价值、易落地”的场景切入，通过快速迭代验证中台价值。 方法论实践： 以下是基于“以业务场景为锚点”方法论实践的 设计，分为 场景筛选矩阵 和 敏捷实施流程 两部分： 1. 场景筛选矩阵（四象限分析法） 2. 敏捷实施流程 • 核心步骤： 1. 需求众包：由业务部门投票决定优先级，确保“为业务而建”； 2. MVP开发：快速交付最小可用功能（如库存预警看板）； 3. 快速验证：小范围试点验证效果，避免大规模失败风险； 4. 规模化扩展：验证成功后复制推广，形成滚雪球效应。 • 成功标志：最终需达成可量化的业务指标（如缺货率下降20%）。 成功案例： 某连锁餐饮企业以“菜品销量预测”为突破口，通过数据中台整合天气、节假日、门店位置数据，结合机器学习算法，将食材损耗率从12%降至6%，单店月均节省成本3万元。项目仅用6周上线，ROI达3.5倍。 2. 技术融合：构建“AI+数据中台”的智能生态 技术升级路径： • 阶段1：数据虚拟化 采用Data Fabric技术，在不迁移数据的前提下实现跨系统联合分析。例如，某跨国物流企业通过Denodo平台，将分布在20个国家/地区的订单数据虚拟集成，跨境合规查询效率提升90%。 • 阶段2：AI原生设计 将大模型嵌入数据加工全流程： • 数据准备：用LLM（如GPT-4）自动解析非结构化数据（如客服录音转文本并打标签）； • 数据分析：通过AutoML工具（如H2O.ai）让业务人员自助建模； • 数据服务：用AI生成动态数据API（如根据用户画像实时推荐商品）。 典型案例： 某银行在数据中台中部署AI助手： • 客户经理输入“某企业近三年营收趋势”，系统自动生成SQL查询并可视化； • 风控模型迭代周期从2周缩短至2天； • 数据服务调用量提升300%，人力成本降低40%。 3. 组织变革：打造“三位一体”的数据运营体系 组织设计框架： • 顶层设计：由CEO挂帅的“数据管理委员会”，制定中台战略并协调资源； • 中层执行：设立“数据产品经理+数据工程师+数据治理专家”铁三角； • 基层赋能：通过低代码平台（如Power BI、QuickSight）让业务人员自助分析。 文化塑造关键动作： • 数据民主化：建立企业级数据目录，业务部门可按权限自助查询； • 激励制度化：将数据质量贡献度纳入部门KPI（如市场部需维护客户画像完整度）； • 培训体系化：开设“数据工作坊”，教业务人员用自然语言生成SQL查询。 成功案例： 某快消企业推行“数据全民化”运动： • 所有员工需通过“数据素养认证考试”； • 每月评选“数据之星”，获奖者可获额外奖金； • 一年内，业务部门自助分析比例从15%提升至70%，IT部门得以聚焦高价值开发任务。 三、未来展望：数据中台的“第二曲线” 随着数据编织、AI代理等技术的成熟，数据中台正从“集中式架构”转向“分布式智能网络”。企业需拥抱两大趋势： 1. 逻辑化与虚拟化：通过数据编织实现“按需集成”，避免物理搬运的合规与成本风险。 2. AI原生中台：将大模型作为数据加工的“协作者”，从ETL到分析全程智能化，例如自动生成SQL代码、动态优化数据管道。 “数据中台的终点不是技术，而是‘人机协同’的智慧涌现。” 让数据中台“活”起来的终极答案 数据中台的命运，不取决于技术是否先进，而在于能否成为业务的“共生体”。正如用友网络岳昆所言：“数据中台是‘幕后英雄’，它的价值在于支撑业务创新，而非独立存在。” 行动倡议： • 如果你是决策者，请反问：“我的业务需要数据中台解决什么具体问题？” • 如果你是执行者，请牢记：“从一个小场景开始，让数据说话，而非让PPT画饼。” “建中台易，用中台难；唯有以终为始，方能让数据从‘泥沼’变‘金矿’。” 来源（公众号）：AI数据推进器
数据中台、数据仓库、数据治理和主数据这些概念对于很多人来说仍显得抽象。用一些通俗的语言和生活中的比喻，深入解析这些关键概念。 一、数据中台：数据的“中央厨房” 想象一下，你是一家大型餐厅的厨师长，每天需要处理从不同供应商那里采购的多种食材。为了确保食材的新鲜、卫生与高效利用，建立一个中央厨房就显得尤为重要。这个中央厨房的角色就是数据中台在企业中扮演的角色。 数据中台整合来自不同业务部门、系统和渠道的数据，对其进行清洗、加工和标准化处理，然后再将处理后的数据提供给业务部门使用。就像中央厨房确保食材的质量和一致性，数据中台则确保数据的质量、一致性和可用性，从而更好地支持企业的决策和运营。 数据中台不等于大数据平台，数据中台的核心工作也并不是将企业的数据全部收集起来做汇总就够了。 数据中台的使命是利用大数据技术、通过全局规划来治理好企业的数据资产，让数据使用者能随时随地获取到可靠的数据。因此，数据中台一旦建成并得以持续运营，其价值将随着时间的推移将呈指数级增长。 数据中台建设是一个宏大的工程，涉及整体规划、组织搭建、中台落地与运营等方方面面的工作，本节重点从物理形态上讲述企业的数据中台应该如何搭建。一般来讲，企业的数据中台在物理形态上分为三个大层：工具平台层、数据资产层和数据应用层。 1.1 工具平台层 工具平台层是数据中台的载体，包含大数据处理的基础能力技术，如集数据采集、数据存储、数据计算、数据安全等于一体的大数据平台；还包含建设数据中台的一系列工具，如离线或实时数据研发 工具、数据联通工具、标签计算工具、算法平台工具、数据服务工具及自助分析工具。 以上工具集基本覆盖了数据中台的数据加工过程。 1.2 数据资产层 数据资产层是数据中台的核心层，总体来讲，可以划分为主题域模型区、标签模型区和算法模型区。 ①主题域模型 主题域模型是指面向业务分析，将业务过程或维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件，如订单、合同、营销等。 为了保障整个体系的生命力，主题域即数据域需要抽象提炼，并且长期维护和更新，但是不轻易变动。在划分数据域时，既要涵盖当前所有业务的需求，又要保证新业务能够无影响地被包含进已有的数据域中或者很容易扩展新的数据域. ②标签模型 标签模型的设计与主题域模型方法大同小异，同样需要结合业务过程进行设计，需要充分理解业务过程。 标签一般会涉及企业经营过程中的实体对象，如会员、商品、门店、经销商等。这些主体一般来说都穿插在各个业务流程中，比如会员一般都穿插在关注、注册、浏览、下单、评价、服务等环节。那么在设计标签的时候就需要充分理解这些业务流程，在流程中发现标签的应用点，结合这些应用点来搭建企业的标签体系。标签模型按计算模式一般分为客观标签和主观标签。 设计标签模型时非常关键的要素是标签模型一定要具有可扩展性。毕竟标签这种数据资产是需要持续运营的，也是有生命周期的，在运营的过程中随时可能增加新的标签。 ③算法模型 算法模型更加贴近业务场景。在设计算法模型的时候要反复推演算法模型使用的场景，包括模型的冷启动等问题。整个模型搭建过程包含定场景、数据源准备、特征工程、模型设计、模型训练、正式上线、参数调整7个环节。 以新零售企业为例，常用的机器学习算法有决策树、神经网络、关联规则、聚类、贝叶斯、支持向量机等。这些算法已经非常成熟，可以用来实现商品个性化推荐、销量预测、流失预测、商品组货优化等新零售场景的算法模型。 1.3 数据应用层 数据应用层严格来说不属于数据中台的范畴，但数据中台的使命就是为业务赋能，几乎所有企业在建设数据中台的同时都已规划好数据应用。数据应用可按数据使用场景来划分为以下多个使用领域：分析与决策应用、标签应用、智能应用。 二、数据仓库：数据的“图书馆” 假设你是一位图书馆管理员，每天的职责是管理和维护图书馆中的成千上万本书。你必须确保每本书按照类别、作者、出版日期整齐有序地摆放，以方便读者查找和借阅。数据仓库在企业中的作用就像这个图书馆。它存储了大量历史数据和结构化数据，并按照一定的规则和格式进行组织。与数据中台不同，数据仓库更注重数据的长期保存和查询分析，提供强大的数据查询和分析能力，帮助企业深入了解市场、客户和业务流程，从而发现潜在的机会和风险。 一般来说，数据仓库是一个面向主题的、集成的、相对稳定的，并反映历史变化的数据集合，它主要用于支撑管理人员的决策过程。 “面向主题”：意味着数据仓库是围绕企业的具体业务需求进行构建的，旨在提升管理效率； “集成”：则是指它能够将来自不同平台的数据进行汇总，打破数据孤岛，同时在整合过程中实现数据治理和编码的标准化； “相对稳定”：强调的是数据仓库不会直接连接到业务系统，而是通过从业务系统中提取数据来工作，以避免对业务系统性能造成影响； “反映历史变化”：则指的是数据仓库能够存储并反映业务系统的历史数据，为未来的大数据挖掘与分析提供重要依据。 接下来，我们明确“数仓”的概念： 数仓，即数据仓库，是企业决策支持体系中的核心组成部分。它从管理需求出发，整合各业务系统的数据资源，通过数据处理工具生成数据仓库，并应用于企业的各个业务领域。数据仓库的运用主要聚焦于优化企业的业务流程、监控时间、成本、质量等关键指标，从而助力企业实现更高效、更精准的管理决策。 三、数据治理：数据的“交警” 城市交通中，交警的职责是维护交通秩序，确保车辆和行人遵循交通规则，防止交通拥堵和事故发生。在数据世界中，数据治理就好比这样的交警。数据治理是对数据进行全面管理和规范的过程，确保数据的准确性、一致性、安全性和可用性，同时防止数据滥用和泄露。数据治理还负责制定数据管理的规章制度，监督数据的采集、存储、处理和使用过程，确保数据在整个生命周期中都得到妥善管理。 数据治理体系内容从两个维度来看： 1）数据治理难点痛点：数据脉络不清晰、数据汇聚能力不足、数据管控能力薄弱、数据治理体系不完善、开放形式不完善。 2）数据治理5个核心：理、聚、管、治、用。 数据治理是企业对数据资产管理行使权力和控制的活动集合（包括计划、监督和执行)，它是管理企业数据资源的一种方式、方法，旨在确保数据的质量、安全、合规和有效性。数据治理是企业实现数据战略的基础，是一个管理体系，包括组织、制度、流程和工具。 数据治理是一套复杂的管理体系，它无法通过单一的工具或产品来实现。数据的生命周期包含了源头、处理和消费这三个阶段，数据的问题也可能会出现在这三个环节中。 例如在数据源头环节，用户录入数据的规范性存在问题，导致了最终数据消费环节的数据质量低。这些表象问题的根源，可能来自于业务系统用户交互设计，乃至是底层数据库表结构设计上的缺陷。想要解决这些表象的问题，就需要解决深层次的信息化业务系统开发以及数据库表约束设计等问题。 例如为了保证用户录入数据的准确性，有三种方式去设计业务系统：其一是设计前端的检验验证，避免用户做出相同的选择；其二是通过程序编写过滤判断的逻辑，筛除掉前端误入的数据，作为第二层验证；其三是通过建立约束条件，例如唯一性约束、检测约束等等来控制数据录入准确性。 因此，企业的数据治理远非使用一款单一的工具或产品就可以实现的，它是需要回到源头，对企业的组织、流程制度、业务系统、底层架构等多个方面进行排查和重构的，它是一套复杂的管理体系。 四、主数据：数据的“身份证” 最后，我们来谈谈主数据。每个人都有自己的身份证，它是个人身份的证明。在数据世界中，主数据就像是数据的“身份证”。主数据是企业内部最关键、最核心的数据，描述了企业的核心业务实体，如客户、产品、供应商等。主数据具有唯一性和权威性，是企业内部各部门和系统之间共享和交换数据的基础。通过管理和维护好主数据，企业可以确保数据的一致性和准确性，从而提高业务处理效率和决策质量。 主数据是指满足跨部门业务协同需要的，反映核心业务实体状态属性的基础信息。举个例子，公司的员工信息，存在于很多业务系统里，比如人力系统、财务系统、OA系统，以及考勤系统等，但每个系统所需要的信息可能不一样，财务系统需要员工开放信息，比如从哪个银行开户，账号是什么，这样方便打款；人力系统可能只是需要员工的一些入职信息。这样的员工信息就属于主数据，它在很多企业业务系统被使用，同时还能反映这个员工本身的一些属性。类比下，还有产品、物料、客商、客户、供应商等主数据。 哪些数据是主数据？ 一家企业不只有主数据，还有一些其他数据，这里有一个金字塔结构的企业数据模型，包括关键的基础数据、主数据、业务数据、报表数据。 基础数据可以理解为基本不会发生什么变化的，比如国家货币计量单位，其他维表数据等，其数据就是一些取值范围，也称其为参考数据；主数据就是长期稳定的，能被多个系统使用的，比如组织机构人员、客商等；业务数据是指一些业务交易系统所产生的数据，包括订单的记录、还有一些考勤记录等，与主数据捆绑的比较紧；报表数据是基于下面三类数据做的一些分析呈现，报表数据的主要作用是通过结果呈现来做预测工作。 主数据、业务数据与元数据的区别 如图所示，表头就是元数据，这些字段本身描述了字段的一些属性信息；而主数据其实就是这样的一条记录，这条记录可以划分为两部分，一部分是主数据，描述核心业务实体属性的数据，另外一部分就是主数据在业务交易过程中由系统产生的数据，比如这块的订单数据就是业务数据。总的来说，所有这些数据作为企业的一部分，只要能产生价值，它都可以称之为数据资产，能去支撑企业上层的生产、财务、项目管理等。 主数据的4个特性 （1）唯一性：在一个系统、一个平台甚至一个企业范围内同一主数据要求具有唯一的识别标志（代码、名称、特征描述等），用以明确区分业务对象、业务范围和业务的具体细节。 （2）共享性：主数据特征会被作为业务流程的判断条件和数据分析的具体维度层次，因此需保证主数据的关键特征在不同应用、不同系统中的高度一致共享，形成统一规范 。 （3）稳定性：主数据作为用来描述业务操作对象的关键信息，在业务过程中其识别信息和关键的特征会被交易过程中产生的数据继承、引用、复制，但主数据本身的属性通常不会随交易的过程所被修改。 （4）有效性：只要该主数据所代表的业务对象仍然在市场中继续存在或仍具有意义，则该主数据就需要在系统中继续保持其有效性，通常贯穿该业务对象在市场上的整个生命周期甚至更长。 因此： 对于大数据平台来说，主数据是非常重要的一类数据，几乎出现在所有的数据处理和分析中，具体到批处理和实时处理又有所不同。 对于批处理来说： 主数据可以同步自主数据管理系统的数据库，在数仓（数据仓库）体系下，几乎所有的主数据都是维度数据，需要建立相应的维度表以支撑业务查询和分析； 对于实时处理来说： 在各种流式计算的过程中也需要获取主数据进行关联处理，而实时处理要求主数据的获取也必须是实时的，这对系统的架构设计提出了挑战。如果原始的主数据管理系统对外提供了获取主数据的 API，对于普通的应用系统这是很有利的条件，它们可直接通过API 实时获得主数据。但是对于大数据系统来说，情况就不那么乐观了，因为大数据处理过程中的巨大吞吐量和流计算处理中对主数据的使用频率都远远超过一般的应用系统。如果大数据平台通过主数据管理系统的API 获取主数据，无论是从并发压力还是从响应的及时性上都可能无法满足要求，还有可能给主数据管理系统带来过大的负载，导致其响应缓慢甚至宥机。 为满足实时计算对主数据的需求，有两种可选的技术方案。 （1）方案一： 如果主数据体量不大，变更也不频繁，可以考虑将这些数据通过 API 读取到大数据工作节点的内存中，在数据处理过程中直接使用，然后周期性地从主数据管理系统同步最新状态的主数据。 （2）方案二： 改造主数据管理系统，引入内存数据库，如Redis, 针对所有主数据，除常规 持久化的业务数据库外，再配备一个内存数据库的副本，将这个内存数据库开放给大数据平台使用。 方案一的优点是架构简单，易于实现，但是对主数据有预设条件，不能成为一种广泛使用的方案。方案二是一套很完备的技术方案，可以满足各种主数据获取需求，代价是架构比较复杂，如果企业正在构建的是一整套大数据平台，方案二是值得一试的， 从技术上讲，主数据管理系统是一个相对传统的Web 应用，负责维护主数据的增删查改，同时对外提供获取主数据的 API, 对于大数据平台，最好提供以内存数据库为依托的数据读取服务。综合这些因素，企业在建设大数据平台时应该结合现状灵活地选择方案。 五、定位与差异：协同作战的团队成员 通过以上的比喻，我们可以更好地理解这些概念的定位和差异。数据中台作为数据的“中央厨房”，负责数据的整合和加工；数据仓库作为数据的“图书馆”，负责数据的存储和查询分析；数据治理作为数据的“交警”，确保数据的规范和安全；而主数据作为数据的“身份证”，确保数据的权威性和一致性。这些概念在企业中相互协作，共同构成完整的数据管理体系。就像一支协同作战的团队，数据中台负责调度和整合数据资源，数据仓库提供数据存储和查询支持，数据治理确保数据的安全和规范，而主数据确保数据的准确性和一致性。这个团队共同为企业提供了强大的数据支持，帮助企业更好地应对市场挑战和抓住机遇。 来源（公众号）：数据学堂
文 | 中国科学院大学经济与管理学院教授 孙毅 建立健全合规高效的数据流通体系是推进数据要素市场化的必然要求，也是推动数据要素以较低的交易成本实现跨主体流通、多场景复用，在更大范围内与其他要素协同、与不同种类数据融合，促进数据要素价值化过程、放大数据要素价值化效应的重要举措。 近日，国家发展改革委、国家数据局等部门联合印发《关于完善数据流通安全治理 更好促进数据要素市场化价值化的实施方案》（以下简称《方案》），针对数据流通安全治理中存在的标准不明、责任不清、制度不健全等突出问题，制定了科学规范、务实可行的政策举措，以期有效降低数据流通环节的安全治理成本，以成本最小化实现安全最优化，营造鼓励创新、包容创新、让企业轻装上阵的数据产业发展环境，培育充满活力、充满信心、充满韧性的市场主体，开创以良法善治统筹发展和安全、平衡活力和秩序的数据要素市场化价值化新局面。 《方案》不新增数据安全责任义务，不新设数据安全治理条款，旨在细化现行法律法规的原则性要求，打消市场主体顾虑，降低市场主体负担。在《网络安全法》《数据安全法》《个人信息保护法》《关键信息基础设施安全保护条例》《网络数据安全管理条例》（以下简称“三法两条例”）的总体框架下，《方案》聚焦数据流通环节的痛点堵点问题，将“三法两条例”的原则性要求细化为数据流通中的具体举措，坚持以促进数据要素流通使用作为安全治理的出发点和落脚点，通过总结安全可信、行之有效、具有共识的安全治理实践经验，健全数据流通安全治理体系，提升数据流通安全治理的稳定性和可预期性，实现高质量发展和高水平安全良性互动。例如，依照《个人信息保护法》规定，在广告投放、精准推荐、用户画像等业务场景中，企业在跨平台交互、开发个人数据时，需要对个人信息进行匿名化处理，以保障个人权益、保护个人隐私。 业界普遍反映，由于个人信息匿名化处理缺乏认定标准，企业在开展相关业务时普遍存在安全合规顾虑，数据安全治理投入因标准缺失导致负担过重。事实上，关于匿名化的标准问题，业界存在一些具有共识、验证可行的做法，如传递非永久性设备标识符、使用联邦学习和隐私计算技术进行联合数据开发、采用聚合数据进行群体统计分析等。针对这些现实问题和迫切需求，《方案》针对个人数据流通保障，在《个人信息保护法》的原则要求下，提出了制定个人信息匿名化相关标准规范，明确匿名化操作规范、技术指标和流通环境要求，以及鼓励采用国家网络身份认证公共服务等多种方式，强化个人信息保护。这些政策举措将为个人数据流通安全治理提供标准和依据，有效打消市场主体安全合规顾虑，减轻安全治理投入负担。 《方案》不搞叠床架屋，不求面面俱到，旨在找出“真问题”、提出“实举措”，强化问题导向，突出可操作性，力求务实管用。针对企业数据、公共数据和个人数据在流通环节中的场景化问题，《方案》立足行业需求、总结行业经验，提炼出针对性举措。 例如，政务数据共享过程涉及多元主体，各参与主体的责任边界缺少清晰界定，出现安全问题时“责任不随数据流通而流转”，政府部门作为政务数据供给源头单位往往承担兜底责任，从而导致政务数据“不愿共享”“不敢共享”。相关政府部门普遍反映希望能够明确政务数据共享的权利责任边界，从而更好地促进政务数据流通使用。 针对上述问题，《方案》依照《政务信息资源共享管理暂行办法》，在政务数据提供方“谁主管、谁提供、谁负责”和政务数据接收方“谁经手、谁使用、谁管理、谁负责”的原则基础上，明确提出要区分数据提供前和数据接收后的安全管理责任。 特别是针对政务数据提供方，要求在数据提供前明确政务数据共享范围、用途、条件，探索建立数据接收方数据安全管理风险评估制度，保障政务数据提供方在履行好事前安全管理责任的前提下不再承担兜底责任。上述举措将建立健全政务数据流通安全合规责任划分机制，有效减轻政务数据共享的安全合规负担，从而提升政务数据共享水平，促进政务数据价值释放。 贯彻落实《方案》的关键在于降低数据流通安全治理成本。 一是要逐步制定完善数据流通安全合规细则与标准，降低制度性交易成本。要加强调研征集新场景、新问题和新诉求，总结提炼有需求、有共识、有效果的经验做法，不断完善数据流通安全治理体系，提升数据流通安全治理的针对性和可操作性，降低因政策要求不明确、不具体、不落地带来制度性交易成本。 二是要加大数据安全治理技术和产品服务研发支持，降低数据流通安全治理的创新成本。加大可信数据空间、区块链、隐私保护计算、匿名化等技术研发和应用推广支持力度，完善引导企业加大技术创新投入的机制，培育一批面向数据流通安全治理的技术创新型企业，壮大数据流通安全治理服务规模，推动数据流通安全应用产品创新，全面提升数据流通安全治理领域企业创新能力。 三是要积极探索数据流通安全治理的创新模式，降低数据流通安全治理的运营成本。采取差异化监管措施，在保障安全的前提下降低数据流通安全治理的行政负担；探索建立数据流通安全保险机制，利用市场化手段合理分散企业风险成本；鼓励各级政府、大型企业面向中小型企业提供有助于提升企业风控能力、降低企业安全成本的数据流通安全治理服务，推动具备条件的部门和地区建立中小企业数据流通安全补贴制度，降低中小企业参与数据流通的合规成本。 四是加强《方案》的政策宣贯，降低数据流通治理的协调沟通成本。强化《方案》出台背景、原则、目标等方面的解读和宣贯，凝聚各方共识、稳定市场预期，避免因理解不深入、认知不统一、配合不到位带来的沟通协调成本，群策群力建立健全数据流通安全治理体系，更好促进数据要素市场化价值化。 来源（公众号）：北京数据
