IT评测·应用市场-qidao123.com技术社区

标题: StarRocks 【新一代MPP数据库】 [打印本页]

---

作者: 小秦哥    时间: 2024-8-10 14:02
标题: StarRocks 【新一代MPP数据库】
1、StarRocks

1.1、StarRocks 简介

        StarRocks 是新一代极速全场景 MPP (Massively Parallel Processing，MPP数据库是一种基于大规模并行处理惩罚技能的数据库系统，旨在高效处理惩罚大量数据。) 数据库。StarRocks 的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需颠末复杂的预处理惩罚，就可以用 StarRocks 来支持多种数据分析场景的极速分析。
        StarRocks 架构轻便，采用了全面向量化引擎，并配备全新设计的 CBO (Cost Based Optimizer) 优化器，查询速度（尤其是多表关联查询）远超同类产物。
        简单来说，StarRocks 适合对 OLAP 数据库业务（Online Analytical Processing，联机分析处理惩罚）进行分析，同时它也可以对接一些外部系统，比如把 Spark、Flink 处理惩罚的数据结果写入到 StarRocks 中，这也是支持的。
        StarRocks 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依靠，高可用，易于运维管理。StarRocks 还兼容多种主流 BI 产物，包罗 Tableau、Power BI、FineBI 和 Smartbi。
        StarRocks采用分布式架构，对数据表进行程度分别并以多副本存储。集群规模可以灵活伸缩，能够支持 10PB 级别的数据分析; 支持MPP框架，并行加速计算; 支持多副本，具有弹性容错能力。
        StarRocks采用关系模型，使用严酷的数据类型和列式存储引擎，通过编码和压缩技能，降低读写放大；使用向量化实验方式，充分挖掘多核CPU的并行计算能力，从而明显提升查询性能。
1.2、StarRocks 使用场景

        StarRocks 可以满足企业级用户的多种分析需求，包罗 OLAP (Online Analytical Processing) 多维分析、定制报表、及时数据分析和 Ad-hoc 数据分析等。
        使用 StarRocks 的 MPP 框架和向量化实验引擎，用户可以灵活的选择雪花模型，星型模型，宽表模型大概预聚合模型。实用于灵活配置的多维分析报表，业务场景包罗：
1.2.1、OLAP 多维分析​

使用 StarRocks 的 MPP 框架和向量化实验引擎，用户可以灵活的选择雪花模型，星型模型，宽表模型大概预聚合模型。实用于灵活配置的多维分析报表，业务场景包罗：

• 用户举动分析
  
• 用户画像、标签分析、圈人
  
• 高维业务指标报表
  
• 自助式报表平台
  
• 业务问题探查分析
  
• 跨主题业务分析
  
• 财务报表
  
• 系统监控分析
  

1.2.2、及时数据堆栈​

StarRocks 设计和实现了 Primary-Key 模型，能够及时更新数据并极速查询，可以秒级同步 TP (Transaction Processing) 数据库的变化，构建及时数仓，业务场景包罗：

• 电商大促数据分析
  
• 物流行业的运单分析
  
• 金融行业绩效分析、指标计算
  
• 直播质量分析
  
• 广告投放分析
  
• 管理驾驶舱
  
• 探针分析APM（Application Performance Management）
  

1.2.3、高并发查询​

StarRocks 通过良好的数据分布特性，灵活的索引以及物化视图等特性，可以办理面向用户侧的分析场景，业务场景包罗：

• 广告主报表分析
  
• 零售行业渠道人员分析
  
• SaaS 行业面向用户分析报表
  
• Dashboard 多页面分析
  

1.2.4、统一分析​

通过使用一套系统办理多维分析、高并发查询、预计算、及时分析查询等场景，降低系统复杂度和多技能栈开发与维护本钱。
使用 StarRocks 统一管理数据湖和数据堆栈，将高并发和及时性要求很高的业务放在 StarRocks 中分析，也可以使用 External Catalog 和外部表进行数据湖上的分析。
1.3、StarRocks 根本概念

• FE：FrontEnd简称FE，是StarRocks的前端节点，负责管理元数据，管理客户端毗连，进行查询规划，查询调理等工作。功能类似于 Hadoop 中的 NameNode。
  
• BE：BackEnd简称BE，是StarRocks的后端节点，负责数据存储，计算实验，以及compaction，副本管理等工作。功能类似于 Hadoop 中的 DataNode。
  
•  Broker：StarRocks中和外部HDFS/对象存储等外部数据对接的中转服务，辅助提供导入导出功能。这个工具不是必须安装的。
  
• StarRocksManager：StarRocks的管理工具，提供StarRocks集群管理、在线查询、故障查询、监控报警的可视化工具。
  
• Tablet：StarRocks中表的逻辑分片，也是StarRocks中副本管理的根本单位，每个表根据分区和分桶机制被分别成多个Tablet存储在差别BE节点上。
  

1.4、StarRocks 系统架构

StarRocks 架构轻便，整个系统的核心只有 FE（Frontend）、BE（Backend）两类历程，不依靠任何外部组件，方便摆设与维护。FE 和 BE 模块都可以在线程度扩展，元数据和业务数据都有副本机制，确保整个系统无单点。StarRocks 提供 MySQL 协议接口，支持标准 SQL 语法。用户可通过 MySQL 客户端方便地查询和分析 StarRocks 中的数据。

FE​
FE 是 StarRocks 的前端节点，负责管理元数据，管理客户端毗连，进行查询规划，查询调理等工作。每个 FE 节点都会在内存保留一份完备的元数据，这样每个 FE 节点都能够提供无差别的服务。
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 的元数据日志来异步同步数据。
    
  
  

BE​
BE 是 StarRocks 的后端节点，负责数据存储、SQL实验等工作。

• 数据存储方面，StarRocks 的 BE 节点都是完全对等的，FE 按照一定策略将数据分配到对应的 BE 节点。BE 负责将导入数据写成对应的格式存储下来，并天生相关索引。
  
• 在实验 SQL 计算时，一条 SQL 语句首先会按照具体的语义规划成逻辑实验单位，然后再按照数据的分布环境拆分成具体的物理实验单位。物理实验单位会在对应的数据存储节点上实验，这样可以实现本地计算，制止数据的传输与拷贝，从而能够得到极致的查询性能。
  

在进行 Stream load 导入时，FE 会选定一个 BE 节点作为 Coordinator BE，负责将数据分发到其他 BE 节点。导入的最终结果由 Coordinator BE 返回给用户。更多信息，参见 Stream load。
1.5、StarRocks 安装摆设

解压安装这里就不再赘述了，必要注意的是，安装的时候使用用 root ！而且 StarRocks 是集群安装。

1. # 修改目录所有者和所有组
2. sudo chown -R root:root StarRocks-1.19.1/

复制代码

1.5.1、安装 FE 

安装 FE 之前必要在 fe 目录下创建一个 meta 的目录！

1. [root@hadoop102 fe]# bin/start_fe.sh --daemon

复制代码

启动 MySQL 客户端节点： 
注意：启动命令应该是 mysql -h hadoop102 -uroot -P9030 ！！！（下面的截图是我普通用户安装的时候截的，但是不应该使用普通用户，而是使用 root 用户）

添加其他FE节点，脚色也分为FOLLOWER,OBSERVER

1. ALTER SYSTEM ADD FOLLOWER "hadoop103:9010";
3. ALTER SYSTEM ADD OBSERVER "hadoop104:9010";

复制代码

再次查看 StarRocks 集群状态：

可以看到，hadoop103 和 hadoop104 的 FE 节点并没有启动。所以在 hadoop103 和 hadoop104 上分别实验：

1. bin/start_fe.sh --helper hadoop102:9010 --daemon

复制代码

注意：只有第一次安装的时候必要指定 --helper ！之后启动就不消了！
再次查看 StarRocks 集群状态：

1.5.2、安装 BE

和安装 FE 一样，安装 BE 也必要先在每个节点的 be 目录下创建一个 storge 目录：

1. mkdir -p storage

复制代码

在 mysql 客户端添加第一个 BE 节点：

1. ALTER SYSTEM ADD BACKEND "hadoop102:9050";

复制代码

启动 hadoop102 对应的 BE 节点：

1. bin/start_be.sh --daemon

复制代码

在 MySQL 客户端添加 hadoop103 和 hadoop104 对应的 BE 节点：

1. ALTER SYSTEM ADD BACKEND "hadoop103:9050";
2. ALTER SYSTEM ADD BACKEND "hadoop104:9050";

复制代码

启动 hadoop103 和 hadoop104 上的 be 节点：

1. bin/start_be.sh --daemon

复制代码

 注意：BE 节点启动后 jps 是不表现历程的，但是可以通过客户端查询它的状态。
查看 BE 状态：

1.5.3、安装 broker（可选）

分别在 hadoop102、hadoop103 和 hadoop104 上启动 broker 节点：：

去 MySQL 客户端添加脚色地址：

1. ALTER SYSTEM ADD BROKER broker1 "hadoop102:8000";
2. ALTER SYSTEM ADD BROKER broker2 "hadoop103:8000";
3. ALTER SYSTEM ADD BROKER broker3 "hadoop104:8000";

复制代码

查看 broker 节点状态：

至此 StarRocks 安装完毕，没有想象的惊心动魄，万幸万幸。
2、StarRocks 表设计

2.1、列式存储

        StarRocks的表和关系型数据雷同, 由行和列构成. 每行数据对应用户一条纪录, 每列数据有雷同数据类型. 所有数据行的列数雷同, 可以动态增删列.  StarRocks中, 一张表的列可以分为维度列(也成为key列)和指标列(value列), 维度列用于分组和排序, 指标列可通过聚合函数SUM, COUNT, MIN, MAX, REPLACE, HLL_UNION, BITMAP_UNION等累加起来. 因此, StarRocks的表也可以以为是多维的key到多维指标的映射.
        在StarRocks中, 表中数据按列存储, 物理上, 一列数据会颠末分块编码压缩等操作, 然后持久化于非易失设备, 但在逻辑上, 一列数据可以看成由雷同类型的元素构成的数组.  一行数据的所有列在各自的列数组中保持对齐, 即拥有雷同的数组下标, 该下标称之为序号大概行号. 该序号是隐式, 不必要存储的, 表中的所有行按照维度列, 做多重排序, 排序后的位置就是该行的行号.
        查询时, 如果指定了维度列的等值条件大概范围条件, 并且这些条件中维度列可构成表维度列的前缀, 则可以使用数据的有序性, 使用range-scan快速锁定目标行. 例如: 对于表table1: (event_day, siteid, citycode, username)➜(pv); 当查询条件为event_day > 2020-09-18 and siteid = 2, 则可以使用范围查找; 如果指定条件为citycode = 4 and username in ["Andy", "Boby", "Christian", "StarRocks"], 则无法使用范围查找.（因为它的第一个条件的字段是 citycode 对应不上 starrocks 的第一个维度列，所以就无法优化查询速度）所以我们在查询的时候必要尽量遵守这个规则。
2.2、稀疏索引

当进行范围查询时，StarRocks如何快速定位到起始目标行呢？答案是使用shortkey index. shortkey index为稀疏索引。

表中构造由三个部分组成：
（1）shortkey index表:  表中数据每1024行, 构成一个逻辑block. 每个逻辑block在shortkey index表中存储一项索引, 内容为表的维度列的前缀, 并且不高出36字节.  shortkey index为稀疏索引, 用数据行的维度列的前缀查找索引表, 可以确定该行数据所在逻辑块的起始行号.
（2）Per-column data block: 这是现实存储数据的物理块（颠末压缩）。表中每一列数据按64KB分块存储,  数据块作为一个单位单独编码压缩, 也作为IO单位, 整体写回设备大概读出.
（3）Per-column cardinal index:  专门存放地址。表中的每列数据有各自的行号索引表,  列的数据块和行号索引项一一对应, 索引项由数据块的起始行号和数据块的位置和长度信息构成, 用数据行的行号查找行号索引表, 可以获取包罗该行号的数据块所在位置, 读取目标数据块后, 可以进一步查找数据.
由此可见, 查找维度列的前缀的查找过程为:  先查找shortkey index, 得到逻辑块的起始行号, 查找维度列的行号索引, 得到目标列的数据块, 读取数据块, 然后解压解码, 从数据块中找到维度列前缀对应的数据项.
2.3、加速数据处理惩罚

（1）预先聚合:  StarRocks支持聚合模型, 维度列取值雷同数据行可合并一行, 合并后数据行的维度列取值稳固, 指标列的取值为这些数据行的聚合结果, 用户必要给指标列指定聚合函数.  通过预先聚合, 可以加速聚合操作.
（2）分区分桶:  究竟上StarRocks的表被分别成tablet, 每个tablet多副本冗余存储在BE上, BE和tablet的数量可以根据计算资源和数据规模而弹性伸缩. 查询时, 多台BE可并行地查找tablet快速获取数据. 别的, tablet的副本可复制和迁移, 增强了数据的可靠性, 制止了数据倾斜. 总之, 分区分桶保证了数据访问的高效性和稳固性.
（3）RollUp表索引: shortkey index可加速数据查找, 然后shortkey index依靠维度列排列次序. 如果使用非前缀的维度列构造查找谓词, 则无法使用shortkey index. 用户可以为数据表创建若干RollUp表索引, RollUp表索引的数据构造和存储和数据表雷同, 但RollUp表拥有自身的shortkey index. 用户创建RollUp表索引时, 可选择聚合的粒度, 列的数量, 维度列的次序; 使频仍使用的查询条件能够命中相应的RollUp表索引.
（4）列级别的索引技能:  Bloomfilter可快速判定数据块中不含所查找值, ZoneMap通过数据范围快速过滤待查找值, Bitmap索引可快速计算出枚举类型的列满足一定条件的行.
2.4、数据模型

目前StarRocks根据摄入数据和现实存储数据之间的映射关系，分为明细模型（Duplicate key）、聚合模型（Aggregate key）、更新模型（Unique key）和主键模型（Primary key）。
四中模型分别对应差别的业务场景
2.4.1、明细模型

        明细模型是默认的建表模型。如果在建表时未指定任何模型，默认创建的是明细类型的表。它就像我们数仓中的 ODS 层大概 DWD 层，也就是说这个表中存储的是一些明细数据（比如用户的所有下单纪录）。
        StarRocks建表默认采用明细模型，排序列使用稀疏索引，可以快速过滤数据。明细模型用于保存所有汗青数据，并且用户可以考虑将过滤条件中频仍使用的维度列作为排序键，比如用户经常必要查看某一时间，可以将变乱时间和变乱类型作为排序键。

1. mysql> create database test_db;
2. mysql> use test_db;
3. CREATE TABLE IF NOT EXISTS detail (
4.     event_time DATETIME NOT NULL COMMENT "datetime of event",
5.     event_type INT NOT NULL COMMENT "type of event",
6.     user_id INT COMMENT "id of user",
7.     device_code INT COMMENT "device of ",
8.     channel INT COMMENT "")DUPLICATE KEY(event_time, event_type)DISTRIBUTED BY HASH(user_id) BUCKETS 8

复制代码

这是一个创建名为"detail"的数据库表的SQL语句。该表包罗以下列：

• event_time：变乱时间，数据类型为DATETIME，不能为空。
  
• event_type：变乱类型，数据类型为INT，不能为空。
  
• user_id：用户ID，数据类型为INT。
  
• device_code：设备代码，数据类型为INT。
  
• channel：通道，数据类型为INT。
  

别的，该表还具有以下约束：

• 使用 DUPLICATE KEY 子句，确保在event_time和event_type上的唯一性。
  
• 使用 DISTRIBUTED BY HASH(user_id) BUCKETS 8进行分桶存储，将数据分布在8个桶中，根据user_id的哈希值进行分布。
  

注意：这里我们指定了 event_time 和 event_type 为排序键，这里的排序键必要按照建表时的排序顺序来，排序键必须从建表语句的第一列开始！

1. INSERT INTO detail VALUES('2021-11-18 12:00:00.00',1,1001,1,1);
2. INSERT INTO detail VALUES('2021-11-17 12:00:00.00',2,1001,1,1);
3. INSERT INTO detail VALUES('2021-11-16 12:00:00.00',3,1001,1,1);
4. INSERT INTO detail VALUES('2021-11-15 12:00:00.00',1,1001,1,1);
5. INSERT INTO detail VALUES('2021-11-14 12:00:00.00',2,1001,1,1);

复制代码

查询明细数据，这种模型用来存储所有汗青明细数据（和 MySQL、Hive的使用没什么两样）：

2.4.2、聚合模型

        有些场景我们不渴望看到明细，而是渴望看到一些聚合的结果（比如用户的下单总金额），那么就可以使用聚合模型来建表。
        建表时，支持定义排序键和指标列，并为指标列指定聚合函数。当多条数据具有雷同的排序键时，指标列会进行聚合。在分析统计和汇总数据时，聚合模型能够镌汰查询时所必要处理惩罚的数据，提升查询效率。
        在数据分析中，很多场景必要基于明细数据进行统计和汇总，这个时候就可以使用聚合模型了。比如：统计app访问流量、用户访问时长、用户访问次数、展示总量、消费统计等等场景。
适合聚合模型来分析的业务场景有以下特点：

• 业务方进行查询为汇总类查询，比如sum、count、max
  
• 不必要查看原始明细数据
  
• 老数据不会被频仍修改，只会追加和新增
  

1. CREATE TABLE IF NOT EXISTS aggregate_tbl (
2.     site_id LARGEINT NOT NULL COMMENT "id of site",
3.     DATE DATE NOT NULL COMMENT "time of event",
4.     city_code VARCHAR(20) COMMENT "city_code of user",
5.     pv BIGINT SUM DEFAULT "0" COMMENT "total page views",
6.     mt BIGINT MAX
7. )
8. DISTRIBUTED BY HASH(site_id) BUCKETS 8;

复制代码

上面的表我们根据 site_id 进行了分组，分别进行聚合计算。

1. INSERT INTO aggregate_tbl VALUES(1001,'2021-11-18 12:00:00.00',100,1,5);
2. INSERT INTO aggregate_tbl VALUES(1001,'2021-11-18 12:00:00.00',100,1,10);
3. INSERT INTO aggregate_tbl VALUES(1001,'2021-11-18 12:00:00.00',100,1,15);
4. INSERT INTO aggregate_tbl VALUES(1001,'2021-11-18 12:00:00.00',100,1,100);
5. INSERT INTO aggregate_tbl VALUES(1001,'2021-11-18 12:00:00.00',100,1,20);
6. INSERT INTO aggregate_tbl VALUES(1002,'2021-11-18 12:00:00.00',100,1,5);
7. INSERT INTO aggregate_tbl VALUES(1002,'2021-11-18 12:00:00.00',100,3,25);
8. INSERT INTO aggregate_tbl VALUES(1002,'2021-11-18 12:00:00.00',100,1,15);

复制代码

2.4.3、更新模型

        建表时，支持定义主键和指标列，查询时返回主键雷同的一组数据中的最新数据。相对于明细模型，更新模型简化了数据导入流程，能够更好地支撑及时和频仍更新的场景。
        有些分析场景之下，数据必要进行更新比如拉链表，StarRocks则采用更新模型来满足这种需求,比如电商场景中，订单的状态经常会发生变化，天天的订单更新量可突破上亿。这种业务场景下，如果只靠明细模型下通过delete+insert的方式，是无法满足频仍更新需求的，因此，用户必要使用更新模型来满足分析需求。但是如果用户必要更加及时/频仍的更新操作，建议使用主键模型。
使用更新模型的场景特点：

• 已经写入的数据有大量的更新需求（汗青数据）
  
• 必要进行及时数据分析
  

1. CREATE TABLE IF NOT EXISTS update_detail (
2.     create_time DATE NOT NULL COMMENT "create time of an order",
3.     order_id BIGINT NOT NULL COMMENT "id of an order",
4.     order_state INT COMMENT "state of an order",
5.     total_price BIGINT COMMENT "price of an order"
6. )
7. UNIQUE KEY(create_time, order_id)
8. DISTRIBUTED BY HASH(order_id) BUCKETS 8

复制代码

插入测试数据，注意：现在是指定create_time和order_id为唯一键，那么雷同日期雷同订单的数据会进行覆盖操作 

1. INSERT INTO update_detail VALUES('2011-11-18',1001,1,1000);

复制代码

 继续插入一条 create_id 和 order_id 雷同的数据：

1. INSERT INTO update_detail VALUES('2011-11-18',1001,2,2000);

复制代码

查询：

 可以看到，如果日期和订单雷同则会进行覆盖操作。
2.4.4、主键模型

        StarRocks 1.19 版本推出了主键模型 (Primary Key Model) 。建表时，支持定义主键和指标列，查询时返回主键雷同的一组数据中的最新数据。相对于更新模型，主键模型在查询时不必要实验聚合操作，并且支持谓词和索引下推，能够在支持及时和频仍更新等场景的同时，提供高效查询。
        为什么有了更新模型还要有主键模型呢？其实主键模型相当于更新模型的一个升级版本。相比力更新模型，主键模型可以更好地支持及时/频仍更新的功能。固然更新模型也可以实现及时对数据的更新，但是更新模型采用Merge on Read读时合并策略会大大限定查询功能，在主键模型更好地办理了行级的更新操作。配合Flink-connector-starrocks可以完成Mysql CDC及时同步的方案。
        必要注意的是：由于存储引擎会为主键建立索引，导入数据时会把索引加载到内存中，所以主键模型对内存的要求更高，所以不适合主键模型的场景照旧比力多的。
目前比力适合使用主键模型的场景有这两种：

• 数据冷热特征，比如近来几天的数据才必要修改，老的冷数据很少必要修改，比如订单数据，老的订单完成后就不在更新，并且分区是按天进行分区的，那么在导入数据时汗青分区的数据的主键就不会被加载，也就不会占用内存了，内存中仅会加载近几天的索引。
  
• 大宽表（数百列数千列），主键只占整个数据的很小一部分，内存开销比力低。比如用户状态/画像表，固然列非常多，但总的用户数量不大（万万-亿级别），主键索引内存占用相对可控。
  

原理：由于更新模型采用Merge策略，使得谓词无法下推和索引无法使用，严峻影响查询性能。所以主键模型通过主键约束，保证同一个主键仅存一条数据的纪录，这样就规避了Merge操作。
StarRocks收到对某纪录的更新操作时，会通过主键索引找到该条数据的位置，并对其标志为删除，再插入一条数据，相当于把update改写为delete+insert

1. CREATE TABLE users (
2.     user_id BIGINT NOT NULL,
3.     NAME STRING NOT NULL,
4.     email STRING NULL,
5.     address STRING NULL,
6.     age TINYINT NULL,
7.     sex TINYINT NULL
8. ) PRIMARY KEY (user_id)
9. DISTRIBUTED BY HASH(user_id) BUCKETS 4

复制代码

测试数据：

1. INSERT INTO users VALUES(1001,'张三','111@qq.com','AAA',17,'0');
2. INSERT INTO users VALUES(1001,'李四','222@qq.com','BBB',18,'1');
3. INSERT INTO users VALUES(1002,'aaa','222@qq.com','aaa',18,'0');
4. INSERT INTO users VALUES(1002,'bbb','222@qq.com','bbb',18,'1');

复制代码

查询结果：

2.4.5、排序键

        我们在上面的四个模型中其实已经用过了。
        StarRocks中为加速查询，在内部构造并存储数据时，会把表中数据按照指定的列进行排序，这部分用于排序的列（可以是一个或多个列），可以称之为Sort Key。明细模型中Sort Key就是指定的用于排序的列（即 DUPLICATE KEY 指定的列），聚合模型中Sort Key列就是用于聚合的列（即 AGGREGATE KEY 指定的列），更新模型中Sort Key就是指定的满足唯一性约束的列（即 UNIQUE KEY 指定的列）。下图中的建表语句中Sort Key都为 (site_id、city_code)。
   CREATE TABLE site_access_duplicate(
  site_id INT DEFAULT '10',
  city_code SMALLINT,
  user_name VARCHAR(32) DEFAULT '',
  pv BIGINT DEFAULT '0')
  DUPLICATE KEY(site_id, city_code)
  DISTRIBUTED BY HASH(site_id) BUCKETS 10;
  
  CREATE TABLE site_access_aggregate(
  site_id INT DEFAULT '10',
  city_code SMALLINT,
  pv BIGINT SUM DEFAULT '0')
  AGGREGATE KEY(site_id, city_code)
  DISTRIBUTED BY HASH(site_id) BUCKETS 10;
  
  CREATE TABLE site_access_unique(
  site_id INT DEFAULT '10',
  city_code SMALLINT,
  user_name VARCHAR(32) DEFAULT '',
  pv BIGINT DEFAULT '0')
  UNIQUE KEY(site_id, city_code)
  DISTRIBUTED BY HASH(site_id) BUCKETS 10;
  三种表对应的sort key都为site_id,city_code。创建排序列必要注意以下两点：
（1）排序列的定义必须出现在建表语句中其他列的定义之前。以图5.1中的建表语句为例，三个表的排序列可以是site_id、city_code，大概site_id、city_code、user_name，但不能是city_code、user_name，大概site_id、city_code、pv。
（2）排序列的顺序是由create table语句中的列顺序决定的。DUPLICATE/UNIQUE/AGGREGATE KEY中顺序必要和create table语句保持一致。以site_access_duplicate表为例，也就是说下面的建表语句会报错。
   -- 错误的建表语句
  CREATE TABLE site_access_duplicate(
  site_id INT DEFAULT '10',
  city_code SMALLINT,
  user_name VARCHAR(32) DEFAULT '',
  pv BIGINT DEFAULT '0')
  DUPLICATE KEY(city_code, site_id)
  DISTRIBUTED BY HASH(site_id) BUCKETS 10;
  
  
  -- 正确的建表语句
  CREATE TABLE site_access_duplicate(
      site_id INT DEFAULT '10',
      city_code SMALLINT,
      user_name VARCHAR(32) DEFAULT '',
  pv BIGINT DEFAULT '0')
  DUPLICATE KEY(site_id, city_code)
  DISTRIBUTED BY HASH(site_id) BUCKETS 10;
   使用时注意事项（并不是说建了排序键就会提升查询效率，取决于查询语句）：
（1）用户查询时如果条件包罗上述两列，则可以大幅地降低扫描数据行，如：
select sum(pv) from site_access_duplicate where site_id = 123 and city_code = 2;
（2）如果查询只包罗site_id一列，也能定位到只包罗site_id的数据行，如：
select sum(pv) from site_access_duplicate where site_id = 123;（只用到了排序键的第一位同样可以优化）
（3）如果查询只包罗city_code一列，那么必要扫描所有的数据行，排序的效果相当于大打扣头，如：select sum(pv) from site_access_duplicate where city_code = 2; //使用时和mysql索引规则一样，缺少最佳左前缀原则，索引会失效
        使用排序键本质就是在进行二分查找，所以排序列指定的越多，那么消耗的内存也会越大，StarRocks为了制止这种环境发生也对排序键做了限定：

• shortkey 的列只能是排序键的前缀;
  
• shortkey 列数不高出3;
  
• 字节数不高出36字节;
  
• 不包罗FLOAT/DOUBLE类型的列;
  
• VARCHAR类型列只能出现一次, 并且是末尾位置;
  
• 当shortkey index的末尾列为CHAR大概VARCHAR类型时, shortkey的长度会高出36字节;
  
• 当用户在建表语句中指定PROPERTIES {short_key = "integer"}时, 可突破上述限定;
  

2.4.6、物化视图

Materialized Views 表：简称 MVs，物化视图
使用场景：

在现实的业务场景中，通常存在两种场景并存的分析需求：对固定维度的聚合分析 和 对原始明细数据任意维度的分析。

例如，在贩卖场景中，每条订单数据包罗这几个维度信息（item_id, sold_time, customer_id, price）。在这种场景下，有两种分析需求并存：

• 业务方必要获取某个商品在某天的贩卖额是多少，那么仅必要在维度（item_id, sold_time）维度上对 price 进行聚合即可。
  
• 分析某个人在某天对某个商品的购买明细数据。
  

在现有的 StarRocks 数据模型中，如果仅建立一个聚合模型的表，比如（item_id, sold_time, customer_id, sum(price)）。由于聚合损失了数据的部分信息，无法满足用户对明细数据的分析需求。如果仅建立一个 Duplicate 模型，虽可以满足任意维度的分析需求，但由于不支持 Rollup，分析性能不佳，无法快速完成分析。如果同时建立一个聚合模型和一个 Duplicate 模型，虽可以满足性能和任意维度分析，但两表之间本身无关联，必要业务方自行选择分析表。不灵活也不易用。

     如何使用：
使用聚合函数（如sum和count）的查询，在已经包罗聚合数据的表中可以更高效地实验。这种改进的效率对于查询大量数据尤其实用。表中的数据被物化在存储节点中，并且在增量更新中能和 Base 表保持一致。用户创建 MVs 表后，查询优化器支持选择一个最高效的 MVs 映射，并直接对 MVs 表进行查询而不是 Base 表。由于 MVs 表数据通常比 Base 表数据小很多，因此命中 MVs 表的查询速度会快很多。
创建物化视图：

1. CREATE MATERIALIZED VIEW test_detail_view
2. AS SELECT user_id,MAX(event_type),COUNT(device_code),SUM(channel) FROM detail GROUP BY user_id;

复制代码

创建完视图后，我们并不能感知创建成功，可以通过explain来分析是否命中视图。可以看到上面物化视图对event_type字段使用max函数，那么rollup命中的数据源为创建的物化视图。

1. explain select max(event_type) from detail;

复制代码

如果使用对event_type字段使用count函数，可以看到rollup命中的是detail表，而不是物化视图。

1. explain select count(event_type) from detail;

复制代码

建立物化视图可以资助用户对于差别场景都起到加速查询的作用。目前物化视图支持的函数如下有：count、max、min、sum、percentile_approx、hill_union、bitmap_union。
所以，如果使用了物化视图，那么我们在查询的时候就必要注意 SQL 中的字段是否能对应上创建的物化视图中字段的函数。
2.4.7、Bitmap 索引

StarRocks支持基于BitMap索引，对于Filter（比如where过滤）的查询有明显的加速效果。
原理：
Bitmap是元素为bit的， 取值为0、1两种情况的, 可对某一位bit进行置位(set)和清零(clear)操作的数组。Bitmap的使用场景有（判定是非）：

• 用一个long型表现32位门生的性别，0表现女生，1表现男生。
  
• 用Bitmap表现一组数据中是否存在null值，0表现元素不为null，1表现为null。
  
• 一组数据的取值为(Q1, Q2, Q3, Q4)，表现季度，用Bitmap表现这组数据中取值为Q4的元素，1表现取值为Q4的元素, 0表现其他取值的元素。
  

什么是 bitmap 索引？

        Bitmap只能表现取值为两种情况的列数组, 当列的取值为多种取值情况枚举类型时, 例如季度(Q1, Q2, Q3, Q4),  系统平台(Linux, Windows, FreeBSD, MacOS), 则无法用一个Bitmap编码; 此时可以为每个取值各自建立一个Bitmap的来表现这组数据; 同时为现实枚举取值建立词典.
        如上图所示，Platform列有4行数据，大概的取值有Android、Ios。StarRocks中会首先针对Platform列构建一个字典，将Android和Ios映射为int，然后就可以对Android和Ios分别构建Bitmap。具体来说，我们分别将Android、Ios 编码为0和1，因为Android出现在第1，2，3行，所以Bitmap是0111（从右往左），因为Ios出现在第4行，所以Bitmap是1000（从右往左）。
        如果有一个针对包罗该Platform列的表的SQL查询，select xxx from table where Platform = iOS，StarRocks会首先查找字典，找出iOS对于的编码值是1，然后再去查找 Bitmap Index，知道1对应的Bitmap是1000，我们就知道只有第4行数据符合查询条件，StarRocks就会只读取第4行数据，不会读取所有数据。
实用场景：
  使用Bitmap可以大大镌汰判定过滤时间（存储体积小：只存储一个向量比如0001），提高查询效率

• 当必要对表数据进行非前置列（排序键）进行过滤时，可以创建bitmap索引加速效率。
  
• 对表数据进行多列过滤，也可以考虑对多列分别创建bitmap索引加速效率
  

测试： 

1. CREATE TABLE IF NOT EXISTS user_dup (
2.     user_id INT,
3.     sex INT ,
4.     age INT
5.    )DUPLICATE KEY(user_id)DISTRIBUTED BY HASH(user_id) BUCKETS 8

复制代码

插入数据：

1. INSERT INTO user_dup VALUES(1001,0,18);
2.    INSERT INTO user_dup VALUES(1002,1,18);
3.    INSERT INTO user_dup VALUES(1003,0,18);
4.    INSERT INTO user_dup VALUES(1004,1,18);
5.    INSERT INTO user_dup VALUES(1005,0,18);
6.    INSERT INTO user_dup VALUES(1006,1,18);
7.    INSERT INTO user_dup VALUES(1007,0,18);
8.    INSERT INTO user_dup VALUES(1008,1,18);

复制代码

创建位图索引：

1. CREATE INDEX user_sex_index ON user_dup(sex) USING bitmap;

复制代码

查看索引：

1. SHOW INDEX FROM user_dup;

复制代码

注意事项：
（1）对于明细模型，所有列都可以建Bitmap 索引；对于聚合模型，只有Key列可以建Bitmap 索引。
（2）Bitmap索引, 应该在取值为枚举型, 取值大量重复, 较低基数, 并且用作等值条件查询大概可转化为等值条件查询的列上创建.
（3）不支持对Float、Double、Decimal 类型的列建Bitmap 索引。
（4）如果要查看某个查询是否命中了Bitmap索引，可以通过查询的Profile信息查看。
2.4.8、Bloom Filter 索引

什么是Bloom Filter:
        Bloom Filter（布隆过滤器）是用于判定某个元素是否在一个聚集中的数据结构，优点是空间效率和时间效率都比力高，缺点是有一定的误判率（因为差别值的hash值大概是雷同的，默认循环三次hash算法，如果要求正确率高，必要进行更多层的for循环）。

        布隆过滤器是由一个Bit数组和n个哈希函数构成。Bit数组初始全部为0，当插入一个元素时，n个Hash函数对元素进行计算, 得到n个slot，然后将Bit数组中n个slot的Bit置1。

        当我们要判定一个元素是否在聚集中时，照旧通过雷同的n个Hash函数计算Hash值，如果所有Hash值在布隆过滤器里对应的Bit不全为1，则该元素不存在。当对应Bit全1时, 则元素的存在与否, 无法确定.  这是因为布隆过滤器的位数有限,  由该元素计算出的slot, 恰好全部和其他元素的slot冲突.  所以全1情况, 必要回源查找才气判定元素的存在性。
什么是Bloom Filter 索引:

StarRocks的建表时, 可通过PROPERTIES{"bloom_filter_columns"="c1,c2,c3"}指定必要建BloomFilter索引的列，查询时, BloomFilter可快速判定某个列中是否存在某个值。如果Bloom Filter判定该列中不存在指定的值，就不必要读取数据文件；如果是全1情况，此时必要读取数据块确认目标值是否存在。别的，Bloom Filter索引无法确定具体是哪一行数据具有该指定的值。

• 建表时指定必要加Bloom Filter索引的列，创建一张测试表
  

1. CREATE TABLE test_bf(
2. id INT,
3. event_type INT,
4. email INT,
5. sex INT,
6. age INT
7. )DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 8
8. PROPERTIES("bloom_filter_columns"="event_type,sex");

复制代码

• 查看Bloom Filter索引。使用show index查看不到Bloom Filter索引，得用show create table 命令
  

1. SHOW CREATE TABLE test_bf

复制代码

• 删除索引
  

1. alter table test_bf set("bloom_filter_columns"="");

复制代码

注意事项：
（1）不支持对Tinyint、Float、Double 类型的列建Bloom Filter索引。
（2）Bloom Filter索引只对in和=过滤查询有加速效果。
（3）如果要查看某个查询是否命中了Bloom Filter索引，可以通过查询的Profile信息查看（TODO：加上查看Profile的链接）。
3、数据导入与查询

3.1、Stream Load（同步导入）

        StarRocks支持从本地直接导入数据，支持CSV格式。数据量在10G以下，可以使用Stream Load导入，这种导入方式是通过用户发送HTTP请求将本地文件或数据流导入到StarRocks中。Stream Load 同步实验导入并返回结果。用户可以直接通过返回结果判定是否导入成功。
        根本原理：Steam Load中，用户通过HTTP协议提交导入命令，提交到FE节点，FE节点则会通过HTTP 重定向指令请求转发给某一个BE节点，用户也可以直接提交导入命令指定BE节点。

测试：

1. [root@hadoop102 ~]# vim test.csv
2. 1001,'test1',123456@.qqcom,'测试地址1',18,1
3. 1002,'test2',123456@.qqcom,'测试地址2',18,1
4. 1003,'test3',123456@.qqcom,'测试地址3',20,0
5. 1004,'test4',123456@.qqcom,'测试地址4',21,1
6. 1005,'test5',123456@.qqcom,'测试地址5',23,0
7. 1006,'test6',123456@.qqcom,'测试地址6',22,1
8. 1007,'test7',123456@.qqcom,'测试地址7',18,0
9. 1008,'test8',123456@.qqcom,'测试地址8',25,1
10. 1009,'test9',123456@.qqcom,'测试地址9',19,0
11. 1010,'test10',123456@.qqcom,'测试地址10',10,1
12. 1011,'test11',123456@.qqcom,'测试地址11',18,1

复制代码

根据官网语法将CSV数据导入对应user表中，官网语法：

1. curl --location-trusted -u user:passwd [-H ""...] -T data.file -XPUT  http://fe_host:http_port/api/{db}/{table}/_stream_load

复制代码

注意：命令-H 为头部信息 column_separator为测试文件中字段间隔符，固然官网写着支持csv但默认是\t，默认支持tsv所以这把这个参数改成逗号

1. [root@hadoop102 ~]# curl --location-trusted -u root -T test.csv -H "column_separator:," http://hadoop102:8030/api/test/users/_stream_load

复制代码

因为Stream load是同步导入，所以可以立马看到是否导入成功：

这里的 '_stream_load' 只是一个标识符 
导入成功后，查看对应的users表

同时，我们也可以通过访问 hadoop102:8030 来访问 starrocks 的 Web UI：

3.2、Broker Load（异步导入）

        StarRocks支持从Apache HDFS、Amazon S3等外部存储系导入数据，支持CSV、ORCFile、Parquet等文件格式。数据量在几十GB到上百GB 级别。
        在Broker Load模式下，通过摆设的Broker程序，StarRocks可读取对应数据源（如HDFS, S3）上的数据，使用自身的计算资源对数据进行预处理惩罚和导入。这是一种异步的导入方式，用户必要通过MySQL协议创建导入，并通过查看导入命令检查导入结果。

使用 broker load 的时候必须保证 broker 历程启动！
这里演示Apache HDFS导入StarRocks,将Hadoop集群的hdfs-site.xml文件复制到对应broker conf 目录下：
Broker Load 支持如下数据文件格式：

• CSV
  
• Parquet
  
• ORC
  

创建两个 csv 文件并上传到 HDFS ：
file1.csv：

1. 1,Lily,23
2. 2,Rose,23
3. 3,Alice,24
4. 4,Julia,25

复制代码

file2.csv： 

1. 200,'北京'

复制代码

StarRocks 创建两张表，分别对应两个文件：

1. CREATE TABLE `table1`
2. (
3.     `id` int(11) NOT NULL COMMENT "用户 ID",
4.     `name` varchar(65533) NULL DEFAULT "" COMMENT "用户姓名",
5.     `score` int(11) NOT NULL DEFAULT "0" COMMENT "用户得分"
6. )
7.     ENGINE=OLAP
8.     PRIMARY KEY(`id`)
9.     DISTRIBUTED BY HASH(`id`) BUCKETS 10;
11. CREATE TABLE `table2`
12. (
13.     `id` int(11) NOT NULL COMMENT "城市 ID",
14.     `city` varchar(65533) NULL DEFAULT "" COMMENT "城市名称"
15. )
16.     ENGINE=OLAP
17.     PRIMARY KEY(`id`)
18.     DISTRIBUTED BY HASH(`id`) BUCKETS 10;

复制代码

从 HDFS 导入： 

1. LOAD LABEL test_db.label1
2. (
3.     DATA INFILE("hdfs://hadoop102:8020/starrocks/file1.csv")
4.     INTO TABLE table1
5.     COLUMNS TERMINATED BY ","
6.     (id, name, score)
7.     ,
8.     DATA INFILE("hdfs://hadoop102:8020/starrocks/file2.csv")
9.     INTO TABLE table2
10.     COLUMNS TERMINATED BY ","
11.    (id, city)
12. )
13. WITH BROKER "broker1"
14. (
15.     "hadoop.security.authentication" = "simple",
16.     "username" = "lyh",
17.     "password" = "123456"
18. )
19. PROPERTIES
20. (
21.     "timeout" = "3600"
22. );

复制代码

 注意：下面标志的地方是必要自定义的地方，参考官网文档：

查看 load 计划：

1. show load where label=load名称

复制代码

查询导入结果： 

3.3、Rountine Load

        如果您必要将消息流不间断地导入至 StarRocks，则可以将消息流存储在 Kafka 的 Topic 中，并向 StarRocks 提交一个 Routine Load 导入作业。 StarRocks 会常驻地运行这个导入作业，持续天生一系列导入使命，消费 Kafka 集群中该 Topic 中的全部或部分分区的消息并导入到 StarRocks 中。
        Routine Load 支持 Exactly-Once 语义，能够保证数据不丢不重。
        Routine Load 目前支持从 Kakfa 集群中消费 CSV、JSON 格式的数据。

环境要求：
（1）支持访问无认证或使用 SSL 方式认证的 Kafka 集群。
（2）支持的消息格式为 CSV 文本格式，每一个 message 为一行，且行尾不包罗换行符。
（3）仅支持 Kafka 0.10.0.0(含) 以上版本。
3.3.1、测试把Kafka的数据导入到StarRocks

StarRocks 创建表格： 

1. CREATE TABLE test_kafka_routine(
2.     `order_id` bigint NOT NULL COMMENT "订单编号",
3.     `pay_dt` date NOT NULL COMMENT "支付日期",
4.     `customer_name` varchar(26) NULL COMMENT "顾客姓名",
5.     `nationality` varchar(26) NULL COMMENT "国籍",
6.     `price`double NULL COMMENT "支付金额"
7. )
8. ENGINE=OLAP
9. DUPLICATE KEY (order_id,pay_dt)
10. DISTRIBUTED BY HASH(`order_id`) BUCKETS 5;

复制代码

创建作业（配置Kafka输入源参数）： 

1. CREATE ROUTINE LOAD test_db.test_kafka_routine_like ON test_kafka_routine
2. COLUMNS TERMINATED BY ",",
3. COLUMNS (order_id, pay_dt, customer_name, nationality, temp_gender, price)
4. PROPERTIES
5. (
6.     "desired_concurrent_number" = "3" #并行度(BE的数量)
7. )
8. FROM KAFKA
9. (
10.     "kafka_broker_list" ="hadoop102:9092,hadoop103:9092,hadoop104:9092",
11.     "kafka_topic" = "like",
12.     "kafka_partitions" ="0,1,2",
13.     "property.kafka_default_offsets" = "OFFSET_BEGINNING"
14. );

复制代码

查询所有使命： 

启动 Kafka 生产者： 

 查询：

可以看到，我们写入到 Kafka like 分区的数据被成功写入到表格中。 

继续测试：

3.3.2、查看导入作业

除了上面的 show routine load\G 查看所有导入的作业之外，还可以通过下面的这些方法查看导入的作业：
通过名称查看导入作业

3.3.3、查看导入使命

3.3.4、暂停导入作业 

3.3.5、恢复导入作业

1. RESUME ROUTINE LOAD FOR test_kafka_routine_like \G

复制代码

3.3.6、停止导入作业

 3.3.7、修改导入作业​

官方文档写得很具体
4、使用 StarRocks

4.1、Colocate join

Colocate Join 功能是分布式系统实现 Join 数据分布的策略之一，能够镌汰数据多节点分布时 Join 操作引起的数据移动和网络传输，从而提高查询性能。（也就是把要 join 的数据尽大概放到雷同的 BE 节点）
在 StarRocks 中使用 Colocate Join 功能，您必要在建表时为其指定一个 Colocation Group（CG），同一 CG 内的表需依照雷同的 Colocation Group Schema（CGS），即表对应的分桶副本具有一致的分桶键、副本数量和副本放置方式。云云可以保证同一 CG 内，所有表的数据分布在雷同一组 BE 节点上。当 Join 列为分桶键时，计算节点只需做本地 Join，从而镌汰数据在节点间的传输耗时，提高查询性能。因此，Colocate Join，相对于其他 Join，例如 Shuffle Join 和 Broadcast Join，可以有用制止数据网络传输开销，提高查询性能。
Colocate Join 支持等值 Join。
4.1.1、创建 Colocate 表

在建表时，必要在 PROPERTIES 中指定属性 "colocate_with" = "group_name" 以创建一个 Colocate Join 表，并且指定其归属于特定的 Colocation Group。

1. CREATE TABLE `tbl1` (
2.     `k1` date NOT NULL COMMENT "",
3.     `k2` int(11) NOT NULL COMMENT "",
4.     `v1` int(11) SUM NOT NULL COMMENT ""
5. ) ENGINE=OLAP
6. AGGREGATE KEY(`k1`, `k2`) -- 排序键必须一致
7. DISTRIBUTED BY HASH(`k2`) BUCKETS 8  -- 分桶键类型和分桶数必须一致
8. PROPERTIES (
9.     "colocate_with" = "group1" -- 指定为同一组
10. );
12. CREATE TABLE `tbl2` (
13.     `k1` date NOT NULL COMMENT "",
14.     `k2` int(11) NOT NULL COMMENT "",
15.     `v1` int(11) SUM NOT NULL COMMENT ""
16. ) ENGINE=OLAP
17. AGGREGATE KEY(`k1`, `k2`) -- 排序键必须一致
18. DISTRIBUTED BY HASH(`k2`) BUCKETS 8 -- 分桶键类型和分桶数必须一致
19. PROPERTIES (
20.     "colocate_with" = "group1" -- 指定为同一组
21. );

复制代码

要想达到优化查询的目标，必须满足下面这些条件：

• 同一 CG 内的表的分桶键的类型、数量和顺序完全一致，并且桶数一致，从而保证多张表的数据分片能够一一对应地进行分布控制。
  
• 同 CG 的表的分桶键的名字可以不雷同，分桶列的定义在建表语句中的出现次序可以不一致，但是在 DISTRIBUTED BY HASH(col1, col2, ...) 的对应数据类型的顺序要完全一致。
  
• 同一个 CG 内所有表的所有分区的副本数必须一致（默认都是 3）。
  
• 同一个 CG 内所有表的分区键，分区数量可以差别。
  

查询是否得到优化： 

1. explain SELECT * FROM tbl1 INNER JOIN tbl2 ON (tbl1.k2 = tbl2.k2);

复制代码

4.2、外部表

        StarRocks 不支持修改（update）功能的，所以如果 StarRocks 要修改数据的话，要么把数据模型设置为主键模型大概更新模型，同时 StarRocks 也提供了一种方案——外部表，也就是可以让 StarRocks 对接外部表，当外部表发生变化的时候，StarRocks 本身也会发生变化。当前 StarRocks 已支持的第三方数据源包罗 MySQL、Elasticsearch、Apache Hive™、StarRocks、Apache Iceberg 和 Apache Hudi。对于 StarRocks 数据源（StarRocks类型的外部表），现阶段只支持 Insert 写入，不支持读取；对于其他数据源（别的类型外部表），现阶段只支持读取，还不支持写入。
4.2.1、MySQL 外部表

首先在 MySQL 创建一张测试表：

插入测试数据：

在 StarRocks 中创建外部表：

1. CREATE EXTERNAL TABLE mysql_external_table
2. (
3.     id int,
4.     name varchar(20),
5.     age int
6. )
7. ENGINE=mysql
8. PROPERTIES
9. (
10.     "host" = "hadoop102",
11.     "port" = "3306",
12.     "user" = "root",
13.     "password" = "123456",
14.     "database" = "starrocks",
15.     "table" = "test_t1"
16. );

复制代码

查询外部表：

必要注意的是，StarRocks 是不支持修改数据的（不管是外部表照旧内部表）：

但是可以通过修改外部数据源来更新 StarRocks 的外部表：

4.2.2、Hive 外部表

启动 Hadoop、Hive（这里很大概遇到 Yarn 启动失败，因为 StarRocks 会占用 Yarn 的 8030、8040 端口）

通过 tail -500 xxx-resourcemanager.log 查看日志
查看端口是否被占用：

1. netstat -tnlp | grep :8040

复制代码

监听日志文件：

1. tail -f 日志文件.log

复制代码

Yarn 官方默认配置文档（yarn-site.xml）
修改被占用的端口：

创建 Hive 表：

1. use test;
3. create table test_t1(
4. id int ,
5. name string,
6. age int);

复制代码

 向 Hive 表中插入数据（这里用的是 Spark 引擎）：

在 StarRocks 中创建 Hive 数据源：

1. CREATE EXTERNAL RESOURCE "hive0"
2. PROPERTIES (
3.   "type" = "hive",
4.   "hive.metastore.uris" = "thrift://hadoop102:9083");

复制代码

创建 Hive 外部表：

1. create external table hive_t1(
2. id int,
3. name varchar(20),
4. age int)
5. ENGINE=HIVE
6. PROPERTIES (
7.   "resource" = "hive0",
8.   "database" = "test",
9.   "table" = "test_t1"
10. );

复制代码

去 hadoop102:8030 的 WebUI 去查看日志：

去官网查询办理方案：

照旧查询失败，尝试换 csv 数据源的 Hive 表作为外部表照旧不行（大概是版本的问题？之后办理再来更新）。
4.3、数组

StarRocks 是支持数组类型字段的，建表的时候使用。

1. CREATE TABLE student(
2. id INT,
3. hobbies ARRAY<INT>
4. )
5. DUPLICATE KEY(id)
6. DISTRIBUTED BY HASH(id) BUCKETS 3;

复制代码

查询数组字段指定索引的值：

 同时 StarRocks 也支持嵌套数组

1. create table t1(
2.   c0 INT,
3.   c1 ARRAY<ARRAY<VARCHAR(10)>>
4. )
5. duplicate key(c0)
6. distributed by hash(c0) buckets 3;
8. INSERT INTO t1 VALUES(1, [[1,2,3],[1,2,3],[4,5,6]]);

复制代码

数组的使用有以下限定

• 只能在duplicate table（明细模型）中定义数组列
  
• 数组列不能作为key列(以后大概支持)
  
• 数组列不能作为distribution列
  
• 数组列不能作为partition列
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)

Powered by Discuz! X3.4