各位 StarRocks 的新老用户：
StarRocks 近期公布了 2.1 版本，外围更新有反对 Apache Iceberg 表面、公布 Pipeline 执行引擎、反对多达 10000 列的表、优化首次 Scan 和 Page Cache 的性能、反对 SQL 指纹等。
以下是具体介绍，欢迎您降级应用、多多反馈！
反对 Apache Iceberg 表面（公测中）
Apache Iceberg 是目前最为风行的构建数据湖的计划之一。在反对了 Hive 表面查问之后，StarRocks 也反对了间接查问 Apache Iceberg 数据湖上的数据，让用户在无需导入数据的状况下，就能实现对数据湖的极速剖析。
在 TPC-H 100G 测试集上，StarRocks 通过 CBO 优化器、向量化执行和 C++ Native 执行等优化， 查问性能是 Trino (PrestoSQL) 的 3 – 5 倍 。
后续，咱们会进一步优化查问 Apache Iceberg 数据湖的性能，同时也会实现查问 Apache Hudi 等其余数据湖计划的性能。
公布 Pipeline 执行引擎（公测中）
执行引擎在多核调度方面，原有任务模型是采纳线程调度，存在两个显著问题：一，在高并发查问场景下，数据依赖和 IO 操作的阻塞会引起较多上下文切换，导致较高的调度代价；二，简单查问的并行度设置过于简单。
新公布的 Pipeline 执行引擎，采纳更高效的协程调度机制，并且原有数据依赖和 IO 操作采纳了异步化执行，升高了上下文切换的代价。 在高并发场景下，局部查问性能晋升为原来的 2 倍，CPU 利用率也显著晋升 ；在 SSB、TPCH 和 TPCDS 测试集上，总体性能也有不错的晋升。同时还实现了查问并行度的自适应设置，您无需再手动设置并行度变量 parallel_fragment_exec_instance_num。
反对多达 10000 列的表
在传统的数仓模型建设中，往往会建设一些大宽表以简化应用和优化查问性能。尤其是在用户画像等场景中，几百上千列的宽表也比拟常见，一些超大客户会应用几千列的表。但在导入几千列的大数据（几亿行）后，特地是还有大字符串的场景，原有按整行 Compaction 的形式会占用大量内存，很容易触发 OOM，并且 Compaction 速度也变慢很多。
新版本重构了 Compaction，按列分组分批进行多版本数据的 merge，并且优化了对大字符串的反对，缩小了内存的应用。最终， 在多达 10000 列表的大数据量导入场景下，内存节俭了数 10 倍，Compaction 性能也晋升为原来的 3 倍 。
优化首次 Scan 和 Page Cache 的性能
在做大数据分析时，一些冷数据须要从磁盘读取（首次 Scan），一些热数据则能够间接从内存读取，两种场景下的查问性能可能会相差几倍甚至几十倍，外围起因是磁盘的随机 IO。StarRocks 通过缩小文件数量、索引懒加载、调整文件构造等，缩小随机 IO，晋升了首次 Scan 的性能，尤其在 HDD 环境中，性能晋升显著。
对于 SSB-100G 测试集中几个首次 Scan 对查问性能影响较大的 SQL（如 Q2.1/Q3.1/Q3.2/Q4.1）， 在有首次 Scan 的情景时，其查问性能晋升为原来的 2~3 倍 。
同时，StarRocks 也优化了本身的 Page Cache 策略，一些场景下会间接寄存原始数据，无需通过 Bitshuffle 编码。因而在读取 Page Cache 数据时也无需额定解码，进而大大晋升了查问效率。
反对 SQL 指纹
SQL 指纹是指对同一类 SQL 计算出的一个 MD5 值，其中，同一类 SQL 是指“规范化后只有常量不同的 SQL 文本”。通过汇总统计分析 SQL 指纹及相干信息，咱们就可能很不便地理解有哪些类型的 SQL、它们呈现的频率 / 耗费的资源 / 解决的时长等，从而能够对耗费资源多且不合理的 SQL，优先进行高效的剖析优化。
SQL 指纹次要被用于慢查问优化、系统资源应用（CPU/ 内存 / 磁盘读写 等）优化。比方，如果发现集群的 CPU/ 内存应用不太高、但磁盘应用常常打满时，能够统计磁盘读占比最高的一些 SQL 指纹，再进一步剖析具体 SQL 读磁盘的合理性，就能够找到一些优化点。
其余优化
- 公测中的新性能反对字符串最大长度为 1MB：在一些简单的业务和场景中，JSON 等 Schema-less 剖析常常会被用到，1MB 的字符串存储可能满足绝大多数场景，联合相干函数，能很好地满足此类剖析需要。
- 反对 CTAS（CREATE TABLE AS SELECT）语法：不再须要当时建表，查问数据即可实现 ETL 操作并导入数据到新表中；联合一些调度，就能够轻松实现轻量级的数仓建模。
- 去除了 JSON 导入中单个 JSON 文件不超过 100MB 大小的限度，并优化了 JSON 导入性能：让您能够轻松导入大 JSON 文件，以及轻松对接大流量的 Kafka 数据。
- 主键模型（Primary Key Model）反对变更表构造（Schema Change）。
- 反对建表语句的工夫戳字段定义为 DEFAULT CURRENT_TIMESTAMP。
- 新增函数 ANY_VALUE、ARRAY_REMOVE、哈希函数 SHA2。
- 反对 Hive 的存储格局为 CSV，优化了通过表面形式读取 Hive 数据的性能。
- 反对导入带有多个分隔符的 CSV 文件。
- 优化 Bitmap Index 性能。