chromedriver放在哪个目录下_数据资产---数据地图和数据目录

对于数据资产，看资料发现大家对这个概念有不同的定义。本文讲的数据资产指的是企业数据所有可描述的部分，包含数据地图（数据的基本信息和数据的统计信息），数据目录，数据血缘，数据质量和知识库五部分。正常逻辑来讲，数据资产不包含知识库，但这里为了将整个数据处理流程闭环，我个人在数据中台加了一个知识库模块，后面会详细介绍该模块的作用。

数据资产主要回答以下几个问题：

1、企业有哪些业务？每个业务的繁荣程度，健康程度如何？（数据目录，数据质量）

2、指定业务有哪些表？表存在哪，有哪些字段，与其他表有没有依赖，通过哪个任务，如何产生的？（数据目录，数据地图，数据血缘）

3、表的数据波动如何？什么时间段高，什么时间段低，有没有质量问题？（数据质量）

4、当一个表的处理流程出现问题，会影响下游的哪些数据？流程恢复后，数据需要多久才能恢复正常？（数据地图，数据血缘）

5、指定表有哪些人能够访问？每天有谁访问？（数据目录，数据地图）

6、线上数据出过哪些问题？如何发现的？如何处理的？（知识库）

7、用户日常问题有没有总结整理？当用户遇到问题，是否有文档可查询问题处理方法？（知识库）

数据地图

数据地图主要是解决使用方以下几个问题：

1、根据关键词查表的问题

2、根据表名查字段，查表介绍的问题

3、查看表的大小，存储方式，存储周期

4、如果涉及到字段添加，字段修改找谁的问题

数据地图构建过程中的两个关键问题：存哪些数据？数据如何更新？

存哪些数据？

数据地图包含数据的基本信息和统计信息两部分。

基本信息：

1、字段信息：字段名，字段类型，字段描述等

2、存储信息：存储引擎，存储周期，存储路径等

3、描述信息：表所属的业务信息（业务名、业务id等），表介绍，负责人，表的业务标签，表的权限标签等

统计信息：

1、表的大小，也就是表所占的空间

2、分区个数

3、最新分区名

4、最近的更新时间

5、表每天的访问次数

数据如何更新？

数据地图包含数据基本信息和统计信息两部分。

基本信息更新

基本信息如何更新，需要看下数据地图的定位。如果所有的数据字段变更都是走数据地图，那么更新元数据时直接更新数据地图即可。

如果数据地图只是个展示工具，不负责修改元数据，那么数据地图更新的记录获取起来会比较麻烦：

如果元数据的存储引擎类似于mysql有binlog，这里可以通过监控db的binlog获取新增和更新的元数据信息。

如果元数据的存储引擎是clickhouse这种，自己存储元数据，无binlog，可以通过收集clickhouse client端的sql，解析sql获取新增和更新的元数据信息。

如果元数据的存储引擎是ES这种，自己存储元数据，但又没有client，没有sql这种。通过定时扫描ES元数据与数据地图数据对比，找出差异部分，更新即可。

总之，见招拆招，想办法获取到变化的信息并更新到元数据系统。

统计信息更新

统计信息的更新方式有定时更新和手动触发两种方式。但两种方式执行的是一套逻辑。

表大小，分区个数，最新分区名，最近的更新时间可以通过以下几个方式获取：

如果是mysql，由于mysql没有分区信息，其他信息可以通过访问information_schema得到；

如果是clickhouse，同样的可以通过system.parts获取相关的统计信息；

如果是ES，分区个数，最新分区，表所占的大小都需要自己写代码统计，最新更新时间获取可能会麻烦一点。如果你索引中开启了_timestamp（默认开启，线上一般会关掉该字段），直接取最新分区中最大的_timestamp即可，也可以将写入时间做为一个业务字段存到索引中，取最新索引中最大的时间即可；

如果是hive数据，分区个数，最新分区，表所占的大小，最新的更新时间都可以通过hdfs命令获取到。

表的访问统计这里可能会依赖于权限系统。

数据目录

数据目录是按照业务划分的，和业务强相关，所以这里不会有现成的样例，但划分规则还是可以聊下。

从业务方面来分，数据目录一般分三层：主业务，子业务和子业务对应的表；

数据目录的每个层级（数据表是最后一层）都会有业务标签。这里分几层不重要，如果业务复杂，四层五层都可以；如果业务简单，两层搞定更好。业务分块和分层一定是业务专家根据公司当前和未来的发展决定的，而不是平台开发同学拍脑袋想出的。当业务分层后，统计各个业务的使用情况，质量情况就简单了。

数据权限

数据权限这块其实和所有的平台都有关系。放在哪个模块都行，这里放到数据目录下面来讲。

这一块根据用户--应用组--表三层的映射关系控制用户对表的操作权限。

应用组这里可以分多层，比如说分为BG-部门-组三层，一个BG包含多个部门，一个部门包含多个组，一个组可以创建多个应用组。部门负责人有部门所有组的权限，一个普通员工可以有多个应用组的权限。

表这里还涉及到字段的读写权限控制。写权限如果要做的精细点，可以精确到字段级别；但在真实的场景下，大多还是读权限的问题，因此简单点来说写权限可以基于表来做。每个表只有表负责人（可以有多个）可以修改。至于字段的读权限，在记录应用组和表映射的时候，直接指定即可。比如说：

#关系型数据库
{
 "mapping_id": 1,
 "app_group": 1,  # 应用组的id
 "table": "ods_xx.ods_xxx_xxx_xxx1", #应用组可以访问的表
 "fields": "*"   #应用组可以访问表的哪些字段。*表示所有字段，如果需要指定字段，逗号隔开即可
}，
{
 "mapping_id": 1,
 "app_group": 1,
 "table": "ods_xx.ods_xxx_xxx_xxx2",
 "fields": "id,name,val"
}

今天先写到这，下次继续。