关于数据库:大数据自动管理24-小时服务无间断StarRocks-如何做到

6次阅读

共计 4193 个字符，预计需要花费 11 分钟才能阅读完成。

互联网公司 A，以售卖在线广告来取得支出。这家公司想为广告主提供一个实时报表平台，为客户实时剖析生产数据，作为广告主投放广告的决策根底。
互联网公司 B，打算开发经营一款 APP。这家公司想对 APP 用户进行行为剖析，剖析影响用户转换率、留存率的因素。

互联网公司 C，以电子商务为主营业务。这家公司想对订单数据进行剖析、实时监测订单状态变更，以动静调整经营策略。

业务属性不同的 A / B / C 三家公司，都想对数据进行实时剖析，对它们来说，什么样的零碎可能满足需要呢？

首先，零碎必须可能存储 PB 级的用户行为日志、广告、订单等数据，并对海量数据进行实时剖析，为业务提供数据撑持。再者，A、B、C 公司提供的皆是在线剖析服务，思考到业务理论运行中的软硬件故障，零碎必须可能容忍异样、保障服务 7×24 小时可用。

本文将讲述 StarRocks 治理海量数据、提供高可用服务等方面的工作和思考。

面对海量数据，业界的通行做法是通过搭建分布式集群来进行数据管理。假如有 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 执行框架

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 多正本在集群中的散布

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 对应的文件，保障查问能够基于正确的数据快照进行计算。

业务运行过程中，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 流程

本文着重介绍了 StarRocks 在大数据管理方面的工作，次要是从高可用、自助治理海量数据等角度进行了论述。当然这只是 StarRocks 性能的冰山一角，高效列存数据组织、物化视图、数据合并 (Compaction)、提早物化(Late Materialization) 等更多功能将在系列文章中进行介绍。

随着越来越宽泛地利用到各大公司，StarRocks 正一直迭代，帮忙用户发明更大价值。身处私有云时代，StarRocks 也在踊跃打造存储计算拆散的 Cloud Native 新架构，相干成绩敬请期待。