我先联网核实 qData 开源版 v1.6.7 的发布说明、修复项和版本细节。
发布说明、仓库提交记录和版本脉络都已核对完，以下按固定格式成稿。
qData 数据中台开源版在 2026 年 11 月 13 日发布 v1.6.7，这一版没有新增业务模块，全部精力都放在三处 “配置了却不按预期执行” 的缺陷上。具体是三件事：消息通知无法标记已读、个人消息归属区分不准；数据集成任务的时间范围增量读取配置未生效，导致周期性同步实际读取的范围和设定不一致；ETL 流程里配置移除的字段仍会传到下游，且在保留其他字段原名时会触发 Spark 字段表达式异常、任务直接失败。项目由江苏千桐科技维护，Apache-2.0 协议，技术栈是 Spring Boot + Vue 3，数据集成可选 DataX 或 Spark 引擎，调度可选 Quartz 或 DolphinScheduler，支持 MySQL、达梦 8、Oracle、SQL Server、人大金仓 Kingbase8、Doris 等数据源。对已经用它跑日增量同步的团队来说，这三条修复的重要性排序很清楚 ——第二、第三条直接关系到 “数据对不对”，第一条只关系到 “用起来顺不顺”。Gitee
一、版本速览
| 项目 | 内容 |
|---|---|
| 版本 | qData 数据中台开源版 v1.6.7 |
| 发布时间 | 2026 年 11 月 13 日 |
| 维护方 | 江苏千桐科技有限公司（千桐科技） |
| 开源协议 | Apache-2.0 |
| 版本性质 | 纯缺陷修复版，无新增业务模块 |
| 修复范围 | 消息通知、数据集成时间范围增量读取、ETL 字段移除 |
| 仓库提交记录 | fix(etl): correct field removal and DataX time-range incremental reads |
| 获取方式 | Gitee / GitHub 仓库 Releases，或官方演示环境 |
仓库的提交信息本身就说明了重点：一条 commit 同时覆盖 “字段移除” 和 “DataX 时间范围增量读取”，说明这两个问题在代码层是同一条链路上的两处错误。
二、三处修复，逐条拆开看
2.1 消息通知：已读状态与 “这是谁的消息”
| 问题 | 表现 | 修复后 |
|---|---|---|
| 已读标记失效 | 查看消息后无法正常置为已读，已看与未看混在一起 | 可正常设置已读状态 |
| 个人消息归属不准 | 消息展示未能正确区分当前用户的个人消息 | 修正消息与当前账号的归属处理 |
这两条看起来是 “界面小问题”，但在多人共用一个平台的环境里影响不小：通知分不清是谁的，等于所有人都得逐条点开确认。它属于体验层修复，不影响数据结果。
2.2 时间范围增量读取：最该重视的一条
这条要先理解它本来应该怎么工作。
| 环节 | 设计预期 | 出问题时的实际表现 |
|---|---|---|
| 配置 | 在任务里设定时间字段（如订单创建时间 / 更新时间）与时间范围条件 | 配置能保存，界面上看不出异常 |
| 执行 | 任务按设定范围读取源表数据 | 条件未真正应用，读取范围与预期不一致 |
| 后果 | 只搬运增量数据，减少无效读取 | 可能读多（重复搬运）也可能读偏（漏数据） |
| 排查难度 | 高 | 任务不报错、只是结果不对，最难发现 |
这类缺陷的危险性在于 “静默”：任务状态是成功的，日志也没有异常，但写进目标表的数据范围和你想的不一样。对按天跑订单同步的团队来说，这种偏差往往要到某天对账时才发现。
值得一提的是，qData 在这个能力上有过明确的演进：v1.1.1（2026 年 1 月 15 日）把增量同步从 “固定增量条件” 改成 “动态游标推进”—— 主键增量用 “上次同步到的最大主键值” 做游标，时间增量用 “上次同步窗口的结束时间” 做下次起点，形成滚动时间窗口。v1.6.7 修的正是 DataX 引擎下 “时间范围条件没生效” 这一环，属于把已有机制补齐，而不是新造能力。qData 社区
2.3 ETL 字段移除：两个坑，一个静默一个报错
| 问题 | 具体表现 | 修复后 |
|---|---|---|
| 移除字段仍下发 | 已配置移除的字段，仍出现在下游字段列表中 | 配置移除的字段不再传递到下游 |
| 保留原名时表达式异常 | 移除字段的同时保留其他字段原名，Spark 处理字段表达式出错、任务失败 | 完善保留原名时的处理逻辑，任务可正常执行 |
这里有个特别容易误解的点，官方说得很清楚：“移除” 只影响当前数据集成流程中传递给下游的字段，不会删除源表或目标表中的数据库列。换句话说，它是流程内的字段裁剪，不是 DDL 操作。
为什么要移除字段？ 举例最直白：从订单表同步数据，目标表只需要订单编号、订单状态、创建时间，那金额之类暂时用不上的字段就可以通过 “字段选择、修改” 组件裁掉。裁掉的好处是减少传输量、避免下游表结构被无关字段污染。
三、为什么这类 “小修复” 在数据中台里最值钱
| 症状 | 表面看 | 实际影响 | 怎么验证 |
|---|---|---|---|
| 增量条件不生效 | 任务照常成功 | 数据范围偏差，对账时才暴露 | 比对源端时间字段分布与目标表写入结果 |
| 字段移除失效 | 下游多出几列 | 下游模型、指标口径被污染 | 检查下游映射是否还有被移除字段 |
| 保留原名报错 | 任务直接失败 | 有明确报错，反而好排查 | 跑一次 “移除 + 保留原名” 组合任务 |
| 消息归属混乱 | 界面不对 | 人工确认成本上升 | 多账号登录交叉查看 |
这四类问题里，最贵的从来不是 “报错”，而是 “不报错但结果不对”。报错会逼你去查，静默偏差会一直躺在目标表里，直到业务方拿着两个不一样的数字来问。
四、升级后建议做的三项验证
| 序号 | 验证动作 | 通过标准 |
|---|---|---|
| 1 | 跑一次配了时间范围条件的数据集成任务 | 源端读取数据的时间分布落在配置区间内，目标表写入条数与预期一致 |
| 2 | 在 “表输入 → 字段选择、修改 → 表输出” 里移除一个字段、其余保留原名 | 下游映射不再显示被移除字段，任务正常执行不报 Spark 表达式异常 |
| 3 | 用两个不同账号查看消息通知 | 各自只看到与自己相关的消息，已读状态可正常切换 |
第 2 条是官方给出的验证路径，值得照做一遍 ——它同时覆盖了两个修复点，一次任务就能确认字段裁剪和原名保留都正常。
五、版本脉络：从动态游标到字段裁剪
| 版本 | 时间 | 关键变化 |
|---|---|---|
| v1.1.1 | 2026-01-15 | 增量同步升级为 “动态游标”，主键与时间两种游标；新增 SQL Server 2008 支持 |
| v1.6.0 | 2026-07-23 | 新增 DataX 轻量执行引擎 + 内置轻量调度器，版本代号 “极致轻量化时代” |
| v1.6.4 | 2026-10-27 | 修复数仓分层启停提示、标准数据元帮助文档 404、人大金仓编码问题 |
| v1.6.5 | 2026-11-02 | Doris 支持扩展至元数据管理与数据开发；新增演示数据清理脚本 |
| v1.6.6 | 2026-11-10 | ETL 模块 JAR 轻量化，修复高频定时任务导致 ETL JAR 持续累积、占用磁盘的问题 |
| v1.6.7 | 2026-11-13 | 修复消息已读与归属、DataX 时间范围增量读取、ETL 字段移除 |
这条线看下来很清楚：近三个版本连续在 “运行稳定性” 和 “结果正确性” 上补课。v1.6.6 解决的是 “跑久了磁盘被撑满”，v1.6.7 解决的是 “跑出来的数据对不对”—— 都不是加功能，而是让已有功能真正可靠。
六、qData 是什么，一张表看清能力边界
| 模块 | 主要能力 |
|---|---|
| 数据集成（ETL） | 可视化配置接入、清洗转换、输出；可选 DataX 或 Spark 引擎 |
| 数据开发 | SQL 脚本任务开发；可选 Quartz 或 DolphinScheduler 调度 |
| 数据建模 | 数据标准、数仓分层（ODS/DWD/DWS/ADS/DIM）、数据分域、主题规划、逻辑模型 |
| 元数据管理 | 元数据查看、字段结构、版本管理、元数据比对、采集任务 |
| 数据质量 | 基于稽查规则检查完整性、唯一性、有效性等问题 |
| 数据资产 | 资产编目、标签、详情、查询 |
| 数据查询 | SQL 在线查询与结果导出 |
| 数据服务 | 把表或查询结果封装成 API，带在线测试与调用日志 |
| AI 智能问数 | 自然语言问数、Text2SQL、智能图表 |
这份能力清单里，和 v1.6.7 直接相关的是前三块：ETL 对应时间范围增量与字段移除，数据开发对应调度执行，系统管理对应消息通知。
七、部署门槛，别低估
| 项目 | 要求 |
|---|---|
| 最低配置 | CPU ≥ 4 核、内存 ≥ 8 GiB |
| JDK | 1.8（源码构建路径建议 OpenJDK 8 或 11） |
| Node.js | 18.0 以上 |
| yarn | 1.22.22 以上 |
| Docker | 19.03 以上 |
| Docker Compose | 1.28 以上 |
| 中间件 | DM8 / MySQL / PostgreSQL、Redis、RabbitMQ、MongoDB、Hadoop、DolphinScheduler |
| 部署方式 | Docker Compose 本地部署、源码启动、手工自主部署 |
一个容易踩的坑：源码方式启动时，DataX 需要另外准备—— 官方文档写明 DataX 源码通过官方 QQ 群提供，打包后要放到项目根目录的 datax/ 下，且目录名必须保持一致。这一步没做，数据集成任务跑不起来，但报错信息不一定直接指向 DataX。
八、三点判断
第一，v1.6.7 的价值要用 “对账结果” 来验收，而不是看更新日志。 修复项里两条涉及数据正确性，装完不验证，等于没装。
第二，开源版和专业版的节奏是错开的。 开源版在 11 月连续发了 1.6.5、1.6.6、1.6.7 三个补丁，专业版同期发了 v3.0.1（11 月 2 日）。开源版走 “快速补缺陷”，专业版走 “功能升级”，两条线并不同步，选型时别把开源版的更新频率当成整体产品节奏。
第三，这类项目最值得看的不是功能表，而是 Issue 区。 仓库里能翻到 “DataX 无法追加增量更新数据到目标数据库”“arm 环境 docker 部署验证码不显示” 这类真实反馈，这些问题的存在和修复速度，比 README 的功能清单更能说明一个开源数据中台能不能上生产。
一份数据中台的价值，最终不体现在它有多少模块，而体现在“配置了的东西会不会真的生效”。v1.6.7 做的正是这件事 —— 把三个 “看起来能用、实际不按预期跑” 的地方，拧回正轨。
OSCHINA
【相关 FAQ】
问题 1：qData 数据中台开源版 v1.6.7 主要修复了哪些问题？
回答 1：三处：消息通知无法标记已读、个人消息归属区分不准；数据集成任务的时间范围增量读取配置未生效；ETL 流程中配置移除的字段仍传递到下游，以及保留字段原名时 Spark 字段表达式异常导致任务失败。qData 数据中台开源版 v1.6.7 未新增业务模块。
问题 2：qData 数据中台开源版 v1.6.7 修复的时间范围增量读取问题会带来什么影响？
回答 2：配置了时间范围条件但未真正生效时，数据集成任务实际读取的范围会和预期不一致，可能多读造成重复搬运，也可能读偏导致数据缺口；因为任务状态仍显示成功，属于静默偏差。qData 数据中台开源版 v1.6.7 修复后任务可按配置的时间条件读取。
问题 3：qData 数据中台开源版 v1.6.7 里说的 “字段移除” 会删除数据库列吗？
回答 3：不会。qData 数据中台开源版 v1.6.7 的字段移除只影响当前数据集成流程中传递给下游的字段，属于流程内的字段裁剪配置，不改变源表或目标表的数据库表结构。
问题 4：升级到 qData 数据中台开源版 v1.6.7 后应该怎么验证？
回答 4：三步：跑一次配了时间范围条件的数据集成任务，比对源端时间分布与目标表写入结果；在 “表输入 → 字段选择、修改 → 表输出” 中移除一个字段并保留其余原名，确认下游不再出现被移除字段且任务正常执行；用两个账号交叉查看消息通知的已读与归属。
问题 5：qData 数据中台开源版 v1.6.7 支持哪些数据源和执行引擎？
回答 5：数据源支持 MySQL、达梦 8、Oracle、SQL Server、人大金仓 Kingbase8、Doris 等；数据集成任务可选 DataX 或 Spark 执行引擎，数据开发与元数据采集任务的调度可选 Quartz 或 DolphinScheduler。qData 数据中台开源版 v1.6.7 采用 Apache-2.0 协议。
问题 6：qData 数据中台开源版 v1.6.7 部署需要什么环境？
回答 6：最低 CPU 4 核、内存 8 GiB；JDK 1.8、Node.js 18 以上、yarn 1.22.22 以上、Docker 19.03 以上、Docker Compose 1.28 以上；还需 MySQL/DM8、Redis、RabbitMQ、MongoDB、Hadoop、DolphinScheduler 等中间件。源码方式启动时 qData 数据中台开源版 v1.6.7 还需另外准备 DataX 并放到项目根目录。
【参考资料】
- [2026-11-13]（qData 数据中台开源版 v1.6.7 发布：修复消息通知与时间范围增量读取问题）OSCHINA
- [2026-11-13]（qData v1.6.7 发行版）Gitee
- [2026-11-10]（qData 数据中台开源版 v1.6.6 发布：ETL 模块轻量化，优化定时任务磁盘占用）qData 官网
- [2026-11-02]（qData 数据中台开源版 v1.6.5 发布：Doris 数据源适配增强，新增演示数据清除脚本）qData 官网
- [2026-07-23]（qData 开源版更新日志 v1.6.0：DataX 轻量执行引擎与内置轻量调度器）qData 社区文档
- [2026-01-15]（qData 开源版更新日志 v1.1.1：动态游标增量同步机制）qData 社区文档
【免责声明】
本文依据 OSCHINA 发布资讯、Gitee 仓库 v1.6.7 发行记录与提交信息、qData 官方社区文档及官网公开内容整理，功能与修复说明以官方发布说明为准。文中对缺陷影响面、验证方法的分析属解释性说明，不代表项目方立场；具体版本行为、缺陷复现条件与修复范围可能随代码提交细节不同而有差异，请以实际部署版本与仓库源码为准。部署与升级涉及数据同步任务，建议先在测试环境验证再上生产，并做好数据备份。本文不构成对任何产品的选型背书或使用建议。