【數(shù)智化案例展】StarRocks × 眾安保險:全新實時分析能力開啟數(shù)字化經(jīng)營新局面
原創(chuàng) StarRocks | 2022-08-03 13:52
【數(shù)據(jù)猿導讀】 StarRocks數(shù)智化案例

StarRocks案例
本項目由StarRocks投遞并參與“數(shù)據(jù)猿行業(yè)盤點季大型主題策劃活動——《2022中國企業(yè)數(shù)智化轉(zhuǎn)型升級創(chuàng)新服務(wù)企業(yè)》榜單/獎項”評選。
在傳統(tǒng)的保險售賣場景中,保險公司主要通過承保利潤和投資收益兩部分獲得盈利,而保險金融的行業(yè)特殊性致使保司對公司整體的數(shù)據(jù)、安全、風控等持有高度敏感性,因此一款保險產(chǎn)品從市場投放到銷售、核保及理賠,每個環(huán)節(jié)都需要嚴格監(jiān)測業(yè)務(wù)走向和數(shù)據(jù)變化。
并且隨著時間的沉淀和業(yè)務(wù)拓展,保司所涉及和積累的相關(guān)數(shù)據(jù)越來越多,其中既包含保司自營的業(yè)務(wù)數(shù)據(jù),也有合作渠道的電商銷售、醫(yī)療健康等數(shù)據(jù)以及第三方的信貸評級、核保風控等數(shù)據(jù)。在日益激烈的市場競爭和技術(shù)變革這兩大背景下,基于大數(shù)據(jù)、人工智能等技術(shù)的商業(yè)模式創(chuàng)新,以及數(shù)字化轉(zhuǎn)型升級已經(jīng)成為保險機構(gòu)的必然選擇。
因此在以上背景下誕生了專門針對保險金融行業(yè)的相關(guān)技術(shù)和產(chǎn)品,通過大數(shù)據(jù)、人工智能等相關(guān)技術(shù)加持,保障保司在每個業(yè)務(wù)環(huán)節(jié)中做到費用可控數(shù)據(jù)可經(jīng)營的目的。常見的例如營銷場景中的渠道投放、用戶觸達、活動監(jiān)控;信貸場景中的授信、支用、還款、防止逆選擇風險等場景。
當然面對保險金融行業(yè)如此大的數(shù)據(jù)量和業(yè)務(wù)復雜度,既有挑戰(zhàn)也有機遇,但需要將這些數(shù)據(jù)進行充分整合并有效利用,才能更好地使其轉(zhuǎn)換為企業(yè)自己的數(shù)據(jù)資產(chǎn),從傳統(tǒng)的運營方式過渡到數(shù)字化在線經(jīng)營。讓數(shù)字反映出真實的運營狀況,及時控制產(chǎn)品風險和調(diào)整策略,以實現(xiàn)保費收入的正向利潤,達到精細化運營。
眾安保險作為一家互聯(lián)網(wǎng)保險公司,海量保單規(guī)模背后離不開科技能力支撐,在“保險+科技”雙輪驅(qū)動下,眾安將自身沉淀的保險科技能力和先進的商業(yè)模式向行業(yè)和海外輸出。催生出數(shù)字化轉(zhuǎn)型中專門針對業(yè)務(wù)數(shù)據(jù)管理和分析的系統(tǒng)產(chǎn)品——集智。
集智是眾安保險的一款可視化智慧經(jīng)營分析平臺產(chǎn)品,集成了人工智能+商業(yè)智能+可視化數(shù)據(jù)倉庫技術(shù),智能整合來自不同場景的數(shù)據(jù),規(guī)范企業(yè)數(shù)據(jù)池,完成繁雜的數(shù)據(jù)治理和智能決策環(huán)節(jié)。
集智秉著“助力企業(yè)實現(xiàn)智慧經(jīng)營”的愿景和“從數(shù)據(jù)到價值,從看見到預(yù)見”的理念,依托豐富的可視化圖表組件以及底層的大數(shù)據(jù)處理能力,實現(xiàn)零代碼拖拽式分析與億級數(shù)據(jù)的秒級響應(yīng),幫助企業(yè)戰(zhàn)略規(guī)劃?員、財務(wù)企劃人員、銷售管理人員、業(yè)務(wù)運營人員及數(shù)據(jù)人員等全面提升信息效率、資源效率及決策效率。
實施時間:
開始時間:2022年1月12日
上線完成:2022年3月29日
業(yè)務(wù)遷移:2022年4月20日
系統(tǒng)集成:2022年5月10日
截止時間:2022年5月30日
客戶的數(shù)智化(數(shù)字化)轉(zhuǎn)型升級需求
目前在眾安保險內(nèi)部,數(shù)字生活、健康險、金融、直營、車險各個業(yè)務(wù)線,以及 HR、運管、風控等中后臺部門,超過3000人都在使用集智平臺,平均日活可達2000+,提升超過50%的數(shù)據(jù)分析效率,降低了公司40%的人力成本。
一款好的數(shù)據(jù)分析產(chǎn)品離不開底層的數(shù)據(jù)引擎,集智平臺的幾大使用場景對底層的數(shù)據(jù)架構(gòu)提出了不同的要求:
可視化分析→需要有豐富的函數(shù)庫支持不同類型圖表的數(shù)據(jù)計算;
交互式分析→需要分析結(jié)果的快速響應(yīng)來保障用戶流暢的分析思路;
多維透視分析→需要大數(shù)據(jù)量的明細數(shù)據(jù)來支撐不同維度的篩選和下鉆;
實時數(shù)據(jù)分析→需要支持數(shù)據(jù)的實時寫入、實時查詢。
針對上述的幾個需求,眾安保險在平臺建設(shè)的初期選用了ClickHouse作為底層統(tǒng)一的OLAP引擎,數(shù)據(jù)鏈路如下:
離線的數(shù)據(jù)會通過DataX統(tǒng)一采集到MaxCompute或Hive數(shù)倉,在離線數(shù)倉內(nèi)部完成數(shù)據(jù)ETL的工作,數(shù)據(jù)加工完成后,再次經(jīng)由DataX輸出到 ClickHouse中,ClickHouse中的數(shù)據(jù)直接提供給看板或者第三方系統(tǒng)做數(shù)據(jù)查詢。
實時的數(shù)據(jù)會通過Binlog監(jiān)聽或者日志采集工具同步到Apache Kafka,再經(jīng)由Apache Flink完成實時的數(shù)據(jù)ETL,最終落到ClickHouse中。值得一提的是,這里為了應(yīng)對一些業(yè)務(wù)場景中數(shù)據(jù)需要實時按主鍵更新需求,眾安保險采用了ClickHouse的Replacing Replicated MergeTree引擎。由于ClickHouse對數(shù)據(jù)更新操作的支持還不夠成熟,因此在使用Replacing引擎的過程中遇到很多問題,這也是眾安保險尋求新的OLAP技術(shù)選型的主要原因。
面臨挑戰(zhàn)
集智上線后采用的是ClickHouse,并且已經(jīng)伴隨業(yè)務(wù)運行了一段時間,但隨著使用平臺的用戶日漸增多,業(yè)務(wù)方需要查詢的數(shù)據(jù)量也越來越大,業(yè)務(wù)場景變得復雜后,很多特定場景ClickHouse無法滿足,面對不同人員角色的需求時也遇到一些瓶頸。同時眾安保險分別從業(yè)務(wù)用戶的角度,以及平臺運維的角度發(fā)現(xiàn)了以下問題:
從用戶角度
一頁分析看板上往往有6-8個圖表,這些圖表的查詢請求都是同時發(fā)給ClickHouse的。但是在多并發(fā)的場景,ClickHouse的查詢性能下降的很快,平時一個1-2s左右的查詢,在8個并發(fā)下就可能把CPU吃滿,平均響應(yīng)時間退化4倍左右,降到8-10s,對看板的首頁加載時間,以及交互分析的體驗影響都比較大;
平臺支持數(shù)據(jù)表的關(guān)聯(lián)查詢,但是ClickHouse的多表關(guān)聯(lián)查詢性能欠佳,涉及Join的查詢往往都需要10s以上,數(shù)據(jù)量大的查詢甚至直接超時無法返回結(jié)果。
從運維角度
ClickHouse不支持事務(wù)性的DDL與DML操作,而且多副本模式的元數(shù)據(jù)管理強依賴于Apache ZooKeeper,表結(jié)構(gòu)變更時常常出現(xiàn)不同副本之間元數(shù)據(jù)不一致的問題,往往定位到最后都是Apache ZooKeeper的原因,排查、運維的成本都比較高;
隨著數(shù)據(jù)量的增多,集群需要擴容時,ClickHouse缺少自動的Resharding機制,橫向擴容時需要借助第三方工具或者手動Reshard,成本比較高。
針對前面提到的實時場景,眾安保險在使用ClickHouse的Replacing引擎中也遇到一些痛點:
查詢慢,Replacing引擎使用的是Merge-On-Read的模式,數(shù)據(jù)寫入時保存多個版本,在查詢時需要指定FINAL關(guān)鍵字進行去重取出最新版本的數(shù)據(jù)。這導致對于Replacing引擎表的查詢,SQL中的謂詞無法下推,同時在低版本的ClickHouse中,對于FINAL語義的查詢也不支持多線程處理,幾乎每次查詢都需要單線程掃描全表數(shù)據(jù),涉及Replacing引擎的查詢響應(yīng)時間往往在10s以上;
Replacing引擎只支持數(shù)據(jù)的更新,并不支持數(shù)據(jù)的刪除。對于Delete操作,當前的做法是通過額外字段來標記當前數(shù)據(jù)是否已經(jīng)被刪除,同時借助TTL 功能來定時清除已經(jīng)被刪除的數(shù)據(jù)。這樣一方面需要額外的定制處理,另一方面新增的標記字段進一步拖慢了查詢的性能;
Replacing引擎只能對同一分片上同一分區(qū)的數(shù)據(jù)去重,這意味著眾安保險在設(shè)計表分區(qū)時,以及寫入數(shù)據(jù)時,都需要做小心的處理,增加了開發(fā)的成本。
上面描述的問題中,有一些涉及ClickHouse底層的缺陷,有一些場景利用ClickHouse提供的其他引擎或者Materialized View等特性可以做一些定制的優(yōu)化,但是掣肘于平臺分析查詢場景的多樣性,眾安保險很難做一些通用性的優(yōu)化。
實時數(shù)倉的場景對OLAP引擎提出了許多挑戰(zhàn),也是之前眾安保險基于ClickHouse架構(gòu)遇到的一大難題場景;
業(yè)務(wù)同學需要根據(jù)實時看板隨時調(diào)整投放策略,要求看板數(shù)據(jù)實時更新,快速響應(yīng);
實時看板的查看頻率比離線看板普遍高出3-5倍,并且查詢結(jié)果無法做緩存處理;
為了聯(lián)合查詢不同主題的數(shù)據(jù),DWS層的寬表之間往往還需要在OLAP層做關(guān)聯(lián)操作;
為了滿足多維分析的需求,落在OLAP層的是明細數(shù)據(jù),數(shù)據(jù)量大;
為了保障數(shù)據(jù)的可維護性與數(shù)據(jù)快速修正的能力,這些明細數(shù)據(jù)需要支持按主鍵更新。
本就不擅長多并發(fā)與多表關(guān)聯(lián)查詢的ClickHouse,再疊上Replacing引擎的 Debuff,導致許多實時的看板常常需要十幾秒才能返回查詢結(jié)果,不能很好地滿足業(yè)務(wù)的需求。同時給集群的CPU負載也造成了不小的壓力,有時會造成集群整體查詢性能的波動。
數(shù)據(jù)支持
眾安保險搭建了包含數(shù)據(jù)倉庫、數(shù)據(jù)工具以及前端支持的成熟的數(shù)據(jù)處理體系,支撐每日上億數(shù)據(jù)量的處理。眾安服務(wù)超過5億用戶,累積出具約427億張保單,平均日新單承保近2000萬,平均日批單量60多萬,平均用戶訪問日志2億多條,用戶訪問請求量每秒30多萬,數(shù)倉日處理任務(wù)2萬多個。這些數(shù)據(jù)既有保單數(shù)據(jù)、埋點數(shù)據(jù),也有來自第三方的數(shù)據(jù),經(jīng)過脫敏、采樣、數(shù)據(jù)訪問控制,在智能資源調(diào)度平臺進行調(diào)度,構(gòu)建從ODS到EDW再到DM的數(shù)據(jù)倉庫分層,形成用戶、保單、理賠、產(chǎn)品、視圖等模型,在DM層形成壽險、意外險、健康險、車險、農(nóng)險、企財險、家財險、信用險、責任險等行業(yè)數(shù)據(jù)模型,依托數(shù)據(jù)管理體系與數(shù)據(jù)流通體系,在保證數(shù)據(jù)質(zhì)量的同時,快速響應(yīng)業(yè)務(wù)需求。
應(yīng)用技術(shù)與實施過程
StarRocks是一款高性能分析型數(shù)據(jù)倉庫,使用向量化、MPP架構(gòu)、可實時更新的列式存儲引擎等技術(shù)實現(xiàn)多維、實時、高并發(fā)的數(shù)據(jù)分析。StarRocks既支持從各類實時和離線的數(shù)據(jù)源高效導入數(shù)據(jù),也支持直接分析數(shù)據(jù)湖上各種格式的數(shù)據(jù)。StarRocks兼容MySQL協(xié)議,可使用MySQL客戶端和常用BI工具對接。同時StarRocks具備水平擴展,高可用,高可靠,易運維等特性。廣泛應(yīng)用于實時數(shù)倉、OLAP報表、數(shù)據(jù)湖分析等場景。
眾安保險通過調(diào)研發(fā)現(xiàn),對于許多遇到的痛點,StarRocks都提供了對應(yīng)的解決方案:
1、支持數(shù)千用戶同時分析,支持高并發(fā),部分場景每秒可支持高達1萬以上的QPS,TP99可控制在1秒以內(nèi);
2、支持Shuffle Join,Colocate Join等多種分布式Join方式,通過CBO優(yōu)化,可以自動選擇性能最優(yōu)的查詢計劃,多表關(guān)聯(lián)性能更優(yōu);
3、支持事務(wù)性的DDL與DML操作,兼容MySQL協(xié)議。StarRocks整體對外暴露的是一個MySQL協(xié)議接口,支持標準SQL語法。用戶通過已有的MySQL客戶端能夠方便地對StarRocks里的數(shù)據(jù)進行查詢和分析;
4、StarRocks的架構(gòu)簡潔,整個系統(tǒng)的核心只有FE(Frontend)、BE(Backend)兩類進程,不依賴任何外部組件,方便部署與維護。同時,F(xiàn)E和BE模塊都可以在線水平擴展,元數(shù)據(jù)和數(shù)據(jù)都有副本機制,確保整個系統(tǒng)無單點;
5、數(shù)據(jù)支持多副本機制并且支持自動均衡,集群隨業(yè)務(wù)增長水平擴展方便,支持在線擴縮容,不影響業(yè)務(wù)使用。
對于實時的場景,StarRocks在1.19版本發(fā)布了Primary Key模型。對比ClickHouse的Replacing引擎與StarRocks自身的UniqueKey模型,Primary Key模型通過在內(nèi)存中維護主鍵索引,支持頻繁實時更新的同時,保證同一個主鍵下僅存在一條記錄,解決了Merge-on-Read方式讀取時在線合并,并且謂詞無法下推和索引失效的問題。通過犧牲微小的寫入性能和內(nèi)存占用提升了查詢的性能,非常符合眾安保險實時數(shù)倉的場景。
調(diào)研之后,眾安保險也對StarRocks和ClickHouse,使用SSB數(shù)據(jù)集做了相應(yīng)的性能對比測試。一共使用到四臺8c32g的機器:StarRocks 1FE/4BE混部,ClickHouse兩分片雙副本。StarRocks使用的版本是2.1.0,ClickHouse使用的版本是21.9.5。測試中為了屏蔽掉系統(tǒng)緩存的影響,對于無并發(fā)的場景,每次查詢前都會通過往drop_cache文件中寫入來清除緩存。
測試的結(jié)果驗證了StarRocks在多并發(fā)與多表關(guān)聯(lián)場景下強悍的性能,同時也發(fā)現(xiàn)了目前StarRocks不足的一些地方:
單表無并發(fā)的場景,除個別SQL外,StarRocks的查詢速度與ClickHouse基本持平,但是StarRocks的CPU負載偏低,是ClickHouse的25%-50%;
單表多并發(fā)的場景,除個別SQL外,StarRocks的平均查詢速度比ClickHouse快1.8倍;
多表關(guān)聯(lián)無并發(fā)的場景,StarRocks平均比ClickHouse快1.8倍;
多表關(guān)聯(lián)多并發(fā)的場景,StarRocks平均比ClickHouse快8倍;
數(shù)據(jù)實時寫入實時查詢的場景,不同的查詢場景下,StarRocks的Primary Key模型查詢速度比ClickHouse的Replacing引擎快3-10倍,且查詢性能較ClickHouse更加穩(wěn)定(Replacing引擎由于后臺不斷地Merge操作,查詢的性能會隨底表數(shù)據(jù)量的起伏對應(yīng)地波動);
數(shù)據(jù)批量導入的場景,眾安保險比較了不同批次大小下的寫入性能,StarRocks的寫入速率平均比ClickHouse要慢20%-30%左右。
基于上述的幾點考慮與測試的結(jié)果,眾安保險決定在平臺的OLAP架構(gòu)中引入StarRocks,并優(yōu)先在實時數(shù)倉的場景落地應(yīng)用。
在集智平臺的實時數(shù)倉里,業(yè)務(wù)庫的Binlog數(shù)據(jù)與日志、事件數(shù)據(jù)會首先經(jīng)由采集工具發(fā)送到Apache Kafka里,中間通過Apache Flink完成初步的數(shù)據(jù)清洗、轉(zhuǎn)換,再次輸出到Apache Kafka作為DWD/DIM層。這一層的數(shù)據(jù)再次經(jīng)過Apache Flink處理,完成數(shù)據(jù)的關(guān)聯(lián)、聚合,最后在DWS層生成不同主題的多維度明細寬表與指標匯總寬表。DWS層的寬表會同時實時同步在OLAP引擎里,通過實時看板提供給業(yè)務(wù)同學查詢。
在上述數(shù)據(jù)流轉(zhuǎn)過程中,借助于StarRocks提供的多種導入與連接方式,可以很好地滿足數(shù)據(jù)寫入與查詢的需求。
(1)數(shù)據(jù)導入層面:
a.存儲在Apache Kafka中的實時數(shù)據(jù),可以通過StarRocks的routine load直接消費Apache Kafka的數(shù)據(jù),不依賴Apache Flink/Apache Spark等流式處理系統(tǒng);
b.存儲在Hadoop或S3中的離線數(shù)據(jù),可以通過StarRocks的broker load等方式,大批量的將數(shù)據(jù)同步拉取到StarRocks中;
c.對于本地數(shù)據(jù)文件,或者存儲在內(nèi)存中的數(shù)據(jù),可以使用基于HTTP協(xié)議的Stream load方式,將數(shù)據(jù)導入到StarRocks中;
d.對于DataX、FlinkX、Apache Seatunnel等數(shù)據(jù)同步工具,StarRocks也開發(fā)了一些插件,可以通過這些同步工具,將其他數(shù)據(jù)源的數(shù)據(jù),批量通過到StarRocks中。
(2)流式系統(tǒng)兼容
a.StarRocks開發(fā)了Flink-connector插件,支持Apache Flink將數(shù)據(jù)sink到StarRocks中;
b.StarRocks有spark-connector,Apache Spark可以批量讀取寫入StarRocks的數(shù)據(jù);
(3)StarRocks還支持MySQL、ElasticSearch、Apache Hive等系統(tǒng)的聯(lián)邦查詢,StarRocks遠程讀取這些系統(tǒng)中的數(shù)據(jù),在內(nèi)部再進行Join等內(nèi)部處理操作;
(4)StarRocks的查詢接口兼容MySQL協(xié)議,使用MySQL Connector就可以對接查詢StarRocks,因此上層各類BI應(yīng)用,只要能對接MySQL,基本就可以對接StarRocks。
眾安保險使用 StarRocks的Primary Key模型來替換ClickHouse的Replacing 引擎,針對線上的實時看板,眾安保險模擬了真實的場景,選取了一個4張寬表關(guān)聯(lián)的復雜查詢,對兩種不同的引擎做了對比測試,結(jié)果如下:
從結(jié)果中可以看到,在沒有并發(fā)的場景下,StarRocks的查詢速度是ClickHouse的2倍左右,在多并發(fā)的場景下,StarRocks的查詢速度是ClickHouse的3-3.5倍左右。
除了查詢性能提升之外,Primary Key模型也可以支持數(shù)據(jù)的刪除,并且不用數(shù)據(jù)開發(fā)額外地維護分片與分區(qū)的寫入規(guī)則,降低了數(shù)據(jù)開發(fā)的成本。
從以上的調(diào)研和測試結(jié)果來看,StarRocks的單表查詢性能和ClickHouse不相上下,在多并發(fā)與多表關(guān)聯(lián)查詢的場景下性能明顯優(yōu)于ClickHouse,特別是針對實時數(shù)倉的高頻更新場景,StarRocks的Primary Key模型能很好地解決ClickHouse的Replacing引擎遇到的一些痛點。此外,StarRocks DDL/DML和數(shù)據(jù)導入具備事務(wù)保證,兼容MySQL協(xié)議,集群相對ClickHouse也更容易運維,對于研運同學來說更加友好。
基于上述方案,眾安保險在集智平臺引入StarRocks,支撐理賠風險洞察、精細化運營分析、營銷實時效果追蹤等方面的應(yīng)用,賦能戰(zhàn)略決策人員、財務(wù)企劃人員、營銷管理人員、數(shù)據(jù)運營人員、數(shù)據(jù)分析人員。
為了提升集智在查詢加載方面的性能,同時將StarRocks極速查詢及高并發(fā)相關(guān)能力更好地賦能給業(yè)務(wù)同學,集智在產(chǎn)品側(cè)深度集成了StarRocks,用戶可以在平臺上快速完成一站式的實時看板搭建。
在集智平臺中,搭建一個分析看板前需要先創(chuàng)建數(shù)據(jù)模型,當數(shù)據(jù)開發(fā)同學面對業(yè)務(wù)方較為復雜或查詢量較大的分析需求時,可在創(chuàng)建數(shù)據(jù)模型時選擇StarRocks的優(yōu)化方式,除了基礎(chǔ)的索引字段、數(shù)據(jù)分布字段以及時間分區(qū)等字段外,還可選擇對應(yīng)的模型引擎以及填寫數(shù)據(jù)保留的時長。
實時模型創(chuàng)建成功后,用戶可以在模型的詳情頁拿到對應(yīng)的StarRocks表連接信息,以及自動生成的Flink SQL Sink語句。
之后,用戶可以在平臺的數(shù)據(jù)ETL模塊新建一個實時Apache Flink任務(wù),往對應(yīng)的實時模型中寫入數(shù)據(jù)。
數(shù)據(jù)寫入模型之后,用戶就可以在搭建看板時使用了,可以在模型上做一些字段的數(shù)據(jù)格式調(diào)整、字段編輯、基于原始字段新增復合字段等操作,以及圖表樣式的調(diào)整,滿足業(yè)務(wù)方不同場景下的業(yè)務(wù)口徑與展示需求。
看板搭建完成后可以進行發(fā)布操作生成一個固定鏈接,就可以提供給業(yè)務(wù)同學使用。
商業(yè)變化
眾安保險集智平臺通過引入StarRocks解決了極速查詢和高并發(fā)等數(shù)據(jù)問題,提升了集智平臺整體的數(shù)據(jù)支持能力和市場競爭力,全面升級數(shù)字化經(jīng)營能力。
以保險產(chǎn)品中線上渠道投放場景為例,當保險產(chǎn)品開始對外發(fā)售前后,市場人員會將產(chǎn)品投放到多個渠道進行推廣曝光,通過經(jīng)營的核心報表實時核算每個渠道的投放成本以及其對應(yīng)的ROI,根據(jù)數(shù)據(jù)表現(xiàn)情況實時調(diào)整投放策略,控制渠道營銷流程中的獲客單價和投放費用。
因此數(shù)據(jù)反饋的快慢也會決定業(yè)務(wù)人員在定位問題、調(diào)整策略等事件上是否占據(jù)最佳時機。
而集智使用StarRocks的模型作為實時報表的底層數(shù)據(jù)支撐后,在業(yè)務(wù)場景中的數(shù)據(jù)查詢表現(xiàn)會怎么樣,以下為真實場景測試結(jié)果:
(1)在報表數(shù)據(jù)加載速度方面:過去業(yè)務(wù)方打開報表需要加載10s+,常常因為打開速度過慢致使業(yè)務(wù)偶爾在關(guān)鍵節(jié)點上無法及時得到事故反饋,導致投放成本難以控制,嚴重影響后續(xù)的投放策略;
而使用StarRocks后加載速度只需3s左右,這樣的響應(yīng)速度讓業(yè)務(wù)同學可以很快抓準業(yè)務(wù)實時的變動節(jié)點,及時對活動策略做出調(diào)整優(yōu)化。
(2)在查詢數(shù)據(jù)量支持方面:過去使用ClickHouse的實時更新模型只能支持較為有限的數(shù)據(jù)量,更大數(shù)據(jù)量的實時更新+查詢常常超時,嚴重影響業(yè)務(wù)進展,也會因此錯過一些關(guān)鍵時機;
而使用StarRocks后可支持近億級數(shù)據(jù)量,能夠適配更多大數(shù)據(jù)量下的業(yè)務(wù)場景,同時也能更好地維持業(yè)務(wù)穩(wěn)定性,增加了業(yè)務(wù)同學對平臺的信任和粘性,大大地提高了生產(chǎn)效率。
關(guān)于企業(yè)
·StarRocks
StarRocks創(chuàng)立兩年多來,一直專注打造世界級的新一代極速全場景MPP數(shù)據(jù)庫,幫助企業(yè)建立“極速統(tǒng)一”的數(shù)據(jù)分析新范式,助力企業(yè)全面數(shù)字化經(jīng)營。
當前已經(jīng)幫助騰訊、攜程、順豐、Airbnb 、滴滴、京東、眾安保險等超過 110 家大型用戶構(gòu)建了全新的數(shù)據(jù)分析能力,生產(chǎn)環(huán)境中穩(wěn)定運行的StarRocks服務(wù)器數(shù)目達數(shù)千臺。
2021 年 9 月,StarRocks源代碼開放,在Github上的星數(shù)已超過3000個。StarRocks的全球社區(qū)飛速成長,至今已有超百位貢獻者,社群用戶突破5000人,吸引幾十家國內(nèi)外行業(yè)頭部企業(yè)參與共建。
·眾安保險
眾安保險作為一家互聯(lián)網(wǎng)保險公司,秉持“科技驅(qū)動金融,做有溫度的保險”的使命,從用戶的互聯(lián)網(wǎng)生活切入,滿足用戶多元化的保障需求,為用戶創(chuàng)造價值。區(qū)別于傳統(tǒng)保險公司的運營模式,眾安保險業(yè)務(wù)流程全程在線,不設(shè)任何分支機構(gòu),通過互聯(lián)?進?承保和理賠服務(wù)。
眾安在線財產(chǎn)保險股份有限公司(以下簡稱“眾安”)是中國首家互聯(lián)網(wǎng)保險公司,于2013年11月6日揭牌開業(yè),2017年9月28日在香港聯(lián)交所主板上市,股票代碼為6060。
眾安總部位于上海,不設(shè)任何分支機構(gòu),完全通過互聯(lián)網(wǎng)展業(yè)。由“保險+科技”雙引擎驅(qū)動,眾安專注于應(yīng)用新技術(shù)重塑保險價值鏈,圍繞健康、數(shù)字生活、消費金融、汽車四大生態(tài),以科技服務(wù)新生代,為其提供個性化、定制化、智能化的新保險。
網(wǎng)上保險買眾安,5億用戶的選擇。截至2021年底,眾安服務(wù)超過5億用戶,累計出具約427億張保單。
在科技賦能保險的同時,眾安將經(jīng)過業(yè)務(wù)驗證的科技對外輸出。2016年11月,眾安成立全資子公司眾安信息技術(shù)服務(wù)有限公司(以下簡稱“眾安科技”),將技術(shù)方案產(chǎn)品化,向海內(nèi)外市場輸出科技產(chǎn)品和行業(yè)解決方案。截至2021年底,眾安的科技輸出累計服務(wù)企業(yè)客戶數(shù)超過600家,海外合作伙伴包括日本財產(chǎn)保險公司SOMPO、東南亞領(lǐng)先的O2O平臺Grab、新加坡綜合保險機構(gòu)Income等知名企業(yè)。
以“科技驅(qū)動金融 做有溫度的保險”為使命,秉承“簡單、快速、突破、共贏”的價值觀,眾安將繼續(xù)乘風破浪,砥礪前行,開啟真正的新保險時代。
來源:StarRocks