觉得 StarRocks 数据湖查询不够极速吗？很有可能是你打开的姿势不对。
但别着急，这篇文章就是要来帮助大家正确的打开 StarRocks 湖仓分析新范式！
文章的最开始，我们要回复一个用户常问的问题，那就是数据在 Hive/Iceberg/Hudi 上，要不要导入数据到 StarRocks？如果你不确定要不要导数据进来 StarRocks，答案是 不要导进来（TPC-DS 1TB测试，直接查性能仅比导入差12%） ，先打开 data cache https://docs.starrocks.io/en-us/latest/data_source/Block_cache
StarRocks 极速数据湖查询到底有多极速？
-
Env
-
Tpcds 1tb
-
8 r6i.2xlarge (8c64g)
-
-
Results
-
Hive: 480s
-
Iceberg: 470s
-
Native: 420s
-
为什么你测试不出来“极速”？
可能是：
-
你的查询太简单，scan 成为性能瓶颈
-
你的存储性能太差
-
你的存储存在慢节点
-
你的存储资源被其他组件打满了
-
怎么正确的使用数据湖查询？
-
最简单的方式是直接查询，只要你的存储性能够好，并且你的 SQL 足够复杂，那么直接查就能比其他查询引擎有倍数的性能提升
-
如果你的存储性能一般，或者你追求更加极致的性能，那么请把 data cache 打开 https://docs.starrocks.io/en-us/latest/data_source/Block_cache
-
和 Trino 对比，如果因为存储性能差而无法显示出性能优势，那么可以从另一个角度出发做对比：机器数量降低到 Trino 的 1/N （例如 1/3），但是查询性能和 Trino 相当
什么时候你才需要考虑导数据进 StarRocks？
Hive Table 和 Native Table 的差别
-
第一次访问的时候，Hive Table 需要从 Hive metastore（HMS）/Glue 获取元数据，并缓存；需要从 HDFS/S3 获取数据，并缓存。
-
从第二次访问开始，Hive Table 就不需要和外部系统进行交互（全 cache 的状态），此时 Hive Table 和 Native Table 基本是一样的。因此大部分情况下，使用了 cache 的 Hive Table 和 Native Table 是没有区别的，在性能上应该接近
导进来有什么坏处？
-
增加了用户的维护成本，用户需要维护一系列 job 来保证持续的导入，以及导入失败之后的错误处理等问题
-
增加了用户的使用成本，导进来的数据和 Hive 上的数据存在一致性问题，用户需要判断什么时候查 Native Table，什么时候查 Hive Table
-
1:1的导入无法带来性能提升（除非用户原来用的 zstd，导进来改成了 lz4 或者无压缩等，见下节）
导进来有什么好处？
-
如果是1:1导进来，没有好处，只有在涉及下面情况下，才考虑导进来：
-
改变了数据存储结构
-
根据某些 column 做分区或分桶
-
根据某些 column 做排序
-
原本 Hive Table 采用了比 lz4 更高压缩率的压缩算法，例如 zstd
-
采用了 colocate（备注：这个 Hive Table 也能做，不过现在没支持）
-
-
做了预计算
-
加了 bitmap 或者 bloom filter 等 index（Hive Table 上 parquet 文件格式也能支持 bloom filter，不过现在没支持）
-
使用了聚合表
-
使用了全局低基数字典
-
-