chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

　　導(dǎo)讀：本次從工程的角度分享一下多維分析平臺在37手游的技術(shù)演進(jìn)。本次分享分為以下四個模塊：

　　37手游業(yè)務(wù)背景37手游多維分析的實(shí)踐多維分析技術(shù)的業(yè)務(wù)化和普惠化多維分析平臺服務(wù)保障--

　　01

　　37手游業(yè)務(wù)背景

　　首先介紹一下業(yè)務(wù)背景。

　　1. 37手游簡介

　　37手游是一家游戲發(fā)行公司，累計運(yùn)營的游戲大概有 2000 多款，月活用戶在3000萬左右。37手游數(shù)據(jù)需求場景特點(diǎn)，和很多公司都有共性，但本身業(yè)務(wù)的特殊性也導(dǎo)致了跟其他公司在技術(shù)選型上有差異。

　　發(fā)行的不同游戲可能對應(yīng)不同游戲研發(fā)商，數(shù)據(jù)來源多樣且復(fù)雜，數(shù)據(jù)格式多樣；廣告投放對接眾多外部媒體，不同媒體數(shù)據(jù)格式、數(shù)據(jù)時效、數(shù)據(jù)對接方式差異很大。2.37手游數(shù)據(jù)分析場景特點(diǎn)

　　37手游數(shù)據(jù)分析的業(yè)務(wù)場景有如下特點(diǎn)和挑戰(zhàn)。

　　第一個特點(diǎn)是時效新：比如在廣告投放的過程中，需要對廣告投放消耗數(shù)據(jù)進(jìn)行實(shí)時追蹤，以及廣告投放消耗之后的效果數(shù)據(jù)進(jìn)行實(shí)時分析；還有游戲運(yùn)營內(nèi)部的實(shí)時分析，比如進(jìn)行了某個活動投放，運(yùn)營人員需要實(shí)時知道某個投放活動的效果怎么樣。

　　第二個特點(diǎn)是維度多：廣告投放很多時候要精細(xì)到特別細(xì)的一些維度，不僅有非常多的廣告計劃，還有非常多的廣告創(chuàng)意，并且同一個廣告計劃里面可能會有不同的圖片，不同素材，按照游戲包+廣告投放渠道+廣告投放計劃+廣告投放素材維度排列組合后就會存在一個維度爆炸的問題；另外一個點(diǎn)是歷史快照數(shù)據(jù)更新問題，比如某個廣告投放計劃原來在某個投手下面，后來變更到另外一個投手下面，從廣告追蹤的角度來講，需要回溯歷史數(shù)據(jù)，也就是說現(xiàn)在的一些效果數(shù)據(jù)(如游戲充值付費(fèi))應(yīng)該歸因到新的投手下面時，就會存在歷史數(shù)據(jù)維度更新的問題。

　　第三個特點(diǎn)是大數(shù)據(jù)量：比如基于用戶ID+游戲包維度+廣告投放維度進(jìn)行精準(zhǔn)去重，根據(jù)用戶的行為數(shù)據(jù)，登錄充值等，需要?dú)w因到是哪個廣告或者素材帶來的，就會涉及到大量的關(guān)聯(lián)操作和去重操作，計算量很大；如果此時查詢并發(fā)比較高，那整個集群就很容易出現(xiàn)資源上的瓶頸，導(dǎo)致系統(tǒng)變慢，影響整個業(yè)務(wù)查詢體驗(yàn)。

　　--

　　02

　　37手游多維分析實(shí)踐

　　1. OLAP在37手游的演進(jìn)

　　37手游多維分析的架構(gòu)選型是跟隨公司的業(yè)務(wù)發(fā)展特點(diǎn)進(jìn)行演進(jìn)的，為了保證系統(tǒng)性能和SLA，新的業(yè)務(wù)場景要求引入新的組件來解決特定業(yè)務(wù)場景問題。在架構(gòu)演進(jìn)過程中，主要從計算能力、查詢性能、架構(gòu)簡潔性、可擴(kuò)展性、穩(wěn)定性、可維護(hù)性等維度考慮架構(gòu)和組件的選型。

　　2018年以前，當(dāng)時業(yè)務(wù)的數(shù)據(jù)量相對比較少，很多業(yè)務(wù)場景是報表查詢，此時只需在數(shù)倉的建模后，將ADS層的數(shù)據(jù)推送到MySQL中即可，因?yàn)閿?shù)據(jù)本身聚合之后數(shù)據(jù)量也不大，MySQL夠用。隨著業(yè)務(wù)的精細(xì)化運(yùn)營以及數(shù)據(jù)量增加，MySQL就逐漸頂不住了，另外用戶的行為數(shù)據(jù)分析，無法用MySQL支撐，因此引入了Druid來應(yīng)對用戶行為分析的場景。

　　2019年之后，有些業(yè)務(wù)場景的數(shù)據(jù)分析采用了Impala，后面會詳細(xì)講解。

　　2020年之后，之前的架構(gòu)無法支撐業(yè)務(wù)發(fā)展，就引入了Clickhouse，從最開始單機(jī)Clickhouse到ClickHouse集群，主要應(yīng)用在報表查詢和自動投放等業(yè)務(wù)場景。

　　在2021年到2022年期間，引入了一些第三方商業(yè)化的工具，包括公有云廠商的一些組件，阿里云ADB、Hologress等，還有最近一兩年熱門的StarRocks等，用于針對性地解決某些特定業(yè)務(wù)場景問題。

　　2. OLAP平臺與數(shù)倉

　　提到多維分析和OLAP，就不得不提數(shù)據(jù)倉庫。通常經(jīng)過ODS到DWD，再到DWS，再到ADS層數(shù)據(jù)建模，經(jīng)過一系列ETL操作，最終ADS層數(shù)據(jù)推送到OLAP查詢層，供應(yīng)用層查詢。

　　下圖就是37手游的數(shù)據(jù)倉庫的總體架構(gòu)圖，數(shù)據(jù)從業(yè)務(wù)庫MySQL和業(yè)務(wù)日志進(jìn)來，經(jīng)過中間的實(shí)時/離線數(shù)據(jù)倉庫ETL 數(shù)據(jù)加工后，最終ADS層數(shù)據(jù)被推到混合OLAP查詢平臺，供業(yè)務(wù)查詢。中間的數(shù)倉架構(gòu)采用了Flink引擎，整體滿足湖倉一體，流批一體的數(shù)倉架構(gòu)設(shè)計思路。實(shí)時數(shù)倉使用Kafka作為存儲層，實(shí)時數(shù)倉DW層會落一份數(shù)據(jù)到Hudi供數(shù)據(jù)分析使用。構(gòu)建邏輯視圖統(tǒng)一實(shí)時數(shù)倉數(shù)據(jù)表(kafka)和離線數(shù)倉表hudi（hive外部表）。通過統(tǒng)一邏輯視圖，做到數(shù)倉流批一體存儲層面的邏輯統(tǒng)一。其中混合OLAP查詢平臺，針對不同的業(yè)務(wù)場景，封裝了不同的組件，不同的業(yè)務(wù)查詢請求流量通過路由分發(fā)到不同的OLAP的查詢引擎上。

　　3. Impala讀寫流程

　　Impala是37手游用來做自助式數(shù)據(jù)提取的計算引擎，下面簡單介紹一下Impala的原理和讀寫流程。Impala主要包含三個組件：Catalog，StateStore，和ImpalaDaemon；Catalog把元數(shù)據(jù)分發(fā)到各個ImpalaDaemon；StateStore收集各個ImpalaDaemon的信息，如進(jìn)程信息，各個節(jié)點(diǎn)的健康信息等，同時StateStore還負(fù)責(zé)請求調(diào)度；ImpalaDaemon對本地數(shù)據(jù)進(jìn)行運(yùn)算后，協(xié)同其他的一些ImpalaDaemon進(jìn)行運(yùn)算，最終把結(jié)果返回給客戶端。

　　上圖是Impala的讀寫流程，首先客戶端提交一個請求后，會對應(yīng)產(chǎn)生一個Impala請求進(jìn)程，該Impala請求進(jìn)程會向StateStore提交一個注冊信息，StateStore就會同時產(chǎn)生一個StateStore存儲進(jìn)程來創(chuàng)建多個線程來處理Impala請求進(jìn)程的注冊信息；接下來根據(jù)用戶輸入的SQL語句，經(jīng)過Impala服務(wù)的三個模塊：Query Planner、Query Coordinator和Query Executor的詞法、語法解析后，拆成各個子任務(wù)，然后分發(fā)到各個ImpalaDaemon中去執(zhí)行；各個ImpalaDaemon運(yùn)算后的結(jié)果返回給協(xié)調(diào)器，協(xié)調(diào)器進(jìn)行匯總，最后將結(jié)果返回給客戶端。

　　以上就是Impala的一個簡單讀寫流程。

　　4. Impala在自助取數(shù)平臺的應(yīng)用

　　介紹一下Impala在37手游的自助取數(shù)平臺的應(yīng)用。

　　業(yè)務(wù)團(tuán)隊經(jīng)常會有各種各樣的取數(shù)需求，取數(shù)需求會占用數(shù)據(jù)開發(fā)人員的不少精力。從收到業(yè)務(wù)團(tuán)隊的取數(shù)需求，到開發(fā)人員編寫SQL到跑代碼獲取數(shù)據(jù)返回給業(yè)務(wù)需求方，經(jīng)常會遭受業(yè)務(wù)團(tuán)隊的吐槽和催促：為啥取個數(shù)據(jù)要這么久。

　　為了提高日常業(yè)務(wù)團(tuán)隊取數(shù)類需求的交互效率，37手游構(gòu)建了自助取數(shù)平臺。

　　用戶首先在自助取數(shù)平臺上篩選維度、選擇指標(biāo)和統(tǒng)計口徑。自助取數(shù)平臺根據(jù)用戶選擇的這些條件進(jìn)行解析，生成代碼和任務(wù)，自助取數(shù)平臺調(diào)度執(zhí)行任務(wù)，其中SQL代碼發(fā)送到Impala集群執(zhí)行。任務(wù)執(zhí)行成功后生成文件供用戶下載。對于業(yè)務(wù)團(tuán)隊來講，只需在自助平臺上做一些選擇，等待取數(shù)任務(wù)調(diào)度執(zhí)行，之后下載獲取數(shù)據(jù)，非常方便和快捷；對于數(shù)據(jù)開發(fā)團(tuán)隊來講，減少了80%以上的取數(shù)需求，可以從SQL Boy的低效工作中解放出來，極大解放了生產(chǎn)力，從而釋放出精力做更高價值的事情。

　　5. Impala的優(yōu)點(diǎn)

　　自助取數(shù)分析平臺的技術(shù)底座就是基于Impala的。為什么會選擇Impala？首先Impala是MPP架構(gòu)的，能夠處理比較大的數(shù)據(jù)操作，而且是無狀態(tài)的，節(jié)點(diǎn)掛掉后只需重啟；其次是Impala兼容Hive存儲，能復(fù)用Hadoop體系的存儲能力，能避免像GP一樣自成一套技術(shù)體系和資源體系；第三個點(diǎn)是Impala的高效查詢性能，支持CBO、并行計算等，Impala的data location的IO協(xié)調(diào)機(jī)制是計算和數(shù)據(jù)盡可能在一個節(jié)點(diǎn)，減少網(wǎng)絡(luò)開銷，尤其在大數(shù)據(jù)場景下，非常節(jié)省網(wǎng)絡(luò)資源；Impala的算子下推的特性能夠保證非常高效的查詢性能；最后一個點(diǎn)是Impala社區(qū)活躍度高，因?yàn)楸容^冷門的組件社區(qū)活躍度不高，在技術(shù)選型上會來帶來一些不可控的風(fēng)險。

　　6. Impala的不足

　　在使用Impala的過程中，也發(fā)現(xiàn)了Impala的不足。

　　首先是單點(diǎn)問題，即Catalog和StateStored單點(diǎn)問題，雖然Catalog單點(diǎn)掛掉之后，對正在進(jìn)行中的查詢影響并不是很大，但可能拉取不到最新的元數(shù)據(jù)。

　　第二個是資源隔離的問題，資源隔離不精確，并且資源不能通過YARN統(tǒng)一資源管理調(diào)度，無法實(shí)現(xiàn)Impala、Spark、Hive等組件的動態(tài)資源共享。

　　第三個是元數(shù)據(jù)更新問題，無法感知HDFS操作，每當(dāng)新的記錄/文件被添加到HDFS中的數(shù)據(jù)目錄時，需要手動去刷新元數(shù)據(jù)。第四個比較重要的點(diǎn)是Impala基于內(nèi)存計算，速度很快，但存在風(fēng)險就是內(nèi)存會溢出，內(nèi)存溢出就導(dǎo)致任務(wù)掛掉。另外Impala的并發(fā)能力比較有限，QPS稍高一點(diǎn)，查詢性能下降明顯。

　　7. ClickHouse為什么快

　　2019年后，37手游開始引入ClickHouse。當(dāng)時ClickHouse是一個比較現(xiàn)象級的產(chǎn)品，非?？臁槭裁碈lickHouse會這么快？

　　ClickHouse實(shí)現(xiàn)了單機(jī)多核并行，還支持分布式計算，支持SIMD指令等，能榨干機(jī)器的性能，從而提升查詢速度；ClickHouse支持多樣化的表引擎，包括MergeTree等20多種表引擎，基于不同的業(yè)務(wù)場景選擇不同的表引擎，可以帶來性能上的提升；ClickHouse的索引機(jī)制包括主鍵索引，稀疏索引，能夠提升查詢性能；ClickHouse的向量化引擎能夠在多數(shù)據(jù)流時，為上層應(yīng)用的性能帶來極大提升；ClickHouse是列式存儲，自帶數(shù)據(jù)壓縮，列式存儲更適合OLAP場景，再加上自帶的數(shù)據(jù)壓縮的處理速度，能做到百倍級別的性能提升；ClickHouse支持多核并行處理，單條SQL的執(zhí)行會盡可能地利用更多的CPU核數(shù)，榨干CPU的資源來提升執(zhí)行效率；ClickHouse還支持多服務(wù)的并行處理數(shù)據(jù)，數(shù)據(jù)保存在不同的節(jié)點(diǎn)不同shard上，查詢可以并行地在所有shard上進(jìn)行處理。8. ClickHouse在廣告自動化投放平臺的應(yīng)用

　　37手游將ClickHouse應(yīng)用在廣告自動化投放平臺來做查詢的加速。37手游的廣告投放平臺需要對媒體廣告投放效果進(jìn)行實(shí)時監(jiān)控（比如在頭條或騰訊的媒體上投放廣告），廣告投放之后就有廣告費(fèi)用消耗，同時也會拉來一些用戶注冊（即對應(yīng)的廣告效果），根據(jù)廣告效果來調(diào)整自動化投放策略。未引入ClickHouse之前，面臨著兩個技術(shù)挑戰(zhàn)：

　?。?）業(yè)務(wù)數(shù)據(jù)的更新頻率非常高，因?yàn)槊襟w廣告投放時，投放資源時刻在消耗，需要實(shí)時拉取。

　　（2）多表關(guān)聯(lián)的問題：廣告投放資源的消耗需要關(guān)聯(lián)上效果數(shù)據(jù)，還要關(guān)聯(lián)各種各樣的廣告數(shù)據(jù)，多表關(guān)聯(lián)的效率就會比較低。

　　針對這些問題使用了ReplicatedMergeTree表引擎。

　　對于多表關(guān)聯(lián)，根據(jù)相同的join key，哈希到同一個節(jié)點(diǎn)，以實(shí)現(xiàn)local join，以減少計算時數(shù)據(jù)做shuffle時的消耗；對于頻繁更新的問題，將業(yè)務(wù)業(yè)務(wù)庫MySQL的數(shù)據(jù)同步到ClickHouse，將Mysql的update/delete/+insert的方式變成clickhouse insert(append)，構(gòu)建歷史數(shù)據(jù)和新增數(shù)據(jù)的視圖，進(jìn)行優(yōu)化合并操作，因?yàn)闅v史數(shù)據(jù)不會發(fā)生變化，相對比較好處理；對于T-1或T的新增數(shù)據(jù)，只有一天的數(shù)據(jù)，數(shù)據(jù)量比較小，在進(jìn)行更新操作時，取最近一條數(shù)據(jù)，然后兩份數(shù)據(jù)合起來，我們曾考慮過用默認(rèn)的replace來進(jìn)行表更新，通過ClickHouse本身的一些機(jī)制來做數(shù)據(jù)合并，但因?yàn)闃I(yè)務(wù)數(shù)據(jù)插入的頻率高，數(shù)據(jù)量大，ClickHouse數(shù)據(jù)合并是異步的，容易出現(xiàn)Merge不過來的現(xiàn)象。當(dāng)然可以通過一些手段優(yōu)化，比如optimize、final進(jìn)行強(qiáng)制合并，但因?yàn)閛ptimize不是一個常規(guī)操作，不能太頻繁；在查詢時，使用final來做合并，會影響查詢性能，特別是在ClickHouse的早期版本，是單線程的，性能也不行。因此最終采用了ReplicatedMerge表引擎配合視圖的方式。

　　9. ClickHouse使用心得

　　在使用ClickHouse過程中有一些心得。

　　第一個根據(jù)應(yīng)用場景合理選擇ClickHouse，避免“讓舉重運(yùn)動員參加長跑比賽”(避免讓clickhouse干它不擅長干的事情)，應(yīng)多做短查詢，避免大數(shù)據(jù)量的合并或頻繁更新；數(shù)倉中的數(shù)據(jù)最好構(gòu)建大寬表，預(yù)聚合之后再寫入，并且是批量寫入Clickhouse。

　　第二個是建表和索引的優(yōu)化。

　　第三個是查詢SQL優(yōu)化，SQL優(yōu)化的很多策略，無論是列裁剪與分區(qū)裁剪，歸根結(jié)底就是減少查詢時的IO，減少網(wǎng)絡(luò)傳輸?shù)某杀?；如果業(yè)務(wù)上能接受，可以采用數(shù)據(jù)采樣，或者使用simple、limit、uniqCombined等方式做近似計算來提升性能。

　　第四個是調(diào)整系統(tǒng)參數(shù)，比如單次查詢的最大執(zhí)行時間max_execution_time，如果執(zhí)行某SQL時超過這個時間，在業(yè)務(wù)上就可能認(rèn)為該SQL是有問題的，可以做降級操作，停掉該任務(wù)；還有單個服務(wù)器單次查詢的最大內(nèi)存max_memory_usage、單個服務(wù)器所有查詢的最大內(nèi)存

　　max_memory_usage_for_all_queries、合并線程量等參數(shù)，需要在具體的業(yè)務(wù)運(yùn)行過程中來調(diào)整這些參數(shù)，來使ClickHouse達(dá)到最優(yōu)性能。

　　10. ClickHouse使用痛點(diǎn)

　　在使用ClickHouse過程中，痛點(diǎn)也非常清晰。

　　從查詢性能角度看，ClickHouse的高并發(fā)能力不足，多表關(guān)聯(lián)查詢性能欠佳。從運(yùn)維角度看，ClickHouse集群強(qiáng)依賴ZooKeeper，增加了運(yùn)維復(fù)雜度；ClickHouse集群缺乏Resharding機(jī)制，集群擴(kuò)容節(jié)點(diǎn)比較麻煩。從數(shù)據(jù)更新角度看，數(shù)據(jù)Replacing使用merge-on-read模式，類似MOR的表模式，當(dāng)多個數(shù)據(jù)版本存在時，不管是直接取數(shù)還是合并后取數(shù)，要取最新的一條數(shù)據(jù)，容易存在性能問題；另外ClickHouse不支持刪除數(shù)據(jù)，需要通過表引擎增加刪除標(biāo)識位或TTL來變相實(shí)現(xiàn)數(shù)據(jù)刪除的操作，這樣就會拖慢性能。

　　11. StarRocks的重要特征

　　基于37手游的業(yè)務(wù)特點(diǎn)和ClickHouse的使用情況，2022年開始調(diào)研StarRocks，StarRocks的特性和37手游的業(yè)務(wù)場景匹配度非常高，下面簡單介紹一下StarRocks的一些重要特性。

　　StarRocks目前有四種數(shù)據(jù)模型：明細(xì)模型、聚合模型、更新模型和主鍵模型，根據(jù)不同的業(yè)務(wù)場景使用不同的數(shù)據(jù)模型，可以提升查詢性能。

　　37手游業(yè)務(wù)中使用較多的是主鍵模型。主鍵模型其實(shí)和更新模型比較相似，要求每個表要有唯一的主鍵，支持按主鍵進(jìn)行更新和刪除操作，通過犧牲數(shù)據(jù)寫入操作的部分內(nèi)存，能夠極大地提升查詢性能。通過各種測試，StarRocks支持多并發(fā)查詢，并且QPS能力比ClickHouse要好。StarRocks支持多種數(shù)據(jù)導(dǎo)入方式，簡化了數(shù)據(jù)加工鏈路。另外StarRocks不依賴ZooKeeper等外部組件，只有自身的FE、BE模塊，降低了運(yùn)維管理難度。

　　12.StarRocks在37手游畫像場景的應(yīng)用

　　37手游用戶畫像場景有四個技術(shù)訴求。第一，支持大數(shù)據(jù)量的查詢；第二，數(shù)據(jù)的時效性要強(qiáng)；第三，可以根據(jù)任意的規(guī)則去圈選用戶，再去做一些畫像操作，比如聚合操作；第四，是要支持多表關(guān)聯(lián)，比如畫像表和用戶維度表關(guān)聯(lián)。其中前面的第三、第四點(diǎn)是我們的強(qiáng)需求項(xiàng)。

　　13.37手游畫像StarRocks方案

　　過去37手游的用戶畫像使用的是ES，但ES的成本比較高，并發(fā)能力也比不上StarRocks+Hbase的方案，并且ES有時會出現(xiàn)讀寫超時(業(yè)務(wù)上讀寫時延有要求)，因此換成了現(xiàn)在StarRocks+Hbase的方案，過去的痛點(diǎn)都解決了。在StarRocks方案中，用戶畫像表使用了寬表+眾表的數(shù)據(jù)設(shè)計方案，對應(yīng)的表模式是主鍵模型+聚合模型來處理寬表和眾表；通過使用StarRocks的to_bitmap將user_id轉(zhuǎn)化為Bitmap類型后，后續(xù)通過Bitmap運(yùn)算支持人群圈選等需求，性能相當(dāng)高。

　　--

　　03

　　37手游多維分析技術(shù)業(yè)務(wù)化和普惠化

　　1.數(shù)據(jù)分析與決策存在痛點(diǎn)

　　做數(shù)據(jù)開發(fā)的工作會經(jīng)常遇到以下的痛點(diǎn)。

　　數(shù)據(jù)開發(fā)團(tuán)隊如果整天就只開發(fā)報表或者寫SQL取數(shù)，數(shù)據(jù)開發(fā)人員容易淪為：“表哥”，“表姐”（只開發(fā)報表）或者SQL Boy（只寫SQL）,這樣數(shù)據(jù)開發(fā)人員可能自我感覺業(yè)務(wù)價值存在感偏低；從業(yè)務(wù)團(tuán)隊的角度來講，大量的取數(shù)需求要提給數(shù)據(jù)開發(fā)團(tuán)隊，并且希望取數(shù)需求盡快完成交付以便及時進(jìn)行數(shù)據(jù)分析和業(yè)務(wù)決策，但實(shí)際情況是業(yè)務(wù)團(tuán)隊會覺得數(shù)據(jù)開發(fā)團(tuán)隊實(shí)現(xiàn)一張數(shù)據(jù)報表需求工時好長，取數(shù)難，取數(shù)慢，效率低。

　　2. 多維分析技術(shù)業(yè)務(wù)化與普惠化

　　針對以上痛點(diǎn)，37手游的數(shù)據(jù)開發(fā)團(tuán)隊采用的策略是：

　　基于多維分析技術(shù)，把多維分析技術(shù)進(jìn)行業(yè)務(wù)化和普惠化，構(gòu)建了數(shù)據(jù)自助分析平臺提供給業(yè)務(wù)側(cè)進(jìn)行數(shù)據(jù)分析和賦能業(yè)務(wù)決策。數(shù)據(jù)開發(fā)人員只要準(zhǔn)備好數(shù)據(jù)集搭建數(shù)據(jù)看板，甚至可以將數(shù)據(jù)看板搭建交由業(yè)務(wù)團(tuán)隊自己實(shí)現(xiàn)，數(shù)據(jù)開發(fā)人員準(zhǔn)備好數(shù)據(jù)集即可，如下圖所示，右邊是數(shù)據(jù)開發(fā)人員準(zhǔn)備好數(shù)據(jù)集，左邊的數(shù)據(jù)圖表可以由業(yè)務(wù)團(tuán)隊來搭建。這樣處理的好處是，數(shù)據(jù)開發(fā)團(tuán)隊可以從做報表開發(fā)中釋放出來，有更多精力做業(yè)務(wù)價值更高的需求；業(yè)務(wù)團(tuán)隊能發(fā)揮自主能動性，利用數(shù)據(jù)自助分析平臺進(jìn)行數(shù)據(jù)看板制作，基于業(yè)務(wù)理解進(jìn)行業(yè)務(wù)問題的下鉆分析或歸因分析。

　　--

　　04

　　37手游多維分析平臺服務(wù)保障

　　1.平臺服務(wù)健康度監(jiān)控

　　很多時候分析問題比解決問題更關(guān)鍵，只要發(fā)現(xiàn)了問題，定位到了問題的原因，解決問題就水到渠成，只是解決問題的難度或者成本不一樣而已。多維分析平臺的服務(wù)健康監(jiān)控其實(shí)是一個問題發(fā)現(xiàn)的前置過程，過程分為以下幾個階段：第一，監(jiān)控數(shù)據(jù)的采集；第二，監(jiān)控數(shù)據(jù)的可視化；第三，異常數(shù)據(jù)的發(fā)現(xiàn)和告警。監(jiān)控數(shù)據(jù)采集階段包括服務(wù)器日記的采集、多維分析平臺的性能指標(biāo)采集，比如查詢錯誤率低于95%、99%，異常走勢等；數(shù)據(jù)可視化是基于Promtheus+Grafana的可視化監(jiān)控方案；根據(jù)實(shí)際業(yè)務(wù)場景進(jìn)行指標(biāo)配置，然后加上閾值觸發(fā)告警，輔助以一些智能化的手段檢測異常數(shù)據(jù)（如時序數(shù)據(jù)異常檢測類算法等）就能夠?qū)崿F(xiàn)多維分析平臺的健康度監(jiān)控和告警。

　　2. 平臺服務(wù)健康度監(jiān)控看板

　　可視化的監(jiān)控看板有很多現(xiàn)成的，比如StarRocks就有現(xiàn)成的監(jiān)控看板（參考StarRocks社區(qū)）能做到開箱即用，基本夠用，能夠滿足大多數(shù)的業(yè)務(wù)需求。

　　3. 數(shù)據(jù)質(zhì)量監(jiān)控

　　多維分析平臺的數(shù)據(jù)質(zhì)量監(jiān)控很重要。數(shù)據(jù)質(zhì)量監(jiān)控是有一套完整方法論的，從需求調(diào)研、指標(biāo)定義、開發(fā)規(guī)范、到任務(wù)和數(shù)據(jù)質(zhì)量的監(jiān)控，有一套完整的流程。業(yè)內(nèi)很多采用數(shù)據(jù)質(zhì)量治理模型DMAIC，分別是指Define、Measure、Analyze、Improve、Control；對應(yīng)數(shù)據(jù)質(zhì)量治理邊界的定義、數(shù)據(jù)質(zhì)量評估模型的建立、數(shù)據(jù)質(zhì)量問題的異常發(fā)現(xiàn)與問題歸因、數(shù)據(jù)質(zhì)量改進(jìn)。DMAIC模型就不展開講了。在37手游的業(yè)務(wù)實(shí)踐中，是從數(shù)據(jù)有效性、數(shù)據(jù)的一致性、準(zhǔn)確性、完整性和時效性五個維度來進(jìn)行評估數(shù)據(jù)質(zhì)量的。

　　4. 多維分析平臺數(shù)據(jù)質(zhì)量監(jiān)控預(yù)警系統(tǒng)

　　37手游構(gòu)建了一套數(shù)據(jù)質(zhì)量監(jiān)控預(yù)警系統(tǒng)來監(jiān)控數(shù)據(jù)質(zhì)量。

　　下圖是數(shù)據(jù)質(zhì)量監(jiān)控的流程圖，主要包括四個模塊，第一個就是調(diào)度模塊，第二個就是后端服務(wù)模塊，第三個就是執(zhí)行引擎模塊，第四個模塊就是告警服務(wù)。整個系統(tǒng)主要就是為了檢測和發(fā)現(xiàn)多維分析平臺的數(shù)據(jù)質(zhì)量問題，然后提供監(jiān)控告警。調(diào)度器發(fā)起監(jiān)控任務(wù)后，后端服務(wù)模塊就會提交作業(yè)任務(wù)到執(zhí)行引擎，執(zhí)行引擎從多維分析平臺中去拉取數(shù)據(jù)然后再執(zhí)行引擎里面做計算，或者是把計算下推到多維分析平臺執(zhí)行；之后把計算結(jié)果返回給后端服務(wù)，后端服務(wù)判斷返回的結(jié)果數(shù)據(jù)是否存在問題或者異常，如果有問題就會調(diào)起告警服務(wù)。

　　5. 多維分析平臺數(shù)據(jù)質(zhì)量監(jiān)控預(yù)警信息

　　根據(jù)異常告警等級，告警信息通過短信、微信或者電話的方式來發(fā)送給業(yè)務(wù)方或者是屬主。上圖是企業(yè)微信上收到的一個告警信息截圖。

　　6. 未來規(guī)劃

　　下面介紹一下未來的規(guī)劃。

　　前面介紹了37手游OLAP計算引擎的架構(gòu)演進(jìn)：從MySQL、Druid，到Impala，再到ClickHouse，最后到StarRocks，有太多的組件，維護(hù)的工作量非常大，所以接下來的重要工作之一就是對現(xiàn)有的組件做一些減法，收斂組件，用盡量少的組件來滿足更多的業(yè)務(wù)場景，減輕運(yùn)維壓力。

　　第二項(xiàng)重要工作就是SaaS產(chǎn)品的引入，不管是社區(qū)還是公共云，都有一些比較好一點(diǎn)的組件和37手游的業(yè)務(wù)場景非常匹配，比如說阿里云的hologress，一個組件就能夠解決用戶畫像場景中Hbase+StarRocks兩個組件組合才能解決的的業(yè)務(wù)問題，無論K-V點(diǎn)查詢、還是OLAP查詢，hologess的性能都挺強(qiáng)；如果公司可以使用公共云，hologress也是一個挺不錯的解決方案。

　　第三項(xiàng)重要工作是ELT模式的探索。數(shù)倉經(jīng)過清晰的數(shù)據(jù)分層設(shè)計與ETL數(shù)據(jù)計算，鏈路還是挺長的。隨著組件的演進(jìn)和發(fā)展，ELT也是一個挺不錯的解決思路，就是原始數(shù)據(jù)或者是粗加工的數(shù)據(jù)，導(dǎo)入到多維分析平臺之后，在多維分析平臺內(nèi)部進(jìn)行統(tǒng)一口徑的數(shù)據(jù)轉(zhuǎn)換加工處理，再對外提供服務(wù)；這種方式精簡了整個數(shù)據(jù)的加工鏈路，組件少了，流程少了，時效就能得到提升了。

　　今天的分享就到這里，謝謝大家。

　　分享嘉賓：閆鐵 37手游 數(shù)據(jù)架構(gòu)師

　　編輯整理：易雙鳳 vivo

　　出品平臺：DataFunTalk

　　01/分享嘉賓

　　閆鐵｜37手游 數(shù)據(jù)架構(gòu)師

　　長期從事BI，數(shù)據(jù)倉庫，大數(shù)據(jù)領(lǐng)域的業(yè)務(wù)開發(fā)和平臺建設(shè)。對數(shù)據(jù)中臺建設(shè)有較豐富的實(shí)踐經(jīng)驗(yàn)。

　　02/關(guān)于我們

　　DataFun：專注于大數(shù)據(jù)、人工智能技術(shù)應(yīng)用的分享與交流。發(fā)起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學(xué)者參與分享。其公眾號 DataFunTalk 累計生產(chǎn)原創(chuàng)文章800+，百萬+閱讀，14萬+精準(zhǔn)粉絲。