资讯动态

Hudi VECTOR 类型跨引擎验证测试文件:生成方法、表结构与底层实现剖析

发布时间:2026/10/6 12:16:11 来源:尧图企业网站定制
数据湖湖仓一体大数据数据存储【免费下载链接】hudiUpserts, Deletes And Incremental Processing on Big Data.项目地址https://gitcode.com/gh_mirrors/hud/hudi点击查看免费下载本文围绕 Hudi 仓库中hudi-common/src/test/resources/vector_cross_engine_validation/README.md所记录的测试资源生成规范展开系统讲解如何用 Spark 3.5 生成包含 VECTOR 列的 MOR/COW 测试表、如何用 zip 打包为跨引擎验证素材并结合仓库源码HoodieSchema.java、HoodieVectorUtils.java剖析 VECTOR 类型在 Hudi 中的逻辑层与物理层设计。读者读完后将掌握 VECTOR 测试表的建表 SQL、类型描述符语法、底层字节级编码规则以及这些测试文件在跨引擎Spark、Parquet、Lance 等一致性验证中的定位。一、测试资源目录概览一份面向跨引擎验证的 VECTOR 数据集在 Hudi 仓库中hudi-common/src/test/resources/vector_cross_engine_validation/目录承担着一个专门职责存放用于跨引擎验证的 VECTOR 类型测试数据。当前目录内包含三个文件文件作用README.md说明测试文件的生成方式、表结构与打包命令即本文主体依据vector_mor.zipMOR读时合并表数据集的压缩包vector_cow.zipCOW写时复制表数据集的压缩包从命名可以推断这两个 zip 包分别对应同一份 VECTOR 表 schema 在MOR与COW两种表类型下的落盘数据目的是让不同查询引擎如 Spark、Presto/Trino、Lance 文件格式等读取同一批 Hudi 表文件时VECTOR 列的解析结果保持一致。README 明确指出这些测试文件由 Spark 3.5 生成Spark3.5 is used to generate these test files.因此它们天然携带 Spark 3.5 写入路径产生的表结构与文件格式特征。二、表结构定义MOR 与 COW 两套 VECTOR 建表 SQLREADME 给出了一套同时覆盖 FLOAT / DOUBLE / INT8 三种向量元素类型的表 schema分别以 MOR 和 COW 两种表类型创建。2.1 MOR 表CREATE TABLE vector_table_mor ( id BIGINT, name STRING, embedding1 VECTOR(128) COMMENT document float embedding, embedding2 VECTOR(128, DOUBLE) COMMENT document double embedding, embedding3 VECTOR(128, INT8) COMMENT document INT8 embedding, ts BIGINT ) USING hudi LOCATION /tmp/hudi_vector_table_mor TBLPROPERTIES ( primaryKey id, preCombineField ts, type mor, hoodie.index.type INMEMORY );2.2 COW 表CREATE TABLE vector_table_cow ( id BIGINT, name STRING, embedding1 VECTOR(128) COMMENT document float embedding, embedding2 VECTOR(128, DOUBLE) COMMENT document double embedding, embedding3 VECTOR(128, INT8) COMMENT document INT8 embedding, ts BIGINT ) USING hudi LOCATION /tmp/hudi_vector_table_mor TBLPROPERTIES ( primaryKey id, preCombineField ts, type cow );2.3 逐字段解析主键与预合并字段primaryKey id、preCombineField ts这是 Hudi 表的标准配置——id决定 upsert 的去重粒度ts决定同主键记录之间的新旧取舍。索引配置差异MOR 表显式声明了hoodie.index.type INMEMORY内存索引而 COW 表未声明使用默认索引。跨引擎验证场景下索引类型会影响写入路径的记录定位方式但不会改变 VECTOR 列的物理编码这正是两套表适合做对比验证的原因。VECTOR 列设计三列 embedding 覆盖了 README 想验证的全部元素类型组合embedding1 VECTOR(128)维度 128元素类型取默认 FLOAT4 字节/元素embedding2 VECTOR(128, DOUBLE)维度 128DOUBLE 元素8 字节/元素embedding3 VECTOR(128, INT8)维度 128INT8 元素1 字节/元素有符号 8 位整数。一个需要留意的细节README 中 COW 表的LOCATION与 MOR 表一致/tmp/hudi_vector_table_mor。从表名与常规实践推断这很可能是原文档中的笔误实际生成时 COW 表应使用独立的路径例如/tmp/hudi_vector_table_cow否则两表会指向同一目录造成覆盖。使用者按原文档复现时建议将 COW 表的 LOCATION 改为独立目录。三、VECTOR 类型描述符语法从 SQL 到源码的映射上述建表 SQL 中的VECTOR(128)、VECTOR(128, DOUBLE)、VECTOR(128, INT8)并非凭空出现的语法它对应 Hudi 内部 schema 模型中的类型描述符type descriptor解析逻辑。在 HoodieSchema.java 中parseTypeDescriptor对VECTOR分支做了严格约束描述符必须携带维度参数params.isEmpty()时报错最多支持 3 个参数dimension、可选的elementType、可选的storageBacking维度通过Integer.parseInt解析非数字抛IllegalArgumentException元素类型缺省为FLOAT存储支撑缺省为FIXED_BYTES。因此语法可总结为VECTOR(dimension[, elementType[, storageBacking]])其中elementType∈ {FLOAT,DOUBLE,INT8}storageBacking当前仅支持FIXED_BYTES。这一语法在仓库测试中同样有迹可循TestHoodieSchemaConversionUtils.scala 中的类型元数据字段即包含VECTOR(128)、VECTOR(64, DOUBLE)、VECTOR(32, INT8)等描述符与跨引擎验证表的三列设计一一对应。四、底层实现VECTOR 在 Hudi 中的逻辑层与物理层设计要理解这份测试文件的正确性依赖什么需要深入 Hudi 的 VECTOR 类型实现。设计依据可追溯至 rfc-99/vector-appendix.md该文档明确了 VECTOR 逻辑类型的目标支持在 blob文本、图像、音视频与向量嵌入并存的数据上执行 KNN 风格向量检索服务于 RAG 等场景。4.1 逻辑层Avro 逻辑类型 三要素在 HoodieSchema.java 中HoodieSchema.Vector通过包装 AvroFIXEDschema 并挂接VectorLogicalType实现VectorElementType枚举L2037-L2072FLOAT每元素 4 字节IEEE 754 单精度、DOUBLE8 字节双精度、INT81 字节有符号 8 位整数StorageBacking枚举L2077-L2095当前仅FIXED_BYTES一种物理支撑VectorLogicalTypeL2420-L2470在 Avro schema 上写入dimension、elementType、storageBacking三个属性并校验dimension 0通过VectorLogicalTypeFactoryL2475-L2502从 schema 反序列化时元素类型缺省回退FLOAT、存储支撑缺省回退FIXED_BYTES。这与 RFC 附录中给出的 Avro schema 模型完全一致{ type : fixed, name : vector, size : 3072, logicalType : vector, dimension : 768, elementType : FLOAT, storageBacking : FIXED_BYTES }4.2 物理层定长打包字节 小端字节序逻辑层之上向量在磁盘上的物理表示采用定长紧凑字节数组这正是FIXED_BYTES的含义也是 README 中三个测试表能被不同引擎无歧义读取的前提维度为 D、元素类型为 FLOAT 的向量恰好占用D * 4字节DOUBLE 为D * 8字节INT8 为D * 1字节总长度即dimension * elementType.getElementSize()元素按**小端序LITTLE_ENDIAN**连续序列化该常量定义为VECTOR_BYTE_ORDERHoodieSchema.java#L2430在 Parquet 文件格式中映射为FIXED_LEN_BYTE_ARRAY(D * 元素字节数)并携带 VECTOR 元数据。4.3 解码路径HoodieVectorUtils读取侧的解码逻辑集中在 HoodieVectorUtils.javadetectVectorColumns(HoodieSchema)L45-L58遍历记录型 schema 的字段凡是getType() HoodieSchemaType.VECTOR的列按字段序号收集为字段序号 → Vector schema映射供下游引擎按列解码decodeVectorBytes(byte[], dim, elemType)L81-L109先用bytes.length dim * elemType.getElementSize()做严格校验长度不匹配直接抛异常再按小端序将字节流解码为float[]、double[]或byte[]。这解释了 README 三列设计的用意FLOAT / DOUBLE / INT8 三种元素类型对应三条解码分支任何一个引擎只要遵守定长 小端约定就能得到一致的数组结果——这正是跨引擎验证要锚定的契约。4.4 文件级向量列元数据为了让任意读取方不依赖 Hudi schema 存储也能识别向量列Hudi 在文件页脚记录了向量列清单。常量VECTOR_COLUMNS_METADATA_KEY hoodie.vector.columnsHoodieSchema.java#L228以逗号分隔的列名:VECTOR(dim[,elemType])形式写入 Parquet footer 或 Lance schema 元数据例如embedding:VECTOR(128),tags:VECTOR(64,INT8)。跨引擎验证数据集之所以具备普适性正是因为这类信息被固化在了文件自身的元数据中而非依赖外部 catalog。五、测试文件生成流程从写入到打包README 明确了两步式生成流程。第一步使用 Spark 3.5 执行建表与数据写入。执行上文的建表 SQLMOR/COW 各一张随后通过 Spark 的 Hudi DataSource API 或INSERT语句写入向量数据。写入时Spark 侧的向量数组如array(cast(0.1 as float), ...)会被序列化为上述定长字节格式落盘。仓库中 docker/demo/sparksql-vector-type-sql.commands 提供了一个可运行的最小示例创建含embedding VECTOR(3)的表后依次执行INSERT、UPDATE、MERGE、DELETE全生命周期每次写命令都会触发自定义类型元数据的重新挂接注释中明确提到 re-attach path可用于验证 VECTOR 类型在各类 DML 下的稳定性。第二步打包测试目录。README 给出的打包命令如下cd /path/to/test/files/ zip -r $TABLE_DIR_NAME.zip $TABLE_DIR_NAME即以表目录名为单位递归压缩生成vector_mor.zip、vector_cow.zip。这里的$TABLE_DIR_NAME即vector_table_mor、vector_table_cow对应的数据目录如 MOR 表位于/tmp/hudi_vector_table_mor。压缩后数据与元数据以单文件形式随仓库分发供测试与 CI 解压复现无需现场搭建 Spark 3.5 写入环境。六、测试文件的消费方式与配套验证6.1 测试文件的用途从目录命名cross engine validation和文件构成可以推断vector_mor.zip/vector_cow.zip的解压产物用于文件格式层验证 Parquet 文件中FIXED_LEN_BYTE_ARRAY向量列的读写一致性引擎层验证 SparkSQL/DataFrame之外的其他引擎读取 Hudi 表时VECTOR 列的 schema 解析与字节解码不产生偏差表类型层对比 MOR 与 COW 两套表在相同 schema 下的落盘差异MOR 含 log 文件、COW 直接生成 parquet base 文件确保两种表类型都覆盖验证。6.2 仓库内的向量检索端到端验证虽然跨引擎数据包主要服务文件/引擎一致性Hudi 仓库内还有一套与之互补的端到端向量检索验证TestHoodieVectorSearchFunction.scala 通过表值函数hudi_vector_search(view, column, query_vector, k[, metric])执行 KNN 检索支持cosine默认、l2、dot_product三种距离度量并在结果中输出_hudi_distance伪列同时覆盖了 k 大于语料行数、带 WHERE 子句、作为子查询等边界场景。这与 README 中的 VECTOR 测试数据互为印证前者验证向量怎么存后者验证存好的向量怎么查。七、复现与扩展建议复现前置条件需要 Spark 3.5 对应版本的 Hudi bundle含 VECTOR 类型支持并按第二节 SQL 建表写入COW 表建议改用独立 LOCATION 避免与 MOR 表目录冲突。扩展新维度/新元素类型只需调整描述符例如VECTOR(512)FLOAT 512 维或VECTOR(64, INT8)重新生成数据包后用 HoodieVectorUtils.java 的解码逻辑做基准校验——定长字节契约保证了任意维度/元素类型组合都有确定性的解码结果。关注点跨引擎一致性最终锚定在定长打包 小端字节序 hoodie.vector.columns文件级元数据这三点上任何引擎接入时都应围绕这三者做断言。八、结语vector_cross_engine_validation目录是 Hudi VECTOR 类型契约即测试思想的具体落地用一份由 Spark 3.5 生成、以 zip 形式分发的 MOR/COW 数据集把逻辑层Avro 逻辑类型三要素、物理层定长字节、小端序、Parquet FIXED_LEN_BYTE_ARRAY与引擎层跨引擎解码一致性串成一条可验证的链路。理解这份 README 及其背后的 HoodieSchema.java 实现是接入 Hudi 向量能力、或为其他引擎适配 VECTOR 列读写的最佳起点。赞分享数据湖湖仓一体大数据数据存储【免费下载链接】hudiUpserts, Deletes And Incremental Processing on Big Data.项目地址https://gitcode.com/gh_mirrors/hud/hudi点击查看免费下载相关推荐VOICEVOX VVPP 引擎包测试文件全解析目录结构、构造方法与校验原理VOICEVOX VVPP 引擎包测试文件全解析目录结构、构造方法与校验原理 本文以 VOICEVOX 开源编辑器仓库中的 tests/unit/backen桌面应用语音Chroma API完全指南掌握Python接口实现蛋白质自动化设计Chroma API完全指南掌握Python接口实现蛋白质自动化设计 Chroma是一个强大的蛋白质设计生成模型通过其Python API开发者和研究人员Jellium Desktop媒体信息导出轻松保存视频与音频参数的完整指南Jellium Desktop媒体信息导出轻松保存视频与音频参数的完整指南 Jellium Desktop作为一款非官方的Jellyfin桌面客户端不仅提供桌面应用音视频上一篇如何掌握Fluent UI HooksReact生命周期完美迁移指南下一篇PHPStan 错误详解property.readOnlyAssignOutOfClass —— readonly 属性在声明类外部被赋值创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑