互联网公司 A,以售卖在线广告来取得支出。这家公司想为广告主提供一个实时报表平台,为客户实时剖析生产数据,作为广告主投放广告的决策根底。
互联网公司 B,打算开发经营一款 APP。这家公司想对 APP 用户进行行为剖析,剖析影响用户转换率、留存率的因素。
互联网公司 C,以电子商务为主营业务。这家公司想对订单数据进行剖析、实时监测订单状态变更,以动静调整经营策略。
业务属性不同的 A / B / C 三家公司,都想对数据进行实时剖析,对它们来说,什么样的零碎可能满足需要呢?
首先,零碎必须可能存储 PB 级的用户行为日志、广告、订单等数据,并对海量数据进行实时剖析,为业务提供数据撑持。再者,A、B、C 公司提供的皆是在线剖析服务,思考到业务理论运行中的软硬件故障,零碎必须可能容忍异样、保障服务 7×24 小时可用。
本文将讲述 StarRocks 治理海量数据、提供高可用服务等方面的工作和思考。
01 零碎架构
面对海量数据,业界的通行做法是通过搭建分布式集群来进行数据管理。假如有 1PB 数据,思考到市场支流机型的单机存储容量,集群规模差不多在 100 台节点左右。如此大规模的数据,如何平均地散布到 100 台节点,如何对其进行并行计算,成为了架构上必须首要解决的两大难题。
StarRocks 采纳 Shared-Nothing 架构,数据按照指定规定散布到各个节点。单个节点既有存储也有计算,二者的严密耦合能够最大限度地实现本地计算,缩小网络传输开销。跨节点的数据计算,例如分布式 Join,通过 MPP (Massively Parallel Processing) 框架实现。
图 1:StarRocks 整体架构
StarRocks 架构图如图 1 所示。FE 为元数据层,治理所有元数据;BE 为 数据存储层,也负责本地数据的计算。FE 对查问进行布局和散布式调度,并调度 BE 实现数据导入、Online Schema Change 等解决,提供高效的数据服务。
Table 和 Tablet
若要形容数据如何散布,必然牵扯到 StarRocks 的数据模型,即 StarRocks 提供什么接口来让用户定义数据。作为一款 OLAP 数据库,StarRocks 的数据模型遵从关系模型。通过如图 2 所示的一个 SQL 语句,能够形容 StarRocks 对数据的定义。
图 2:StarRocks Table Schema
图 2 中 bigdata 除定义数据类型之外,还定义了分区、分桶等数据分布的形式。bigdata 以季度为分区粒度,每个季度一个分区。分区内的数据,又再次进行 Hash 分桶,将其划分成 100 个 Tablets。Table -> Partition -> Tablet 三者之间的关系能够示意为图 3。
图 3:Table / Partition / Tablet 三者之间的关系
Tablet 为数据管理的最小单元,无论多大数据规模的 Table 都能够拆解成一组 Tablets,对立进行治理。导入时,数据根据分区、分桶的定义,写到指定 Tablet;查问时,数据依据查问条件主动路由到相应 Tablet。
咱们所展现的图 2 中,bigdata 共有 400 个 Tablets。现假如有 100 台节点,StarRocks 会如何平均地把这些 Tablets 存储到 BE 中呢?
FE 会平均调度每台 BE 存储 4 个 Tablets。对于某个 BE 节点存储哪些 Tablets,没有动态绑定。FE 在保证数据可用性和可靠性的条件下,会动静调度 Tablets 数据到不同的 BE 上,以实现数据的更优散布。比方,当一个 BE 节点磁盘空间满,Tablet 就可能被挪动到更闲暇一些的 BE 节点。Tablets 数据迁徙由 StarRocks 主动实现,无需人工干预,所有查问和导入失常在线运行而不受影响。
通过这种拆分 Tablet 的形式,业务方在扩缩容 BE 节点时,FE 将依据策略,在不同 BE 之间挪动局部大量的 Tablets 即可主动疾速实现数据平衡。而其余采纳传统 MPP 数据库架构的零碎,比方 ClickHouse,将全副表数据依照集群节点组成动态散布到各个节点上。在集群伸缩时,须要将全副数据进行从新 Sharding 和散布以实现较好的数据平衡。
整个过程须要挪动所有的数据,而且写入服务须要暂停。整个过程往往须要手动操作,非常复杂,并且易出错。而 StarRocks 基于 Tablets 切分和迁徙的主动伸缩机制具备十分好的线性扩大能力,整个过程齐全主动执行,无需手动操作,无需停服。
MPP 计算引擎
解决完 Tablet 散布难题之后,紧接着要面对的是如何计算 Tablet 数据,获取业务指标数据。StarRocks 会利用 Tablet 数据的本地性,尽可能在凑近 Tablet 的中央实现更多算子的计算,缩小网络数据传输。另外 StarRocks 采纳 MPP 执行框架,多机并行执行查问。
于是,不管用户执行的是 Sort、GroupBy 还是 Join,StarRocks 都能最大限度地可能利用集群资源进行计算。绝对于 ClickHouse 和 Druid 等采纳的 Scatter-Gather 模式,StarRocks 的 MPP 架构能够无效防止单点瓶颈,更好利用集群整体的资源。
图 4:StarRocks 的 MPP 执行框架
02 元数据和数据的高可用
StarRocks 元数据具体可分为三类:表 Schema,Tablet 的地位信息,节点状态。
作为集群的大脑,元数据每时每刻都可能被批改。频繁写入的过程中,为保障元数据的可用性,StarRocks 内嵌一个 BDB-JE 数据库进行元数据同步,此机制相似 raft 复制协定。每条写入日志会实时同步给多数派正本 (线上举荐三正本),少数正本写入胜利能力返回给客户端胜利信息。
与元数据一样,Tablet 也冗余多正本进行存储,默认三正本。单次导入的数据,同步发给三个正本,由它们各个写入本人的数据存储引擎中,当其中两个正本实现写入时,即可认为这批次导入实现。所有的导入工作对立由 FE 进行任务调度和事务协调,Tablet 的三个正本所在的 BE 之间无需运行相似 Raft 之类的复制协定。如果某个节点因为故障,没有写入最新数据,在节点复原后,FE 将依据节点状态调度 Clone 工作给对应的 BE,BE 将追平数据,从而放弃三个正本统一。
FE 治理 Tablet 多个正本时,保障多个正本不落在雷同节点上,从而避免单点故障导致数据失落。FE 也能够依据策略动静在不同 BE 上创立和删除 Tablet 正本,实现 Tablet 数据在不同 BE 之间的主动数据平衡。整个过程之中,查问和导入不受影响。Tablet 各个正本在集群之中的散布如图 5 所示。
图 5:Tablet 多正本在集群中的散布
03 数据导入
StarRocks 的实时导入次要面向分钟级别或者秒级别数据导入。以最常见的数据起源 Kafka 来说,StarRocks 原生反对订阅 Kafka、主动分批导入,每隔肯定的距离周期,提交一次导入。用户在应用过程中,只需在 StarRocks 中创立一个针对 Kafka 的例行导入工作即可。
之所以采纳微批 (MiniBatch) 来进行实时导入,而不是单条单条实时导入,次要是思考到 OLAP 零碎导入申请的两个个性:
分钟级或者秒级导入能够满足大多业务对时效性的要求。
单条高频写入,须要零碎设计非常复杂的存储机制来反对,而且零碎吞吐能力会升高,也往往无奈具备十分好的事务保障。StarRocks 采纳微批形式能够大大晋升数据写入吞吐能力,并且对导入反对事务保障,这对加重用户开发利用的老本十分要害。如果一个订单表在同步完 MySQL 数据之前能被查问到,查问后果很可能会对业务方造成困扰。
那么 StarRocks 如何保障实时导入事务?
StarRocks 应用经典的两阶段提交 (Two-Phase Commit) 形式,对单次导入进行解决。当导入事务实现时,StarRocks 为导入调配一个 Version,通过 MVCC(Mulit-version Concurrenyc Control)解决事务之间的抵触。
能够构想这样一种情景:某个查问带着 Version 100 进行数据扫描,整个执行过程超过一分钟;一分钟内,如果有新导入实现,其会被赋予 Version 101、Version 102;通过 Version,查问能够过滤掉 Version 100 和 Version 101 对应的文件,保障查问能够基于正确的数据快照进行计算。
04 Online Schema Change
业务运行过程中,Schema 变更不间断产生。这种变更,可能来自于剖析维度变动,导致的加列、减列需要;也可能来自于构建索引、减速查问的需要。如果 Schema 变更中能不中断业务,可极大缓解 DBA 运维集群的压力。他们不必告诉业务方暂时中止业务、期待变更后果,节俭了协调各方面业务方的工夫,也大大减少了手工运维工作和失误。
Online Schema Change 将基于原有数据表(原表)生成一张新的数据表(新表)。整个过程分为三个阶段 t1、t2、t3。
t1: 收到 Schema Change 申请。此时,同时存在着正在运行的导入工作,需期待这部分导入工作实现,能力下发 Schema Change 工作。
t2: t1 之前的导入曾经实现,间接下发 Schema Change 工作。至于 [t1, t2] 之间的导入工作,FE 会调度生成两份数据,一份给原表,一份给新表。
t3:BE 实现了 Schema Change。FE 对原表和新表进行原子替换,Schema Change 实现。
整个过程中,原有 schema 的数据导入和查问可能失常运行,查问会基于原表进行。Schema Change 实现之后,查问会基于新表进行,业务方也能够导入新 schema 的数据。
图 6:Online Schema Change 流程
05 总结
本文着重介绍了 StarRocks 在大数据管理方面的工作,次要是从高可用、自助治理海量数据等角度进行了论述。当然这只是 StarRocks 性能的冰山一角,高效列存数据组织、物化视图、数据合并 (Compaction)、提早物化(Late Materialization) 等更多功能将在系列文章中进行介绍。
随着越来越宽泛地利用到各大公司,StarRocks 正一直迭代,帮忙用户发明更大价值。身处私有云时代,StarRocks 也在踊跃打造存储计算拆散的 Cloud Native 新架构,相干成绩敬请期待。
作者
李超勇 | StarRocks 外围研发
负责 StarRocks 的新型列式存储引擎、物化视图以及元数据管理等方面的研发工作。