基于Apache doris怎么构建数据中台(三)-数据资产管理

前面我们讲了什么是数据中台，及数据中台的架构及功能规划，这次我们开始从数据资产开始拆解每个功能模块做的内容

1.概述

数据资产管理平台可以定量评估数据资产的成本，价值，质量。帮助企业优化存储成本，节约计算资源。精细化的数据生命周期管理，帮助企业更好的管理数据的生产到销毁的整个生命周期。

在管理方面：管理者在规划数据文化建设时，对企业数据资产的全局构成、使用形式、 使用效果都需要详细的指标输入，往往这些指标都没有被统筹起来；在组织保障上， 需要多少资源、运作机制应该如何制定才能保障数据文化的落地，也需要运营指标来 辅助决策，所以管理者通常需从以下几个方面的问题进行思考：

1. 数据如何被用起来？
2. 数据保值后如何增值？
3. 组织已不再满足变化所需？
4. 管理体系如何建立？

在治理方面：企业拥有大量的数据资产之后，由于分工不同，一般的数据生产者、数据 消费者之间会随着时间推移、人员变动等因素，造成数据资产的信息成为无人维护的 静态状态，数据的存储成本、检索的理解成本会越来越高。这些数据资产分布在一片 数据沼泽中，难以分辨数据资产的成本、价值，更难以进行生命周期管理，甚至给数据 消费者带来难以跨越的信息鸿沟；数据治理通常关注以下几个方面的问题：

1. 数据的成本如何降低？
2. 数据生命周期如何管理？
3. 数据质量低，如何保证可用？
4. 数据价值如何评估？

在运营方面：数据资产从被建立，到数据内容的生产、到被使用，各环节用户各自所关注的、所进行的工作重点不一致；从数据管理视角、数据生产视角、数据应用视角来 看，各个视角之间的目标实现、工作重点、协作方式，不再以点对点的形式存在，而是 贯穿于整个数据链路中，数据运营正是为了从以上角度来发现问题、解决问题，作用是：数据运营会从“战略、执行、目标拆解、跟踪实现”各个阶段进行统筹，对运营目标 负责。数据运营通常关注以下几个方面的问题：

1. 有限的资源如何科学分配？
2. 数据的关系如何互相影响？
3. 如何发现最迫切的问题？
4. 数据运营缺乏工具、渠道；

在使用方面：数据只有被用起来，才能发挥其应有的价值。然而当前部分的企业使用 数据的情况并不乐观。根据调研统计，只有约 14%的企业数据相关的从业人员认为使用 数据是方便的。数据使用是否方便，可从两个维度来判断，一是工具：是否能够具备 “顺畅的、快捷的、容易完成的”数据使用场景的工具集；二是时间：是否可以快速地查找、信任、理解数据。根据调研统计，有不低于 80%的时间消耗在“查找-理解-信任”数据的过程中；这两个现状成为阻碍数据使用的最大的瓶颈。我们归纳了数据使用的几 大问题点，如下所示：

1. 数据孤岛亟需打破；
2. 发现、理解、使用数据耗时费力；
3. 知识经验无法共享、迭代；
4. 沟通不畅、权责不明；
5. 个人信息无法归档；
6. 数据安全如何保障；

本次只介绍数据资产管理的核心元数据管理及数据资产数据地图，及数据生命周期管理，其他相关模块：数据接入，数据处理，数据服务等后面介绍

2.资源管理

实现集中对各种数据资源的管理，包括数据库，消息队列等的管理

实现数据库数据源管理：属性包括：所属业务名称，业务技术负责人，数据源IP，端口、数据库名称，用户名、密码，数据库类型（Mysql、oracle、SQLServer、Doris等），创建时间，创建人

实现Kafka数据源管理：属性包括：Kafka集群名称，Kafka Broker Server地址（示例：172.22.197.123:9020），对应zookeeper地址（示例：172.22.197.123:2181）,创建时间，创建人，集群负责人

3.元数据管理

元数据管理是整个系统的核心，所有的功能及业务流程都是围绕这个进行的，也是整个系统数据治理的核心

元数据主要解决三个问题：首先，通过建立相应的组织、流程和工具，推动业务标准的落地实施，实现指标的规范定义，消除指标认知的歧义；其次，基于业务现状和未来的演进方式，对业务模型进行抽象，制定清晰的主题、业务过程和分析方向，构建完备的技术元数据，对物理模型进行准确完善的描述，并打通技术元数据与业务元数据的关系，对物理模型进行完备的刻画；第三，通过元数据建设，为使用数据提效，解决找数据，理解数据，问题评估难题以及取数和数据可视化难题

4.元数据管理系统架构

这里元数据分为物理元模型和血缘元模型

5.元数据采集

元数据采集分为人工录入和自动抽取，通过人工录入的方式实现物理表的准确归属（包括该表属于仓库哪一层、对应的主题、业务过程、星型模型关系等）以及指标的采集，从而完成技术元数据和业务元数据的采集，通过自动抽取的方式完成生产元数据的采集和使用元数据的采集，主要包括：物理模型的依赖关系、存储占用、热度等信息

血缘关系：这块因为我们数仓是用的Apache doris，实现起来相对月Hadoop架构的简单了很多，通过Flume采集每个Doris Fe节点的审计日志（fe.audit.log）中的sql，通过阿里开源的数据库连接池Druid进行解析自动生成，这里同时还可以对SQL操作进行一些安全审计，比如Delete，truncate，drop及sql执行成功失败，执行时间等进行审计预警

5.1 元数据管理功能

1.业务数据元数据同步采集

实现对业务数据库数据表的元数据自动采集同步，包括建表语句中的中文备注信息，并将中文备注信息填写到对应的中文字段名称中，界面提供元数据修改功能，主要修改是添加业务技术负责人、修改表的中文名称、备注说明等信息，表的字段名称，类型、长度等信息不允许修改

2.数据仓表元数据采集

实现对数仓数据库数据表的元数据自动采集同步，包括建表语句中的中文备注信息，并将中文备注信息填写到对应的中文字段名称中，界面提供元数据修改功能，主要修改是添加数仓表对应技术负责人、修改表的中文名称、备注说明等信息，表的字段名称，类型、长度等信息不允许修改

3.元数据版本管理

因为数据库表存在结构变更，这里需要提供元数据多的历史版本管理，可以查询元数据历史版本信息

4.业务元数据变更管理及预警

对业务元数据的变更（主要是Mysql数据库），通过flink监控binlog的schema变更时间，一旦发现及时发送消息通知，后端监控变更消息队列，取到变更信息，发出元数据变更预警，并自动修改相应的元数据，生成版本信息。

5.元模型构建

分为以物理表为核心的基础元模型构建，以及以血缘为中心的血缘元模型。

基础元模型构建以物理表为中心，打通其与技术元数据（主题、业务过程、Schema）的关系，实现了物理表的清晰归属，打通其与生产元数据的关系，要加上物理表查询热度、资源消耗、查询密级等生产使用信息，打通其与指标、维度和应用的对应关系，为上层的取数应用建立了完备的元数据。

血缘元模型以血缘为中心，通过监控Doris审计日志，通过sql解析完成自动的血缘关系构建，不仅要构建从上游业务表到仓库表的物理血缘，而且要打通仓库表到下游对应报表的血缘，为后续的影响评估构建了完备的元数据基础

6.虚拟库及表的管理

对于通过API接口方式对接的数据，要通过页面手动添加库，添加表及表字段类型，字段名称，字段中文名称，字段长度等等，这样的目的是为了统一元数据管理方式

5.2 业务元数据

5.2.1 数据域主题管理

1. 数据仓库是面向主题（数据综合、归类并进行分析利用的抽象）的应用。数据仓库模型设计除横向的分层外，通常也需要根据业务情况进行纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念层次归类，目的是便于数据的管理和应用。
2. 数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。
3. 数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分

数据域的管理本质是一个分类管理，暂定二级分类

数据域主题作用于数仓内部数据表的管理及数据指标的分类管理

5.2.2 数据维度管理

建立统一的维度管理系统，实现对维度信息的统一管控，并为公司的数据产品提供统一的维度数据服务，包含维度开发管理，维度信息管理及维度数据服务三个方面。

维度管理：基于数据维度管理规范，对维度新增、修改、发布等生命周期进行统一管理。

维度服务：基于数据仓库ODS层模型源数据，建立服务化的维度表模型，在模型基础上建立维度，包括系统维度和手工维度定义，支持离线和实时大数据量的维度查询服务，维度创建完成后为各数据产品提供高可用，高性能的数据服务

1， 选择业务过程 根据业务场景以及可用数据源 2， 声明粒度 根据事实表及应用场景，确定汇总粒度，一般尽可能的用最细粒度 3， 确定维度 根据确定的粒度，定义对应的维度，最细粒度，也是最低层次的维度 4， 确定事实 确认将哪些事实放到事实表中，维度表只是做关联，不做维度数据的查询服务。

维度定义： 维度按集团产业进行指标一级业务域划分，包括：智能工厂、供应商、采购、销售、门店、仓储、运输、POS等；在各业务域下，对维度进行主题分类，主要有：时间类（DT）、组织类（OG）、产品（PD）、销售平台（SP）、经营方式（BM）、终端(TM)、业务渠道(BC)、营销(MK)、会员(MB)、采购模式(PM)、地点(AD)等。

维度管理：

维度：维度平台要支持快速定义维度,通过设置维度的基本信息，选择维度映射的维度表，做好维度与维度表的映射，设定维度的一些特性（布尔维度，时间维度，杂项维度等），检测维度的定义结果。达到了让业务人员能够只是通过页面操作就可以制定需要的维度。

维度表：数据开发人员可以通过维度库平台定义维度表，定义好之后可以集成数据仓库的同步任务一键将仓库的数据同步到维度表中，将维度表与维度做映射关系。

维度层级：维度库平台支持定义维度层级，只要是维度库平台上有的维度表并且做好维度与维度的映射关系之后，就可以定义需要的维度层级，根据维度层级提供维度值的上卷下钻查询服务。

维度血缘：提供了维度，指标，报表的血缘关系，以及还准备做的维度数据的血缘，维度，指标，报表调用次数的血缘等等。

5.3 数据地图

数据地图提供数据检索能力，致力于提供蜀海生态内丰富数据源的检索服务。完成找数据的过程，通过该平台，用户可以以较小成本找到所需数据，无论是业务数据、数仓数据库表或字段、数据指标，数据服务都可以通过该功能完成检索，对业务及数据开发使用人员能很快的找到需要的资源，并根据搜索的结果展示了解数据

1.找表

通过统一的查询页面，通过输入关键字完成数据表的检索

在检索的结果页面找到符合自己的数据，进去查看表的详情页信息，详情页展示内容包括

• 表的详情信息
• 表的字段信息
• 表的数据预览（最多10条）
• 表的血缘关系（包括表的上下游依赖，表的关联关系）
• 表的使用情况统计
• 表的建表语句
• 表评论信息，对于表有不理解的地方可以在这块进行提问
• 表的分区信息
• 表的使用说明
• 收藏及使用足迹记录

表明细

2.找维度

通过统一的维度检索页面，通过输入关键字检索字段信息，点击字段列表数据，可以查看该字段的信息

• 维度所在表的信息
• 维度关联表的信息
• 维度说明信息
• 该维度关联的指标数据信息
• 维度评论

3.找指标

通过统一的指标检索页面，通过输入关键字检索指标信息，点击指标列表数据，可以查看该指标的信息

• 显示指标的基本信息
• 指标的生产链路
• 指标技术逻辑
• 指标字段信息（按维度和指标分开）
• 指标数据预览
• 指标使用说明
• 指标评论

指标明细：

4.找服务

通过统一的服务检索页面，通过输入关键字检索服务信息，点击服务列表数据，可以查看该服务的信息

• 数据服务接口基本信息
• 数据接口参数及响应说明
• 数据接口使用说明
• 接口权限

5.找报表

5.3 数据生命周期管理

主要是为了完成数据从产生、采集、处理、存储、加工、使用及归档销毁的全生命周期的各个阶段的管理

根据数据的使用情况或者根据 用户设定的数据生命周期，及时帮用户销毁数据，在大数据研发中大部分用户关注的是数据怎么进入数据仓库，但是很少有用户会关注数据的销毁。随着时间持续性发展之后数据会无限量增加，数据仓库慢慢的成为一个很大的成本负担。数据生命周期管理，关注于数据整个链路的生命周期管理，及时推荐无效数据下线。 在数据下线的过程中，很多用户会担心数据误删，完备的数据下线机制，在有效期限内可以对数据进行恢复，确保数据误删的情况。

主要是通过数据接入，数据ETL、数据地图、元数据、数据指标各个系统在使用过程中的使用日志数据，对数据进行一个全面的采集及分析，生成数据在各个阶段的数据指标。

生命周期管理关注以下内容：

1. 数据归档管理：对符合归档的数据进行归档到冷存储上，减少存储及计算成本
2. 统计在数据每个阶段的数据变化趋势
3. 业务库DDL变更趋势
4. 数据热度排名：数据库，数据表的使用热度统计
5. 数据库数据量排名，
6. 库内数据表数据排名

根据数据的使用情况或者根据 用户设定的数据生命周期，及时帮用户销毁数据

1. 在大数据研发中大部分用户关注的是数据怎么进入数据仓库，但是很少有用户会关注数据的销毁。随着时间持续性发展之后数据会无限量增加，数据仓库慢慢的成为一个很大的成本负担。数据生命周期管理，关注于数据整个链路的生命周期管理，及时推荐无效数据下线。 在数据下线的过程中，很多用户会担心数据误删，完备的数据下线机制，在有效期限内可以对数据进行恢复，确保数据误删的情况

5.4 数据资产全景视图

数仓界的360，可以定量评估数据资产的成本，价值，质量。帮助企业优化存储成本，节约计算资源。精细化的数据生命周期管理，帮助企业更好的管理数据的生产到销毁的整个生命周期。

• 资源视图
• 数据库统计
• 表统计
• 表引用统计
• 数据在各个生命周期阶段的资源使用情况
• 文件数量：总文件数，累计存储量，当月优化存储量
• Job统计
• 优化建议等
• 足迹

5.5 数据问答

我们为数据地图中的找表，找维度，找指标，找服务，找报表都提供了数据问答功能，通过评论问答功能，帮助用户可以快速得到问题反馈：如果用户看了信息后还是感到有问题，提供评论问答的功能，用户通过这个功能可以进行提问，会有相应的负责人进行回复。对于重复问反复问的问题，用户通过查看其它人的提问和回复就能找到答案。并且负责人还会定期的将问答信息沉淀到对应的元数据里，不断地对元数据进行补充和完善

下一讲会讲解怎么基于Apache doris实现快速数据接入，零代码数据接入系统