想象你走进一家餐厅：菜单上写着“清蒸鲈鱼”“宫保鸡丁”，你只需要在菜品后面打个勾，后厨就会自动完成杀鱼、切菜、调味、掌勺的全部工序——你完全不关心过程，只在意端上桌的菜是不是你想要的模样。 数据可视化世界里的 Vega-Lite，就是这样一个“点菜平台”。传统方式像自己下厨：你要亲手写代码告诉计算机“先画一条线，再画一个点，把坐标轴放在旁边”——每一步都要亲力亲为。而 Vega-Lite 让你像点菜一样描述需求：“我要用柱状图展示每个月的销售额，颜色按地区区分。”剩下的一切——坐标轴的刻度怎么排、图例放在哪、颜色怎么选——都由底层渲染引擎自动完成。 这套“声明式”思想正在重塑 AI 时代的数据产品：无论你做大模型的可视化输出，还是构建自助分析平台，都能用一段精简的 JSON 描述，快速得到专业图表。本文就用“可视化餐厅”这个比喻，带你从“冰箱里的食材”走到“高峰期的厨房调度”，彻底看懂 Vega-Lite 的核心原理。

岗位关联

对 AI 从业者而言，掌握 Vega-Lite 意味着能用极其精简的声明式语法生成高质量图表，这是构建 AI 数据产品、自动化报表和智能可视化前端的基础能力，能显著提升从数据到决策的交付效率。

目录
  1. 可视化演示
  2. 数据与图元
  3. 编码通道
  4. 变换管道
  5. 分面与图层
  6. 交互机制
  7. 性能与工程
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

数据与图元

餐厅后厨第一步永远是“备菜”：把买回来的鱼去鳞、洗净、切好，码在盘子里等待下锅。在 Vega-Lite 的世界里，这份“备好的食材”就是数据表（DataFrame 或 JSON 数组）。每一行数据是一份独立的食材，比如“一月卖了 120 杯奶茶”；每一列则是一种食材属性，比如月份、销量、门店。

食材备好后，关键问题是“你想做成什么菜”。同样的鲈鱼，可以清蒸、红烧、做汤——这就是图元（mark）的选择。Vega-Lite 提供 bar（柱条）、line（折线）、point（散点）、area（面积）、arc（扇形）等“菜式”。你声明 "mark": "bar"，引擎就知道要端出一盘柱状图。

Vega-Lite 的规范（spec）本质是一份“点菜单”，由三部分组成：data 声明用哪些食材，mark 声明做什么菜，encoding 声明怎么摆盘。引擎拿到点菜单后，会把每一行数据映射成一个具体的图元：一条柱、一个点、一段折线。这个映射过程可以用公式概括：

所以，用 Vega-Lite 画图本质上就是“点菜”：数据定食材，mark 定菜式，剩下的映射计算全部由后厨自动完成。你不需要关心后端渲染器具体怎么计算像素位置，只要把食材和菜式说清楚。

Vi=mark(scale(Di))\displaystyle V_i = \mathrm{mark}\bigl(\mathrm{scale}(D_i)\bigr)
式子意思是：第 \(i\) 行数据 \(D_i\) 先经过比例尺 \(scale\) 换算成屏幕上的位置和样式，再由图元 \(mark\) 决定画成柱条还是散点。
  1. 数据对象 \(D_i\)从数据表中取出编号为 \(i\) 的一行，相当于从冰箱里拿出一份加工好的食材。
    Di={field1:v1, field2:v2, … }D_i = \{ \mathrm{field}_1 : v_1,\ \mathrm{field}_2 : v_2,\ \dots \}
  2. 比例尺 \(\mathrm{scale}\)把字段的原始数值（如销量 120）映射成屏幕上的像素坐标或颜色深浅。
    scale:Rm→Rk\mathrm{scale}: \mathbb{R}^m \rightarrow \mathbb{R}^k
  3. 图元 \(\mathrm{mark}\)决定最终用哪种图形呈现，是画一根柱子、一个圆点还是一条折线。
    mark∈{bar, line, point, area, arc}\mathrm{mark} \in \{ \mathrm{bar},\ \mathrm{line},\ \mathrm{point},\ \mathrm{area},\ \mathrm{arc} \}

编码通道

菜端上桌讲究“色香味俱全”：同样的宫保鸡丁，摆盘不同，食欲完全不同。数据可视化也一样——同一个字段放在 x 轴还是放在颜色上，表达的语义天差地别。Vega-Lite 用“编码通道”（encoding channel）来控制这种“摆盘”。

编码通道是字段与视觉属性之间的对应关系。你可以把“月份”映射到 x 通道（横轴位置），把“销量”映射到 y 通道（纵轴高度），再把“门店”映射到 color 通道（颜色）或 size 通道（大小）。相当于在菜单上注明：“请把月份放在左右方向，销量放在上下方向，不同门店用不同颜色。”

真正做“量体裁衣”的是比例尺（scale）。原始数据里“销量 120”是一个抽象数字，屏幕上的柱子应该有多高？比例尺负责把数据值域（domain）映射到像素范围（range）。线性比例尺是最常用的映射方式，它把最小值放到屏幕起点、最大值放到屏幕终点，中间的数值按比例均匀排布：

Vega-Lite 的厉害之处在于：你只需要说“销量映射到 y 通道”，引擎会自动判断该用线性比例尺还是对数比例尺，自动生成坐标轴刻度、图例位置和网格线。这就像餐厅大厨看到“红烧鱼”三个字，自动决定放多少酱油、多少糖——你根本不用写配方。

v′=vmin⁡+v−dmin⁡dmax⁡−dmin⁡×(vmax⁡−vmin⁡)\displaystyle v' = v_{\min} + \frac{v - d_{\min}}{d_{\max} - d_{\min}} \times (v_{\max} - v_{\min})
这是标准线性归一化公式：先算出原始值在数据区间中的相对位置（0 到 1 之间），再把它平移到目标像素区间。
  1. 计算偏移量先算出原始值 \(v\) 离数据最小值 \(d_{\min}\) 有多远，相当于看食材在整条货架上的位置。
    v−dmin⁡v - d_{\min}
  2. 归一化除以数据范围，得到 0 到 1 之间的比例，表示“处于全程的百分之多少”。
    v−dmin⁡dmax⁡−dmin⁡∈[0,1]\frac{v - d_{\min}}{d_{\max} - d_{\min}} \in [0,1]
  3. 放大到目标区间乘以像素范围长度，把比例换算成实际的像素跨度。
    v−dmin⁡dmax⁡−dmin⁡×(vmax⁡−vmin⁡)\frac{v - d_{\min}}{d_{\max} - d_{\min}} \times (v_{\max} - v_{\min})
  4. 平移起点加上目标区间最小值 \(v_{\min}\)，让结果落在正确的像素坐标内。
    v′=(⋯ )+vmin⁡v' = (\cdots) + v_{\min}

变换管道

做菜不是把食材直接下锅就行，中间有洗、切、腌、焯等一堆预处理工序。Vega-Lite 的变换（transform）就是数据进入锅之前的“后厨流水线”，它按数组顺序依次加工数据，加工完的结果再交给 mark 绘制。

流水线上最常见的四道工序：filter（过滤） 像挑菜，把不符合条件的行丢掉，比如“只保留销量大于 100 的月份”；aggregate（聚合） 像切丁汇总，把多行按某列分组并求和、平均、计数，比如按门店汇总总销量；bin（分箱） 像把连续散落的食材按大小装筐，把年龄、价格这类连续数值切成一段段区间；window（窗口） 像滑动炒勺，计算滚动平均、累积和等。

其中分箱是高频操作，它把连续数值离散化成整数序号，公式很简洁：

有了变换管道，你可以在声明式规范里直接写 "transform": [{"filter": "datum.sales > 100"}, {"bin": {"field": "price", "step": 10}}]——食材在进锅前就被处理得干干净净。这也意味着数据清洗、聚合和可视化共用一套声明语法，让“从数据到图表”的全链路变得极其紧凑。

bin(v)=⌊v−min⁡step⌋\displaystyle \mathrm{bin}(v) = \left\lfloor \frac{v - \min}{\mathrm{step}} \right\rfloor
含义是：看原始值 \(v\) 落在从左边界数起的第几个等宽箱子里，箱子宽度为 \(step\)。
  1. 计算与起点的距离用原始值减去数据下界 \(min\)，得到它相对起点的位置。
    v−min⁡v - \min
  2. 除以步长把距离换算成“多少个箱子宽度”。
    v−min⁡step\frac{v - \min}{\mathrm{step}}
  3. 向下取整得到所在箱子的序号，例如 3.7 落到第 3 号箱。
    ⌊v−min⁡step⌋\left\lfloor \frac{v - \min}{\mathrm{step}} \right\rfloor

分面与图层

一桌宴席不会只有一道菜。去餐厅请客，你会说“先上八道热菜，凉菜拼盘放中间，汤最后上”——这就是“摆盘结构”。Vega-Lite 提供了四种组合手段，让你把多张图组织成一场完整的“宴席”。

分面（facet） 是把一张大表按某个字段拆成多个子图：比如按“门店”分成三张小柱状图，排成一排方便对比。图层（layer） 是把多个图元叠在同一张图上：先画柱条，再叠一条折线，二者共享坐标轴。并列（concat） 是把几张彼此独立的图拼在一起；重复（repeat） 则是用同一套配方，对多个字段各做一张图——类似“同样的宫保做法，分别做鸡丁和虾仁”。

分面背后的数学本质，是把数据集拆成若干个互不重叠的子集，每个子集画一张子图：

分面和图层让“一桌菜”有了结构：分面是按地区分桌，图层是同一桌里多层叠放。实际项目中二者经常组合使用——如“每个地区一张图，图里既画实际销量柱条，又画目标销量折线”。你只需要在规范里嵌套几句声明，后厨就会自动完成所有排版。

⋃k=1mDk=D,Di∩Dj=∅  (i≠j)\displaystyle \bigcup_{k=1}^{m} D_k = D, \quad D_i \cap D_j = \varnothing \; (i \neq j)
这个式子告诉你：所有子图的数据合起来等于原数据，且任意两张子图的数据没有重叠——整桌菜加起来恰好是全部食材，没有浪费也没有重复。
  1. 拆分子集按分面字段（如地区）把原数据 \(D\) 拆成 \(m\) 个子集 \(D_1, D_2, \dots, D_m\)。
    D1, D2, …, DmD_1,\ D_2,\ \dots,\ D_m
  2. 并集还原所有子集取并集恰好等于原数据，保证不丢数据。
    ⋃k=1mDk=D\bigcup_{k=1}^{m} D_k = D
  3. 两两不相交任意两个子集的交集为空，保证每条数据只出现在一张子图中。
    Di∩Dj=∅D_i \cap D_j = \varnothing

交互机制

前面的流程都是“厨房做什么，食客吃什么”。但真正的餐厅里，食客随时会改口：“这道菜多放辣”“那把肥肉挑掉”。Vega-Lite 的交互机制，就是让图表变成一张“可改口的菜单”。

核心概念是选择（selection）：用户点击、框选或悬停时，引擎记录哪些数据点被选中，形成一个选中集合。然后通过条件编码（condition），让视觉属性随选中状态动态切换：选中的柱子高亮成红色，未选中的自动淡化。提示信息（tooltip）则像服务员报菜名，鼠标悬停时弹出该数据点的详细字段。

条件编码的逻辑可以用分支公式表达：

交互不是“加个动画”那样可有可无的装饰，而是数据分析的必经之路：分析师需要点击某个地区看明细、框选一片异常点看分布。Vega-Lite 把交互也变成声明式语法——"selection": {"brush": {"type": "interval"}}——用户行为被抽象成一句描述，复杂的事件监听和状态管理全部由引擎代劳。

Vij={Vactive,j∈SVbase,j∉S\displaystyle V_{ij} = \begin{cases} V_{\mathrm{active}}, & j \in S \\ V_{\mathrm{base}}, & j \notin S \end{cases}
意思是：第 \(i\) 行第 \(j\) 条数据的视觉属性，取决于它是否属于用户选中的集合 \(S\)——选中就用高亮样式，没选中就用普通样式。
  1. 选中集合 \(S\)用户通过点击或框选产生的一组数据索引，相当于食客点名要的菜。
    S={j1, j2, … }S = \{ j_1,\ j_2,\ \dots \}
  2. 命中分支当 \(j\) 属于 \(S\) 时，视觉属性取高亮值。
    j∈S⇒Vactivej \in S \Rightarrow V_{\mathrm{active}}
  3. 未命中分支当 \(j\) 不在 \(S\) 中时，保持基础样式。
    j∉S⇒Vbasej \notin S \Rightarrow V_{\mathrm{base}}

性能与工程

饭点高峰期，后厨最容易手忙脚乱：订单多、食材杂、灶台不够用。Vega-Lite 渲染大数据时也一样：数据量一大，图元数量暴增，浏览器就会卡顿。性能优化的核心思路，和餐厅高峰期的调度如出一辙——减少同时下锅的菜。

第一板斧是预聚合：既然要画“各城市总销售额”，那就在 transform 里先按城市分组求和，把十万行原始数据压缩成几十行，再交给 mark 绘制。第二板斧是分箱降采样：把连续值切成分箱，每个箱画一根柱，点的数量从几万降到几十。第三板斧是合理分层：避免在单个视图中叠加过多图层。

渲染开销最终由“实际绘制的图元数”决定，可以估算为：

工程上，Vega-Lite 规范最终会交给 Vega 运行时编译执行，再由 Canvas 或 SVG 渲染。理解这层“点菜单 → 后厨 → 上菜”的架构，你就能在实际项目中有的放矢：数据量大了就预聚合，分面太多就合并，图层太厚就精简。后厨调度得当，再高峰的饭点也能从容出餐。

R=B×M×L\displaystyle R = B \times M \times L
渲染的图元总数 \(R\) 等于分箱数 \(B\)、分面数 \(M\)、图层数 \(L\) 三者的乘积。每一项变小，总开销都会成倍下降。
  1. 分箱数 \(B\)连续数据被切成多少个桶，桶越少渲染越轻。
    B=number of binsB = \text{number of bins}
  2. 分面数 \(M\)一张图被拆成多少个子图，子图越多开销越大。
    M=number of facetsM = \text{number of facets}
  3. 图层数 \(L\)同一张图里叠加了几层 mark，每层都是一次完整绘制。
    L=number of layersL = \text{number of layers}
  4. 总图元数三者相乘得到最终渲染对象个数，这是决定性能的关键指标。
    R=B×M×LR = B \times M \times L

AI 应用场景

大模型自动生成图表

阶段：数据可视化生成 / 智能前端渲染

解决的问题：传统方式要求用户掌握可视化库 API，大模型输出的图表常常格式混乱、难以直接渲染。借助 Vega-Lite 的声明式规范，大模型只需输出一段标准化 JSON，前端即可自动渲染出专业图表。

具体案例：用户对 AI 助手说“把各部门季度业绩画成按地区分面的柱状图”，大模型生成一份 Vega-Lite spec（包含 data、mark、encoding、facet 字段），前端拿到 spec 后交给 Vega 引擎渲染，实现“一句话出图”。

自助式 BI 分析平台

阶段：交互式数据分析

解决的问题：业务人员希望自己拖拽字段生成图表，但传统 BI 每加一种图表类型都要写大量前端代码。Vega-Lite 把字段到通道的映射抽象成可配置的 JSON，平台只需收集用户的拖拽操作，动态生成 spec 即可。

具体案例：某电商数据平台允许运营人员把“销售额”拖到 y 通道、“商品类目”拖到 color 通道，并选择“按周分箱”。平台将拖拽结果拼接成 Vega-Lite 规范，实时渲染出聚合分析图，同时支持点击筛选（selection），让运营自助完成钻取分析。

自动化报表流水线

阶段：数据预处理与报告生成

解决的问题：日报、周报需要重复生成几十张固定图表，手写代码维护成本高。Vega-Lite 的 transform 管道能在声明层完成过滤、聚合、分箱，报表系统只需更新数据源，图表自动刷新。

具体案例：某金融公司每日自动生成“各支行存贷款情况”报表，spec 中预置 transform 做按日聚合和同比过滤，数据从数仓更新后，20 张图表全部自动重绘，无需人工干预。

Python 演示

python66 行
import json  # 模拟一份销售数据: 每个月的奶茶销量DATA = [    {"month": "Jan", "sales": 120},    {"month": "Feb", "sales": 95},    {"month": "Mar", "sales": 150},    {"month": "Apr", "sales": 130},    {"month": "May", "sales": 175},    {"month": "Jun", "sales": 200},]  # 一份声明式"点菜单": 数据是食材, mark 是菜式, encoding 是摆盘SPEC = {    "data": DATA,    "mark": "bar",    "encoding": {        "x": {"field": "month", "type": "nominal"},        "y": {"field": "sales", "type": "quantitative"},        "color": {"field": "month", "type": "nominal"},    },}  def normalize(values, height):    """把数据值等比缩放到 0~height 区间, 模拟比例尺 scale."""    lo = min(values)    hi = max(values)    span = hi - lo if hi > lo else 1    return [round((v - lo) / span * height) for v in values]  def render_bar_chart(spec, width=18, height=16):    """迷你渲染引擎: 把声明式 spec 解析成文本柱状图."""    rows = spec["data"]    y_field = spec["encoding"]["y"]["field"]    heights = normalize([row[y_field] for row in rows], height)    lines = []    for level in range(height, 0, -1):        line = ""        for h in heights:            cell = "|" * width if h >= level else " " * width            line += "[" + cell + "]"        lines.append(line)    lines.append("[" + "-" * width + "]" * len(rows))    return "\n".join(lines)  def apply_filter(rows, field, threshold):    """模拟 transform 中的 filter: 只保留销量超过阈值的月份."""    return [row for row in rows if row[field] > threshold]  def main():    filtered_data = apply_filter(DATA, "sales", 100)    SPEC["data"] = filtered_data    chart = render_bar_chart(SPEC)    print(chart)    print("mark:", SPEC["mark"])    print("encoding:", json.dumps(SPEC["encoding"], ensure_ascii=False))  if __name__ == "__main__":    main()
目的：用纯 Python 实现一个“迷你 Vega-Lite”——通过声明式 spec 描述图表，再由渲染函数自动完成比例尺计算和柱状图绘制，让你直观理解声明式可视化的核心思想。
  1. "encoding": {"x": {"field": "month", ...}}声明要画什么：月份放横轴、销量放纵轴，相当于在菜单上写清楚摆盘要求。
  2. def normalize(values, height)模拟比例尺（scale）的核心逻辑：把原始数值映射到 0~height 的像素区间。
  3. heights = normalize([row[y_field] for row in rows], height)批量取出销量字段并全部换算成柱子高度，这就是“数据 → 视觉属性”的映射。
  4. for level in range(height, 0, -1)从顶到底逐行扫描，决定每个字符位置是否画柱子，相当于渲染引擎逐像素构图。
  5. def apply_filter(rows, field, threshold)模拟 transform 管道中的 filter：先过滤数据再绘图，说明变换发生在渲染之前。
  6. SPEC["data"] = filtered_data修改声明式规范的数据部分，图表立即按新数据重新渲染，体现“改菜单即可换菜”的思想。

常见误区

误区我直接用 ECharts 配置项不就行了？Vega-Lite 无非是换了个名字的配置库，多学一套没啥必要。

正解两者理念完全不同。ECharts 本质是命令式配置，你要手动指定坐标轴范围、刻度数量、图例位置；Vega-Lite 是声明式语法，你在规范里只描述“月份在 x、销量在 y”，比例尺、坐标轴、图例全部由引擎自动推断生成。就像一个是“我说一步你做一步”，另一个是“你说清目标，我全包”。

为何常见：因为两者最终都产出图表，表面看起来都是“写一个对象、出一个图”，初学者很少关注底层是命令式还是声明式。

误区filter 只是让这些点在图上不显示，原始数据没变，所以 transform 可有可无。

正解Vega-Lite 的 transform 在渲染前对数据执行真实加工，filter 会真正丢弃行，aggregate 会生成新的聚合数据表，bin 会生成新的分箱字段。渲染器拿到的是变换后的新数据集，而不是原数据。这就像后厨真的把菜切好了才下锅，不是等菜上桌假装切过。

为何常见：因为大多数人在交互式工具里“貌似”看到 filter 只是让点消失，没有意识到数据管道已经发生了物理替换。

误区一旦要自定义交互、复杂图层，Vega-Lite 就无能为力了，必须回到 D3 手写。

正解Vega-Lite 提供了 layer（图层叠加）、facet（分面矩阵）、selection（选择交互）、condition（条件编码）等组合机制，绝大多数复杂图表都能用声明式规范表达。它还会自动处理比例尺、坐标轴、响应式布局这些 D3 里最繁琐的细节。真正需要 D3 的场景，通常是你必须操作 DOM 做完全定制的视觉元素——这属于“不想点菜，非要自己进厨房”。

为何常见：人们常把“配置复杂”等同于“能力弱”，却忽略了 Vega-Lite 组合子表达力带来的简洁性。

面试题

Q1. Vega-Lite 最核心的设计理念是什么？

单选题 · easy

  • A.命令式逐像素绘制每个图形
  • B.声明式描述最终想要什么图← 正确答案
  • C.强制使用 Python 语言编程
  • D.限定只能绘制简单柱状图

答案：B。Vega-Lite 是声明式可视化框架，用户只需描述“要什么图”（数据、图元、编码通道），渲染引擎自动完成比例尺、坐标轴、图例等细节。A 是命令式的特征，C 和 D 都不符合事实——它使用 JSON 规范且支持多种图表。

Q2. 想展示一年销售额随时间的连续变化趋势，优先选哪种图元 mark？

单选题 · easy

  • A.bar 柱条
  • B.line 折线← 正确答案
  • C.arc 扇形
  • D.tick 短线

答案：B。折线图（line）最适合表达连续时间序列的趋势变化。bar 更适合对比离散类别，arc 适合占比，tick 适合分布刻度。就像观察体温变化要画曲线而不是画一排柱子。

Q3. 把“城市”字段映射到颜色通道后，最可能的结果是？

单选题 · easy

  • A.城市名会随机变成字符串
  • B.不同城市自动获得不同颜色← 正确答案
  • C.城市按拼音自动排序显示
  • D.颜色通道被引擎自动忽略

答案：B。颜色通道把类别字段映射为视觉上的颜色区分，引擎会自动为每个城市分配一个颜色，并生成图例。A 是胡编，C 是排序不是颜色，D 更不可能——通道既然声明了就会被使用。

Q4. 在 Vega-Lite 中，比例尺（scale）的主要职责是什么？

单选题 · mid

  • A.把数据值映射到屏幕视觉属性← 正确答案
  • B.对数据做去重清洗和修复
  • C.把图表导出成 PNG 图片
  • D.为所有图元添加过渡动画

答案：A。比例尺解决“数据值多大对应多高柱子”的问题，把数值域映射到像素范围。B、C、D 分别是数据清洗、导出和动画功能，都不属于比例尺的职责。可以类比为“把食材重量换算成菜盘大小”。

Q5. transform 中的 filter 变换起到什么作用？

单选题 · mid

  • A.过滤掉不符合条件的行← 正确答案
  • B.把数据列转换为数据行
  • C.为图表添加视觉滤镜效果
  • D.自动提高图表的渲染速度

答案：A。filter 是数据行级过滤，只保留满足条件的行。它发生在渲染前，不是给图加 CSS 滤镜。B 是行列转置，C 是视觉特效，D 是性能优化的结果而非 filter 的直接功能。

Q6. bin（分箱）变换在数据可视化中常用于？

单选题 · mid

  • A.将连续数值离散化为区间← 正确答案
  • B.把类别数据转为连续数值
  • C.删除数据表中的重复行
  • D.把柱状图改成折线图

答案：A。bin 把年龄、价格等连续数值切成等宽区间，每个区间作为一个桶，常用于直方图。B 方向反了，C 是去重，D 是图元类型变化，都与 bin 无关。

Q7. 关于 facet（分面）与 layer（图层）的说法，正确的有哪些？

多选题 · mid

  • A.facet 按字段拆分为多个子图← 正确答案
  • B.layer 将多个图层叠加在一起← 正确答案
  • C.两者都必须在同一张图内完成
  • D.两者可以相互组合嵌套使用← 正确答案

答案：ABD。facet 把数据按字段拆分到多个子图，layer 把柱条、折线等图元叠在同一坐标系里，二者可以组合——例如每个分面子图内再叠加多个图层。C 错误，facet 本就是跨子图的，不是“同一张图内完成”。

Q8. 关于 selection 驱动的条件编码，下列说法正确的有？

多选题 · hard

  • A.选中区域可以高亮强调显示← 正确答案
  • B.未选中区域可以被淡化处理← 正确答案
  • C.选择状态只影响图例样式
  • D.条件编码依据选中集合切换← 正确答案

答案：ABD。selection 产生选中集合，condition 根据元素是否在集合中切换视觉属性：选中的高亮、未选中的淡化。A、B、D 都描述了这种机制。C 错，选择状态影响的是数据点的视觉编码，不止是图例。

Q9. 当原始数据量非常大时，降低渲染压力的最有效手段是？

单选题 · hard

  • A.在 transform 中做预聚合← 正确答案
  • B.取消所有比例尺计算
  • C.删除所有交互事件绑定
  • D.把图表改用位图格式

答案：A。预聚合把十万行原始数据按分组压缩成几十行，直接减少需要绘制的图元数量，是治本之策。B、C、D 只解决了边缘问题，比例尺、交互、格式都绕不开海量图元的渲染开销。

Q10. 下列关于 Vega-Lite 规范的说法，正确的有哪些？

多选题 · extreme

  • A.编码声明了字段到通道的映射← 正确答案
  • B.图层顺序决定绘制的先后顺序← 正确答案
  • C.每个字段必须映射到颜色通道
  • D.变换按数组顺序依次执行← 正确答案

答案：ABD。encoding 就是字段到 x/y/color/size 等视觉通道的映射声明；layer 数组的顺序决定图元绘制的先后，先画的在底层；transform 是按数组顺序执行的管道。C 错误，字段是否映射到颜色完全由需求决定，没有“必须”。