信息速览
同一个菌属，在两篇论文里跑出十倍之差，经常不是样本的差别，而是 prep、去复用、质控、聚类这一串步骤的差别。论文方法部分通常只有两百字，压缩掉的部分恰好是别人要复现时最需要的部分。
Qiita 把这一串步骤变成可查询的记录。每一项研究下面挂着若干 prep，每个 prep 下面挂着按处理步骤串起来的 artifact，每个 artifact 记着它从哪个上游来、经过哪个 processing、用了哪套虚拟环境与参数。原始读段与分析产物并列存放，不是一份，而是每一步都留一份。它由加州大学圣迭戈分校 Knight 实验室维护，北亚利桑那大学的 Caporaso 实验室参与共同开发，站点当前版本 2026.01，公开库含 891 项研究。
代价也很实在：prep、artifact、processing、study、analysis 这套概念模型，第一次接触几乎都要卡一次；旧域名 qiita.microbio.me 已在汇总文档中残留但站点本身不再解析，按旧文档抄网址会直接失败。一屏速览见下表。
| 维度 | 内容 |
|---|---|
| 中文名 | 奇塔（官方音译） |
| 英文名 | Qiita |
| 读音 | 站点注明按 cheetah 读 |
| 维护方 | UCSD Knight 实验室；Caporaso 实验室共建 |
| 首发 | 2012 年前后；旗舰论文 2018 年 |
| 现役版本 | 2026.01（站点页脚构建号 3b390e0） |
| 当前入口 | https://qiita.ucsd.edu/ |
| 旧入口 | qiita.microbio.me（不再解析，汇总文档仍有残留） |
| 公开研究 | 891 项 |
| 唯一公开样本 | 438,595 |
| 私有样本 | 118,389 |
| 沙箱样本 | 663,630 |
| 已提交 EBI | 1,148 |
| 已提交 EBI 样本 | 390,512 |
| 数据模态 | 16S、18S、ITS、鸟枪宏基因组、宏转录组、全长操纵子、基因组分离株、代谢组 |
| 最大模态 | 16S 扩增子（389,616 样本） |
| 访问门槛 | 公开数据可匿名下载；非公开需 owner 授权 |
| 许可 | BSD 3-Clause |
| 检索层 | redbiom（metadata、feature、taxon 三路） |
| 托管项目 | Earth Microbiome Project、American Gut Project |
§1 它要解决的具体麻烦
1.1 数据是有，可复现性没有
微生物组领域在 2010 年代积累了一个尴尬的局面：沉积到公共测序归档里的样本越来越多，每篇论文却各自跑一套流程。同一个 16S V4 数据集，用闭参考 Greengenes 聚出的 OTU 表和用 deblur 去噪得到的序列表，物种数可以相差数倍；同一份表，是否抽平、抽到几千条，alpha 多样性的结论可能反转。这些差别都写在方法部分里，但方法部分的写法既不统一，也不足以让人照着重跑。
更麻烦的是中间产物。一篇论文公布了 FASTQ 与最终的 BIOM，而真正决定结果的是中间那一层：去复用用了哪套 barcode、质控的截断长度是多少、是否做过人源宿主过滤、过滤用的是哪一版参考基因组。这一层几乎从不公开。于是「别人能不能复现你的结果」这个问题，长期只能靠邮件问作者，而作者往往已经毕业。
更隐蔽的一层是版本。同一套流程在 2016 年和 2020 年跑，即便参数写得一字不差，底下的软件依赖、宿主参考基因组、参考数据库都已经换过。方法部分不会写软件版本，参考文献里也很少提到具体的参考库版本号。读者照着重跑，得到一条略有差异的曲线，然后不确定差异来自哪里。
Qiita 的设计起点就是这两层。它把「数据文件」当成一个过于粗糙的单位，改用「artifact」这个更细的单位，并且规定每一个 artifact 必须记录它是怎么来的。同时它把处理链放在服务器上跑，而不是让每篇论文各自在本机跑一遍，于是版本这件事被集中管理。
这不意味着 Qiita 解决了版本漂移。它只是让漂移变得可以观察：哪一批 artifact 用的是哪一版宿主过滤，可以在库里查到，而不是靠回忆。
1.2 三条常见的错误期待
第一次接触这个平台的人，通常带着三种期待，三种都会部分落空。
期待一：以为它是一个下载站。 首页确实有「下载全部公开 BIOM」的入口，但那个包只包含各 study 的 processed BIOM，不含 analysis 阶段从多研究合并出来的表。想要后者，必须自己建一个 analysis 并在里面重新合并。文档把这一点写在下载页的注里，但很少有人读到最后一行。
期待二：以为它的丰度表是统一重处理的。 不是。每项 study 的 BIOM 由提交方在各自 prep 上跑出来的 processing 生成，参数各异。Qiita 不负责跨研究统一。这是一条需要反复强调的边界，也是它与 EMBL-EBI 侧资源最大的差别。
期待三：以为 artifact 的数就是数据的数。 站点有 artifact 相关的统计，但一个 artifact 可能是十兆的 FASTQ 包，也可能是一个几百字节的排序坐标文件。按个数理解规模会严重失真。
1.3 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 复现某篇论文的 OTU 表 | 该 study 下按处理步骤串起来的 artifact 链 | 够，前提是论文引用的是 Qiita 的 artifact |
| 把两个研究的样本合起来做元分析 | analysis 功能，可在同一 context 下合并 | 勉强够，context 不一致时结果不可比 |
| 按「土壤且 pH 小于 7」找样本 | redbiom 的 metadata 检索 | 够，这是它的强项 |
| 按「含有某个 OTU」找样本 | redbiom 的 feature 检索 | 够，需知道 OTU id 或序列 |
| 拿一份统一重处理的相对丰度矩阵 | 不提供 | 不够，去 curatedMetagenomicData |
| 拿经过统一流水线重跑的功能注释 | 不提供 | 不够，去 MGnify |
| 长期归档并拿到稳定登录号 | 可同步提交 ENA | 部分够，需提交方主动勾选 |
| 匿名脚本批量拉取 | 公开 artifact 与 public_download 端点免登录 | 够，但端点无文档，需按页面表单拼接 |
| 拿到每一步的软件版本与参数 | 2024.07 起把宿主过滤信息写入库并链接到 artifact 与 prep | 部分够，历史数据未全部回填 |
| 拿临床表型做预测建模 | 元数据里有部分宿主字段，但非结构化、非临床级 | 不够，需自行整理 |
1.4 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 审稿时作者说「数据已公开」，你要核 | 按 study id 找到 artifact 链，核对处理方法 | 要求作者给出 artifact id，而不是 study id |
| 你有一批 16S 数据，想找可比的公开样本 | redbiom 按 metadata 或 feature 检索 | 检索后必须先确认 context 一致 |
| 你要做 EMP 级别的环境样本分析 | EMP 的样本托管在这里 | 用 emp_release 字段筛批次 |
| 你要复现 AGP 的肠型分析 | AGP 托管在这里，教程也用它做示例 | 注意 AGP 的预处理版本与最新版不同 |
| 你要一份不用自己跑的丰度表 | 不提供统一表 | 转向 curatedMetagenomicData |
| 你要在大规模与 MGnify 结果对齐 | 两套 context 体系不同 | 只能在物种层面粗对齐，不能逐值比对 |
| 你在教学，要学生跑通一条完整链 | 概念模型清晰，教程完整 | 从 §6.1 的最短流程开始 |
1.5 一句话判断
它是一个把「这一份结果是怎么算出来的」当一级对象的平台：凡是要追问来源的地方都值得进来，凡是只想要一张表的地方都不必进来。
1.6 不适合谁：四条边界
第一条，不适合把它当归档库。 它的长期存档服务是转交给 ENA 的，自己不是国际核苷酸序列数据库合作组织的成员。真要做十年归档，ENA 才是终点。
第二条，不适合要求「开箱即用的统一矩阵」的人。 这个诉求属于 curatedMetagenomicData 与 MGnify，不属于 Qiita。
这两个邻居的差别也值得说清。curatedMetagenomicData 面向的是人体微生物组，把各研究的原始读段按固定方法重处理后，以 R 包的形式分发；它的人体样本整理得比 Qiita 更整齐，但没有原始读段，也没有非人体样本。MGnify 面向的是所有提交到欧洲核酸归档的测序数据，用统一流水线重跑，同版本内可比；它覆盖广，但没有逐步产物的溯源。Qiita 的位置在这两者之间：既有原始读段，也有逐步产物，但没有统一重处理。三者各缺一块，缺的那块恰好是另两个的强项。
第三条，不适合零代码用户。 界面能点，但要完成一次像样的元分析，仍然要懂命令行、BIOM 格式与 QIIME 2。
第四条，不适合把结果直接用于临床判断的人。 平台是研究工具，条款与免责声明把这一点写得很清楚，元数据也不具备临床级结构。
§2 数据构成与规格
2.1 六个概念，一次讲清
Qiita 的学习曲线陡，陡在概念，不在操作。六个概念理顺了，剩下的都是表单。
study 是顶层容器，对应一篇论文或一个项目。一项 study 有一份样本信息表，描述每个样本的环境与宿主属性；study 本身不存序列。
sample 是生物学单位，从哪来、什么部位、什么时间。样本信息表里的每一行就是一个 sample，允许有空白与对照样本。
prep（preparation）是湿实验与建库单位。同一样本可以分别做 16S、ITS、宏基因组，于是同一样本在多项 prep 里各出现一次。prep 信息表描述的是这份样本在这个 prep 里怎么被处理：用哪个引物区、哪次测序、barcode 是什么。
artifact 是原子单位。官方 FAQ 的定义是：artifact 是一组文件及其摘要，代表某条处理命令或分析命令的输入或输出。原始 per-sample FASTQ 是 artifact，去复用质控后的 FASTQ 是 artifact，BIOM 是 artifact，系统发育树是 artifact，距离矩阵与 PCoA 排序也是 artifact。
processing 是一条处理链的实例，记录用哪个插件、哪个版本、哪些参数，把上游 artifact 变成下游 artifact。
analysis 是跨 study 的分析容器。把多项 study 的 artifact 选进同一个 analysis，在同一 context 下重新计算，输出新的 artifact。
这六个概念的关系可以一句话概括：study 装 sample，sample 按 prep 分叉，prep 产出 artifact，artifact 由 processing 派生，analysis 把分散的 artifact 拉到一起重算。
2.2 为什么要发明 artifact 这个单位
传统的做法是把「数据集」当作单位，一个数据集一个压缩包。Qiita 把单位切细，直接后果是同一批字节会以不同形态反复出现。同一样本的 FASTQ，在原始形态、去复用后形态、质控后形态各存一份；同一份质控后 FASTQ 进 deblur 得到 BIOM，进闭参考聚类得到另一份 BIOM。两份 BIOM 都挂在同一母节点下，是并列关系，不是替代关系。
这个设计的收益是可追溯。任何一份 BIOM 都能顺着母节点一路往上查到原始 FASTQ 与参数。代价是存储与理解成本：同一批序列在库里被重复存储多份，artifact 总数远大于研究数与样本数。
还有一层代价容易被忽略。artifact 之间是派生关系，不是版本关系。系统不会告诉你「这一份 BIOM 已经被哪一份取代」。当一位研究者后来又用新算法重跑了一遍，新 BIOM 会以一个新的节点出现在同一母节点下，与旧 BIOM 并列。页面上会看到两条分支，没有箭头表示「后者更好」。选择哪一条，是使用者的判断，不是系统的判断。
这条设计选择与「living data」的承诺是一致的：既然数据会持续被重新注释，就不能让任何一份产物被静默覆盖。旧结果留在原地，作为当时那一刻的证据；新结果是新的证据。审计意义上这是对的，使用体验上这要求使用者自己有版本意识。
对使用者的直接影响是一条硬规则：引用时应绑定 artifact id，不要只写 study id。同一项 study 下可能同时存在多个可用的 BIOM，只写 study id 无法区分。
2.3 记录结构：从 study 到一个 BIOM 的完整解剖
以一项典型的 16S 研究为例，从 study 到可分析的 BIOM，中间要经过下面这些节点。
| 层 | 对象 | 内容 | 由谁产生 |
|---|---|---|---|
| 1 | study | 标题、摘要、PI、环境包、DOI | 提交方填写 |
| 2 | sample 信息表 | 每行一个样本，含 sample_name 与宿主/环境字段 | 提交方上传 |
| 3 | prep 信息表 | 每个 prep 一行样本，含 barcode、run_prefix、引物区 | 提交方上传 |
| 4 | raw artifact | 未去复用的 FASTQ，正反向与 barcode 文件 | 提交方上传 |
| 5 | demux artifact | 去复用并质控后的 per-sample FASTQ | 内置 split libraries 步骤 |
| 6 | BIOM artifact | deblur 表或闭参考 OTU 表 | deblur 插件或闭参考聚类插件 |
| 7 | 树 artifact | 从代表序列构建的系统发育树 | 依插件可选 |
| 8 | 分析 artifact | 距离矩阵、PCoA 坐标、alpha 多样性表 | analysis 内计算 |
第 5 步默认参数来自 QIIME 1.9.1。这是一个容易误解的点：Qiita 是独立平台，但拆库与质控那一步用的是 QIIME 1 的实现，而不是 QIIME 2。文档明确写「uses the default in QIIME 1.9.1」。
第 6 步有两条路。一条是 deblur，官方标为 preferred，把序列按固定长度截断后去噪，OTU id 就是唯一序列；默认产出两张表，一张是完整的 deblur 表，另一张是只保留与 Greengenes 相似度达 80% 的参考命中表，后者被官方自己描述为极为朴素、粗糙的过滤。另一条是闭参考聚类，参照 Greengenes 3_8-97、SILVA 119、UNITE 7 三套库之一，OTU id 依参考库给定，未命中参考库的序列被丢弃。
2.4 模态与规模
站点统计页在每一次访问时动态生成，页脚给出生成时间。截至 2026 年 10 月 28 日的快照，各字段如下。
| 统计项 | 数值 |
|---|---|
| 公开研究 | 891 |
| 私有研究 | 176 |
| 沙箱研究 | 3,000 |
| 已提交 EBI 研究 | 1,148 |
| 唯一公开样本 | 438,595 |
| 唯一私有样本 | 118,389 |
| 唯一沙箱样本 | 663,630 |
| 已提交 EBI 样本 | 390,512 |
| 已提交 EBI 样本（按 prep 计） | 454,883 |
| 全站注册用户 | 17,482 |
| 累计作业数 | 939,259 |
按数据类型拆分的公开样本数如下。这张表只收规模，不收分布比例。
| 数据类型 | 公开样本数 | 说明 |
|---|---|---|
| 16S | 389,616 | 细菌与古菌标记基因，绝对主力 |
| 18S | 12,149 | 真核标记基因 |
| ITS | 15,550 | 真菌标记基因 |
| 宏基因组 | 105,808 | 鸟枪法 |
| 全长操纵子 | 803 | 全长 rRNA 操纵子 |
| 宏转录组 | 27,161 | RNA 层面 |
| 代谢组 | 1,545 | 非测序模态 |
| 基因组分离株 | 1,505 | 培养物分离株测序 |
两处口径需要点明。第一，「唯一样本」与「按数据类型计」不是同一分母：一个样本可能同时做了 16S 与宏基因组，前者去重，后者不去重，所以模态列相加必然大于唯一样本数。第二，研究与样本的「已提交 EBI」数大于公开数，说明部分私有研究也已把原始数据托管到 ENA，只是 Qiita 侧的 artifact 尚未公开。这两条都不是错误，但引用时必须说明用的是哪一个口径。
2.5 与同类资源的字段差异
| 维度 | Qiita | MGnify | curatedMetagenomicData |
|---|---|---|---|
| 原子单位 | artifact | analysis（MGYA） | 数据集版本 |
| 原始读段 | 库内存一份 | 不存，指向 ENA | 不存 |
| 中间产物 | 逐步保留 | 只留最终产物 | 不保留 |
| 处理参数 | 逐 artifact 记录 | 流水线版本统一 | 方法固定为 MetaPhlAn 与 HUMAnN |
| 跨研究可合并性 | 需先对齐 context | 同版本内可比 | 包内已统一 |
| 交付形态 | ZIP 包与 BIOM | TSV、FASTA、GFF | R 对象 |
| 检索方式 | redbiom 三路检索 | REST API 按 accession | R 函数按数据集名 |
中间那一行是三者最根本的分野。Qiita 认为中间产物本身就是资产，MGnify 认为中间产物是过程，curatedMetagenomicData 认为过程可以全部隐去、只留结果。
§3 身份层：它到底是仓库还是档案
3.1 名实之间
站点首页给自己的定义是「entirely open-source microbial study management platform」——开源的微生物研究管理平台。关键词是 management。它不把自己定位成数据库，也不定位成分析服务，而是定位成「管理」。
这个定位解释了几乎所有的设计取舍。管理意味着要有账户、要有权限、要有可见度状态机、要让 owner 决定何时公开；管理也意味着它不承诺统一重处理，因为统一重处理是数据中心的职责，不是管理平台的职责。
官方另有一句话值得单独记下：内部数据集是 living data，会按当前最佳实践被周期性重新注释。这句话是它区别于静态归档的根据，也埋下了版本漂移的隐患。
3.2 谁在维护，维护多久了
站点 FAQ 的免责声明写明：Qiita 是研究工具，托管在加州大学圣迭戈分校 Knight 实验室维护的科研计算资源上。文档页脚版权从 2015 年起标注 Qiita Development Team。首页给出两个代码入口，主仓库在 biocore 组织下的 qiita，插件在 qiita-spots 组织下，按 BSD 3-Clause 分发。
平台与 Knight 实验室自身的研究工作绑定很深。EMP、American Gut 与后续的微生物组大规模计划都需要一个统一的样本管理入口，Qiita 最早就是为这个需求长出来的。它属于「研究基础设施」而不是「公共服务」，这在变更频率与文档维护上都能看到痕迹：文档版本号跟随发布号走，但页面内仍留有旧域名示例。
3.3 挂靠在哪张学术网络上
三个层级的挂靠关系需要分清。
第一层是机构层面：UCSD 的 Knight 实验室是主要运营方，Caporaso 实验室（北亚利桑那大学）提供 QIIME 系谱与技术路线，论文作者列表同时覆盖这两个团队与 Dorrestein 实验室。
第二层是项目层面：Earth Microbiome Project 的样本流转依赖 Qiita，American Gut Project 的公开数据也托管在这里。这两个项目不是 Qiita 的客户，而是它的共生物种——项目需要管理平台，平台需要真实负载。
第三层是数据生态层面：Qiita 与 ENA 之间是单向托管关系。提交方可以选择把原始数据同步提交 ENA，拿永久登录号。Qiita 因此不承担永久存档职责，这一点与 MGnify、ENA 的定位差别很大。
3.4 版本号里的取舍
首页页脚显示当前版本 2026.01，后面跟着构建号。文档站标题同样写 qiita 2026.01 documentation。版本号用年月，说明这是一个按发布周期滚动更新的平台，不是一个按数据集版本发布的仓库。
2024.07 那次发布有一项具体变更值得记录：宿主过滤的信息开始写入数据库，并链接到 artifact 与 prep。此前这些信息只存在于文档的方法描述里。官方对这次变更的说法是「for easier tracking」，目标是最终把最新的过滤方法应用到全部已有数据。这意味着 2024 年 7 月之前处理的 artifact，其宿主过滤参考库版本需要去 artifact 元数据里查，查不到就是查不到。
§4 质量层：artifact 链记录了什么，没记录什么
4.1 artifact 的溯源粒度
一个 artifact 记录的下游信息相当细：类型、生成它的 processing、上游 artifact、以及处理的名称与参数。这一层是 Qiita 的核心资产。
粒度也有边界。processing 记录的是参数，不记录环境。文档说每条流水线跑在各自的虚拟环境里，因此同一 processing 名在不同时点可能对应不同依赖版本。真正决定结果的软件版本，不一定能从 artifact 页面上直接读到。这一点在使用老 artifact 时必须留意。
4.2 预处理做了什么，没做什么
内置预处理覆盖三件事：去复用、质控、人源宿主过滤。标记基因扩子走「Split libraries and QC」，宏基因组走 fastp 去接头加 minimap2 宿主过滤。
宿主过滤的历史版本在文档里列成一张表，从 atropos 加 bowtie2 对 GRCh38.p7 加 PhiX 174，逐步演进到 fastp 加 minimap2 对 GRCh38.p14、T2T-CHM13v2.0 与人类泛基因组参考联盟 2023 版。最新一步还加入了 Movi。这张表本身就说明了一个问题：同一个样本在不同年份处理，人源读段残留量不同。
没做的事同样重要。平台不做跨研究的丰度归一，不做批次校正，不做物种注释的统一定版。deblur 那条路甚至明确不依赖参考库，OTU id 就是序列本身；闭参考那条路则完全依赖参考库版本。两种选择在同一项 study 里可以并存，结果不可互换。
不做这些，是有意为之还是没来得及做，官方没有解释。但从使用后果看，这一组「不做」把责任明确划给了分析者。平台保证每一步都留痕，不保证最后的表可以被横着拼。凡是想跨研究直接比较的人，都会在某一刻遇到这道墙。
另有一件事平台做了一半：系统发育树。闭参考路线下，是否附树取决于所选参考库是否自带树；deblur 路线下，树由代表序列另行构建。这意味着库内并非每份 BIOM 都配了树，做 UniFrac 类分析前必须先确认树是否存在。
4.3 官方口径里的一处冲突
文档的哲学页仍写着「目前在 main site、Sloan portal、EMP portal 三个门户」并给出 qiita.microbio.me、sloan_microbe.microbio.me、emp.microbio.me 三个地址。而主站实际已在 qiita.ucsd.edu 提供服务，旧域名不再解析。
这不是笔误，是文档同步滞后于基础设施迁移。判断标准很简单：以 qiita.ucsd.edu 能否打开为准。凡是从旧教程里抄来的 microbio.me 网址，一律替换成 ucsd.edu 之后再试。
4.4 一个样本能支撑几个问题
artifact 链的存在让「这份数据还能回答什么别的问题」变得可以核算。同一批 FASTQ，换一个去噪算法就得到一份新 BIOM；换一套参考库就得到另一份；换一种抽平策略就得到第三份。每一份都是合法 artifact，都有完整的上游记录。
代价是研究者容易误以为 artifact 多的 study 数据也多。实际上原始字节是同一批，多出来的只是派生形态。判断一项 study 的真实体量，应当看原始 FASTQ 的 artifact，而不是 artifact 总数。
还有一个反向的用途常被忽略：artifact 链可以当作「数据可用区」的边界来读。一项 study 若只有原始 FASTQ，没有下游 BIOM，说明它上传后没有走完处理；若有 BIOM 但没有树，说明系统发育相关的分析在这项 study 上做不了。这种「缺什么」的信息，在只有最终表的资源里是看不到的。
§5 取数层：怎么把数据拿出来
5.1 三条通道
Qiita 的取数有三条路，适用场景不同。
第一条是页面下载。登录后在 study 页选定数据类型与 prep，进入 processing 网络图，点开节点即可看到可用文件，包括 FASTQ、FASTA 与 BIOM。analysis 页同理，能拿到距离矩阵、PCoA 与可视化文件。
这个网络图是理解 Qiita 的关键界面。它不是列表，而是一张有向图：左边的节点是原始文件，向右每经过一次 processing 就分出一条新分支，右侧是最终产物。看这张图能一眼分辨「这份表是从哪条路来的」。第一次用的人常把图当成装饰，直接找下载按钮，结果下到的是自己并不需要的那一份。
第二条是匿名端点。公开 study 与 artifact 可以不登录直接取，这是脚本化的主通道。文档给出的地址形态是固定的，把 id 换掉即可。
第三条是整包镜像。首页提供「下载全部公开 BIOM 与元数据」的入口，一次打包，带 MD5 与最后更新时间。这个包适合做骨架，不适合做全集。
5.2 匿名端点与导出
#-- 公开 study 的元数据与 BIOM 汇总，匿名可取，大文件建议断点续传
curl -L -o qiita_study_biom.zip \
"https://qiita.ucsd.edu/public_download/?data=biom&study_id=10317"
#-- 只取原始读段；文件很大，先看页面上的提示再决定是否整包拉
curl -L -o qiita_study_raw.zip \
"https://qiita.ucsd.edu/public_download/?data=raw&study_id=10317"
#-- 单个 artifact 直接下载，artifact id 从 study 页面的处理网络图里读
curl -L -o qiita_artifact.zip \
"https://qiita.ucsd.edu/public_artifact_download/?artifact_id=REPLACE_WITH_YOUR_ARTIFACT_ID"
第三行里的 id 必须换成真实值，脚本不会校验，填错只会拿到空包或错误页。这一条是新手最常见的挫败来源。以上端点在 2026 年 10 月 29 日的探测中可连通；单次请求若对同一点位重复发起，后端会挂起连接，批量脚本应串行、加退避。
5.3 redbiom：先检索再取数
redbiom 是一个缓存服务，存的是一份比 Qiita 主库小得多、稀疏得多的向量化副本，主要为 metadata。它的作用是让人先找到样本，再回到 Qiita 取。它是一个 Qiita 插件，也可以单独装成命令行工具。文档站另有一节专门的教程，用 American Gut 的数据与一项炎症性肠病研究的样本走完整流程，从检索到取出到用 QIIME 2 重新处理，可以当作入门范本。
「缓存」这个词在这里需要按字面理解：它不是索引，也不是元数据库的完整副本。它回答的是「哪些样本命中这个条件」，而不是「这个条件的全部信息」。命中之后仍要回到主库去取 artifact，这一步的红利是避免了全库扫描，代价是检索结果的完整性依赖缓存的刷新节奏。页面在服务说明处给出一行最后更新标记，2026 年 10 月 29 日抓取时该处显示为未报告，也就是说当次检索的结果序列没有可核对的时间戳。写方法时最好把抓取日期一起写上，否则日后无法判断当时看到的是哪一版缓存。
三路检索的用法各不相同。
metadata 检索用的是自然语言处理后的词干匹配。查 antibiotics 时实际匹配的是词干 antibiot，查 crying 匹配 cry。词干之间可以用 & 取交、| 取并、- 取差，还能跟上 Python 风格的比较式。文档的例子包括分析婴儿、抗生素与年龄的组合，以及按土壤 pH 筛 EMP 批次。
feature 检索按特征查，闭参考下是 OTU id，deblur 下是序列本身。
taxon 检索只在闭参考数据上做，且只支持 Greengenes 命名，格式是等级前缀加双下划线加名称，例如 g__Escherichia。
redbiom 的一条硬约束是：检索结果必须带 context 才能取数。原因写在文档里：不同处理流程会带不同的偏倚，只有在同一 context 内数据才被期望可比。
这条约束的设计意图值得展开。redbiom 只存 metadata 的稀疏表示，因此它能回答「哪些样本符合这个条件」，但不能回答「这些样本的数据能不能用在一起」。后一个问题只有 context 能回答。系统把检索与取数拆成两步，等于把「可比性判断」这件事显式交还给使用者，而不是在后台悄悄合并。
实践中最常见的失误是检索到几百个样本就直接全部取数。抽出前若不看 context，取回来的数据包里会混着好几套流水线的产物，脚本能读通、不会报错，直到合并后的矩阵出现一堆零与异常值。
5.4 context 是什么
context 的语法形如「分箱策略-参考库-测序平台-测序区域-截断长度-编号」。它本质上是对一条处理流水线的压缩表示。
理解 context 的最佳方式是把它的每一段对应到一个真实决策：用 deblur 还是闭参考聚类、用哪套参考库、用哪个测序平台、扩增哪个区、截到多少碱基。这五个决策决定了数据里有多少种偏倚。同一 context 内的样本共享这套偏倚，因此可以合并；跨 context 合并则是把不同偏倚混在一起。
这一步是 Qiita 元分析的门槛所在。旧教程里常见「搜到就拿来用」的做法，脚本能跑通，结论不可靠。
context 的另一面是它不能替代元数据。context 描述的是处理，不是样本。两个样本在同一 context 内只能说明它们经过了同一条流水线，不说明它们的宿主、部位、采集时间相近。做元分析时，context 与元数据两个条件要同时满足：前者保证数据可比，后者保证问题成立。
5.5 从 artifact 到 QIIME 2
Qiita 的 artifact 与 QIIME 2 的 QZA 在概念上相近，都是把多个文件封装成一个单元。差别是 QIIME 2 只有两种封装：QZA 与 QZV，而 Qiita 的 artifact 类型更多。
官方 FAQ 给了一张对照表，把 Qiita 的产物映射到 QIIME 2 的语义类型：beta 多样性 TSV 转 DistanceMatrix，FASTA 转 FeatureData 的 Taxonomy 或 Sequence，BIOM 转 FeatureTable 的三种频次语义，排序结果转 PCoAResults，树转 Phylogeny，alpha 多样性表转 SampleData 的 AlphaDiversity。掌握这张表，就能把 Qiita 的产物接进 QIIME 2 的生态。
5.6 许可与访问门槛
许可这件事，官方说法比大多数同类平台干脆。FAQ 明确：Qiita 软件与插件按 BSD 3-Clause 分发；从 qiita.ucsd.edu 与 redbiom 下载的全部原始数据、处理后数据与元数据，同样按 BSD 3-Clause 分发。
访问门槛按可见度分档，需要注意「三档」与「五态」是两套说法。哲学页正文先写「有 sandboxed、private、public 三种状态」，同一页的图注又写「有五种：sandboxed、awaiting_approval、private、public、archived」。前者是面向使用者的简化，后者是完整状态机。实际使用时按五态理解更准确：sandbox 是上传后的默认态，可在系统内使用但外人不可见；申请升级后进入 private 并分配永久空间；管理员核验期间的中间态为 awaiting_approval；论文就绪后 owner 切到 public；旧 BIOM 在算法更新后被 archived。
私有研究的例外通道是单条 artifact 的下载链接。owner 在页面上点「Generate Download Link」得到一个唯一链接，任何人拿到即可下载，不需要登录。这条通道让同行评议期间的私下共享成为可能，也意味着链接本身需要当作凭证管理。
§6 与库内相邻资源的关系
6.1 关系图谱
库内与 Qiita 相邻的资源共七个，关系分三类。
第一类是托管关系：Earth Microbiome Project 与 American Gut Project 的数据在 Qiita 上，这两个库内资源与 Qiita 是「同一批字节的两种入口」。从项目入口进是读它的实验设计与表型，从 Qiita 进是读它的处理链。
第二类是数据出口关系：ENA 是 Qiita 的长期存档终点，SRA、HMP 是同一批研究的另一个镜像。凡是要拿永久登录号，最终都落在这一层。
第三类是方法学邻居：MGnify 是 EBI 侧的统一重处理，curatedMetagenomicData 是人体宏基因组的整理丰度表，GTDB 与 SILVA 是参考库层。这三者与 Qiita 不在同一层，混为竞品会误判。
6.2 三者分工写透
Qiita 的不可替代性在中间层。 它保存原始读段与逐步分析产物的双轨，每一份 artifact 都记录了从哪个 prep 来、经过哪个 processing、用了什么参数。这让「别人能不能复现你的结果」第一次有了可查的答案。
MGnify 的不可替代性在一致性。 它在 EBI 侧用统一流水线重跑，输出标准化分析结果，同一流水线版本内的结果可以直接横向比较。它不做逐步溯源，因为它的主张恰好相反：你不需要知道中间怎么走的，只需要知道用的是哪版流水线。
curatedMetagenomicData 的不可替代性在便捷。 它只出整理后的相对丰度表，不含原始读段。研究者拿到的是开箱可用的矩阵，代价是彻底放弃对上游的控制。
三者的关系可以用一句话概括：要问「怎么算的」去 Qiita，要问「横向比一比」去 MGnify，要问「给我一张能直接建模的表」去 curatedMetagenomicData。三者叠加使用才是完整的工作流：先用 curatedMetagenomicData 筛出候选研究，再用 MGnify 看统一重处理下的表现，最后用 Qiita 回到原始 artifact 核参数。
6.3 一个具体的对照场景
假设你要研究某类肠道菌群与宿主状态的关联。用 curatedMetagenomicData，你能很快拿到合并好的矩阵与元数据，跑出关联结果。审稿人问「这几个研究的 deblur 参数一致吗」，你答不上来，因为那个包里根本没有这一层。
换用 Qiita 的路径：先用 redbiom 按宿主状态与部位检索样本，拿到候选 study 列表；再逐个检查 context，只保留同 context 的子集；在 analysis 里合并重算，得到一份带完整上游记录的矩阵。样本数会少很多，但每个样本的来源都能查到。
两条路的结论常常不一致，这本身是有价值的信息：如果 curatedMetagenomicData 给出强关联而 Qiita 的同 context 子集给出弱关联，差异很可能来自批次而非生物学。
把这个场景再推一步。假设差异确实来自批次，那么下一步不是折中，而是判断哪一版更接近真值。若 Qiita 的同 context 子集样本量足够，它以一致的处理为前提，批次的干扰更小；若子集太小，统计功效不足，弱关联可能只是噪声。这个判断没有通用答案，但把两版结果并列写进结果部分，本身就是一种可复现的表述。
§7 质量评估与局限性
7.0 阅读本节前的一个前置校正
在给 Qiita 打分之前，需要先纠正一个默认的误判：按「数据集」的标准评价它。
按数据集的标准，它不合格：没有统一重处理、没有统一定版注释、不同 study 的 BIOM 不能直接拼接。按「分析档案」的标准，它的分数完全不同：每条产物都有上游、每个参数都可查、每次预处理都留有版本记录。
这是评价基础设施型资源最常见的错位。做湿实验的人觉得它好用，因为它能托管；做数据工程的人觉得它难用，因为它不给统一表。两者都没说错，只是尺子不同。
评分采用第三把尺子：作为一份「可回溯分析链的档案」，它做得怎么样。
7.1 DAIMS 评分表
| 评估维度 | 分值 | 评分理由 |
|---|---|---|
| 描述层：身份与边界 | 4.0 / 5 | 官方明确定位为研究管理平台而非数据库；Knight 实验室与论文信息齐全；但文档内的旧门户地址未更新，边界要靠使用者自行判断 |
| 描述层：文档完备度 | 4.5 / 5 | 入门、处理、下载、redbiom、context、术语表、FAQ 齐备，概念解释质量高；扣分在旧域名残留与部分页面版本不一 |
| 结构层：标识体系 | 4.5 / 5 | study、prep、artifact、analysis 各有整数标识，层级清晰且可脚本拼接；artifact 级标识是同类资源中少见的细粒度 |
| 结构层：层级一致性 | 4.0 / 5 | study 到 sample 到 prep 到 artifact 的主链严格；异常在可见度状态，三态与五态两套说法并存 |
| 结构层：模态配对 | 3.5 / 5 | 同一批样本跨 16S、ITS、宏基因组、代谢组的多模态配对在库内可实现，但模态间缺少统一的关联键，需靠 sample_name 人工对齐 |
| 访问层：开放程度 | 4.0 / 5 | 公开数据可匿名下载，端点无需令牌；非公开数据默认隔离，只能由 owner 授权；下载端点无机器可读说明 |
| 访问层：可复现性 | 5.0 / 5 | 这是它最强的一项：每份产物都可回溯到处理步骤与参数，2024.07 起宿主过滤信息入库存档，复现问题有据可查 |
| 访问层：许可清晰度 | 4.5 / 5 | FAQ 一句话把软件、原始数据、处理后数据、元数据统一到 BSD 3-Clause，在同类平台里罕见地明确；扣分在 ENA 侧许可需另行核对 |
八项合计三十四点，满分四十。换算成百分制约八十五分，落在「专业使用者会长期依赖，通用流程会觉得别扭」这一档。
分数偏低的两项都很有指向性。层级一致性扣在文档口径，不是工程问题；模态配对扣在关联键，是多模态研究的普遍问题，Qiita 只是没有额外解决。
7.2 同层比较
| 评估维度 | Qiita | MGnify | curatedMetagenomicData |
|---|---|---|---|
| 可追溯性 | 强，artifact 逐级可查 | 中，仅流水线版本 | 弱，只有重处理版本号 |
| 统一性 | 弱，各 study 各自为政 | 强，同一流水线可比 | 强，包内已统一 |
| 开箱可用性 | 低，需理解概念模型 | 中，需处理 TSV | 高，R 对象直接可用 |
| 原始读段可得性 | 强，库内存一份 | 无，指向 ENA | 无 |
| 交互检索 | redbiom 三路检索 | API 按 accession | R 函数按名 |
7.3 它为何能持续
Qiita 能存在，是因为它是别人工作的副产品，而不是一个独立产品。
Knight 实验室自己的项目需要它：EMP 的环境样本要托管，American Gut 的公开数据要托管，实验室的测序产出要走一条标准化入库路径。这三条需求构成了真实负载。平台的软件成本因此被摊薄到这些项目上，而它对外提供的服务是这些项目的自然外溢。
这也解释了它为什么不做统一重处理：那是数据中心的KPI，不是实验室的。同样解释了它为什么文档里还留着旧门户地址：维护者优先保证流水线跑通，文档同步是次要任务。
7.4 已知的、可枚举的偏差
偏差一，模态结构偏斜。 16S 研究在数量上压倒宏基因组，公开库中 16S 样本数接近宏基因组的四倍。想做大样本宏基因组分析的人，在这里能找到的资源远少于想象。
偏差二，公开不等于全量。 私有与沙箱样本加起来接近七十八万，是公开数的近两倍。公开库只代表「owner 愿意公开的部分」，人群与疾病谱都因此被筛选过一轮。
偏差三，处理版本漂移。 文档承诺数据是 living data、会按最佳实践周期重注释，但历史 artifact 的实际参数依处理年份而变。跨年比较同一 study 的两版 BIOM，差异可能全部来自流水线而非样本。
偏差四，宿主过滤史不一致。 人源读段清理的参考库从 GRCh38.p7 一路换到 T2T-CHM13v2.0，中间还叠加过 Movi 与泛基因组参考。老数据的人源残留比例不可与新数据直接比较。
偏差五，环境注释依赖 EMPO 版本。 环境分层用 EMPO 本体，本体本身经历过多轮修订，文档站同时保留旧版对照表供参考。同一条样本在旧版与本体的新版里可能落在不同的末级类目。跨版本检索环境信息，若按末级类目名称过滤，会漏掉一批；按上级类目过滤，则会把不同环境混进来。稳妥做法是先按上级类目缩小范围，再逐条读原始字段。
偏差六，命名歧义。 平台缩写与一个日本技术文章社区完全同名，且后者的网页数量大得多。用搜索引擎找文档时，需要带上 ucsd 或 microbiology 一类的词，或者直接访问域名。这不是数据质量问题，但在实际使用中造成的检索损耗是真实的。
7.5 外部验证的入手点
三个可比对的外部坐标。其一，ENA 侧的研究数：Qiita 侧已提交 EBI 的研究数为 1,148，与 ENA 中同源项目的登录号可以逐一核对。其二，MGnify 侧：凡是在 ENA 有原始数据的宏基因组研究，MGnify 几乎都有对应分析产物，同一样本在两边的物种层面结果可以粗对。其二的位置最容易被高估：两边的参考库、分类器与阈值都不同，能对上的是物种层面的相对趋势，对不上的是具体数值。任何「MGnify 与 Qiita 结果一致」的表述，若没有给出一致性的判定标准，不能采信。其三，论文侧：旗舰论文给出的是平台能力与设计，不是数据规模，引用规模数字时须注意出处是站点统计而不是论文。
7.6 伦理与合规要点
条款明确要求样本编号与元数据在提交前完成去标识。公开研究的下载完全匿名，没有点击同意协议的环节，这意味着使用者的合规责任落在自己一侧。
人体来源样本的处理方式没有统一标准：宿主读段清理依赖各研究自己的预处理参数，历史版本也不一致。做二次分析时若涉及人体序列，应先做一次宿主比对确认，不能假定库内数据已经干净。
私有研究的存在带来另一层考量：owner 可以随时把研究永久删除，前提是尚未公开。已公开的研究则不可撤回，这一条在很大程度上保证了公开库的稳定性。
§8 生态位与历史
8.1 历史沿革
时间线可以粗分为四段。
2012 年前后平台上线，定位是研究管理；2018 年旗舰论文在 Nature Methods 发表，题目强调 rapid 与 web-enabled，正文给出的是平台设计与元分析能力，不是数据规模。2024 年 7 月发布把宿主过滤信息写入库并链接到 artifact，这是溯源能力的一次实质补强。2026.01 是当前版本，站点与文档同步更新。
需要点明的是，论文不是数据规模的出处。旗舰论文发表于 2018 年，正文里的任何规模数字都只代表当时；引用 2026 年的库规模必须标站点统计页与生成日期。
8.2 它站在哪种工具传统里
Qiita 站在 QIIME 系谱的开源传统里，而不是站在生物信息数据库的传统里。
这条系谱的特征是：工具与平台同源，方法论文与软件发布同期，代码开放、许可宽松、文档面向研究者而非工程师。它的判断标准是「一个做湿实验的学生能不能跑通」，而不是「一个数据工程师能不能批量集成」。
理解了这一点，很多看似缺陷的设计都能解释。artifact 要人点开图看、下载端点没有机器可读的说明、context 要靠人判断——这些都是在「让研究者看得懂」与「让机器读得顺」之间选了前者。
8.3 与直接竞品的位置关系
在「微生物组数据托管」这个格子里，Qiita 的对手不是 MGnify 或 curatedMetagenomicData，而是 QIITA 之外的通用序列归档。
与 ENA 比：ENA 管字节，Qiita 管过程。ENA 保证十年后文件还在，Qiita 保证今天能说清这份文件是怎么变成那张表的。
与实验室自建服务器比：自建服务器便宜、自由，但没有人替你维护预处理版本，也没有办法把别人拉进来。
与商业云平台比：商业平台在易用性与支持上更强，但在「结果可被第三方核验」这一点上，开源平台的优势是结构性的。
8.4 边界之外还有什么
读到这里需要明确一件事：Qiita 不是唯一能回答「怎么算的」的地方。
在单细胞领域，CellxGene 与各大数据门户在处理元数据上做得更细；在宏基因组领域，MGnify 的版本化流水线在一致性上更彻底；在临床队列领域，EGA 与 dbGaP 的受控访问模型在隐私保护上更完备。
Qiita 的位置是特定的：它是少数把原始读段与逐步产物一起托管、同时把参数记录到 artifact 粒度的平台。这个位置不大，但很少有人占。
§9 使用指引
9.1 三种角色的最短路径
研究生角色： 先读下载页与应用场景文档，再跑通一次「按 study 下载 BIOM、读进 R 或 Python、算一次 alpha 多样性」。不要一上来就碰 redbiom 与 context。
元分析角色： 先看 context 说明页，再在 redbiom 里做三路检索，用检索结果生成候选样本清单，最后在 analysis 里合并。判断能不能合并的标准只有一个：context 是否一致。
工程角色： 先读 FAQ 的 artifact 定义与下载页的端点清单，把端点封装成函数，再处理并发限制。不要指望有 OpenAPI 文档。
9.2 一条最短的可用流程
#-- 最小可用示例：读取 Qiita 的 BIOM 并核对样本数与特征数
#-- 依赖：pip install biom-format pandas
#-- 输入：从 public_download 端点取回的 zip，解包后位于 ./qiita_dump 下
import glob
import biom
import pandas as pd
root = "./qiita_dump"
tables = sorted(glob.glob(f"{root}/BIOM/*/*.biom"))
if not tables:
raise SystemExit("未找到 BIOM 文件，先确认 zip 已解包到 ./qiita_dump")
table = biom.load_table(tables[0])
print("artifact 文件:", tables[0])
print("样本数:", table.shape[1])
print("特征数:", table.shape[0])
print("样本表前五行:", table.ids(axis="sample")[:5].tolist())
#-- 判断是否为相对丰度：求和接近 1 是已归一，接近整数是计数
counts = pd.Series(table.sum(axis="sample"))
print("每个样本特征计数和的中位数:", int(counts.median()))
四个输出里最值得看的是最后一个。计数和如果是整数且量级在几千到几万，说明这是原始计数表，需要自己决定是否抽平；如果接近 1，说明表已被归一。这一步能挡掉很多「以为拿到的是计数、其实是相对丰度」的错误。
9.3 引用方式
官方给出的引用格式是：Gonzalez A, Navas-Molina JA, Kosciolek T, McDonald D, Vázquez-Baeza Y, 等. Qiita: rapid, web-enabled microbiome meta-analysis. Nature Methods, 2018, 15: 796–798. DOI 10.1038/s41592-018-0141-9。
使用具体数据时，除平台引用外还应引用对应 study 的原始论文，并在方法中写明 artifact id。只写 study id 不足以定位到具体那份表。
§10 AI 使用声明
本文由人工核验与语言模型协作完成，分工如下。分工的意义在于把可核验的部分与需要判断的部分分开：凡是能从站点页面直接读到的，交给自动抓取并留下时间戳；凡是涉及口径取舍的，一律标出并说明依据。
| 环节 | 谁做的 | 具体内容 | 需要复核什么 |
|---|---|---|---|
| 站点探测 | 模型执行 | 对主域、旧域名、文档页各发请求 | 旧域名是否仍未恢复 |
| 文档抓取 | 模型执行 | 逐页读取下载、FAQ、术语表、redbiom、context、处理推荐、哲学页 | 页面是否随版本更新 |
| 规模数字 | 模型执行 | 读取统计页并记录页脚生成时间 | 数字每日变动 |
| 论文信息 | 模型执行 | 按 DOI 核对刊名、卷、页、作者数 | 引用格式是否需按投稿要求调整 |
| 正文写作 | 模型起草 | 结构、概念解释、评分、流程 | 与所在领域的实际经验是否相符 |
| 事实判断 | 人工 | 哪些数字入正文、哪些只写定性 | 是否存在过度解读 |
未做的事一并声明：没有下载任何完整的 study 包，没有重跑任何 processing，没有验证任一 artifact id 的真实内容，没有对 891 项公开研究逐条核对元数据。
常见误读（避坑清单）
| 常见说法 | 实际 | 证据 |
|---|---|---|
| Qiita 是日本的技术文章社区 | 同一个名字，两个不同实体；本站点读作 cheetah | 首页写明 canonically pronounced cheetah |
| 旧地址 qiita.microbio.me 是备用入口 | 域名不再解析，请求超时无响应 | 2026-10-29 探测返回连接失败 |
| 下载全部公开 BIOM 的包就是全库 | 只含各 study 的 processed BIOM，不含 analysis 阶段产物 | 下载页在注中写明排除 analysis 的 BIOM |
| 库内 BIOM 都是统一重处理的 | 各 study 各自 processing，参数不同 | 处理推荐页按研究类型给不同插件与参数 |
| artifact 多说明数据多 | artifact 是派生物，同一批 FASTQ 可派生多份 | FAQ 的 artifact 定义 |
| 按数据类型相加等于唯一样本数 | 唯一样本去重，模态列不去重 | 统计页两栏分列 |
| 公开就一定能匿名下载原始读段 | 需 owner 勾选允许下载原始文件 | 下载页第一段写明该开关 |
| 可见度只有三档 | 面向使用者是三档，状态机有五态 | 哲学页正文三态、图注五态 |
| deblur 表与闭参考 OTU 表可以互换 | 两者并列，特征定义方式根本不同 | 处理推荐页两条路分别说明 |
| 参考命中表是通用过滤结果 | 只保留与 Greengenes 相似度达 80% 的序列，官方称其朴素 | 处理推荐页原文 |
| 私有研究可以随便删 | 已公开的研究不可撤回 | FAQ 写明仅未公开者可永久删除 |
| 名字和日本社区混用无碍检索 | 检索会被同名内容淹没 | 首页读音说明与域名区分 |
FAQ
Q1：Qiita 与 QIIME 2 是同一个东西吗？
不是。QIIME 2 是分析工具包，在本机或集群上跑；Qiita 是把数据、处理步骤与结果都托管起来的平台。Qiita 内部调用 QIIME 1.9.1 的拆分与质控、deblur 与闭参考聚类，artifact 也能按对照表转成 QIIME 2 的 QZA。
Q2：Qiita 的名字怎么读？
站点首页明确写 canonically pronounced cheetah，按猎豹的音来读。它和日本同名的技术文章社区没有任何关系。
Q3：我只要丰度表，为什么还要来这里？
如果你的问题只需要一版统一重处理的相对丰度表，curatedMetagenomicData 更省事。Qiita 的价值在于表可以一路回溯到 deblur 的参数和原始 FASTQ，评审问起时能给出路径。
Q4：为什么每个 study 的表不能直接拼？
因为 processing 参数不同。截断长度、去噪算法、参考库版本任何一项不一致，同一物种在两份表里的计数就没有共同分母。拼接前必须把样本限定在同一 context 内。
Q5：EMP 与 American Gut 的数据在哪里？
在 Qiita 上。EMP 的样本用 emp_release 字段区分批次，AGP 的样本在库内可以按研究名与元数据检索。两者的原始读段同步提交 ENA，Qiita 侧保存的是带处理链的 artifact。
Q6：redbiom 是独立数据库吗？
不是。它是 Qiita 的一个缓存服务，存一份稀疏的 metadata 副本用于快速检索，检索到的样本仍要回到 Qiita 取。它也能单独安装成命令行工具，功能比插件版更全。
Q7：不同年份处理的同一 study 结果能比吗？
不能直接比。宿主过滤的参考库从 GRCh38.p7 换到 T2T-CHM13v2.0，中间还叠过 Movi 与泛基因组参考。跨年比较前必须先确认两版 BIOM 的 processing 参数。
Q8：许可到底是什么？
BSD 3-Clause。软件、插件、站点下载的原始数据、处理后数据与元数据统一到这一个许可。原始研究若另有限制，以 ENA 记录与原文为准。
术语表
| 术语 | 释义 |
|---|---|
| artifact | 一组文件及其摘要，代表某条处理或分析命令的输入或输出；Qiita 的原子单位 |
| prep | preparation，湿实验与建库单位；同一样本在不同 prep 下各出现一次 |
| processing | 一次处理链的实例，记录插件、版本与参数 |
| analysis | 跨 study 或跨 prep 的分析容器，输出新的 artifact |
| context | 分箱策略、参考库、平台、测序区、截断长度与编号的压缩表示 |
| deblur | 去噪得到确切序列的方法，Qiita 中标为优先路线 |
| 闭参考聚类 | 只与参考库比对的 OTU 聚类，未命中者丢弃 |
| EMPO | Earth Microbiome Project Ontology，环境分层本体 |
| redbiom | Qiita 的检索缓存服务，可按 metadata、feature、taxon 检索 |
| biom | 特征表的标准格式，记录样本乘特征的计数矩阵 |
| QZA / QZV | QIIME 2 的两种封装，前者是分析产物，后者是可视化 |
| sandbox | 上传后的默认可见度，可在系统内使用，外人不可见 |
| awaiting_approval | 申请公开后、管理员核验中的中间状态 |
| archived | 算法更新后旧 BIOM 的长期保存状态 |
| split libraries | 去复用与质控步骤，Qiita 中沿用 QIIME 1.9.1 默认参数 |
附录 A：核心数字核对表
| 项 | 值 | 来源 | 来源层级 |
|---|---|---|---|
| 公开研究数 | 891 | 统计页 | 官方动态 |
| 私有研究数 | 176 | 统计页 | 官方动态 |
| 沙箱研究数 | 3,000 | 统计页 | 官方动态 |
| 唯一公开样本 | 438,595 | 统计页 | 官方动态 |
| 唯一私有样本 | 118,389 | 统计页 | 官方动态 |
| 唯一沙箱样本 | 663,630 | 统计页 | 官方动态 |
| 已提交 EBI 样本 | 390,512 | 统计页 | 官方动态 |
| 已提交 EBI 按 prep 计 | 454,883 | 统计页 | 官方动态 |
| 16S 公开样本 | 389,616 | 统计页 | 官方动态 |
| 宏基因组公开样本 | 105,808 | 统计页 | 官方动态 |
| 宏转录组公开样本 | 27,161 | 统计页 | 官方动态 |
| ITS 公开样本 | 15,550 | 统计页 | 官方动态 |
| 18S 公开样本 | 12,149 | 统计页 | 官方动态 |
| 代谢组公开样本 | 1,545 | 统计页 | 官方动态 |
| 基因组分离株公开样本 | 1,505 | 统计页 | 官方动态 |
| 全长操纵子公开样本 | 803 | 统计页 | 官方动态 |
| 注册用户 | 17,482 | 统计页 | 官方动态 |
| 累计作业 | 939,259 | 统计页 | 官方动态 |
| 当前版本 | 2026.01 | 页脚与文档标题 | 官方静态 |
| 构建号 | 3b390e0 | 页脚 | 官方静态 |
| 旗舰论文 DOI | 10.1038/s41592-018-0141-9 | 论文与 FAQ | 论文 |
| 论文卷期页 | 15 卷 796 至 798 | Crossref | 论文 |
| 论文作者数 | 23 | Crossref | 论文 |
| 提交 ENA 元数据上限 | 10M | FAQ | 官方静态 |
| 单 prep 样本上限 | 800 | FAQ | 官方静态 |
| 许可 | BSD 3-Clause | FAQ 许可段 | 官方静态 |
附录 B：数字的来源分层
第一层，统计页。 研究数、样本数、模态计数、用户数与作业数。这些数字每次访问动态生成，页脚给生成时间，跨日引用必须带日期。重跑方法就是再访问一次统计页，抄下页脚时间。
第二层，文档静态值。 版本号、构建号、许可、提交上限、单 prep 样本上限、deblur 与闭参考的具体工具与参考库、宿主过滤的历史版本表。这些值随发布变更，但两次发布之间稳定。
第三层，论文。 只有 DOI、卷期页与作者数，以及论文对平台能力的定性描述。论文里没有任何一个本文引用的规模数字。
第四层，未核实。 资助编号、运维人员规模、每年新增 artifact 数、下载端点的速率限制、历史 artifact 的具体软件版本。这些要么需要后台，要么需要长期观测，本文一律只作定性描述。
附录 C：完整参考文献
| 编号 | 文献 | 标识 | 用途 |
|---|---|---|---|
| 1 | Gonzalez A 等. Qiita: rapid, web-enabled microbiome meta-analysis. Nature Methods, 2018 | 10.1038/s41592-018-0141-9 | 平台设计与定位 |
| 2 | Qiita 文档站 qiita 2026.01 | qiita.ucsd.edu/static/doc/html/ | 概念、处理、下载、FAQ |
| 3 | Qiita 统计页 | qiita.ucsd.edu/stats/ | 全部规模数字 |
| 4 | redbiom 说明页 | qiita.ucsd.edu/static/doc/html/redbiom.html | 检索语法与缓存定位 |
| 5 | context 说明页 | qiita.ucsd.edu/static/doc/html/reanalysis/understanding-contexts.html | context 语法与偏倚 |
| 6 | Qiita 代码仓库 | github.com/biocore/qiita | 开源状态与许可 |
附录 D：任务代码
#-- 步骤一：抓统计页并保存，用于留存当日口径
python3.11 -c "import urllib.request,pathlib,time;t=urllib.request.urlopen('https://qiita.ucsd.edu/stats/').read().decode('utf-8','ignore');pathlib.Path('qiita_stats_'+time.strftime('%Y%m%d')+'.html').write_text(t)"
#-- 步骤二：从留存页面里抽出规模字段，确认与本文附录 A 一致
python3.11 -c "import re,glob;t=open(sorted(glob.glob('qiita_stats_*.html'))[-1]).read();p=re.sub(r'<[^>]+>',' ',t);p=re.sub(r'\s+',' ',p);m=re.search(r'public : (\d+).*?submitted to EBI : (\d+)',p);print('公开研究/公开样本:',m.groups() if m else '结构变化，需重写正则')"
#-- 步骤三：确认旧域名是否恢复（返回非零即未恢复）
curl -s -o /dev/null -w "%{http_code}\n" -m 10 https://qiita.microbio.me/ || echo "旧域名无响应，符合本文判断"
第二段的正则依赖页面文字顺序，站点改版即失效，这是这类抓取脚本的常态。第三段在本文核验时的输出为无响应。
附录 E：如果只记五件事
- 它的单位是 artifact，不是数据集。 引用时绑定 artifact id，只写 study id 无法定位到那张表。
- 它不提供统一重处理。 要统一表去 curatedMetagenomicData，要统一流水线去 MGnify，要溯源回来。
- context 一致才能合并。 五段语法对应五个决策，任何一段不同，两份表就没有共同分母。
- 旧域名已失效。 文档里的 microbio.me 一律替换成 ucsd.edu。
- 它是研究基础设施，不是公共服务。 能持续是因为实验室自己的工作需要它，不要期待企业级 SLA。
编辑说明
核验时间 2026 年 10 月 29 日。核验方式：对主域、下载页、FAQ、术语表、redbiom、context、处理推荐、哲学页、入门指南各做一次抓取并通读正文；对统计页抓取一次，记录页脚生成时间 10-28-26 02:09:20；对旧域名发一次请求，无响应；对 public_download 与 public_artifact_download 两个端点各做一次探测，前者首次连接可通、重复请求时后端挂起，后者对无效 id 返回 404，属预期行为；按 DOI 经 Crossref 核对论文刊名、卷、页与作者数。
未覆盖的内容：没有下载任何完整 study 包，没有重跑任何 processing，没有逐条验证 artifact id，没有核对资助信息，没有核对 ENA 侧同源项目的逐项对应关系。
两处口径冲突已如实记录，正文未作取舍：其一，可见度状态在哲学页正文写作三态、图注写作五态，本文按五态理解并注明简化口径；其二，哲学页给出的三个门户地址中，主站地址与实际在用地址不一致，本文以实际在用地址为准并在 §4.3 点明。
规模数字全部来自统计页单次快照，属动态数据；引用时须带日期。论文不承载任何规模数字，本文未做此等归因。
体例要求移出正文的元话语与重复口径说明集中于本区。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- hmp — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- mgnify — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- curatedmetagenomicdata — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- american-gut-project — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- metasub — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- human-microbiome-project — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- cami2 — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- ckm-gut-metagenome — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- nmdc — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
- uhgg — 共享标签：基因组学与多组学 / 测序数据 / 微生物组
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
