数据资产管理平台竞品分析报告

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

编辑导读:数据资产管理平台是用于管理公司数据资产的,是常用的产品之一。要想找到找到适合的产品,首先需要了解公司自身的痛点,再根据痛点在考察各竞品的功能。本文作者例举了几个数据资产管理平台,并对其进行分析,希望对你有帮助。

数据资产管理平台竞品分析报告

目前,公司正在进行数据治理,准备外购一款数据资产管理平台,用于承接公司的数据资产。 为了找到适合的产品,首先需要了解公司自身的痛点,再根据痛点在考察各竞品的功能,本文正是基于这样的思路进行分析。

一、痛点及需求

在实际数据管理时,常遇到这样的问题:

  • 数据语言不统一:不同业务系统同样指标或字段定义不一致,缺少统一的数据命名规范和标准
  • 数据找不到、读不懂:数据多源头,分析师和技术不知道想要的数据在哪、数据加工逻辑等,无法厘清信息资产
  • 数据不可信:缺乏数据的质量管控和评估手段,无法保障数据准确性、一致性、有效性等
  • 数据不可联:“烟囱式”开发,数据不共享、不流通,无法实现跨领域的数据分析和数据创新

对于上述问题,提炼出以下需求点:

  • 数据标准:建立统一的数据规范命名体系,保障数据口径一致
  • 元数据:建立数据资产地图,包括元数据管理、血缘及影响分析、资产目录等
  • 数据质量:建立数据质量规则和质量监控机制,帮助用户及时发现数据质量问题
  • 数据安全:建立包括访问控制、脱敏加密等在内的数据安全体系
  • 主数据管理:建立主数据模型、主数据管理流程,实现跨部门、跨系统数据融合应用

二、竞品分析

对A、B、C、D四家数据资产供应商进行分析,首先从数据治理体系上对各家产品进行概览性描述,然后在分析和对比核心功能模块,最后得出结论。

2.1 A

2.1.1 数据资产管理平台产品信息架构

数据资产管理平台竞品分析报告

接下来分模块对产品功能简要介绍
2.1.1.1  数据接入

支持Oracle、Mysql、SqlServer等关系型数据库、mongodb数据库及大数据环境下的Hive、HBase、HDFS分布式数据库的接入与管理,支持Excel补录数据,实现结构化数据、非结构化数据的统一归集。

2.1.1.2 元数据

可自定义元数据,系统自动采集元数据(增量更新),可对元数据进行检索和维护(字段级别),当数据模型发生变化时,元数据可动态感知,并生成感知日志

血缘分析:支持自动解析和手工维护析血缘关系;血缘分析方式:影响分析、血缘分析和全链分析;分析内容:库表字段间的血缘关系,不支持加工逻辑的解析

数据资产管理平台竞品分析报告

2.1.2 数据标准

A在建设数据标准时,将数据标准分为两部分:数据标准制定+标准执行评估。

其中标准制定分为枚举项标准和数据元标准,两者都是公共的业务术语,具体如下:

  • 枚举项标准是指可枚举的最小数据单元,如男女、省市县。枚举项标准可关联到数据词典;
  • 数据元标准则是非枚举型的最小数据单元,如电话号码,从业务和技术两个维度对字段进行描述,发布后方能生效;

数据词典是确定的、标准的静态数据分类,供元数据和模型配置中引用。可根据需求自定义字典中包含的字段,灵活性较高

数据标准执行评估,评估方式为 事后评估 :数据标准直接下发到数据模型,采用手动/定时任务方式评估模型是否符合标准,以及标准执行的具体情况

2.1.2.1 数据建模与同步加工

首先新建数据分类,主要是从非业务角度对数据资源进行分类管理

支持新建、抽取、映射、导入、融合五种数据建模方式,支持主子表复合模型建模。支持对模型打标签,对模型字段属性编辑、查看库表结构。可启用模型审核流程,审核后模型才能生效。模型每次生效都会产生新版本,支持不同版本之间的对比。在建模初始化中,对模型的修改则不会产生版本记录,减少脏数据产生。

支持对数据模型配置管理,包括模型属性配置和页面展示配置。其中,

  • 属性配置 是对模型字段进行配置管理,包括是否匹配字段(数据维护、调用接口、数据清洗时根据匹配字段进行匹配导入)、是否为字段设置默认值(常量、系统变量)、设置关联对象类型(关联模型、关联数据词典。关联后,可配置引用/显示字段、为字段赋值、配置过滤规则)、配置运算公式(字符型/数值型/日期型/常量属性支持“拼接”运算,数值型属性支持“四则运算”)
  • 页面展示配置 包括展现方式(列表/树列表)、排序字段配置、属性分组设置、文本域设置等
  • 属性配置和展示配置中配置的内容将在数据管理模块中查看

在数据管理模块中,可对 数据模型的具体属性值 进行维护和查看,其中,

  • 数据查看:查看已生效的模型和模型数据情况
  • 数据维护/初始化维护:该功能仅适用创建方式的数据模型。可以对模型字段值进行编辑、导入/导出、审核,管理版本等
  • 任务管理:查看导入、导出任务执行记录、执行状态、进度、失败原因

在数据融合模块,支持对数据模型进行同步和加工,其中,

  • 模型同步:同步数据源之间的表/视图同步,支持配置过滤规则(行过滤、列过滤)、更新策略(全删全增、追加、更新、增量追加、增量更新)、配置调度任务和权限
  • 模型加工 :对数据进行加工处理,有两种加工方式:可视化拖拽方式和写SQL方式
  • 可视化拖拽方式 :通过拖拽进行数据源连接并基于连接结果做数据过滤等加工操作,然后发布为模型/视图。支持的加工操作包括:横/纵向连接、过滤、去重、排序、映射、字段合并、拆分、分组聚合、赋值、类型及大小写转化等,支持预览
  • 写SQL方式 :通过写SQL完成数据连接、数据过滤、数据汇总等一系列加工处理,可直接发布为模型/视图,支持预览
  • 任务调度:查看/执行模型同步和加工配置的定时任务,查看任务日志和模型更新结果

对于非结构化数据,在文件管理模块中进行查看和维护;支持对文件元数据定义,支持office系列、txt、图片、pdf类型、音视频的文件上传、预览、下载和删除;支持服务器磁盘、HDFS、HBASE等多种文件存储方式

2.1.2.2 数据质量

A的数据质量包括质量规则管理、质量落地评估、质量预警三类功能。其中,

  • 质量规则管理:质量规则管理包括质量规则制定+权重设置。质量规则包括非空规则、唯一规则、组合唯一、一致规则、核准规则、规范规则、阈值规则、正则规则、条件规则、组合规则、多字段约束规则。同时,支持内置规则模板,实际制定规则时,可直接引用
  • 任务评估:支持配置定时任务,对任务执行情况进行监控,查看评估结果和评估日志。在查看评估结果时,可查看可视化评估报告、脏数据表、以及历史评估结果
  • 质量预警:包括异常预警和低分预警(任务评估时会给出具体的质量评分),预警通过短信/邮件方式通知接收人

制定质量规则的对象是单个字段或单个模型,不支持批量操作

2.1.2.3 数据资产地图

数据资产地图包括两部分:资产地图和资产盘点

  • 资产地图:支持从业务角度定义主题,基于主题对数据资产进行归类、展示;资产目录则是从数据资源存储角度对数据资产进行归类、展示
  • 资产盘点:基于数据现状对数据进行盘点,包括资产大盘(数据量、资源访问情况、数据质量评估情况、数据交换情况)、元数据盘点(模型个数、模型按库/主题/分类/创建方式分布情况等)、数据盘点(结构化/非结构化数据量、访问次数、存储空间等)、数据质量盘点、数据交换盘点

2.1.2.4 数据服务

数据服务是用来做平台和第三方之间进行数据交换的:当第三方查询/更新平台数据时,提供接口服务。

支持对服务调用方管理、加密传输,支持对交互的数据进行字段和值映射,支持查看交换日志

2.1.2.5 数据安全

数据安全方面主要是权限控制,另外包括密级管控、脱敏加密。权限控制中,支持对数据库权限、数据分类权限、字段权限、行权限、按钮权限管控,具体的数据权限和用户权限查询可在权限查看中进行检索查看。

2.2 B

2.2.1 数据治理体系–多平台

接下来分模块对产品功能简要介绍

2.2.1.1 数据接入

支持关系型数据库类型: MariaDB、DB2、Gauss DB、GBase、SAP HANA、MaxCompute、MySQL、Oracle、Postgre SQL、HAWQ、SQLServer 和 Teradata 等

支持的非关系型数据库: Cassandra、HIVE 和 Mongo DB 等
2.2.1.2 元数据

元数据自动采集,无需配置采集任务

支持自定义元数据属性;支持元数据引用数据标准;支持手工维护血缘关系

提供智能标签服务体系,通过定义打标签的规则自动为数据打标签,标签可作为检索条件对元数据和数据资产进行检索

对元数据分类维度包括业务部门、IT部门和业务域三个方面,元数据检索/查看粒度包括系统、库、schema、表/视图、字段、存储过程、函数。视图可以查看到对应的SQL语句、解析出的表和视图

支持定义业务实体和业务流程,从实际业务场景角度对元数据进行盘点,在数据建模平台引用

对于用户在数据资产管理平台上提交的数据需求,在元数据模块中进行收录、分析和管理

支持血缘分析和影响分析,元数据血缘分析可解析出加工过程

2.2.2 数据标准

B的数据标准体系分为基础标准和指标体系,其中,

  • 基础标准是字段级数据标准,包含命名词典(是公共的、最小粒度的词根,通过词根可进行字段中文名称拼接)、标准代码(是枚举项,作维度值使用,通过枚举项代码直接引用)、数据标准(通用的业务术语)
  • 指标体系是指标级别数据标准,包含指标体系和维度体系(定义了通用的指标和维度)

支持从业务属性、技术属性和管理属性三个方面对每个数据标准进行维护

支持查看每个数据标准被引用的情况、版本历史、开发审核状态

数据标准落地支持事前控制和事后评估,其中,

  • 事前控制 :整个数据标准体系可在数据建模平台直接引用,数据资产管理平台和数据建模平台打通,两个平台关于数据标准的操作(如编辑、更新)可实现同步
  • 事后评估 :支持元数据引用数据标准,在数据资产模块和数据建模模块可查看数标落地情况

2.2.2.1 数据建模

数据建模平台通过可视化画ER图的方式,实现从应用数据标准到数据库设计。支持多人协作的数据建模跨部门共享数据模型。

  • 可视化拖拉方式建模、直接引用数据标准,或引用智能推荐的数据标准数据字段
  • 多人协作,同时编辑和修改模型
  • 自动生成SQL建库脚本,数据字典管理
  • 对象级增量版本管理,详细列出模型版本之间差异,并根据差异进行表和字段级别的合并,模型变更全历史记录
  • 支持对象命名自动按规范翻译,实现数据模型的命名规范
  • 自动进行模型合规检查,记录模型库对标准的引用情况,生成标准落标报告

2.2.2.2 数据质量

B数据质量规则包括完整性、准确性、一致性、可用性、合规性等规则,支持对规则自定义

基于需求选择对应的质量规则后,生成检查任务和修复任务

驾驶舱展示整个资产的质量问题等情况

2.2.2.3 数据资产

该数据资产地图面向的人员为内部技术人员,其中

  • 资产概要展示了数据资产的整体情况,如业务系统个数、各系统标准覆盖率、核标率等
  • 系统数据地图和业务数据地图以可视化动态地图方式展示各系统/数据库分布情况
  • 业务数据地图中支持筛选重要性为高的业务数据进行展示
  • 系统数据地图中支持检索功能,支持查看每个系统的基本情况:接口、模型、所属业务域,系统间的关联关系、表级血缘关系等

2.2.2.4 数据服务

数据资产目录平台主要面向业务人员使用,基于统一数据授权,统一提供数据资产访问平台。

  • 资产检索:基于数据业务目录检索目标数据,包括报表、表/视图、指标、数据标准、文件类资产、数据库
  • 数据探查:除展示目标数据的基本情况,还包括血缘关系、字段的值域分布、API调用情况等,支持添加评论备注、在线编辑、接入BI产品
  • 当未检索到目标数据时,可创建数据需求,该需求在元数据模型汇总,基于需求BI进行开发
  • 智能数据标签:自动发现敏感数据和个人隐私数据,并进行标注,提示风险
  • 数据安全:控制API,JDBC和BI工具的访问,统一用户密码体系,提供数据访问时间控制,字段项脱敏控制

2.3 C

2.3.1 数据治理平台产品信息架构

接下来分模块对产品功能简要介绍

2.3.1.1 数据接入/集成

支持数据库、报表工具、ETL工具等数据采集适配器,主流关系型/非关系型数据库,关系型包括MySQL、Oracle、MaxCompute等,非关系型包括MongoDB、Hive、HBase、HDFS等 EXCEL导入、支持采集文件

2.3.1.2 元数据

支持元模型设计,包括基本信息、属性、父类、子类、组合、被组合、依赖、被依赖等

基于设计好的元模型,配置元数据采集任务:①首先配置采集源,②设置采集任务,③入库审核,④查看采集日志。当系统第一次被采集时,可经过入库审核操作,支持采集部分表,勾选部分字段入平台库中

在元数据管理中,支持对采集到的的元数据进行编辑和新增,同时支持对元数据检核,包括一致性检核(检查最新元数据与数据源里的数据是否一致)、组合关系缺失检核(跟元模型对比)、属性填充率检核、元数据标准覆盖率检核、检核例外管理、配置检核任务。血缘分析支持手工维护;支持查看元数据版本变更记录;支持为元数据添加数据标准映射(手动和智能推荐映射两种方式)

元数据应用中,血缘分析包括影响分析、血缘分析、全链分析、关联度分析、属性值差异分析、元数据对比分析、重复元数据分析;支持解析出加工过程;支持对元数据进行检索,检索粒度包括系统、库、域、表、字段、索引等

2.3.1.3 数据标准

数据标准体系包括两部分:基础数据标准和常用数据标准。其中,

  • 基础数据标准包括了词根管理、参考数据管理和编码规则管理
  • 词根管理中维护了公用的、最小粒度的词根;支持导入导出
  • 编码规则管理则维护了字段命名规则,比如规定日期类型字段标准为YYMMDD
  • 参考数据维护了公用的维度值,如产品类型,支持新建维表,维表类型包括维表、数据期维表、螺旋维表;支持导入导出
  • 常用数据标准维护了字段级的常用业务术语,如开户日期,支持分类和自定义;支持映射到元数据

对数据标准进行增删改查时,从业务属性、技术属性和管理属性三个方面进行操作

数据标准经过审核后发布为定版数据标准,才可进行使用;支持查看历史版本

数据标准执行情况仅支持事后评估

2.3.1.4 数据质量

数据质量规则支持有效性、准确性、完整性、一致性、及时性、偏差性稽核规则

规则配置支持条件过滤,权重配置

配置好任务调度方案后,执行结果在数据质量监控模块查看;支持制定预警机制,通过邮件/短信通知接受人

2.3.1.5 数据资产

从业务角度对数据资产进行盘点展示,支持定义数据资产编目;支持查看数据表的库表结构和字段值,记录数据表被查看和被交换的次数

数据资产生命周期可用于对数据进行归档,一般按时间维度来维护归档机制

2.3.1.6 数据服务

通过接口实现数据的交换,通过访问控制授权访问

数据安全包括权限、脱敏加密

三、核心功能对比

通过对各家产品的纵向分析,可知道各产品的功能基本情况,接下来进行横向分析,对比各家产品在元数据、数据标准、数据质量、数据建模、数据资产、数据服务6个功能模块上的表现情况,对比结果见下表。

3.1 元数据

总结:

在元数据管理中,最基本的需求是描述数据的基本信息(业务/技术/管理元数据)和解析数据的来龙去脉(血缘分析),衍生需求是元数据的父/子类标准、变更记录、审核、补录维护、下载等。

从元数据采集到应用整个流程上看,四家基本功能大致相同。

  • 在元模型设计上,C和D的元模型设计自由度最高,可配置信息丰富;A和B只支持业务/技术/管理元数据属性定义
  • 在元数据采集上,A、B和D元数据采集方式一致,C元数据采集时需配置数据采集任务,配置不同的入库策略
  • 在元数据管理上,B、C和D有元数据质量检查这一功能,B的是平台自主检测,C的则是用户自主执行检查(关于这一功能的使用C的顾客表示不好用);A无元数据质量检查功能
  • 在元数据应用上,A的血缘解析和元数据应用相对较弱,且整体元数据的组织比较混乱,无归类层级关系;B有独特的数据/报表收集流转功能、智能标签

3.2 数据标准

总结:

对于数据标准的需求,可以分为两个部分:数据标准制定和数据标准执行。在数据标准制定中,可以将数据标准分为基础数据标准(行业/业务词汇库、参考数据、与主数据相关的标准业务术语)、应用数据标准(指标体系)、命名规则(表/字段命名规则)。在数据标准执行中,分为事前控制和事后评估。

  • 在基础数据标准中,四家产品功能大致相同。A仍然在产品信息整合上较混乱,B在标准版本管理上优于其他三家,C提供的参考数据管理能力比较丰富,除了满足基本维度管理外,还支持特殊需求,如螺旋维表等;D的优势项在于数据标准间的关系图谱,支持分析数标上游参考、下游引用等全链路关系分析
  • 在应用数据标准中,B和D支持指标体系管理和命名规范,能进一步统一数标建设规范
  • 在数标执行中,对于事前落标上,只有B和D支持事前落标,支持从源头上建设数据标准;对于事后落标上,A和C通过配置任务方式在评估贯标情况、B和D则采用自动化/半自动化方式评估贯标情况,四者贯标结果颗粒度大致相同

3.3 数据质量

总结:

数据质量建设包括质量规则制定和质量规则落地评估两个方面。

  • 在规则制定与管理中,A、B、D三家的数据质量规则基本一致,满足需求,C的规则制定与管理功能比较丰富,如数据质量规则与数据标准直接打通、规则支持Python脚本、问题评级等
  • 其他功能,四家产品大致相同

3.4 数据建模

总结:

数据建模包括模型设计和模型管理两个方面。

  • C无建模工具、D与B是合作关系,其建模工具就是B的建模工具
  • B和A有建模工具,就功能能力来说,A建模工具比较简陋,基本满足不了建模需求。而B建模功能能力丰富,采用可视化ER图的方式,支持从应用数据标准到数据库设计模型全生命周期管控。此外实现数标事前落地的需求,支持拖拉的方式直接引用数据标准或智能推荐标准、模型对象自动规范化命名等

3.5 数据资产

在数据资产上,B和C的数据资产地图内容比较丰富,A一般

  • A数据资产提供对各类资产的盘点和数据资产地图,按业务和系统角度对数据进行归类,支持查看数据和查看元数据
  • B的数据资产地图,按系统角度对数据归类层面,在满足基本需求的前提下,采用可视化动态报表样式进行展现,体验较好,按业务角度对数据归类层面,有较好的搜索功能,支持查看数据和库表结构、API、血缘关系、添加评论等。当未检索到目标数据时,可通过创建需求方式向数仓开发描述、提交数据需求,减少沟通成本
  • C的数据资产地图仅支持一种方式对数据进行归类,支持查看数据、库表结构、元数据、交换和下载等
  • D的数据资产地图可自定数据地图的内容,通过数据血缘汇总数据地图的链路关系

3.6 数据安全与服务

在数据安全与服务模块,四家产品功能基本相同,都提供权限方案、安全等级、脱敏加密等功能

四、总结

  • 需求满足程度上,四家产品在元数据、数据标准、数据质量、数据资产、数据服务/安全模块上基本满足数据治理需求,但如果考虑数据标准前置落地需求,则只有B满足需求
  • 从交互体验上,B的产品功能最简洁,学习成本低、交互简单友好;A的产品功能较多,产品信息架构较混乱,功能分散、有部分功能重复,内在逻辑线不清晰,学习成本较高,交互体验较差;C的产品功能最丰富,整体产品逻辑清晰,但是功能层级嵌套较深,有些功能不易被发现,学习成本高,交互体验好

 

本文由 @细嗅蔷薇 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!

随意打赏

提交建议
微信扫一扫,分享给好友吧。