数据仓库系列：StarRocks 入门培训教程

朱雀 2024-02-05 22:29 124阅读 0赞

#### 文章目录 ####

*   *  1. 什么是StarRocks?
     *   *  1.1. 适用场景
         *  1.2. \[产品特性\](https://docs.starrocks.io/zh-cn/latest/introduction/Features)
     *  2. 系统架构
     *   *  2.1. 系统架构
         *   *  2.1.1. 整体架构
             *  2.1.2. 高可用实现方式
         *  2.2. 数据如何管理？
     *  3. 表模型
     *   *  3.1. 明细模型
         *  3.2. 聚合模型
         *  3.3. 更新模型
         *  3.4. \[主键模型\](https://docs.starrocks.io/zh-cn/latest/table\_design/table\_types/primary\_key\_table)
     *  4. 数据导入导出
     *   *  4.1. 数据导入
         *  4.2. 导出数据
     *  5. 使用 Catalog 管理和查询内外部数据
     *   *  5.1. Catalog
         *  5.2. 外部表
         *  5.3. 文件外部表
     *  6. 物化视图
     *   *  6.1. 同步物化视图
         *  6.2. 异步物化视图
         *  6.3. Colocate Join（大表关联）
     *  7. 企业架构升级示例
     *   *  案例1 \[海尔云链 金融数据查询增速三倍，服务器成本减半\](https://blog.csdn.net/flyinthesky111/article/details/124407888)
         *  案例2 广告行业中的实时分析场景

其它文章请参考  
[数据仓库系列：StarRocks 下一代高性能分析数据仓库的架构、数据存储及表设计][StarRocks]  
[数据仓库系列：StarRocks的简单试用及与clickhouse的对比][StarRocks_clickhouse]  
[数据仓库系列：如何将StarRocks集群与Jupyter集成？][StarRocks_Jupyter]

### 1. 什么是StarRocks? ###

StarRocks 是一款MPP DB, 对标ClickHouse、Vertica、Teradata、Greenplum，在查询性能上远超当代最快的开源数据库 clickhouse，目前已经被一众互联网企业在生产环境中采用。  
提供千亿级大数据的在线多维分析和分布式存储。

> 新一代极速全场景 MPP (Massively Parallel Processing) 数据库

是fork [doris][]后独立运营的商业化版本[StarRocks][StarRocks 1]

可以认为是 MySQL 8.x的分布式版本，会用MySQL, 就会用StarRocks

#### 1.1. 适用场景 ####

StarRocks 可以满足企业级用户的多种分析需求，主要使用场景如下：

*  `OLAP (Online Analytical Processing) 多维分析` 如自助式报表平台，用户行为分析
 *  `实时数据仓库` 如电商大促数据分析、广告投放分析，支持针对数据更新
 *  `高并发查询` 如如广告主报表分析
 *  `统一分析`
    
     *  通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景，降低系统复杂度和多技术栈开发与维护成本。
     *  使用 StarRocks 统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在 StarRocks 中分析，也可以使用 External Catalog 和外部表进行数据湖上的分析。

详见[适用场景][Link 1]

#### 1.2. [产品特性][Link 2] ####

*  **MPP 分布式执行框架**  
    在 MPP 框架中，数据会被 Shuffle 到多个节点，并且由多个节点来完成最后的汇总计算。在复杂计算时（比如高基数 Group By，大表 Join 等操作），StarRocks 的 MPP 框架相对于 Scatter-Gather 模式的产品有明显的性能优势  
    ![在这里插入图片描述][f3cb4e181943488c8543bd49ae037029.png]
 *  **全面向量化 MPP 查询引擎**： 充分发挥了 CPU 的处理能力,同时支持极速的单表和多表查询性能
 *  **CBO 优化器**: 支持极速的秒级 AdHoc 查询
 *  **可实时更新的列式存储引擎**: 具备极致的实时更新和查询性能
 *  **全新设计的数据分布模式**，具备高并发查询能力, 可以支持每秒上万次的并发查询能力。
 *  **智能的物化视图**： 使用物化视图（materialized view）进行查询加速和数仓分层, 具备灵活透明的预计算加速能力  
    ![在这里插入图片描述][04e98cbec6bb49d2861b5b2aed8264b5.png]
 *  **数据湖分析**： StarRocks 主要负责数据的计算分析，而数据湖则主要负责数据的存储、组织和维护【类似于spark作为查询分析引擎】  
    ![在这里插入图片描述][efb2ab59829942c9871f271229a55606.png]

### 2. 系统架构 ###

#### 2.1. 系统架构 ####

##### 2.1.1. 整体架构 #####

StarRocks 架构简洁，整个系统的核心只有 FE（Frontend）、BE（Backend）两类进程，不依赖任何外部组件，方便部署与维护

StarRocks 的整体架构如下图：

*  FE（Frontend）前端节点: 多个FE组成第一层，提供FE的 `横向扩展和高可用`
    
     *  负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。
     *  每个 FE 节点都会在内存保留一份完整的元数据，这样每个 FE 节点都能够提供无差别的服务
 *  BE（Backend）后端节点: 多个BE组成第二层
    
     *  负责数据存储与管理、查询计划执行等工作
 *  FE 和 BE 模块都可以在线水平扩展，元数据和业务数据都有副本机制，确保整个系统无单点
 *  StarRocks 提供 MySQL 协议接口，支持标准 SQL 语法

##### 2.1.2. 高可用实现方式 #####

FE 有三种角色：Leader FE，Follower FE 和 Observer FE。Follower 会通过类 Paxos 的 Berkeley DB Java Edition（BDBJE）协议自动选举出一个 Leader

*  Leader
    
     *  Leader 从 Follower 中自动选出，进行选主需要集群中有半数以上的 Follower 节点存活。如果 Leader 节点失败，Follower 会发起新一轮选举。
     *  Leader FE 提供元数据读写服务。只有 Leader 节点会对元数据进行写操作，Follower 和 Observer 只有读取权限。Follower 和 Observer 将元数据写入请求路由到 Leader 节点，Leader 更新完数据后，会通过 BDB JE 同步给 Follower 和 Observer。必须有半数以上的 Follower 节点同步成功才算作元数据写入成功。
 *  Follower
    
     *  只有元数据读取权限，无写入权限。通过回放 Leader 的元数据日志来异步同步数据。
     *  参与 Leader 选举，必须有半数以上的 Follower 节点存活才能进行选主。
 *  Observer
    
     *  主要用于扩展集群的查询并发能力，可选部署。
     *  不参与选主，不会增加集群的选主压力。
     *  通过回放 Leader 的元数据日志来异步同步数据。  
        ![在这里插入图片描述][76a6f6be58da49708bb7152719b50b2f.png]

#### 2.2. 数据如何管理？ ####

StarRocks 使用列式存储，采用分区分桶机制进行数据管理。

表按照日期划分为 4 个分区，第一个分区进一步切分成 4 个 Tablet。每个 Tablet 使用 3 副本进行备份，分布在 3 个不同的 BE 节点上。  
![在这里插入图片描述][8ec579175e6a4880926805ba7e651bf2.png]

*  一张表被切分成了多个 Tablet，StarRocks 在执行 SQL 语句时，可以对所有 Tablet 实现并发处理，从而充分的利用多机、多核提供的计算能力
 *  Tablet 的分布方式与具体的物理节点没有相关性。在 BE 节点规模发生变化时，比如在扩容、缩容时，StarRocks 可以做到无需停止服务，直接完成节点的增减。节点的变化会触发 Tablet 的自动迁移
 *  支持 Tablet 多副本存储，默认副本数为三个。多副本能够保证数据存储的高可靠以及服务的高可用。

相关的SQL语句

-- 建表SQL
    CREATE TABLE IF NOT EXISTS sr_member (
        sr_id            INT,
        name             STRING,
        city_code        INT,
        reg_date         DATE,
        verified         BOOLEAN
    )
    PARTITION BY RANGE(reg_date)
    (
        START ("2021-01-01") END ("2021-12-31") EVERY (INTERVAL 3 MONTH)
    )
    DISTRIBUTED BY HASH(city_code) BUCKETS 4
    PROPERTIES(
        "replication_num" = "1"
    );
    
    -- 查看表分区
    show partition from test.sr_member;
    
    -- 查看tablet
    show tablet from test.sr_member;

### 3. 表模型 ###

![在这里插入图片描述][303df19369d74362892301c557e7ec4b.png]

#### 3.1. 明细模型 ####

**适用场景**

*  分析原始数据，例如原始日志、原始操作记录等。
 *  查询方式灵活，不需要局限于预聚合的分析方式。
 *  导入日志数据或者时序数据，主要特点是旧数据不会更新，只会追加新的数据。

**建表示例**

CREATE TABLE IF NOT EXISTS detail (
        event_time DATETIME NOT NULL COMMENT "datetime of event",
        event_type INT NOT NULL COMMENT "type of event",
        user_id INT COMMENT "id of user",
        device_code INT COMMENT "device code",
        channel INT COMMENT ""
    )
    DUPLICATE KEY(event_time, event_type)
    DISTRIBUTED BY HASH(user_id) BUCKETS 8
    PROPERTIES("replication_num" = "1");

**注意事项**：

*  排序键的相关说明：
    
     *  在建表语句中，排序键必须定义在其他列之前。
     *  排序键可以通过 `DUPLICATE KEY` 显式定义。本示例中排序键为 `event_time` 和 `event_type`。  
        如果未指定，则默认选择表的前三列作为排序键。
     *  明细模型中的排序键可以为部分或全部维度列。
 *  建表时，支持为指标列创建 BITMAP、Bloom Filter 等索引。
 *  建表时必须使用 DISTRIBUTED BY HASH 子句指定分桶键, 也可以不指定（自 2.5.7 版本起，会自动设置分桶数量 (BUCKETS)）

#### 3.2. 聚合模型 ####

**适用场景**：数据统计和分析场景

*  大多数查询是聚合查询，例如SUM、COUNT和MAX。
 *  不需要检索原始的详细数据。
 *  历史数据不经常更新。只追加新数据。

**建表示例**

CREATE TABLE IF NOT EXISTS example_db.aggregate_tbl (
        site_id LARGEINT NOT NULL COMMENT "id of site",
        date DATE NOT NULL COMMENT "time of event",
        city_code VARCHAR(20) COMMENT "city_code of user",
        pv BIGINT SUM DEFAULT "0" COMMENT "total page views"
    )
    AGGREGATE KEY(site_id, date, city_code)
    DISTRIBUTED BY HASH(site_id) BUCKETS 8
    PROPERTIES ("replication_num" = "1");

**注意事项**：

*  排序键的相关说明
    
     *  在建表语句中，排序键必须定义在其他列之前。
     *  如果 AGGREGATE KEY 未包含全部维度列（除指标列之外的列），则建表会失败。
     *  如果不通过 AGGREGATE KEY 显示定义排序键，则默认除指标列之外的列均为排序键。
     *  排序键必须满足唯一性约束，必须包含全部维度列，并且列的值不会更新。
 *  在运行查询时，排序键在多版聚合之前就能进行过滤，而指标列的过滤在多版本聚合之后
 *  建表时，不支持为指标列创建 BITMAP、Bloom Filter 等索引
 *  将数据加载到使用聚合键模型的表中时，只能更新表的所有列

#### 3.3. 更新模型 ####

**适用场景**

*  需要实时和频繁更新数据的业务场景，如在电子商务场景中，每天可以下数亿个订单，订单状态经常变化

**建表示例**

CREATE TABLE IF NOT EXISTS orders (
        create_time DATE NOT NULL COMMENT "create time of an order",
        order_id BIGINT NOT NULL COMMENT "id of an order",
        order_state INT COMMENT "state of an order",
        total_price BIGINT COMMENT "price of an order"
    )
    UNIQUE KEY(create_time, order_id)
    DISTRIBUTED BY HASH(order_id) BUCKETS 8
    PROPERTIES ("replication_num" = "1");

**注意事项**：

*  主键的相关说明：
    
     *  在建表语句中，主键必须定义在其他列之前。
     *  主键通过 `UNIQUE KEY` 定义。
     *  主键必须满足唯一性约束，且列的值不会修改。
     *  设置合理的主键。
        
         *  查询时，主键在聚合之前就能进行过滤，而指标列的过滤通常在多版本聚合之后，因此建议将频繁使用的过滤字段作为主键，在聚合前就能过滤数据，从而提升查询性能。
         *  聚合过程中会比较所有主键，因此需要避免设置过多的主键，以免降低查询性能。如果某个列只是偶尔会作为查询中的过滤条件，则不建议放在主键中。
 *  建表时，不支持为指标列创建 BITMAP、Bloom Filter 等索引。

#### 3.4. [主键模型][Link 3] ####

**适用场景**： 适用于实时和频繁更新的场景

*  实时对接事务型数据至 StarRocks
 *  利用部分列更新轻松实现多流 JOIN

**建表示例**

create table orders (
        dt date NOT NULL,
        order_id bigint NOT NULL,
        user_id int NOT NULL,
        merchant_id int NOT NULL,
        good_id int NOT NULL,
        good_name string NOT NULL,
        price int NOT NULL,
        cnt int NOT NULL,
        revenue int NOT NULL,
        state tinyint NOT NULL
    ) PRIMARY KEY (dt, order_id)
    PARTITION BY RANGE(`dt`) (
        PARTITION p20210820 VALUES [('2021-08-20'), ('2021-08-21')),
        PARTITION p20210821 VALUES [('2021-08-21'), ('2021-08-22')),
        PARTITION p20210929 VALUES [('2021-09-29'), ('2021-09-30')),
        PARTITION p20210930 VALUES [('2021-09-30'), ('2021-10-01'))
    ) DISTRIBUTED BY HASH(order_id) BUCKETS 4 
    PROPERTIES("replication_num" = "1","enable_persistent_index" = "true");
    
    create table users (
        user_id bigint NOT NULL,
        name string NOT NULL,
        email string NULL,
        address string NULL,
        age tinyint NULL,
        sex tinyint NULL,
        last_active datetime,
        property0 tinyint NOT NULL
    ) PRIMARY KEY (user_id)
    DISTRIBUTED BY HASH(user_id) BUCKETS 4 
    PROPERTIES("replication_num" = "1","enable_persistent_index" = "true");

**注意事项**：

*  主键相关的说明：
    
     *  在建表语句中，主键必须定义在其他列之前。
     *  主键通过 `PRIMARY KEY` 定义。
     *  主键必须满足唯一性约束，且列的值不会修改。本示例中主键为 `dt`、`order_id`。
     *  主键支持以下数据类型：BOOLEAN、TINYINT、SMALLINT、INT、BIGINT、LARGEINT、DATE、DATETIME、VARCHAR/STRING。并且不允许为 NULL。
     *  分区列和分桶列必须在主键中。
     *  合理设置主键的列数和长度。建议主键为占用内存空间较少的数据类型，例如 INT、BIGINT 等，暂时不建议为 VARCHAR。
 *  the memory occupied by the primary key index 的计算公式： (主键长度+9) x 记录数量 x 副本数 x 1.5 = 占用内存大小
    
     *  9是每行不可变的开销，
     *  1.5是每个哈希表的平均额外开销
 *  enable\_persistent\_index:主键索引可以持久化到磁盘并存储在内存中，以避免占用太多内存。

### 4. 数据导入导出 ###

#### 4.1. 数据导入 ####

*  所有导入方式都提供原子性保证，即同一个导入作业内的所有有效数据要么全部生效，要么全部不生效，不会出现仅导入部分数据的情况。
 *  通过导入作业实现数据导入。每个导入作业都有一个标签 (Label)，由用户指定或系统自动生成，用于标识该导入作业
 *  提供两种访问协议用于提交导入作业：MySQL 协议和 HTTP 协议

详见用法参见: [导入总览][Link 4]  
![在这里插入图片描述][d0626eb5256c456b8e99e56abdb0db22.png]

#### 4.2. 导出数据 ####

导出使用详见[EXPORT][]，  
**注意**：

*  导出路径需要各个BE节点都可以访问，不能是本地路径
 *  目前支持HDFS及对象存储，如
    
     *  Alibaba Cloud OSS
     *  Tencent Cloud COS
     *  AWS S3
     *  Huawei Cloud OBS  
        ![在这里插入图片描述][27fcf971e04c4f0caf2744c6d30630bd.png]  
        导出示例SQL

EXPORT TABLE db1.tbl1 
    PARTITION (p1,p2)
    (col1, col3)
    TO "hdfs://HDFS_IP:HDFS_Port/export/lineorder_" 
    PROPERTIES
    (
        "column_separator"=",",
        "load_mem_limit"="2147483648",
        "timeout" = "3600"
    )
    WITH BROKER
    (
        "username" = "user",
        "password" = "passwd"
    );

### 5. 使用 Catalog 管理和查询内外部数据 ###

#### 5.1. Catalog ####

**外部数据**：指保存在外部数据源（如 Apache Hive™、Apache Iceberg、Apache Hudi、Delta Lake、JDBC）中的数据。  
`通过Catalog不需要执行数据导入就可以直接查询`  
![在这里插入图片描述][544872bddb0c4c4c8bb85d00c8d76fee.png]  
**External catalog: 外部数据目录**，用于连接外部 metastore。在 StarRocks 中，您可以通过 external catalog 直接查询外部数据，无需进行数据导入或迁移。当前支持创建以下类型的 external catalog：

*  Hive catalog：用于查询 Hive 数据。
 *  数据湖
    
     *  Iceberg catalog：用于查询 Iceberg 数据。
     *  Hudi catalog：用于查询 Hudi 数据。
     *  Delta Lake catalog：用于查询 Delta Lake 数据。
 *  JDBC catalog：用于查询 JDBC 数据源的数据。

CREATE EXTERNAL CATALOG jdbc0
    PROPERTIES
    (
        "type"="jdbc",
        "user"="postgres",
        "password"="changeme",
        "jdbc_uri"="jdbc:postgresql://127.0.0.1:5432/jdbc_test",
        "driver_url"="https://repo1.maven.org/maven2/org/postgresql/postgresql/42.3.3/postgresql-42.3.3.jar",
        "driver_class"="org.postgresql.Driver"
    );
    
    CREATE EXTERNAL CATALOG jdbc1
    PROPERTIES
    (
        "type"="jdbc",
        "user"="root",
        "password"="changeme",
        "jdbc_uri"="jdbc:mysql://127.0.0.1:3306",
        "driver_url"="https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.28/mysql-connector-java-8.0.28.jar",
        "driver_class"="com.mysql.cj.jdbc.Driver"
    );

#### 5.2. 外部表 ####

StarRocks 支持以`外部表 (External Table)`的形式，接入其他数据源。**外部表指的是保存在其他数据源中的数据表**，而 StartRocks 只保存表对应的元数据，并直接向外部表所在数据源发起查询。  
目前 StarRocks 已支持的第三方数据源包括

*  MySQL、
 *  StarRocks、
 *  Elasticsearch、
 *  Apache Hive™、
 *  Apache Iceberg
 *  Apache Hudi。

对于 StarRocks 数据源，现阶段只支持 Insert 写入，不支持读取，对于其他数据源，现阶段只支持读取，还不支持写入。

CREATE EXTERNAL TABLE mysql_external_table
    (
        k1 DATE,
        k2 INT,
        k3 SMALLINT,
        k4 VARCHAR(2048),
        k5 DATETIME
    )
    ENGINE=mysql
    PROPERTIES
    (
        "host" = "127.0.0.1",
        "port" = "3306",
        "user" = "mysql_user",
        "password" = "mysql_passwd",
        "database" = "mysql_db_test",
        "table" = "mysql_table_test"
    );

#### 5.3. 文件外部表 ####

文件外部表 (File External Table) 是一种特殊的外部表。您可以通过文件外部表直接查询外部存储系统上的 Parquet 和 ORC 格式的数据文件，无需导入数据。同时，文件外部表也不依赖任何 Metastore。StarRocks 当前支持的外部存储系统包括 HDFS、Amazon S3 及其他兼容 S3 协议的对象存储、阿里云对象存储 OSS 和腾讯云对象存储 COS。

USE db_example;
    CREATE EXTERNAL TABLE table_1
    (
        name string, 
        id int
    ) 
    ENGINE=file
    PROPERTIES 
    (
        "path" = "s3://bucket-test/folder1/", 
        "format" = "orc",
        "aws.s3.use_instance_profile" = "true",
        "aws.s3.iam_role_arn" = "arn:aws:iam::51234343412:role/role_name_in_aws_iam",
        "aws.s3.region" = "us-west-2" 
    );

### 6. 物化视图 ###

#### 6.1. 同步物化视图 ####

同步物化视图下，所有对于基表的数据变更都会自动同步更新到物化视图中。您无需手动调用刷新命令，即可实现自动同步刷新物化视图。同步物化视图的管理成本和更新成本都比较低，适合实时场景下单表聚合查询的透明加速。

#### 6.2. 异步物化视图 ####

相较于同步物化视图，异步物化视图支持多表关联以及更加丰富的聚合算子。异步物化视图可以通过手动调用或定时任务的方式刷新，并且支持刷新部分分区，可以大幅降低刷新成本。除此之外，异步物化视图支持多种查询改写场景，实现自动、透明查询加速。

<table> 
 <thead> 
  <tr> 
   <th>** 单表聚合**</th> 
   <th><strong>多表关联</strong></th> 
   <th><strong>查询改写</strong></th> 
   <th><strong>刷新策略</strong></th> 
   <th><strong>基表</strong></th> 
   <th></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>StarRocks 2.5 异步物化视图</strong></td> 
   <td>是</td> 
   <td>是</td> 
   <td>是</td> 
   <td>异步定时刷新手动刷新</td> 
   <td>支持多表构建。基表可以来自：Default CatalogExternal Catalog已有异步物化视图</td> 
  </tr> 
  <tr> 
   <td><strong>StarRocks 2.4 异步物化视图</strong></td> 
   <td>是</td> 
   <td>是</td> 
   <td>否</td> 
   <td>异步定时刷新手动刷新</td> 
   <td>支持基于 Default Catalog 的多表构建</td> 
  </tr> 
  <tr> 
   <td><strong>同步物化视图（Rollup）</strong></td> 
   <td>仅部分聚合算子</td> 
   <td>否</td> 
   <td>是</td> 
   <td>导入同步刷新</td> 
   <td>仅支持基于 Default Catalog 的单表构建</td> 
  </tr> 
 </tbody> 
</table>

#### 6.3. Colocate Join（大表关联） ####

Colocate Join 功能是分布式系统实现 Join 数据分布的策略之一，能够减少数据多节点分布时 Join 操作引起的数据移动和网络传输，从而提高查询性能。

*  使用 Colocate Join 功能，您需要在建表时为其指定一个 Colocation Group（CG），同一 CG 内的表需遵循相同的 Colocation Group Schema（CGS），即表对应的分桶副本具有一致的分桶键、副本数量和副本放置方式
 *  如此可以保证同一 CG 内，所有表的数据分布在相同一组 BE 节点上。当 Join 列为分桶键时，计算节点只需做本地 Join，从而减少数据在节点间的传输耗时，提高查询性能

### 7. 企业架构升级示例 ###

#### 案例1 [海尔云链 金融数据查询增速三倍，服务器成本减半][Link 5] ####

*  在实时处理方面用 StarRocks 替代了以前的 Hbase+Phoenix，
 *  离线数据方面也部分用 StarRocks 替代了 Hive+Alluxio+Presto。

迭代新架构后

*  查询效率大幅提升，查询平均耗时得到了大幅缩减
 *  服务器成本整体减低到接近原体系架构的一半
 *  以前使用多服务多组件，如今统一到 StarRocks，使得运维成本也得到了大大降低。  
    ![在这里插入图片描述][63ab02ffc7aa42ee9c4131d77615f530.png]

#### 案例2 广告行业中的实时分析场景 ####

*  StarRocks 在写入和查询性能上都有比较好的表现；
 *  StarRocks 的主键能力能够承担部分 ElasticSearch 的点查点更新的场景；
 *  StarRocks 有 Connector 能力，能够直接将 ElasticSearch 作为外表关联进行一些数据探索的能力，同时也支持了谓词下推等能力，使 - - - StarRocks 与 ElasticSearch 的数据之间产生了很好的联系；
 *  因为在非常高的 QPS 的情况下，StarRocks 的能力还未能满足 QPS 和 latency 的要求，所以目前只是部分的更新和点查场景交给了 StarRocks，依然保留了 ElasticSearch 与 StarRocks 共存的场景；
 *  StarRocks 的扩缩容能力较好，面对不断变化的业务负载有很好的管理。

![e442cf6034b447cdae04908e56561838.png][]

[StarRocks]: https://cloudcoder.blog.csdn.net/article/details/130037739
[StarRocks_clickhouse]: https://cloudcoder.blog.csdn.net/article/details/130046033
[StarRocks_Jupyter]: https://cloudcoder.blog.csdn.net/article/details/131259704
[doris]: https://github.com/apache/doris
[StarRocks 1]: https://github.com/StarRocks/StarRocks
[Link 1]: https://docs.starrocks.io/zh-cn/latest/introduction/what_is_starrocks
[Link 2]: https://docs.starrocks.io/zh-cn/latest/introduction/Features
[f3cb4e181943488c8543bd49ae037029.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/cde6e2dfc3934270bda635feea0d79b3.png
[04e98cbec6bb49d2861b5b2aed8264b5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/bb7f9cc106bb4740b9d0dc2e47c0e956.png
[efb2ab59829942c9871f271229a55606.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/a42a3575e53a4d9cb7ce20e315fe343c.png
[76a6f6be58da49708bb7152719b50b2f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/e331e4a1337f4adb8295b81b7f79f2c8.png
[8ec579175e6a4880926805ba7e651bf2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/a1824d3bc83a41f9b0511d33aadee101.png
[303df19369d74362892301c557e7ec4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/045a86c87b9b425cb3f0dd056f5ea51c.png
[Link 3]: https://docs.starrocks.io/zh-cn/latest/table_design/table_types/primary_key_table
[Link 4]: https://docs.starrocks.io/zh-cn/latest/loading/Loading_intro
[d0626eb5256c456b8e99e56abdb0db22.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/654dca69895147d58f4dbd81b8fd70e6.png
[EXPORT]: https://docs.starrocks.io/zh-cn/latest/sql-reference/sql-statements/data-manipulation/EXPORT
[27fcf971e04c4f0caf2744c6d30630bd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/7226037875c64cf68e5606f8448b5132.png
[544872bddb0c4c4c8bb85d00c8d76fee.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/401498f650cc4d2091dcdbef11e9c767.png
[Link 5]: https://blog.csdn.net/flyinthesky111/article/details/124407888
[63ab02ffc7aa42ee9c4131d77615f530.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/5d45016dc808452091d5e3b429ecb90f.png
[e442cf6034b447cdae04908e56561838.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/7304fc607e7b409c917b3f7e8eeca5e5.png