网站开发学什么语言好,模板网站做外贸可以吗,网站服务器的选择有哪几种方式,微信商城是正规的吗在 11 月 17 日举行的 StarRocks Summit 2023上#xff0c;StarRocks TSC Member、镜舟科技 CTO 张友东详细介绍了 StarRocks 社区的发展情况#xff0c;并全面解析了 StarRocks 的核心技术与未来规划#xff1b;我们特意将他的精彩演讲整理出来#xff0c;以帮助大家更深入… 在 11 月 17 日举行的 StarRocks Summit 2023上StarRocks TSC Member、镜舟科技 CTO 张友东详细介绍了 StarRocks 社区的发展情况并全面解析了 StarRocks 的核心技术与未来规划我们特意将他的精彩演讲整理出来以帮助大家更深入地了解 StarRocks 。 社区概览 随着数字技术的发展数据呈爆炸式增长数据类型越来越丰富对数据价值挖掘的实时性要求不断提升业务场景也越来越复杂度。在过去几年里数据分析的需求通常采用多套系统组合的方式来完成比如采用 Kylin 在支持 BI 报表场景采用 Trino、Impala 支撑交互式分析场景采用 ClickHouse、Druid 来支撑实时分析场景StarRocks 希望通过技术创新简化数据技术栈用户可以借助 StarRocks 一个引擎实现全场景的数据分析。 StarRocks 从2021年9月正式开源在过去两年时间里Github star 5700有近300位开发者参与社区贡献对齐到两年的时间里StarRocks 同类开源数据库项目里增长最快的。2022年底StarRocks 项目正式捐赠给了 Linux Foundation更加开源开放希望能吸引到全世界的开发者和用户参与社区建设。 StarRocks 目前已经在各个行业的标杆用户落地包括互联网、游戏、零售、物流、制造、金融等行业有超过 300家市值10亿美金以上的大型用户在生产环境使用 StarRocks场景覆盖 BI 报表、交互式探寻分析、实时分析、湖仓分析等一系列场景其中很多用户已经采用 StarRocks 实现了全场景的数据分析架构统一。 StarRocks 开源社区非常活跃社区开发工作由镜舟科技主导推进贡献了70%以上的核心代码随着社区不断的发展壮大目前吸引了阿里云、腾讯、火山引擎、滴滴出行等头部企业的参与从 StarRocks 2.4 版本开始阿里、腾讯等企业开始持续给社区贡献重点特性包括物化视图、CN 弹性节点、Pulsar 数据源、Paimon catalog 等一系列的重要特性。 StarRocks 开源至今经历了3个大版本的迭代分别是 1.0、2.0 以及现在正在迭代的3.0大版本一直以‘极速统一’为中心发展。 1.0 版本主打性能借助 CBO、向量化引擎、Runtime filter等技术性能方面做到业界领先这些最核心的基础 Feature 已经在生产环境稳定运行2年以上为 StarRocks 广泛应用打下了坚实的基础。 2.0 围绕融合统一支持了 Pipeline 引擎、主键模型、数据湖分析、物化视图、资源隔离等一系列的能力让更多的分析 workload 能同时在 StarRocks 上运行从而达到统一的目的这些特性已经在生产环境稳定运行一年以上。 3.0 围绕湖仓一体在存算分离、湖仓分析、物化视图等方向上重点突破用户可以通过 StarRocks 轻松构建湖仓一体架构实现 One DataAll Analytics 的湖仓分析价值。 技术进化 存算分离降本增效弹性伸缩 StarRocks 3.0 版本开始正式支持了存算分离架构StarRocks 由 FE、BE 组件组成FE 负责元数据的管理查询计划构建而 BE 则负责实际的数据存储和查询计划的执行在 3.0 版本之前数据存储在 BE 的本地通过多副本的机制实现高可用在 3.0 存算分离架构下数据则存储到 S3 对象存储或者 HDFS 上实现存算分离架构。 StarRocks 的存算分离架构优势 架构设计高度抽象可扩展性强StarRocks 在实现存算分离时做了一层 StarOS 的抽象将分布式调度、存储访问、Cache 管理等逻辑进行了封装屏蔽了底层环境差异使得在数据库层面可以像开发单机应用一样开发分布式应用 这也使得存算一体与存算分离的开发上能很好的统一。 极简架构易于管理存算分离保持极简架构无需引入复杂的组件依赖能够同时适应在 Cloud 与 On premise 环境里部署。 实时与分析一体存算分离架构下依然可以实现实时的数据导入实时数据查询的能力同时也支持主键模型来满足数据更新的需求。 在性能方面从存算一体架构到存算分离I/O 从访问本地盘变成了访问远端到存储I/O latency 上有明显的增加存算分离架构通过将数据缓存在本地磁盘来进行查询加速这也是业界普遍的做法。存算分离的性能在开启 Data cache 的情况下跟存算一体的查询性能一致在完全冷读的情况下查询延时是存算一体的2-3倍能满足绝大部分的场景的性能诉求。 存算分离架构给业务带来的价值主要有2个点一是降本增效、二是灵活的弹性伸缩 存储层面StarRocks 的存储从三副本本地盘或云盘的存储变成一副本的 S3/HDFS 存储整体存储成本可以下降 80%计算节点无状态可以通过快速弹性来灵活应对业务波峰波谷带来的技术挑战。 在存算分离架构下StarRocks 可以方便的支持 Multi-warehouse 的能力多个 Warehouse 共享一份数据不同 Warehouse 应用在不同的 Workload计算资源可以进行物理隔离Warehouse 内部按需独立弹性伸缩。比如你可以用一个 Warehouse 用来导入如果是离线的场景数据导入完就可以临时把 Warehouse 的资源释放来降低成本然后构建不同的 Warehouse 用来分别用来服务BI 报表与 adhoc 查询的场景彼此间计算物理隔离Warehouse 内部按需弹性伸缩。 极速统一的湖仓分析 StarRocks 从 2.5 版本开始支持统一 Catalog 的管理既能高效分析导入到 StarRocks 里的数据也能直接分析外部数据源的数据。包括开放的数据湖 Hive、Iceberg、Hudi、关系型数据库 MySQL、PostgreSQL Elastic search 等并能实现跨数据源的联邦分析。 极致的数据湖分析性能 StarRocks 可以直接分析外部数据源免除了 ETL 的负担针对开放数据湖的数据StarRocks 做了大量的优化来提升查询效率。 CBO、向量化引擎、Runtime Filter、延迟物化等一系列查询层的技术都可以应用到湖上数据分析。 I/O 合并减少 I/O 次数通过 column、row group 合并访问等机制减少 I/O 次数。 借助 Data cache 降低 I/O 延迟让 I/O 延迟达到访问本地存储的水平。 直观来讲假设以 Trino 直接查询 Hive 作为基准不做任何的数据迁移StarRocks 直接查询数据湖在绝大部分场景下性能提升3倍主要得益于 StarRocks 的向量化引擎、CBO 优化器以及 C Native 的执行在此基础上如果打开 Data cache性能可以达到 Trino 的6倍如果性能还不满足业务需求可以将数据写入 StarRocks 内表借助优化的数据组织细粒度的索引、统计信息等查询性能相比 Trino 10倍性能提升。 目前 StarRocks 社区已经很多用户采用 StarRocks 替换 Trino/Presto 来加速湖上的查询为了减少用户的迁移成本StarRocks 从 3.0 版本开始支持了 Trino 的查询方言整体兼容度 90% 以上使得用户可以无缝替换获得更好的查询性能。 简化建表语句提升数据导入效率 借助 StarRocks 极速的数据湖查询能力能满足大部分的 OLAP 查询需求对于实时性要求非常高的场景则需要以 StarRocks 作为数据存储将数据导入到 StarRocks通过 StarRocks 主键模型的能力来支持秒级别实时更新的能力。 在分布式架构下StarRocks 的一张表要先进行分区每个分区根据 Hash 分成多个桶每个桶内的数据独立存储管理数据按指定的 Key 进行排序。StarRocks 在分区、分桶、排序等方面都做了大量的优化工作使得用户初次建表非常简单如果表的数据组织不满足查询性能要求可以通过 Optimize table 来一键优化。 分区支持根据表达式自动建分区、LIST 分区等简化分区的创建。 分桶支持随机分桶策略支持根据历史分区大小推断新分区的分桶数。 排序各数据模型支持 ORDER BY 来统一制定排序键使得排序键与列定义顺序、主键完全解耦。 在写入方面数据写入之后为了保证高可用数据需要复制到多个节点StarRocks 2.5 版本开始在数据复制写入方面做了很大的提升引入了 Single leader replication 的策略原来的写入流程里每个副本上都要写 memtable、对数据进行排序编码然后 Flush 成 Segment 文件在新的方式只需要一个节点写入数据为 Segment 文件然后将文件物理复制到其他的副本新的写入方式在 CPU、MEMORY、I/O、NETWORK 方面的开销都明显降低使得新的导入方式的性能提升一倍。 主键模型数据更新与查询效率可以兼得 StarRocks 通过 delete insert 的方式支持 OLAP 场景的实时 Update 能力是开源数据库里最先采用该机制实现数据更新的系统。主键模型在功能上持续完善 1支持全内存和持久化两种模式的索引适应不同硬件配置的场景 2支持部分列更新能非常简单的实现多流 join 的需求 3支持条件更新解决高并发写入时数据乱序写入问题。 在性能方面StarRocks 支持了按列更新的模式更新时只需修改对应列的数据性能相比按行更新的模式提升10倍分析型数据库通常采用列存列存部分列更新时需要把原来所有的数据读取出来构造完成的行再重新写入代价非常大对于有的场景用户只对全表少数列更新时则可以采用 StarRocks 按列更新的模式该特性非常有用比如在用户画像的场景用户可以在外部构建好用户不同维度标签的信息然后采用列更新的模式聚合成一张大宽表。 生成列加速半结构化数据分析 StarRocks 原生支持 JSON、ARRY、MAP、Struct 等类型方便半结构化数据的处理。半结构化数据整体存储方便灵活访问但查询性能不高因为在查询过滤时需要将整个字段读出来做计算资源开销非常大。在 StarRocks 3.1 版本里支持了生成列Generated column 的新特性用来加速半结构化数据的查询。 用户可以将数据数据存成 JSON将其中经常需要查询分析的列以生成列的方式单独存储查询的时候会自动改写利用生成列加速反过来如果原始数据是大宽表的形式存储但有多个列或者所有列经常需要一起访问这个时候可以将这些列组合成一个 JSON 对象以生成列的方式存储加速整体的查询。 算子落盘突破查询内存限制 不管数据在开放数据湖还是 StarRocks 里在 2.x 系列的版本StarRocks 查询的中间结果必须能全部加载到内存这样查询速度是最快的但对于一些特别复杂的场景以及一些对延时不敏感的 ETL 场景不太友好。 在 3.0 StarRocks 支持了查询中间结果落盘的机制Aggregate、Join、Order by 的查询中间结果遇到内存不足时可以临时换到磁盘保证查询不会因为内存不足而失败。算子落盘可以较好去支持物化视图构建、轻量级 ETL目前算子落盘在3x16c64g 节点能稳定跑完 TPC-DS 的所有99个查询不会出现内存不足而无法完成的情况同等配置情况下是 Spark 效率的4.35倍。 全新物化视图为更多场景加速 物化视图是数据库领域的经典概念本质上是将查询结果进行物化存储用来加速查询物化视图在 OLTP 数据库作用相对较小但在 OLAP 的场景因为很多的查询比较复杂能发挥很大的作用。在 StarRocks 早期的版本已经有了同步的物化视图支持单表简单聚合算子的查询但是对于复杂的算子以及多表 join 的场景则无法加速。 StarRocks 从 2.4 版本开始研发全新的异步物化视图物化视图可以针对任意 SQL极大的丰富了应用场景支持手动、自动方式来维护物化视图与基表的一致性做到分区粒度的刷新由于物化视图刷新是非常耗资源的为了减少对线上业务的影响物化视图还支持使用资源组来限制后台刷新占用的计算资源。 物化视图主要的价值包括 通过物化视图可以简化数据分层建模将以前通过外部调度工具完成的建模任务放到 StarRocks 里完成简化数据技术栈。 通过物化视图可以做透明查询加速目前 StarRocks 支持 aggregate、join、union 等大部分查询的自动改写虽然是分区粒度的刷新物化视图的改写也可以用在实时分析的场景对于已经刷新的历史分区自动利用物化视图加速对于实时部分尚未刷新的分区则采用物化视图来查询加速然后将结果 Union 起来返回。 物化视图的查询加速、分层建模不仅能给与 StarRocks 的内部表也可以在外部的 Catalog 上构建物化视图数据在外部统一管理确保 Single souce of truth同时通过物化视图按需的加工数据或加速查询。 从建模的视角有了物化视图给 StarRocks 的用户带来了极大的便利。在物化视图之前一般采用预建模的方式数据工程师将各种数据表预先建模加工好给数据分析师去使用而现实中数据建模的常见矛盾在于建模的过程难以跟上业务发展的速度难以衡量数据建模的投入产出。很多时候早期数据的使用者倾向于不做建模直接使用原始数据最后遇到性能问题。有了物化视图之后可以从预建模演变到后建模分析师可以创建逻辑的 view 满足业务需求如果遇到性能问题再根据逻辑view 来构建物化视图加速或者更进一步不做任何提前的预建模直接查询原始表按需构建物化视图加速。 湖仓新范式 数据分析的演进趋势是湖仓一体 当前业界构建数据分析的技术栈有两条典型的路线一个是数仓路线一个是数据湖的路线。 数据仓库的路线数据先通过 ETL 统一写入到数仓进行管理然后构建数据集市来满足 BI 分析的各种需求优势是数据质量高、查询性能高、具备实时分析的能力、数据治理功能完善等而数据湖的路线通常是未经加工的数据先统一存储在数据湖作为企业数据的 Single source of truth然后按需的使用数据构建数据应用优势是通开放生态、扩展性强性价比高。 那未来数据架构应该是建数据仓库还是建数据湖用户之所以有现在的纠结是因为数据仓库和数据湖各有优劣如果能将优势兼具用户也不必关注到底是湖还是仓。目前在业界也在探索湖仓融合的路径比如湖上性能不满足采用湖上建仓的方案加速查询再比如很多数据仓库产品开始扩展查询外部数据湖的能力。但这些本质上都是湖仓组合的方案我们认为发展的趋势是湖仓一体化。 Lakehouse: One DataAll Analytics 湖仓一体到底意味着什么那就是一套架构满足所有的分析需求我们做了一个理念的抽象Lakehouse 就是要实现 One DataAll Analytics 的业务价值。 湖仓架构下数据要统一存储管理一份数据作为 Single source of truth避免导来导去造成数据冗余分析口径不一致等问题。存储层通常采用 S3/HDFS 作为数据存储底层并采用开放数据湖或者 私有的格式去管理数据。 有了统一的数据管理要基于这份数据满足所有的业务分析场景的诉求包括 BI 报表、交互式分析、实时分析、ETL 数据加工等场景这就要求必须要有一个足够强大的分析引擎能同时满足这些场景的查询需求。 对于部分特别复杂的查询部分的数据源数据组织未针对分析优化在这样的情况下直接分析不一定能满足查询延时的需求这就要求 Lakehouse 具备通用的数据加工数据查询加速的能力。 总结一下要实现 One DataAll Analytics需要有统一的数据存储适应不同场景极速的查询引擎以及按需数据加工/查询加速的能力。 基于 StarRocks 的湖仓新范式 如何采用 StarRocks 构建湖仓新范式 用户可以将 StarRocks 当作一站式的 Lakehouse数据统一导入进来借助 StarRocks 存算分离的架构实现低成本的数据存储然后利用 StarRocks 查询引擎来服务全场景的数据分析应用。 如果用户的数据已经在开放在开放数据湖Hive、Hudi、Iceberg、Paimon可以通过 StarRocks 直接分析数据湖来加速交互式查询分析也能获得极高的查询性能。 不管你的数据统一存储在 StarRocks 里还是开放数据湖里当查询性能不足时可以利用 StarRocks 的物化视图来加速查询性能StarRocks 3.0 借助存算分离、湖仓分析、物化视图等关键特性实现 OLAP 数仓 向 统一湖仓的升级达到 One DataAll Analytics 的业务价值。 湖仓新范式正被广泛实践 StarRocks 3.0 从今年4月发布以来已经有数十家企业在实践湖仓新范式并取得非常好的业务效果。 芒果 TV 采用 StarRocks 存算分离作为统一的 Lakehouse所有数据导入到 StarRocks 进行统一管理。相比原来 Hadoop 体系多系统组合的方案架构更简单同时查询性能提升10倍。 微信近实时的数据写入到 Iceberg通过 StarRocks 直接分析 Iceberg 上的数据实现近实时链路的统一同时 Iceberg 的数据还用于其他的场景做加工处理。 携程数据统一存储在 Hive采用 StarRocks 直接查询加速报表对于实效性要求极高的基于 Hive 建立物化视图查询加速整体性能提升10倍。 在上面的3个案例里用户分别基于 StarRocks、Iceberg、Hive 作为统一的数据存储并以 StarRocks 作为统一的查询引擎湖仓一体的实践不是一蹴而就的很多企业当前已经有了大数据体系的建设那么可以从业务层面 到 部门层面 到公司层面逐步实践湖仓新范式最终实现极速统一的数据分析。 未来规划 在未来一年里StarRocks 还是会继续围绕云原生实时湖仓为重心在云原生、实时分析、湖仓一体方面做更多的产品技术突破。 在云原生方面主要增强弹性能力以及提升性能。在弹性能力上增强 Multi-warehouse 能力建设增强 time travel、schema 快速演进的能力以及针对 FE 做存算分离提升系统的扩展性性能方面则会重点优化冷读的性能优化缓存策略支持自动的缓存预热提升主键模型的能力并在存算分离架构下支持高频实时导入。 在实时链路建设上实时分析最大的挑战就是链路太复杂维护难度高StarRocks 希望简化整个实时链路 Pipeline 的构建StarRocks 在即将发布的3.2 版本已经支持了 Pipe 的功能Pipe 可以从 S3 持续增量的导入增量文件也可以持续增量的导出数据到 S3后续 Pipe 也会统一支持 Kafka、关系型数据库让数据的导入导出更加简单实时。数据实时导入之后可以用于查询分析如果需要加速则可以利用实时的物化视图实时物化视图针对数据增量实时计算维护物化视图的一致性。 在湖仓一体能力上会增强 ETL Worklaod 的处理能力。目前 StarRocks 已经能很好的支持交互式分析的 Workload再加上轻量级 ETL Workload 的支持可以实现大部分情况下一套系统就能解决问题。在数据的提取和写入上主要是支持更多的开放表格式文件格式同时也会让 StarRocks 的私有文件格式适配到社区的生态能通过 Spark 直接读写提升效率在数据处理方面会继续增强算子落盘的能力优化 group execution 的执行提升查询容错能力在调度方面完善 Task 调度框架结合查询队列查询自动重试等特性更好的支持 ETL Workload。 StarRocks 经过2年多的发展已经成为了企业 OLAP 数据分析、湖仓分析的首选StarRocks 社区的发展离不开社区所有用户、开发者以及背后厂商的支持感谢所有参与 StarRocks 的社区的同学期待 StarRocks 新一年的进化。 本文由 mdnice 多平台发布
