StarRocks介紹

StarRocks，作為新一代極速全場(chǎng)景MPP（Massively Parallel Processing）數(shù)據(jù)庫(kù)，充分汲取了關(guān)系型OLAP數(shù)據(jù)庫(kù)與分布式存儲(chǔ)系統(tǒng)在大數(shù)據(jù)時(shí)代的精髓。通過(guò)不斷的改進(jìn)與優(yōu)化，它在架構(gòu)上進(jìn)行了升級(jí)，并增添了諸多創(chuàng)新功能，從而演變?yōu)橐豢铑I(lǐng)先的企業(yè)級(jí)產(chǎn)品。StarRocks致力于為用戶提供極速且統(tǒng)一的分析體驗(yàn)，能夠靈活應(yīng)對(duì)各種數(shù)據(jù)分析場(chǎng)景。它支持多種數(shù)據(jù)模型、導(dǎo)入方式，并能輕松整合及接入現(xiàn)有系統(tǒng)，如Spark、Flink、Hive和ElasticSearch等。

此外，StarRocks還兼容MySQL協(xié)議，使得用戶能夠通過(guò)MySQL客戶端及常用BI工具輕松進(jìn)行數(shù)據(jù)分析。其分布式架構(gòu)特性使得數(shù)據(jù)表能夠水平劃分并多副本存儲(chǔ)，集群規(guī)?？伸`活調(diào)整，支持高達(dá)10PB級(jí)別的數(shù)據(jù)分析。同時(shí)，MPP框架的引入使得計(jì)算能夠并行加速，而多副本設(shè)計(jì)則提供了彈性容錯(cuò)能力。

在技術(shù)層面，StarRocks采用關(guān)系模型和嚴(yán)格的列式存儲(chǔ)引擎，通過(guò)精妙的編碼和壓縮技術(shù)來(lái)降低讀寫(xiě)放大效應(yīng)。其向量化執(zhí)行方式能充分利用多核CPU的并行計(jì)算能力，從而顯著提升查詢性能。要實(shí)現(xiàn)這一技術(shù)，需要借助CPU的SIMD指令集，這是一種能夠在CPU寄存器層面實(shí)現(xiàn)數(shù)據(jù)并行操作的技術(shù)。

什么是StarRocks？

StarRocks是新一代極速全場(chǎng)景MPP數(shù)據(jù)庫(kù)（高并發(fā)數(shù)據(jù)庫(kù)）。

StarRocks充分吸收關(guān)系型OLAP數(shù)據(jù)庫(kù)和分布式存儲(chǔ)系統(tǒng)在大數(shù)據(jù)時(shí)代的優(yōu)秀研究成果。

1.可以在Spark和Flink里面處理數(shù)據(jù)，然后將處理完的數(shù)據(jù)寫(xiě)到StarRocks里面。

2.可以實(shí)現(xiàn)將數(shù)據(jù)從Hadoop倒入到StarRocks里面去，也可以將StarRocks的數(shù)據(jù)倒入到Hadoop里面，都是可以實(shí)現(xiàn)的。

3.可以對(duì)接ES數(shù)據(jù)庫(kù)（ElasticSearch）。

4.StarRocks兼容MySQL的協(xié)議，可以通過(guò) MySQL的客戶端 和 常用BI工具 對(duì)接StarRocks來(lái)進(jìn)行數(shù)據(jù)分析。

5.StarRocks采用分布式架構(gòu)，對(duì)數(shù)據(jù)表進(jìn)行水平劃分并且以多副本存儲(chǔ)，集群規(guī)?？梢造`活伸縮，能夠支持10PB級(jí)別的數(shù)據(jù)分析，支持MPP框架，并行加速計(jì)算，支持多副本，具有彈性容錯(cuò)能力。

StarRocks適合什么場(chǎng)景？

1.OLAP多維分析：用戶行為分析，用戶畫(huà)像，財(cái)務(wù)報(bào)表，系統(tǒng)監(jiān)控分析。

2.實(shí)時(shí)數(shù)據(jù)分析：電商數(shù)據(jù)分析，直播質(zhì)量分析，物流運(yùn)單分析，廣告投放分析。

3.高并發(fā)查詢：廣告主表分析，Dashboard多頁(yè)面分析。

4.統(tǒng)一分析：通過(guò)使用一套系統(tǒng)解決上述場(chǎng)景，降低系統(tǒng)復(fù)雜度和多技術(shù)棧開(kāi)發(fā)成本。

StarRocks基本概念：

1.FE：FrondEnd是StarRocks的前端節(jié)點(diǎn)，負(fù)責(zé)管理元數(shù)據(jù)，負(fù)責(zé)與客戶端連接，進(jìn)行查詢規(guī)劃，查詢調(diào)度等工作。

2.BE：BackEnd時(shí)StarRocks的后端節(jié)點(diǎn)，負(fù)責(zé)數(shù)據(jù)存儲(chǔ)，計(jì)算執(zhí)行，以及Compaction，副本管理等工作。

3.Broker：Broker并不是必須出現(xiàn)的，當(dāng)StarRocks和HDFS進(jìn)行交互的時(shí)候（也就是數(shù)據(jù)從HDFS到StarRocks中 和 數(shù)據(jù)從StarRocks中到HDFS里面），那么StaRocks負(fù)責(zé)這個(gè)過(guò)程的中轉(zhuǎn)服務(wù)，輔助提供導(dǎo)入導(dǎo)出功能。

4.StarRocksManager：StarRocks的可視化工具，提供StarRocks的集群管理，在線查詢，故障查詢，監(jiān)控報(bào)警的可視化工具。

5.Tablet：StarRocks中表的邏輯分片，也是StarRocks中副本管理的基本單位，每個(gè)表根據(jù)分區(qū)和分桶機(jī)制被劃分成多個(gè)Tablet存儲(chǔ)在不同BE節(jié)點(diǎn)上。

StarRocks系統(tǒng)架構(gòu)：

FE：

1.接受MySQL客戶端的連接，解析并且執(zhí)行SQL語(yǔ)句。

2.管理元數(shù)據(jù)，執(zhí)行SQL DDL命令，用CataLog記錄庫(kù)，表，分區(qū)，tablet副本等信息。

3.FE高可用部署，使用 復(fù)制協(xié)議選主 和 主從同步 元數(shù)據(jù)，所有的元數(shù)據(jù)修改操作，都有FE的leader節(jié)點(diǎn)完成，F(xiàn)E的follower節(jié)點(diǎn)可執(zhí)行讀操作。元數(shù)據(jù)的讀寫(xiě)滿足順序一致性，F(xiàn)E的節(jié)點(diǎn)數(shù)目采用2n+1，可以容忍n個(gè)節(jié)點(diǎn)故障，當(dāng)FE leader故障的時(shí)候，可以從現(xiàn)有的follower節(jié)點(diǎn)中重新選主，完成故障切換。

4.FE中的SQL Layer對(duì)用戶提交的SQL進(jìn)行解析，分析，改寫(xiě)，語(yǔ)義分析和關(guān)系代數(shù)優(yōu)化，生產(chǎn)邏輯執(zhí)行計(jì)劃。

5.FE中的Planner負(fù)責(zé)把邏輯計(jì)劃轉(zhuǎn)化為可分布式執(zhí)行的物理計(jì)劃，分發(fā)給一組BE。

6.FE監(jiān)督BE，管理BE的上下線，根據(jù)BE的存活和健康狀態(tài)，維持tablet副本的數(shù)量。

7.FE協(xié)調(diào)數(shù)據(jù)導(dǎo)入，保證數(shù)據(jù)導(dǎo)入的一致性。

BE：

1.BE管理tablet副本，tablet時(shí)table經(jīng)過(guò)分區(qū)分桶形成的子表，采用列式存儲(chǔ)。

2.BE受FE指導(dǎo)，創(chuàng)建或刪除子表。

3.BE接收FE分發(fā)的物理執(zhí)行計(jì)劃并指定BE coordinator節(jié)點(diǎn)，在BE coordinator的調(diào)度下，與其他BE worker共同協(xié)作完成執(zhí)行。

4.BE讀本地的列存儲(chǔ)引擎獲取數(shù)據(jù)，并通過(guò)索引和謂詞下沉快速過(guò)濾數(shù)據(jù)。

5.BE后臺(tái)執(zhí)行compact任務(wù)，減少查詢時(shí)的讀放大。

6.數(shù)據(jù)導(dǎo)入的時(shí)候，由FE指定BE coordinator，將數(shù)據(jù)以fanout的形式寫(xiě)入到tablet多副本所在的BE上。

StarRocks為什么快：

列式存儲(chǔ)：StarRocks中，一張表的列可以分為維度列（key列）和指標(biāo)列（value列），維度列用于分組和排序，指標(biāo)列可通過(guò)聚合函數(shù)等累加起來(lái)。StarRocks可以認(rèn)為是多維的key到多維指標(biāo)的映射。（在寫(xiě)SQL的時(shí)候最好要根據(jù)表的前綴，類似于MySQL的索引最左前綴原則）

稀疏索引：當(dāng)進(jìn)行范圍查詢時(shí)，StarRocks能夠快速定位到起始目標(biāo)行，是因?yàn)閟hortkey index（稀疏索引）。

預(yù)先聚合：StarRocks支持聚合模型，維度列取值相同數(shù)據(jù)行可合并一行，合并后數(shù)據(jù)行的維度列取值不變，指標(biāo)列的取值為這些數(shù)據(jù)行的聚合結(jié)果，用戶需要給指標(biāo)列指定聚合函數(shù)，通過(guò)預(yù)先聚合，可以加速聚合操作。

分區(qū)分桶：StarRocks的表被分為tablet，每個(gè)tablet多副本冗余存儲(chǔ)在BE上，BE和tablet的數(shù)量可以根據(jù)計(jì)算資源和數(shù)據(jù)規(guī)模而彈性伸縮，查詢時(shí)，多臺(tái)BE可并行地查找tablet快速獲取數(shù)據(jù)。而且tablet的副本可以復(fù)制和前一，增強(qiáng)了數(shù)據(jù)的可靠性，避免了數(shù)據(jù)傾斜。

列級(jí)別的索引技術(shù)：Bloomfilter可以快速判斷數(shù)據(jù)塊中不含所查找值，ZoneMap通過(guò)數(shù)據(jù)范圍快速過(guò)濾待查找值，Bitmap索引可快速計(jì)算出枚舉類型的列滿足一定條件的行。

StarRocks的4種表模型：

明細(xì)模型（Duplicate key）：關(guān)注歷史數(shù)據(jù)。

聚合模型（Aggregate key）：關(guān)注總量，平均值，最大值，最小值，計(jì)算一個(gè)統(tǒng)一的指標(biāo)。

更新模型（Unique key）：設(shè)定一個(gè)主鍵（uid），主鍵是唯一的，如果主鍵是第一次出現(xiàn)在表中，那么執(zhí)行插入操作，如果主鍵第二次出現(xiàn)在表中，那么執(zhí)行更新操作，覆蓋前一條記錄。（并不是真的覆蓋，其實(shí)也存著明細(xì)數(shù)據(jù)，只是將最新的一條記錄返回）

主鍵模型（Primary key）：主鍵模型相當(dāng)于是更新模型的升級(jí)版，速度更快一些。更新模型采用Merge on Read讀時(shí)合并策略會(huì)大大限制查詢功能，在主鍵模型更好地解決了行級(jí)的更新操作。配合Flink-connector-starrocks可以完成MySQL CDC實(shí)時(shí)同步的方案。存儲(chǔ)引擎會(huì)為主鍵建立索引，導(dǎo)入數(shù)據(jù)時(shí)會(huì)把索引加載到內(nèi)存中，所以主鍵模型對(duì)內(nèi)存的要求更高。真正保證每個(gè)主鍵只有一條數(shù)據(jù)存在。

各自適用場(chǎng)景：

1.明細(xì)模型：建表的時(shí)候注意設(shè)置排序列（duplicate key）

關(guān)注歷史明細(xì)數(shù)據(jù)。

2.聚合模型：建表的時(shí)候注意設(shè)置聚合列（ distributed by hash(site_id) ）

業(yè)務(wù)方進(jìn)行查詢?yōu)閰R總類查詢，比如sum，count，max。

不需要查看明細(xì)數(shù)據(jù)。

老數(shù)據(jù)不會(huì)被頻繁修改，只會(huì)追加和新增。

3.更新模型：建表的時(shí)候注意設(shè)置UNIQUE KEY 唯一列(create_time,order_id)

數(shù)據(jù)需要進(jìn)行更新，比如拉鏈表。

已經(jīng)寫(xiě)入的數(shù)據(jù)有大量的更新需求。（比如電商場(chǎng)景中，訂單的狀態(tài)經(jīng)常會(huì)發(fā)生變化，沒(méi)必要用明細(xì)表記錄變化趨勢(shì)，使用更新模型記錄最新的狀態(tài)即可）

需要進(jìn)行實(shí)時(shí)數(shù)據(jù)分析。

4.主鍵模型：建表的時(shí)候注意PRIMARY KEY主鍵列（user_id）

數(shù)據(jù)冷熱特征：只有最近幾天的數(shù)據(jù)才需要修改，老的冷數(shù)據(jù)很少需要修改，比如訂單數(shù)據(jù)，老的訂單完成后就不再更新，并且分區(qū)是按天進(jìn)行分區(qū)的，那么在導(dǎo)入數(shù)據(jù)時(shí)歷史分區(qū)的數(shù)據(jù)的主鍵就不會(huì)被加載，也就不會(huì)占用內(nèi)存了，內(nèi)存中僅會(huì)加載近幾天的索引。

大寬表（數(shù)百列數(shù)千列）：主鍵只占整個(gè)數(shù)據(jù)的很小一部分，內(nèi)存開(kāi)銷比較低。比如用戶狀態(tài)/畫(huà)像表，雖然列非常多，但總的用戶數(shù)量不大，主鍵索引內(nèi)存占用相對(duì)可控。

StarRocks排序列：

明細(xì)模型中的排序列可以理解成是 DUPLICATED KEY

聚合模型中的排序列可以理解成是 AGGREGATE KEY

更新模型中的排序列可以理解成是UNIQUE KEY

主鍵模型中的排序列可以理解成是PRIMARY KEY

排序列的設(shè)定順序必須和建表語(yǔ)句的字段順序一樣，如果想使用到排序列那么必須要按照類似于MySQL的索引最左前綴原則，設(shè)定where條件。

使用排序鍵的本質(zhì)其實(shí)就是在進(jìn)行二分查找，所以排序列指定的越多，那么消耗的內(nèi)存也會(huì)越大，StarRocks為了避免這種情況發(fā)生也對(duì)排序鍵做了限制：

1.排序鍵的列只能是建表字段的前綴。

2.排序鍵的列數(shù)不能超過(guò)3.

3.字節(jié)數(shù)不超過(guò)36字節(jié)。

4.不包含F(xiàn)LOAT/DOUBLE類型的列。

5.Varchar類型列只能出現(xiàn)一次，并且是末尾位置。

物化視圖：Materialized View（MVs）物化視圖

在基于維度進(jìn)行分析的時(shí)候，需要使用物化視圖。

StarRocks中Bitmap索引：

BitMap索引利用位數(shù)組（bit array）來(lái)表示數(shù)據(jù)集中某個(gè)屬性的所有可能值是否出現(xiàn)，每個(gè)位對(duì)應(yīng)數(shù)據(jù)表中的一行記錄，如果該位為1，則表示該行記錄具有指定的屬性值；如果為0，則表示不具備。這種結(jié)構(gòu)非常適合于 處理布爾型查詢 或者 枚舉類型比較少 的列查詢，比如性別。

BitMap在一些場(chǎng)景下表現(xiàn)的比較優(yōu)秀，但是同樣也存在著局限性：

1.內(nèi)存消耗：BitMap索引會(huì)占據(jù)比較大的內(nèi)存空間。

2.更新成本：當(dāng)數(shù)據(jù)插入，刪除或者更新的時(shí)候，對(duì)應(yīng)的位圖需要維護(hù)，會(huì)產(chǎn)生開(kāi)銷。

總結(jié)：最適用的場(chǎng)景是針對(duì)于低基數(shù)（列中不同值的數(shù)量很少），會(huì)展現(xiàn)出更高的優(yōu)化能力。

StarRocks中布隆過(guò)濾器：

Bloom Filter（布隆過(guò)濾器），是用于快速地判斷某個(gè)元素是否在一個(gè)集合中的數(shù)據(jù)結(jié)構(gòu)，優(yōu)點(diǎn)是空間效率和時(shí)間效率都很高，缺點(diǎn)是有一定的誤判率。就是說(shuō)，如果布隆過(guò)濾器說(shuō)一個(gè)元素不在集合中，那它確實(shí)不在；但如果說(shuō)一個(gè)元素可能在這個(gè)集合中，這個(gè)結(jié)論也不一定是正確的。

工作原理：布隆過(guò)濾器 由一個(gè) 位數(shù)組（二進(jìn)制向量） 和 一系列哈希函數(shù) 組成。在初始化的階段，所有的位都是0。當(dāng)一個(gè)元素被插入到布隆過(guò)濾器中時(shí)，會(huì)被每一個(gè)哈希函數(shù)處理，每個(gè)哈希函數(shù)都會(huì)產(chǎn)生一個(gè)位數(shù)組的索引，然后相應(yīng)位置的位會(huì)被置為1。這樣，每個(gè)元素的插入都會(huì)在位數(shù)組中留下多個(gè)標(biāo)記。檢查一個(gè)元素是否在集合中的時(shí)候，也是使用同樣的哈希函數(shù)計(jì)算出多個(gè)索引的位置，如果所有這些位置的位都是1，那么可能在集合中，如果任何一位是0，那么就可以確定不在集合中。

（如果布隆過(guò)濾器已經(jīng)判斷出集合中不存在指定的值，就不需要讀取數(shù)據(jù)文件。

   如果布隆過(guò)濾器判斷出集合中包含指定的值，就需要讀取數(shù)據(jù)文件確認(rèn)目標(biāo)值是否存在。

   另外，Bloom Filter索引無(wú)法確定具體是哪一行數(shù)據(jù)具有該指定的值）

在StarRocks中的應(yīng)用：

減少磁盤(pán)I/O：在執(zhí)行查詢時(shí)，布隆過(guò)濾器可以先于實(shí)際數(shù)據(jù)讀取之前被查詢，用于快速排除那些肯定不包含查詢結(jié)果的數(shù)據(jù)塊，從而減少不必要的磁盤(pán)讀取操作，提高查詢效率。

分區(qū)剪枝（partition pruning）：在分布式系統(tǒng)中，布隆過(guò)濾器可以幫助決定是否需要從特定分區(qū)或者節(jié)點(diǎn)中讀取數(shù)據(jù)，實(shí)現(xiàn)查詢的分區(qū)剪枝，減少網(wǎng)絡(luò)傳輸和計(jì)算資源的消耗。

動(dòng)態(tài)調(diào)整：StarRocks的布隆過(guò)濾器支持動(dòng)態(tài)調(diào)整其誤報(bào)率，以適應(yīng)不同查詢場(chǎng)景的需求。通過(guò)調(diào)整哈希函數(shù)的數(shù)量和位數(shù)組的大小，可以在誤報(bào)率和存儲(chǔ)空間之間找到平衡。

通過(guò)在建表的時(shí)候設(shè)定 PROPERTIES("bloom_filter_columns"="event_type,sex");

注意事項(xiàng)：

1.不支持對(duì)Tinyint，F(xiàn)loat，Double類型的列建Bloom Filter索引。

2.Bloom Filter索引只對(duì) 'in' 和 '=' 過(guò)濾查詢有加速效果。

3.如果要查看某個(gè)查詢是否命中了Bloom Filter索引，可以通過(guò)查詢的Profile信息查看（TODO：加上查看Profile的鏈接）。

StarRocks的數(shù)據(jù)導(dǎo)入：

Colocate join：

colocate join可以避免數(shù)據(jù)網(wǎng)絡(luò)傳輸開(kāi)銷，核心思想是將同一個(gè)Colocation Group中表采用一致的分桶鍵，一致的副本數(shù)量和一致副本放置方式。因此如果join列分桶鍵一致，則計(jì)算節(jié)點(diǎn)只需做本地join即可，無(wú)須從其他節(jié)點(diǎn)獲取數(shù)據(jù)，從而規(guī)避網(wǎng)絡(luò)shuffle的過(guò)程。

可以通過(guò)設(shè)置PROPERTIES（"colocate_with" = "group"）,如果colocate：true，那么就是得到了colocate join優(yōu)化，如果colocate：false，那么就是沒(méi)有得到colocate join優(yōu)化（可能會(huì)存在shuffle）。

StarRocks外部表：

到此這篇關(guān)于StarRocks數(shù)據(jù)庫(kù)詳解(什么是StarRocks)的文章就介紹到這了,更多相關(guān)StarRocks詳解內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論