据地图平台是字节跳动内部的大数据检索平台，每天近万的字节员工在此查找所需数据。数据地图通过提供便捷的找数，理解数服务，大大节省了内部数据的沟通和建设成本。

数据血缘图谱介绍

字节的数据可分为端数据和业务数据，这些记录往往需要通过加工处理才能产生业务价值。数据加工处理的流程一般是读取原始数据，进行数据清洗，再经过多种计算和存储，最终汇入指标、报表和数据服务系统。数据血缘描述了数据的来源和去向，以及数据在多个处理过程中的转换，是组织内使数据发挥价值的重要基础能力。

数据地图平台在 2021 年接入了全链路核心元数据，包括但不限于：Hive、Clickhouse、Kafka、BI 报表、BI 数据集、画像、埋点、MySQL、Abase。这些数据全部要通过数据血缘连接起来，进而可以进行影响分析、内部审计、SLA 保障、归因分析、理解和查找数据、自动化推荐等操作。

随着内部数据不断膨胀，简单的数据血缘图谱已经无法满足万级表血缘的关系展示。一些突出的问题包括看不清单个表的直接上下游，看不清数据链路，整体情况等等。因此需要重构一种更清晰、灵活、便利的方式。下图简单展示了优化后的使用效果。

在新版血缘图谱中，我们可以直接清晰的看到每个表的多层上下游依赖关系，甚至可以直接看到一些特殊场景下用户关注的表属性，通过点击节点高亮查看数据链路，更可以看清每层的统计信息。在下文中我们将详细拆解优化的全过程。

需求发现

要做出一个能满足用户需求的图产品，首先是要清楚用户想从图中获取什么信息，从而有针对性的将这些信息展示出来。从血缘图谱的背景本身可以推断出用户希望在图谱中查看表之间的关系，查看关系链路，而更多的使用场景待发掘。因此我们对内部重度用户进行了访谈，整理得出了以下不同用户角色使用数据血缘图谱的用户场景。

结合访谈结果和用户的日常反馈，数据血缘图谱的场景按目前用户的使用频率从大到小排序依次为：

抽象出几个主要需求即为：

1. 表血缘关系查看：能从图中清楚的浏览用户关注的表的上下游血缘关系，最好还能便捷的查看一些场景相关的表属性。
2. 表血缘链路查看：能清晰的查看到某个上游/下游表到用户关注表的链路情况。
3. 按关键指标分组查看：例如当表数据发生变更时，分组查看所有下游表的负责人以便通知变更。
4. 筛选关键信息查看：例如用户找数据指标的时候，仅看相关的报表更高效。

问题分析

其实上述需求旧版血缘图谱都有一定程度上的满足，我们需要去找出旧版血缘图谱提供的功能为什么不满足用户需求，有哪些问题需要在新版中注意避免。

• 概览：在数据量较小的情况下可用，在数据量大的时候完全不可用。看不清每层有多少个节点，层级关系是怎么样的，且链路查看困难。

• 旧版血缘图谱中功能细节粗糙：
• 用户无法直观的区分节点：旧版节点上显示了表类型、库名、表名。因此表名只能显示几个字符，不具备辨识度。
• 无法知晓表到表之间的任务：旧版血缘图谱仅在侧边栏列出了与当前表相关的任务有哪些并未列出加工逻辑的对应关系，归因分析困难。
• 分组结构不清晰：旧版是在原图中框出节点来展示分组的。一方面是空间利用率更低，另一方面是看节点时难定位到所属分组，看分组时则无法看清包含的节点。
• 筛选功能不直观：符合筛选条件的节点高亮展示，而被筛掉的表仍在图中，无法有效提升用户浏览效率。

方案设计

用户在使用过程中看重的是查看关系的效率和属性的完备度，因此在设计优化方案时会尽量从这两点出发去考虑。

首先是表数据查看的效率问题。看不清表名，无法区分相同前缀的表是用户痛点之一。首先我们统计了现有表的平均字符数是 47 位，于是调宽了节点让用户能更直观的区分表名。用数据地图平台中通用的类型图表来代替色块图例，让数据类型一目了然。

其次对于数据量大时看不清数据关系的问题，我们需要一个更紧凑清晰的数据呈现方式。通过需求分析和用户调研，我们了解到用户关心的是节点所在层级和节点之间的联系。对于同一层级节点的先后顺序，次层级节点之间的关系不是很看重。

说到紧凑的布局方式，自然而然我们就想到了列表。如果能用一个列表来承载层级血缘的节点，用连线来连接不同层级的节点，那么久可以表达节点之间的血缘关系了。当节点较多超出一屏时可以拖动此列滚动条来查看更多节点，连线随之刷新位置。当层级不满一屏时整体居中展示，层级过多超过一屏时可以左右滑动查看。这样在保留层级结构信息的同时最大程度的利用了可视区域，展示出了尽可能多的数据。

新版血缘图谱支持了点击任意节点则高亮该节点到主节点的链路功能。配合列滚动和连线刷新，不管数据量多大总能看清一整条数据链路。

我们还在每列列表顶部增加了层级信息和节点统计，让用户能同时查看每个节点细节和节点的整体分布。最终实现效果如下图：

当用户想去找数，理解数或做归因分析时，不仅要了解一个表的上游依赖，更需要理解表的加工逻辑。因此我们在节点的连线上新增了任务信息。当用户 hover 到连线上后，连线会加粗高亮并弹出任务信息。我们还附上了大数据开发平台的对应任务链接，点击链接即可跳转到新页面查看任务逻辑详情。

在设计分组功能时，采用了每列独立分组的方式。一般认为用户会关注有对应分组数据的节点，因此总将有分组的数据放在上面，无分组数据的置底，这样排序能提升用户的浏览效率。

旧版血缘图谱的筛选功能是在前端处理的，由于一些性能限制导致筛选后只能显示部分数据，用户无法得知符合条件的节点是否已经全部展示。新版血缘图谱针对这个用户痛点，将前端筛选改为了服务端筛选，尽量展示全符合要求的数据。每个层级的顶栏对应更新为筛选后的统计信息。同时更新连线，如果筛选后节点之间是有关联的，也会展示关联关系和高亮关系链路。

不同职能的用户在不同场景下使用血缘图谱时关注的节点属性并不相同，如果血缘图谱可以直接在图上显示用户当前想关注的表属性就能帮助用户更高效的解决问题。于是我们在血缘图谱上设计了属性展示功能，用户可以勾选自己感兴趣的属性直接显示到图中。比如下图中展示了每个节点表热度和生命周期两个属性。

技术实现

技术选型

在编码实现之前，我们需要进行技术选型。好的选型往往能让编码事半功倍。在做技术选型时，我们会主要考虑实现复杂度、研发周期、可扩展性三个角度。分析整个血缘图谱的需求：

1. Canvas 实现滚动条，节点文字标签混排很复杂，要达到 HTML 的美观度需要大量调试，后续迭代要新增属性标签，进行流式布局会很头痛。开放组件给别的产品复用也有很大的定制成本。而这些问题使用 React 框架渲染就可以轻松解决。
2. 如果用 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

一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。

欢迎加入字节跳动数据平台官方群，进行数据技术交流、获取更多内容干货

点击 大数据研发治理套件-火山引擎 了解产品详情

在前面

今年国庆假期终于可以憋在家里了不用出门了，不用出去看后脑了，真的是一种享受。这么好的光阴怎么浪费，睡觉、吃饭、打豆豆这怎么可能（耍多了也烦），完全不符合我们程序员的作风，赶紧起来把文章写完。

这篇文章比较基础，在国庆期间的业余时间写的，这几天又完善了下，力求把更多的前端所涉及到的关于文件上传的各种场景和应用都涵盖了,若有疏漏和问题还请留言斧正和补充。

自测读不读

以下是本文所涉及到的知识点，break or continue ?

• 文件上传原理
• 最原始的文件上传
• 使用 koa2 作为服务端写一个文件上传接口
• 单文件上传和上传进度
• 多文件上传和上传进度
• 拖拽上传
• 剪贴板上传
• 大文件上传之分片上传
• 大文件上传之断点续传
• node 端文件上传

原理概述

原理很简单，就是根据 http 协议的规范和定义，完成请求消息体的封装和消息体的解析，然后将二进制内容保存到文件。

我们都知道如果要上传一个文件，需要把 form 标签的enctype设置为multipart/form-data,同时method必须为post方法。

那么multipart/form-data表示什么呢？

multipart互联网上的混合资源，就是资源由多种元素组成，form-data表示可以使用HTML Forms 和 POST 方法上传文件，具体的定义可以参考RFC 7578。

multipart/form-data 结构

看下 http 请求的消息体

• 请求头：

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryDCntfiXcSkPhS4PN 表示本次请求要上传文件，其中boundary表示分隔符，如果要上传多个表单项，就要使用boundary分割，每个表单项由———XXX开始，以———XXX结尾。

• 消息体- Form Data 部分

每一个表单项又由Content-Type和Content-Disposition组成。

Content-Disposition: form-data 为固定值，表示一个表单元素，name 表示表单元素的 名称，回车换行后面就是name的值，如果是上传文件就是文件的二进制内容。

Content-Type：表示当前的内容的 MIME 类型，是图片还是文本还是二进制数据。

解析

客户端发送请求到服务器后，服务器会收到请求的消息体，然后对消息体进行解析，解析出哪是普通表单哪些是附件。

可能大家马上能想到通过正则或者字符串处理分割出内容，不过这样是行不通的，二进制buffer转化为string,对字符串进行截取后，其索引和字符串是不一致的，所以结果就不会正确，除非上传的就是字符串。

不过一般情况下不需要自行解析，目前已经有很成熟的三方库可以使用。

至于如何解析，这个也会占用很大篇幅，后面的文章在详细说。

最原始的文件上传

使用 form 表单上传文件

在 ie时代，如果实现一个无刷新的文件上传那可是费老劲了，大部分都是用 iframe 来实现局部刷新或者使用 flash 插件来搞定，在那个时代 ie 就是最好用的浏览器（别无选择）。

DEMO

这种方式上传文件，不需要 js ，而且没有兼容问题，所有浏览器都支持，就是体验很差，导致页面刷新，页面其他数据丢失。

HTML

 <form method="post" action="http://localhost:8100" enctype="multipart/form-data">

        选择文件:
            <input type="file" name="f1"/> input 必须设置 name 属性，否则数据无法发送<br/>
<br/>
            标题：<input type="text" name="title"/><br/><br/><br/>

        <button type="submit" id="btn-0">上 传</button>

</form>

复制代码

文件上传接口

服务端文件的保存基于现有的库koa-body结合 koa2实现服务端文件的保存和数据的返回。

在项目开发中，文件上传本身和业务无关，代码基本上都可通用。

在这里我们使用koa-body库来实现解析和文件的保存。

koa-body 会自动保存文件到系统临时目录下，也可以指定保存的文件路径。

然后在后续中间件内得到已保存的文件的信息，再做二次处理。

• ctx.request.files.f1 得到文件信息，f1为input file 标签的 name
• 获得文件的扩展名，重命名文件

NODE

/**
 * 服务入口
 */
var http = require('http');
var koaStatic = require('koa-static');
var path = require('path');
var koaBody = require('koa-body');//文件保存库
var fs = require('fs');
var Koa = require('koa2');

var app = new Koa();
var port = process.env.PORT || '8100';

var uploadHost= `http://localhost:${port}/uploads/`;

app.use(koaBody({
    formidable: {
        //设置文件的默认保存目录，不设置则保存在系统临时目录下  os
        uploadDir: path.resolve(__dirname, '../static/uploads')
    },
    multipart: true // 开启文件上传，默认是关闭
}));

//开启静态文件访问
app.use(koaStatic(
    path.resolve(__dirname, '../static') 
));

//文件二次处理，修改名称
app.use((ctx) => {
    var file = ctx.request.files.f1;//得道文件对象
    var path = file.path;
    var fname = file.name;//原文件名称
    var nextPath = path+fname;
    if(file.size>0 && path){
        //得到扩展名
        var extArr = fname.split('.');
        var ext = extArr[extArr.length-1];
        var nextPath = path+'.'+ext;
        //重命名文件
        fs.renameSync(path, nextPath);
    }
    //以 json 形式输出上传文件地址
    ctx.body = `{
        "fileUrl":"${uploadHost}${nextPath.slice(nextPath.lastIndexOf('/')+1)}"
    }`;
});

/**
 * http server
 */
var server = http.createServer(app.callback());
server.listen(port);
console.log('demo1 server start ......   ');
复制代码

CODE

https://github.com/Bigerfe/fe-learn-code/