Gaia DR3 — 18 亿源的全天星表与它的 ID 陷阱

Gaia DR3 是欧洲空间局盖亚任务的第三次主要数据发布，2022 年 6 月 13 日上线。它把 34 个月内对全天球的反复扫描压缩成一张 18.1 亿行的源表，外加 90 张围绕它展开的衍生表：把视差换算成距离的、把光谱反推成温度和重力的、把光变曲线归到二十几种变星类型的。对天文学来说它是本世纪的「底图」，对做机器学习的人来说它是一份罕见的、标注齐全、又逐行带误差的十亿级表格。

它最容易被低估的地方在于边界。这 18.1 亿行里有星、有类星体、有星系、有小行星，混在同一张表里；主键 source_id 跨版本并不稳定；逐历元测光不在表里而在另一条通道上；许可是带 NC 的，不是常见的 CC BY。

下面的速览表把最该先知道的几件事排在一起，后面的章节再逐项展开。

项目	数值	来源
源总数	1,811,709,771	官方 counts 表
全天体测量解	1,467,744,818（5 参数 5.85 亿＋6 参数 8.82 亿）	同上
平均 BP/RP 光谱	219,197,643	同上
平均 RVS 光谱	999,645	同上
视向速度	33,812,183	同上
变源	10,509,536，24 个监督式类别	同上
Archive 表数	gaiadr3 schema 共 91 张	TAP_SCHEMA 查询
主键	source_id（64 位整数）	官方源标识说明页
观测期	2014-07-25 至 2017-05-28，34 个月	官方 DR3 内容页
参考历元	J2016.0	同上
全量体积	约 10 TB（约 9 TiB）	同上
许可	CC BY-NC 3.0 IGO	官方 License 页与 ESA 档案条款
发布日	2022-06-13	官方 DR3 内容页

§1 速览：它是什么，也不是什么

§1.1 一句话定义

Gaia DR3 是一份逐源一行、把某个天体在 34 个月扫描期内的全部观测平均成一组数值的全天星表，附带把平均光谱压成系数、把光变曲线归成类别、把可疑的成团与成双单独列表的派生表。

它不是时间序列库，不是图像库，也不是「所有天体都齐全」的清单。它的设计目标是测量，不是采样：能测准的记下来，测不准的留空。

§1.2 为什么它不算「普通表格数据」

把 Gaia DR3 当普通表格数据用，会在三个地方栽跟头，而这三点恰好是它区别于一般 AI 数据集的原因。

第一，每一列都带误差，且误差随亮度非线性变化。官方给出的中位位置不确定度，在 G<15 时是 0.01–0.02 毫角秒，到 G=20 是 0.4 毫角秒，G=21 时是 1.0 毫角秒；视差不确定度从 0.02–0.03 毫角秒涨到 1.3 毫角秒。这意味着 18 亿行在「信息量」上极不均匀：暗端的绝大多数行只能锁死位置，暗端之外的派生量几乎全空。

第二，缺失不是随机的。视向速度只覆盖 1.9% 的源，因为 RVS 仪器需要把光色散成光谱，只有足够亮、足够干净的源才能得到可靠结果。所以任何「剔除含空值的行」的操作，都会把样本削成高信噪比的那一小撮，随后所有统计都只对那一小撮成立。

第三，同一行内混着不同档次的产品。一行 gaia_source 里的 ra/dec 来自天体测量链，phot_g_mean_mag 来自光度链，radial_velocity 来自光谱链，各自的有效条件、系统误差、否决规则都不同。列与列之间的相关性并不像一张普通的实验记录那样干净。

§1.3 三十秒决策卡：你的处境，它能帮你什么

你的处境	它能帮你什么
要做一个十亿行级的表格回归基准，测特征工程与采样策略	18 亿行、152 列、每列带误差与质量标记，天然的分层抽样练习题
研究银河系结构，需要恒星的三维位置与速度场	视差＋自行＋视向速度三者齐全的源可直接反解空间运动
要训练光变曲线分类器	1,050 万条变源光变曲线，24 个监督式类别，类别定义表也在库里
做光谱到参数的端到端映射	2.19 亿条平均 BP/RP 光谱配 4.7 亿组天体物理参数，是少见的跨亿级「输入—标签」配对
需要一批天体做交叉验证的锚点	12 个外部星表的交叉匹配表、160 万条参考架源、81 万非单星解
要研究单个天体在几年里的亮度变化	表里没有，得走 DataLink 通道取逐历元测光，见 §5

§1.4 不适合谁

如果需求是高时间分辨的时序建模，DR3 的主体不提供。所有主表存的都是「平均解」，一行对应一个源，不携带历元。逐历元数据虽然存在，但被放在 TAP 之外，且只有变源（1,050 万）才保证有。

如果需求是成像，它给不了你一张图。Gaia 不发布像素，只发布测量值；想看图要去找 SDSS、Pan-STARRS、Legacy Survey 这类成像巡天。

如果需求是暗弱天体或致密星场，DR3 的能力有限。G 波段的上限约 21 等，亮端约 3 等；银河系盘面方向的源密度极高，天体测量与光度都会退化，官方专门为拥挤星场另设了一条处理管线（crowded_field_source 系列要到 DR4 才成为正式表）。

如果需求是商业产品直接使用，先看许可。CC BY-NC 3.0 IGO 明令禁止未经授权的商业使用，ESA 的档案条款要求事先书面申请。

§2 数据构成：一条 18 亿行记录的构造

§2.1 全量规模与口径

官方 counts 表把口径分得很细，粗看容易混淆。核心的几个数字这样理解：源总数是源清单的行数；全天体测量解是「位置、视差、自行三者都解出来了」的子集；2 参数解是「只解出了位置」的另一部分；两者不重叠，加起来略小于源总数。有平均 G 星等的源比源总数少约 540 万个，这部分源因为输入颜色太差、有效穿越次数太少，光度链没能在平均这一步给出结果。

产品	数量	相对源总数
源总数	1,811,709,771	100%
全天体测量解	1,467,744,818	约 81%
其中 5 参数解	585,416,709	约 32%
其中 6 参数解	882,328,109	约 49%
2 参数解	343,964,953	约 19%
有平均 G 星等	1,806,254,432	约 99.7%
有平均 G_BP 星等	1,542,033,472	约 85%
有平均 G_RP 星等	1,554,997,939	约 86%
视向速度	33,812,183	约 1.9%
天体物理参数（BP/RP 谱推断）	470,759,263	约 26%
对象分类结果	1,590,760,469	约 88%
变源	10,509,536	约 0.58%

这张表的读法是自下而上越来越稀疏。列越靠下的产品，覆盖的源越少、对单个源的信息量越大。任何跨列联合分析，样本量都由最短的那一列决定。这一点在 §4 里会用一条真实查询演示它有多致命。

5 参数与 6 参数的分野值得单独说明。5 参数是标准的恒星模型：赤经、赤纬、视差、赤经自行、赤纬自行。6 参数多拟合了一个量，官方的叫法是「伪颜色」（pseudo-colour），只对缺少高质量颜色信息的源才启用。所以 6 参数解并不是「更高级的解」，而是「颜色缺失时的补救解」，其不确定度官方明说平均比 5 参数略差。

2 参数解的数量与源总数的关系也常被读错。2020 年 EDR3 发布时这个数字是 3.61 亿，DR3 里是 3.44 亿，看起来「减少了」。原因是 EDR3 到 DR3 之间源清单本身经过整顿，一部分源的解被升级成了全天体测量解，另一部分被剔除。源清单在发布之间是流动的。

§2.2 六类产品，六种物理含义

91 张表按内容可以归成六类。这个分类不是官方的，是为了让第一次接触的人知道「该去哪张表找什么」。

类别	代表表	一行的含义	规模
主星表	gaia_source（152 字段）	一个源的平均解	18.1 亿行
天体物理参数	astrophysical_parameters（226 字段）	一个源由光谱推断的物理量	4.7 亿行
光谱摘要	xp_summary（20 字段）	一条平均 BP/RP 谱的拟合质量	2.19 亿行
变源	vari_summary（68 字段）＋ 12 张分类研究表	一条光变曲线的统计量或轨道参数	1,050 万行起
非单星	nss_two_body_orbit（77 字段）等 4 张	一个双星系统的轨道解	81.4 万行
河外与太阳系	qso_candidates、galaxy_candidates、sso_orbits	一个候选类星体、星系或小行星	665 万 / 484 万 / 15.5 万

字段数最多的不是主表，而是 astrophysical_parameters，226 个字段。它把二十多种算法（官方叫 Apsis 系统）的结果并排放在一起，每个算法一组参数加一组标记位。这种「宽表 + 多套互相重叠的解」的设计，是 DR3 在数据结构上最需要适应的一点。

§2.3 一条记录逐项解剖

拿 TAP 里随手查到的一行真实记录来拆。这是一颗 G=9.2 等的恒星，天体测量解干净：

source_id,ra,dec,parallax,pmra,pmdec,phot_g_mean_mag,bp_rp,radial_velocity,ruwe
139028439265224320,46.5130,36.8246,2.1254,-4.5828,-2.7517,9.1978,1.3959,9.4254,0.8929

列	值	单位	该怎么读
source_id	139028439265224320	—	19 位十进制，64 位整数。它本身体内含位置信息，但不能当作坐标用
ra / dec	46.5130 / 36.8246	度	ICRS，参考历元 J2016.0
parallax	2.1254	毫角秒	倒数是秒差距，约 0.47 千秒差距
pmra	-4.5828	毫角秒/年	赤经方向的自行，注意这是角度速度不是线速度，随赤纬增大而增大
pmdec	-2.7517	毫角秒/年	赤纬方向的自行
phot_g_mean_mag	9.1978	星等	越低越亮，是对数标度
bp_rp	1.3959	星等	颜色指数，近似反映表面温度
radial_velocity	9.4254	km/s	正值表示远离
ruwe	0.8929	无量纲	接近 1 说明天体测量解干净

这张表里最易错的是 pmra。赤经方向的自行在赤道坐标系里是角度变化率，把两个天体的 pmra 直接比较，天赤道附近与天极附近会差出好几个数量级。要比较真实的切向速度，得换算成 l、b 方向的自行分量，再乘以距离；而要算距离，又得先相信 parallax。这条依赖链是 DR3 一切「从观测到物理」推导的缩影：每一层都建立在前一层的假设上，误差逐层放大。

ruwe 那一行值得多看一眼。它不是一个误差条，而是「拟合优度相对于同类源应有的水平」的比值。官方推荐用它来筛掉天体测量解不可靠的源，社区常用的门槛是 1.4。接近 1 表示拟合正常，明显大于 1 通常意味着源被误判为单个星、实际是未分辨的双星。判它属于哪个分档，取决于你要做什么：做星族统计时该剔掉，做双星搜索时反而是信号。

§2.4 与同类资源的定位差异

资源	核心内容	与 DR3 的分工
Gaia DR3	全天天体测量 + 低分辨光谱 + 变源	位置与运动的基准；覆盖 18 亿源，深度到 G≈21
SDSS	深度成像 + 中分辨光谱	光谱分辨率高一个量级，但只覆盖北天约三分之一，源数少四个数量级
2MASS / allWISE	近红外与中红外测光	不测视差；DR3 的交叉匹配表把它们接成了外键
Pan-STARRS1	全景成像，多波段	成像深度与视差无关，用来补 DR3 看不到的形态信息
Hipparcos / Tycho	早期高精度天体测量，亮星	DR3 的交叉匹配表把这两代结果与自己的源逐一对上，是亮星区的一致性检验
NASA Exoplanet Archive	行星级参数与大气光谱	行星本身不在 DR3 的射程内，两者在「宿主恒星参数」这一层相接

判断规则可以压成一句：要全天、要运动学、要十亿级样本 → DR3；要单源的高分辨光谱或深成像 → SDSS 与 PS1；要用谁的质量参数去养一颗行星模型 → Exoplanet Archive，DR3 只提供它背后的恒星。

§3 位置层：source_id、历元与版本

这一章解决三个前置问题：一个源怎么被唯一指认、它的数值属于哪个时刻、以及你手上的这份数据到底属于哪个版本。这三件事没定下来，后面的一切查询都在打折扣。

§3.1 source_id 是 19 位整数，不是一个稳定的天体编号

官方源标识说明页把规则写死了：Gaia DR3 的源名统一构造为 Gaia DR3 yyy....yy，也就是前缀加 19 位十进制数字，存在表里就是 source_id 一个 64 位整数列。

官方同时写了两句话，它们比格式更重要。第一句：source_id 的数值里含有该源在天空中的大致位置信息。第二句：从 DR1 到 DR2 再到 DR3，一个具体源的标识号可能改变，也可能消失，因此 DR3 的源清单必须当作与 DR2、DR1 相互独立的清单来处理。

这两句合起来产生一个反直觉的结论：「天体的主键」在 Gaia 里并不存在。存在的是「某个发布里某一行」的主键。要把同一颗星跨发布对上，必须用交叉匹配表（如 dr2_neighbourhood），而不是拿 source_id 直接 join。

社区里流传的「按 source_id 高低切分训练集与测试集」也一样会出问题。既然 ID 数值隐含位置信息，按 ID 排序再分段，等于按天区切片，训练集与测试集的天区分布会系统性不同。这在做星表数据的机器学习时是一个隐蔽的泄漏源，和普通表格按行切分完全不是一回事。

§3.2 每一行都锚在 J2016.0 这个时刻

DR3 的参考历元是 J2016.0。这一点经常被忽略，因为表里没有一列写着「时刻」。ra、dec、parallax 这些值都是外推到 J2016.0 的结果，不是「2017 年 5 月数据截止那一刻」的值。

参考历元每个发布都不同：DR1 是 J2015.0，DR2 是 J2015.5，DR3 是 J2016.0。跨发布比较位置时，必须先把各自外推到同一个历元，否则自行带来的位移会直接混进「位置差」里。一个自行 100 毫角秒/年的源，在半个世纪的跨度上会移动 5 角秒，比大多数望远镜的分辨率还大。

时间坐标本身也有讲究：官方说明 DR3 结果使用的时间坐标是质心坐标时（TCB）。vari_epoch_radial_velocity 里的 rv_obs_time 就是按这个系统记录的。

§3.3 DR3 与 EDR3 是层叠关系，不是并列关系

2020 年 12 月 3 日发布 EDR3，2022 年 6 月 13 日发布 DR3。两者共享同一段观测、同一套天体测量与光度定标。官方原话是 DR3「不包含新的天体测量，也不包含新的光度定标」，也就是说 EDR3 的那一部分原样保留，DR3 在其上叠了新的产品。

这解释了一个常被问到的现象：为什么 DR3 的视差和 EDR3 的视差一模一样。因为它们是同一个解。要引用天体测量结果，官方给出的规范是引用 DR3 文档里写明的那篇总览论文；两个发布在这一层的数值没有差别，差别只在 DR3 多了什么。

内容	EDR3 有	DR3 新增
位置、视差、自行	有	无
G / G_BP / G_RP 星等	有	无（仅修正了一处已知问题）
BP/RP 平均光谱	无	2.19 亿条
RVS 平均光谱	无	99.96 万条
视向速度	无	3,381 万
天体物理参数	无	4.7 亿组
变源分类	无	1,050 万，24 类
类星体与星系候选	无	665 万与 484 万
太阳系天体	无	15.8 万

读这张表的方式是：如果你的工作只用到位置、视差、自行和三波段测光，用 EDR3 就够了，源清单还更小一些。DR3 的价值在新增的那一半。

§3.4 版本状态：一次改名留下的表

DR3 发布至今唯一一次真正改变表内容的事件，出在 vari_planetary_transit。这张表装的是 41 颗新行星凌星候选与 173 颗已知系外行星的周期、深度等参数；官方在 2022 年 6 月 23 日——发布后第十天——就通知不要使用。

2023 年 2 月 7 日 11:00 CET，官方做了处理：把出错的旧表改名为 vari_planetary_transit_13june2022，然后用修正后的数据（solution_id 从 375316653866487564 换成 375523436409132247）重新建了一张同名的新表。改动同时作用于 Archive 与批量下载仓库。

这个处理方式留下一个必须记住的后果：两张表会同时存在。任何写死了 vari_planetary_transit 表名的脚本，拿到的会是新数据；任何按旧 solution_id 过滤的脚本，拿到的会是旧数据。如果不看 solution_id，你永远不知道自己手上的是哪一份。这张表在 TAP 的表清单里至今并存的两个名字，就是这段历史的化石。

§3.5 勘误是常态，且会改变你该用哪一列

官方单设了一个「已知问题」页，明确说它记录的是「无法并入正式发布、或发布之后才发现的」问题。也就是说，DR3 是一份带着已知伤疤的冻结数据，官方选择用勘误页而不是新版本号来处理。

目前列在上面的十几条里，对使用者影响最深的有三条：

• ipd_gof_harmonic_amplitude 与 ipd_gof_harmonic_phase 两个字段，全表算错了。官方理由是这两个量本应由图像参数拟合的拟合优度导出，实际却错误地用了 G 波段通量来计算。官方原话是「其使用不予鼓励」，并说明正确计算的字段要到 DR4 才发布。
• nss_two_body_orbit 里有 4 个源的天体测量轨道解是假阳性，其中两个在 2023 年 5 月就已上报，2024 年 5 月更新时又加了两个。这四个源对应的 binary_masses 记录已被宣布失效，但它们在 gaia_source 里的天体测量与其它参数不受影响、仍然有效。
• synthetic_photometry_gspc 表里 SDSS 与 PS1 的通量与通量误差单位，标成了 W m⁻² nm⁻¹，正确应是 W m⁻² Hz⁻¹。官方说「只有单位写错，表和数据其它方面是对的」。

第三条尤其值得警惕。它说明错误不一定来自数值，也可能来自单位标注，而单位错的两组数据在数值上一模一样、在物理上差了一个光速因子。做合成测光交叉比对时，如果不自己核对单位，会算出一套自洽但完全错误的结论。

§4 质量层：误差、缺失与三张表讲同一件事

这一章不讲「数据好不好」，只讲「哪些数字能直接用、哪些必须先过一道筛」。Gaia 与传统数据集最大的差别是：它把质量信息也做成了列，而且做了很多列。用不用得上这些列，决定了一个分析能走多远。

§4.1 误差随亮度变，且不是线性变

官方在 DR3 内容页上把不确定度按星等分档列了出来，这是理解整份数据的前提。

量	G<15	G=17	G=20	G=21
位置	0.01–0.02 mas	0.05 mas	0.4 mas	1.0 mas
视差	0.02–0.03 mas	0.07 mas	0.5 mas	1.3 mas
自行	0.02–0.03 mas/yr	0.07 mas/yr	0.5 mas/yr	1.4 mas/yr
G 星等	约 0.3 mmag	1 mmag	6 mmag	—
G_BP 星等	约 0.9 mmag	12 mmag	108 mmag	—
G_RP 星等	约 0.6 mmag	6 mmag	52 mmag	—

三个可以直接落地的观察。第一，G_BP 的误差在暗端比 G 大一个数量级以上，从 6 mmag 到 108 mmag 差 18 倍，而 G 只从 0.3 到 6。蓝色通道的灵敏度和背景代价最高，暗端尤其明显；这也是为什么官方在勘误里专门提醒 G_BP 星等暗于 20.3 时要谨慎使用。第二，视差相对误差随距离增长得比位置快，因为视差信号本身随距离反比衰减，而位置信号不会。第三，2 参数解的中位位置不确定度是 1–3 mas，比 5 参数解暗端还差，把它们与全天体测量解混在一起做统计，会把精度分布抹平。

把这张表换算成一个具体门槛：如果要做 10% 以内的距离估计，视差需要大于 10 倍相对误差阈值，也就是在 G≈17 处距离要到约 1.4 千秒差距以内；到 G=20 处只能到约 200 秒差距。这个数量级决定了 DR3 在做银河系远端的距离测量时基本只能靠大样本统计，不能靠单源。

§4.2 视差零点：一个必须显式处理的偏移

官方明确给出了一个数字：由河外源（理论上视差应为零）反推出的 DR3 视差零点约为 −17 微角秒。

这个偏移不大，但它在两个场景下会致命。一是远距离恒星，真实视差本身只有几十微角秒，一个 17 微角秒的偏移就能让「距离」变成负数或无穷；二是大样本的垂直结构统计，系统性的零点会在数亿行上累积成可见的偏差。

官方对此的处理是「给出一个暂定的零点修正公式」，而不是直接改数据。这是 DR3 的一贯做法：数据冻结，修正方法交给使用者。所以任何涉及距离的分析，都应该先决定用不用这个修正，并且把它写进方法里。用与不用都能发表，不声明才是问题。

与之配套的还有一个量叫 astrometric_excess_noise_sig，即「超出预期噪声的显著性」。它的作用不是告诉你误差多大，而是告诉你「这行的模型是不是根本不适用于这个源」。一个未分辨的双星，其中心位置会随时间晃动，单星模型强行拟合后残差偏大，这个量就会跳高。它是与 ruwe 互补的第二道筛子。

§4.3 三张表讲同一件事：为什么交叉分析总在缩水

回到 §2.1 里那张覆盖率的表。它的真正含义不是「产品有缺失」，而是「任何联合分析都会被最短的那一列截断」。

设想一个很自然的任务：用 BP/RP 光谱推断出的有效温度做标签，训练一个从 G、G_BP、G_RP 三波段测光反推温度的模型。想法很合理——测光数据覆盖 15 亿源，光谱参数覆盖 4.7 亿源，理论上能拿 4.7 亿条样本。

实际跑下来会发现三件事。

第一，astrophysical_parameters 里同一个温度有多个版本。名字里带 gspphot 的来自光度链的 GSP-Phot 模块，带 gspspec 的来自光谱链的 GSP-Spec 模块，带 mhd 的来自另一种模型，还有 flame、esp-hs、esp-ucd 等等。官方 Apsis 系统的设计就是让多个算法各自输出一套参数，附各自的标记位。选哪一个，直接决定标签的含义。

第二，每个版本都有自己的有效范围。GSP-Phot 对超冷星不适用，GSP-Spec 只对 RVS 光谱足够好的源有效。不加筛选直接把两套参数的并集当标签，等于把不同物理条件下的测量混进同一个回归目标。

第三，astrophysical_parameters 的 226 个字段里，绝大部分是可空的。真正「温度、重力、金属丰度、消光四项齐全」的源，远少于 4.7 亿。

所以这里的操作顺序必须是：先定标签来源，再定有效性门槛，最后才谈样本量。反过来做——先把表 join 起来再想办法——得到的样本集会比想象中小一两个数量级，而且缩小的方式与科学问题无关。

§4.4 变源：24 类是一个约定，不是自然界的分法

1,050 万个变源被归入 24 个监督式类别，其中 997.7 万个拿到了分类结果。类别的名字就在 vari_classifier_class_definition 表里，用 TAP 一查就能列出来：

ACV|CP|MCP|ROAM|ROAP|SXARI   ACYG   AGN   BCEP
BE|GCAS|SDOR|WR   CEP   CV   DSCT|GDOR|SXPHE
ECL   ELL   EP   LPV   MICROLENSING   RCB
RR   RS   S   SDB   SN   SOLAR_LIKE   SPB   SYST   WD   YSO

这张清单有三个必须知道的性质。

第一，竖线是并列，不是分隔。ACV|CP|MCP|ROAM|ROAP|SXARI 在表里是一行一个类别名，表示这几类在分类器里是同一个输出标签，因为它们在光变形态上难以区分。把它当成六个类别去做多分类，类别数就不对了。这也是官方页面正文写「24 类」、而相关论文标题写「25 类」的原因之一：口径不同，一个是分类器的输出标签数，一个是论文讨论的物理类别数。

第二，类别的定义依赖于分类器。vari_classifier_class_definition 表里有一列 classifier_name，查询结果只返回了一个值 nTransits:5+。也就是说，这 24 个类是从「至少 5 次有效穿越」这个前提下训练出来的分类器的输出。少于 5 次穿越的源，即使确实是变源，也不会进入这套分类。

第三，AGN 也在这 24 类里。24 类中有 87 万多个是活动星系核，它们不是恒星。做恒星变源统计时如果不剔掉这一类，样本里会混进河外源。

§4.5 贯穿案例：一个做光变分类器的团队，第一周踩到的四个坑

这一节用一个具体项目把上面几节串起来。假设有一支三人团队，目标是用 DR3 训练一个区分食双星与 RR 天琴型变星的模型——这两类在光变形态上有相似之处，是文献里常被拿来对比的一对。

第一天的计划：查表，vari_eclipsing_binary 有 218 万行，vari_rrlyrae 有 27 万行，总量约 245 万，够用。拉数据，抽 80% 训练。

第一个坑，出现在查字段的时候。vari_eclipsing_binary 有 39 个字段，vari_rrlyrae 有 78 个。两者字段数差一倍，共有的字段只有 source_id、solution_id 和少数几个通用量，光变形态参数（傅里叶系数、周期、振幅）的命名与组织方式并不一致。想直接拼表是拼不起来的，必须先定一套两边都有的特征。

第二个坑，出现在取光变曲线的时候。表里只有拟合出来的统计量，没有原始光变曲线。要拿曲线得走 DataLink 通道，而这条通道不在 TAP 里，得逐个源或分批请求。245 万条曲线的获取，从「一条 SQL」变成了「一个需要排队、限流、断点续传的工程」。

第三个坑，出现在按 source_id 切分数据集的时候。团队为了省事，按 source_id 排序后取前 80%。结果发现模型在验证集上的表现好得不正常。原因在 §3.1 已经写过：source_id 的数值里含位置信息，按数值排序切分等于按天区切分，而天区与天区之间的星族结构、消光、观测次数都不同。模型的「泛化」实际是从不同天区学到的规律，换到同一天区的另一半就崩了。

第四个坑，出现在统计类别比例的时候。团队发现食双星比 RR 天琴型多 8 倍，于是做了类别加权。但 vari_rrlyrae 这张表本身是有选择效应的：RR 天琴型在球状星团与银晕里密集，在那里的观测条件和分类难度与银盘不同。在整张表上做加权，等于假设这两类的可探测性在各天区一致，而这个假设并不成立。

四周之后，团队的工作流变成了这样：从 vari_summary 取通用统计量做初步特征，用 vari_eclipsing_binary 与 vari_rrlyrae 各自的轨道/傅里叶解做专用补充特征，用天球坐标做分组切分而不是随机切分，并且把「分类器只对 ≥5 次穿越有效」写进了数据清洗脚本的第一行。

这个案例要说明的不是「DR3 难用」，而是：它的坑几乎全藏在「表之间的关系」里，而不是「表的内部」。单看任何一张表，字段说明都写得清楚；把两张表放在一起，问题才开始出现。

§4.6 一个官方的反面例子：出错了也不会重发

vari_planetary_transit 的改名风波（§3.4）值得从质量管理的角度再看一遍，因为它展示了 Gaia 处理错误的方式，也暴露了使用者必须自己承担的部分。

时间线是这样的：2022 年 6 月 13 日发布，表里 41 颗新候选加 173 颗已知行星；同年 6 月 23 日，官方发通知说这张表有严重错误、不要使用；2023 年 2 月 7 日，官方给出修正后的表，同时把旧的改名保留。

整件事里最关键的细节是「旧表保留」。官方完全可以直接删掉，但它选择了改名保留。原因不言自明：已有论文可能引用了旧表，删掉就无法复现。但保留的代价是，Archive 里同时存在两个名字极像的表，而它们的区别只在 solution_id 一处。

对使用者来说，这形成一个必须养成的习惯：任何引用 DR3 的数字之前，先确认它来自哪张表、哪个版本。 这不只是严谨问题——如果你的论文里写「Gaia DR3 报告了 214 台行星凌星」，而官方表里是 41 颗新候选加 173 颗已知行星共 214 条，那么这句话本身没错；但如果审稿人拿的是 2022 年 6 月那张表，数字同样对得上，含义却完全不同。

§4.7 DAIMS 评估：把它当数据管理对象看

DAIMS（Data and Information Management Standards，v1.1）本是为生物医学数据设计的成熟度框，套在 Gaia DR3 上会暴露它的性格：它在「可追溯性」上极强，在「可获取性」上很强，在「可协商性」上很弱。

DAIMS 维度	成熟度	依据
唯一标识	高	source_id 逐行唯一，且每个发布独立编号
元数据描述	极高	152 字段每列都有单位与说明、TAP_SCHEMA 可机器读取
数据溯源	极高	每个源可回溯到 DPAC 的处理链路与具体论文
数据质量声明	高	官方单设「已知问题」页，逐条给出受影响源数
版本管理	高	发布之间不重叠，勘误可知，旧表保留
许可清晰度	中	许可类型明确，但 NC 条款的具体边界依赖 ESA 逐案解释
商业可用性	低	须事先书面申请，无标准化的商业授权流程
机器可读格式	极高	统一的 TAP/ADQL 接口，所有表同构可查
可复现性	高	冻结数据 + 保留旧表，但逐历元产品不在 TAP 里
文档可达性	中	2026 年 10 月核验时内部文档站返回 503

综合判断：作为「可检索、可追溯的天文表格」，它的成熟度接近满分；作为「可以随手拿来炼丹的机器学习数据集」，它有明显的门槛——体积大、许可受限、缺失结构复杂。

这张表对你意味着什么？如果你的项目需要向合作方或审稿人证明数据来源可信，DR3 的溯源能力是加分项，你能把任何一行追到具体的处理模块。反过来，如果你的项目是一个商业产品，许可这一行就是必须先解决的问题，而且不是「加个署名」能解决的。

§5 工具层：三条取数路径与它们各自的代价

DR3 没有「下载链接」这种东西。它有三条互不相同的取数路径，各自适合不同的任务，代价差了一个数量级。走错路径的代价，往往比走错模型还大。

§5.1 三条路径一览

路径	接口	适合什么	单次规模上限	需要注册
TAP 同步查询	tap/sync	交互式探索、小结果集	取决于服务端，通常几十万行	否
TAP 异步作业	tap/async	大批量导出、长时间扫描	每个用户并发上限 5 个作业	否
批量下载	Archive 网页	全表、逐历元产品、光谱文件	10 TB 总量	否

三条路径都免注册。这一点常被误传成「需要注册才能取数」——实际匿名即可查询与下载，注册只在需要保存查询历史、提高并发额度时才有用。

§5.2 TAP 同步查询：一条 curl 就够了

Gaia Archive 的 TAP 服务是一个标准的 IVOA Table Access Protocol 端点，接受 ADQL。从能力文档看，它同时声明了 ADQL 2.0 与 2.1 两个版本，并且提供了一整套自定义函数（esdc_array_*、esdc_astrometric_parameter_error、epoch_prop 等），说明它把天文学里常用的坐标变换与时序外推都做进了查询语言。

最直接的用法是拼一个 URL：

Q='SELECT TOP 5 source_id, ra, dec, parallax, phot_g_mean_mag
     FROM gaiadr3.gaia_source
    WHERE phot_g_mean_mag BETWEEN 9 AND 10 AND parallax_over_error > 100'
curl -sS -G "https://gea.esac.esa.int/tap-server/tap/sync" \
  --data-urlencode "REQUEST=doQuery" \
  --data-urlencode "LANG=ADQL" \
  --data-urlencode "FORMAT=csv" \
  --data-urlencode "QUERY=$Q"

这段能直接跑，返回的就是 §2.3 里那种格式的 CSV，第一行是列名。三个参数缺一不可：REQUEST=doQuery 是动作，LANG=ADQL 声明查询语言，FORMAT 决定返回格式（csv、json、votable 都可以）。

用 Python 的 astroquery 包会更省事，它把上面这段封装成了一个方法：

from astroquery.gaia import Gaia

job = Gaia.launch_job(
    "SELECT TOP 5 source_id, ra, dec, parallax "
    "FROM gaiadr3.gaia_source "
    "WHERE phot_g_mean_mag < 10 AND parallax_over_error > 100"
)
t = job.get_results()
print(t.colnames)

launch_job 默认走异步通道，因为 TAP 的同步通道对超过一定行数的查询会直接拒绝。要控制行为，用 Gaia.launch_job(..., dump_to_file=True, output_format='csv') 让结果落盘，避免一次性读进内存。

§5.3 表结构要先查，不要猜

新手最常犯的错是按记忆写列名。DR3 有 91 张表、2088 个字段（gaiadr3 schema 的 TAP_SCHEMA 列数），猜错是常态。正确做法是先查元数据：

Q="SELECT table_name, COUNT(*) AS n
     FROM TAP_SCHEMA.columns
    WHERE schema_name = 'gaiadr3'
    GROUP BY table_name
    ORDER BY n DESC"
curl -sS -G "https://gea.esac.esa.int/tap-server/tap/sync" \
  --data-urlencode "REQUEST=doQuery" --data-urlencode "LANG=ADQL" \
  --data-urlencode "FORMAT=csv" \
  --data-urlencode "QUERY=$Q"

这条查询返回每张表的字段数，一眼就能看出哪张表是宽表、哪张是窄表。查到最大的是 astrophysical_parameters（226 字段）、astrophysical_parameters_supp（175）、gaia_source（152）。

注意一个实操细节：TAP_SCHEMA.tables 与 TAP_SCHEMA.columns 里的 table_name 是带 schema 前缀的完整名（如 gaiadr3.gaia_source），但真正写 ADQL 时要写成 gaiadr3.gaia_source，不能写成裸表名。两者一致，但 columns 表里还有 db_table_name 等字段，别混用。

§5.4 逐历元数据的取法：DataLink 不在 TAP 里

这是 DR3 取数路径上最容易被误解的一处，值得单独说。

前面 §2.2 列了六类产品，但逐历元测光（epoch photometry）不在这六类里，因为它根本不在 TAP 的 91 张表中。用 TAP 查 gaiadr3 schema 的全部表名，能搜到的只有 vari_epoch_radial_velocity 一张历元表——那是视向速度的时间序列，不是测光。

官方 DR3 内容页的说法是：变源分析随附了「底层的逐历元测光」（underlying epoch photometry）。这份数据以附属产品形式挂在 Archive 上，通过每个源的 DataLink 接口按需获取。所以正确的取数流程是：

1. 先用 TAP 查出你关心的 source_id 列表；
2. 再对每个源走 Archive 的 DataLink 通道取它的附属文件；
3. 附属文件才是逐历元的光变曲线。

这条链路的一个实证细节：2026 年 10 月，Gaia Archive 做了一次破坏性变更，把原来叫 RAW 和 INDIVIDUAL 的 DataLink 数据结构分别改名为 DATAMODEL_GAIA 与 DATAMODEL_STANDARD。任何写死了旧名字的客户端，在升级后会直接报错。这类变更不出现在数据文档里，只出现在新闻页，是 DR3 生态里最难预判的一类风险。

§5.5 并发限制：5 个作业意味着什么

同一次变更还带来另一个限制：单个用户同时运行的作业数不能超过 5 个。

对个人探索这几乎无感。但如果要批量导出几十张表做本地分析，就会排队。一个实用的做法是把多个表合并进一个查询（用 UNION 或分表串行），而不是并发拉起多个作业。另一个做法是直接走批量下载，一次把全量拖下来——代价是 10 TB 的磁盘和带宽，以及下载后自己建索引。

场景	推荐路径	理由
查几个源长什么样	同步 TAP	秒级返回，无需管理作业
拉一个天区的所有源	异步 TAP	行数多，同步会超时
全表做统计	批量下载	每次都扫全表，查询开销远大于下载
取某源的光变曲线	DataLink	唯一通道
取光谱系数	批量下载	光谱文件单独打包

§5.6 工具链：哪些是真能用的

DR3 的软件生态分成三层：官方工具、社区库、格式转换。

官方在 DR3 页上列出了几个专用工具：GaiaXPy（把 BP/RP 系数转回光谱）、Bolometric Correction Tool（补算未被算出的热改正）、GSPPhot 与 GSPSpec 的定标工具、OA 自组织映射工具、消光系数工具、拟合光度不确定度工具、NSS 工具。这些工具解决的都是一件事：把表里的数值转成物理量。

社区库里最常用的是三个：astroquery（查询）、pygaia（天体测量与光度的换算公式）、gaiaxpy（专门做光谱重建）。三个都能从 PyPI 直接装，都轻量。

要特别提一个生态缺口：VizieR 的 CDS 镜像在 2026 年 10 月核验时不可达。VizieR 是天文界最常用的星表检索界面，它收录了 Gaia DR3（编号 I/355），很多教程都默认「去 VizieR 查」。这条路径走不通的时候，只能回到 Archive 本身的 TAP。

§5.7 官方文档站的可达性：一个需要留余量的地方

DR3 的完整数据模型、数据处理文档、逐章引用说明，都放在 gea.esac.esa.int/archive/documentation/ 下面。2026 年 10 月核验期间，这个路径持续返回 503。

这不是说文档没了——同一时期，TAP 服务、DR3 内容页、已知问题页、新闻页全部正常响应。这意味着文档的不可达是局部的、可恢复的。

但它对使用者的实际影响是具体的：如果你的流程依赖自动从文档站抓取元数据（比如解析数据模型生成字段说明），需要有备用路径。 备用路径有两个：一是 TAP_SCHEMA 本身，它把每张表的每个字段的单位与说明都以机器可读的方式存着，是文档的可查询镜像；二是 DR3 的批量下载包，里面附带了完整的 ECSV 文件与列说明。

§6 与库内条目的关系

这个维基的主体是医学与生命科学数据。Gaia DR3 是全站第一条天体物理数据集，它的加入不是偶然，而是「AI-ready」这个概念在向外扩张时自然碰到的一个边界。

站内条目	关系	检索路径
NASA Exoplanet Archive	同为天文方向；DR3 提供宿主恒星参数，它提供行星参数	按「天体物理」「星表」检索
各类影像数据集	互补：DR3 不含像素，只含测量值	按「多模态」检索
大样本队列类数据集	结构相似：都是逐行带误差与缺失的宽表	按「时序数据」检索

要让读者从医学数据走到 Gaia，中间需要一座桥：两者都是「测量记录 + 质量标记 + 版本冻结」的三件套。医学队列里，「患者 3 号的血红蛋白在 2019 年 4 月测了一次，误差 ±0.2，2019 年 6 月的记录缺失」；Gaia 里，「源 X 的视差解出来了，误差 0.03 毫角秒，视向速度缺失」。结构一模一样，只是「患者」换成了「源」。

这个类比能直接迁移经验：在医学数据里怎么处理缺失、怎么做队列划分避免泄漏、怎么用测量误差加权，在 DR3 上同样适用，而且因为样本大，问题会被放大得更清楚。

§7 质量评估与局限性：先拆掉一个评价框架

§7.0 阅读本节前需要知道的一件事

DR3 不应该用「机器学习数据集」的框架来评价。它没有训练集与测试集的划分，没有类别标签的均衡性可言，也没有「一张图一个标签」的监督结构。拿 ImageNet 那套指标（类别平衡、标注一致性、分辨率）去衡量它，评价出来的东西与它实际能做的事无关。

更准确的说法是：DR3 是一份测量记录，它的质量指标是精度、系统误差、覆盖率，而不是标注准确率。 用这个框架看，才谈得上评价。

第二种常见的框架错位是把「没被标为变源」理解成「不变」。变源判定需要足够多的有效穿越，暗源穿越次数少，即使真变了也检不出来。所以变源表是有偏的清单，不是「所有会变的天体」。

§7.1 逐条局限

局限	具体表现	官方依据
时间跨度短	34 个月，不足以测长期趋势	DR3 内容页观测期说明
单个源被多次穿越但发布平均值	主表一行一个平均解，不携带历元	同页「underlying epoch photometry」表述
光谱是低分辨	BP/RP 分辨率低，RVS 只有 99.96 万条	counts 表
河外源混入恒星表	665 万类星体候选、484 万星系候选与恒星同表	counts 表
亮端与暗端受限	G 约 3 至 21	同页限等说明
拥挤星场退化	银盘方向精度下降，专门管线在 DR4 才成表	DR4 内容页 crowded field 系列
商业不可免费	CC BY-NC 3.0 IGO	License 页
文档站间歇不可达	2026 年 10 月核验持续 503	实际访问
部分字段已知错误	ipd_gof_harmonic_* 全表不可用	已知问题页 2024-10-09

§7.2 外部验证：三组能自己做的对照

局限不是只能接受，有些可以自己验。下面三组对照都不需要额外数据。

对照一：视差零点。 取一批高银纬、看起来像河外源的天体，它们的视差中位数应该接近 0，实际会接近 −17 微角秒。这验证了官方给出的零点。

对照二：误差随星等的变化。 按星等分箱，算每箱视差的四分位距，应该能复现官方表格里的单调上升趋势。如果复现不出来，多半是查询时把 2 参数解混进来了。

对照三：交叉匹配的一致性。 DR3 与 2MASS 的交叉匹配表里，同一个源的位置差应该落在两部星表的误差范围内。偏差大的那一批，通常就是 §4.2 里提到的「未分辨双星」候选。

§7.3 与同类数据集的关系

DR3 的定位在「广度」这一端。它是全天、十亿级、每个源几十个参数，但每个参数的精度有限、每种产品覆盖有限。要深度要去找专门的巡天，要单个源的高分辨光谱要去找 SDSS，要恒星参数的高精度版本要去看专门的星表（如 APOGEE、GALAH）。

这不是缺点，是分工。银河系研究近十年的范式变化，靠的正是「先有全天的低精度底图，再有局部的深度样本」，两者叠加才有三维结构图。

§8 版本与生态：一张表为什么能活二十年

§8.1 版本节奏

发布	时间	观测跨度	源数
DR1	2016-09	14 个月	1,142,679,769
DR2	2018-04	22 个月	1,692,919,135
EDR3	2020-12-03	34 个月	约 18 亿
DR3	2022-06-13	34 个月	1,811,709,771
DR4	2026-12-02	5.5 年	约 28 亿（官方约数）
DR5	约本十年末	10.5 年	未定

DR3 在这个序列里的位置很特殊：它与 EDR3 共享同一段观测，但产品种类翻了几倍。这也是为什么它的源数（18.1 亿）与 EDR3 几乎相同，而内容量完全不同。

§8.2 DR4 已经排上日程，DR3 的位置正在变化

这一点值得单独说，因为它是这份数据集当下最现实的问题。

官方在「Gaia 观测结束」页上写过：DR4 覆盖 5.5 年任务数据，预计 2026 年发布；DR5 覆盖完整 10.5 年，约在本十年末。

更具体的时间表出现在 2026 年 10 月 8 日的通知里：为准备 DR4，Gaia ESA Archive 将于 2026 年 11 月 25 日 12:00 CET 停机，2026 年 12 月 2 日 12:00 CET 重新开放，届时上线 DR4。

DR4 页面上给出的对照数字很直白：DR3 全量 10 TB，DR4 约 400 TB；DR3 的源表是 18 亿，DR4 会发布所有处理过的源，约 28 亿，其中 gaia_source 是约 20 亿的高质量子集，另外新增 all_source_astrometry、all_source_photometry、all_source_rvs、all_source_flags 四张覆盖全源的表。

这意味着两个判断：

第一，DR3 在 2026 年 12 月之后会从「最新版」变成「上一版」。以它为基准的论文仍然成立，但「用最新数据」这个理由不再适用。

第二，DR3 的某些已知问题会在 DR4 里被修正。ipd_gof_harmonic_* 的两个字段，官方明说正确的结果会在 DR4 发布。如果你在做的东西恰好依赖这两个字段，等 DR4 比在 DR3 上想办法绕开更划算。

但 DR3 不会因此失去价值。DR4 的源清单与 DR3 不是一一对应的：DR4 专门设了一张 dr3_neighbourhood 交叉表，用来在 DR4 的源与 DR3 的源之间找对应关系，官方在这张表的说明里写得很重：「想查一个在 DR3 里认出来的源在 DR4 里的记录，不能简单取同 source_id 的那一行」，一个 DR4 源的邻域里可能有零个、一个或（很少见地）多个 DR3 对应体。

这段说明同时确认了两件事：DR3 会作为一份独立的、可被追溯的清单长期存在；而它的 source_id 确实不跨版本稳定——这一点在 §3.1 已经从 DR3 自己的文档里读到，现在又从 DR4 的文档里得到了印证。

§8.3 它为何能持续：三个刚性

一张星表能活二十年，靠的不是情怀。

第一个刚性是「底图效应」。 银河系研究里所有涉及距离、运动、空间分布的工作，都要先有一份全天的、逐源带误差的坐标与自行。DR3 是这个底座。用它的人不必喜欢它，但没有替代品——SDSS 只覆盖北天三分之一，2MASS 没有视差，Hipparcos 只有 11.8 万颗。

第二个刚性是「测量不可复制」。 Gaia 卫星已经停止观测（2025-01-15），航天器已经钝化（2025-03-27）。DR3 那 34 个月的观测数据是唯一的，不存在「重新测一遍」的选项。这跟可以重采的图像数据集完全不同：一份 2016 年的 CT 数据集，理论上还能从别的医院再收一批；Gaia 在 2016 年看到的天，只有它记下来了。

第三个刚性是「机构承载」。 数据由 ESA 的 ESAC 科学数据中心物理托管，由 DPAC 联盟（跨越欧洲多国的数百名研究人员）负责处理，并由五个伙伴数据中心（CDS、ASI SSDC、ARI、AIP、Flatiron）提供镜像。这套结构保证了即使主站在维护，数据也不会消失——这也是为什么 2026 年 10 月文档站 503 时，TAP 仍然能用。

§8.4 它的起源：一次「测量学上的登月」

Gaia 的设计目标在 1990 年代就定下了：用一台卫星，以微角秒级的精度测量十亿颗恒星的位置与运动，画出银河系的三维图。这个精度是什么概念——从地球上看，一枚放在月球上的硬币的张角约是几毫角秒；Gaia 的目标精度比它小两三个数量级。

实现这个精度的关键不是望远镜口径，而是「同时测量」：三台仪器共用同一个焦平面，天体测量、测光、光谱在同一批穿越中被记录下来，彼此的定标互相约束。这也是为什么 DR3 能把位置、颜色、光谱、变源放进同一张源表——它们在物理上是同一次观测的产物。

§8.5 那些看起来「不利」的设计，其实是被算过的

DR3 有几处设计初看很别扭，但它们都是权衡的结果。

为什么主表只存平均解，不存历元？ 因为对 18 亿个源各存几十到几百次穿越，体积会膨胀两个数量级。DR4 之所以能到 400 TB，就是因为把逐历元产品正式发布了。DR3 的选择是把逐历元留给真正需要的那部分源（变源），其余的只留平均。

为什么光谱用基函数系数而不是波长采样？ 因为 BP/RP 是低分辨率光谱，每个源只有几十个采样点，直接存储体积小但重建费劲；用基函数系数存储，体积更小，且保留重建能力。代价是使用者必须用 GaiaXPy 这类工具才能看到「光谱长什么样」。

为什么 24 类变源分类要合并那么多子类？ 因为分类器的信息来自穿越次数（nTransits:5+），穿越次数少的源光变形态信息不足，细分就变成了噪声。合并成粗类是统计上的诚实。

§9 使用指引：三种角色的路径

§9.1 三种角色

角色	目标	最短路径
研究者	回答一个天体物理问题	TAP → 定样本 → 下载 → 本地建模，始终记录筛选条件
工程师	把 DR3 接进产品	先解决许可，再评估体积，最后定缓存策略
学习者	理解「十亿级带误差的表」长什么样	从 §2.3 的逐行解剖开始，跑一次同步查询

§9.2 最小可运行流程

下面这段是从零到拿到一份可用样本的完整流程，可直接跑：

from astroquery.gaia import Gaia

Q = """
SELECT source_id, ra, dec, parallax, parallax_error, pmra, pmdec,
       phot_g_mean_mag, bp_rp, ruwe, radial_velocity
  FROM gaiadr3.gaia_source
 WHERE parallax_over_error > 10
   AND ruwe < 1.4
   AND phot_g_mean_mag BETWEEN 6 AND 18
   AND ra_error IS NOT NULL
   AND dec_error IS NOT NULL
   AND pmra IS NOT NULL
   AND pmdec IS NOT NULL
"""

job = Gaia.launch_job_async(Q, dump_to_file=True,
                            output_format="csv",
                            output_file="dr3_sample.csv")
print(job.get_results().colnames)

四个筛选条件各自的理由：parallax_over_error > 10 保证视差信噪比够（距离相对误差约 10%）；ruwe < 1.4 剔掉疑似未分辨双星；星等区间避开亮端与暗端两个退化区；最后四条非空判断把样本限定在「位置、视差、两个自行分量都有误差估计」的源上，也就是官方口径里的 5 参数解，比只判 parallax IS NOT NULL 更稳。

这里刻意没用 astrometric_params_solved 那一位标记：字段确实存在（官方说明是「解出了哪些参数」），但它的具体取值编码在核验日可达的页面里没有列出，写死一个数字反而会让人以为那是标准写法。用列的非空性判断，是所有字段说明都支持的做法。

§9.3 在 AI 流程中的位置

DR3 在机器学习流程里扮演的是「带物理先验的结构化表格」这个角色，不是「原始数据」。把它当原始数据用会有两个后果：一是体积压不住，二是丢失了误差信息。

更合适的用法有两种。

一是当作特征工程与不确定度建模的基准。 18 亿行、152 列、每列带误差，天然适合做「如何用误差加权」、「如何处理结构化缺失」这类研究。这类工作不需要天文背景，但需要理解为什么缺失不是随机的。

二是当作跨模态对齐的一端。 DR3 的光谱、测光、位置、运动是同一个天体的不同物理侧面的测量。用它做「多模态表征学习」，比常规的多模态数据集更有意思：模态之间不是「图文配对」那种松散关系，而是同一个物理量的不同投影。

§9.4 一个完整的每日工作流示例

对经常使用 DR3 的人来说，下面这套流程可以省掉大量试错。

第一步，先用小样本试查询。任何复杂的 join 都先用 TOP 100 跑一遍，确认字段名与筛选条件都成立。

第二步，用 COUNT(*) 估算样本量。在拉数据之前知道会有多少行，能避免「拉了半小时发现只有 300 行」。

第三步，只拉需要的列。gaia_source 有 152 列，全拉会比只拉 10 列慢十几倍，而且大部分列在后续分析里用不上。

第四步，把结果与 solution_id 一起存。这样以后能追溯是哪一版的数据。

第五步，把筛选条件写进脚本并存档。DR3 的坑大多不在查询，而在「三个月后忘了当时为什么这么筛」。

§10 AI 使用声明

项目	说明
性质	测量记录，非标注数据集
建议用途	天体测量与运动学分析、光谱参数回归、变源分类、跨模态表征学习
不建议用途	直接当作商业产品训练数据；把主表当时间序列；用 source_id 跨版本连接
伦理	无个人数据，无一例对应自然人；但商业使用须遵守 CC BY-NC 3.0 IGO
引用	致谢写 Credit: ESA, Gaia DPAC；论文引用 DR3 总览论文，具体产品另引对应处理论文
版本	Gaia DR3，Archive release 3.15（2026-10-14）；DR4 定于 2026-12-02 上线
状态	冻结，只出勘误不改数据；卫星已于 2025-01-15 停止科学观测
再分发	可自由分发（非商业），须保留许可与署名

§11 常见误读（避坑清单）

常见说法	实际情况	证据
「Gaia DR3 是 CC BY 4.0，随便用」	是 CC BY-NC 3.0 IGO，商业使用须先向 ESA 申请	官方 License 页与 ESA 档案条款原文
「source_id 是稳定主键，跨发布直接 join」	官方明说 DR3 源清单须当作与 DR2、DR1 相互独立	官方源标识说明页原文
「18.1 亿个源，就有 18.1 亿个天体」	源是发布内的行，同一物理天体跨发布可能变成另一个源	同上
「按 source_id 排序切训练/测试集」	ID 内含位置信息，按数值切分等于按天区切分	官方源标识说明页
「Gaia 是恒星表，里面都是恒星」	含 665 万类星体候选、484 万星系候选	官方 counts 表
「表里能取到光变曲线」	TAP 的 91 张表里没有逐历元测光，须走 DataLink	TAP_SCHEMA 查询 + 内容页表述
「变源 24 类就是 24 种物理上有区别的星」	部分类别是并列合一的输出标签，且分类器只对 ≥5 次穿越有效	vari_classifier_class_definition 表查询结果
「表里空着的行可以用列均值补」	缺失是系统性的（如视向速度只覆盖 1.9%），补齐等于编造	官方 counts 表
「DR3 还在持续更新」	观测到 2017-05-28 为止，数据冻结，只出勘误；DR4 定于 2026-12-02	内容页 + 2026-10-08 新闻
「ipd_gof_harmonic_* 两个字段可以用来筛双星」	这两个字段全表算错，官方「不予鼓励」使用	已知问题页 2024-10-09
「16 位 ID 就够表示一个源」	source_id 是 64 位整数、19 位十进制，用 32 位或浮点接收会丢精度	官方源标识说明
「Gaia 卫星还在给 DR3 加新数据」	卫星已于 2025-01-15 停止科学观测、2025-03-27 钝化	官方观测结束页

§12 FAQ

Q1：DR3 的源数为什么和 EDR3 差不多，内容却多那么多？

因为两者共享同一段观测与同一套天体测量、光度定标。官方原话是 DR3「不包含新的天体测量，也不包含新的光度定标」。所有新增产品——光谱、天体物理参数、变源、河外源候选、太阳系天体——都是在同一批观测上增加的分析。

Q2：我要做星族研究，应该先用哪张表？

从 gaia_source 拿位置、视差、自行与三波段星等做初筛，再用 astrophysical_parameters 补温度与重力。不要一上来就 join 全部——先定有效范围，再定样本。

Q3：视差零点 −17 微角秒要不要修正？

取决于用途。做近距离恒星、距离远小于 1 千秒差距的，影响可以忽略；做大样本的银晕结构或远端距离统计，必须修正并在方法里声明。官方给的是「暂定修正公式」，没有直接改数据。

Q4：为什么同一个源在 astrophysical_parameters 里有多组温度？

因为 Apsis 系统里并存多个算法：GSP-Phot（来自 BP/RP 低分辨光谱）、GSP-Spec（来自 RVS 光谱）、FLAME、ESP-Hs、ESP-UCD、MHD 等。每组都有独立的有效范围与标记位，必须选一组，不能混用。

Q5：变源分类的 24 类里，为什么有的类名用竖线连起来？

竖线表示这几个类别在分类器里被合并成一个输出标签，因为光变形态上不可分。把它当独立类别展开会导致类别数算错。

Q6：DR3 里有逐历元测光吗？

有，但不在 TAP 表里。它作为附属产品通过 DataLink 挂在 Archive 上，只对变源（1,050 万）提供。TAP 中唯一的历元表是 vari_epoch_radial_velocity，那是视向速度时序。

Q7：vari_planetary_transit 和 vari_planetary_transit_13june2022 用哪个？

用前者（不带日期的）。前者是 2023-02-07 修正后的新表（solution_id 375523436409132247），后者是保留下来备查的原始错误版本。

Q8：商用要怎么申请？

许可页给出的路径是发邮件到 data.licences@esa.int 提出详细申请。ESA 的档案条款原文要求「任何商业使用、包括直接或间接产生经济收益的使用，都须事先获得授权」。没有标准化的自动授权流程。

Q9：10 TB 全量数据，个人能下载吗？

技术上可以，免注册。实际操作上要考虑磁盘与带宽，以及下载后如何建索引——压缩 ECSV 需要解压，总量会更大。更常见的做法是按需 TAP 导出，只下需要的列与行。

Q10：DR4 上线后 DR3 还能查吗？

能。Archive 设计上承载所有发布的全部数据（官方原话「hosts all data of all data releases」），DR4 页也提供了 DR4 与 DR3 之间的交叉匹配表 dr3_neighbourhood。DR3 会作为历史版本长期可访问。

Q11：为什么 G_BP 的误差比 G 大那么多？

BP 波段是蓝端的低分辨光谱通道，单光子通量低、背景贡献大，暗端尤其明显。官方表格里 G_BP 在 G=20 处的误差是 108 mmag，而 G 只有 6 mmag。官方在勘误里专门提醒 G_BP 暗于 20.3 时要谨慎。

Q12：DR3 和 SDSS 能互换吗？

不能。DR3 是全天、十亿级、低分辨光谱、测视差与自行；SDSS 是局部天区、深成像、中分辨光谱、不测视差。两者是「面」与「点」的关系，交叉使用时靠交叉匹配表对齐。

术语表

术语	含义
天体测量（astrometry）	测量天体在天空中的位置及其随时间的变化
视差（parallax）	地球绕日运动导致天体视位置的周期性偏移，倒数是距离
自行（proper motion）	天体在天空中的角速度，单位毫角秒/年
mas	毫角秒，1/1000 角秒
ruwe	重归一化单位权重误差，衡量天体测量解相对期望质量的比值
参考历元	所有历元相关量外推到的统一时刻，DR3 为 J2016.0
ICRS	国际天球参考系，Gaia 坐标的基准
TCB	质心坐标时，DR3 结果使用的时间坐标
BP/RP	蓝端与红端低分辨率光谱通道
RVS	径向速度光谱仪，中分辨率，用于测视向速度
G / G_BP / G_RP	Gaia 三波段星等
5 参数解	赤经、赤纬、视差、两个自行分量
6 参数解	5 参数加一个拟合的伪颜色，用于缺颜色的源
2 参数解	只解出赤经、赤纬
变源	亮度随时间变化的天体
非单星（NSS）	不是单个天体的系统，包括双星与带伴星系统
GSP-Phot	由 BP/RP 光谱推断天体物理参数的模块
GSP-Spec	由 RVS 光谱推断化学丰度与参数的模块
Apsis	汇总多个参数推断算法的系统名
QSO	类星体，活动星系核的一种
SSO	太阳系天体
HEALPix	球面等面积划分方案，用于全天图
TAP	表访问协议，天文数据的标准查询接口
ADQL	天文数据查询语言，SQL 的天文扩展
DataLink	表行到附属产品的链接协议，逐历元数据的通道
交叉匹配（cross-match）	把两个星表里指向同一个天体的行对应起来
Gaia-CRF3	Gaia DR3 的天球参考架，由 161 万源定义

附录 A 速查卡

键	值
全名	Gaia Data Release 3
发布	2022-06-13
观测期	2014-07-25 至 2017-05-28
源总数	1,811,709,771
表数	91（gaiadr3 schema）
主键	source_id（64 位整数）
TAP 端点	https://gea.esac.esa.int/tap-server/tap/sync
许可	CC BY-NC 3.0 IGO
署名	Credit: ESA, Gaia DPAC
全量体积	约 10 TB
下一个版本	DR4，2026-12-02 上线

附录 B 文件与表清单

表	字段数	内容
gaia_source	152	主表，逐源平均解
astrophysical_parameters	226	四套算法的物理参数
astrophysical_parameters_supp	175	补充参数
gaia_source_lite	51	主表的精简版
xp_summary	20	BP/RP 光谱拟合摘要
vari_summary	68	变源统计摘要
vari_cepheid	81	造父变星专用解
vari_rrlyrae	78	RR 天琴型专用解
nss_two_body_orbit	77	双星轨道解
qso_candidates	41	类星体候选
galaxy_candidates	38	星系候选
synthetic_photometry_gspc	54	合成测光（注意单位勘误）
total_galactic_extinction_map	—	全天消光图
vari_epoch_radial_velocity	16	视向速度时序

附录 C 外部资源对照

资源	用途
Gaia DR3 内容页	权威数字与限制说明的来源
Gaia DR3 已知问题页	勘误的唯一权威来源
Gaia ESA Archive	TAP 查询与批量下载入口
Gaia Data License	许可原文
ESA 档案通用条款	署名与商业授权流程
五个伙伴数据中心	CDS、ASI SSDC、ARI、AIP、Flatiron，提供镜像

编辑说明

核验时间：2026-10-29。核验方式：逐页抓取 ESA COSMOS 站点上的 DR3 内容页、许可页、已知问题页、观测结束页、DR4 内容页、2026 年新闻页与 ESA 档案条款页；通过 Gaia ESA Archive 的 TAP 同步端点实际执行 ADQL 查询，取得表清单（gaiadr3 schema 91 张）、各表字段数与单位、真实记录样本、变源类别定义表内容；核对官方 counts 表全部数字。未能核实：DR3 数据处理文档站（gea.esac.esa.int/archive/documentation/）在核验期间持续返回 503，涉及逐章文档的细节未逐条比对；data.licences@esa.int 的实际审批流程未验证。版本说明：DR4 的上线时间取自 2026-10-08 官方新闻页；核验日 DR4 尚未进入 Archive（gaiadr4 schema 查得 0 列）。

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• sdss-dr20 — 共享标签：多模态 / 评测基准 / 图像分类 / 影像-文本对齐
• soilgrids — 共享标签：多模态 / 评测基准 / 图像分类
• nasa-exoplanet-archive — 共享标签：多模态 / 评测基准 / 图像分类
• randolph-glacier-inventory — 共享标签：多模态 / 评测基准 / 图像分类
• biomedica — 共享标签：多模态 / 评测基准 / 图像分类 / 影像-文本对齐
• plip — 共享标签：多模态 / 评测基准 / 图像分类 / 影像-文本对齐
• eurosat — 共享标签：多模态 / 评测基准 / 影像-文本对齐
• cern-cms-opendata — 共享标签：多模态 / 评测基准 / 图像分类
• esa-worldcover — 共享标签：多模态 / 评测基准 / 图像分类
• skincap — 共享标签：多模态 / 图像分类 / 影像-文本对齐

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。