StarRocks 元函数 inspect_mv_relationships透视外部表与物化视图的映射关系【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocksinspect_mv_relationships()是 StarRocks FE 提供的一个无参元函数meta function用于将 FE 内存中ConnectorTblMetaInfoMgr的内容以 JSON 形式导出从而展示外部基表external base table与物化视图materialized view之间的映射关系。本文以该函数的官方文档为主体结合 MetaFunctions.java 与 ConnectorTblMetaInfoMgr.java 的源码实现讲清其用途、权限要求、输出格式、底层存储结构及排查实践帮助你快速定位「外部表上到底挂了哪些 MV」这类元数据问题。函数概览inspect_mv_relationships是一个典型的常量函数Constant Function在 MetaFunctions.java 中通过注解注册ConstantFunction(name inspect_mv_relationships, argTypes {}, returnType VARCHAR, isMetaFunction true) public static ConstantOperator inspectMvRelationships() { ... }其语义非常简单返回ConnectorTblMetaInfoMgr中存储的全部内容该管理器维护了从外部基表到物化视图的映射信息。注意这里的外部表指的是通过 Catalog 接入的 Hive、Iceberg、Hudi、Paimon 等外部数据源表而非 StarRocks 内表。参数Arguments无。该函数不接受任何参数。返回值Return Value返回一个VARCHAR字符串内容是 JSON 格式的映射信息。当系统中没有任何外部表与物化视图的关联关系时返回空对象{}。使用示例官方文档给出的示例展示了空状态下尚未为外部表创建关联 MV的查询结果mysql select inspect_mv_relationships(); ---------------------------- | inspect_mv_relationships() | ---------------------------- | {} | ---------------------------- 1 row in set (0.01 sec){}表示当前ConnectorTblMetaInfoMgr中不存在任何映射条目这是一个健康且正常的初始状态。只有当用户基于外部表或外部表上的视图创建物化视图后这里才会出现内容。权限要求虽然该函数不接收参数但它属于元函数meta function调用时需要较高的系统级权限。从源码 MetaFunctions.java 可以看到函数执行前会先进行权限校验ConnectContext context ConnectContext.get(); try { Authorizer.checkSystemAction(context, PrivilegeType.OPERATE); } catch (AccessDeniedException e) { AccessDeniedException.reportAccessDenied( , context.getCurrentUserIdentity(), context.getCurrentRoleIds(), PrivilegeType.OPERATE.name(), ObjectType.FUNCTION.name(), inspect_mv_relationships); }也就是说调用方必须具备OPERATE系统权限对应 GRANT 语法中的GRANT OPERATE ON SYSTEM否则会被拒绝访问。这与inspect_mv_meta、inspect_mv_plan等同类元函数保持一致——它们都属于排查/管理类接口需要管理员权限才能执行。输出 JSON 的结构与含义调用该函数后FE 会委托给ConnectorTblMetaInfoMgr的inspect()方法完成序列化。结合 ConnectorTblMetaInfoMgr.java 的源码输出的 JSON 格式为{ catalog.db.table: [ { dbId: 1, id: 2 }, { dbId: 1, id: 5 } ] }各层级含义如下JSON 层级含义最外层 key形如catalog.db.table的表全限定名对应一张外部基表value数组关联到该外部表的物化视图列表每个元素是一个MvIddbId物化视图所在数据库的 IDid物化视图自身的表 ID在源码中映射关系被组织为catalogName - dbName - tableIdentifier - ConnectorTableInfo三层结构见 ConnectorTblMetaInfoMgr.javaprivate final TableString, String, MapString, ConnectorTableInfo connectorTableMetaInfos;使用 Guava 的TreeBasedTable存储数据库名、表名均采用大小写不敏感的排序String.CASE_INSENSITIVE_ORDER每个外部表对应一个ConnectorTableInfo其内部核心字段是relatedMaterializedViews即一组MvId见 ConnectorTableInfo.javainspect()遍历时以TableName(catalog, db, tableName)为 key以tableInfo.inspect()序列化后的MvId数组为 value最终拼成 JSON。源码与测试对输出格式的印证单元测试 ConnectorTblMetaInfoMgrTest.java 直接验证了上述 JSON 形态ConnectorTableInfo tableInfo new ConnectorTableInfo( ImmutableSet.of(new MvId(1, 1), new MvId(1, 2))); mgr.addConnectorTableInfo(cat, db, tbl, tableInfo); json mgr.inspect(); Assertions.assertEquals({\cat.db.tbl\:[{\dbId\:1,\id\:1},{\dbId\:1,\id\:2}]}, json);可以看到一个外部表cat.db.tbl关联了两个 MVdbId1, id1与dbId1, id2序列化结果与上面表格描述完全一致当执行removeConnectorTableInfo移除映射后inspect()重新返回{}。这也意味着该函数输出的每个条目都是外部表 - 依赖它的 MV 集合的一对多关系。底层实现ConnectorTblMetaInfoMgr 如何维护映射要真正用好这个排查函数有必要理解映射关系在 FE 中是如何被写入和删除的。ConnectorTblMetaInfoMgr对外提供的主要方法包括addConnectorTableInfo(catalog, db, tableIdentifier, connectorTableInfo)当外部表上新建/注册物化视图依赖时把ConnectorTableInfo内含新增的MvId合并进对应表条目若此前不存在则新建条目ConnectorTblMetaInfoMgr.java。removeConnectorTableInfo(...)删除映射若某表的关联 MV 集合清空则移除该表条目若整个库下无任何条目则连库一并移除ConnectorTblMetaInfoMgr.java。setTableInfoForConnectorTable(...)把ConnectorTableInfo中记录的MvId回写到对应的Table对象上供优化器识别物化视图依赖ConnectorTblMetaInfoMgr.java。所有读写操作都由一个ReentrantReadWriteLock保护ConnectorTblMetaInfoMgr.javainspect()走读锁保证在并发写入场景下也能安全地导出快照。该管理器由GlobalStateMgr统一持有函数内部通过GlobalStateMgr.getCurrentState().getConnectorTblMetaInfoMgr().inspect()获取结果MetaFunctions.java。从 MaterializedView.java 与 MVMetaVersionRepairer.java 中的引用可以推断这类映射信息在 MV 创建、元数据回放replay create mv journal与元数据修复等流程中都会被维护。典型使用场景排查外部表 MV 依赖丢失当基于 Hive/Iceberg 外部表创建的物化视图出现刷新异常或改写query rewrite不生效时先执行select inspect_mv_relationships();确认该外部表条目下是否仍存在对应的MvId。若条目为空或缺失说明依赖元数据未正确建立。验证 MV 创建结果在外部表上CREATE MATERIALIZED VIEW之后通过本函数核对映射是否如期写入作为 DDL 生效的旁证。理解映射粒度输出清晰地展示了一个外部表可能同时被多个 MV 依赖value 数组包含多个MvId方便评估 MV 之间的共享基表关系。与相关元函数的分工StarRocks 提供了一整套inspect_*系列元函数注册于同一个 MetaFunctions.java彼此分工不同实际排查时经常配合使用函数作用inspect_mv_relationships()导出外部基表与物化视图的映射关系本文主题无参数inspect_related_mv(catalog.db.tbl)查看指定表关联的物化视图按表维度查询inspect_mv_meta(mv_name)查看物化视图的元数据信息inspect_mv_refresh_info(mv_name)查看物化视图的刷新配置信息inspect_mv_plan(mv_name)查看物化视图的查询计划若你只需要关注某一个外部表的 MV 依赖使用inspect_related_mv更聚焦而当需要全局视角、一次导出所有外部表与 MV 的依赖关系时inspect_mv_relationships()是最直接的选择。小结inspect_mv_relationships()是一个零参数、面向管理员的元函数它把 FE 内部ConnectorTblMetaInfoMgr中外部基表 - 物化视图的映射以 JSON 形式完整暴露出来。理解它的输出格式{catalog.db.table: [MvId...]}、权限门槛需OPERATE系统权限以及背后的三层存储结构与读写锁机制能让你在排查外部表物化视图元数据问题时多一件趁手的诊断工具。相关源码与测试可进一步参考函数注册与实现MetaFunctions.java映射存储与序列化ConnectorTblMetaInfoMgr.java单表元信息结构ConnectorTableInfo.java输出格式验证用例ConnectorTblMetaInfoMgrTest.java【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考