数据采样的 transform.sample

[hustcc]

transform.sample

针对线、柱、条、散点类图表，当数据量远大于屏幕像素的时候，开启一些内置的采样策略，可以有效的优化图表的绘制效率，默认关闭，也就是按照原始数据全部渲染。

开始

这是使用 sample 的示例

import { Chart } from '@antv/g2';

const chart = new Chart({
  container: 'container',
});

chart.data([]);

chart
  .line()
  .encode('x', 'x')
  .encode('y', 'y')
  .transform([
    type: 'sample',
    thresholds: 500,
    y: 'max',
  ])

chart.render();

选项

属性	描述	类型	默认值
groupBy	数据分组的字段	string | string[]	-
thresholds	采样策略启用的数据量阈值	number	2000
[channel]	对指定的通道采用指定的采样策略	Strategy	-

strategy 内置有 6 种策略，分别为：

• lttb - 采用 Largest-Triangle-Three-Bucket 算法，可以最大程度保证采样后线条的趋势，形状和极值。
• mean - 取过滤点的平均值
• median - 取过滤点的中位数
• max - 取过滤点的最大值
• min - 取过滤点的最小值
• sum - 取过滤点的和
• (I: number[], V: number[]) => number - 使用自定义的函数进行采样

FAQ

• 怎么做自定义的抽样策略？

function strategy(I: number[], V: number[]) {
  // 这里对这一组数据进行抽样，返回一个数据
  return 1;
}

chart
  .line()
  .encode('x', 'x')
  .encode('y', 'y')
  .transfrom([
    { type: 'sample', y: strategy },
  ])

[visiky]

我顺便补充一个点，line + point 这种组合图，我看某图表库对于 point 的抽样展示处理（因为 point 只是辅助），是会根据像素距离情况来定，这种情况我们会怎么处理？

[hustcc]

只要两个 mark 的抽样逻辑使用一样的，就问题不大。抽样逻辑都是稳定的算法。

[visiky]

嗯嗯，我这边其实想提到的也是获取屏幕大小来计算 point 的抽样逻辑，如果只是根据数据的话，那问题不大

[pearmini]

有两点需要提一下：

• 是 mark.data.transform 还是 mark.transform？
• "数据量远大于屏幕像素的时候" 是否需要知道视图的宽高？如果需要的话只有 screen space 的 mark.transform，这个时候才能获得计算得到的布局（包括 padding 这些），但是目前 api 的设计估计是完成不了这个需求的。参考 pack。

[hustcc]

• mark.transform
• screen 大小，只是让开发者知道使用抽样的原理，实际的逻辑不会判断屏幕像素，而是根据数据量来的。largeThreshold

[pearmini]

嗯嗯，那我没有问题了

[pearmini]

还有一个点就是 G2 里面可能还有一些其他和 strategy 相似的 API，可能后续需要统一一下命名。

[hustcc]

最新更新：

• 增加 thresholds 配置，默认 2000
• 策略 average 改名为 mean，并增加 median

[hustcc]

sampling -> sample

[hustcc]

sample 还是建议放到 data.transform 中。

1. 当前实现不太符合语义，依然是一种聚合的思路，实际需要的是抽取一个数据

{
  type: 'sample',
  y: 'min',
  opacity: 'mean'
}

但是抽样，需要的是保留原始数据中 x y 等通道的对应关系。而当前实现比如对 y 进行 max 后，x 实际是取的那一组数据的第一个，组合出来的数据，实际上并不存在。见问题：#4505

而一旦设置两个以上通道的 reducer，大概率是无法保持数据一致的。

2. 抽样应该针对数据源头直接处理，而不是在抽取列之后，没有必要的性能损耗

3. 实现自定义抽样算法的时候，更方便，不用针对各种列去做抽样，比如：lttb

[pearmini]

sample 还是建议放在 mark.transform 里面。

1. 可以设计的有语义，聚合思路和筛选思路都是可行的。目前是聚合的思路，ECharts 里面也是聚合思路（下图中红色为筛选，黄色为聚合，蓝色未知），但是这个里面 sample transform 实现问题 #4505 希望的筛选思路。这都是底层实现问题，并不是上层 API 设计的问题。

2. 性能问题目前在于以下的情况会执行两次：

const options = {
  type: 'view',
  children: [
    {
      type: 'line',
      data,
      encode: { x: 'date', y: 'value' },
      transform: [{ type: 'sample' }],
    },
    {
      type: 'point',
      data,
      encode: { x: 'date', y: 'value' },
      transform: [{ type: 'sample' }],
    },
  ],
};

但是之后 G2 会支持在 view 处理数据，vega-lite 也有同样的设计，之后的声明会如下。

const options = {
  type: 'view',
  data,
  encode: { x: 'date', y: 'value' },
  transform: [{ type: 'sample' }],
  children: [{ type: 'line' }, { type: 'point' }],
};

注意这里不是语法糖！而是数据会在 view 层面处理，然后传递给 mark，实际的列处理还是执行了1次。

3. 不会复杂太多，ECharts 本身就是支持列数据，它的实现肯定是就是操作列。只是和我们平时的操作对象数组有区别，熟悉里之后应该还好，同时操作列本身会高效一点：因为数组更简单，寻址更容易。