StarRocks介紹

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

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

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

什么是StarRocks？

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

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

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

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

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

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

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

StarRocks適合什么場景？

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

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

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

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

StarRocks基本概念：

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

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

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

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

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

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

FE：

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

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

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

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

5.FE中的Planner負責把邏輯計劃轉(zhuǎn)化為可分布式執(zhí)行的物理計劃，分發(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時table經(jīng)過分區(qū)分桶形成的子表，采用列式存儲。

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

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

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

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

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

StarRocks為什么快：

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

稀疏索引：當進行范圍查詢時，StarRocks能夠快速定位到起始目標行，是因為shortkey index（稀疏索引）。

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

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

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

StarRocks的4種表模型：

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

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

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

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

各自適用場景：

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

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

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

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

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

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

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

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

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

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

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

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

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

StarRocks排序列：

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

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

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

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

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

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

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

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

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

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

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

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

在基于維度進行分析的時候，需要使用物化視圖。

StarRocks中Bitmap索引：

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

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

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

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

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

StarRocks中布隆過濾器：

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

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

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

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

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

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

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

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

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

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

注意事項：

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

2.Bloom Filter索引只對 'in' 和 '=' 過濾查詢有加速效果。

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

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

Colocate join：

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

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

StarRocks外部表：

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

最新評論