数据新时代：如何选择现代数据治理平台
谈现代数据治理系统的十大架构特征
最近一位老友找到我，咨询他的数据治理平台到底该不该换，背景是这样的：若干年前采购了一个市场主流的数据治理平台，功能大概就是数据治理三件套——标准、元数据和质量等经典数据治理的功能。现在企业要信创，该平台无法支持上云、新数据库等诉求，原厂也不再提供升级支持。这位朋友考虑到动迁成本以及多年累积的付出，犹豫是否再缝缝补补凑合一阵子。
这种情况在市面上还是比较普遍的，经常有某客户抛弃老平台，重新采购新系统的案例。（这点不得不说，相比于西方企业市场，我国企业的外购系统的生命周期明显偏短的，具体个中原因暂且不表）。如果您也是正在做类似平台的选型，除了关注功能，更要关注到基础架构层面，那才是工具长期可持续的保证。
作为一家专业的数据治理产品提供商，在最近发布的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能力，立志为企业提供专业的、架构优良的、技术先进的、易用好用的数据治理平台，并与客户一同成长，保持平台的升级与演进，让用我们平台的企业永远走在数据治理的前沿!
