关键技术及实现
大数据渲染
由于动态探查场景下前端需要支持最大5000条数据的展示和交互，所以在渲染这块存在比较大的压力，主要集中在探查卡片和数据预览两个部分。
火山引擎DataLeap探查卡片包含了特定列的部分关键信息汇总，比如0值、Null值、枚举值等，如下图红框部分：
火山引擎DataLeap探查卡片部分由于存在较多定制化内容，所以采用了虚拟列表方案进行渲染，支持收起状态和展开状态：
数据预览部分展示的是探查的全部数据集合，可以快速查看原始数据的详细内容，由于内容同质化比较高，所以火山引擎DataLeap数据预览采用的是基于团队内部维护的canvas版本Table方案进行渲染，如下图红框部分：
卡片联动
由于卡片和数据预览列的宽度差异较大，并且上下两部分滑动是独立的，造成在选择查看某个具体列的时候，上下对齐位置会比较麻烦，为了解决这个问题，火山引擎DataLeap这块增加了自动定位功能，演示效果如下：
这部分需要解决的问题有两个：卡片中间点坐标计算和自动定位逻辑。
中间点坐标计算逻辑如下：
获取到中点坐标后，自动定位需要符合如下规则：
1. 选中卡片后，表格要自动滚动定位到下方居中对齐，无法满足对齐标准的，尽量靠近选中卡片位置。
2. 选中表格列后，卡片要自动滚动定位到上方居中对齐，无法满足对齐标准的，尽量靠近选中表格位置。
3. 搜索选中列后，卡片和表格要自动满足上面两个规则，并滚动到可视区域内。
规则中有几种边界情况，参考下图：
居中对齐是对于卡片和列宽在scroll距离允许情况下的理想对齐方式，贴边对齐是针对卡片在起始和结束位置scroll不足以满足居中对齐要求时候的对齐方式，除此之外还有一种是卡片的宽度远大于列宽，并且不是起始或者结束位置的时候所采取的对齐方式，如下如卡片B因为无法滚动，卡片A的宽度又占据了底部第二列的一部分，所以此时卡片B只能高亮和底部的列进行对齐。
操作栈
火山引擎DataLeap动态探查支持了对于探查结果的基础分析能力，比如列删除、过滤、排序等，如下图红框部分：
用户对于探查结果的每一次操作都会被记作一次操作，多次操作串联起来形成操作栈，可以自由的修改或者删减操作栈里的操作，并实时查看最新结果，以过滤操作演示效果如下：
操作栈部分需要处理的问题主要有以下几点：
1.如何管理多种操作进行串行计算
这里把所有操作都抽象成了Input + Logic = Ouput的结构，Input是输入参数，此处可以是指某一列的数据、上一步操作的结果或者其他计算值，Logic是操作的具体逻辑，负责根据Input转换生成Output，Output可以作为最终结果进行渲染，也可以再次进入下一环节参与计算，拿列删除操作举个栗子，下面是大体代码实现：
可以看到ColDelOpt内部有一个run方法，该方法支持传入一个包含了列信息columns和数据集dataSourceMap的params对象，此处params即被抽象的外部输入参数Input，run方法内部的逻辑部分即被抽象的Logic部分，最后方法返回值包含了最新的columns和dataSourceMap，即为Output部分。基于这种结构，用户所有的操作都可以被初始化成不同的Opt实例，由操作引擎统一调用实例的run方法，并传入所需的参数，最终得到计算结果。
2.某个操作被修改后如何进行二次计算
操作栈的计算是由计算引擎来完成的，引擎负责根据外部事件，来自动执行现有操作的数据处理工作，引擎执行流程和大体代码如下：
应用实践
以一个小例子来演示下动态探查的使用。前端开发过程中，有一个真实的场景，火山引擎DataLeap研发人员为了排查一个竖屏显示器的bug（1080*1920），想找到关联的用户，看其分布情况，就可以很方便的用动态探查去寻找。
后续计划
关注动态探查的操作丰富性以及之后的数据走向，比如离线数据导出，和生成SQL等，火山引擎DataLeap技术方向上主要放在以下几个方面：
•更多的探查类型和图表支持
动态探查目前支持空值，枚举值，零值，数据统计等基础的探查功能，未来会计划支持包括map，json，time，sql语句等类型的识别和探查。同时提供更丰富的图表支持。
•操作栈的编辑器体验
动态探查目前还是以类Excel的操作为主，未来主要提供编辑器级别的操作体验，可以提供HSQL支持的大部分函数，包括支持多表join功能。
•操作流程的SQL生成
动态探查目前的SQL能力还未建设完成，会在未来结合编辑器级别的操作，并支持多表，配合词法解析功能，提供更精准的生成SQL能力。