从数据驱动到知识驱动：数据治理+RAG技术推动知识治理与服务的智能化
在人工智能和大数据技术的快速发展下，企业正面临着从数据驱动到知识驱动的转型。RAG（Retrieval-Augmented Generation，检索增强生成）技术作为一种结合了信息检索和生成模型的先进技术，正在成为推动企业智能化转型的重要工具。知识库是企业知识管理和应用的核心平台，通过RAG技术，企业可以动态检索和应用这些知识，显著提升大模型的精确性和专业性，帮助企业更高效地利用内部和外部的知识资源。而数据治理在知识库的构建和管理中扮演着关键角色，通过系统化的治理工作，确保数据质量、安全性、一致性和可用性。两者的结合，为企业提供了更高效、更智能的知识检索和应用能力。RAG：知识管理领域的重要突破RAG技术通过结合信息检索和生成模型，实现了对私域知识的深度挖掘和智能应用。RAG能够实时捕捉新知识，自动更新知识库内容，并通过自然语言处理技术，实现知识的智能检索和生成。它为知识管理带来了以下优势：· 精准知识检索: 利用语义理解和上下文分析，快速定位用户所需的知识点，提高检索效率和准确性。· 自动化知识生成: 根据用户需求，自动生成报告、摘要、FAQ等知识内容，降低人工成本，提高知识产出效率。· 个性化知识推荐: 基于用户画像和行为数据，推荐相关知识和资源，提升用户体验和知识获取效率。· 智能问答系统: 构建智能客服、虚拟助手等应用，为用户提供实时、准确的知识服务。RAG可读取的数据类型RAG技术能够处理多种类型的数据，包括：1.非结构化数据：最常见的类型，包括文本（如百科类知识、领域知识库、论文等）以及图片、视频、音频等多模态数据。2.半结构化数据：包含文字与表格的混合内容，例如带有标签的文档或部分结构化的报告。3.结构化数据：以知识图谱为主，利用企业已经整理和提炼的存量数据，提供更精确的信息。通过向量数据库等技术，RAG能够将以上各种类型的数据转化为统一的数值向量表达形式，便于在企业内部知识库中进行检索和分析。RAG的优势1.解决敏感数据的使用问题企业的一些敏感数据（如商业秘密、客户信息等）不便于直接用于模型训练，但可以通过RAG技术在应用中使用。这种方式避免将这些数据用于微调模型所带来的高成本和权责边界模糊的问题。2.降低训练成本和更新滞后问题RAG技术通过动态检索的方式，能够实时结合最新的企业数据，避免了重新训练模型的麻烦。3.保持大模型与数据的权责分离RAG技术使得大模型提供方和企业之间的权责边界更加清晰。企业可以保留对数据的控制权，而模型提供方只需提供基础的大模型能力。数据治理+RAG提升知识检索和应用能力数据治理为知识的生成、管理和应用提供坚实的基础。下面我们来探讨一下数据治理与RAG技术是如何结合的：1.数据上下文补全通过数据治理确保RAG技术能够动态检索知识库中的数据，为大模型提供更完整的上下文信息，并通过数据标准化和整合，消除数据孤岛，确保上下文信息的全面性和一致性，从而提升大模型的输出质量。2.数据整合与关联知识库需要整合来自不同来源的数据，并建立数据之间的关联关系。通过数据模型的管控，确保数据关联关系和外键的准确性和完整性，为RAG技术提供清晰的逻辑结构；并通过数据血缘分析，追踪数据的来源和流向，确保关联关系的可追溯性。3.元数据管理元数据是描述数据的数据，如数据表的中文名、字段含义、数据来源等。通过对元数据管理，确保表中文名和字段中文名的准确性和一致性，便于用户理解和使用数据。同时，元数据的版本控制和更新机制，可以确保元数据的时效性，为RAG技术提供最新的数据描述信息。4.业务域为导向以业务域为导向的知识库能够更好地满足具体业务需求。通过企业的业务领域（如财务、人力资源、供应链等）划分数据，确保知识库的结构与业务需求相匹配；并通过业务键（如订单号、客户ID等）唯一标识业务实体，确保知识的准确性和一致性；同时通过定义和管理业务规则，确保知识库中的知识符合业务逻辑。5.数据安全管理知识库中的知识往往涉及企业的核心业务数据和商业秘密，企业需要建立完善的数据治理体系，在确保知识库的安全性和合规性的同时平衡知识的开放性和保密性。通过权限管理，确保只有授权用户能够访问和操作知识库中的数据，并对敏感数据进行加密存储和传输，防止数据泄露。同时，记录数据访问和操作日志，可以及时发现和处理安全风险。总结RAG技术与数据治理的结合，为知识治理与服务的智能化提供了新的可能性。通过数据治理，企业可以确保数据的质量、安全性和可用性，为RAG技术的应用提供坚实的基础。而RAG技术则通过动态检索企业内部的专有知识，为大模型提供更精确、专业的支持，同时避免了敏感数据用于模型训练所带来的成本和权责问题。在未来，数据治理与RAG技术的深度融合将进一步推动知识治理与服务的发展，帮助企业在激烈的竞争中脱颖而出，引领行业的创新与变革。参考文章：《治理之智 | 检索增强：解决企业“上云用模”的数据安全隐忧》;文章图片来源于网络，如有侵权，联系小编删除
查看详情
数据流动的密码：揭开血缘关系的全貌
数据血缘描述了数据从源头到目的地的流动和转换过程，尽管各类业务利益相关者对数据血缘的期望和需求各不相同，但对其核心认知是一致的。本文将深入探讨数据血缘的不同类型及其依赖关系，帮助大家更好地理解这一复杂但关键的主题。一、数据血缘类型的全貌主题：数据血缘可以分为元数据血缘和数据值血缘。元数据血缘关注数据的处理和转换文档，而数据值血缘则侧重于数据实例层的转换和跟踪。层次：数据血缘可以在四个层次上记录：业务层、概念层、逻辑层和物理层。不同层次使用不同的元数据来描述数据血缘。方向：根据数据血缘的方向，可以分为横向数据血缘和纵向数据血缘。横向血缘展示数据从起点到终点的流动，而纵向血缘则连接不同层次的数据组件。方法：数据血缘的记录方法分为描述型和自动型。描述型血缘通过手工记录元数据，而自动型血缘则通过自动化工具采集和记录元数据。数据血缘分类概念图1、元数据血缘和数据值血缘数据血缘的主题可以分为元数据血缘和数据值血缘，不同的利益相关者对每种血缘类型的关注点也不一样。元数据血缘数据管理和IT专业人员通常将数据血缘理解为由元数据进行的数据处理和转换文档。元数据血缘可以在任何抽象层记录描述，不同层次使用不同的元数据。数据值血缘业务利益相关者更加关注数据实例层的转换，希望看到整个数据链中跟踪数据值的变化。例如，如果管理报告中总收入为100万欧元，他们希望将它追溯到单个合同金额以及了解从合同金额到100万欧元间的转换规则。这种需求被称为“数据值血缘”，通常只在物理层记录。因此，在与不同利益相关者群体进行沟通时，应该考虑到元数据血缘和数据值血缘间的差异。2、不同记录层的数据血缘数据血缘的记录层次包括业务层、概念层、逻辑层和物理层。详情可点击《数据血缘元模型：架起业务与技术的桥梁》这篇文章查看。此外，还想强调以下两点：· 不同企业采用不同数量的层级和组件来描述数据血缘，且对这些层级的命名和定义也各有差异。· 根据我的实践经验总结，建议分类是基于通用实践的，每家企业应根据自身需求选择适合的分类方式。3、横向和纵向数据血缘数据血缘记录的方向分为横向和纵向数据血缘，如下图。自由格式的数据血缘元模型横向数据血缘是最常见的数据血缘类型，描述了数据链上两个位置之间数据路径的数据血缘，展示数据从创建点到应用点的流动。可以在业务层、概念层、逻辑层和物理层上记录横向数据血缘。纵向数据血缘是链接不同层级中组件的数据血缘。例如业务主题域、数据实体、数据属性以及数据库表和列之间的关系。4、描述型和自动型数据血缘数据血缘的分类依据之一是记录方法，这是第四个关键因素。记录方法主要分为描述型和自动型两种。描述型数据血缘：指将元数据数据血缘手工记录到数据存储库中。自动型数据血缘：将通过实施自动扫描并采集元数据的过程，并将元数据数据血缘记录到存储库中。这两种方法各有其适用的场景，同时也具备各自的优点和局限性。可从以下几个方面来选择数据血缘的记录方法：1）数据模型层描述型数据血缘适合在业务层、概念层和逻辑层记录元数据血缘，但在物理层手工记录数据血缘是非常困难的。以我的实践经验为例，整理包含数千行数据的Excel文件可能需要耗费数百个工时，效率极低。相比之下，自动型数据血缘更适用于采集物理层的数据血缘信息。但需要注意的是，从逻辑层到物理层的数据血缘映射，通常仍需通过手工方式完成，以确保准确性和一致性。2）所需资源无论是创建还是维护阶段，数据血缘的记录都是一项时间和资源密集型的工作。我们需要持续关注数据血缘的变化，并及时调整。自动型数据血缘在初始阶段，创建读取和上传元数据的自动化流程需要大量资源；之后，随着新版本的发布，数据血缘信息应能自动更新；然而，如果涉及新应用程序，则需要手工编码来完成。描述型数据血缘，在设计和维护阶段需要持续投入资源。二、数据血缘间的相互依赖之所以想分享下各种数据血缘之间的依赖，是因为在实践中，我经常遇到有关沟通数据血缘的挑战。比如：元数据架构师说：“我们要开发一个横向数据血缘的未来态架构(FSA)。”我的第一反应是：”在哪个层上？横向数据血缘可以在四个层级上记录。”很明显，元数据架构师说的是物理层元数据血缘，只是将其简称为横向数据血缘。我们先来分析这些数据血缘间可能的组合和依赖，如下：数据血缘的主题与其他数据血缘分类之间的依赖关系· 数据血缘的主题和数据血缘的记录层级元数据血缘可在被记录在每个抽象层级上，记录的元数据组件和元素会有所差异。无论何种情况，元数据血缘都用于描述数据流和数据转换的过程。而数据值血缘仅能在物理层记录，本文仅针对物理层中存在的数据实例进行讨论。· 数据血缘的主题和数据血缘的记录方向元数据血缘可从两个方向进行记录：横向数据血缘展示数据沿数据链的流动路径，而纵向数据血缘则连接不同抽象层级的元数据组件。数据值血缘仅能记录在横向数据血缘中，因为数据实例仅存在于物理层。· 数据血缘的主题和数据血缘的记录方法元数据血缘的记录可采用描述型和自动型方法，而数据值血缘由于仅存在于物理层，因此更适合通过自动型方法进行记录。数据血缘的记录方法和记录层级之间的依赖关系· 数据血缘的记录方法和数据血缘的记录层级记录数据血缘的描述性方法适用于所有层级。在实践中，我曾见过使用Excel或Word文件记录物理层数据血缘的情况，但这是一种最不推荐的方式。描述性方法更适合用于记录业务层和概念层的数据血缘，因为这些层级缺乏自动记录的方法。对于物理层，强烈建议仅采用自动型数据血缘记录方法。逻辑层则是一个分区：逻辑模型既可以通过逆向工程从物理模型中生成，也可以在数据建模工具中手动创建。综上所述，数据血缘作为数据管理中的核心概念，其复杂性和多样性要求我们在实际应用中采取灵活且系统化的方法。通过深入理解数据血缘的四大因素——主题、层次、方向和方法，希望大家能够更好地满足不同利益相关者的需求，并有效应对数据管理中的挑战。无论是元数据血缘还是数据值血缘，无论是横向还是纵向数据血缘，亦或是描述型与自动型记录方法，每种类型都有其独特的应用场景和优势。在实际操作中，企业应根据自身的业务需求和技术架构，选择合适的数据血缘记录方式，并确保其与整体数据治理策略保持一致。同时，随着数据环境的不断变化，数据血缘的记录和维护也需要持续投入资源和精力，以确保其准确性和时效性。
查看详情
数据血缘元模型：架起业务与技术的桥梁
在当今数据驱动的商业环境中，数据血缘（Data Lineage）已成为确保数据透明性、可追溯性和合规性的关键工具。数据血缘不仅帮助组织理解数据的来源、流转和变化，还为数据治理、数据质量管理、审计和业务决策提供了坚实的基础。本文将深入探讨数据血缘元模型的结构，从业务层到物理层，逐层解析其核心组件和逻辑，并结合实际应用场景，帮助读者全面掌握数据血缘的构建与应用。一、数据血缘元模型的结构数据血缘元模型是描述数据血缘模型的元数据框架，它通过不同抽象层（业务层、概念层、逻辑层和物理层）来记录数据的流转路径。每个层次都有其独特的组件和元数据元素，共同构成了完整的数据血缘体系。数据血缘元模型的核心目标是通过分层结构，确保数据从业务需求到技术实现的完整映射，从而支持数据的全生命周期管理。数据血缘元模型的结构■ 业务层业务层是数据血缘的起点，其核心是满足业务利益相关者的需求。业务层的主要任务是将业务需求与数据流转路径进行映射，确保数据的业务价值得以体现。业务层的主要组件包括：业务能力：业务能力描述了组织的核心能力，描述业务能力的两个元数据是：业务能力层次、实现维度；业务能力层次分为战略能力、核心能力和支持能力；而流程、工具、角色及数据等可以实现业务能力。流程：流程是实现业务能力的具体活动，可以分解为子流程或活动链，通过使用流程来记录业务、技术和操作元数据。角色：在数据血缘场景中，角色可以分配给各种对象，例如组织、特定人员和IT系统/应用程序。业务主题域（数据）：业务主题域是描绘业务能力所需数据的蓝图。以客户管理为例，其业务主题域聚焦于客户数据的方方面面。业务主题域是在最高抽象级别上描述数据的元数据元素。IT资产：对于数据血缘来说，“IT资产”是指IT系统、应用程序、数据库和ETL工具。业务层的概念图在业务层数据血缘组件中，最首要的是业务能力。流程支持一个或多个业务能力，角色和IT资产支持流程的实现，角色使用IT资产完成工作，业务能力定义了业务主题域。业务层的关键作用：通过业务能力、流程和角色的映射，明确数据的业务价值。通过IT资产和业务主题域的定义，确保数据与业务需求的一致性。■ 概念层概念层是数据血缘的中间层，其主要任务是定义数据实体及其之间的关系。概念层通过语义模型，确保业务术语和定义的一致性，为逻辑层的数据建模提供清晰的业务上下文。概念层模型的概念图概念层包括数据实体和它们之间的关系。业务规则标识了不同数据实体之间的约束。数据实体具有唯一业务术语和相应定义。业务术语和定义在概念层内容中保持唯一。在概念层中，业务元数据元素描述数据血缘的组件，包括：所有者所有者是负责描述和维护组件的角色。创建、修改、删除日期表示对象生命周期的阶段状态关系类型概念层的核心价值：通过语义模型，解决传统概念模型在业务术语和定义上的不足。为逻辑层的数据建模提供清晰的业务上下文。■ 逻辑层逻辑层是数据血缘的核心建模层，其主要任务是将概念层的数据实体和业务规则转化为具体的数据模型。逻辑层通过定义数据实体、数据属性和业务规则，确保数据的准确性和一致性。逻辑层主要包括以下组件：数据实体：是逻辑数据模型中的元数据对象，用于标识、描述或度量业务主题如客户、订单等。数据属性：是逻辑数据模型中的元数据组件，用于标识、描述或度量数据实体。如客户姓名、订单金额等。数据元素：数据元素是一个“在语境中不可分割的数据单元”。这意味着数据实体和数据属性在不同语境中都会是数据元素。数据实体是概念业务模型中的数据元素，而数据属性是逻辑模型中的数据元素。逻辑层的概念图数据血缘在逻辑层的首要组件是数据实体。一个数据实体有一个或多个数据属性；同一抽象层的数据实体和数据属性相互间有对应关系；业务规则定义了适用于数据元素或数据属性组合的条件和限制；数据实体和数据属性都在具体内容中有唯一业务术语和定义。在逻辑层中，业务元数据和技术元数据都可以描述数据血缘的组件：业务元数据：逻辑模型本身就是元数据对象，因此对于逻辑模型及组成它的元数据对象，都需要记录其所有者。技术元数据：根据DAMA-DMBOK2(31)，应将以下元数据元素识别为数据属性-数据实体或属性的标识符和名称-数据值域：这是数据元素的所有允许值清单。-数据类型：数字、日期和时间是数据类型实例。逻辑层的关键特点：数据实体和数据属性之间的关系清晰可见。业务规则定义了数据的转换和验证逻辑，确保数据的准确性和一致性。■ 物理层物理层是数据血缘的技术实现层，其主要任务是将逻辑层的数据模型转化为具体的数据库结构和ETL作业。物理模型的关键需求之一是有能将逻辑数据模型和物理数据模型之间的元数据对象连接在一起。例如，如果采用关系数据库，数据实体应对应于一个或多个数据表，数据属性对应于一个或多个数据列，如图所示：物理层的概念图各种自动型数据血缘解决方案可能记录各种各样的物理层的元数据组件。例如SAS数据血缘应用程序能记录SAS应用程序中使用的400多个元数据对象，因此，元数据组件、组件间的关系类型，以及描述组件的元数据元素等记录内容，会因企业的实际情况及需要记录的物理层数据血缘的选择而变化。二、业务规则：数据血缘的核心挑战业务规则是数据血缘中最复杂的组件之一，其挑战主要体现在：术语多样性：不同语境下，业务规则的定义和表示方式不同。层次依赖性：业务规则在概念层、逻辑层和物理层有不同的表现形式。技术实现：隐式规则（如嵌入程序逻辑的规则）难以记录和分析。业务规则的分类：概念层：约束是定义特定数据实体的特征或描述不同数据实体间关系的规范。逻辑层：根据业务规则目的，至少可以分为两种类型：转换规则和验证规则。转换规则：数据间的转换规范，定义一个数据属性或一组数据属性应该进行的转换方式，以创建新的数据属性。通常，新创建数据属性的值与原始数据属性的值不同。转换规则的例子有计算、聚合等。验证规则：一种控制数据属性的值与预定的质量需求间的对应规范。验证规则可以应用于单个数据属性或一组数据属性。物理层：逻辑层确定的转换或验证规则在物理层转变为用编程语言编写的程序代码。物理层的业务规则可以在（数据链）不同位置上执行，有显式规则和隐式规则两类。隐式业务规则是指那些嵌入在程序逻辑中的业务规则。显式业务规则存储在一个数据库中。业务规则的概念图三、总结数据血缘元模型通过业务层、概念层、逻辑层和物理层的逐层细化，为企业提供了全面的数据流转视图。它不仅帮助满足法规需求，还支持业务变更、数据质量管理和审计需求。然而，记录和管理业务规则仍然是数据血缘的最大挑战，需要企业在技术和业务层面投入更多资源。随着数据技术的不断发展，数据血缘将更加智能化和自动化，为企业提供更高效的数据管理解决方案。未来，数据血缘将不仅仅是数据治理的工具，更将成为企业数字化转型的核心驱动力。
查看详情
数据血缘：企业数据管理的“胡萝卜与大棒”
企业通常有强大的驱动因素来启动数据管理，特别是数据血缘工作。这些工作可能会带来许多与所需资源相关的挑战。这些驱动因素通常同时扮演“胡萝卜和大棒”角色。因此，企业应该在实现数据血缘的需求和实施后带来的收益间寻求平衡。本文将深入探讨数据血缘的四大业务驱动因素。· 满足法规需求· 业务变更· 数据管理工作· 审计需求一、满足法规需求随着全球监管环境的日益复杂，企业面临着越来越多的法规要求。数据血缘作为一种强大的工具，能够帮助企业满足这些法规需求。例如，巴塞尔银行监管委员会发布的《有效风险数据汇总和风险报告原则》（BCBS 239）、欧盟的《通用数据保护条例》（GDPR）等，都要求企业具备高度的数据透明度和可追溯性。尽管这些法规文件并未直接提及“数据血缘”，但数据管理专业人员通过分析法规需求，将其转化为数据管理语言，特别是数据血缘模型，从而确保企业合规。例如，BCBS 239和GDPR的翻译实例展示了如何将法规需求与数据血缘组件（如业务流程、IT资产、数据模型等）进行匹配。到目前为止，将这些法规需求与特定的数据血缘组件间进行匹配，确定了以下组件：· 业务流程· 涉及的业务职能和角色· IT资产，如系统、应用程序、数据库、网络· 概念层、逻辑层和物理层的数据模型· 以ETL过程的形式实现的业务规则及其技术实现二、业务变更企业在经营过程中，会经常处理各种类型的业务变更，比如信息需求的变化、应用程序环境的变化、组织结构的变化。影响分析和根因分析是执行这些变更时要用到的工具。记录数据血缘对完成这些分析有很大的帮助。1、影响分析影响分析允许自始至终跟踪数据链上的变化。数据库内的变化也需要进行影响分析。这些变化会影响数据链上的后续数据库和最终报告。数据血缘有助于预测整个数据链上必需的变化。2、根因分析新的信息需求需要进行根本原因分析。根因分析有助于从数据应用点回溯到数据源点。这些分析结果将可以：· 说明数据需求· 评估所需数据的可用性· 评价潜在的数据源数据血缘能简化根本原因分析的执行。三、数据管理举措数据质量、参考数据和主数据管理、数据仓库和商业智能(DWH和BI)，以及数据集成都是重要的数据管理能力，需要数据血缘作为输入来完成它们的活动。1、数据质量如果没有数据血缘支撑，有两类数据质量关键活动就很难得到执行。· 解决数据质量问题：通常信息问题是在数据和信息链末端发现。大多数信息问题的突出问题是报告数据的不一致。为了找出问题原因，需要对数据转换进行彻底而详细的逆向分析。· 聚焦于数据问题的预防：通过收集数据和信息质量要求，并在数据和信息链上构建数据检查和控制来实现预防。2、参考数据和主数据参考数据和主数据是组织中共享和使用最多的数据。要正确地管理这些数据，需要协同数据源。数据血缘允许跟踪参考数据和主数据的来源。它还可帮助优化使用这些数据的数据链。3、DWH和BI，数据集成从DWH和BI的角度来看，优化数据集成过程是有效利用IT资源的关键。被记录下来的数据血缘和业务规则有助于数据转换更加透明。四、审计需求财务和风险专业人员花费大量时间来满足审计要求。这些要求集中在对报告中数字的解释。这项任务需要数据链上数据转换的知识。正确记录的数据血缘有助于提供数据的可跟踪性和透明性。五、结语数据血缘不仅是企业满足法规需求的工具，更是业务变更、数据管理举措和审计需求中的关键支撑。通过实现数据血缘，企业能够在复杂的数据环境中保持透明、可追溯和高效，从而在激烈的市场竞争中脱颖而出。注：文章来源《数据血缘理论与业务实践》
查看详情
数据新时代：如何选择现代数据治理平台
谈现代数据治理系统的十大架构特征最近一位老友找到我，咨询他的数据治理平台到底该不该换，背景是这样的：若干年前采购了一个市场主流的数据治理平台，功能大概就是数据治理三件套——标准、元数据和质量等经典数据治理的功能。现在企业要信创，该平台无法支持上云、新数据库等诉求，原厂也不再提供升级支持。这位朋友考虑到动迁成本以及多年累积的付出，犹豫是否再缝缝补补凑合一阵子。这种情况在市面上还是比较普遍的，经常有某客户抛弃老平台，重新采购新系统的案例。（这点不得不说，相比于西方企业市场，我国企业的外购系统的生命周期明显偏短的，具体个中原因暂且不表）。如果您也是正在做类似平台的选型，除了关注功能，更要关注到基础架构层面，那才是工具长期可持续的保证。作为一家专业的数据治理产品提供商，在最近发布的Datablau产品7x版本的研发中，我们也一直在探索，如何让产品在企业运营中可持续发展，如何保护客户的投资，如何让产品在客制化和标准化之间平衡，并保持持续的升级能力。这里结合我们的实践，谈一谈现代数据治理平台，具备的十大架构特性，供您参考。基础架构特征（上）现代应用程序架构的特征反映了当前技术的发展趋势和业务需求的变化。随着云计算、容器化、微服务、人工智能等技术的普及，应用程序的架构也变得更加复杂、灵活、可扩展和高效。以下是现代数据治理平台架构的一些主要特征：1.微服务架构微服务架构（Microservices Architecture）是一种将应用程序分解为一组小的、独立的服务架构模式。每个服务都围绕一个特定的业务功能构建，能够独立部署、扩展、开发和维护。特征：· 高度的模块化，每个服务独立运行，且可以使用不同的技术栈。· 独立部署、扩展和更新。· 服务之间通过API通信。微服务是云化时代软件架构的基本特征，数据治理平台的早期版本功能是单一的，大多是个前后端一体的单体应用程序。随着企业数据量增加和数据管理活动的细化，已经演化为一个复杂的应用程序，它包含了多个数据治理功能域，如标准、元数据、质量、安全、资产等，与数据领域的生态系统，如数据开发、服务、BI、分析等都有了集成应用。所以现代数据治理系统已经是一个贯穿开发，投产，生产三个环节的，一个企业级的综合数据治理平台。微服务架构让这个平台更容易云化，实现高可用，生态集成，在大数据量下提高负载能力和稳定性。当然微服务的粒度是个架构哲学问题，把握应用与分工的平衡性非常重要。在Datablau平台中共有20个左右的微服务，涵盖了原子的业务模块和公共的服务模块和基础设施模块等。《Datablau平台微服务架构》2.API驱动架构开放API成为现代应用程序架构的核心。应用程序通过RESTful API、GraphQL或gRPC等接口进行服务交互和数据交换。这种架构使得系统能够与外部系统进行集成，并且提供灵活的通信方式。特征：· 标准化的接口，简化服务间的通信。· 支持跨平台访问和异构系统的集成。· API文档（如OpenAPI）成为接口规范的重要部分。正如在《Datablau平台微服务架构》所述，早期的应用系统用JSP这种前后一体程序构建，虽然开发调试成本低，但是带来了耦合性和封闭性的弊端，所以现代软件平台必须是API驱动的前后分离的。3.事件驱动架构（EDA）事件驱动架构基于事件的触发和响应进行工作。应用程序中的事件（如用户行为、系统变化等）会引发一系列的操作和流程。这种架构适用于高并发、异步处理和实时响应的场景。特征：· 异步处理和消息队列（如Kafka、RabbitMQ）用于事件的传播和处理。· 支持实时数据处理和流处理。· 提高系统的解耦性和可伸缩性。Datablau产品中主要通过Kafka建立多服务的信息同步通道，记录跨服务的日志和对象状态同步，保证多服务间的事务最终一致性。参考上图《Datablau平台微服务架构》。4.API网关和服务中心API网关：用于处理和管理客户端请求，负责路由、负载均衡、认证、日志等功能。API网关通常作为所有微服务的入口点。服务中心：服务中心是一个基础设施层，提供微服务之间的通信、监控、安全和管理功能，通常与容器化和Kubernetes集成。特征：· 简化客户端与后端微服务的通信。· 提供流量控制、负载均衡、故障恢复、认证授权等功能。· 支持微服务之间的可靠通信和可观测性。Datablau产品中主要通过Gateway建立API路由通道，管理微服务的入口点，进行多服务的系统集成和参数配置。参考上图《Datablau平台微服务架构》。5.用户体验（UE）现代应用程序对用户体验（UE，User Experience）的要求比以往任何时候都更为严格和复杂。随着互联网和移动应用的普及，过去工业化风格的UI已经无法被习惯好的UE体验的用户所容忍。作为一个数据管理应用，其用户也跨出了数据管理人员的范围，更多角色包括业务侧人员的加入，让好的UIUE已经成为衡量数据治理平台是否更容易推广的重要指标之一。专业的UIUE是一个专业的领域，主要的内容包括简单直观的界面，减少学习成本、功能流畅等，现代的数据治理平台在此基础上更加强调：智能化体验：随着人工智能和机器学习的普及，现代数据治理平台不仅仅是工具，还需要通过智能化功能提升用户体验和工作效率。例如：智能推荐、自动化建模等智能功能，可以大大提升用户的交互体验。互动性体验：主动元数据治理（Active Metadata Management）是近年来流行的数据治理方法，数据治理平台需要有主动驱动的功能支持，在数据设计与加工过程中，通过通知、互动、联动等智能化方式，达到第一时间进行数据治理的目的，事半功倍。《Datablau元数据平台界面》以上介绍了一个现代数据治理平台，应该具备的基础软件架构，它保证了应用程序的云化能力、开放性和易用性等核心的架构能力。那么作为数据领域的应用，还需要一些高级的架构特性，来应对大数据量，迭代迅速的数据工具生态、成本效益考量等核心问题。高级架构特征现代数据治理平台是一个面向数据的企业级的现代应用，其需要特别的架构来适应快速发展的数据行业，适应大型企业的客制化需求，提高应用平台的可维护性。如下特征是我们在Datablau 7.x系统中重点打造的能力。1.数据库插件化近年来，国产化的数据库获得了蓬勃发展，在企业应用中也是百花齐放，接到了一个前所未有的数据库支持请求，这种情况在数据管理领域其实并不罕见。同时国产数据库还在快速发展中，版本迭代的连续性和兼容性问题都很大，意味着不同版本和方言的支持也是很重要的。数据库插件通常包含原生数据库驱动和采集插件两个部分，它们是可以热插拔的，也就是可以不停掉程序，进行更新支持。插件需要支持版本的隔离和类空间隔离，保证同类不同版本数据库可以在平台同时采集。《Datablau平台数据库驱动和插件管理》2.元模型驱动元模型（Metamodel）是描述模型的模型，是元数据的元数据，它提供了一个抽象框架，用于定义、描述和约束其他模型的结构和行为。换句话说，元模型本身是对特定领域或系统中各种模型的结构、关系、元素等规范化的描述。它不仅定义了模型的组成部分（如对象、属性、关系等），还规定了这些组成部分如何组合和交互。元模型的定义要素：1)对象：元模型描述的基本构建块，通常是“类”或“实体”，它们在具体模型中可能对应数据对象或业务对象。例如，在数据管理领域，元模型中的元素可以是“数据表”、“字段”、“数据类型”等。2)属性：这些是元素的特征或属性。在元模型中，元素可以具有不同的属性，比如数据类型、约束条件、默认值等。3)关系：元模型定义了元素之间的关系，这些关系可能是层次结构（如继承）、关联、依赖等。在数据管理中，这些关系可能是表与表之间的外键关系，或数据对象之间的依赖关系。4)约束：元模型还会规定哪些规则和约束是必须遵守的，比如数据格式要求、参照完整性、唯一性约束等。这些约束确保了模型及其实例的一致性和有效性。元模型驱动（Metamodel Driven）是现代数据治理平台的重要能力，通过定义所管理的数据对象的构成和规则，使得复杂的数据对象可以得到抽象化表示，使得这些对象可以共享相同的结构或规则，减少冗余和重用能力。其最重要的价值是快速应对业务需求或系统变化，支持定制和扩展。Datablau数据治理平台广泛具有元模型驱动的能力，根据数十年模型领域的积累，将元模型分为三层架构。《Datablau元模型架构》特别需要注意的是，元模型带来高扩展性好处的同时，也带来了一些副作用：· 过于专业，对于终端用户定义元模型要求很高。Datablau产品中特别有UDP（user defined property）这种动态的元模型，给到用户快速定义扩展的属性，简单易用。· 元模型高度抽象，底层数据存储非常集中，导致数据访问的性能降低。Datablau产品中主要通过缓冲层进行提速，大量使用了ES，Reddis和图数据库进行提速。· 过于通用的界面，导致用户难以使用。Datablau产品中主要通过开发个性化UI，从用户视角进行UE设计，将高难专业的内容进行包装，对于用户使用产品非常容易。3.二次开发解耦二次开发通常是指在已有的商业软件、开源软件或者平台上进行二次开发，以满足特定的业务需求、实现个性化功能或集成其他系统。在二次开发的过程中，架构设计尤为重要，它决定了系统的可扩展性、可维护性、灵活性和稳定性。数据治理系统是一类特殊的管理系统，在国情下存在各行各业的管理流程不一致的情况，造成比较频繁的定制开发需求。目前国内大部分厂商的产品大多是基于产品源码进行开发，这种开发应该称之为一次开发，即产品定制开发。产品定制开发造成的问题是比较多的，尤其是产品架构二次开发架构不好的时候，会造成系统的大规模质量衰退，同时，定制的系统长期维护成本是非常高的，以至于系统处于无法更新升级，处于安全的风险之中。Datablau 7x系列产品采用全面的二次开发架构，支持高扩展，低成本，长期可维护的二次开发能力，支持三种模式，可混用搭配：· API集成开发：通过Restful API进行二次开发是成本最低，质量最可靠的开发方式，大量的系统集成，功能自动化等使用此方式。这种开发方式的局限是无法浸入式功能和UI扩展。· SDK二次开发：通过SDK二次开发是开发能力更强的一种方式，它可以调整UI，扩充系统能力。这种开发方式的局限是开发曲线较长。· 插件式二次开发：通过Plugin的扩充可以对系统的特定部分进行能力扩展，比如集成和数据库插件等。这种开发方式的局限是只能在特定支持的部分扩展。《Datablau二次开发架构》4.信创支持未来几年内，数据治理平台对于国产信创系统的支持，已经成为一个刚需和必选的能力项。Datablau 7x系列产品全面支持新的信创系统架构，完成了与主流厂家的认证，同时具备快速支持能力。参考清单如下（不是最新）：《Datablau信创支持证书清单》5.自动化与智能化数据正在呈爆炸式增长：每天估计会产生2千万亿字节的数据。鉴于数据的规模和速度，自动化和智能化的数据治理越来越有必要，以确保用户能够找到并使用相关的数据。目前AI与数据分为两个方向，即AI4Data 和 Data4AI。大模型提供商和训练者更关注Data4AI，旨在为AI训练提供更高质量更合规的数据集。在本文中更关注的是AI4Data，就是如何利用大模型和AIGC技术，赋能数据治理活动，减少付出的人力成本。在可见的未来，智能驱动（AI-Powered）的数据治理平台将成为标准化的能力。Datablau 7x系列产品已经引入了全新的AI Center模块，作为自动化与智能化的数据智能中心，与数据治理平台进行生态集成。参考架构如下：《Datablau AIC智能治理》AIGC作为一个新兴的技术，让我们对其带来的解决问题的能力给与了较高的期望。我们已经在如下方面取得不错的效果：· 数据语义的生成：对于数据中的元数据语义，通过AIGC进行自动补全。· 智能数据分类：AIC可以根据数据的内容或特征，自动进行分类和分组。自动识别其主题、类别或类型，并进行标注。· 数据标准的生成：AIC可以根据数据的内容或特征，建立适合行业的数据标准，并对数据标准的分布进行智能推荐。· 质量自动评估：AIC可以分析数据集的完整性、准确性、一致性、及时性等维度，自动评估数据质量，并提出优化建议。我们已经取得不错的进展，伴随AI增强的数据管理能力还在不断的探索和成熟中，我们未来会进一步更新我们的进展。总结从2014年以来，数据治理平台已经演化为一系列生态服务集成的大型应用程序集合，这和十年前的平台完全不是一个量级的产品。试图自研该系统的企业越来越少，一方面是成本效益的考量，另一方面市场的产品成熟度已经到达一定程度。作为数据治理产品的专业提供商，我们具有二十几年的产品设计开发经验和数据治理的Knowhow能力，立志为企业提供专业的、架构优良的、技术先进的、易用好用的数据治理平台，并与客户一同成长，保持平台的升级与演进，让用我们平台的企业永远走在数据治理的前沿!
查看详情
数据治理2025年的趋势与展望
序言2025年初，蓝天暖阳，春天正在走近。然而我们仍能感到经济的寒冷，全球政治波谲云诡，局部战争硝烟弥漫，贸易战此起彼伏，经济持续下行。在这样的大环境之下，企业经营面临外部环境的挑战，如何推进或保住主营业务，数字化转型要如何开展，数据治理要如何持续，如何持续以前的数字化投资，这都是企业管理在做预算规划时，所面临的战略难题。作为数据治理一线的参与者，通过我们遍布各行各业的客户群体，根据对当下数据治理进展的理解和观察，分享数据治理2025年发展趋势的观点，供您参考。目录 序言 1.数据治理的持续投资与深化应用 2.数据治理的自动化与智能化 3.架构驱动的数据治理 4.数据治理左移与源头治理 5.数据血缘治理 6.数据资产的价值外延 7.数据中台的归位，与数据治理的再融合 8.数据安全，监管强化与信创 其他观察与说明 结语：数据治理人的使命一、数据治理的持续投资与深化应用鉴于严峻的外部环境，特将数字化与数据治理的持续并深化作为一个首要趋势，它是后面八个趋势的基础。根据宏观机构报告，当下企业超越周期的策略，如果用两个字总结就是“经营”，2025年将是企业的运营之年，数据分析则是经营必备的手段，这个过程中数据治理在业务、IT和数据三个方面是必须要持续投资的：1）业务战略，聚焦主业在2025年，中国乃至全球很多行业都已经进入存量经济状态，企业选择聚焦主业，精简业务结构，提升核心竞争力。在全球经济下行和市场动荡中，专注于最具增长潜力的领域，优化资源配置，提升效率，才能在激烈竞争中立足并实现长期可持续发展。在这个背景下，进行数据治理，运用数字化和AI技术，加强精益经营，尤其是大型企业，这将是必然和唯一的选择，因为我们已经到了精益经营的阶段。图1：《企业经营ROI》2）IT战略，运营与管理在2025年，企业IT战略将聚焦于加强系统的业务运营和提升IT管理效率。通过优化现有系统，减少重复建设，将更多资源投入到业务赋能上，提升业务响应速度与创新能力。借助新技术推动业务增长，强化数据分析和自动化，确保IT与业务深度融合，助力企业在复杂环境中快速应变、持续发展。很多IT部门面临自证价值的窘境，需要从过去建设新系统进而功成名就的技术思维模式中走出来，多建立业务分析组织，加强与业务部门沟通能力。同时也建议加强架构管理，在应用系统上走向高质量建设，比如在老系统中置入数据洞察和AI助理，可能让业务有惊喜，而投入更少，风险更小。所以IT也应该更加关注数据治理和AI的应用。3）数据战略，去冗存精有人比喻数据是一把照妖镜，可以照出业务的真伪，也可以照出IT建设质量，更可以照出企业资源配置和业务产出(ROI)的关系，帮助企业决策哪里应该继续投入，哪里应该瘦身。然而在今天的大多数企业数据方面的投资还是很少的，可能是IT预算的几十分之一到上百分之一。让企业真的从数据中获得价值，吸引到更多投资，是数据部门的核心任务。总结一下，企业2025年将选择聚焦主体业务，持续用数据精准变革企业。数据人的使命是当好数据的管家，做好数据应用和数据管理上的提升，让企业数据素养水平可持续发展，辅助企业的业务经营的精益和提升。二、数据治理的自动化与智能化如果说近年来有什么最令人期待的技术革新的话，那一定是AI技术。从机器学习（ML）进化到内容生成（AIGC），再到智能体（Agent），AI已经逐步应用到垂直行业和具化的业务场景中。图2：《人工智能时代的数据治理》，来自AWS按照DAMA经典理论，数据治理是PPT（不是PPT忽悠，是People，Process，Technology）的三要素的有机结合与运营闭环。人工智能驱动的数据治理（AI-Powered Data Governance）将是未来的趋势，有望从技术侧的技术革新，减少人员的投入和数据治理流程带来的溢出成本。然而需要注意的是，AI技术并不是数据治理开展不起来的企业的救命稻草，反过来数据治理可能是AI技术在企业应用的救命稻草，这是个很有戏剧性的逻辑，现在已经得到引证，未来会进一步显性化这个趋势。大模型已经逐步部署到企业，AI应用逐步落地，在数据治理领域也有很多探索。目前通过大模型和智能化的算法，在数据语义建模，数据标准化落标、数据质量监控、数据查询和清洗、ChatBI等领域，已经取得不错的效果，我们期待2025年有更多进展。三、架构驱动的数据治理近年来，越来越多的企业将数字化转型和科技赋能上升至组织战略层面，从3A（业务架构，应用架构、数据架构）企业架构视角进行规划和实施，这是符合数据治理发展规律的趋势。在金融业，以银行业的建设银行数据架构方法（ABCD四层模型）为代表，我们看到了其新一代建设的十年后，在股份行和先进城商行进行持续实践和探索，在各行的新一代核心建设中，我们看到经典信息架构的思维，在数据管理领域，重提数据架构的管理与落地。这标志着无论是IT建设还是数据管理的工作，从系统局部走向企业全局，加强企业级别数据标准的统一，目标是实现“一点生成，多处共享，数出同源，口径一致”的管理要求。图3：《业务架构与信息架构的关系》在制造业，以华为的五层数据架构为代表，以业务对象为核心，通过将业务与数据紧密结合，实现了数据的有效管理和应用。具体来说，该架构从L1的主题域分组到L5的属性，逐步细化，确保数据的层次清晰和一致性。在制造业中，华为通过数据架构将生产管理、供应链、设备监控等业务对象进行数字化建模和管理，实现了数据的实时采集、分析和应用。通过数据的标准化和治理，华为确保了数据的准确性和一致性，为制造业的智能化转型提供了坚实的基础。数据治理本身就是企业级的，能够从架构视角出发是业界数据治理实践进步的表现，也是必然的发展趋势。需要注意的是企业仍需从自身出发，深刻了解TOGAF的精神和各种裁剪方案，制定适合自己的开展策略。不要陷入晦涩难懂的方法论陷阱和得其形不得其神的教条主义中。四、数据治理的左移（Shift-Left）数据治理的“左移（Shift-Left）”与源头数据治理将成为2025年的数据治理的重要趋势之一。传统的数据治理多集中在数据采集后的数据清洗和管理，但近年来的数据治理实践发现，事后数据治理事倍功半，随着企业对数据质量和实时性要求的提升，数据治理的重心开始左移——从数据源头开始进行治理。图4：《Shift-Left Data Governance》数据治理左移（Shift-Left）和源头治理是同义理念，国内和国际的两种叫法。了解我们的朋友应该知道，我们从18年以来一直倡导源头治理的理念，并在各行各业有着广泛的成功案例。经常有以本企业对源端开发没有掌控，就认为不适用源端治理的观点，这其实是非常片面的理解，源头治理是一种思想，管控应用开发环节只是这种思想的具体举措之一。实际上这个思想之下，企业任何IT管理模式，都有适用的措施，只要数据对企业是重要的，是要使用的。源头治理意味着，在应用开发、数据采集、数据生产的初期就开始进行规范化管理，避免数据质量问题在后期出现。数据治理的左移不仅仅是技术上的转变，更是管理理念的转型，强调数据质量、数据合规和数据安全的早期介入，从而减少后期的治理成本。五、数据血缘治理数据血缘治理（Data Lineage Governance）简单定义就是对数据从源头到终端的流动路径的管理和应用。随着数据量和复杂度的增加、监管要求的加强，以及数据驱动决策的重要性，数据血缘治理成为企业数据治理的重点，将成为2025年数据治理的重要趋势之一。数据血缘的作用可以简单地总结为以下五条：1)提高数据透明度：清晰显示数据的来源、流向和变更过程，确保数据的可追溯性。2)确保数据质量：帮助识别和纠正数据流转中的问题，保证数据的准确性和一致性。3)指标口径溯源：帮助确定指标加工的路径以及数据问题的根因分析。4)增强数据安全：通过监控数据流动路径，识别潜在的安全风险，防止数据泄露或篡改。5)促进数据驱动决策：帮助决策者理解数据背景和来源，提高分析结果的可信度和决策的准确性。图5：《基于算法和口径的血缘追溯》来自Datablau SQLink数据血缘管理并不是一个新的产物，而是一个存在二十多年的经典数据治理内容。那为什么在2025年会热门起来呢，原因是因为国内的数据治理到了一定阶段，就像街面已经清扫干净，开始关注地下管道的疏导一样，是数据治理深化的必然结果。那么建设数据血缘治理项目，有哪些注意的点呢1.数据血缘治理需要多团队结合，信任是关键数据血缘治理不仅是IT部门的任务，成功的实施需要跨部门的协作和管理, 也依赖于高质量的数据管理。一些企业在实施数据血缘治理时忽视了质量管理工作，只关注技术上的血缘解析，一旦链路不准确，进而影响到后续的分析和决策，则数据部门将失去信任，甚至背负问题责任。2. 自动化工具至关重要，但并非万能在实施数据血缘治理时，普遍采用自动化工具来跟踪和可视化数据流动。自动化工具能大大提高效率，减少人工跟踪和记录的工作量，同时还能确保实时更新和监控数据流向。但是，一些复杂的业务流程或定制的数据处理方式可能无法完全通过现有工具自动化。因此，企业需要结合人工干预和工具的双重优势，以确保数据血缘的准确性和完整性。3. 数据血缘治理需要持续维护现在数据血缘技术基本是依赖于语法解析技术，然而数据库SQL语法也是一个不断升级的，所以需要一个持续的定期更新和维护，避免技术滞后导致的血缘不准确，影响分析结果的不准确和决策的失误。六、数据资产的价值外延在数字经济时代，数据作为一种新型生产要素的地位日益突出，推动了数据资产的财政入表、数据生产要素化及基于数据空间的数据交易的快速发展。图6：《Data Space Architecture》，来自IDSA首先，数据资产的财政入表是指将数据作为国家经济的一部分纳入正式的财政核算体系。这一举措使得数据不再仅仅是企业的资源，而是具有公共价值和战略意义的国家资产。通过明确数据的经济价值，政府能够制定更加科学的政策，推动数据的合理利用与流通。其次，数据生产要素化将数据视为类似土地、劳动力和资本的核心生产要素。现代企业通过收集、分析海量数据来优化决策、提高效率，推动创新。例如，人工智能、机器学习等技术的进步离不开海量的高质量数据，这进一步强化了数据作为生产要素的地位。最后，基于可信数据空间的数据交易平台的兴起，推动了数据的流通与共享。通过这些平台，企业可以在安全合规的环境下交换数据资源，提升数据的利用效率。这不仅促进了不同领域的数据合作，也为各行业带来了创新驱动和竞争优势。总之，数据的财政入表、生产要素化及数据交易，正在推动数据资源的价值化与市场化，成为数字经济发展的重要推动力。七、数据中台的归位，与数据治理的再融合2024年围绕数据中台产生了各种争议话题，有先知先觉的批判，也有恨铁不成钢的惋惜，甚至知名机构给打了个小红叉。作为行业20年数据治理的入局者，始终理性看待每个新技术新概念的出现，我们将数据中台回归本位，继续跟踪数据治理平台的发展与趋势：图7《Modern Data Warehouse》1.企业仍然需要数据汇聚与挖掘计算的基础平台，无论它叫数据中台，还是数智基建，亦或是现代数据仓库（我更喜欢这个叫法）。数据底座层面的技术仍在快速发展（如Lakehouse等），企业也有了更多选择，从实际出发，选择经典Hadoop系列，或是选择迅猛发展的MPP（如Doris），抑或是直接MySQL走起，只要适合企业情况即可。在计算方面，并行计算技术让数据处理越来越快，而维护成本越来越低。2.数据中台与数据治理的融合，数据中台是企业数据治理中非常重要的一部分，是DAMA车轮图中的一个辐条；但是反过来讲则不合适了，道理很简单，就像接不起业务变革这个责任一样，数据中台也接不起数据治理的责任。让我们建立标准化的整合模型，提供统一高质量的数据，提供高性能的数据访问，配合做好企业统一的数据治理，继续做好做强数据中台的本分工作。八、数据安全，监管强化与信创随着数据安全的法律法规的发布，企业大部分实施了数据的分类分级，发布了内部的数据安全管理办法，这些措施已经在逐步发挥作用。监管强化也是明确的趋势，金融行业和银保行业的一表通，逐步发展到了T+1和在线监管的程度。大型的政府和央企组织也已经逐步增强监管的数据范畴，增加数据规则，提高数据的质量。信创，众所周知的原因，正在从核心软硬件到终端软硬件发展。其他观察说明篇幅有限，认知有限，还有很多趋势未观察到，并不代表这些不是未来方向。1.Data Fabric： 数据编织（Data Fabric）是一种通过构建统一的数据架构来实现跨系统、跨平台的数据访问与治理的技术框架。近年来被Gartner标记为趋势，企业受制于IT架构和发展水平，国内仍在探索期，尚未观察到显著案例。2.Data Mesh： 数据网格（Data Mesh）是一种去中心化的数据架构理念，强调将数据治理分散到各个领域中，而非依赖于单一的中心化平台。近年来新兴的概念，虽然被Gartner合并到Data Fabric，但是却有其理念的独特性。在国内仍在探索期，可能因为我们企业的现有治理架构之下，尚无法广泛建立这样的落地实践。3.Active Metadata Management： 主动元数据治理是指能够动态变化并具有自我更新能力的元数据管理理念。在国内仍在探索期，因为企业当前元数据的应用水平和数据使用的群体受限。4.Data Vault Modeling：DV模型是一种高扩展和离散式的建模范式，在国外有广泛的应用。在国内仍在探索期，这可能与我们实施数据仓库的方法与团队，以及云计算等应用有一定关系。结语：数据治理人的使命2025年，企业将迎来更加深刻的变革，数据治理人员肩负着推动企业数字化转型、确保数据质量与安全的重要使命。在这个充满挑战和机遇的时代，让我们勇敢地承担起这个时代赋予我们的责任，持续推动数据治理的深入实施，帮助企业在时代洪流中找到前行的方向。同时也不断提升自己，成就自己，共勉！
查看详情
数据血缘在保险行业的应用探索
一、引言（一）数据与数据管理数据是记录并保存客观事件的一种符号，是客观存在的资源。2020年4月9日，中共中央、国务院发布了《关于构建更加完善的要素市场化配置体制机制的意见》，意见中将数据定义为一种新型生产要素，与土地、劳动力、资本、技术要素并列为五大生产要素。数据管理是伴随着信息化到数字化进程发展推进的，在企业未普及计算机时，早期的数据都是使用线下文本记录留存的，数据的查询使用不仅费劲而且容易丢失。当计算机开始商业化生产，从实验室走向社会，由单纯为军事服务逐步转变成为社会公众服务。政企单位的数据逐步由线下记录转为线上存储，当线上数据逐步增加，现代企业管理精细化逐步形成之后，对数据管理提出更高的需求，数据不仅要记录，还要在组织内部共享，数据之间要相互调用，以提升组织内部效率，数据管理的作用越发凸显。（二）数据管理遇到了哪些问题？进入数字化时代后，数据规模指数级增长，数据的价值日益凸显，随着越来越多的企业将数据纳入资产管理范畴，势必需要对数据进行精细化管理。对数据进行精细化管理，首先就是梳理清楚数据与数据之间的交错关系。数据通过生产、转换、流通和加工，又会生成新的数据，这种变化复杂无序。针对这些错综复杂的数据，在管理的过程中经常会遇到以下问题。（1）数据对象间的关系难以展现，比如表中的数据从哪来，到哪去？（2）数据质量问题不可追溯，数据质量问题的排查，需要沿着数据链路逐级排查，如果是多个数据源加工出来的复杂数据，判断数据问题的原因就更加困难。（3）数据影响难以定位，公司有上百个系统，当某个系统的数据发生变化时，很难快速评估出会导致哪些下游系统受到影响以及找出这些数据覆盖的业务场景范围，所以就不能提前做出数据预测并给出解决方案。二、为什么需要掌握数据血缘（一）什么是数据血缘？“血缘”源自人类社会，血缘关系是与生俱来的先天关系，在人类社会的早期就已存在，是最早形成的社会关系之一。而数据血缘是人类血缘的延展，DAMA、DCMM、维基百科、微软公司、IBM、Informatica公司等都对数据血缘有自己的定义。通俗地讲，数据血缘是数据全生命周期过程中的数据关系，包括数据特征的变化，即数据的来龙去脉，主要涉及数据的来源、数据的加工方式、映射关系以及数据的流出和消费。（二）什么是数据血缘图谱？单个表，单个系统的数据血缘关系，无法全面地展示公司数据在不同系统、数据库、应用程序之间的流转。比如我们想可视化展现客户信息从哪个系统哪个字段录入，进行了哪些加工，存到了哪，用到了哪些报表，报给了哪些监管部门，这就是数据血缘图谱。这里面最核心的是各系统数据的血缘（也就是数据的流转关系），然后再根据需要结合数据可视化技术进行展示。而数据血缘关系的获取，则涉及到元数据的采集分析、SQL解析、甚至手工维护等。（三）为什么我们需要掌握数据血缘？我们来看一个例子，你是某大型企业的数据分析负责人，某天早上刚到公司，就收到业务部门领导的消息：我的管理驾驶舱报表数据又不对了，到底哪里的数据发生了变化？你需要给一个答复。你首先查到数据背后关联的指标多达28个，与昨晚ETL更新的数据做对比，发现其中有12个发生了变化，于是你排查了这12个数据，发现分别来自4个数据源，你分别找到这4个数据源的负责人员排查数据为何发生变化，最终找到了数据发生错误的原因，源头A录入了错误数据，导致流入管理驾驶舱的最终数据发生了错误，这时已经是晚上10点。于是你开始思考能否将这些要排查的数据的流向都展示出来，发现异常数据时及时预警并标注。当我们看到某一个数据异常时，就可以通过线上溯源，准确找到和定位具体的数据问题，提高问题解决效率，这样将极大提升终端用户的使用体验。你描述的高效场景是一个美好的世界，这也是数据血缘使用的典型场景之一。三、数据血缘分析及相关工具介绍（一）数据血缘分析我们知道，数据分析是为了提取有用信息和形成结论而对数据加以详细研究和概括总结的过程。而数据血缘分析就是一种找出数据中的血缘关系，用于全面追踪数据处理过程的技术手段。数据血缘分析主要包括3个方面。（1）来源分析：来源分析反映数据的来源与加工过程，主要用于定位数据质量问题。（2）影响分析：影响分析展示以某个数据为起点，该数据带来的影响，反映数据的流向与加工过程，主要用于需求迭代或数据修改的影响评估。（3）全链路分析：全链路分析以某个数据为起点，展示该数据之前的数据来源，以及该数据之后的数据流向的全过程，其实就是把来源分析和影响分析进行结合。（二）国内外数据血缘分析工具（1）Apache Atlas平台（开源工具）Apache Atlas提供元数据管理功能，用于识别、分类和管理数据资源，包括数据资源的标记和分类、数据资源间关系的建立、数据资源血缘关系的维护、数据资源使用规则的定义等。（2）马哈鱼数据血缘平台（商业工具）马哈鱼数据血缘平台是一款用于分析SQL语句，帮助用户在SQL环境中进行机器学习建模和推理，可轻松上手的数据血缘平台。马哈鱼数据血缘平台支持多种机器学习框架，包括TensorFlow、XGBoost、LightGBM等，并提供了可视化的工具来帮助用户分析和理解数据。（3）数语科技SQLink数据链路监测平台（商业工具）Datablau SQLink是数语科技2024年3月发布的独立的SQL血缘解析工具，其依托于Datablau 数据治理产品在大型企业大量复杂SQL的处理积累，拥有较高的SQL解析准确率和覆盖率。四、数据血缘在保险行业的应用探索（一）数据血缘如何助力提升监管数据合规1.隐私保护保险公司处理大量的个人数据（如客户的健康状况、财务状况等敏感信息），这些数据需要符合隐私保护法规。数据血缘能够帮助追踪敏感数据的流动路径，确保只有授权人员可以访问敏感数据，防止数据泄露或滥用。此外，数据血缘还可以帮助在发生数据泄露时快速定位数据泄露的源头。2.数据报送时效在保险行业，经常需要向监管部门报送数据及报表，这些数据通常涉及各业务环节或业务领域，需要进行数据整合，而且时效性要求一般较高。数据血缘有助于简化开发流程，尤其是在需要多种数据集进行整合和开发的场景下。当开发人员能够清晰地看到数据的流动路径和变换逻辑时，就能快速理解如何获取、处理和使用这些数据资源，减少了由于数据理解不清或信息不对称带来的开发延误。数据血缘的可视化和文档化效果能够大大加快数据开发的速度。3.数据报送质量数据质量是监管合规的一个重要方面，数据血缘可以帮助跟踪数据流转中的每个环节，及时识别数据质量问题并加以修正，尤其是在理赔、承保、风险管理等关键领域。（二）数据血缘如何助力数据资源开发利用在数据开发过程中，我们可以通过数据血缘技术提升数据开发效率，具体有以下应用场景。1.提升查询效率通过数据血缘确定表的上下游关系，可以了解表和字段所涵盖的业务范围，方便开发人员在查询业务场景时快速定位到对应的表和字段，从而提升开发查询效率。2.提升调度性能通过收集调度任务的开始和结束时间，可以了解任务ETL链路中的时间瓶颈。通过任务执行情况定位性能瓶颈，并调整任务的基线和资源分配，可以提升整条ETL链路的执行效率。3.数据异常定位在调度中发现数据异常时，可以利用数据血缘关系来跟踪数据的波动情况，快速定位数据异常的原因。4.数据模型优化通过对下游表和字段的使用频次进行统计分析，可以找出被广泛使用的部分，进而分析是否存在重复计算和资源浪费的情况。可以考虑将这部分数据建设成统一使用的事实表或维度表，或者包含计算的通用指标，从而优化数仓模型。5.调度依赖的准确性判断通过对比调度平台的调度关系元数据和收集到的血缘关系，可以及时判断调度任务的依赖是否准确。6.模型变更影响预测系统在上线前，通过数据模型版本升级变更信息，将其应用到全链路血缘，可生成影响报告事前通知相应责任人调整应对。（三）数据血缘如何助力数据安全管理1.防止数据泄露数据血缘通过记录和可视化数据从源头到目标系统的流动路径，帮助跟踪数据的流向，确保每一步的数据访问都可以追溯。这在识别和防止数据泄露、滥用或未经授权的访问方面至关重要。如果某个数据集被异常访问或篡改，数据血缘可以帮助安全团队迅速识别问题的根源。2.细化权限管理数据血缘提供的数据流向和处理链路信息有助于完善权限控制。通过了解数据流转的各个环节，可以设置基于角色的数据访问权限，只允许有权访问特定数据的人查看或修改数据。这种精细化的权限控制能显著提高数据的安全性，减少因权限滥用或管理失误导致的数据泄漏风险。3.漏洞管理与风险评估数据血缘能帮助识别数据处理过程中的潜在风险点。例如，某个数据流可能涉及多个系统和多个用户，数据血缘可以帮助识别哪些环节可能成为攻击目标或数据泄露的薄弱环节。通过了解数据的流转和依赖关系，企业能够提前进行漏洞修复和风险评估。4.数据恢复与灾难恢复在发生数据丢失、系统故障或安全事件时，数据血缘能够帮助追溯数据的恢复路径。了解数据是如何从源头到达当前状态的，有助于制定有效的数据备份和灾难恢复策略，确保在发生问题时能够快速恢复数据并保证其安全性。（四）数据血缘如何与人工智能等新技术结合应用数据血缘与大模型（如大型语言模型、深度学习模型）和其他人工智能（AI）技术的结合，能够极大地提升数据处理、分析、合规、透明度、决策支持等多个领域的效率和效果。大模型在理解和生成自然语言、图像、视频等方面的能力，结合数据血缘的追溯和可视化功能，能够推动更加智能化和自动化的数据管理。特别是在风险预测（如欺诈检测、信用评分等）中，大模型或AI技术具有强大的数据处理和模式识别能力。结合数据血缘，AI可以实时监控数据流动中的异常情况，自动识别潜在的风险点。数据血缘能够帮助AI更精准地识别出数据中不合常规的模式，并作出警报，降低数据风险。
查看详情
数据新时代：如何选择现代数据治理平台(下)
上篇文章我们分享了《数据新时代：如何选择现代数据治理平台(上)》，介绍了一个现代数据治理平台，应该具备的基础软件架构，它保证了应用程序的云化能力、开放性和易用性等核心的架构能力。那么作为数据领域的应用，还需要一些高级的架构特性，来应对大数据量，以及迭代迅速的数据工具生态、成本效益考量等核心问题。所以，我们今天继续分享《数据新时代：如何选择现代数据治理平台(下)》——详细介绍现代数据治理平台的高级架构特征。高级架构特征现代数据治理平台是一个面向数据的企业级的现代应用，其需要特别的架构来适应快速发展的数据行业，适应大型企业的客制化需求，提高应用平台的可维护性。如下特征是我们在Datablau 7.x系统中重点打造的能力。1.数据库插件化近年来，国产化的数据库获得了蓬勃发展，在企业应用中也是百花齐放，接到了一个前所未有的数据库支持请求，这种情况在数据管理领域其实并不罕见。同时国产数据库还在快速发展中，版本迭代的连续性和兼容性问题都很大，意味着不同版本和方言的支持也是很重要的。数据库插件通常包含原生数据库驱动和采集插件两个部分，它们是可以热插拔的，也就是可以不停掉程序，进行更新支持。插件需要支持版本的隔离和类空间隔离，保证同类不同版本数据库可以在平台同时采集。图3《Datablau平台数据库驱动和插件管理》2.元模型驱动元模型（Metamodel）是描述模型的模型，是元数据的元数据，它提供了一个抽象框架，用于定义、描述和约束其他模型的结构和行为。换句话说，元模型本身是对特定领域或系统中各种模型的结构、关系、元素等规范化的描述。它不仅定义了模型的组成部分（如对象、属性、关系等），还规定了这些组成部分如何组合和交互。元模型的定义要素：1)对象：元模型描述的基本构建块，通常是“类”或“实体”，它们在具体模型中可能对应数据对象或业务对象。例如，在数据管理领域，元模型中的元素可以是“数据表”、“字段”、“数据类型”等。2)属性：这些是元素的特征或属性。在元模型中，元素可以具有不同的属性，比如数据类型、约束条件、默认值等。3)关系：元模型定义了元素之间的关系，这些关系可能是层次结构（如继承）、关联、依赖等。在数据管理中，这些关系可能是表与表之间的外键关系，或数据对象之间的依赖关系。4)约束：元模型还会规定哪些规则和约束是必须遵守的，比如数据格式要求、参照完整性、唯一性约束等。这些约束确保了模型及其实例的一致性和有效性。元模型驱动（Metamodel Driven）是现代数据治理平台的重要能力，通过定义所管理的数据对象的构成和规则，使得复杂的数据对象可以得到抽象化表示，使得这些对象可以共享相同的结构或规则，减少冗余和重用能力。其最重要的价值是快速应对业务需求或系统变化，支持定制和扩展。Datablau数据治理平台广泛具有元模型驱动的能力，根据数十年模型领域的积累，将元模型分为三层架构。图4《Datablau元模型架构》特别需要注意的是，元模型带来高扩展性好处的同时，也带来了一些副作用：· 过于专业，对于终端用户定义元模型要求很高。Datablau产品中特别有UDP（user defined property）这种动态的元模型，给到用户快速定义扩展的属性，简单易用。· 元模型高度抽象，底层数据存储非常集中，导致数据访问的性能降低。Datablau产品中主要通过缓冲层进行提速，大量使用了ES，Reddis和图数据库进行提速。· 过于通用的界面，导致用户难以使用。Datablau产品中主要通过开发个性化UI，从用户视角进行UE设计，将高难专业的内容进行包装，对于用户使用产品非常容易。3.二次开发解耦二次开发通常是指在已有的商业软件、开源软件或者平台上进行二次开发，以满足特定的业务需求、实现个性化功能或集成其他系统。在二次开发的过程中，架构设计尤为重要，它决定了系统的可扩展性、可维护性、灵活性和稳定性。数据治理系统是一类特殊的管理系统，在国情下存在各行各业的管理流程不一致的情况，造成比较频繁的定制开发需求。目前国内大部分厂商的产品大多是基于产品源码进行开发，这种开发应该称之为一次开发，即产品定制开发。产品定制开发造成的问题是比较多的，尤其是产品架构二次开发架构不好的时候，会造成系统的大规模质量衰退，同时，定制的系统长期维护成本是非常高的，以至于系统处于无法更新升级，处于安全的风险之中。Datablau 7x系列产品采用全面的二次开发架构，支持高扩展，低成本，长期可维护的二次开发能力，支持三种模式，可混用搭配：· API集成开发：通过Restful API进行二次开发是成本最低，质量最可靠的开发方式，大量的系统集成，功能自动化等使用此方式。这种开发方式的局限是无法浸入式功能和UI扩展。· SDK二次开发：通过SDK二次开发是开发能力更强的一种方式，它可以调整UI，扩充系统能力。这种开发方式的局限是开发曲线较长。· 插件式二次开发：通过Plugin的扩充可以对系统的特定部分进行能力扩展，比如集成和数据库插件等。这种开发方式的局限是只能在特定支持的部分扩展。图5《Datablau二次开发架构》4.信创支持未来几年内，数据治理平台对于国产信创系统的支持，已经成为一个刚需和必选的能力项。Datablau 7x系列产品全面支持新的信创系统架构，完成了与主流厂家的认证，同时具备快速支持能力。参考清单如下（不是最新）：图6《Datablau信创支持证书清单》5.自动化与智能化数据正在呈爆炸式增长：每天估计会产生2千万亿字节的数据。鉴于数据的规模和速度，自动化和智能化的数据治理越来越有必要，以确保用户能够找到并使用相关的数据。目前AI与数据分为两个方向，即AI4Data 和 Data4AI。大模型提供商和训练者更关注Data4AI，旨在为AI训练提供更高质量更合规的数据集。在本文中更关注的是AI4Data，就是如何利用大模型和AIGC技术，赋能数据治理活动，减少付出的人力成本。在可见的未来，智能驱动（AI-Powered）的数据治理平台将成为标准化的能力。Datablau 7x系列产品已经引入了全新的AI Center模块，作为自动化与智能化的数据智能中心，与数据治理平台进行生态集成。参考架构如下：图7《Datablau AIC智能治理》AIGC作为一个新兴的技术，让我们对其带来的解决问题的能力给与了较高的期望。我们已经在如下方面取得不错的效果：· 数据语义的生成：对于数据中的元数据语义，通过AIGC进行自动补全。· 智能数据分类：AIC可以根据数据的内容或特征，自动进行分类和分组。自动识别其主题、类别或类型，并进行标注。· 数据标准的生成：AIC可以根据数据的内容或特征，建立适合行业的数据标准，并对数据标准的分布进行智能推荐。· 质量自动评估：AIC可以分析数据集的完整性、准确性、一致性、及时性等维度，自动评估数据质量，并提出优化建议。我们已经取得不错的进展，伴随AI增强的数据管理能力还在不断的探索和成熟中，我们未来会进一步更新我们的进展。总结从2014年以来，数据治理平台已经演化为一系列生态服务集成的大型应用程序集合，这和十年前的平台完全不是一个量级的产品。试图自研该系统的企业越来越少，一方面是成本效益的考量，另一方面市场的产品成熟度已经到达一定程度。作为数据治理产品的专业提供商，我们具有二十几年的产品设计开发经验和数据治理的Knowhow能力，立志为企业提供专业的、架构优良的、技术先进的、易用好用的数据治理平台，并与客户一同成长，保持平台的升级与演进，让用我们平台的企业永远走在数据治理的前沿!
查看详情
数据新时代：如何选择现代数据治理平台(上)
谈现代数据治理系统的十大架构特征最近一位老友找到我，咨询他的数据治理平台到底该不该换，背景是这样的：若干年前采购了一个市场主流的数据治理平台，功能大概就是数据治理三件套——标准、元数据和质量等经典数据治理的功能。现在企业要信创，该平台无法支持上云、新数据库等诉求，原厂也不再提供升级支持。这位朋友考虑到动迁成本以及多年累积的付出，犹豫是否再缝缝补补凑合一阵子。这种情况在市面上还是比较普遍的，经常有某客户抛弃老平台，重新采购新系统的案例。（这点不得不说，相比于西方企业市场，我国企业的外购系统的生命周期明显偏短的，具体个中原因暂且不表）。如果您也是正在做类似平台的选型，除了关注功能，更要关注到基础架构层面，那才是工具长期可持续的保证。作为一家专业的数据治理产品提供商，在最近发布的Datablau产品7x版本的研发中，我们也一直在探索，如何让产品在企业运营中可持续发展，如何保护客户的投资，如何让产品在客制化和标准化之间平衡，并保持持续的升级能力。这里结合我们的实践，谈一谈现代数据治理平台，具备的十大架构特性，供您参考。基础架构特征（上）现代应用程序架构的特征反映了当前技术的发展趋势和业务需求的变化。随着云计算、容器化、微服务、人工智能等技术的普及，应用程序的架构也变得更加复杂、灵活、可扩展和高效。以下是现代数据治理平台架构的一些主要特征：1.微服务架构微服务架构（Microservices Architecture）是一种将应用程序分解为一组小的、独立的服务架构模式。每个服务都围绕一个特定的业务功能构建，能够独立部署、扩展、开发和维护。特征：· 高度的模块化，每个服务独立运行，且可以使用不同的技术栈。· 独立部署、扩展和更新。· 服务之间通过API通信。微服务是云化时代软件架构的基本特征，数据治理平台的早期版本功能是单一的，大多是个前后端一体的单体应用程序。随着企业数据量增加和数据管理活动的细化，已经演化为一个复杂的应用程序，它包含了多个数据治理功能域，如标准、元数据、质量、安全、资产等，与数据领域的生态系统，如数据开发、服务、BI、分析等都有了集成应用。所以现代数据治理系统已经是一个贯穿开发，投产，生产三个环节的，一个企业级的综合数据治理平台。微服务架构让这个平台更容易云化，实现高可用，生态集成，在大数据量下提高负载能力和稳定性。当然微服务的粒度是个架构哲学问题，把握应用与分工的平衡性非常重要。在Datablau平台中共有20个左右的微服务，涵盖了原子的业务模块和公共的服务模块和基础设施模块等。图1《Datablau平台微服务架构》2.API驱动架构开放API成为现代应用程序架构的核心。应用程序通过RESTful API、GraphQL或gRPC等接口进行服务交互和数据交换。这种架构使得系统能够与外部系统进行集成，并且提供灵活的通信方式。特征：· 标准化的接口，简化服务间的通信。· 支持跨平台访问和异构系统的集成。· API文档（如OpenAPI）成为接口规范的重要部分。正如在《Datablau平台微服务架构》所述，早期的应用系统用JSP这种前后一体程序构建，虽然开发调试成本低，但是带来了耦合性和封闭性的弊端，所以现代软件平台必须是API驱动的前后分离的。3.事件驱动架构（EDA）事件驱动架构基于事件的触发和响应进行工作。应用程序中的事件（如用户行为、系统变化等）会引发一系列的操作和流程。这种架构适用于高并发、异步处理和实时响应的场景。特征：· 异步处理和消息队列（如Kafka、RabbitMQ）用于事件的传播和处理。· 支持实时数据处理和流处理。· 提高系统的解耦性和可伸缩性。Datablau产品中主要通过Kafka建立多服务的信息同步通道，记录跨服务的日志和对象状态同步，保证多服务间的事务最终一致性。参考上图《Datablau平台微服务架构》。4.API网关和服务中心API网关：用于处理和管理客户端请求，负责路由、负载均衡、认证、日志等功能。API网关通常作为所有微服务的入口点。服务中心：服务中心是一个基础设施层，提供微服务之间的通信、监控、安全和管理功能，通常与容器化和Kubernetes集成。特征：· 简化客户端与后端微服务的通信。· 提供流量控制、负载均衡、故障恢复、认证授权等功能。· 支持微服务之间的可靠通信和可观测性。Datablau产品中主要通过Gateway建立API路由通道，管理微服务的入口点，进行多服务的系统集成和参数配置。参考上图《Datablau平台微服务架构》。5.用户体验（UE）现代应用程序对用户体验（UE，User Experience）的要求比以往任何时候都更为严格和复杂。随着互联网和移动应用的普及，过去工业化风格的UI已经无法被习惯好的UE体验的用户所容忍。作为一个数据管理应用，其用户也跨出了数据管理人员的范围，更多角色包括业务侧人员的加入，让好的UIUE已经成为衡量数据治理平台是否更容易推广的重要指标之一。专业的UIUE是一个专业的领域，主要的内容包括简单直观的界面，减少学习成本、功能流畅等，现代的数据治理平台在此基础上更加强调：智能化体验：随着人工智能和机器学习的普及，现代数据治理平台不仅仅是工具，还需要通过智能化功能提升用户体验和工作效率。例如：智能推荐、自动化建模等智能功能，可以大大提升用户的交互体验。互动性体验：主动元数据治理（Active Metadata Management）是近年来流行的数据治理方法，数据治理平台需要有主动驱动的功能支持，在数据设计与加工过程中，通过通知、互动、联动等智能化方式，达到第一时间进行数据治理的目的，事半功倍。图2《Datablau元数据平台界面》小结以上介绍了一个现代数据治理平台，应该具备的基础软件架构，它保证了应用程序的云化能力、开放性和易用性等核心的架构能力。那么作为数据领域的应用，还需要一些高级的架构特性，来应对大数据量，迭代迅速的数据工具生态、成本效益考量等核心问题。下篇文章继续分享《数据新时代：如何选择现代数据治理平台(下)》，详细介绍现代数据治理平台的高级架构特征。
查看详情
从“数据民工”到“数据销售”：数据治理如何赢得业务心（二）
那么，数据人有了业务视角，是不是就意味着业务会一起参与数据治理工作？答案当然是否。数据人除了具备业务视角这个前提条件外，至少还要解决两个关键问题，才能真正让业务人员参与到数据治理活动中来：1、如何证明这套东西是能落地、可执行的？2、如何证明最终完成的成果对预期的业务目标有直接的正向影响？下面我们来重点分析上篇文章《从“数据民工”到“数据销售”：数据治理如何赢得业务心（一）》中留下的这两个问题。首先，如何保证数据治理能够落地？除了常规的管理体系落地所需要确认的四个维度（明确的管理目标和管理主客体、明确的数据管理范畴、完整的管理规范、流程及配套的技术平台和设计方法论、明确的绩效评估指标和指标优化路径指导），我这里额外补充了三个层面的内容：首先是认知层面，为了让业务部门认可数据团队，数据部门需要了解公司的主营业务模式、核心业务流程及业务痛点问题，尤其是需要理解特定的业务话术，让业务部门认可数据团队是“自己人”而非纯IT技术团队；同时，数据团队也要充分理解公司管理团队、业务团队、IT团队的诉求和能力现状，并能够结合行业案例和具体的实践过程对内分享，让公司上上下下明确数据治理具体的工作内容和实施路径，这就要求数据团队不仅要知道同行案例具体做了什么，更要知道为什么这么做及实施过程中的踩坑心得。其次是规划层面，数据团队需要在充分了解公司业务模式、业务问题现状的基础上，充分展示其结构化业务设计能力，例如业务能力、版图设计能力、业务流程设计和优化能力，重点是通过业务能力的优化设计提炼出共性的数据能力，使之不仅能服务于当下，更能成为企业的公共基础能力服务于后续更多的业务领域。这里尤其需要提醒的是，规划层面不仅要注重设计能力，也要注重分享宣贯能力，要让业务部门相信整个规划的合理性，就需要数据团队在深度调研一线业务团队、IT团队或管理层的基础上，展示整体规划的目标设计和路径设计是完全站在企业实际情况的基础之上，过程中可以针对性的引入行业最佳实践经验，通过阐述行业其他成功案例在实施目标、组织现状、管理思路等多方面的共性需求，引入行业案例中被实践证明过的、不同组织岗位在不同阶段需要完成的工作内容、输出的成果和准入准出标准，加速整个规划方案的细化过程。最后是执行层面，业务视角有一个很重要的点，就是希望任何结果都能够“看得见、摸得着”，因此，良好的样例设计，通常会成为影响治理实施成败的关键因素。结合我本人过往成功交付和参与的治理案例，一个好的样例设计通常具备这么几个特点：1、业务形态对数字依赖性越强越好，业务流程相对标准，规则简单，最终业务活动结果对数据依赖性高，这样方便在数据治理实施过程中尽可能减小业务知识的学习成本。2、样例实施尽量在一个组织部门内，跨部门协同不利于减少实施过程中的沟通成本，加速里程碑目标的达成并推动后续的持续优化，这也是为什么很多数据治理都先从数字化中心开始，其实就是方便资源协调，尤其是技术资源的协调，很多时候能否推动IT部门处理核心数据问题会是影响试点成败的关键因素之一。3、不建议数据治理工作一开始就参与过于复杂、并且需要快速上线交付业务使用的大型项目，避免数据治理成为进度延后的一个潜在因素，业务形态稳定，发版周期/质量水平相对成熟的项目更适合优先推行数据治理体系；推行时首先保证事前-事后治理流程的闭环（如标准贯标-质量监管建立），后续再讲优化。有了好的样例试点，就需要配套建设持续性的运维服务保障能力。实践中，服务运维能力建设可从以下几个方面开展：1、管理流程和技术平台持续优化，可以参考业务流程常见的优化方法，不断优化过程中那些学习成本高、超出实际业务目标的严格管理环节，实现管理规范性与实施难度之间的平衡；2、绩效指标和看板的设计优化，配合实现数据治理流程的优化设计，以及越来越多人对于数据治理工作和成果物不同的分析诉求；3、管理规范和管理流程的可配置化，以实际不同场景下数据治理流程和方法论的裁剪；4、建立良好的运营服务，尤其是数据团队对于业务反馈的，落地过程中的瓶颈性问题，需要第一时间提供具体的措施帮助业务人员解决问题，并不断提炼共性的问题，完善实施方法论和培训教程，通过结合具体问题和场景的持续培训赋能，提升整个业务团队的数据管理能力。下图系统地说明了，为了绕过业务认可数据治理工作，数据团队所需要具备的能力和待完成的关键工作内容：
查看详情
