ToB企服应用市场:ToB评测及商务社交产业平台

标题: 字节跳动数据质量动态探查及相关前端实现 [打印本页]

---

作者: 天空闲话    时间: 2022-8-28 21:07
标题: 字节跳动数据质量动态探查及相关前端实现

更多技术交流、求职机会、试用福利，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

 
需求背景

 
数据探查上线之前，数据验证都是通过写 SQL 方式进行查询的，从编写 SQL，到解析运行出结果，不仅时间长，还会反复消耗计算资源，探查上线后，只需要一次探查，就可以得到整张表的探查报告，但后续我们还发现了一些问题，主要有三点：
 

• 无法看到探查的数据明细以及关联的行详情，无法对数据进行预处理操作。
  
• 探查还是需要资源调度，等待时长平均分钟级。
  
• 与质量监控没有打通，探查数据的后续走向不明确。
  

 
针对这些问题，我们进一步开发了动态探查需求，解决的问题如下：
 

• 基于大数据预览的探查，支持对数据进行函数级别的预处理。
  
• 探查结果秒级更新，实时响应。
  
• 与数据监控打通，探索 SQL 的生成模式。
  

 
本文主要介绍动态探查的应用场景和相关的技术实现。
 
应用场景

 
探查主要应用在元数据管理，数据研发，数仓的开发以及数据治理，可为对数据质量有需求的场景提供数据质量的发现和识别能力。目标用户除了研发同学，也包含不是以 SQL 研发为主的群体，比如算法建模和数据挖掘等领域。
 
探查可以有效的打通三个闭环：
 

• 元数据管理 -> 探查 -> 数据预览探查（库表的质量报告）
  
• 数据监控  数据探查
  
• 动态探查 -> SQL -> 数据开发 -> 调试 -> 探查报告（质量分析）
  

 
 
名词解释

 

• 全量探查：基于库表的全量探查，后端引擎执行，展示探查后列的统计分布结果。
  
• 动态探查：基于抽样的部分数据探查，展示字段明细，可以使用操作对数据进行预处理，并实时动态的展示统计分布结果。数据获取后的过程都由前端执行。
  

 
两者的对比示意图
 
 
 
技术实现

除了数据的抽样部分在后端做，其他的都是前端实现的。包括大数据展示，探查计算，卡片联动，操作栈交互，以及未来要做的函数编辑器以及 SQL 生成。
 
技术架构

 

• 抽样能力：对数据进行基于质量分布特征的抽取。目前做的是随机抽样，后续尝试基于特征来抽样。
  
• 数据展现：大容量的数据载体，支持对数据处理的实时展现。前端目前是基于虚拟滚动 Table 做的，后续打算迁移到 canvas table 上。
  
• 前端探查：实时探查，可视化展现数据分布，突出质量指标。数据处理能力：函数处理能力（GroupBy..）
  
• 操作栈：需要对数据操作进行管理和回溯基于 immutable 和操作流实现操作栈。
  
• 编辑器：提供完整函数的功能，需要：词法解析，智能提醒，语法高亮。基于编辑器实现函数的功能，antlr4 实现词法解析，配合 monaco editor 实现一些智能提醒和语法高亮。
  
• 生成 SQL：将可视化的交互式操作转换成可执行的 SQL。
  

目前 sql generator 有以下几种方式：

• 基于链式调用生成
  
• 基于标签模板生成
  
• 基于 AST（抽象语法树）去做
  

 
关键技术及实现

大数据渲染

由于动态探查场景下前端需要支持最大 5000 条数据的展示和交互，所以在渲染这块存在比较大的压力，主要集中在探查卡片和数据预览两个部分。
 
探查卡片包含了特定列的部分关键信息汇总，比如 0 值、Null 值、枚举值等，如下图红框部分：
 
图片探查卡片部分由于存在较多定制化内容，所以采用了虚拟列表方案进行渲染，支持收起状态和展开状态：
 
图片数据预览部分展示的是探查的全部数据集合，可以快速查看原始数据的详细内容，由于内容同质化比较高，所以数据预览采用的是基于团队内部维护的 canvas 版本 Table 方案进行渲染，如下图红框部分：
 
卡片联动

由于卡片和数据预览列的宽度差异较大，并且上下两部分滑动是独立的，造成在选择查看某个具体列的时候，上下对齐位置会比较麻烦，为了解决这个问题，这块增加了自动定位功能，演示效果如下：
 
这部分需要解决的问题有两个：卡片中间点坐标计算和自动定位逻辑。
 
中间点坐标计算逻辑如下：

1. // 计算卡片中点坐标 index是卡片序号，adsorbSider表示是否吸边
2. getCardCenter(index: number, adsorbSider?: boolean) {
3.     ...
4.     // 获取卡片信息
5.     const cardBox: IBaseBox = this.cardList[index];
6.     // 获取列信息
7.     const colBox: IBaseBox = this.colList[index];
8.     const clientWidth = getClientWidth();
9.     if(adsorbSider) {
10.       // 吸边处理
11.       if(cardBox.offset < this.cardScroll) {
12.         return cardBox.offset;
13.       }
14.       if(cardBox.offset + cardBox.width - this.cardScroll > clientWidth) {
15.         return cardBox.offset + cardBox.width - clientWidth;
16.       }
17.       return this.cardScroll;
18.     }
19.     return getTargetPosition(colBox, this.tableScroll, cardBox);
20. }
22. // 获取滚动目标位置
23. // originBox: 滚动起始对象
24. // originScroll: 滚动起始左侧scroll
25. // targetBox: 滚动结束对象
26. const getTargetPosition = (originBox: IBaseBox, originScroll: number, targetBox: IBaseBox) => {
27.   const clientWidth = getClientWidth();
28.   if(!originBox || !targetBox) return 0;
30.   let offsetLeftSider = Math.max(originBox?.offset - originScroll, 0);
31.   if(offsetLeftSider + targetBox.width >= clientWidth) {
32.     if(targetBox.offset + targetBox.width > clientWidth) {
33.       // 此处容易出现吸边
34.       return targetBox.offset + targetBox.width - clientWidth;
35.     } else {
36.       return 0;
37.     }
38.   }
39.   const scroll = targetBox?.offset - offsetLeftSider + (targetBox.width - originBox.width) / 2;
40.   return Math.max(
41.     Math.min(targetBox.offset, scroll),
42.     0
43.   );
44. }

复制代码

获取到中点坐标后，自动定位需要符合如下规则：
 

• 选中卡片后，表格要自动滚动定位到下方居中对齐，无法满足对齐标准的，尽量靠近选中卡片位置。
  
• 选中表格列后，卡片要自动滚动定位到上方居中对齐，无法满足对齐标准的，尽量靠近选中表格位置。
  
• 搜索选中列后，卡片和表格要自动满足上面两个规则，并滚动到可视区域内。
  

 
规则中有几种边界情况，参考下图：
 
居中对齐是对于卡片和列宽在 scroll 距离允许情况下的理想对齐方式，贴边对齐是针对卡片在起始和结束位置 scroll 不足以满足居中对齐要求时候的对齐方式，除此之外还有一种是卡片的宽度远大于列宽，并且不是起始或者结束位置的时候所采取的对齐方式，如下如卡片 B 因为无法滚动，卡片 A 的宽度又占据了底部第二列的一部分，所以此时卡片 B 只能高亮和底部的列进行对齐。
 
操作栈

动态探查支持了对于探查结果的基础分析能力，比如列删除、过滤、排序等，如下图红框部分：
 
图片用户对于探查结果的每一次操作都会被记作一次操作，多次操作串联起来形成操作栈，可以自由的修改或者删减操作栈里的操作，并实时查看最新结果，以过滤操作演示效果如下：
 
图片操作栈部分需要处理的问题主要有以下几点：
 

• 如何管理多种操作进行串行计算
  

这里把所有操作都抽象成了Input + Logic = Ouput的结构，Input 是输入参数，此处可以是指某一列的数据、上一步操作的结果或者其他计算值，Logic 是操作的具体逻辑，负责根据 Input 转换生成 Output，Output 可以作为最终结果进行渲染，也可以再次进入下一环节参与计算，拿列删除操作举个栗子，下面是大体代码实现：

1. class ColDelOpt {
2.   run = (params: IOptEngineMetaInfo) => {
3.     // 操作Input部分
4.     const {
5.       columns = [],
6.       dataSourceMap = {}
7.     } = params;
8.     const {
9.       fields = []
10.     } = this.params;
12.     // 操作Logic部分
13.     const nextColumns = columns.filter((item) => !fields.includes(item.name));
15.     // 操作的Output
16.     return {
17.       columns: nextColumns,
18.       dataSourceMap
19.     }
20.   }
21. }

复制代码

 
可以看到 ColDelOpt 内部有一个 run 方法，该方法支持传入一个包含了列信息 columns 和数据集 dataSourceMap 的 params 对象，此处 params 即被抽象的外部输入参数 Input，run 方法内部的逻辑部分即被抽象的 Logic 部分，最后方法返回值包含了最新的 columns 和 dataSourceMap，即为 Output 部分。基于这种结构，用户所有的操作都可以被初始化成不同的 Opt 实例，由操作引擎统一调用实例的 run 方法，并传入所需的参数，最终得到计算结果。
 

• 某个操作被修改后如何进行二次计算
  

操作栈的计算是由计算引擎来完成的，引擎负责根据外部事件，来自动执行现有操作的数据处理工作，引擎执行流程和大体代码如下：
 
 

1. // 操作引擎
2. class OptEngine {
4.   // 操作列表
5.   private optList: IOptEngineItem[] = [];
7.   // 原始数据
8.   private metaData: IOptEngineMetaInfo = {
9.     columns: [],
10.     dataSourceMap: {},
11.   };
13.   // 执行算子
14.   optRun = () => {
15.     let {
16.       columns = [],
17.       dataSourceMap = {}
18.     } = this.metaData;
20.     if(!this.optList.length) return {
21.       columns,
22.       dataSourceMap
23.     };
25.     for(let index = 0; index < this.optList.length; index++) {
26.       // 读取操作算子
27.       const optItem = this.optList[index];
28.       let startTime = performance.now();
30.       try {
31.         // 执行算子计算
32.         const result = optItem.run({
33.           columns,
34.           dataSourceMap
35.         });
37.         // 更新算子结果
38.         columns = result.columns || [];
39.         dataSourceMap = result.dataSourceMap || {};
40.       } catch(e) {
41.         // 报错后直接直接返回
42.         return {
43.           columns,
44.           dataSourceMap,
45.           // 装填报错信息
46.           errorInfo: {
47.             key: optItem.key || '',
48.             message: e.message
49.           }
50.         }
51.       }
52.     }
54.     return {
55.       columns,
56.       dataSourceMap,
57.     }
58.   }
60.   autoRun = (
61.     metaInfo: IOptEngineMetaInfo,
62.     optList: IOptItem[],
63.     callback: (params: IAutoRunResult) => void
64.   ) => {
65.     // 装填数据
66.     this.setupMetaData(metaInfo);
67.     // 装填操作栈
68.     this.setupOptList(optList.map((item) => {
69.       // 行过滤
70.       if(item.type === OPT_TYPE.FILTER) {
71.         return new FilterOpt({
72.           key: item.key,
73.           params: item.params
74.         })
75.       }
76.       // 其余类型操作
77.       ...
78.       // 默认原值返回
79.       return new IdentityOpt({
80.         key: item.key,
81.       })
82.     }));
84.     // 执行操作计算
85.     const result = this.optRun();
87.     // 返回数据
88.     return {
89.       // 计算列
90.       columns: result.columns,
91.       // 执行结果
92.       dataSource: Object.entries(result.dataSourceMap).map(([key, value]) => ({
93.         field: key,
94.         value
95.       })),
96.       // 操作栈执行异常信息
97.       errorInfo: result.errorInfo
98.     };
99.   }
100. }

复制代码

 
应用实践

以一个小例子来演示下动态探查的使用。前端开发过程中，有一个真实的场景，我们为了排查一个竖屏显示器的 bug（1080*1920），想找到关联的用户，看其分布情况，就可以很方便的用动态探查去寻找。
 
后续计划

 
关注动态探查的操作丰富性以及之后的数据走向，比如离线数据导出，和生成 SQL 等，技术方向上主要放在以下几个方面：

• 更多的探查类型和图表支持动态探查目前支持空值，枚举值，零值，数据统计等基础的探查功能，未来会计划支持包括 map，json，time，sql 语句等类型的识别和探查。同时提供更丰富的图表支持。
  

• 操作栈的编辑器体验动态探查目前还是以类 Excel 的操作为主，未来主要提供编辑器级别的操作体验，可以提供 HSQL 支持的大部分函数，包括支持多表 join 功能。
  

• 操作流程的 SQL 生成动态探查目前的 SQL 能力还未建设完成，会在未来结合编辑器级别的操作，并支持多表，配合词法解析功能，提供更精准的生成 SQL 能力。
  

立即跳转火山引擎大数据研发治理套件官网了解详情！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4