StarRocks湖仓融合的四种范式

演讲⼈：赵恒—StarRocks—PMC CONTENTS⽬录 StarRocks湖仓融合的四种范式 StarRocks 3.0预览 湖仓融合的难点 为什么需要湖仓融合 为什么需要湖仓融合 什么是数据湖 什么是数据湖？ •云⼚商：基于对象存储S3/OSS/COS构建的统⼀存储•互联⽹公司：⽀持Upsert，Time travel等⾼级特性的存储（Iceberg/Hudi/Delta lake）•传统⽤户：能够存储所有结构化、半结构、⽆结构数据 为什么要⽤数据湖？ •更低的存储成本，更⾼可靠性：从HDFS到对象存储•更好的Table format：⽀持ACID事务，⽀持Schema evolution•更好的File format：⽀持半结构化map、Struct、Json，⽀持嵌套结构。•统⼀的Catalog:统⼀元数据管理、权限管理、统计信息管理、⼊湖管理 为什么要在湖上建仓 为什么湖上建仓（OLAP）？ •数仓加速：基于数据湖的远程IO成本⾼，早期的数据湖格式不成熟，索引不完善，查询性能需要提升，数据湖的底座针对吞吐优化，关注低成本和⾼可靠，不适应⾼性能需求。•实时分析：基于数据湖的存储实时性不够，⽆法解决秒级实效性的问题•⾼并发查询：对于⾼并发查询，我们需要降低数据的扫描量，⼀种是聚合类查询需要通过预计算的⼿段来提⾼并发，⼀种是点查需要有细粒度的数据裁剪和索引优化来提升。 引⼊OLAP的问题？ •数据的导⼊是⼀个复杂问题，不仅仅是数据成本的上升，也让管理成本成倍增长•如何维护数据和元数据⼀致性•OLAP对AI等需要开放的底层⽂件格式的业务不够友好 为什么要湖仓融合？ •简化技术架构，降低运维成本•Single Source of Truth：只有⼀份数据，基于相同的数据来计算•有湖仓融合的数据底座才可能做统⼀的上层数据治理 Lakehouse分层与StarRocks 湖仓融合的难点 湖和仓的差异— Catalog和建表 •都有类似的Catalog层次结构•Catalog —database — table •建表语句和数据分布上有差异 湖和仓的差异Table format •Table Format对⽐ •Copy on write / Merge on read —> Delete and insert (Merge on write)•对⽐Merge-on-read:避免sort merge的开销，不存在频繁写⼊下读放⼤的问题•对⽐Copy-on-write:避免过多的写放⼤•对⽐Delta store：能够充分利⽤⼆级索引•StarRocks可以补充数据湖上秒级实时性的场景 StarRocks as Lakehouse 性能的差异 •本地IO和远程IO：通过Local cache加速•File Format :•数据类型：Json/Struct/Map，⽀持bitmap/Hll, Fast Decimal•索引：聚簇索引和⼆级索引•数据分布•⽀持colocated join, colocated aggregation•hash分布可以进⼀步裁减提升点查性能•查询引擎•向量化引擎的MPP执⾏框架•Query cache•统计信息•湖上统计信息还⽐较基础，SR提供ndv ngram等复杂统计信息 03 湖仓融合1：数据湖查询加速 湖仓融合2：湖仓分层建模 湖仓融合3：实时数仓与数据湖融合 湖仓融合4：StarRocks 3.0云原⽣湖仓 湖仓融合⼏种模式的总结 StarRocks3.0存算分离 StarRocks 2.0-3.0 StarRocks 3.0存算分离和StarOS StarRocks 3.0存算分离和StarOS 为什么要存算分离？ •计算和存储的增长并不匹配，随着数据量变⼤，不⽅便扩展•计算的变化弹性很⼤，尤其对于Adhoc场景下计算集群弹性会很⼤•⽀持多集群能⼒，把不同的负载分配到不同的集群上•需要适配云原⽣的架构，充分利⽤云上的池化资源能⼒ StarRocks的存算分离有什么特⾊？ •StarRocks的存算分离基于StarOS，有良好的架构设计，StarOS定位⼀个通⽤的云原⽣基础架构，让各种应⽤能够快速的获得云原⽣的能⼒•我们的存算分离既能⽀持云上的基础设施（对象存储）也能⽀持⾃建的传统基础设施（HDFS），既可以在云上部署，也可以在本地部署。•StarRocks的存算分离可以解决之前云原⽣数仓中实时问题解决不好的困难。让实时的数据和可以在底层的湖上做统⼀管理 StarRocks存算分离的价值：降低存储成本 StarRocks存算分离的价值：资源隔离 StarRocks存算分离的价值：Multi-AZ StarRocks存算分离的价值：Multi-cluster和弹性 StarRocks 3.0存算分离和StarOS 当前能⼒ •StarRocks存算分离，⽀持⾮PK表的所有功能表级别的TTL和单副本，故障⾃动恢复，降低总体持有成本，适合解决⽇志分析场景的降本 优化⽅向 •多集群⽀持，增强弹性能⼒•Local LogStore、FileStore，统⼀架构•实现完整的Primary key存算分离•FE存算分离，提升横向扩展能⼒ — THANKS — 感谢您的观看 演讲⼈：赵恒—StarRocks—PMC