2024百億數(shù)據(jù)處理實(shí)踐

HadoopAmbari、spark、Flume上分為四個(gè)層次，第一個(gè)數(shù)據(jù)源，主要是收集數(shù)據(jù)庫(kù)mysql、mongodb、redis等數(shù)據(jù)，再一個(gè)就是服務(wù)端日志（基于log4j）、前端/客戶端數(shù)據(jù)；這些數(shù)據(jù)通過(guò)不同的數(shù)據(jù)采集storm，主要用來(lái)實(shí)時(shí)統(tǒng)計(jì)和監(jiān)控；最頂層就是數(shù)據(jù)應(yīng)用，目前業(yè)務(wù)服務(wù)比較多，查詢報(bào)表、數(shù)據(jù)挖掘我們會(huì)把數(shù)據(jù)中轉(zhuǎn)dm組、風(fēng)控組、安全組進(jìn)行數(shù)據(jù)應(yīng)用。flume數(shù)據(jù)基于storm，生成一些索引方式，計(jì)算count等流式處理，接下來(lái)就會(huì)存到redis、Hbase，最后會(huì)基于一個(gè)web工程進(jìn)行相關(guān)管理。這就是目前日志平臺(tái)處理。性能慢的問(wèn)題：日志多樣化，需求多樣化；日志量逐漸增大，性能下降；agentdockerdockerid，后面是實(shí)際業(yè)務(wù)日志）tailagent、fileagent、mysqlagent、redisagent，最后收集到kafka，在數(shù)據(jù)量大情況下tailagent會(huì)非常慢，比如一個(gè)目錄有上百個(gè)文件，收集的時(shí)候每個(gè)文件每秒一千的flumeagent中對(duì)tailagent數(shù)據(jù)非常實(shí)時(shí)，日志延遲不能超過(guò)一百毫秒，我們引入redisagent，就是業(yè)務(wù)方將數(shù)據(jù)導(dǎo)入redis中，我們進(jìn)行100毫秒的針對(duì)處理，這樣經(jīng)過(guò)對(duì)阿agent層的優(yōu)化，基本可以解決性能延遲、查詢延遲等問(wèn)題。所有的數(shù)據(jù)存儲(chǔ)kafka后，當(dāng)時(shí)kafka是按照數(shù)據(jù)庫(kù)類型進(jìn)行大類topic劃分，帶來(lái)的問(wèn)題就是數(shù)據(jù)熱點(diǎn)問(wèn)題，比如agent日志量非常大，但是服topickafka（比如每秒十萬(wàn)）topicstorm在客戶端為了方便瀏覽日志，開(kāi)發(fā)了alano客戶端日志，相當(dāng)于在Linux下TL-f或者下載一個(gè)文件，第二個(gè)就是DM客戶端，主要用來(lái)把收集到日志中轉(zhuǎn)給DM或風(fēng)控或安全組。tailagent（1）文件監(jiān)控。實(shí)時(shí)監(jiān)控文件的變化；（2）文游標(biāo)保存，每一個(gè)文件的讀取根據(jù)日志讀取實(shí)時(shí)性要求會(huì)在每個(gè)一秒進(jìn)行保存在本地或量讀取，將數(shù)據(jù)傳到agent，通過(guò)agent傳到kafka。redisRPUSH臺(tái)服務(wù)器上部署一個(gè)redisagent，通過(guò)LPOP或者TRANSACTIONDM、風(fēng)控、安全組的數(shù)據(jù)中轉(zhuǎn)，秒24HBaseHmaster，部署三個(gè)Hmaster，任何一臺(tái)出狀況可以實(shí)現(xiàn)秒級(jí)切換，保證服務(wù)可用性，秒價(jià)查詢會(huì)對(duì)BlockcacheDataNode，對(duì)數(shù)據(jù)要求可（1Namenode進(jìn)程死機(jī)（3）datanode（4）namenode如何在數(shù)據(jù)節(jié)點(diǎn)比較少的情況下存儲(chǔ)幾十TB到百TBsnappylzo、gzip,最后選型為snappy，因?yàn)樗趬嚎s比例和性能讀取方面，讀取解壓方面要遠(yuǎn)遠(yuǎn)好于gzip，壓縮性能又優(yōu)于lzo。在解決完壓縮后，就要解決如何實(shí)現(xiàn)服務(wù)的秒級(jí)查詢，以及一臺(tái)服務(wù)down后不應(yīng)影響查詢，或者服務(wù)GC導(dǎo)致查詢延遲秒級(jí)以上。解決方案有以下幾個(gè)方面：（1）系統(tǒng)級(jí)別的優(yōu)化。比如磁盤(pán)選型、swapping的禁用、網(wǎng)絡(luò)參數(shù)優(yōu)化等；（2）服務(wù)級(jí)別優(yōu)化。如讀寫(xiě)請(qǐng)（3）客戶端。如何保證如果服務(wù)端gc，某一服務(wù)down后，查詢保證服務(wù)的可用性；（4）設(shè)hbaserowkeyNode、zoomkeeperRAID600G擇SSID，如果對(duì)查詢耗時(shí)要求比較低，但存儲(chǔ)量又較大，可以選擇3T的大盤(pán)。是我的郵件和別人的做一個(gè)rowkey的查詢等。節(jié)點(diǎn)，在線業(yè)務(wù)量幾百T左右，出來(lái)span數(shù)據(jù)外數(shù)據(jù)都需要實(shí)時(shí)查詢。hbasehive下來(lái)講一下對(duì)于大數(shù)據(jù)，hive是如何進(jìn)行分析的。數(shù)據(jù)收集后，會(huì)得到很多表，每個(gè)表數(shù)據(jù)量都很大，最大的上百億，因此選型用hive。架構(gòu)如下，taskdrive，tasktracker300IO，CPU，內(nèi)存，網(wǎng)絡(luò)。這是基本96g,cpu24iojoin，groupbyNjobmap數(shù)少，map少導(dǎo)致并行計(jì)算的量很大，輸出量很大帶來(lái)內(nèi)存消耗過(guò)大，job的map斜,mapreduce（256255），這是因?yàn)閿?shù)據(jù)傾斜導(dǎo)致分區(qū)不均勻，某一個(gè)reduce分區(qū)可能會(huì)是其他分區(qū)的幾十倍或幾百倍。參數(shù)如何配置降低網(wǎng)絡(luò)IO消耗，Hadoop軟件優(yōu)化基本就是DataNode層次優(yōu)化，配置優(yōu)化，主要是hive如何配置實(shí)現(xiàn)解決數(shù)據(jù)傾斜的問(wèn)題、map過(guò)少的問(wèn)題等。接下來(lái)介紹下map過(guò)少、數(shù)據(jù)量較大如何解決，用join，選型是bucket，如果你用普通joinjoinbucket對(duì)sort優(yōu)化；文件系統(tǒng)選型，數(shù)據(jù)錄入hive有txtfile、enforcefile等選擇哪一種數(shù)據(jù)存joinjobjob形成bucketjoin或普通的join，按照順序join基本能解決job數(shù)過(guò)多的問(wèn)題。在hive進(jìn)行數(shù)據(jù)分析的過(guò)程中，需要考慮的點(diǎn)有：（1）盡量早地過(guò)濾數(shù)據(jù)，減少每SQLjobsqlselectwheregroupbyjoin，而不是包含在語(yǔ)義中直接使用；（3）SQLJOB54mapjoinMapjoin什么樣的級(jí)別，那些表應(yīng)該首先做join，獲得一個(gè)比較小的結(jié)果集，再用結(jié)果集和其他表join?；谶@五個(gè)原則在寫(xiě)hql語(yǔ)