深圳 网站建设设计,wordpress完整备份,网站主机建设方案,国内老牌的网站制作半结构化分析主要是指对 MAP#xff0c;STRUCT#xff0c;JSON#xff0c;ARRAY 等复杂数据类型的查询分析。这些数据类型表达能力强#xff0c;因此被广泛应用到 OLAP 分析的各种场景中#xff0c;但由于其实现的复杂性#xff0c;对这些复杂类型分析将会比一般简单类型… 半结构化分析主要是指对 MAPSTRUCTJSONARRAY 等复杂数据类型的查询分析。这些数据类型表达能力强因此被广泛应用到 OLAP 分析的各种场景中但由于其实现的复杂性对这些复杂类型分析将会比一般简单类型要更困难和耗时例如 需要对 MAPSTRUCTJSON 等数据类型中的某个字段进行查询分析。由于这些复杂类型会被存储为一个整体因此需要先将整个半结构化类型的字段先从存储层读取上来然后再对其中的某些字段进行分析IO效率较低。 对复杂类型进行较为耗时的分析计算(聚合排序等等)查询的实时CPU 开销可能也是一个不可忽略的性能影响因素。 面对上述的挑战StarRocks在3.1 版本正式推出生成列(Generated Column)特性提供一种透明加速的解决方案能有效提升半结构化数据的分析效率令用户拥有更极速的分析体验。 生成列介绍 生成列是一种特殊的列可以在建表语句或 Schema Change 语句中指定生成列绑定到一个标量表达式上当数据导入时会自动根据表达式定义进行计算并且将其计算结果写入到生成列中。 在半结构化分析的场景中可以将复杂耗时的标量表达式绑定在某个生成列上在数据导入阶段提前将结果计算好并且持久化到磁盘中。当需要进行查询分析时即可马上获得表达式计算的结果。 生成列的查询改写 当希望查询生成列保存的表达式计算结果时可以直接在 SQL 中指定生成列的列名但是这种方法意味着需要调整已有业务 SQL很难完全做到无缝对接。 为了进一步提升功能的使用体验简化使用流程StarRocks 支持生成列自动查询改写。在生成执行计划时SQL 优化器将会检查 SQL 中所有的表达式并且将那些已经绑定到生成列上的表达式改写成查询生成列列值。 例如上述例子中如果在某个查询中需要获取 colc 中的 a 字段则执行查询SELECT get_json_string(json_string(tbl.colc), $.a) FROM tbl执行过程大致如下 可见优化器自动将表达式改写为查询生成列的值实现透明加速。 高效的生成列加列 在实际应用生成列的使用场景中在已有的表添加生成列可能是一个高频操作。例如可能在任意时间点发现某个表达式计算存在性能瓶颈因此希望添加生成列以进行查询加速。 StarRocks 支持高效的加列操作对于添加普通列存储引擎并不会真正重写物理文件而只是将物理文件重新 link 到新 Tablet 的路径下修改元数据完成加列操作。但是如 MODIFY COLUMN 这类 Schema Change 操作由于需要改变存量数据的内容因此会重写所有物理文件。类似地对于生成列加列来说由于需要存储新增的生成列表达式的计算结果重写数据似乎也是不可避免的。但是如果仍然采用全量重写物理文件的方案将无法很好适应频繁加列的场景加列的代价太大。 为了进一步提高生成列加列的效率StarRocks 针对生成列加列进行了专门的优化。当添加一个生成列时不会改写存量的物理文件而是为每一个存量的 segment 生成一个只包含生成列值的 cols 文件(物理格式和 segment 文件一样但只包含生成列一列数据)当需要查询这些存量数据时StarRocks 会自动将 segment 和 cols 文件的内容进行合并获得正确的查询结果。 总的来说生成列加列优化后读 I/O 只涉及到生成列表达式的引用列写 I/O 只涉及到生成列本身的表达式结果整个 Schema Change 的 I/O 效率相比完全重写有大幅提高更好支持实时动态生成列加列的用户需求。 效果验证 为了更好验证生成列对半结构化分析的加速效果我们进行了简单的测试验证。 集群信息StarRocks v3.1 1FE1BE 104C376GB 创建一张如下的数据表 CREATE TABLE t ( id bigint(20) NOT NULL COMMENT , array_int ARRAYint(11) NOT NULL COMMENT , json_data json NOT NULL COMMENT , gc_1 double NULL AS array_avg(test.t.array_int) COMMENT , gc_2 ARRAYint(11) NULL AS array_sort(test.t.array_int) COMMENT , gc_3 varchar(65533) NULL AS get_json_string(json_string(test.t.json_data), $.a) COMMENT ) ENGINEOLAP PRIMARY KEY(id)COMMENT OLAPDISTRIBUTED BY HASH(id) BUCKETS 48 PROPERTIES (replication_num 1,in_memory false,storage_format DEFAULT,enable_persistent_index false,replicated_storage true,compression LZ4) 普通列数据创建方式 id作为 primary key 列保证唯一。 array_int长度为 10000 的 ARRAY 保存的都是随机数。 json_data包含两个 keykey a 对应的 value 为整型 1key b 对应的value 是长度为 100 个 uuid 构成的字符串 性能测试使用下面的 query q1:SELECT get_json_string(json_string(json_data), $.a) FROM Aq2:SELECT array_avg(array_int) FROM A; 测试结果 从上述的测试结果可知 q1使用生成列提取大 JSON 字段中的某个子字段在查询阶段大幅节省了读取 JSON 字段的 I/O 消耗查询性能提升达 4 倍以上。 q2使用生成列对大 ARRAY 字段进行聚合计算(计算平均值)在查询阶段不仅节省读取该半结构化数据字段的 I/O 消耗同时也大幅节省了 ARRAY 聚合计算所带来的 CPU 消耗获得百倍的性能提升。 总结 生成列功能是一种加速半结构化分析的有效手段当面对复杂的半结构化表达式计算时可以为其添加对应的生成列在导入阶段自动完成表达式计算并将结果持久化。在查询阶段通过优化器的自动改写直接从生成列中获得表达式计算结果避免实时的表达式计算实现透明加速。 通过使用生成列用户能大幅减少查询时复杂表达式的 I/OCPU 等资源消耗在不同的场景下获得数倍甚至百倍的性能提升。 本文由 mdnice 多平台发布