开启掘金成长之旅!这是我参与「掘金日新计划 · 12 月更文挑战」的第1天,点击查看活动详情
产品简介
是什么
StarRocks 是下一代亚秒级 MPP 数据库,适用于完整的分析场景,包括多维分析、实时分析和 ad-hoc 查询。
新一代极速全场景 MPP (Massively Parallel Processing,大规模并行处理) 数据库。StarRocks 的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需经过复杂的预处理,就可以用 StarRocks 来支持多种数据分析场景的极速分析。
架构简洁,采用了全面向量化引擎,并配备全新设计的 CBO (Cost Based Optimizer) 优化器,查询速度(尤其是多表关联查询)远超同类产品。
能很好地支持实时数据分析,并能实现对实时更新数据的高效查询。StarRocks 还支持现代化物化视图,进一步加速查询。
兼容 MySQL 协议,支持标准 SQL 语法,易于对接使用,全系统无外部依赖,高可用,易于运维管理。
一个官方视频介绍: #
-
背景
- Doris :百度统计报表的专用系统
- Apache Doris:2018年百度贡献给Apache 的
- DorisDB:原百度 Doris 团队的个别人员离职创业的商业化闭源产品
- StarRocks:版权的问题,将 DorisDB 改名为 StarRocks
-
官方文档
- Apache Doris 官网文档:doris.apache.org/zh-CN/learn…
- StarRocks 官方文档:docs.starrocks.io/zh-cn/main/…
-
出现:如何有效地分析这些海量的数据,真正有效地利用数据为业务创造价值?
- 数据分析性能不达标:业务提出了更多的分析需求,比如多维分析,实时分析,高并发查询。在很多分析需求场景下,当前系统性能表现不佳,无法提供极速分析体验。
- 数据分析的灵活性不足:比如自助化 BI 这样灵活的场景下,星型模型和雪花模型的价值不可替代。现有的系统难以同时高性能支持这些建模手段。
- 数据架构复杂度太高:目前同时构建离线数据链路和实时数据链路,存在数据同步、数据一致性、计算逻辑同步、异常数据处理、多系统运维等问题。
- 数据分析能力弹性不足:数据规模越来越大,对应的数据分析系统需要不断地扩容;不同的业务线有不同的数据分析访问量。如何保证既能支持好业务,又能节省成本?就需要一套全新的“极速统一”的数据架构。“极速”,意味着全面提升数据处理和分析的性能;“统一”意味着将复杂分散的数据架构融合为简单统一的架构。
复杂的企业数据分析架构
-
StarRocks 实现了极速统一分析
- StarRocks 可以同时高效支持 OLAP 多维分析、实时数据分析、高并发查询、AdHoc 查询等多场景,并且比上一代同类型产品的分析能力快3~5倍以上。
- 全新的 OLAP多维分析体验,打破“只能做大宽表”的局限性,让多种数据建模模式:预计算、大宽表、星型模型和雪花模型等都具备极速分析体验。
- 全新的实时数据分析体验,支持数据实时更新和删除,并能保证极速查询性能。
- 全新的高并发查询体验,支持数千人同时访问。
- 全新极简统一的OLAP架构,大大降低了使用和运维管理复杂度,提升了开发和使用效率。
- OLAP
OLAP(Online Analytical Processing):分析型数据库,是指一类支持对大规模数据进行较为复杂的联机分析处理的数据库,更关注复杂查询和聚集分析。
- 通常并发不高,每个查询会运行较长时间,操作的数据量巨大。
- 分析中的查询,大多只需读取数据,不会对历史数据轻易修改。
- 分析中的关系代数操作,会包含非常复杂的交运算,中间结果可能种类繁多数量庞大,但 最终返回给用户的结果可能较小较容易理解。
分布式 OLAP 数据库:业界代表包括 TeraData、Greenplum、GaussDB(DWS)、AnalyticDB、 Bigquery、 Clickhouse等。
常见OLAP引擎对比
-
特性
- Native vectorized SQL engine(原生矢量化SQL引擎)
- Standard SQL(标准SQL):与MySQL协议兼容。可以使用各种客户端和BI软件来访问StarRock。
- Smart query optimization(智能查询优化):CBO(基于成本的优化器)可以优化复杂的查询。
- Real-time update(实时更新):可以根据主键执行 upsert/DELETE 操作,在并发更新时实现高效的查询。
- Intelligent materialized view(智能实化视图):可以在数据导入过程中自动更新,并在查询执行时自动选择。
- Querying data in data lakes directly(直接查询数据湖中的数据):直接访问,无需导入。
- Resource management(资源管理):允许StarRock限制查询的资源消耗。
- Easy to maintain(易于维护):简单的架构使其易于部署、维护和扩展。在集群扩展或扩展时平衡资源,并在节点发生故障时自动恢复数据副本。
-
在大数据生态中的地位:StarRocks 不依赖于某⼀种技术栈,而又能够兼容大数据平台的绝大部分技术栈。
- 在数据导入层面上,StarRock 可以拉取 HDFS、S3、OSS 中的数据,也可以导⼊平面文件,或者是消费 Kafka 中的增量数据;
- 对于像 MySQL 或者 Oceanbase 这样的 TP 业务库,全量数据我们可以通过 dataX, sqoop 等工具进⾏同步,增量数据我们可以通过 canal 这样的 CDC 工具实时同步;
- 如果在同步的过程中,我们需要进⾏⼀些清洗或者数据转换操作,可以使⽤ Flink 或 者 Spark;
- 此外 StarRocks 还支持外表联邦查询,可以拉取 Hive、MySQL、ES 以及 Iceberg 中的 数据,与 StarRocks 中的表进⾏关联,避免数据孤岛的存在;
- 从顶层协议来看,StarRocks 兼容了
MySQL
协议,可以轻松平稳的对接多种开源或者 商业BI
工具,⽐如说 Tableau,FineBI,SmartBI,Superset 等。
数据运营层 ODS
数据细节层 DWD
数据服务层 DWS
数据应用层 ADS
使用场景
-
OLAP 多维分析
利用 StarRocks 的 MPP 框架和向量化执行引擎,用户可以灵活的选择雪花模型,星型模型,宽表模型或者预聚合模型。
-
实时数据仓库
实现了 Primary-Key 模型,能够实时更新数据并极速查询,可以秒级同步 TP (Transaction Processing) 数据库的变化,构建实时数仓。
- 电商大促数据分析
- 物流行业的运单分析
- 直播质量分析
-
高并发查询
良好的数据分布特性,灵活的索引以及物化视图等特性
- SaaS 行业面向用户分析报表
- Dashboard 多页面分析
-
统一分析
通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景;
使用 StarRocks 统一管理数据湖和数据仓库,将高并发和实时性要求很高的业务放在 StarRocks 中分析,也可以使用 StarRocks 外表查询功能进行数据湖上的分析。
架构
架构简洁,整个系统的核心只有 FE(Frontend)、BE(Backend)两类进程,不依赖任何外部组件,方便部署与维护。
FE 和 BE 模块都可以在线水平扩展,元数据和业务数据都有副本机制,确保整个系统无单点。
提供 MySQL 协议接口,支持标准 SQL 语法。用户可通过 MySQL 客户端方便地查询和分析 StarRocks 中的数据。
FE(前端节点:管理)
FE 是 StarRocks 的前端节点,负责管理元数据,管理客户端连接,进行查询规划,查询调度等工作。使用 Java 语言。
FE 的主要作用有:
缓存外部表元数据。其中,元数据信息分为两类:
- 数据表的基本元信息,如表结构 Schema、存储位置、分区信息、不同类别的统计信息等;
- 数据表下的数据文件信息,如某个分区下的文件列表、大小、压缩格式等。
查询规划。包括解析 SQL 文本,生成逻辑执行计划和物理执行计划,对执行计划进行优化,如分区/列裁剪,Join Reorder 等。
查询调度。使用上述的外部表元数据,根据数据的分布情况分配可用的 BE 节点资源等信息,规划每个 BE 需要执行的具体计算任务,并使用算法保证数据本地性的同时,尽可能让每个 BE 节点并行地读取大致相同的数据量以提高执行效率。
根据配置有两种角色:Follower 和 Observer。Follower 会通过类 Paxos 的 BDBJE 协议选主出一个 Leader。三者区别如下:
-
Observer
- 主要用于扩展集群的查询并发能力,可选部署。
- 不参与选主,不会增加集群选主压力。
- 通过回放 Leader 的元数据日志来异步同步数据。
-
Follower
- 只有元数据读取权限,无写入权限。通过回放 Leader 的元数据日志来异步同步数据。
- 参与 Leader 选举,必须有半数以上的 Follower 节点存活才能进行选主。
-
Leader
- 只有 Leader 节点会对元数据进行写操作,Follower 和 Observer 只有读取权限。
- Leader 从 Follower 中选举。如果 Leader 节点失败,Follower 会发起新一轮选主。
BE(后端节点:数据存储、SQL执行)
BE 是 StarRocks 的后端节点,负责数据存储、SQL执行等工作。
-
数据存储:BE 节点是完全对等的,FE 按照一定策略将数据分配到对应的 BE 节点。BE 负责将导入数据写成对应的格式存储下来,并生成相关索引。
-
执行 SQL 计算
- 一条 SQL 语句首先会按照具体的语义规划成逻辑执行单元,然后再按照数据的分布情况拆分成具体的物理执行单元。
- 物理执行单元会在对应的数据存储节点上执行,这样可以实现本地计算,避免数据的传输与拷贝,从而能够得到极致的查询性能。
BE 主要作用有:
- 执行 FE 分配的计算任务。如 Scan、Join、Shuffle、Aggregate 等。
- 向 FE 汇报执行状态,传输执行结果。
数据管理
-
使用列式存储,采用分区分桶机制进行数据管理。
- (1)分区:如将一张表按照时间来进行分区,粒度可以是一天,或者一周等。
- (2)分桶:一个分区内的数据可以根据一列或者多列进行分桶,将数据切分成多个 Tablet。(Tablet 是 StarRocks 中最小的数据管理单元。每个 Tablet 都会以多副本(replica) 的形式存储在不同的 BE 节点中。您可以自行指定 Tablet 的个数和大小。)
-
如下,展示了 StarRocks 的数据划分以及 Tablet 多副本机制。
图中,表按照日期划分为 4 个分区,第一个分区进一步切分成 4 个 Tablet。每个 Tablet 使用 3 副本进行备份,分布在 3 个不同的 BE 节点上。
-
支持高并发的能力
- StarRocks 在执行 SQL 语句时,可以对所有 Tablet 实现并发处理,从而充分的利用多机、多核提供的计算能力。
- 用户也可以利用 StarRocks 数据的切分方式,将高并发请求压力分摊到多个物理节点,从而可以通过增加物理节点的方式来扩展系统支持高并发的能力。
-
支持 Tablet 多副本存储
- 默认副本数为三个。多副本能够保证数据存储的高可靠以及服务的高可用。
特性
MPP分布式执行框架
在 MPP 执行框架中,一条查询请求会被拆分成多个物理计算单元,在多机并行执行。每个执行节点拥有独享的资源(CPU、内存)。单个查询请求可以充分利用所有执行节点的资源,所以单个查询的性能可以随着集群的水平扩展而不断提升。
如上,
- 将一个查询在逻辑上切分为多个逻辑执行单元(Query Fragment)。
- 按照每个逻辑执行单元需要处理的计算量,每个逻辑执行单元会由一个或者多个物理执行单元来具体实现。即,不同逻辑执行单元可以由不同数目的物理执行单元来具体执行,以提高资源使用率,提升查询速度。
- 物理执行单元是最小的调度单位。一个物理执行单元会被调度到集群某个BE上执行。
全面向量化执行引擎
充分发挥了 CPU 的处理能力。
按照列式的方式组织和处理数据。StarRocks 的数据存储、内存中数据的组织方式,以及 SQL 算子的计算方式,都是列式实现的。
按列的数据组织也会更加充分的利用 CPU 的 Cache,按列计算会有更少的虚函数调用以及更少的分支判断从而获得更加充分的CPU指令流水。
CBO 优化器
-
背景
- 在多表关联查询场景下,仅靠优秀的执行引擎没有办法获得最极致的执行性能。因为这类场景下,不同执行计划的复杂度可能会相差几个数量级。
- 查询中关联表的数目越大,可能的执行计划就越多,在众多的可能中选择一个最优的计划,这是一个NP-Hard的问题。只有优秀的查询优化器,才能选择出相对最优的查询计划,从而实现极致的多表分析性能。
-
设计
- StarRocks从零设计并实现了一款全新的,基于代价的优化器CBO(Cost Based Optimizer)。
-
优势
- 由于全新CBO的支持,StarRocks能比同类产品更好地支持多表关联查询,特别是复杂的多表关联查询,让全面向量化引擎能够发挥极致的性能。
可实时更新的列式存储引擎
StarRocks能够支持秒级的导入延迟,提供准实时的服务能力。
智能的物化视图
-
StarRocks 支持用户使用物化视图进行查询加速。(FROM 官方文档)
- 可以自动根据原始表更新数据;而且物化视图的选择也是自动进行的。
-
物化视图包含了两个维度的内容,一个维度是物化,一个维度是视图。(FROM 官方知乎社区)
- 物化这个维度指的是物化视图要将数据进行物理化存储,这样后续应用就能够直接使用,起到查询加速的效果。
- 视图是逻辑层次的概念,表达的是一个查询的结果集,视图可以直接被用来指定进行查询。用户使用视图更多的是想做一个逻辑的抽象,用来简化 SQL。
- 所以物化视图是两者的融合,一方面能够通过物理层的存储来加速查询,另一方面提供了逻辑层的抽象,用来简化用户的 SQL 表达。
数据湖分析
StarRocks不仅能高效的分析本地存储的数据,也可以作为计算引擎直接分析数据湖中的数据。
支持包括 Apache Hive
、Apache Iceberg
、Apache Hudi
(Uber 开源的Data Lakes解决方案)等数据组织结构,支持 Parquet、ORC、CSV 等文件格式,也支持 HDFS、S3、OSS 等存储方式。
在数据湖分析的场景中,StarRocks 主要负责数据的计算分析,而数据湖则主要负责数据的存储、组织和维护。