DataHub Cloud v0.3.10 发布说明全解:Smart Assertions、API Tracing 与 Remote Executor 运维要点
【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub
导读
本文基于 DataHub 开源仓库中 DataHub Cloud v0.3.10 发布说明,完整梳理该版本(2025 年 4 月发布)的能力变更、已知问题与升级路径,并结合仓库源码解析upsertLinkGraphQL 端点、scrollAcrossEntities排序、在线 Smart Assertions、OpenAPI 异步写入与 API Tracing 等关键特性的底层实现。读完本文,你将掌握 v0.3.10 全系列版本(v0.3.10 → v0.3.10.4)的变更全貌,明确升级时的版本选型与前置条件(如 Remote Executor 最低版本、环境变量配置),并能从源码层理解各特性背后的工作方式。
一、版本概览:发布时间、配套组件与升级基线
v0.3.10 是 DataHub Cloud 于 2025 年 4 月发布的一个重要版本,其配套组件版本如下:
| 项目 | 版本 |
|---|---|
| 发布日期(Release Availability Date) | 2025 年 4 月 4 日 |
| 推荐 CLI/SDK 版本 | 1.0.0.2 |
| 配套 Helm Chart 版本 | 1.5.21 |
需要特别注意的是,v0.3.10 主版本本身因 Slack 应用回归问题(详见下文"版本演进脉络")被标记为不可使用,官方建议直接升级到 v0.3.10.1 及以上。该系列最终收敛到 v0.3.10.4,其中 v0.3.10.2 被明确标注为相比 v0.3.10.1 的推荐版本。该发布说明与仓库中同目录的 v1.0.0 发布说明 相互衔接:v0.3.10.1 的变更集与开源仓库 v1.0.0 版本保持一致。
二、已知问题:升级前必读的两个前提条件
1. API Tracing 与系统 Hook 生成的 aspect 冲突
发布说明明确指出:API Tracing 对部分可由系统 hook 生成的 aspect(如siblings)会报告为 trace error,前提是系统 aspect 与 ingestion 正在创建冲突的 aspect。
这背后的机制可以从 response_helper.py 中窥见:API Tracing 依赖服务端在响应头返回traceparent追踪头(_TRACE_HEADER_NAME = "traceparent"),客户端通过_extract_trace_id从响应头提取 trace ID,再用TraceData对指定 aspect 的写入状态进行校验。当siblings这类由系统 hook 异步生成的 aspect 与 ingestion 写入的 aspect 互相覆盖时,客户端校验自然会出现不一致的"错误"记录。这是功能本身处于实验阶段(Experimental)的正常表现,不代表数据写入真正失败。
2. Online Smart Assertions 的启用前置条件
开启 GMS 中的ONLINE_SMART_ASSERTIONS_ENABLED特性开关前,必须满足两个条件:
- Remote Executor 必须升级到 v0.3.10.2 或更高版本;
- 必须禁用离线 pipeline 驱动的 smart assertions(offline pipeline driven smart assertions)。
v0.3.10.1 与 v0.3.10.2 之间对这条规则的描述差异也印证了其演进:v0.3.10.1 要求远程执行器手动设置ONLINE_SMART_ASSERTIONS_ENABLED环境变量,而 v0.3.10.2 起不再需要在远程执行器上设置该环境变量,Online Smart Assertions 即可工作——这正是 v0.3.10.2 被推荐的原因之一。
三、版本演进脉络:从 v0.3.10 到 v0.3.10.4
该发布说明按子版本组织变更日志,反映了"发布后快速修补"的迭代节奏。以下按时间线完整梳理。
v0.3.10:因 Slack 回归被废弃
发布后发现 Slack 应用存在回归问题,官方直接声明:"Do not use this release, instead go straight to v0.3.10.1."(不要使用此版本,直接升级到 v0.3.10.1)。这是该系列中唯一一个完全不可用的版本。
v0.3.10.1:功能大版本,与开源 v1.0.0 对齐
v0.3.10.1 包含开源仓库 v1.0.0 版本的全部变更,是本次发布的功能主体。
破坏性变更(Breaking Changes)
- API 校验全面启用:所有ASYNC ingestion 请求都将执行 API 校验,校验范围包括URN、Entity Type Name、Entity 与 Aspect 名称。违反这些规则将返回 4xx 异常。这意味着旧版本中"宽松写入"的 ingestion 任务在新版本下可能直接报错,升级前需要审计 ingestion 配置中的 URN 与命名是否合规。
Bug 修复
- Schema Tab:V1 体验中支持富文本渲染,链接可直接点击,无需再点 "View more";
- Subscriptions:修复订阅摘要中用户/组显示名称的边界情况;
- Nav Bar:修复 Safari 中新版导航栏头部 Logo 的样式问题;
- Group Membership:加固用户详情页展示组成员时的 UI 容错;
- Structured Properties:允许为资产应用结构化属性值时搜索 Glossary 节点;
- Lineage(多项):隐藏列表视图中无用过滤器;移除每跳节点数限制(此前会导致部分结果被隐藏);修复 Charts 等实体类型的间接上游血缘不完整问题——同时影响 Impact Analysis 与 Lineage Graph,并导致 Upstream Health 侧边栏漏报存在健康问题的上游资产;
- Queries Tab:调整分页大小;
- Search Filters:新增 "Has Siblings" 过滤器(默认关闭,可按需申请开启)。
Product 特性(面向最终用户)
- Navigation:V2 UI 中新的简化导航栏默认开启;
- Custom Asset Actions:通过 Documentation 页签创建的链接可以提升显示到页面头部与搜索结果中,同时新增
upsertLinkGraphQL 端点,便于以编程方式管理链接; - Proposals:实体详情页开始展示新的提案类型——Ownership(所有权)、Domains(域)与 Structured Properties(结构化属性);重新设计的 Proposals 2.0 体验进入 Beta(按需开启);并支持在Settings > My Notifications中配置"被指派审阅提案"或"自己提交的提案被批准/拒绝"的通知;
- Observe:按需 Smart Assertions 进入 Beta(按需开启),可通过 UI 为 Observe 支持的任何表创建 freshness(新鲜度)、volume(量)与 field metric(字段指标)异常检测;Smart Assertion 调优支持调整训练数据回看窗口(lookback window)、收紧或放松敏感度、增加数据点排除窗口;Incidents V2显著增强,支持设置指派对象(assignees)、严重级别(severity)、阶段(stage)与受影响资产,并支持在 incidents 页签中搜索、分组与过滤;
- Remote Executor:Manage Data Sources页面新增Executors页签,用于远程执行器池的管理与可观测性;可直接从 UI 创建并配置新的 Executor Pools,并可将其设为未来 Ingestion Source 配置的默认池;可查看已部署执行器集合、其状态、配置的 Ingestion Source 与当前运行任务;
- Compliance Forms:支持在 Compliance Center 中深链到特定 Compliance Form 的填写体验;
- Search:新增Deprecated 过滤器支持搜索已弃用资产,并在 Lineage 侧边栏中将弃用状态作为上游健康警告展示。
Platform 特性(面向平台/开发者)
- OpenAPI:API Tracing 改进(实验性);
- GraphQL:为
scrollAcrossEntities增加排序能力; - Performance:使用嵌套域与容器时改进访问策略(access policy)性能;
- OpenAPI:新增操作端点,可获取原始 ES 文档并查看 MCP/MCL topic 的 Kafka lag;
- OpenAPI:对异步端点使用的 URN 与实体/方面名称增加额外校验;
- OpenAPI:修复 timeseries aspect ingestion bug #12912;
- Restore Indices Job:支持只读副本(read-only replicas)。
Ingestion 特性
- MLflow:支持数据集 ↔ 运行的 lineage,并支持数据集的自定义平台映射;
- OpenAPI:Ingestion 可使用 OpenAPI 替代 Rest.li,设置环境变量
DATAHUB_REST_SINK_DEFAULT_ENDPOINT=OPENAPI即可切换; - API Tracing:Ingestion 可通过跟踪到 primary 与 search 存储的写入来追踪每个异步写入,设置环境变量
DATAHUB_REST_TRACE_MODE=ENABLED即可开启。
v0.3.10.2:推荐修补版本
- 已知问题:Remote Automations runner 在安装
acryl-datahub时遇到依赖解析问题,因此本版本中远程自动化为不支持状态(需要运行自动化请联系 DataHub Cloud 支持); - Bug 修复:
- Executor/Observe:Online Smart Assertions 无需再在远程执行器上设置
ONLINE_SMART_ASSERTIONS_ENABLED环境变量; - Forms:修复 v0.3.10.1 引入的"在按问题批量表单视图中应用过滤器或做某些修改时被移出表单体验"的 bug;
- Manage Ingestion:修复 v0.3.10.1 引入的"无法正常切换管理 ingestion 页面"的 bug;
- Structured Properties:修复可误创建"不接受任何 Entity 类型值"的 Entity 类型结构化属性问题;
- API:修复 Entity 类型大小写敏感导致的校验错误;
- Observe:为断言添加标签(tags)现在可以正常工作;
- Executor/Observe:Online Smart Assertions 无需再在远程执行器上设置
- Product 改进:
- Executor Pools:Pool id 字符数上限提升到 200;
- Observe:为 Smart Assertions 的各种调优旋钮提供清晰说明。
v0.3.10.3:一批体验与统计修复
- Automations:修复远程 action 因尝试安装本地版本
acryl-datahub时报错而无法运行的问题; - Automations:修复 Glossary 术语选择器中部分术语无法加载的渲染问题;
- Stats:修复使用采样(sampling)分析表时获取表行数的 bug;
- Analytics:首页新增 usage analytics;
- Lineage:修复隐藏 transformation 节点时血缘边不显示的问题;
- Slack:修复极少数情况下 Slack 应用安装报错的问题;
- UX + Permissions:修复查看结构化属性页面与管理 ingestion 页面的权限问题。
v0.3.10.4:图形界面与依赖收尾
- GraphQL:固定 GraphiQL 依赖并使用 React 18 的特定版本与修正后的 SRI 哈希;
- UX:首页推荐中隐藏已删除资产。
四、源码级解读:v0.3.10 关键特性的底层实现
4.1 Custom Asset Actions 与upsertLinkGraphQL 端点
v0.3.10.1 宣布新增upsertLinkGraphQL 端点,用于编程式管理资产链接。该端点在仓库中的服务端实现位于 UpsertLinkResolver.java:
- 参数绑定:从
AddLinkInput中解析linkUrl、label(链接标签)与resourceUrn(目标资产 URN),并读取可选的联系settings; - 权限校验:调用
LinkUtils.isAuthorizedToUpdateLinks(context, targetUrn)检查操作者是否被授权更新该资产的链接,同时允许GlossaryUtils.canUpdateGlossaryEntity放行 Glossary 实体场景,未授权则抛出AuthorizationException; - 输入验证:
LinkUtils.validateAddRemoveInput对 link URL 与目标 URN 做合法性校验; - 落库写入:以当前操作者 URN 为 actor,调用
LinkUtils.upsertLink(...)写入元数据。
整个解析器通过GraphQLConcurrencyUtils.supplyAsync异步执行,失败时会包装为运行时异常并记录日志。对应的解析器注册在 GmsGraphQLEngine.java,测试覆盖见 LinkUtilsTest.java。此外,仓库中还有配套的链接工具类 LinkUtils.java 与 entity.graphql 中的 GraphQL schema 定义。
4.2 GraphQL:scrollAcrossEntities排序
平台特性中提到的"scrollAcrossEntities增加排序",对应 schema 定义 search.graphql 中的scrollAcrossEntities(input: ScrollAcrossEntitiesInput!): ScrollResults。该查询用于跨实体类型做滚动式(scroll)搜索结果分页,适合在大结果集下按序翻页消费,新增排序能力后,调用方可以在滚动遍历的同时按自定义字段排序,为"搜索结果 + 排序"的组合场景(如资产列表导出、批量扫描)提供了便利。
4.3 "Has Siblings" 搜索过滤器
v0.3.10.1 新增的 "Has Siblings" 过滤器(默认关闭、按需开启)在前端有完整实现:传统搜索路径位于 HasSiblingsFilter.tsx 与配套的 HasSiblingsRenderer.tsx,同时新的 searchV2 体验也有对应实现(见 searchV2/filters/render/siblings)。siblings(兄弟实体)是 DataHub 中表达"同一逻辑资产的不同物理实现"(如 Hive 表与对应的 S3 数据集)的建模方式,"Has Siblings" 过滤器让用户可以快速筛选出存在兄弟实体的资产,便于识别需要同步元数据的资产组。
4.4 Ingestion 切换 OpenAPI 端点与 API Tracing
v0.3.10.1 引入的两个 Ingestion 环境变量,其底层实现在 Python ingestion SDK 中:
- OpenAPI 端点切换:
DATAHUB_REST_SINK_DEFAULT_ENDPOINT=OPENAPI(发布说明中的名称)对应当前仓库源码 env_vars.py 中get_rest_emitter_default_endpoint()读取的DATAHUB_REST_EMITTER_DEFAULT_ENDPOINT(取值RESTLI或OPENAPI)。在 rest_emitter.py 中,emitter 会先探测服务端能力(get_rest_emitter_default_endpoint() or RestSinkEndpoint.RESTLI),再决定_openapi_ingestion模式,并打印Using OpenAPI for ingestion.或Using Restli for ingestion.的启动日志。启用后,每个MetadataChangeProposal会通过_to_openapi_request转换为 OpenAPI 请求格式发送。 - API Tracing:发布说明中的
DATAHUB_REST_TRACE_MODE=ENABLED对应 SDK 中的 emitter 追踪机制(当前源码中为DATAHUB_EMITTER_TRACE=true,见 env_vars.py 的get_emitter_trace())。开启后,异步写入会跟踪到 primary 与 search 存储,response_helper.py 中的TraceData从响应头traceparent提取 trace ID 与各 aspect 的写入时间戳,帮助定位"MCP 已发送但尚未落到搜索索引"的中间状态。值得一提的是,文档中使用的变量名与当前仓库实现中的变量名存在差异(REST_SINKvsREST_EMITTER、TRACE_MODE=ENABLEDvsEMITTER_TRACE=true),从源码结构看属于后续版本对配置项的重命名,部署时应以所使用 SDK 版本的实际支持为准。
4.5 Incidents V2 与 Observe 能力
Incidents V2 引入的指派对象、严重级别、阶段、受影响资产等能力,在 GraphQL 层对应 resolvers/incident 目录下的一组解析器:EntityIncidentsResolver(查询实体关联的 incident)、RaiseIncidentResolver(发起)、UpdateIncidentResolver(更新字段)、UpdateIncidentStatusResolver(更新状态)、UpsertIncidentResolver(新建或更新)以及工具类IncidentUtils。配合 Observe 模块的按需 Smart Assertions 与调优能力,用户可以基于异常检测结果直接驱动 incident 全生命周期管理。
4.6 Smart Assertions 与 Remote Executor 的依赖关系
在线 Smart Assertions 是本版本最重要的 Observe 能力之一。结合已知问题部分可以梳理出完整的启用链路:
- 在 GMS 侧开启
ONLINE_SMART_ASSERTIONS_ENABLED特性开关; - 确保所有 Remote Executor 升级到v0.3.10.2+(v0.3.10.2 起无需在执行器上再设置同名环境变量);
- 确保离线 pipeline 驱动的 smart assertions 已禁用,避免两种执行路径同时运行产生重复或冲突的断言结果。
离线 pipeline 与在线执行是两套互斥的运行机制,混用会导致断言结果口径不一致。这正是该特性"上线门槛高"的原因:升级前需要同时协调 GMS 配置、执行器版本与离线任务下线三个动作。
五、升级路径建议与注意事项
综合整个 v0.3.10 系列,升级时建议遵循以下检查清单:
- 版本选型:跳过 v0.3.10(Slack 回归),最低选择 v0.3.10.1;推荐直接升级到v0.3.10.2(修复了 v0.3.10.1 中 Forms 与 Manage Ingestion 的回归 bug,且放宽了 Online Smart Assertions 的执行器配置);最终版本 v0.3.10.4 提供了最完整的修复集。
- 破坏性变更评估:v0.3.10.1 起对所有 ASYNC ingestion 请求执行 URN、Entity Type、Entity/Aspect 名称的严格校验,升级前需审计 ingestion 配置中的命名合规性,避免 4xx 报错。
- Remote Automations 限制:v0.3.10.1 与 v0.3.10.2 中远程 automations 因
acryl-datahub依赖解析问题暂不支持,依赖远程自动化的场景需联系 DataHub Cloud 支持或评估后续版本。 - Smart Assertions 启用顺序:先升级执行器到 v0.3.10.2+,再关闭离线 pipeline 版 smart assertions,最后开启 GMS 的
ONLINE_SMART_ASSERTIONS_ENABLED。 - 配套版本对齐:CLI/SDK 使用 1.0.0.2,Helm Chart 使用 1.5.21,并留意后续发布说明(仓库 release-notes 目录持续更新,含 v0.3.11 至 v2.x 的演进记录)以规划后续升级。
总结
DataHub Cloud v0.3.10 系列是一次以Observe(可观测性)能力大升级 + API 治理收紧为双主线的重要发布:按需 Smart Assertions、Incidents V2、Smart Assertion 调优共同完善了异常检测闭环;Async API 严格校验、OpenAPI 写入通道、API Tracing 与upsertLink端点则让平台在工程治理与可编程性上更进一步。升级时务必以"跳过 v0.3.10、优先 v0.3.10.2+"为基线,并严格按本文清单处理 Smart Assertions 与 Remote Executor 的前置条件,即可平稳完成这次升级。
【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考