StarRocks 元数据透视:information_schema.tables_config 系统表字段全解与源码级剖析

发布时间:2026/9/17 9:05:46
StarRocks 元数据透视:information_schema.tables_config 系统表字段全解与源码级剖析 StarRocks 元数据透视information_schema.tables_config 系统表字段全解与源码级剖析【免费下载链接】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/starrockstables_config是 StarRocks 提供的一张 information_schema 系统表用于查询集群中所有表的核心配置元数据包括引擎类型、数据模型、主键、分区键、分桶键、分桶数、排序键以及表属性等。本文以 官方文档 为骨架结合 FEFrontend与 BEBackend两侧源码逐字段拆解其含义、取值来源与使用方式帮助你通过一条 SQL 快速完成表的配置体检与元数据审计。tables_config 是什么tables_config是 StarRocks 内置的一张系统元数据表System Table隶属于information_schema数据库它不存储任何用户数据而是实时反映当前集群中每张表的建表配置信息。官方文档对其定位的描述是tables_config provides information about the configuration of tables——即提供关于表配置的信息。在 FE 侧这张表由 TablesConfigSystemTable.java 定义表类型为Table.TableType.SCHEMA通过TSchemaTableType.SCH_TABLES_CONFIG与 BE 的 schema scanner 关联在 BE 侧则由 schema_tables_config_scanner.cpp 负责执行列的定义与数据填充。它与常见的tables、table_privileges等系统表同属 information_schema 家族但聚焦点完全不同tables回答有哪些表而tables_config回答每张表是怎么建的、怎么分布的、怎么排序的。它覆盖的表类型包括 OLAP 明细表、聚合表、更新表、主键表以及物化视图Materialized View和 OLAP 外表OLAP_EXTERNAL对于外部 Catalog 下的 Hive、MySQL、Iceberg、Hudi、JDBC、Elasticsearch 等外表类型从源码注释看仍处于待支持状态详见下文支持范围。字段总览tables_config共提供 12 个字段官方文档中的定义如下FieldDescriptionTABLE_SCHEMAName of the database that stores the table.TABLE_NAMEName of the table.TABLE_ENGINEEngine type of the table.TABLE_MODELData model of the table. Valid values:DUP_KEYS,AGG_KEYS,UNQ_KEYSorPRI_KEYS.PRIMARY_KEYPrimary key of a Primary Key table or a Unique Key table. An empty string is returned if the table is not a Primary Key table or a Unique Key table.PARTITION_KEYPartitioning columns of the table.DISTRIBUTE_KEYBucketing columns of the table.DISTRIBUTE_TYPEData distribution method of the table.DISTRIBUTE_BUCKETNumber of buckets in the table.SORT_KEYSort keys of the table.PROPERTIESProperties of the table.TABLE_IDID of the table.从数据类型上看除DISTRIBUTE_BUCKETINT4 字节与TABLE_IDBIGINT8 字节为数值类型外其余 10 个字段均为 VARCHAR其中PROPERTIES的容量最大使用MAX_FIELD_VARCHAR_LENGTH以容纳 JSON 形式的属性串其余名称类字段使用NAME_CHAR_LEN。这一列类型定义同时存在于 FE 的 TablesConfigSystemTable.java 与 BE 的 schema_tables_config_scanner.cpp 两处二者保持一致。字段逐项深度解析以下结合 FE 侧生成逻辑源码 InformationSchemaDataSource.javagenNormalTableConfigInfo方法逐字段说明其语义与取值来源。TABLE_SCHEMA 与 TABLE_NAMETABLE_SCHEMA存储表的数据库名称源码中直接取自dbNametableConfigInfo.setTable_schema(dbName)。TABLE_NAME表名称取自table.getName()。这两个字段共同构成查询时的定位键也是权限过滤的最小单元见下文权限与过滤。TABLE_ENGINE表的引擎类型。对 OLAP 系列表取自olapTable.getType().toString()即返回OLAP对物化视图返回MATERIALIZED_VIEW对 OLAP 外表返回OLAP_EXTERNAL对普通视图View则返回VIEW此时仅设置引擎字段其余配置字段留空。TABLE_MODEL表的数据模型Data Model取自olapTable.getKeysType().toString()有效取值与官方文档一致DUP_KEYS明细模型Duplicate KeyAGG_KEYS聚合模型Aggregate KeyUNQ_KEYS更新模型Unique KeyPRI_KEYS主键模型Primary KeyKeysType是 FE 中OlapTable的核心枚举决定了表的去重、聚合与更新语义。PRIMARY_KEY主键信息。源码逻辑为tableConfigInfo.setPrimary_key(olapTable.getKeysType().equals(KeysType.PRIMARY_KEYS) || olapTable.getKeysType().equals(KeysType.UNIQUE_KEYS) ? pkSb : DEFAULT_EMPTY_STRING);即仅当表属于主键模型或更新模型时才返回主键列取baseSchema中所有isKey()的列以反引号包裹、逗号分隔拼接其他模型一律返回空字符串。这与官方文档中 An empty string is returned if the table is not a Primary Key table or a Unique Key table 的描述完全对应。PARTITION_KEY分区列Partitioning columns。源码遍历partitionInfo.getPartitionColumns(...)将分区列名以col形式用, 拼接无分区时返回空字符串。对于未启用分区的单分区表此字段通常为空。DISTRIBUTE_KEY、DISTRIBUTE_TYPE、DISTRIBUTE_BUCKET这是描述表数据分布分桶策略的三个字段均取自olapTable.getDefaultDistributionInfo()DISTRIBUTE_KEY分桶列Bucketing columns取自distributionInfo.getDistributionKey(olapTable.getIdToColumn())即DISTRIBUTED BY HASH(...)中指定的列。DISTRIBUTE_TYPE数据分布方式取自distributionInfo.getType().name()典型取值为HASH哈希分桶与RANDOM随机分桶。DISTRIBUTE_BUCKET分桶数量取自distributionInfo.getBucketNum()。需要说明的是当使用自动分桶Auto Bucket时这里反映的是当前生效的分桶数设置。这三个字段是排查数据倾斜、评估查询并行度与分桶数规划的重要依据。SORT_KEY排序键。排序键决定了数据在存储引擎中的物理排布顺序直接影响前缀匹配查询的效率。源码逻辑为MaterializedIndexMeta index olapTable.getIndexMetaByMetaId(olapTable.getBaseIndexMetaId()); if (index.getSortKeyIdxes() null) { tableConfigInfo.set_sort_key(pkSb); } else { // 按 sortKeyIdxes 中的列下标映射到列名拼接输出 }即若未显式指定ORDER BY排序键则默认排序键回退为主键列集合pkSb若建表时通过ORDER BY显式声明了排序键则按index.getSortKeyIdxes()中记录的列下标逐一映射到baseSchema中的列名输出。理解这一点对解读为什么 SORT_KEY 与 PRIMARY_KEY 显示相同很有帮助。PROPERTIES表属性集合以 JSON 字符串形式返回。源码中通过new Gson().toJson(genProps(table))序列化其中genProps的逻辑是对物化视图返回其getMaterializedViewPropMap()其他表返回table.getProperties()。实际内容通常包含replication_num、storage_medium、compression、enable_persistent_index主键表、bloom_filter_columns、dynamic_partition.*等一系列建表/Alter 时写入的 key-value 属性适合用 JSON 解析函数或客户端反序列化后做精细分析。TABLE_ID表的全局唯一 IDBIGINT取自table.getId()。它可与tables系统表、partitions、tablets等元数据视图中的表 ID 关联作为跨视图联查的连接键。注意 TABLE_ID 与业务侧可见的TABLE_ID如通过SHOW CREATE TABLE的注释所见是同一标识。数据链路一条 SQL 查询背后的 FE/BE 协作了解字段含义后再看tables_config的数据是如何流转的这对排查查询结果为什么不刷新/不全很有价值。整条链路为SQL 解析与规划用户执行SELECT * FROM information_schema.tables_configFE 识别出SCH_TABLES_CONFIG类型的系统表将扫描任务下发给 BE。BE 发起扫描BE 侧 schema_tables_config_scanner.cpp 的start()方法构造TGetTablesConfigRequest请求——若查询带有WHERE table_schema...谓词会将数据库名写入auth_info.pattern若带有表名过滤则写入table_name字段。RPC 到 FE通过 schema_helper.cpp 中的SchemaHelper::get_tables_config以_call_rpc调用 FE 的getTablesConfigThrift 接口。FE 生成结果FE 侧 InformationSchemaDataSource.java 的generateTablesConfigResponse遍历授权数据库与表逐表生成TTableConfigInfo最终回填到resp.tables_config_infos。BE 填充 Chunkscanner 的fill_chunk()按 slot_id 将每个字段写入向量化 Chunk逐行返回给查询执行引擎。权限与过滤查询不是全库裸奔generateTablesConfigResponse中体现了严格的行级权限控制先通过getAuthDbRequestResult基于当前用户的库级权限预过滤数据库集合WHERE table_schema谓词在此阶段被下推消化再对每张表调用Authorizer.checkAnyActionOnTableLikeObject做对象级授权校验未通过授权的表会被静默跳过记录 INFO 日志。因此普通用户查询tables_config只会看到自己有权限的库表这是该表在生产环境可直接开放查询的安全基础。并发安全细粒度锁而非库级大锁源码注释特别说明了锁策略遍历前先对表列表做无锁快照db.getTables()返回并发安全副本然后仅对当前正在读取的单表加LockType.READ级别的表级库级锁lockTableWithIntensiveDbLock读取完毕立即释放。这样的设计避免了持有整个数据库的读锁长时间阻塞 DDL/ALTER 操作也通过加锁后二次校验getTable(db.getId(), table.getId())防止并发 DROP 导致的悬空引用——从源码结构看这是针对元数据一致性做过的专门优化。实战查询示例1. 查看某数据库下所有表的模型与分桶情况SELECT TABLE_NAME, TABLE_MODEL, PARTITION_KEY, DISTRIBUTE_KEY, DISTRIBUTE_TYPE, DISTRIBUTE_BUCKET, SORT_KEY FROM information_schema.tables_config WHERE TABLE_SCHEMA tpcds ORDER BY TABLE_NAME;2. 筛选主键模型与更新模型的表及其主键SELECT TABLE_SCHEMA, TABLE_NAME, PRIMARY_KEY FROM information_schema.tables_config WHERE TABLE_MODEL IN (PRI_KEYS, UNQ_KEYS) AND PRIMARY_KEY ! ;3. 结合 TABLE_ID 跨视图关联例如关联 tablet 信息SELECT tc.TABLE_SCHEMA, tc.TABLE_NAME, tc.TABLE_MODEL, tc.TABLE_ID FROM information_schema.tables_config AS tc LEFT JOIN information_schema.tables AS t ON tc.TABLE_ID t.TABLE_ID WHERE tc.TABLE_SCHEMA dwd;4. 检查存在表级自定义属性的表PROPERTIES为 JSON 串可结合json_extract等函数或客户端侧解析筛选出设置了特定属性的表例如SELECT TABLE_NAME, PROPERTIES FROM information_schema.tables_config WHERE TABLE_SCHEMA dwd AND json_extract_string(PROPERTIES, $.replication_num) IS NOT NULL;支持范围与注意事项从 InformationSchemaDataSource.java 的源码分支可以确认当前支持范围完整返回全部配置字段OLAP 表明细/聚合/更新/主键、OLAP 外表、Lake 系列表、物化视图Lake 物化视图亦在内这些类型进入genNormalTableConfigInfo获取完整配置仅返回引擎类型普通视图View其余字段保持默认空值待支持源码中留有TODO(cjs): other table type (HIVE, MYSQL, ICEBERG, HUDI, JDBC, ELASTICSEARCH)的注释表明 Hive、MySQL、Iceberg、Hudi、JDBC、Elasticsearch 等外表类型的配置信息尚未纳入本表。另外两点使用提示一是由于数据由 FE 实时生成查询结果始终反映最新元数据状态无需担心缓存过期二是PRIMARY_KEY对明细模型、聚合模型返回空字符串SORT_KEY在未显式声明排序键时回退为主键解读结果时需结合TABLE_MODEL一并判断。源码指引官方字段文档tables_config.mdFE 系统表定义TablesConfigSystemTable.javaFE 数据生成核心逻辑InformationSchemaDataSource.javaBE 扫描器列定义与填充schema_tables_config_scanner.cppBE→FE RPC 封装schema_helper.cpp掌握tables_config后你可以用一条 SQL 审计全集群表的建表配置、定位分桶异常或主键设计也可以结合其他系统表构建自己的元数据管理视图。【免费下载链接】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),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询