| |
|
|
|
| 知识库 -> 科技 -> 为什么数据治理这么重要？ -> 正文阅读 |
|
|
[科技]为什么数据治理这么重要？ |
| [收藏本文] 【下载本文】 |
|
原文：为什么数据治理这么重要？北大教授万字长文终于讲清楚了 |
|
2019年，深圳某区住建局。 600万，砸进了一个数据治理项目。 验收那天，专家看了半小时PPT，签字，通过。 系统上线。 然后——没人用。 数据躺在那里，格式还是老样子，科室之间该不共享还是不共享。每年20万运维费照交，系统就在服务器里躺着。 600万，换来一个”我们做过数据治理”的交代。 你是不是觉得这故事很眼熟？ 说实话，在政府信息化这个圈子里，这种事太普遍了。大部分数据治理项目，最后都是这个结局——验收即死亡。 但今天我不想讲”系统建了没人用”这个老话题。 我想讲的是：这些脏活累活，为什么始终没人愿意做？ 先说一个数据。 2023年，全国数据产存转化率只有2.9%。 什么意思？你辛辛苦苦采集、存储、管理的数据，真正被用起来的，不到3%。海量数据，源头即弃。 这个数字来自《全国数据资源调查报告（2023年）》，国家数据局2024年5月发布的。 我第一次看到的时候愣了半天——我们天天喊”数据资产”，结果90%以上的数据，从生下来就没被用过。 但你仔细想想，不奇怪。 因为数据的脏活累活，实在太苦了。 第一部分：数据分散三处，打通比新建难十倍 我在深圳参与过一个气象数据治理项目，3000万，总架构师。 拿到这个项目的时候，我以为最难的是技术方案。 结果发现，最难的是—— 气象数据分布在三个地方。 政务云一批，政务外网一批，自己的机房还有一批。 三个地方，三套标准，三个安全域。 你不能简单地把它们搬到一起，得一套一套地打通。光存储方案，我们就改了六版。 为什么？ 政务云那边说：数据出去可以，但必须走专用通道，你们先把方案拿给我们审批。 政务外网那边说：专用通道？我们外网没有这个接口，你们得自己解决。 自己机房那边说：我们是自有机房，数据安全我们自己负责，凭什么让你们统一管？ 三个部门，三种逻辑，三套利益。 你说服了这个科室，那个科室又提出新要求。 有一回，政务云的负责人直接跟我说：张工，你们这个方案，我们不签。 我说：为什么不签？ 他说：你们没按我们的格式来。 我说：我们按国标格式走的，你们这个是企业标准，比国标还严。 他说：那是你们的事。反正我们这关过不了。 当场僵住。 最后怎么解决的？ 不是靠技术，是靠领导拍桌子。分管副市长开了一次专题会，三个部门当场签了责任书，这才把路铺平。 你问我这中间花了多少时间？ 四个月。 四个月，就为了打通三个系统的数据。 第二部分：”服务”还是”软件开发”，傻傻分不清 做政府项目，有个特别奇葩的坑—— 你以为写的是”数据治理”，按”服务”的方式报预算。 结果申报上去，政数局直接打回来。 那天我接的电话，对方语气很平静，但每个字都像刀子： “张工，你们这个项目，我们看了一晚上。有个问题——你们这里既有数据治理服务，又有数据处理工具开发。这两个东西，不能放在一个项目里报。” 我说：”但我们这个本质上就是一个数据治理项目啊，工具只是辅助手段。” 他说：”那你们那个数据清洗工具，算不算软件开发？算的话，你就得按软件工程的规范来，写需求规格说明书、测试报告、用户手册。这些你们都有吗？” 我愣了一下。 我说：”……这个，我们当时没按这个模板来准备。” 他说：”那你们就补。补完了我们再上会。” 啪，挂了。 我当时坐在办公室里，盯着电脑屏幕，脑子里一片空白。 补？那就意味着整个项目方案重写。预算得重新算，评审得重新过，时间节点得重新排。 我抬头看了看窗外，天已经黑了。 旁边同事问我：怎么了？ 我说：两个字，打回来。 他问：哪两个字？ 我说：重写。 后来怎么过的？ 是把整个项目拆成了两个子项目，一个走服务，一个走软件开发。 一个项目变成两个项目，两套流程，两套评审，两次上会。 两个月，就耗在这件事上。 真正写代码的时间可能只占20%，剩下80%的时间，我在跟人解释”为什么这个项目需要两种不同的申报方式”。 有一天下班，我跟同事吐槽：政府项目最大的问题就是，定义权不在你手里。 他说：何止定义权，解释权都不在你手里。 我觉得他说得对。 第三部分：分类分级，没有标准可依 气象数据是敏感数据，涉及公共安全和个人隐私。 按规定，这些数据应该做分类分级管理。 但是—— 分类分级的标准呢？ 国家气象局出了一份讨论稿。 讨论稿，不是正式文件。 没有正式标准，就没有合规依据。你说你这个数据是”一般数据”，凭什么？依据是什么？验收的时候拿什么给专家看？ 没办法。 最要命的是，你自己定的标准，专家不认。 专家说：你这个分级依据是什么？ 你说：参照国家气象局的标准。 专家说：国家气象局哪个文件？ 你说：讨论稿。 专家说：讨论稿不是正式文件，不能作为依据。 当场卡住。 你说：那能不能用行业惯例？ 专家说：行业惯例不具备法律效力。 你还能说什么？ 所以项目里专门加了一部分：研究气象数据分类分级的方法论。 听起来很专业，说白了就是—— 花几十万，去研究”到底应该怎么分级”。 这不是数据治理，这是学术研究。 但你没有选择。没有标准，你就得自己造标准。 有一句话怎么说来着—— “在沙滩上盖房子，最后还得自己挖沙子。” 第四部分：BIM平台与16个系统对接 深圳BIM平台，1个多亿。 这个项目里有一个特别有意思的任务—— 要跟16个系统做对接。 什么系统？智慧住建、智慧城管、智慧应急、智慧交通…… 每个系统都有自己的数据格式，自己的接口标准，自己的安全要求。 你得一家一家地去协调。 人家凭什么配合你？你能给他什么好处？数据格式不兼容怎么办？联调测试的时候出了问题谁负责？ 有一家单位的信息化负责人直接跟我说：张工，你们这个接口文档，我们看了，看不懂。 我说：这是行业标准格式。 他说：行业标准我们用不上，我们系统是定制的，你们得按我们的格式来。 我说：按你们格式来，我们的工作量要增加三倍。 他说：那是你们的事。反正我们这边没有额外的人力配合你们。 当场僵住。 后来怎么推下去的？ 项目负责人亲自出面，一家一家地拜访，一家一家地解释。 请吃饭，喝茶，送资料，反复沟通。 这才勉强把进度推起来。 你知道这中间有多少扯皮的事？ 三天三夜讲不完。 第五部分：市政府突然加了一个任务 你以为做完一个项目规划，万事俱备了。 然后市政府来了一个通知—— “气象公共数据授权运营试点场景建设”，交给你们一并完成。 这是政治任务，不能拒绝。 但这个任务，原本不在你的项目规划里。 没有预算，没有人员，没有时间。 你得硬着头皮接下来。 当时我的第一反应是：这不是我们能决定的事。 但上面说：这是市里定的，你们配合就行了。 配合？ 项目边界不断扩大，工期不断压缩，资源不断吃紧。 原本承诺的交付节点，推迟了三个月。 原本可以做得精细的地方，只能草草了事。 有一段时间，整个团队天天加班到晚上十点。 不是技术问题，不是方案问题，是政治任务突然砸下来，你没有拒绝的权利。 这不是执行的问题。 这是项目管理里最难受的一种情况——范围蔓延，而且是自上而下的范围蔓延。 有一句话说得好： “在体制内做事，最难的不是怎么做，而是做完之后发现，需求变了。” 第六部分：为什么没人愿意做这些事？ 说了这么多，你会发现一个规律—— 这些脏活累活，有一个共同特点： 不出成绩，但特别容易背锅。 数据治理做好了，没人在乎，因为”本来就该这样”。 数据治理做砸了，全都知道，因为系统崩了，业务停了，投诉来了。 而且，这些工作的成果，很难量化。 你说我花了半年时间，打通了三个系统的数据接口—— 领导问：有什么用？ 你怎么说？说”以后查数据快一点”？ 但”快一点”怎么算绩效？怎么写进验收报告？ 所以聪明人的选择是：少做这些事，多做那些看得见、摸得着、能写进PPT的东西。 有一句话说得很扎心： “在政府信息化这个行当里，最受欢迎的不是解决问题的人，是制造新项目的人。” 因为新项目意味着新的预算、新的考核、新的机会。 而数据治理？那是打基础。基础谁看得见？ 第七部分：脏活，才是真正的壁垒 但我想说一个反直觉的观点—— 正因为这些事没人愿意做，所以它们才是真正的壁垒。 大家都在追热点、追风口、追新技术。 大模型火了，全都去做大模型。 智能体火了，全都去做智能体。 但真正底层的、支撑这些上层应用的数据治理、系统对接、标准统一—— 愿意做的人，少之又少。 为什么？ 因为太苦了。太慢了。太不性感了。 没有爆款，没有融资，没有媒体报道。 只有无尽的协调会、无尽的公文、无尽的解释。 但也正因为如此—— 谁真正把脏活做扎实了，谁就建立了真正的护城河。 你的数据质量比别人好，你的系统比别人稳定，你的数据治理经验比别人丰富—— 这些东西，不是花几十万买一套系统就能解决的。 是需要时间、需要踩坑、需要交学费，慢慢磨出来的。 有一句话说得好： “潮水退去的时候，才知道谁在裸泳。但脏活做扎实的人，早就建好了防波堤。” 还有一句： “大家都在盖楼的时候，你去打地基。等楼盖完了，发现地基最值钱的，只有你。” 前几天有个同行跟我聊，说他想转行做AI。 我说：AI是好赛道，但你知道AI落地最缺什么吗？ 不是算法，不是算力，是干净的数据、成熟的场景、懂行的团队。 这些东西从哪来？ 从脏活里来。 从那些没人愿意做的数据清洗、系统对接、标准制定里来。 你没有这些东西，AI就是空中楼阁。 有了这些东西，你才有资格谈AI。 所以—— 如果你正在做一个看起来特别土、特别慢、特别不出成绩的数据治理项目， 别急着抱怨。 把它做好。 这可能才是你未来最大的资本。 作者：17年数字政府从业者，踩过的坑比走过的路多。 你的项目里，有什么特别难推动的脏活？欢迎在评论区聊聊。 相关阅读： 为什么政府信息化项目99%都是”表演式使用”？— 交付即死亡的全景拆解政府手里的数据原来可以换钱 — 数据要素市场化到底怎么回事 欢迎加入圈子：数字治理实践圈 — 政府信息化实战交流，不灌鸡汤，只聊真实经历。 数据来源：《全国数据资源调查报告（2023年）》，国家数据局，2024年5月。 |
|
什么是数据治理？ 参考原文链接： 数据治理是指从使用零散数据变为使用统一数据、从具有很少或没有组织流程到企业范围内的综合数据管控、从数据混乱状况到数据井井有条的一个过程。数据治理是指从使用零散数据变为使用统一数据、从具有很少或没有组织流程到企业范围内的综合数据管控、从数据混乱状况到数据井井有条的一个过程。 从范围来讲，数据治理涵盖了从前端业务系统、后端业务数据库再到业务终端的数据分析，从源头到终端再回到源头，形成的一个闭环负反馈系统。从目的来讲，数据治理就是要对数据的获取、处理和使用进行监督管理。 是以服务组织战略目标为基本原则，通过组织成员的协同努力，流程制度的制定，以及数据资产的梳理、采集清洗、结构化存储、可视化管理和多维度分析，实现数据资产价值获取、业务模式创新和经营风险控制的过程。是一个持续性的服务，而不是一个有着明确范围的一锤子买卖。 为什么要实施数据治理？经过 30 年的信息化建设，企业和政府部门都围绕着业务需求建设了众多的业务系统，从而导致数据的种类和数量大增，看似积累了众多的数据资产，实则在需要使用时，困难重重。因为各个业务系统的建设都是围绕着业务需求来建设的，当业务环境发生变化时，原来的业务系统不能互联互通，不能满足跨部门、跨职能、跨组织的协作需求。各个业务系统所产生的海量数据以复杂而分散的形式存储，导致数据之间的不一致和冲突等质量问题，从而导致数据在应用过程中的无所适从，难以实现数据的深度利用，从而难以实现业务模式创新和经营风险控制。数据治理的目标是什么？ 数据治理本身不是目的，它只是实现组织战略目标的一个手段。 从组织职能和体量大小方面来看，不同类型组织的数据治理目标大不相同： 集团企业总部和政府大数据管理局的目标是：制定数据政策、保障数据安全、促进数据在组织内无障碍共享，其重点目标是推进和保障数据战略的顺利实施。企业和政府业务部门的目标是：通过提升信息管理能力，提升组织精细化管理水平，提高业务运营效率，增强组织决策能力和核心竞争力，从而为实现组织战略目标提供能力支撑，其重点目标是数据价值获取、业务模式创新和经营风险控制数据治理包含哪些内容？ 相对于国际组织和国际企业发布的数据治理框架，以下国家标准 GB/T 34960 发布的数据治理框架比较符合我国企业和政府的组织现状。包含顶层设计、数据治理环境、数据治理域和数据治理过程。 |
|
|
1.顶层设计是数据治理实施的基础，是根据据组织当前的业务现状、信息化现状和数据现状，设定组织机构的职权利，并定义符合组织战略目标的数据治理目标和可行的行动路径。 2.数据治理环境是数据治理成功实施的保障，指的是分析领导层、管理层、执行层等等利益相关方的需求，识别项目支持力量和阻力，制定相关制度以确保项目的顺利推进。 3.数据治理域是数据治理的相关管理制度，是指制定数据质量、数据安全、数据管理体系等相关标准制度，并基于数据价值目标构建数据共享体系、数据服务体系和数据分析体系。 4.数据治理过程就是一个 PDCA（plan-do-check-act）的过程，是数据治理的实际落地过程，包含确定数据治理目标，制定数据治理计划，执行业务梳理、设计数据架构、数据采集清洗、存储核心数据、实施元数据管理和血缘追踪，并检查治理结果与治理目标的匹配程度。 数据治理实施方法论 近年来，推动数据治理体系建设一直是业界探索的热点。结合多年政府各个部门及各类企业数据治理项目经验，百分点曾经提出数据治理项目开展过程中数据治理平台应具备 4 大能力：聚、治、通、用，以及项目实施总体指导思想：PDCA。 |
|
|
四大能力建设： 聚：数据汇聚能力治：狭义数据治理能力，包括数据标准、数据质量、元数据、数据安全、数据生命周期、主数据。通：数据拉通整合能力，原始业务数据分散在各业务系统中，数据组织是以满足业务流转为前提。用：数据服务能力，数据资产只有真正赋能于前端业务才能发挥实际效用，所以如何让业务部门快速找到并便利的使用所需数据资产是数据治理平台的另一项核心能力。 P：plan，标准、规划、流程制定；D：do，产品工具辅助落地；C：check，业务技术双重检查保证；A：action，持续优化提升数据质量及服务。 |
|
|
结合数据治理项目实际落地实施过程以四大能力构建、PDCA 实施指导思想提出了“PAI”实施方法论，即流程化（process-oriented）、自动化（automation）、智能化（intelligence）三化论，以逐步递进方式不断提升数据治理能力，为政府和企业后续的数据赋能业务及数据催生业务创新打下坚实基础。 流程化将数据治理项目执行过程进行流程化梳理，同时规范流程节点中的标准输入输出，并将标准输入输出模板化。另外对各流程节点的重点注意事项进行提示。是数据治理工作开展第一步，是自动化和智能化的基础，将数据治理各节点开展过程中用到的内容进行梳理并规范，包括：业务流程图、网络架构图、业务系统台账等，行业知识梳理完善以后形成行业版知识（抽离通用版），如标准文件梳理：1.代码表整理，2.数据元标准整理（数据仓库行业模型对应标准梳理）。 自动化针对流程化之后的相关节点及标准输入输出进行自动化开发，减轻人力负担，让大家将精力放在业务层面及新技术拓展上，避免重复人力工作。如自动化数据接入及自动化脚本开发等。 智能化针对新项目或是新领域结合历史项目经验及沉淀给出推荐内容，比如模型创建、数据质量稽核规则等。在流程化、自动化基础之上针对数据拉通整合、主题模型、数据加工检查给出智能化建议，减少人工分析的工作。 数据治理需要哪些工具？ 从技术实施角度看，数据治理包含“理”“采”“存”“管”“用”这五个步骤，即业务和数据资源梳理、数据采集清洗、数据库设计和存储、数据管理、数据使用。 数据资源梳理：数据治理的第一个步骤是从业务的视角厘清组织的数据资源环境和数据资源清单，包含组织机构、业务事项、信息系统，以及以数据库、网页、文件和 API 接口形式存在的数据项资源，本步骤的输出物为分门别类的数据资源清单。数据采集清洗：通过可视化的 ETL 工具（例如阿里的 DataX，Pentaho Data Integration）将数据从来源端经过抽取 (extract)、转换 (transform)、加载 (load) 至目的端的过程，目的是将散落和零乱的数据集中存储起来。基础库主题库建设：基础数据一般指的是核心实体数据，主题数据一般指的是某个业务主题数据，分析数据指的是基于业务主题数据综合分析而得的分析结果数据。基础库和主题库的建设就是在对业务理解的基础上，基于易存储、易管理、易使用的原则抽像数据存储结构，就是基于一定的原则设计数据库表结构，然后再根据数据资源清单设计数据采集清洗流程，将整洁干净的数据存储到数据库或数据仓库中。元数据管理：元数据管理是对基础库和主题库中的数据项属性的管理，同时，将数据项的业务含义与数据项进行关联，还是自动化数据共享、数据交换和商业智能（BI）的基础。血缘追踪：数据被业务场景使用时，发现数据错误，数据治理团队需要快速定位数据来源，修复数据错误。我们的实践是在元数据和数据资源清单之间建立关联关系，且业务团队使用的数据项由元数据组合配置而来，这样，就建立了数据使用场景与数据源头之间的血缘关系。数据资源目录：基于业务场景和行业规范而创建，同时依托于元数据和基础库主题而实现自动化的数据申请和使用。一般应用于数据共享的场景。质量管理：数据价值的成功发掘必须依托于高质量的数据，唯有准确、完整、一致的数据才有使用价值。因此，需要从多维度来分析数据的质量。例如：偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。商业智能（BI）：数据治理的目的是使用，对于一个大型的数据仓库来说，数据使用的场景和需求是多变的，那么可以使用 BI 类的产品快速获取需要的数据，并分析形成报表。数据共享交换：数据共享包括组织内部和组织之间的数据共享，共享方式也分为库表、文件和 API 接口三种共享方式，库表共享比较直接粗暴，文件共享方式通过 ETL 工具做一个反向的数据交换就可以实现。 |
|
|
通过大数据治理提供多种数据服务，从根本上解决数据问题 传统数据治理更多是在强调通过一些流程和制度把数据质量提高，并不能很好地解决以上种种数据问题。现在做数据治理，更多是为大家提供统一的数据服务的能力，从而让数据问题得以解决。 |
|
|
这样的环境应该包括哪些东西？需要能解决一些什么样的问题？简单总结就是四个字：管（Manage）、看（Browse）、找（Discover）、用（Apply）。 |
|
|
管。我们管的时候，需要建立整个企业层面的元数据以及跟合作伙伴打交道的元数据，这样才能把所有的数据和数据之间的关系统一整合起来，而这些元数据不是手工录入进去，而是采进去的。后面会讲到我们元数据的智能化采集，这是能体现数据治理智能化的概念之一。看。“看”的部分是能展现数据治理效果、决定数据治理成败的主要部分。找。要想实现“找”，要建立业务元数据跟技术元数据的匹配，其中的难点是如何通过业务含义来查找数据，如果从技术含义找这些数据其实问题不是很大。恰恰我们做数据分析做使用都是从业务含义上来找，需要找到语义以及语义的上下级的关系，并且做一个延伸的搜索。用。美团配送数据治理实践1.定标准，提质量 第一步，主要围绕着业务标准、技术标准、数据安全标准和资源管理标准进行展开。通过业务标准，指导一线团队完成指标的规范定义，最终达成业务对指标认知一致性这一目标；然后通过技术标准来指导研发同学规范建模，从技术层面解决模型扩展性差、冗余多等问题并保障数据一致性；通过安全标准来指导我们加强数据的安全管控，确保数据拿不走、走不脱，针对敏感数据，用户看不懂；通过资源管理标准的制定，帮助我们在事前做好资源预算，在事中做好资源管理，在事后做好账单管理。 业务标准 业务团队负责指标的定义。产研商分负责给出指标定义标准和辅助工具，辅助业务团队完成指标的规范定义，达成指标认知一致性这一目标。最后由指标管理委员会负责指标的管理与运营，保障指标从创建、审核、上线以及到最后消亡的整个生命周期的运营。 技术标准 这里所说的技术标准，主要是针对数据RD提出的建模标准和数据生产规范，通过建模标准来明确数仓分层架构，并清晰定义每一层的边界与职责，采用维度建模的设计理念。我们的整个仓库架构分为四层：操作层、基础事实层、中间层和应用层，并在每一层同步制定对应的建模规范，如下图所示： |
|
|
除了建模标准外，我们还制定了涵盖从生产到运维环节的生产规范以保障模型的质量，主要包括上线前的模型评审、生产过程中的完成元数据配置、DQC、SLA和生命周期设置以及上线后的日常运维机制等等。 |
|
|
仓库各层元数据管理标准 |
|
|
仓库各层生命周期管理策略 安全标准 首先要有数据的分级、分类标准，确保数据在上线前有着准确的密级。 第二，针对数据使用方，要有明确的角色授权标准，通过分级分类和角色授权，来保障重要数据拿不走。 第三，针对敏感数据，要有隐私管理标准，保障敏感数据的安全存储，即使未授权用户绕过权限管理拿到敏感数据，也要确保其看不懂。 第四，通过制定审计标准，为后续的审计提供审计依据，确保数据走不脱。 |
|
|
资源管理标准 在资源管理方面，配送技术工程部已经对资源管理涉及的内容进行了合理抽象和准确定义，抽象出租户、资源和项目组等概念。不管是后续的资源预算还是资源管理，我们都需要基于租户和项目组来进行运营，因此，对于业务团队而言，我们只需要将租户和项目组特定职能划分清楚，然后根据不同的职能归属我们的资产，并分配生产该资产所需要的资源。为了方便后续的运营，我们对每个租户和项目组分配确定了责任人，由责任人对运营结果负责。 对业务部门来说，资源管理的关键是对数据资产做清晰的分类，基于数据的分类划分不同的租户和项目组，将数据和租户、项目组实现一一映射。由于租户和项目组都有特定的责任人对其负责，因此，我们通过这种映射关系，不仅实现了资产的隔离，还实现了资产确权（项目组负责人同时对资产负责和运营）。我们整体将数据分为两大类，一是原始数据，包括流到数据中心的数据和日志中心的数据，针对流入数据中心的数据，根据其产生的方式不同，又进一步分为业务数据和流量数据。二是加工数据，对应着数据团队的仓库建设和其他团队的集市建设。基于上述的描述，针对资源管理，我们做了如下划分和确权： |
|
|
资源划分与管理 2.重实施，保落实 第二步，落实第一步的标准，完成数据治理第一阶段的目标，实现存量数据“由乱到治”，并完成相应组织和工具的建设，为实现第二阶段“行不逾矩”这一目标提供工具和组织能力。在此过程中，主要分成三个方面的治理工作：第一，架构模型“由乱到治”的治理，消除模型冗余、跨层引用和链路过长等问题，在架构上保证模型的稳定性和数据一致性；第二，元数据“由乱到治”的治理，实现指标的标准定义、技术元数据的完整采集并建立指标与表、字段的映射关系，彻底解决指标认知一致性，以及用户在使用数据过程中的“找数难”等问题；第三，围绕着隐私安全和共享安全加强数据的安全管控来实现数据走不脱、拿不走，以及隐私数据看不懂这一目标。 架构治理 主要是解决两个问题： 第一，模型的灵活性，避免需求变更和业务迭代对核心模型带来的冲击，让RD深陷无休止的需求迭代中；第二，数据一致性，消除因模型冗余、跨层引用等问题带来的数据一致性问题。 模型灵活性 配送解决的是效率、成本和体验三者之间的平衡问题，即在满足一定用户体验的条件下，如何提升骑手配送效率，服务更多的商家，以及如何管控骑手，降低配送成本。抽象到数据层面，基本上反映为上游包裹来源的变化、配送对外提供服务的变化以及对内业务管控的变化。为屏蔽业务迭代给核心模型带来的冲击，我们通过对外封装包裹属性和对内封装运单属性，抽象出包裹来源、提供服务、业务架构等一致性维度，任何业务迭代在数据层面只涉及维度的调整，大大降低了对核心模型冲击和“烟囱式”数据建设问题（新来一个业务，就拉起一个分支进行建设）。 |
|
|
包裹事实分配到运单明细构造单一运单模型 配送指标体系建设的一个重点就是要输出各组织层级的规模、体验和效率指标，实现对运力的有效管控，运力所属组织的层级关系会随业务的迭代而不断变化。为了适应这种变化，避免仅仅因增加维度带来中间层数据的重复建设，我们将组织层级维表由固定层级建模方式调整为桥接表的方式来自适配组织层级变化，从而实现了中间层模型可以自动适配组织层级的变化，能自动产生新维度的指标。如下图所示： |
|
|
桥接表自适配组织层级灵活变动 在精细化分析的场景下，业务会有分时段、分距离段以及分价格段的数据分析诉求。我们以分时段为例，有晚高峰、午高峰、下午茶等不同的分时段，不同的业务方对同一个时段的定义口径不同，即不同的业务方会有不同的分时段策略。为解决该场景下的分析诉求，我们在事实表中消除退化维度，将原来封装到事实表的时段逻辑迁移到维度表中，并将事实表中的时间进行按特定的间隔进行刻度化作为维表中的主键，将该主键作为事实表的外键。这样，针对业务不同的时间策略需要，我们就可以在维表中进行配置，避免了重复调整事实表和反复刷数的问题。即通过将时间、价格、距离事实刻度化，实现灵活维度分析。如下图所示： |
|
|
数据一致性 数据一致性得不到保障的一个根本原因，是在建模的过程中没有实现业务口径标签化，并将业务口径下沉到主题层。 |
|
|
治理前模型架构 |
|
|
治理后模型架构 元数据治理 元数据治理主要解决三个问题： 首先，通过建立相应的组织、流程和工具，推动业务标准的落地实施，实现指标的规范定义，消除指标认知的歧义；其次，基于业务现状和未来的演进方式，对业务模型进行抽象，制定清晰的主题、业务过程和分析方向，构建完备的技术元数据，对物理模型进行准确完善的描述，并打通技术元数据与业务元数据的关系，对物理模型进行完备的刻画；最后，通过元数据建设，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。 元数据采集 元数据采集分为人工录入和自动抽取，通过人工录入的方式实现物理表的准确归属（包括该表属于仓库哪一层、对应的主题、业务过程、星型模型关系等）以及指标的采集，从而完成技术元数据和业务元数据的采集，通过自动抽取的方式完成生产元数据的采集和使用元数据的采集，主要包括：物理模型的依赖关系、存储占用、热度、等信息。 元模型构建 分为以物理表为核心的基础元模型构建，以及以血缘为中心的血缘元模型。基础元模型构建以物理表为中心，打通其与技术元数据（主题、业务过程、Schema）的关系，实现了物理表的清晰归属，打通其与生产元数据的关系，为其加上了物理表查询热度、资源消耗、查询密级等生产使用信息，打通其与指标、维度和应用的对应关系，为上层的取数应用建立了完备的元数据。血缘元模型以血缘为中心，不仅构建了从上游业务表到仓库离线表的物理血缘，而且打通了仓库离线表到下游对应报表的血缘，为后续的影响评估构建了完备的元数据基础。 元数据服务 统一元数据服务（OneService），主要提供两类元数据服务，提供查询表、指标、维度基本信息的基础元数据服务以及查询表级血缘、字段级血缘的血缘服务。 元数据应用 主要孵化出了三个产品，以“找数、理解数、影响评估”为应用场景的数据地图（Wherehows），以“取数、数据可视化”为应用场景的数据可视化（QuickSight），以及以管理审计为目的的管理审计报表。 安全治理 安全治理主要加强了敏感数据的安全治理和数据共享环节的安全治理。通过对隐私数据的安全治理，不仅要保证其在存储环节的不可见性，而且还要保证在其使用环节对用户进行双重鉴权，字段的密级鉴权和解密的密钥鉴权；通过对数据共享环节的安全治理，在数据分级分类的基础上，使数据的权限控制从表级权限控制扩展到行级权限控制。 共享环节安全治理 针对共享环节的安全治理，主要在数据生产环节完成数据的分级分类和数据确权，在数据的使用环节完成数据的表级权限控制和行级权限控制。确保数据在使用环节规范的审批流转，权限开放以后的安全审计，保证数据走不脱。 3.工具简介 数据地图（Wherehows） 数据地图作为元数据应用的一个产品，聚焦于数据使用者的“找数”场景，实现检索数据和理解数据的“找数”诉求。通过对离线数据集和在线数据集的元数据刻画，满足了用户找数和理解数的诉求，通过血缘图谱，完成物理表到产品的血缘建设，消除用户人肉评估的痛苦。 离线数据场景 关键字检索和向导查询共同解决了“找数据”的问题 |
|
|
|
|
|
打通业务元数据和技术元数据之间的关系，提高“找数据”的能力 |
|
|
提供较为完善的数据信息，帮助用户更好理解数据 |
|
|
通过评论问答功能，帮助用户快速得到问题反馈 |
|
|
业务数据场景 业务数据场景主要想解决的一个问题是，如何知道一个业务表（MySQL表）有没有同步到数仓。 |
|
|
生产评估场景 在日常数据生产工作中，经常需要对表进行影响评估、故障排查、链路分析等工作，这些工作如果靠纯人工去做，费时费力。但现在打通了“业务表/字段 -> 数仓表/字段 -> 产品”三者之间的血缘关系，就能够在10分钟内完成评估工作。对于不同的场景，血缘链路提供了两个便捷的功能：过滤和剪枝。例如，某个表逻辑需要修改，需要看影响哪些下游表或产品？应该要通知哪些RD和PM？这种情况下，血缘工具直观地显示影响了哪些负责人和产品，以及这个表的下游链路。 |
|
|
有些表的链路很长，整个血缘关系图很大，这样会导致用户定位信息或问题。所以血缘工具提供了剪枝的功能，对于没用的、不想看到的分支可以剪掉，从而让整个链路变得更加直观。 数据可视化（QuickSight） 聚焦于数据使用者“取数”场景，使用QuickSight，用户可以不再关心数据的来源，不再担心数据的一致性，不再依赖RD的排期开发。通过所选即所得的方式，满足用户对业务核心指标的二次加工、报表和取数诉求。 首先，通过指标池、数据集等概念对离线生产的指标进行逻辑隔离，针对不同用户开发不同的数据集以达到权限控制的目的。 |
|
|
用户、指标池与数据集间的关系 其次，为用户提供一系列的组件，帮助用户基于为其开放的数据集实现指标的二次加工和数据可视化功能，满足其在不同业务场景下的取数和可视化应用。 |
|
|
|
|
|
指标加工组件 总结在数据标准方面，制定了业务标准、技术标准、安全标准、资源管理标准，从而保障了数据生产、管理、使用合规。在数据架构方面，通过桥接表、时间刻度化、业务口径下沉等手段提升模型灵活性，并保障数据一致性，消除跨层引用和模型冗余等问题。在数据安全方面，加强了对敏感数据和数据共享环节的安全治理，保证数据拿不走、走不脱，隐私数据看不懂。在元数据建设方面，打通了从采集到构建再到应用的整条链路，并为数据使用人员提供数据地图、数据可视化等元数据应用产品，帮助解决了“找数”、“取数”、“影响评估”等难题。蚂蚁金服的数据治理实践蚂蚁的业务形态和面临的多方面挑战 |
|
|
当今，蚂蚁的业务形态成为了“技术+数据+算法”三者的融合来追求价值最大化。与此同时，数据质量治理也存在着诸多挑战，它们来自于业务方面、数据方面、用户方面。 数据质量治理思路 从事金融业务的同学往往深有感触，互联网金融时代业务的生命周期缩短了很多，并且变化也非常频繁，相比于原本银行的节奏显得非常快。此外，目前无论是蚂蚁金服还是阿里巴巴都在谈“数据业务化、业务数据化”，数据和业务一同共同发展和前进，并且已经进入了发展的深水区。 那么如何实现数据质量治理呢？ 首先，需要有一套明确的组织，这是持续建设企业文化的土壤。而数据质量治理文化的建设一定是一个确定的、有组织的并且需要长期持续推进的事情。 在组织保障和质量文化的基础之上，蚂蚁还侧重了研发流和数据流。在金融领域，研发流的管控更严格，也更严谨。而对于如今的互联网金融而言，也需要进行强管控，这是因为业务形态决定了研发周期很短，现在蚂蚁在研发流做了强管控，在一站式数据研发平台上，使用了分级管控。需求提出之后就会被等级管理，并且进行打标，进而走入不同流程。其次，研发流上还侧重分级管控，在同一套标准上定义级别，拉平不同的研发流。对于数据流而言，当一个应用发布到生产环境之后，大部分精力花费在数据流中，每天需要从生产环境将数据采集到处理平台，然后运行算法计算，之后将数据返回到生产环境中，走这样的闭环。 |
|
|
基于以上的数据质量治理思路，蚂蚁金服做了很多有意思的东西，在数据平台运行时会将整个体系监控起来，如果出现数据质量故障，就能够及时进行修复。 此外，从研发到生产的各个环节，蚂蚁都做了大量的工作，这是因为基于平台进行数据研发的同学很多，需要尽量降低使用门槛。对于全数据流而言，主要建设了四大能力，包括感知能力、识别能力、智愈能力和运营能力。 最后是运营能力，数据质量不会被展现在前台，如果数据质量足够好，完全可以实现无感知，使用者不用再担心数据能不能用，也不会出现敢不敢用的疑惑，因此数据质量对于运营而言也非常重要。其实，数据质量问题既不仅属于研发也不仅属于业务，而是需要全员参与，共同来解决，这就是数据治理的思路。 蚂蚁数据质量治理架构 在系统层，研发阶段主要集中在数据测试、发布管控以及变更管理等方面的建设，这里着重提及变更问题，数据的变更不仅仅设计到系统层的变更管理，也会涉及到在线系统的相互打通。如今，在线数据源的变更，也会使得数据运营发生变更，更可能会导致数据运营的数据质量问题。 在线研发部分为数据运营系统提供了一些相关的接口，能够通知使用者线上的哪些变更会影响到数据运营。对于发布管控能力而言，蚂蚁投入了大量精力进行研发。目前在蚂蚁已经没有专职负责数据测试的同学，基本上全部都是全栈工程师，所以对于研发而言可能管控不是非常强，但却实现了强大的发布管控能力，将与经验、规范、性能以及质量相关的检测全部在这部分执行。 |
|
|
在生产阶段，则主要侧重于质量监控、应急演练以及质量治理这三个系统能力。蚂蚁做了一件很有意思的事情——数据攻防演练，工程师会人为创造故障，然后测试系统能否在短时间内发现故障并进行有效修复，这部分也是目前蚂蚁在重点进行建设的能力。在质量治理部分，会根据不同应用的级别，发布到生产环境之后进行定期巡检，分析是否会影响数据质量。总之，对于数据质量架构体系的系统层而言，不仅原数据非常重要，如今更是结合机器学习来自动配置一些相关策略。 数据质量治理方案 如下图所示的是蚂蚁金服在实践中的事前、事中、事后的数据质量质量方案。 |
|
|
整体而言，事前包括需求、研发、和预发三个阶段，而如今蚂蚁在事前可以做到的可管控、可仿真、可灰度。在事中，监控问题是重点建设的，出现问题不可怕，但是需要实现自主发现问题。而为了使得防御能力更强，蚂蚁实现了主动的攻击演练，而正是通过攻防演练，帮助蚂蚁发现了自身很多薄弱的地方。除此之外，还在事中提供了强大的应急能力，某些事件将会触发应急预案，在这部分，保证数据质量其实就是把不确定的数据风险变成确定的东西。在事后，数据质量也非常重要，事后需要通过有效的指标和管控手段来进行审计和度量，以此发现整个链路上不完善的地方并持续完善。 最后为大家分享蚂蚁金服在数据质量治理方面的两个案例： 案例 1：在蚂蚁数据治理架构体系下的发布环节，实现了一个发布强管控的流程。任何脚本在提交时都需要经过检测，然后发布到线上，并再进行一次检测。 案例 2：数据治理涉及到整个链路，而针对不同链路上的数据版本，数据采集主要是将数据从一端搬运到另一端，不存在加工的过程，此时可以人为注入一些故障，分析数据质量治理体系能否发现问题并作出修改，因此这就产生了“攻”与“防”双方。数据加工处理又另外一套体系结构，其涉及逻辑的加工，更多地需要考虑注入怎样的故障，需要面临什么。如今，在蚂蚁真正落地数据质量治理体系的时候，在攻防演练环节投入了大量精力。 |
|
|
八千里路云和月 | 从零到大数据专家学习路径指南 我们在学习Flink的时候，到底在学习什么？ 193篇文章暴揍Flink，这个合集你需要关注一下 Flink生产环境TOP难题与优化，阿里巴巴藏经阁YYDS Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点 我们在学习Spark的时候，到底在学习什么？ 在所有Spark模块中，我愿称SparkSQL为最强！ 硬刚Hive | 4万字基础调优面试小总结 数据治理方法论和实践小百科全书 标签体系下的用户画像建设小指南 4万字长文 | ClickHouse基础&实践&调优全视角解析 【面试&个人成长】2021年过半，社招和校招的经验之谈 大数据方向另一个十年开启 |《硬刚系列》第一版完结 我写过的关于成长/面试/职场进阶的文章 当我们在学习Hive的时候在学习什么？「硬刚Hive续集」 你好，我是王知无，一个大数据领域的硬核原创作者。 做过后端架构、数据中间件、数据平台&架构、算法工程化。 专注大数据领域实时动态&技术提升&个人成长&职场进阶，欢迎关注。 |
|
1、从一个问题开始 在开始讲启动契机之前，先问自己一个问题：假如数据都清洗干净了、所有数据都拉通了、数据质量提升了，然后那，然后在这个数据的基础上你想做什么? 我理解这个一切都准备好了之后的那个“然后那”的答案，就是一个数据治理启动的契机一部分。如果，面对这个“然后那”，并没有一个强有力的答案，那么个人认为就还没有找到这个启动的契机。 缺少这个契机，主要是缺少了一个业务场景，或者说业务目标，没有业务场景、目标的数据治理，那就是纯为了治理而治理。为了治理而治理是一定不会成功的，因为都没有一个实际的业务来校验、反馈是否真的成功。自说自话的结果，没什么意义。 单独说一句，提升安全合规性也是一个业务目标，甚至可以说是一个事关生死的业务目标。 2、这个契机都包含些什么 这个契机不仅仅是一个场景，还要包含这个场景的相关方，这个场景适合的时间。 按照讲故事的逻辑，就是需要明确一下什么时间，什么人，做了什么事情。这三点都明确了，且觉得合适，那么就是数据治理启动的一个契机了。 做了什么事情，就是一个场景。也就是具体做的一件事情。 什么人，也就是找到数据治理的相关方。 什么时间，也就是启动数据治理的时机，什么时候合适。 这个启动的契机，需要协调各个利益方，只有找到利益方了，满足各方的意见才能做到很好的落地。 下面我们从这三个要素角度，试着看看都分别有什么。 3、场景从哪里找 场景主要是要找到要干什么事情。也是开篇提到的那个问题的答案。然后那？数据都清洗、拉通、质量提升之后，然后想干什么。 在DGI数据治理框架中说，企业生存的三个主要驱动力包括： 增加利润成本与复杂性控制通过对风险与脆弱性的研究确保企业正常运作：合规、安全、隐私等 而这个数据治理的场景，也逃脱不了这三类驱动力。可以从这三类驱动力中找到想干什么。并且，这件想干什么的事情，最好一句话就能够说清楚的。 为什么强调一句话，个人之前看到过一个说法：凡是一句话说不清楚的需求，都是伪需求。这句话可能有点过于绝对了。但是传达的道理还是挺明确的，即必须有一个能够简短表达的需求。 这个确定场景的过程也绝不是闭门造车的过程，是需要深入到业务中去，真实的了解痛点在哪里。 这个过程中如何和业务沟通配合，就是“人和”的部分了，在整个数据治理过程中充满了这种人与人之间的沟通交流，是否能够达成配合顺利，达到“人和”的程度，也是成败的关键。 （后续，会单独说下个人认为数据治理过程中的“天时、地利、人和”以及“利其器”的内容）。 在沟通过程中也会有一些沟通模板。有一个固定的模版，能够更好的进行推广，升级沟通形式。 并且这个场景，最好是能够获取高层认可的，或者直接就是高层想做的。这样推进的时候会阻力更小。 5、明确相关方 在找到了具体场景的同时，需要明确这个场景在实际落地的时候的相关方。 个人理解这个相关方包括两类：直接相关方和间接相关方。 直接相关方就是治理这个动作直接作用的双方。类似于力作用的时候的施力一方，和受力一方。这里面就是发出治理需求的一方，一个就是被治理影响的一方。 直接相关方的施力一方：就是发出治理规范要求的一方，可能是专门的数据管理部门，也可能就是数据中台部门。后续，我们假设这个部门就是数据中台部门。 但一定不能业务部门或者IT部门来做。因为受力一方就是业务部门和IT部门，不能即做选手，又做裁判。 直接相关方的受力一方：就是IT部门和业务部门。IT部门就是系统建设的部门。业务部门就是系统使用的部门。在数据治理过程中都会对这两个部门提出相应的一些要求。后续我们也统称为业务部门。 间接相关方：就是能够让治理顺利施行的一方。这个方面个人认为是治理工具提供方。 个人总感觉数据治理过程中的工具提供方一直是没有被充分重视的一个环节。各种数据治理政策的落地，各种目录的梳理其实都需要工具辅助支撑，才能很好的落地的。 这个工具，通过采购可能并不一定完全满足需求。如果通过自研，那么工具的整个研发周期又会很长，是否将工具研发周期也包在数据治理的周期内？如果提前准备工具，又需要和实际治理过程中需求相匹配，但是还没有启动数据治理，具体需求还不能确定，怎么让提前准备的工具完全匹配？ 而且工具提供方其实最终产物是一个平台工具，并不实际的产生业务价值。 这些都是这个工具提供方，这个间接相关方的难点。即需要工具，又不想让工具的准备占据过多精力。 间接相关方可能还会涉及到安全部门。一般公司会有独立的安全部门来负责安全。或者法务部门，现在数据安全法，个人隐私保护法也都比较多，由法务部门提供些意见支持还是有必要的。 确定好了直接相关方和间接相关方。明确了要做的场景中，这些人都处在什么位置，都需要干什么。是确定契机的第二点，明确什么人。 人力即权力。或者说人事即权力。这种人事安排，组织安排是否合适，是否和你要做的事情相匹配，即意味着这件事情能不能做的下去。权力能不能发挥出来。 4、时间怎么控制 确定了什么事情：找到了场景。明确了什么人：明确相关方。第三个就是确定时间了。 也就满足最开始提到契机里面包含的：什么时间，什么人，做了什么事情中的第三个要素了。 这个时间包括宏观上的时间，也包括微观上的时间。 宏观上的时间比较重要的一点就是：系统不再频繁做大的功能变更了。如果业务还处在高速发展期，业务流程，数据流向会进行大的彻底的变更。那么这种时候，时间上就不是合适的时间点。 另外几个是，组织要足够大，系统要相对复杂。如果组织本来就比较小，或者系统很少，关系比较简单，那也没有必要进行独立的数据治理。 在时机上有跨职能项目合作。或者是整体合规要求，这种被动的时机，也是启动的不错的时间点。 微观上的时间是场景的业务方准备好了。如果业务方现在有其他的更重要的事项需要研发，你这时候去让业务配合，即使说通了，但是也不是人家第一优先级。怎么可能好好配合进行数据治理。 而且好多时候，这种业务方没有准备好，还不能明说。要看看他们的当前目标是什么，多私下沟通交流，感觉还是挺微妙的。 5、总结 如果没有筹齐这三个要素，说明做这件事情的契机还不成熟，还需要再等等、再找找，启动全局的数据治理，还是需要三思下。或者采用更聚焦、更局部的方式来启动。 如果已经集齐了这三要素，那么下一步我们看看数据治理过程中直接相关的两方，也就是数据中台和业务部门的几种合作的模式。通过哪种合作形式能够更好的进行数据治理的推进。 |
|
在社会经济发展的历史长河中，每一次生产要素的变迁都决定着行业兴衰和企业沉浮。今天，数字经济的高速发展和人工智能变革浪潮到来，一个全新且重要的生产要素——数据，正以前所未有的速度和体量涌现，并深刻影响着每一个行业的未来。 中国无疑是一个“数据大国”，拥有最活跃的应用场景和爆发性增长的数据总量，人工智能应用前景广阔。但我们距离真正的“数据强国”，似乎还隔着一层无形的“天花板”：数据治理难题。尤其是《“数据要素×”三年行动计划》执行的深入，千行百业在数智化转型中，传统的数据治理方式方法难以为继，加速向“智理”进化成为大势所趋。 因此，从“治理”到“智理”是中国成为数据强国和行业数智化转型的必然路径。在2025第四届数据治理年会上，百分点科技率先发布业内首个深度聚焦数据治理领域的垂直大模型：百思数据治理大模型（BS-LM）和百思数据治理平台（AI-DG），全面开启数据的智能治理时代。 正如百分点科技CEO 苏萌博士所言：“未来的AI竞争中，比参数规模更重要的是场景深度。百思大模型将百分点科技过去十年沉淀的治理方法论‘产品化’，赋能行业和客户完成高质量、高效率、高价值的数据治理。” |
|
|
数据治理演进到3.0阶段 IDC《2024中国数据治理解决方案市场追踪报告》（以下简称：《报告》）显示，2024年中国数据治理解决方案市场总规模达到3764.9亿人民币，同比增长率达到30.6%，未来几年将央国企、政务等客户还将继续保持数据治理的高投入。 无疑，数据治理乃行业未来数智化转型建设的刚需，其最大价值是让数据成为资产，并有效赋能业务创新和智能决策。但面对AI时代海量数据的敏捷需求，传统数据治理模式逐渐力不从心，甚至成为一项“包袱”，拖累企业数据要素价值的释放。 当前，传统数据治理模式主要存在：规则僵化、人工依赖重；语义割裂、协同困难；治理任务碎片化、难以自动化编排；知识难沉淀、治理难传承；规则驱动向智能驱动的转变缺位等突出挑战。 例如，治理规则和数据标准往往需要专家利用经验手工定义，使得数据治理周期长、适应性差，难以应对企业与组织日趋快速变化的业务需求。 |
|
|
众所周知，数据治理属于高度专业的领域，过去一直依赖数据治理专家的专业知识和实践经验。固然，数据治理近年来尝试融入AI技术，试图在功能中嵌入AI能力，推动数据质量识别、修复策略等功能走向AI化，但这基本属于点状的突破，依然很难解决治理全流程智能化不足、行业经验支撑不足、交互复杂、数据治理价值感低等问题。 因此，数据治理需要从“人工主导”加速向“AI自治”演进。百分点科技政企业务总经理马伟凯介绍：“数据治理1.0阶段主要是人工主导、平台赋能；2.0阶段则是功能AI化、降本增效。进入到3.0阶段，数据治理应该是AI原生治理，以大模型为内核、多智能体协作为载体，实现数据治理范式的跃迁。” 百思数据治理大模型：“智理”有解 “AI自治”，意味着数据治理范式从“分散化、规则驱动”走向“语义统一、智能驱动”。 这其中，数据治理大模型的应运而生成为必然。众所周知，通用大语言模型近年来取得持续突破，但也在垂直领域常陷入“知识肤浅、幻觉频发”的困境。虽然如此，通用大语言模型能力不断提升，为专注数据治理领域的大模型夯实重要基础。Gartner就预测，到2028年，企业中超过50%的生成式AI模型将为特定领域模型（DSLM）。 与通用大语言模型相比，数据治理大模型深度融合数据治理领域的知识体系和治理逻辑，具备数据治理领域的上下文理解能力，更加符合数据治理业务场景的推理与决策需求。数据治理大模型无疑是下一代数据治理体系的“核心引擎”，让数据“智理”真正有解。 如今，作为领先的数据智能企业，百分点科技率先出手，推出百思数据治理大模型，其基于百分点科技近千个数据治理项目经验与方法论沉淀打造，并深度融合DCMM、DAMA等国际国内权威数据治理框架和行业最佳实践。百思数据治理大模型具备数据治理知识的深度融合和专家级认知能力、全流程智能规划和闭环治理体系、治理资产构建与生成、场景化智能协同、治理成效精准度量和全面信创适配等能力特性。 |
|
|
以困扰垂直行业用户多年的数据治理流程规划为例，百思数据治理大模型可以基于用户战略目标与数据现状，自动生成涵盖规划设计、流程构建、资源调配的端到端治理方案，通过多行业场景知识库实现个性化匹配与动态优化。 马伟凯介绍，百思数据治理大模型采用“通用指令学习→领域增强→能力对齐”的多阶段训练策略，针对不同治理业务域分别构建多个具备深度专业能力的“领域专家模型”，并创新性提出数据治理“知识原语”理念，将复杂的数据治理知识体系解构为可计算、可组合的语义单元，构建了精准且可扩展的语义理解基础。 此外，百思大模型以“知识+推理”为核心，构建起覆盖数据治理全生命周期的智能能力体系，具备对治理逻辑、业务语义与合规要求的深度理解能力，形成“专家级”的行业认知，成为适用于垂直行业数据治理的智能决策引擎。 AI-DG：让“智理”高效执行 再好的数据治理规划，如果没有高效执行也将无法实现。 IDC在《报告》中强调，企业需要尽可能将数据治理与AI、Agentic相融合，实现流程自动化、智能化。众所周知，既懂业务和技术，又懂数据治理项目执行的专业人才目前依然稀缺，而智能体的涌现，则为数据治理的高效执行带来契机。 为此，百分点科技此次还推出以大模型为核心、多智能体协作为载体、AI自主工程化交付为目标的下一代数据治理平台：百思数据治理平台（AI-DG）。如果说百思数据治理大模型是一个智能决策引擎，那么AI-DG则相当于一个高效的执行引擎，能够将智能决策落实为具体的执行，从而完成数据“智理”的闭环。 百思数据治理平台采用“对话式治理”新模式，精准理解用户自然语言所描述的需求，并自动调度多智能体协同工作，完成数据探查、标准制定等全链路任务；同时，面对复杂治理任务时，专业智能体高度协同体系还能极大减少人工与重复劳动，并减少人工传递导致的碎片化问题；AI-DG的AI-Ready架构与智能体协同机制，还提供体系化与场景化双模式治理能力，既能完成全链路体系建设，又能解决特定场景的数据难题；多模态数据处理能力则能帮助用户构建统一治理体系，打破异构数据壁垒，实现多模态数据的标准化管理。 |
|
|
以非结构化数据治理为例，当前企业的数据治理工作大部分仍然以结构化数据或者少量知识文档为主，非结构化数据仅少部分被治理与利用。IDC《报告》认为，数据格式的界限正在模糊，打破数据形势之间的界限才能统一数据价值。 而百思数据治理平台所提供的多模态数据处理能力，打破文本与图像、音视频等非结构化数据的治理壁垒，自动提取实体、标签及语义关联，并实现跨模态联合分析，深度挖掘数据之间的潜在关系，为用户建立统一数据治理体系做好充足保障。 “从AI-DG的实践来看，用户的数据治理项目交付周期缩短70%以上，运营成本降低50%以上 。”马伟凯如是说。 事实上，针对政企对于数据安全与数据控的迫切需求，百思大模型与AI-DG实现全栈信创适配，深度兼容国产技术体系，构建“数据不出域、模型可审计、过程可追溯”的全链路安全保障体系，并支持本地化与私有云等灵活部署方案。 据悉，百分点科技后续还将持续推进数据治理AI Agent体系的建设，推动“规划-执行-评估-优化”的全自动自循环治理机制建设，并联合政务、应急等关键行业伙伴，共同推动数据治理生态的完善。 综合观察 数据要素已是无可争议的核心生产要素。 中国作为全球最大的数据圈，从数据大国到数据强国，需要的不仅仅是数据规模，更离不开数据的“智理”能力。随着我国《“数据要素×”三年行动计划》执行的深入，数据治理已成为企业与组织数智化转型的核心战略组成部分，企业对于数据治理的需求也将加速转向“智理”。 百思数据治理大模型的发布，标志着传统数据治理时代的徐徐落幕，全面融合Data+AI的数据“智理”新时代加速到来。面向未来，随着数据治理新范式的普及，政企等行业将不再为数据治理而困扰，数据价值的全面释放也必然让数字中国的蓝图加速照进现实。 |
|
引言：从“数据沼泽”到“数据地图” 在数据爆炸的时代，企业面临的核心矛盾不再是“数据太少”，而是“数据太多、太乱、太难找”。 想象一下：一家大型银行有超过5000个数据库实例、10万张数据表、百万级字段。分析师想找一个“客户月均消费额”的指标，需要在几十个系统中翻找，问了一圈也不知道谁有、在哪里、能不能用。最终花了三天时间，拿到一个不知道是否准确的数据。 这就是典型的“数据沼泽”——数据浩如烟海，却无法被发现、被理解、被使用。 数据目录，正是这片沼泽上的“导航系统”。它让数据从“混沌”走向“有序”，从“不可见”走向“可发现”，从“难理解”走向“易使用”。 本期我们将深入探讨数据目录的构建方法、数据地图的可视化实践，以及数据资产“入湖、找数、懂数”的全链路机制，帮助企业打造数据时代的“导航系统”。 |
|
|
一、数据目录：数据资产的“黄页”1.1 什么是数据目录？ 数据目录（Data Catalog）是企业数据资产的集中式清单和检索系统。它记录了“有什么数据、数据在哪里、数据长什么样、数据代表什么、谁在负责、如何使用”等元信息，让用户可以像查字典一样查找和理解数据。 一个生动的类比：图书馆的目录系统 图书馆有几十万册书，没有目录，你只能盲目翻找有了目录卡片（或在线检索系统），你可以按书名、作者、分类、关键词找到需要的书目录告诉你：书在哪里（书架位置）、书的内容是什么（简介）、这本书怎么样（评分、借阅次数） 数据目录扮演同样的角色 企业有成千上万张表，没有目录，你只能到处问人有了数据目录，你可以按业务域、表名、字段、指标找到需要的数据目录告诉你：数据在哪里（数据库、表）、数据代表什么（业务定义）、数据质量如何（评分、负责人）1.2 数据目录的核心价值价值维度说明业务收益可发现性用户能够快速找到所需数据资产减少“问人找数”的时间，从几天缩短到几分钟可理解性用户能够理解数据的含义和上下文降低数据使用门槛，业务人员也能自助用数可信赖性用户能够评估数据的质量和可靠性避免使用错误数据，提升决策质量可治理性管理者能够掌握数据资产的全局视图支撑数据治理决策，识别数据资产价值1.3 数据目录 vs. 元数据管理 很多人容易混淆数据目录和元数据管理。其实二者是相辅相成的关系： 维度元数据管理数据目录定位数据管理的“基础设施”数据消费的“用户界面”关注点如何采集、存储、管理元数据如何让用户发现、理解、使用数据用户数据工程师、数据治理人员数据分析师、数据科学家、业务用户输出元数据存储库、血缘图谱可检索的数据资产清单、数据详情页 关系：元数据管理是数据目录的“引擎”，数据目录是元数据管理的“界面”。 二、数据目录构建方法：四步法 构建一个有效的数据目录，不能一蹴而就。基于大量企业实践，我总结出“四步构建法”： 第一步：定范围——明确“管什么” 目标：确定数据目录的覆盖范围，避免“贪大求全”。 决策要点： 按业务域：优先覆盖核心业务域（客户、产品、交易、营销）按数据层级：优先覆盖数据仓库/数据中台的“黄金数据”（经过治理、质量有保障的数据）按使用频率：优先覆盖高频使用的数据资产 实战建议：初期覆盖3-5个核心业务域、100-200张核心表，跑通流程后再逐步扩展。 第二步：建标准——明确“怎么管” 目标：建立数据目录的元数据标准和规范，确保目录内容的一致性和可用性。 核心要素： 要素说明示例资产命名规范数据资产（表、字段）的命名规则{业务域}_{主题}_{粒度}_{后缀}资产分类体系数据资产的分类层级一级分类：业务域；二级分类：主题域；三级分类：数据表标签体系用于快速筛选的标签质量等级（金牌/银牌/铜牌）、敏感等级（核心/敏感/内部/公开）必填属性每条资产记录必须包含的属性资产名称、业务定义、数据Owner、更新频率、质量评分第三步：采元数据——打通“数据源” 目标：从各数据源采集元数据，自动化构建目录的骨架。 采集内容： 技术元数据：表名、字段名、字段类型、分区信息、存储位置血缘元数据：表的上下游依赖关系、ETL任务信息统计元数据：表大小、记录数、访问频率、更新记录 采集技术： 基于JDBC/ODBC采集关系型数据库元数据基于Hive Metastore采集数据仓库元数据解析ETL脚本（SQL、Python）构建血缘关系通过API接入第三方工具元数据第四步：富内容——让数据“活起来” 目标：在自动化采集的元数据基础上，补充业务和管理元数据，让数据目录真正“好用”。 需要补充的内容： 内容类型说明补充方式业务定义表的业务用途、字段的业务含义数据Owner录入、业务专家标注质量信息数据质量评分、检核结果数据质量平台自动同步使用说明数据的使用场景、注意事项数据管家录入、用户贡献常见问题数据使用中的常见问题和解答数据管家维护样例数据脱敏后的数据样例系统自动抽取用户评价使用者的评分和评论用户反馈机制热门标签用户自定义标签用户标注三、数据地图：让数据资产“看得见” 数据目录的核心呈现形式是数据地图——一个可视化的数据资产导航平台。 3.1 数据地图的核心功能 1. 全局检索 关键词检索：支持表名、字段名、业务术语、标签的模糊检索高级筛选：按业务域、数据层级、质量等级、敏感等级、更新频率等筛选智能排序：按相关性、热度、质量评分排序 2. 资产详情页 基本信息：表名、业务定义、数据Owner、更新频率技术信息：字段列表、数据类型、分区信息、存储大小血缘信息：上游来源表、下游依赖表（可视化展示）质量信息：质量评分、检核规则、问题记录样例数据：脱敏后的数据样例使用指南：使用场景、注意事项、常见问题用户互动：评分、评论、收藏、分享 3. 资产全景 业务域视图：按业务域（客户、产品、交易）展示数据资产分布数据层级视图：按ODS/DWD/DWS/ADS层级展示数据流向热力图：展示高频使用的数据资产质量看板：展示各业务域的数据质量情况3.2 数据地图的交互设计原则原则说明实践简单直观用户无需培训即可上手借鉴电商网站的商品搜索体验多视角不同角色有不同的使用视角业务用户看业务定义，技术用户看技术细节上下文丰富提供足够的决策信息质量评分、负责人、使用热度帮助用户判断是否可用可行动用户可以直接获取数据提供“申请权限”、“导出DDL”、“复制查询”等操作四、数据资产“入湖、找数、懂数”——全链路实践 数据目录的价值，体现在数据资产从“产生”到“消费”的全链路中。我将其总结为“入湖、找数、懂数”三部曲。 4.1 入湖：让数据“进得来、理得清” “入湖”是指数据进入数据平台（数据湖/数据仓库 ）的过程。数据目录在这一阶段的核心作用是建立资产的“身份证”。 关键实践： 1. 资产注册机制 数据表创建时，强制要求在数据目录中注册注册内容包括：业务定义、数据Owner、安全等级、预期更新频率未注册的资产无法进入数据服务目录（不被消费端发现） 2. 自动化采集 数据目录自动采集技术元数据（表结构、分区、血缘）减少人工录入负担，保证元数据的及时性和准确性 3. 质量基线校验 新接入的数据表需通过质量基线校验（如关键字段非空率≥95%）校验结果在数据目录中展示，帮助用户判断数据可信度 4. 分级分类打标 根据数据敏感度自动或人工打标（核心/敏感/内部/公开）标签用于后续的权限控制和数据脱敏4.2 找数：让数据“找得到、找得准” “找数”是数据目录最核心的用户场景。目标是将用户找数据的时间从“几天”缩短到“几分钟”。 关键实践： 1. 多维度检索 用户输入：“客户 月均消费” 系统检索： - 表名包含“customer”或“cust” - 字段包含“月均消费”或“avg_amount” - 业务定义包含“客户消费” - 标签包含“客户分析” 返回结果按相关性排序 2. 智能推荐 基于搜索历史推荐：用户搜索过“客户画像”，推荐相关的“客户标签表”基于相似用户推荐：相似角色用户高频使用的数据资产基于血缘推荐：查看某张表时，推荐其上下游相关表 3. 数据预览 搜索结果直接展示数据样例（脱敏后）用户无需申请权限即可预览数据结构，判断是否满足需求 4. 权限申请入口 找到数据后，一键发起权限申请自动识别数据Owner，发起审批流程审批通过后自动开通权限4.3 懂数：让数据“读得懂、用得对” “懂数”是数据目录区别于普通元数据工具的核心价值。目标是让用户真正理解数据的含义和正确使用方法。 关键实践： 1. 业务术语词典 建立企业级业务术语库，统一定义核心业务概念在数据目录中，字段与业务术语关联鼠标悬停即可查看术语定义 示例： 字段名：total_revenue 业务定义：营业收入——企业在销售商品、提供劳务等经营活动中实现的总收入，不含增值税 计算口径：主营业务收入 + 其他业务收入 注意事项：不含营业外收入 2. 指标百科 定义核心业务指标的计算口径和公式指标与数据表/字段关联，明确指标的数据来源支持指标的血缘追溯——指标的分子分母从哪些字段来 示例： 指标名称：客户月均消费额 计算公式：SUM(订单金额) / COUNT(DISTINCT 客户ID)（按月） 数据来源：dws_customer_order_monthly表 关联字段：customer_id、order_amount 注意事项：不含退款订单 3. 数据质量评分 在数据详情页展示质量评分（如满分5分）展示各质量维度的得分情况（完整性、准确性、及时性等）提示用户“此数据质量评分较低，使用时请注意” 4. 使用指南与FAQ 数据Owner维护使用指南：什么场景用、什么场景不能用、常见误区收集用户常见问题，形成FAQ用户可对指南进行评价和反馈 5. 数据故事 用图文方式展示数据的使用场景和业务价值例如：“某业务团队使用此数据进行客群细分，营销转化率提升15%”激发其他用户的使用兴趣五、数据目录的实施路线图5.1 实施三阶段阶段目标关键任务周期第一阶段：基础构建建立数据目录基础能力1. 明确数据目录范围和标准2. 部署元数据采集工具3. 完成核心系统元数据采集4. 实现基础检索功能2-3个月第二阶段：内容丰富让数据目录“好用”1. 补充业务定义和指标口径2. 建立数据质量评分机制3. 实现数据血缘可视化4. 上线数据预览和权限申请3-4个月第三阶段：智能运营让数据目录“主动服务”1. 智能推荐功能上线2. 业务术语自动标注3. 用户互动机制（评分、评论）4. 数据价值评估模型持续迭代5.2 成功关键要素 1. 业务参与 数据目录不是IT的“自嗨”工具。业务部门必须深度参与： 业务术语的定义和审核数据资产的业务标注使用场景的案例分享 2. 质量优先 数据目录不能是“垃圾堆”。低质量、无人维护的数据资产，会降低目录的信任度： 建立数据资产的“准入门槛”（质量基线）定期清理僵尸资产（长期未访问的表）对质量低的数据资产打标警示 3. 激励机制 鼓励用户使用和贡献： “数据资产贡献榜”：展示贡献最多的数据Owner、数据管家“最佳数据目录奖”：表彰标注质量高、使用指南完善的团队数据目录使用情况纳入数据治理考核 4. 持续运营 数据目录不是“一次性项目”，需要持续运营： 定期更新元数据（至少每日）定期审核业务定义的准确性（每季度）收集用户反馈，持续优化体验六、数据目录的常见误区与对策误区表现应对策略把数据目录当技术项目只有IT参与，业务不买账业务Owner主导业务元数据定义；业务KPI纳入数据目录使用贪大求全试图一次性覆盖所有数据聚焦核心业务域，小步快跑；先覆盖数据仓库的“黄金数据”只采不用元数据采集了，但用户不用持续优化检索体验；建设使用场景（如数据权限申请、影响分析）忽视质量低质量数据进入目录，用户不信任建立数据资产准入门槛；质量评分公开透明缺乏运营上线后就没人管了建立数据目录运营机制；定期审计资产质量；收集用户反馈七、让数据目录成为数据驱动的“第一站” 数据目录的本质，是降低数据消费的门槛，让数据从“少数人的特权”变成“多数人的工具”。 当数据目录真正发挥作用时： 分析师不再需要到处问人，打开目录就能找到需要的数据业务人员不再需要依赖技术，自己就能理解数据的含义数据Owner能够清晰了解自己管辖的数据资产和用户反馈管理者能够掌握全局数据资产分布，识别高价值数据 数据目录，是数据时代的“导航”。它指引每一个数据消费者，在浩瀚的数据海洋中，快速、准确地抵达目的地。 了解更多数据治理领域解决方案，请关注gzh：数据如海深难测，关注后，点开私信，获取1.3G数据治理解决方案资料。 |
|
|
| [收藏本文] 【下载本文】 |
| 上一篇文章 下一篇文章 查看所有文章 |
|
|
|
|
娱乐生活:
电影票房
娱乐圈
娱乐
弱智
火研
中华城市
印度
仙家
六爻
佛门
风水
古钱币交流专用
钓鱼
双色球
航空母舰
网球
乒乓球
中国女排
足球
nba
中超
跑步
象棋
体操
戒色
上海男科
80后
足球: 曼城 利物浦队 托特纳姆热刺 皇家马德里 尤文图斯 罗马 拉齐奥 米兰 里昂 巴黎圣日尔曼 曼联 |
| 网站联系: qq:121756557 email:121756557@qq.com 知识库 |