PAYATHON 2026

DDF 2.26.45 使用外部 Solr 时如何排查 GeoJSON 入库失败？

数据小陈

结论

现有日志无法确定 DDF 2.26.45 外部 Solr 部署需要哪些 core、configset 或 schema.xml。日志可以确认两点：DDF 请求按 id_txt 排序，而当前 Solr schema 将该字段定义为多值 text_general，因此 Solr 拒绝了请求。alerts 请求失败可以解释管理界面为何持续显示告警，但不能据此认定它导致了 GeoJSON 入库失败。

DDF 2.26.17 的文档提到 catalog 和 metacard_cache 两个 core，但那是在介绍同义词配置，并未列出外部 Solr 所需的全部 core。文档中的快速安装方式使用预配置的 Solr，也没有提供外部 Solr 各 core 的 schema.xml 示例。因此，仅凭这些信息，无法断定只配置 alerts 就够用，也不宜直接给出未经核对的 schema 配置。DDF 2.26 文档 DDF 快速入门

先核对 core 和连接配置

  1. 在 DDF 配置中分别确认 catalog provider 和 persistence/alerts 使用的 Solr URL 与 core 名称。日志显示，alerts 查询发往 http://localhost:8983/solr/alerts，但这不能说明 catalog ingest 也使用同一个 core。
  2. 查看外部 Solr 的 core 列表，并与该 DDF 发行版自带的 Solr 配置逐项核对。至少确认 catalog、metacard_cache 是否被相应功能使用，再从 DDF 2.26.45 的实际配置中确认 alerts/persistence 使用的 core 或存储配置。不要直接把这些名称视为完整清单。
  3. 确认外部 Solr 的版本兼容性，以及 schema/configset 的来源。DDF 文档说明，默认发行版包含与 DDF 集成的 Solr 组件。HTTP 连接成功，并不能证明任意 Solr 版本或默认 configset 都兼容。DDF Solr 配置说明

处理 id_txt 排序异常

报错指出，id_txt 是多值 text_general 字段，却被用于排序。先检查 alerts core 的实际 schema 和触发排序的查询，再根据该 Solr 版本的要求调整字段定义，或让查询使用合适的排序字段。不要未经核实就把 id_txt 改成单值字段，这可能影响其他写入或查询。

字段 schema 决定 Solr 能否按该字段排序。text_general 用于文本分析，字段名是 id_txt 并不能说明它适合作为排序键。应以 DDF 2.26.45 中该 core 的实际 schema 和查询参数为准。Solr 字段与排序文档 Solr 查询参数文档

修正配置后，重新加载对应 core 或重启 Solr，并检查 ddf.log 中是否还出现 can not sort on multivalued field: id_txt。如果 core 中已有数据，修改 schema 前还需确认是否要重建索引；现有材料无法判断这一点。

单独定位 GeoJSON 入库失败

service:list 中能看到 GeoJSON transformer，只能说明 DDF 中存在该服务，不能证明文件已成功解析或写入 catalog。ingest_error.log 只记录了失败数量，没有说明原因。还需查看同一时间段内更完整的 DDF 日志和 catalog Solr 日志，并确认 catalog provider 指向的 core、该 core 的 schema 与 DDF 配置是否相符。

核对 core 和 schema 后，再执行原始命令：

catalog:ingest -t geojson /tmp/test-location.geojson

如果仍然失败，可根据新日志判断问题来自文件解析、目标 core 不可用、schema 拒绝字段，还是 catalog provider 配置。目前的信息无法证明 GeoJSON 入库失败与 alerts core 的排序错误有关，也不足以提供可靠的特定 schema.xml 示例。

备注：内容仅供参考。