1、基于Spark與NoSQL的實(shí)時(shí)數(shù)據(jù)處理實(shí)踐技術(shù)創(chuàng)新 變革未來(lái)概要關(guān)于我（們）數(shù)據(jù)、流程和架構(gòu)業(yè)務(wù)訴求技術(shù)和架構(gòu)挑戰(zhàn)和方案未來(lái)展望數(shù)據(jù)流程和架構(gòu)主要數(shù)據(jù)來(lái)源AppAnalyticAddTrackingGameAnalytic數(shù)據(jù)流程和架構(gòu)數(shù)據(jù)內(nèi)容設(shè)備信息業(yè)務(wù)信息上下文信息設(shè)備ID設(shè)備軟件信息設(shè)備硬件信息業(yè)務(wù)事件會(huì)話信息行為狀態(tài)網(wǎng)絡(luò)位置傳感器數(shù)據(jù)流程和架構(gòu)數(shù)據(jù)體量2.5/6.5億+日/月活躍智能設(shè)備活躍設(shè)備370億每天處理事件事件(日志)數(shù)17T+每天新增日志量存儲(chǔ)大小數(shù)據(jù)存儲(chǔ)離線數(shù)據(jù)處理Data CollectorJenkinsSpark Core/SQLYARNAlluxioHDFSGree

2、nPlum數(shù) 據(jù) 流 向Kafka實(shí)時(shí)數(shù)據(jù)處理JenkinsSpark StreamingYARNHDFS數(shù)據(jù)流程和架構(gòu)數(shù)據(jù)收集數(shù)據(jù)接入智能App數(shù)據(jù)采集MySQLHDFSAlluxioHBaseScyllaDBMCDataCloudDataATM數(shù)據(jù)應(yīng)用OpCenterSDMK概要關(guān)于我（們）數(shù)據(jù)、流程和架構(gòu)業(yè)務(wù)訴求技術(shù)和架構(gòu)挑戰(zhàn)和方案未來(lái)展望業(yè)務(wù)訴求新的數(shù)據(jù)處理、服務(wù)訴求數(shù)據(jù)修正時(shí)序數(shù)據(jù)事件數(shù)據(jù)時(shí)間修正（離線計(jì)算：數(shù)據(jù)到達(dá)延 遲）面向?qū)嶓w或者指標(biāo)的時(shí)序數(shù)據(jù)需求（離線計(jì) 算：時(shí)間斷面）面向?qū)嶓w，實(shí)時(shí)數(shù)據(jù)處理位置數(shù)據(jù)豐富實(shí)時(shí)處理面向?qū)嶓w，多維度、多值、多版本的查詢(xún)實(shí)時(shí)查詢(xún)業(yè)務(wù)訴求面向?qū)嶓w，多維

3、度、多值、多版本的查詢(xún)實(shí)體智能設(shè)備、位置（GeoHash、網(wǎng)格）、wifi、基站單個(gè)實(shí)體多個(gè)維度信息：ID、軟/硬件信息、環(huán)境多維度信息單個(gè)維度信息多個(gè)值：wifi1、wifi2多值多版本 單個(gè)值多個(gè)版本：wifi1-ts1、wifi1-ts2舉個(gè)例子概要關(guān)于我（們）數(shù)據(jù)、流程和架構(gòu)業(yè)務(wù)訴求技術(shù)和架構(gòu)挑戰(zhàn)和方案未來(lái)展望技術(shù)和架構(gòu)選型因可擴(kuò)展高吞吐高容錯(cuò)較成熟與其他組件好集成原不保證數(shù)據(jù)有序管理工具不夠完善主要 劣勢(shì)數(shù)據(jù)接入-Kafka技術(shù)和架構(gòu)因可擴(kuò)展高吞吐高容錯(cuò)支持窗口函數(shù)支持SQL技術(shù)統(tǒng)一調(diào)度、資源管理統(tǒng)一原微批、延遲高主要劣勢(shì)實(shí)時(shí)數(shù)據(jù)處理-Spark Streaming選型技術(shù)和架構(gòu)選型

4、因可擴(kuò)展高吞吐高容錯(cuò)較成熟低延遲 (vs HDFS)Free Schema原運(yùn)維成本相對(duì)較高(compact、split、flush)延遲不穩(wěn)定(GC、緩存命 中)主要劣勢(shì)數(shù)據(jù)存儲(chǔ)-HBase技術(shù)和架構(gòu)選型因可擴(kuò)展高吞吐高容錯(cuò)低延遲延遲穩(wěn)定原項(xiàng)目較新Bug、使用坑多主要劣勢(shì)數(shù)據(jù)存儲(chǔ)-ScyllaDB技術(shù)和架構(gòu)ScyllaDBHDFS（Bitmap）中間件規(guī)則引擎Data CollectorKafkaSpark Streaming智能AppHBaseSDMK用戶應(yīng)用概要關(guān)于我（們）數(shù)據(jù)、流程和架構(gòu)業(yè)務(wù)訴求技術(shù)和架構(gòu)挑戰(zhàn)和方案未來(lái)展望挑戰(zhàn)和方案可降級(jí)至HBase集群熱備？成 本較高HFile備份基

5、于容器 快速重建集 群熱備：可 切換至業(yè) 務(wù)線集群KafkaSpark&Yarn整體原則：故障告 警，人工介入切換、 重啟、重建HBaseScyllaDB服務(wù)穩(wěn)定性挑戰(zhàn)和方案Region數(shù)量擴(kuò)容Region數(shù)量擴(kuò)容Streaming并發(fā)數(shù)、CPU、內(nèi)存Docker實(shí)例 擴(kuò)容容量預(yù)估Topic分區(qū)數(shù)量擴(kuò)容KafkaSpark&Yarn整體原則：根據(jù)同 比、環(huán)比數(shù)據(jù)量情 況，預(yù)估下月/下 季最大容量HBaseScyllaDB挑戰(zhàn)和方案數(shù)據(jù)正確性&一致性讓批次冪等：針對(duì)每個(gè)partition的數(shù)據(jù)產(chǎn)生一 個(gè)uniqueID，只有這個(gè)uniqueID 相關(guān)所有數(shù)據(jù)都被完全計(jì)算，才算 成功，否則失敗回滾

6、。如果重復(fù)執(zhí) 行到uniqueID，會(huì)跳過(guò)。一些建議使用HBase的version特性去重， 保證數(shù)據(jù)沒(méi)有重復(fù)Spark Streaming + Kafka保證 “at last once”根據(jù)業(yè)務(wù)定方案沒(méi)有銀彈挑戰(zhàn)和方案Spark Streaming-性能穩(wěn)定性問(wèn)題方法大存儲(chǔ)SSD盤(pán)推測(cè)執(zhí)行Kafka topic 個(gè)數(shù) Spark reblanceSpark反壓Spark控量數(shù)據(jù)量突增慢節(jié)點(diǎn)問(wèn)題Yarn不穩(wěn)定(Docker容器)將Docker宿主盤(pán)從系統(tǒng)盤(pán)遷移至1T 的SSD盤(pán)1.操作是冪等情況下才可開(kāi)啟推測(cè)執(zhí)行。 spark.speculation=true2.將量比較大的topic分區(qū)數(shù)

7、加大3.使用spark的reblance算子1.通過(guò)spark控制每秒的量:saprk.streaming.kafka.maxRat ePerPartition|spark.streaming.re ceiver.maxRate，2. 開(kāi) 啟 spark 的 反 壓 機(jī) 制 ： spark.streaming.backpressure.e nable， spark.streaming.backpressure.initialRate（Direct模式不行）Docker宿主盤(pán)使用服務(wù)器系統(tǒng)盤(pán)，Spark作業(yè)大的shuffle爆盤(pán)數(shù)據(jù)不均衡或者節(jié)點(diǎn)負(fù)載高等原因 導(dǎo)致某節(jié)點(diǎn)作業(yè)處理相對(duì)較慢應(yīng)用故障恢

8、復(fù)后、流量新高峰等原 因?qū)е聅park處理淤積挑戰(zhàn)和方案Spark Streaming-優(yōu)雅的停止在獨(dú)立線程事件觸發(fā)調(diào)用ssc.stop(true, true)1.定義事件，比如HDFS上標(biāo)識(shí)文件、 監(jiān)聽(tīng)socket、啟動(dòng)RESTfull服務(wù)等，并調(diào)用ssc.stop(true, true)；2.觸發(fā)事件。其他事件觸發(fā)發(fā)送SiGTERM信號(hào)給作業(yè)的Driver1.設(shè)置 spark.streaming.stopGracefullyOnShutdown為true；2.在Spark UI上找到Drive所在節(jié)點(diǎn)；3.登陸節(jié)點(diǎn)找到Driver進(jìn)程ID；4.執(zhí)行kill -SIGTERM 。發(fā)送SIGT

9、ERM信號(hào)挑戰(zhàn)和方案Spark Streaming-其他建議spark.streaming.kafka.maxRetriesspark.yarn.maxAppAttemptsspark.yarn.am.attemptFailuresValidityIntervalspark.yarn.max.executor.failuresspark.yarn.executor.failuresValidityInterval挑戰(zhàn)和方案HBase-性能穩(wěn)定性問(wèn)題方法自控策略預(yù)分區(qū)持續(xù)監(jiān)控&優(yōu)化Major CompactRegion SplitMemStore FlushFlush Queue大小、頻次，HF

10、ile大 小、個(gè)數(shù)磁盤(pán)、網(wǎng)絡(luò)IO，堆內(nèi)存使 用波動(dòng)等根據(jù)數(shù)據(jù)情況估算分區(qū)大小及分區(qū) 個(gè)數(shù)，并預(yù)分區(qū)建表關(guān)閉 MChbase.hregion.majorcompaction=0。單rs每次處理region個(gè)數(shù)(根據(jù)期望 執(zhí)行的時(shí)間長(zhǎng)度定)可能會(huì)阻塞客戶端請(qǐng)求，占用服務(wù) 器資源Region Split導(dǎo)致region短暫下線， 如果有數(shù)據(jù)熱點(diǎn)情況會(huì)惡化Major Compact會(huì)消耗大量的磁盤(pán)、 網(wǎng)絡(luò)IO，引發(fā)原因有：挑戰(zhàn)和方案HBase-其他建議paction.large/smallhbase.hstore.flusher.counthbase.regionserver.optionalcach

11、eflushintervahbase.hregion.memstore.flush.sizehbase.hregion.memstore.block.multiplierhbase.hregion.percolumnfamilyflush.size.lower.boundhbase.regionserver.global.memstore.sizehfile.block.cache.sizehbase.regionserver.global.memstore.size.lower.limit（hbase.regionserver.global.memstore.lowerLimit）挑戰(zhàn)和方案面向?qū)嶓w VS HBase數(shù)據(jù)模型多版本多值多維度實(shí)體TableColumn FamilyColumn Family QualifierVersion值作為HBase的列名維度作為HBase的列族名:imei，wifi相對(duì)時(shí)間作為HBase的version，HBase列不賦值挑戰(zhàn)和方案大時(shí)間窗口查詢(xún)及整體存儲(chǔ)量tdid1 , imei1 , bitmap1,2,3,5 tdid1 , imei2 , bitmap4 tdid1 , wifi1 , bitmap1,2,3 tdid1 , wifi2 , bitmap4,5多版本多值多維