qData数据中台专业版V2.6.0发布：血缘全链路再升级，在线接口测试与帮助中心正式上线

silent_sigma

qData数据中台专业版V2.6.0围绕数据血缘、数据集成、数据开发、数据服务、整库同步、数据连接等核心能力进行调整，同时新增在线接口测试、数据源诊断和帮助中心，扩展多类数据源适配，并进一步优化任务日志、作业管理、数据标准及全局交互能力。

--------------------------------
从“能接、能算、能用”，进一步走向可追踪、可调试、可排查

企业数据中台真正进入持续使用阶段后，日常工作往往已经不再只是“把数据接进来”。

一条数据从业务系统进入平台，到最终提供给业务使用，通常需要经历：

数据源连接 → 数据同步 / 集成 → 数据开发 → 数据加工 → 数据服务 → 接口调用

而在这条链路之外，还伴随着另一条研发和运维链路：

连接是否正常 → 任务如何运行 → 日志在哪里查看 → 数据从哪里来 → 下游被谁使用 → 接口是否可用 → 出现异常如何定位

当数据源、任务和数据服务数量持续增加后，企业面对的问题也会逐渐从“功能有没有”，转向“不同能力之间能否衔接起来”。

例如：

•
一张表虽然已经同步进入平台，但能否看到具体由哪个整库同步任务产生？

•
数据已经通过API提供给业务系统，但能否继续向上追踪API依赖的数据来源？

•
Flink、Spark等开发任务越来越多时，离线与实时任务如何分类管理？

•
接口开发完成之后，是否还需要离开平台借助其他工具完成请求调试？

•
数据连接失败时，究竟是地址、端口、账号还是权限问题？

•
任务异常后，开发人员能否快速从日志中判断执行阶段和异常位置？



因此，qData V2.6.0并不是围绕某一个独立模块进行单点增强，而是继续补充数据从接入、加工、开发到服务应用过程中的可管理性、可追踪性与可调试性。

--------------------------------
01 数据血缘继续向两端延伸：补齐整库同步与数据服务节点

企业数据链路往往不是简单的：

源表 → 目标表

实际上，在源表和目标表之间存在具体的数据处理任务；而数据形成结果表之后，也并不意味着链路已经结束，很多数据还会继续通过数据服务接口向其他系统提供。

因此，一条更接近实际的数据链路可能是：

源表 → 整库同步任务 → 目标表 → 后续数据加工 → 数据服务 → 业务系统

qData V2.6.0进一步扩展数据血缘覆盖范围，将整库同步任务和数据服务节点纳入血缘体系。

--------------------------------
新增整库同步血缘，看见“数据通过什么任务进入平台”

整库同步是企业建设ODS层、开展数据库迁移和多系统数据汇聚时常见的数据接入方式。

过去如果血缘只展示：

源表 → 目标表

开发人员虽然能够确认两张表之间存在关系，但仍然缺少一个重要信息：

具体是哪一个整库同步任务完成了这次数据传输？

qData V2.6.0将整库同步任务作为独立血缘节点，支持展示：

源表 → 整库同步任务 → 目标表

这意味着数据接入阶段不再只体现表与表之间的逻辑关系，还可以进一步还原实际承担数据同步的任务节点。




--------------------------------
整库同步节点统一进入血缘分析体系

整库同步血缘并不是只增加一类图形节点。

qData专业版V2.6.0将整库同步节点进一步纳入：

•
血缘地图；

•
血缘维护；

•
来源分析；

•
影响分析。



在血缘地图中，可以查看源表、整库同步任务和目标表之间的完整链路。

在来源分析中，可以以整库同步任务为分析对象，继续向上查看数据来源及关联链路。

在影响分析中，也可以从整库同步节点向下查看可能涉及的目标数据和后续关系。

血缘维护则用于新增、查看和维护整库同步相关血缘关系。




对于企业来说，这类能力更适合用于数据问题追溯、同步任务梳理以及数据变更前的关系确认。

需要说明的是，血缘能够帮助开发和治理人员明确“关系在哪里”，但不能直接替代任务日志、SQL逻辑和数据质量分析。数据异常仍需要结合实际任务运行情况进一步判断。

--------------------------------
新增数据服务血缘，继续追踪数据“最终被谁使用”

数据加工完成之后，很多ADS结果表或业务数据还会继续通过数据服务提供给外部系统。

如果血缘只停留在数据表层面，数据团队能够知道一张结果表是如何形成的，却无法继续判断：

这张表最终支撑了哪些数据服务？

qData V2.6.0新增数据服务血缘，支持建立：

来源表 → 数据服务

之间的上下游关系。




数据服务节点可以进入血缘地图，并支持：

•
查看来源表与数据服务之间的上下游关系；

•
在血缘维护中新增、查看和维护数据服务关系；

•
以数据服务节点为起点进行来源分析；

•
向上查看接口所依赖的来源表及相关链路。



这样一来，血缘关系可以进一步从“数据如何形成”，延伸到“数据如何被服务使用”。

对于接口调整、数据源变更和服务依赖梳理，这类关系可以提供更直观的参考。

--------------------------------
02 重构数据集成与数据开发任务入口，区分离线与实时处理链路

当平台同时承载批处理任务和实时计算任务时，如果所有任务长期集中在同一入口，随着任务数量增加，管理成本也会随之上升。

离线任务和实时任务在执行方式、资源使用、故障排查和运维关注点上都存在差异。

因此，qData V2.6.0分别调整了数据集成和数据开发的菜单结构。

--------------------------------
数据集成拆分为离线任务与实时任务

V2.6.0将数据集成任务进一步拆分为：

•
离线任务






•
实时任务






两个独立入口。

其中，离线数据集成任务统一进入离线任务管理，实时数据集成任务统一进入实时任务管理。

这种调整本身不会改变数据处理逻辑，但能够让不同运行模式的任务拥有更加明确的管理入口。

对于同时存在批量同步、周期性ETL以及实时数据处理的企业环境来说，分类管理也更便于后续进行任务查找、运维和问题定位。

--------------------------------
数据开发同样区分离线与实时任务

数据开发侧采用相同思路。

V2.6.0将原有数据开发任务进一步拆分为：

•
离线开发任务；






•
实时开发任务。






不同类型任务分别进入对应管理入口。

从企业研发流程来看，这实际上是在进一步明确：

不同计算模式的任务，应进入与其运行方式相匹配的管理链路。

当任务数量较少时，这种区别可能并不明显；但随着项目规模增加、开发团队扩大，清晰的任务分类会逐渐成为研发和运维管理的一部分。

--------------------------------
03 调整Flink、Spark运行方式，并扩展数据开发适配范围

企业数据研发场景通常不会只依赖一种计算引擎。

关系型数据库SQL、Hive、Spark以及Flink可能同时存在于一套数据平台中，分别承担数据库加工、离线计算和实时计算任务。

V2.6.0继续调整数据开发的底层运行方式和数据源适配范围。

--------------------------------
Flink、Spark任务调整为集群模式运行

本次版本将：

•
Flink任务调整为集群模式运行；

•
Spark任务调整为集群模式运行；



并同步调整相关执行配置及运行方式。

这类变化更多属于执行架构层面的调整。

对于企业用户而言，实际使用时仍需要结合已有Flink、Spark集群资源、执行参数、资源容量以及平台部署架构完成配置。

平台运行模式的变化并不能替代企业自身对计算资源、队列、并发和容量的规划。

--------------------------------
数据开发新增达梦、ODPS和Hive适配

V2.6.0进一步完成多类数据源的数据开发能力验证，目前新增或完善：

•
达梦数据库数据开发；

•
ODPS数据开发；

•
Hive数据开发。



这意味着企业在国产数据库、云端大数据平台以及Hive数据仓库等不同环境中，可以进一步通过qData开展相应的数据开发任务。




对于同时存在传统关系型数据库、国产数据库、离线数据仓库和云数据平台的企业而言，多数据源开发能力能够减少不同技术体系之间的数据研发割裂。

具体可使用的SQL能力、权限范围以及计算资源，仍需结合对应数据库或数据平台本身的能力进行配置。

--------------------------------
关系型数据库数据开发新增血缘解析

除了扩展数据开发环境，本次版本还新增了关系型数据库数据开发的血缘支持。

平台可以解析关系型数据库数据开发任务产生的数据表上下游关系，并将相关血缘纳入统一血缘管理，在血缘地图中继续查看相应开发链路。

这样一来，血缘分析不再只围绕部分大数据计算任务展开，传统数据库中的数据开发关系也可以进一步进入统一视图。

--------------------------------
04 优化数据集成ETL架构和任务日志，让运行链路更容易维护和排查

数据平台长期运行后，除了功能数量，底层代码结构和运行日志同样会影响后续维护成本。

V2.6.0对数据集成ETL相关代码进行了进一步调整，包括精简冗余代码和处理逻辑、优化底层代码结构，并调整相关模块依赖关系。

这类调整主要作用于平台内部架构。

从使用层面来看，它并不会直接增加一个新的业务入口，但有助于减少ETL底层长期演进过程中形成的冗余逻辑，为后续组件维护和能力扩展提供更清晰的代码基础。

--------------------------------
数据开发日志进一步调整

任务执行失败时，开发人员通常最先关注：

任务在哪个阶段失败？

其次才是：

具体异常是什么？

因此，V2.6.0对数据开发任务执行日志进行了调整，包括：

•
优化日志展示内容；

•
优化任务执行状态展示；

•
优化异常信息展示；






•
调整不同执行阶段的日志输出和查看方式。






日志本身并不能自动完成故障诊断，但更加清晰的执行阶段和异常信息，可以减少开发人员从大量输出中寻找关键信息的成本。

--------------------------------
作业管理日志同步优化

除了数据开发任务，本次版本还同步调整了作业管理中的任务运行日志。

主要包括：

•
优化作业任务运行日志；

•
调整日志展示内容；






•
优化任务执行状态和异常信息；

•
统一相关任务日志展示方式。






当企业逐渐形成由多个任务组成的作业编排后，问题排查不再只关注某一个SQL任务，而需要从作业整体运行链路中确认异常节点。

统一日志展示方式，可以让不同任务之间的排查方式保持相对一致。

--------------------------------
05 数据服务新增在线接口测试，从“发布接口”延伸到“直接调试接口”

数据服务是数据中台连接业务应用的重要出口。

过去，数据接口完成配置或发布之后，开发人员往往还需要借助Postman等外部工具进行：

•
请求参数配置；

•
鉴权信息填写；

•
接口调用；

•
返回结果查看；

•
状态码和耗时分析。



当接口数量不断增加时，接口配置与接口验证分处不同工具，也会增加上下文切换成本。

因此，qData V2.6.0新增数据服务在线接口测试能力。




--------------------------------
支持多种HTTP请求方式

在线接口测试支持直接选择数据服务接口进行调试，并配置请求地址发送请求。

当前支持：

•
GET；

•
POST；

•
PUT；

•
PATCH；

•
DELETE；

•
HEAD；

•
OPTIONS。



覆盖常见HTTP请求方式。

这意味着从数据服务配置到基础接口验证，可以继续在平台内部完成。




--------------------------------
请求参数配置覆盖常见接口调试信息

在线调试过程中，可以分别配置：

•
Params；

•
Body；

•
Headers；

•
Cookies；

•
Auth。






其中，Params还支持：

•
新增参数；

•
启用参数；

•
删除参数；

•
设置参数名称；

•
设置参数值；

•
设置参数类型。



对于需要验证分页参数、筛选条件、请求头、认证信息等场景，可以直接按照实际接口要求组织请求内容。

--------------------------------
多标签调试多个接口

接口联调往往不会一次只验证一个接口。

例如，一个业务功能可能同时依赖用户接口、订单接口和指标接口。

V2.6.0支持同时打开多个接口测试标签页，并提供：

•
多接口并行调试；

•
固定标签页；

•
关闭当前标签；

•
关闭其他标签；

•
关闭全部标签。



多标签方式更适合进行接口对比以及多接口联合验证。




--------------------------------
支持请求超时与HTTP重定向设置

在接口测试过程中，还可以：

•
配置请求超时时间；

•
启用或禁用HTTP跟随重定向。



这类配置能够覆盖部分接口网络行为测试场景。




--------------------------------
不只是看Body，还可以查看完整响应信息

接口返回后，平台支持查看：

•
Response Body；

•
Cookie；

•
Header；

•
实际请求信息；

•
HTTP响应状态码；

•
请求耗时；

•
响应数据大小。






从研发链路来看，可以将接口验证过程概括为：

选择数据服务 → 配置请求 → 设置参数与认证 → 发送请求 → 查看状态码与响应 → 判断接口是否符合预期

在线测试能力主要面向开发和联调阶段，并不能替代专业API测试、压力测试、自动化测试或完整的接口监控体系。

--------------------------------
06 整库同步新增OceanBase和TiDB，继续扩展数据库接入范围

企业进行数据库迁移、ODS建设或多业务系统数据汇聚时，整库同步通常比逐表创建数据集成任务更适合大规模数据接入场景。

随着企业数据库技术栈逐渐多样化，整库同步能力也需要持续适配更多数据库类型。

qData V2.6.0新增：

•
OceanBase整库同步






•
TiDB整库同步






支持基于OceanBase和TiDB创建整库同步任务。

这进一步扩展了整库同步可覆盖的数据源环境。

对于数据库迁移、分布式数据库数据汇聚以及数据仓库贴源层建设等场景，可以减少大量表逐项配置同步任务的重复工作。

但整库同步并不意味着任意数据库之间都可以无差异迁移。实际实施过程中仍需关注源端和目标端支持范围、字段类型映射、增量机制、数据量以及网络带宽等因素。

--------------------------------
07 数据连接新增“诊断”能力，从连接失败进一步定位失败原因

数据连接是整个数据中台的入口。

一旦数据源连接不可用，上层的数据同步、数据开发、数据查询和数据服务都会受到影响。

但实际排查连接问题时，“连接失败”只是结果，真正的问题可能发生在不同位置：

配置错误 → 地址无法解析 → 端口不通 → 账号认证失败 → Database / Schema错误 → 权限不足 → 元数据无法读取

如果系统只能返回“连接失败”，技术人员仍然需要逐层手动检查。

因此，qData V2.6.0新增数据源诊断能力。

--------------------------------
覆盖多类数据源连接诊断

当前诊断能力覆盖：

•
关系型数据库；






•
数据仓库；






•
对象存储；






•
时序数据库。






不同类型数据源的连接机制存在差异，但平台可以围绕基础访问链路进行进一步检查。

--------------------------------
从网络连通到账号权限逐项检查

数据源诊断支持检查：

•
连接配置；

•
网络地址解析；

•
端口连通性；

•
账号认证；

•
Database；

•
Schema；

•
账号角色与权限；

•
元数据读取能力。



同时展示各诊断项的执行状态和诊断结果。




这样一来，“测试失败”可以进一步拆解为更具体的问题位置。

例如，当端口连通但认证失败时，排查方向可以优先转向账号密码和认证方式；当账号认证成功但元数据无法读取时，则可以继续检查Schema和权限范围。

诊断结果可以帮助缩小排查范围，但仍不能替代数据库自身日志、网络策略和安全审计系统。

--------------------------------
测试连接统一进入配置流程第三步

V2.6.0同时优化数据连接的新增和修改流程，将“测试连接”统一放入配置流程第三步。

用户可以针对当前配置执行完整连接测试，并查看：

•
测试过程；

•
各诊断项状态；

•
最终测试结果。



这样可以在正式保存或启用连接前，先确认当前配置是否满足基本访问条件。




--------------------------------
08 逻辑模型发布继续扩展数据库支持

企业完成逻辑数据模型设计之后，还需要将模型结构真正发布到目标数据库。

因此，模型管理不仅涉及逻辑层设计，也会受到不同数据库DDL能力和发布机制的影响。

qData V2.6.0进一步扩展逻辑模型发布支持范围，新增：

•
Kingbase；






•
PostgreSQL；






•
Oracle。






三类数据源的模型发布能力。

--------------------------------
支持删除重建与增量发布

针对Kingbase、PostgreSQL和Oracle，本次版本均支持：

•
删除重建发布

•
增量发布



删除重建更适合需要根据当前模型重新构建目标结构的场景，而增量发布则更适合已有模型持续调整后，仅将变化内容同步至目标数据库。

在生产环境中，模型发布涉及真实数据库结构变化，因此仍需要结合企业自身的数据库权限、版本管理和变更审核制度使用。

--------------------------------
09 帮助中心直接嵌入平台，让功能使用与文档查询处于同一上下文

企业平台功能持续增加后，另一个常见问题是：

用户知道功能入口在哪里，却不一定知道具体应该怎么配置。

如果每次遇到问题都需要离开平台、重新打开文档站点，再查找对应章节，学习和排查过程会被不断打断。

因此，qData V2.6.0新增平台帮助中心。




--------------------------------
用户手册直接嵌入平台

帮助中心采用抽屉形式嵌入平台页面。

用户可以：

•
在平台内直接打开帮助中心；

•
在当前页面关闭帮助中心；

•
浏览内嵌的qData用户手册；

•
按照目录切换对应帮助内容。



这种方式并不是替代完整文档体系，而是尽量缩短“遇到问题—查找说明—返回操作”的路径。




--------------------------------
帮助内容覆盖主要功能模块

当前帮助内容覆盖：

•
qData概览；

•
基础管理；

•
数据建模；

•
数据研发；

•
数据治理；

•
数据资产；

•
数据服务。



同时，功能页面新增“查看帮助文档”入口，可以进一步跳转至对应内容。

对于新用户或跨模块使用人员而言，可以减少从完整文档目录中重新定位功能说明的步骤。




--------------------------------
10 作业管理UI升级，优化复杂任务编排的操作路径

当单个任务逐渐组合为完整作业后，用户关注的不只是“某个任务是否能够运行”，还需要从整体编排角度查看多个节点之间的关系。

因此，V2.6.0进一步升级作业管理页面。

本次主要调整包括：

•
优化作业任务资源树展示；

•
优化作业编排画布布局；

•
优化节点展示；

•
调整作业内任务节点的展示方式；

•
优化任务保存入口；

•
优化任务配置入口；

•
优化任务检查入口；

•
调整作业配置页面整体布局和交互方式。



这类调整的重点不是改变任务编排本身，而是让作业资源、画布节点以及配置入口之间的关系更清晰。

对于包含较多任务节点的作业来说，界面结构和交互方式会直接影响开发人员查找节点、修改任务和执行检查时的操作成本。




--------------------------------
11 标准数据元拆分：数据元与代码表分别管理

数据标准管理中，数据元和代码表虽然关系紧密，但承担的管理对象并不完全相同。

数据元更多用于描述字段语义、类型及标准定义；代码表则主要维护具体枚举值和编码体系。

qData V2.6.0调整原“标准数据元”功能结构，将其拆分为：

•
数据元

•
代码表



两个独立菜单。

拆分后：

•
数据元可以独立创建、维护和管理；






•
代码表可以独立创建、维护和管理；






两类对象分别通过独立功能入口进行操作。

这种调整有助于进一步明确两类标准对象的管理边界。

对于企业数据标准体系来说，功能入口的拆分并不等同于标准体系已经自动建立，企业仍然需要结合自身业务制定数据元命名、定义、编码和维护规范。

--------------------------------
12 完善全局输入校验与类目树展示，减少基础配置问题

除了主要研发能力，V2.6.0还对全局交互和基础校验进行了统一调整。

这类功能通常不会成为版本宣传中的核心模块，但在企业平台长期使用过程中，基础交互的一致性会直接影响日常操作体验。

--------------------------------
输入框增加统一基础校验

本次版本在全局范围增加输入框基础校验，包括：

•
必填输入框不允许为空；

•
输入内容不允许全部为空格；

•
相关文本输入统一限制最长不超过50个字符；

•
统一相关输入框校验规则；

•
统一异常提示方式。



这些检查可以提前拦截一部分无效配置，例如名称完全为空、只有空格或输入内容超过限制。

它们主要用于提高基础数据填写的规范性，并不能替代业务层面的数据校验规则。




--------------------------------
左侧类目树调整为紧凑型样式

平台还对全局左侧类目树进行了样式调整，包括：

•
调整为紧凑型展示；

•
优化类目节点之间的间距；

•
调整多层级类目树节点展示方式；

•
统一不同模块左侧类目树的整体样式。



当数据源、任务、模型和资产目录不断增加时，更紧凑的展示方式能够在有限区域内呈现更多层级信息。




--------------------------------
版本价值 ：从能力扩展，进一步走向链路协同

相比单一功能增加，qData V2.6.0更关注数据接入、研发、治理、服务和运维之间的衔接，使企业数据平台在复杂数据环境下具备更完整的研发与管理链路。

•
1.数据链路更完整



整库同步、关系型数据库开发和数据服务进一步纳入血缘体系，使数据能够从来源、同步、加工一直追踪到服务使用，为数据问题追溯和上下游关系分析提供更清晰的依据。

•
2.研发与排障链路更连贯



离线与实时任务分类管理，结合任务日志优化、在线接口测试和数据源诊断，使开发人员可以更集中地完成任务开发、运行检查、接口调试和连接问题定位，减少不同工具和页面之间的切换。

•
3.异构数据环境适配进一步扩大



通过扩展达梦、ODPS、Hive、OceanBase、TiDB、Kingbase、PostgreSQL、Oracle等数据源在数据开发、整库同步和模型发布中的支持范围，进一步适配企业多数据库、多技术栈并存的数据架构。

•
4.平台长期使用更加规范



帮助中心、作业管理UI、数据元与代码表独立管理，以及全局输入校验和交互优化，进一步完善平台使用和管理细节，为企业持续开展数据研发、治理与运维提供更统一的工作入口。

总体来看，qData V2.6.0的价值不只是增加更多功能，而是继续将数据接入、加工、追踪、调试和服务使用组织到更加连贯的链路中，让企业数据中台从“具备能力”进一步走向“能力之间能够协同”。

--------------------------------
写在最后

qData 数据中台专业版V2.6.0的变化并不集中在某一个独立功能点，而是围绕企业数据平台的一条完整使用链路继续向前延伸。

从整体来看，这一版本可以归纳为几个方向：

•
在数据接入侧，整库同步新增OceanBase和TiDB支持，数据连接进一步加入诊断能力，使数据从“配置连接”到“确认连接问题”拥有更完整的操作路径。

•
在数据研发侧，数据集成和数据开发进一步区分离线、实时任务，Flink与Spark调整为集群模式运行，同时增加达梦、ODPS、Hive数据开发支持，并继续优化ETL底层架构和任务日志。

•
在数据治理与链路分析侧，整库同步、关系型数据库开发以及数据服务进一步进入血缘体系，让血缘关系从数据接入、开发加工继续向数据服务端延伸。

•
在数据服务侧，新增在线接口测试，从接口配置进一步延伸到请求参数、认证、响应信息和多接口调试，使数据服务开发与联调过程更加连贯。



与此同时，逻辑模型发布继续扩展数据库适配，帮助中心进入平台内部，作业管理完成交互调整，数据元与代码表拆分管理，并统一基础输入校验与类目树样式。

对于企业数据中台来说，平台建设并不是简单叠加更多功能，而是需要逐步将数据接入、研发、运行、治理、服务和排查组织成一套可以持续使用的工作链路。

qData V2.6.0本次调整的重点，也正是在已有数据能力基础上继续补充这些环节之间的连接。

这些能力并不能替代企业自身的数据架构设计、权限体系、生产变更制度、资源规划和运维监控，但可以进一步减少不同数据环节之间的信息断点，让数据从接入平台、加工运行到形成服务的过程更加清晰，也为后续的数据治理和持续运营提供更完整的基础。

原文链接

solar957

这种认真写长文的楼主不多了，必须支持。

wild_frost

• 任务异常后，开发人员能否快速从日志中判断执行阶段和异常位置？

这句信息量很大，值得单独展开讲讲。

wombat_solar_96

支持原创，内容很扎实，持续关注。

lunar443

看完顺手回一个，内容确实有料。

hawk_hyper_31

从头看到尾，收获不少，感谢分享。