共计 4471 个字符，预计需要花费 12 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
数据地图平台是字节跳动外部的大数据检索平台，每天近万的字节员工在此查找所需数据。数据地图通过提供便捷的找数，了解数服务，大大节俭了外部数据的沟通和建设老本。
血统图谱由 xGraph 与数据地图平台团队单干研发。xGraph 从 Dataleap 业务中孵化，从底至上齐全自研，提供设计成熟的内置节点、连线、分组款式，精心打磨图剖析产品中罕用布局和交互，帮忙用户疾速搭建关系图产品。血统图谱解决方案已积淀到 xGraph 为更多团队复用。
数据血统图谱介绍
字节的数据可分为端数据和业务数据，这些记录往往须要通过加工解决能力产生业务价值。数据加工解决的流程个别是读取原始数据，进行数据荡涤，再通过多种计算和存储，最终汇入指标、报表和数据服务零碎。数据血统形容了数据的起源和去向，以及数据在多个处理过程中的转换，是组织内使数据施展价值的重要根底能力。
数据地图平台在 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 理解详情