有赞数据地图实践

分享嘉宾：何会会 有赞 数据开发工程师

编辑整理：xiaomei

出品平台：DataFunTalk

导读：今天和大家分享一下数据地图相关知识，以及有赞在数据地图方面的实践。主要分为4个部分：

数据地图的背景

数据地图是什么

有赞数据地图实践

总结和展望

1. 数据地图背景

每个企业都有和数据相关的工作过程，如数据采集、数据开发、数据搜索、数据管理、数据分析、数据挖掘，还有故障排查、链路优化等，这些都是和数据相关的。在这些工作过程中通常会遇到很多痛点：

数据流转链路不清晰，想找数据时找不到想要的数据；

管理数据时，无法高效地进行数据管理；

发生故障时，故障排查效率比较低；

想优化一条链路时，比较困难。

数据地图是以解决这些痛点为基础研究开发的。

2. 数据地图的目标

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

让用户能够高效地能找到想要的数据；

能够方便地查看多种多样的数据血缘信息；

能够实现高效的数据管理；

高效地应对故障，比如在故障排查时能够快速评估故障的影响面以及恢复时间；

能够根据用户不同需求场景看到不同的链路视角。

为什么叫数据地图？数据地图其实就是“数据+地图”。地图大家都不陌生，如高德地图，具有找地点、路径分析、搜索周边相关、地点管理等能力。数据也具备独立特征，包括类型全、数据是流通的不是孤立的、数据生命周期比较长。

数据的特征加上地图的普遍能力，就构成了数据地图的独有能力，包括：数据搜索，用户可以搜索想要的任何数据；数据高效管理，可以高效的管理数据；数据分析能力，数据路径分析的能力，比如血缘查看、关键路径排查。

接下来，从数据全链路、数据搜索、数据管理、数据链路分析四个方面介绍一下有赞数据地图实践。

1. 数据全链路

之所以称为数据全链路，是因为其覆盖数据类型、任务类型、平台类型、元数据类型、血缘类型都比较全。其中，元数据包含了基础元数据，技术元数据，趋势源数据、血缘信息；血缘类型实现了表表血缘、表任务血缘、字段血缘。基于强大的基础采集能力，构建了上层的数据搜索、数据管理、链路分析等应用。有赞数据地图对各个平台采集的数据进行抽象，抽象成表和任务模型进行统一管理，完成了从业务到业务的闭环。

2. 数据搜索

数据采集、全链路构建完成后，就要对数据进行高效搜索构建。数据搜索的目标是使找数据更精确、更容易。

如何做到找数据更容易？找数据是技术人员和业务人员经常会面对的场景，之前是根据关键字和技术元数据直接找数据，但业务人员不懂，找数据就不方便。因此从业务的角度，如业务过程、业务实体方面，如何让业务人员更容易找数据。

解决数据更精确的问题，首先匹配的内容是比较广泛的，包括表、任务、标签、业务指标、文档、商业智能的报表等都是有赞匹配的内容，见截图。在匹配内容符合基本查询条件后，把最想找的数据优先排在前面。实现数据优先排序，是根据搜索结果项进行打分，分数较高的排在前面。打分会包含加分项和减分项。加分项包括当前owner、下游数越多、质量分越高、访问次数越多、公共层的表，均是作为加分项优先展示；减分项则包含设置了替换表（该表后续不再维护或会被新表替代）、临时表，均为不推荐表，作为一个减分项。每项均设置一个相对应的权重，最终得出分数进行排序，将分数高的优先呈现给用户，实现找数据更精确，更匹配用户搜索的诉求，这是有赞对于数据搜索的优化。

3. 数据管理

有赞采用数据专辑的方式进行数据管理，类似歌曲专辑一样，按不同维度对数据进行划分，实现对数据的分类管理。用数据专辑对数据进行管理有4个好处：

结构化管理数据的方式，解决Word、文本编辑器、webExcel、shimo等非结构化数据管理方式后期使用不方便的问题；

协作更加方便，可进行点赞、分享、实时添加/删除数据、多人协作；

管理维度多样化，可从业务维度、优先级维度、重要性维度、治理维度、用途维度、其他特征维度等对数据专辑进行划分；

数据专辑对表批量管理，可对表设置权限、下线、核心表链路保障、业务拆分实现专辑表数据的拆分。数据专辑是在不同场景下非常好的数据管理模式。

4. 数据链路分析

① 血缘查看

可以自由查看数据的血缘。数据血缘的种类比较丰富，包含表表血缘、表任务血缘、字段血缘。表的上游或下游个数都会很多，这种情况下想要找到用户比较关注的上下游就会比较困难。有赞做了很多优化的体验，最上游&最下游的快捷方式，为用户提供只看ODS层、业务层最上游的表或只看最下游的表；聚合查看，满足当上游或下游个数非常多的情况下，按照库、owner、数据类型、表类型进行聚合，快速查看用户关注的表；节点搜索，针对节点进行关键词搜索；节点排序，按照表名的字典顺序进行排序，有助于用户快速定位表。

② 异常分析

异常分析，当目标表或业务表出现异常时，需要排查原因，就可以用到异常分析的场景。当前异常会分三种情况，电话告警、表未产出、规则失败。在发生异常时，需要以目标表为源头，向上溯源找到所有有异常的表；以有异常的表为源头，经过一些列的剪枝优化，将相对简单的异常路径展示出来。

剪枝优化是在血缘汇总信息上下游数量比较多的情况下，如果将所有的点全都展示出来会很混乱，要对异常节点到目标表的所有的路径进行剪枝。

剪枝的目的是，减少图中非必要节点和边的数量，这样异常路径看清来会很清晰。

优化剪枝的2个关键步骤：

找到要剪枝的起点；

下游选择的策略，包含上游个数最多的节点策略和最靠近目标表的策略。当前有赞的选择策略是上游个数最多的节点。

针对有赞当前下游选择的策略，异常分析剪枝算法为：

找到上游所有有源头的表，看是否有下游，如果没有下游即为目标表，直接返回；如有下游且下游个数为1，返回该下游；如有下游个数大于1，查看下游节点是否有异常节点，如有异常节点，返回下游节点异常集合；如果下游节点都为正常节点，则查看是否有待剪枝的节点，如有则返回下游待剪枝节点集合；如无则找出下游节点里面上游最多的节点，查看是否成环，如未成环则表明正常直接返回；如成环则将该下游节点从下游集合中拿掉，再找出下游节点里上游最多的节点，如此往复，直到不成环返回。

基于该策略目前效果是明显的，可从1000多个节点剪枝到几十个。

当前策略是以减少节点个数为目标，而最靠近目标表的策略是以减少边个数为目标，两个策略侧重点不同。

③ 影响分析&产出时间预估

影响分析&产出时间预估实践，其场景是当核心表出现故障时，需要快速评估一个表的影响面和恢复时间。其核心流程是向下评估影响面，向上预估产出时间，根据上游表的产出时间预估出本表的产出时间，其算法在下面详细介绍。

首先解释一下运行时长的概念，有赞中运行时长取的是最近7天的中位数，来减少特殊情况造成的不准确问题。

其预估产出时间算法为：

如果当前节点任务已经完成，预计完成时间=当前节点实际完成时间；如果当前节点尚未完成，则查看当前节点关联的任务是否正在运行，如果关联任务在运行中且时长严重超出历史运行时长，则预计完成时间=当前时间+历史运行时长+1h处理恢复时间，作为该表的预计完成时间，该公式是由有赞经常处理故障的数仓及其他人员共同商讨总结的算法；如果当前运行时长正常，则预计完成=实际开始时间+历史运行时长；如果当前节点已运行过但运行失败，无法预估产出时间，返回-1，需要人工重启；如果当前节点任务没有失败，并且不在运行中，表明该节点任务尚未运行，则查看是否存在上游节点，如果有上游，获取其上游所有节点的预计产出时间，如果上游有不可预估的情况，那么产出时间无法预估，返回-1；如果上游预计产出时间都可预估，则该节点的预计完成时间=Max（上游产出时间，历史开始时间，当前时间）+历史运行时长；如果没有上游，说明该节点为源头节点，如果当前时间＞历史开始时间，说明节点未正常启动，无法预估产出时间，返回-1，需要人工启动发起调度；如果当前时间＜历史开始时间，说明节点未调度，则预估完成时间=历史完成时间。

预估产出时间算法虽然复杂，但在有赞实践过程中发现，预估产出时间与最终产出时间是很接近的，目前是有赞比较好的一个预估产出时间的算法。

④ 链路优化

对数据产生的链路优化实践，在表成本太大、链路太长、产出时间太晚等情况下需要进行链路优化。有赞目前已针对优化表产出时间场景开展了相关实践，其链路优化步骤为：

先找到关键路径（在这里关键路径是以当前表为叶子节点，向上找直接上游里最慢的节点，再找最慢节点组成的路径，称之为关键路径），开展关键路径节点的时间进行优化，表的产生时间会往前提；

如关键路径找到后发现节点上游都没有问题，则查看表自身任务的启动时间是否合理，去优化表任务的启动时间；

如发现表无法优化了，可考虑表是否可以替换。根据字段血缘来看，产出最晚的上游表的被使用了哪些字段，根据字段血缘来看目标表是否用到这些字段，如果未使用相关字段，则可创建一个新表，将产出时间最晚的字段去掉，从而要目标表去引用新表，将最影响产出的字段去掉，达到链路优化目的。

⑤ 数据监控保障

在上游发生变化时，如何通知下游？有赞有2个措施开展数据监控保障，包括定时任务和手动触发：

定时任务是扫描数据开发平台发布到调度中心的任务，检测任务语法是否通过、任务使用的输入表是否存在、输入表使用的字段是否存在，提前预知并通知下游用户，避免晚上起夜处理或对数据问题后知后觉。

手动触发是在数据治理工作人员现有表要用新表或字段替换时，可手动触发检测表对下游任务、下游表或下游字段的影响，在确定没有影响情况下，再改变现有表情况。

1. 总结

交互体验方面，解决页面卡死问题，使页面交互更加流程，接口RT99%以上均小于1s。

使用情况方面，增加了分析场景、开展日常运营工作，使得UV从90升到130、PV从2K升到了3.5K。

工作提效方面，提效1~3小时。

数据类型方面，当前支持29种数据类型、16种任务类型、覆盖平台数4个以上。

2. 展望

① 底层存储方式重构

目前血缘关系存储使用的是关系数据库，后面会使用图数据库推理引擎能力对底层存储进行重构，使链路分析场景，更高效、更准确。基于图数据库推理引擎，拓展数据地图能力。

②  更多场景支持

数据地图有更多的场景支持，比如，降本的工作；成本、质量、稳定性方面的链路优化，有更多场景来支撑；质量的保障，对下游应用的质量保障，可考虑使用数据专辑对数据地图数据进行批量保障，支持更多的链路场景。

③ 模型可视化

引用更多丰富的可视化组件，使数据模型和业务模型更直观地呈现出来，使理解数据和业务更加方便。业务模型可通过业务模型可视化实现对整个业务流程预览，每个业务过程都有对应的事实表、维度表、负责人等信息，在看数据和理解数据更加方便。比如有赞入职的新同学，对微商城业务及具体产品流程不了解，可通过业务模型可视化了解到：商家先浏览-再下单-等待商家支付-等待卖家发货-等待买家确认收货-交易成功，这个为微商城核心业务流程的链路，新同学看到这个业务模型，对有赞业务理解更加方便。ER模型是MySQL库模型的可视化。数据仓库中最常见的星型模型&雪花模型，可通过图形化的方式更加容易理解模型。

Q：有赞中字段血缘关系的解析是怎么实现的？每个字段的标签梳理是怎么做的？

A：有赞中团队分工比较细，字段血缘的解析是由数据基础平台工作人员负责解析，有赞地图工作人员负责调用离线服务获取字段血缘。

Q：数据治理效果中提到数据开发同学的起夜率，是一个强考核指标吗？该指标比重是多少？

A：数据治理要有一个效果指标来衡量工作的重要性，不是为做功能而做功能，而是真实的提供大家工作效率，减少一些起夜率，这些指标是有赞自己定义的。

Q：平台业务人员主要是哪些内容来解决什么问题？平台业务人员发现指标有错，如何从血缘上追溯呢？如数据产品经理发现数据有问题，和数据团队配合的链路是怎样的？

A：关于平台的问题，有赞数据血缘是接入了4种平台，数据开发平台、实时开发平台、商业智能、指标库。其中，数据开发平台，开展日常的数据开发任务，包括离线、实时开发。商业智能，即BI报表。指标库，提供给外界商家用的数据，显示商家后台有哪些指标，这些指标用了哪些表，都是从指标库配置的。

如数仓核心表出了问题，可快速定位到它的影响面。有故障产出时，通过建立沟通群的方式，产品经理比较在意的商家数据恢复时间问题上，有赞有预估产出时间功能，可秒级回复商家数据什么时候恢复的问题，采用这种方式实现各团队配合。