数据地图渠道是字节跳动内部的大数据检索渠道，每天近万的字节员工在此查找所需数据。数据地图经过供给便捷的找数，理本领服务，大大节省了内部数据的交流和建造本钱。
数据血缘图谱介绍
字节的数据可分为端数据和事务数据，这些记录往往需求经过加工处理才干产生事务价值。数据加工处理的流程一般是读取原始数据，进行数据清洗，再经过多种核算和存储，终究汇入目标、报表和数据服务体系。数据血缘描述了数据的来历和去向，以及数据在多个处理进程中的转化，是安排内使数据发挥价值的重要基础能力。
数据地图渠道在 2021 年接入了全链路中心元数据，包含但不限于：Hive、Clickhouse、Kafka、BI 报表、BI 数据集、画像、埋点、MySQL、Abase。这些数据全部要经过数据血缘衔接起来，进而能够进行影响剖析、内部审计、SLA 确保、归因剖析、理解和查找数据、自动化推荐等操作。
随着内部数据不断膨胀，简略的数据血缘图谱已经无法满意万级表血缘的联系展现。一些突出的问题包含看不清单个表的直接上下流，看不清数据链路，全体状况等等。因而需求重构一种更明晰、灵敏、便当的方式。下图简略展现了优化后的运用效果。
在新版血缘图谱中，咱们能够直接明晰的看到每个表的多层上下流依靠联系，甚至能够直接看到一些特殊场景下用户重视的表特点，经过点击节点高亮检查数据链路，更能够看清每层的核算信息。在下文中咱们将详细拆解优化的全进程。
需求发现
要做出一个能满意用户需求的图产品，首先是要清楚用户想从图中获取什么信息，然后有针对性的将这些信息展现出来。从血缘图谱的背景自身能够推断出用户期望在图谱中检查表之间的联系，检查联系链路，而更多的运用场景待开掘。因而咱们对内部重度用户进行了访谈，整理得出了以下不同用户角色运用数据血缘图谱的用户场景。
结合访谈成果和用户的日常反应，数据血缘图谱的场景按现在用户的运用频率从大到小排序依次为：
| 场景 | 用户重视 | 场景描述 |
|---|---|---|
| 影响剖析 | 下流 | 当处于血缘上游的研制同学修正使命前，经过检查自己的下流，告诉对应财物或使命的担任人，进行相应的修正，否则会造成严峻的生产事故。 |
| 找数理本领 | 上游 | 在找数据时，经过检查一份数据财物的血缘，来更多的了解它的“前世此生”，能够更好的判定当时财物是不是自己需求的，或者是不是值得信任的。就像了解一个人，能够从他周围的朋友中得到许多信息一样，是对这个人“生平”很好的补充。 |
| 链路梳理 | 链路 | 事前挑选已知的中心使命，经过血缘联系，自动化的梳理出其地点的中心链路。多用于内审和数据治理。 |
| 归因剖析 | 上游 | 当某一个目标或字段数据/产出时间等出问题时，经过检查血缘上游的使命或财物，排查出造成问题的根因。 |
| 运用剖析 | 下流 | 一个表的下流表越多，运用越频繁，能够以为价值越大。 |
笼统出几个首要需求即为：
- 表血缘联系检查： 能从图中清楚的阅读用户重视的表的上下流血缘联系，最好还能便捷的检查一些场景相关的表特点。
- 表血缘链路检查： 能明晰的检查到某个上游/下流表到用户重视表的链路状况。
- 按要害目标分组检查： 例如当表数据产生改变时，分组检查所有下流表的担任人以便告诉改变。
- 挑选要害信息检查： 例如用户找数据目标的时分，仅看相关的报表更高效。
问题剖析
其实上述需求旧版血缘图谱都有必定程度上的满意，咱们需求去找出旧版血缘图谱供给的功用为什么不满意用户需求，有哪些问题需求在新版中注意避免。
- 概览：在数据量较小的状况下可用，在数据量大的时分完全不行用。看不清每层有多少个节点，层级联系是怎么样的，且链路检查困难。
节点较少，比较明晰
很多节点，检查困难
- 旧版血缘图谱中功用细节粗糙：
- 用户无法直观的区别节点：旧版节点上显现了表类型、库名、表名。因而表名只能显现几个字符，不具备辨识度。
- 无法知晓表到表之间的使命：旧版血缘图谱仅在侧边栏列出了与当时表相关的使命有哪些并未列出加工逻辑的对应联系，归因剖析困难。
- 分组结构不明晰：旧版是在原图中框出节点来展现分组的。一方面是空间利用率更低，另一方面是看节点时难定位到所属分组，看分组时则无法看清包含的节点。
- 挑选功用不直观：契合挑选条件的节点高亮展现，而被筛掉的表仍在图中，无法有用提升用户阅读功率。
计划规划
用户在运用进程中垂青的是检查联系的功率和特点的完备度，因而在规划优化计划时会尽量从这两点动身去考虑。
首先是表数据检查的功率问题。看不清表名，无法区别相同前缀的表是用户痛点之一。首先咱们核算了现有表的均匀字符数是47位，于是调宽了节点让用户能更直观的区别表名。用数据地图渠道中通用的类型图表来代替色块图例，让数据类型一目了然。
其次关于数据量大时看不清数据联系的问题，咱们需求一个更紧凑明晰的数据出现方式。经过需求剖析和用户调研，咱们了解到用户关怀的是节点地点层级和节点之间的联系。关于同一层级节点的先后顺序，次层级节点之间的联系不是很垂青。
提到紧凑的布局方式，自可是然咱们就想到了列表。假如能用一个列表来承载层级血缘的节点，用连线来衔接不同层级的节点，那么久能够表达节点之间的血缘联系了。当节点较多超出一屏时能够拖动此列翻滚条来检查更多节点，连线随之改写方位。当层级不满一屏时全体居中展现，层级过多超过一屏时能够左右滑动检查。这样在保留层级结构信息的一起最大程度的利用了可视区域，展现出了尽或许多的数据。
新版血缘图谱支持了点击恣意节点则高亮该节点到主节点的链路功用。配合列翻滚和连线改写，不管数据量多大总能看清一整条数据链路。
咱们还在每列列表顶部添加了层级信息和节点核算，让用户能一起检查每个节点细节和节点的全体散布。终究完结效果如下图：
当用户想去找数，理本领或做归因剖析时，不只要了解一个表的上游依靠，更需求理解表的加工逻辑。因而咱们在节点的连线上新增了使命信息。当用户 hover 到连线上后，连线会加粗高亮并弹出使命信息。咱们还附上了大数据开发渠道的对应使命链接，点击链接即可跳转到新页面检查使命逻辑详情。
在规划分组功用时，采用了每列独立分组的方式。一般以为用户会重视有对应分组数据的节点，因而总将有分组的数据放在上面，无分组数据的置底，这样排序能提升用户的阅读功率。
旧版血缘图谱的挑选功用是在前端处理的，因为一些功能限制导致挑选后只能显现部分数据，用户无法得知契合条件的节点是否已经全部展现。新版血缘图谱针对这个用户痛点，将前端挑选改为了服务端挑选，尽量展现全契合要求的数据。每个层级的顶栏对应更新为挑选后的核算信息。一起更新连线，假如挑选后节点之间是有关联的，也会展现关联联系和高亮联系链路。
不同职能的用户在不同场景下运用血缘图谱时重视的节点特点并不相同，假如血缘图谱能够直接在图上显现用户当时想重视的表特点就能协助用户更高效的处理问题。于是咱们在血缘图谱上规划了特点展现功用，用户能够勾选自己感兴趣的特点直接显现到图中。比方下图中展现了每个节点表热度和生命周期两个特点。
技术完结
技术选型
在编码完结之前，咱们需求进行技术选型。好的选型往往能让编码事半功倍。在做技术选型时，咱们会首要考虑完结杂乱度、研制周期、可扩展性三个角度。剖析整个血缘图谱的需求：
- Canvas 完结翻滚条，节点文字标签混排很杂乱，要达到 HTML 的美观度需求很多调试，后续迭代要新增特点标签，进行流式布局会很头痛。敞开组件给其他产品复用也有很大的定制本钱。而这些问题运用 React 框架烘托就能够轻松处理。
- 假如用 DOM 完结不但很难完结箭头，在连线高亮时也很难灵敏处理层叠联系。在大数据量下连线许多，还简单出现功能问题。而这是 Canvas 的优势。
于是咱们结合两者之长，选用了 React + Canvas 的混合形式来完结血缘图谱。Canvas 居于底部，仅担任画连线。React 在上层担任烘托节点呼应 hover 等交互。DOM 层叠联系如下：
整个血缘图谱的初始化流程如下：
- 数据预处理： 服务端给到点边结构的数据。因为两个节点之间或许存在多个使命，对应会有多条连线记录。而血缘图谱中相同两个节点之间仅一条连线，对应多个使命。先做连线的合并处理。
- 核算节点层级： 服务端会给到点边结构的数据，依据主节点的连线联系向来历和去向两个方向做广度遍历来确认每个节点的层级。
- 数据分组： 按分组条件对每列数据进行分组核算。
- 节点布局： 依据层级和分组状况布局节点，相对应的每个节点有 { x, y, width, height 特点以确认每个节点的定位。
- 初始化画布： 画布用于制作连线，呼应连线的交互。采用内部自研的图形烘托引擎完结。
- 烘托节点： 依据节点的方位和分组状况用 React 烘托出每一列节点 DOM。
- 烘托画布： 依据远景的列和节点方位调整画布，制作连线。在烘托连线时分两个图层：默许状态连线在底层；高亮链路和高亮连线状态下的连线在上层。这样做的好处是高亮的连线永远在默许状态的上方，不必特殊处理图形的层叠联系。
完结细节
用这种混合形式的一个应战便是 Canvas 和 DOM 的改写率和同步率。 在血缘图谱中翻滚横向翻滚条和每一列的纵向翻滚条时 Canvas 要进行及时的改写以确保连线和节点的相对方位必定。
- 当图谱横向翻滚时，每条连线的斜率不变，仅仅端点左右平移了。咱们能够经过更新绘图矩阵来加速这种状况下的更新，不需求去重核算每条连线的方位。具体做法是监听容器的翻滚事情，依据容器的 scrollLeft 特点来更新绘图矩阵后重绘。
- 当图谱纵向翻滚时，与当时翻滚的列中节点相连的连线斜率和端点都有变化，而与翻滚列不直接相连的连线无需更新。咱们仅重核算并更新与当时列衔接的线条方位。
另一个应战是 DOM 节点在大数据量下的功能问题。 通常状况下咱们以为 Canvas 在大数据量烘托有更好的功能，而万级的 DOM 节点就会让用户在运用中感受到卡顿了。这时分咱们想到了按需烘托。用户在图谱可视区域中一屏能看到的节点数量是有限的，高度为 1120 的容器中，一列仅存在至多 30 个节点。假如仅烘托可见的节点，则能确保运用进程的流通。具体做法是在节点布局时添加以下进程：
- 依据视口的方位（首要是图容器的横向翻滚间隔 scrollLeft ）和每一列的翻滚间隔（首要是每一列容器的纵向翻滚间隔 scrollTop ）核算现在的可视规模。
- 核算节点坐标时判别是否在可视规模的上半屏和下半屏内，假如在此规模内则打标。多显现一屏的节点是期望在用户上下翻滚阅读节点时不会出现空白区域闪一劣等体验欠安的问题。
- 核算出每一列的实在长度。
在 React 烘托时更新每列容器的长度，将节点依据坐标肯定定位到正确的方位上。看起来就跟全量烘托的效果共同，烘托功率大幅提升。
可是问题并不止于此。在进行大数据量的纵向翻滚时，会发现帧率很低，交互还是不流通。剖析得知是因为列表翻滚时会在短时间内进行很多线条重核算和烘托。于是还要在 Canvas 制作上进行优化。
咱们从上图能够看到在单层节点许多的状况下，主节点与不行见节点的连线可见，可是没有任何价值，仅仅加重了用户对当时节点连线检查的担负。因而咱们对线条也进行了烘托优化，仅当一条连线两端的节点都在可见规模中时才烘托连线，在连线的 Tooltip 上添加了来历去向的展现辅佐检查。至此咱们做到了在杂乱状况下的流通展现血缘数据。
总结
以上便是数据血缘图谱的整个优化进程。在这个进程中，我总结起来便是在了解用户诉求的前提下，抑制地表达联系图中的信息，在合适的场景下突出中心的内容 。 做图剖析产品时不需求拘泥于某种形式，而是真实的从用户需求动身，为用户服务。
关于咱们
火山引擎大数据研制治理套件 DataLeap
一站式数据中台套件，协助用户快速完结数据集成、开发、运维、治理、财物、安全等全套数据中台建造，协助数据团队有用的下降作业本钱和数据维护本钱、发掘数据价值、为企业决议计划供给数据支撑。
欢迎加入字节跳动数据渠道官方群，进行数据技术交流、获取更多内容干货
点击 阅读原文了解产品详情
