如今的應(yīng)用導(dǎo)向逐漸從計(jì)算密集型演變?yōu)閿?shù)據(jù)密集型廊蜒，也就是說計(jì)算速度并不是導(dǎo)致系統(tǒng)能力不足的關(guān)鍵因素，關(guān)鍵在于數(shù)據(jù)量婆誓，數(shù)據(jù)格式以及數(shù)據(jù)的變化网杆。應(yīng)運(yùn)而生的大數(shù)據(jù)技術(shù)包括HBase羹饰，Kafka，Spark等成為行業(yè)內(nèi)典型的解決方案跛璧。
根據(jù)Oracle在2013年發(fā)表的論文，我們很容易看出在行業(yè)早期新啼，大數(shù)據(jù)能做什么已經(jīng)有了相當(dāng)明確的指導(dǎo)追城。
總結(jié)來看就是
- 對(duì)于多結(jié)構(gòu)數(shù)據(jù)的管理，包括存儲(chǔ)管理以及快速查詢
- 實(shí)時(shí)的數(shù)據(jù)分析燥撞，包括一些可視化的監(jiān)控以及方案分析等
- 智能分析座柱，包括應(yīng)用于智能推薦，企業(yè)決策制定物舒，包括物聯(lián)網(wǎng)應(yīng)用以及邊緣計(jì)算等色洞。
我們可以簡(jiǎn)略的畫出一套大數(shù)據(jù)平臺(tái)的設(shè)計(jì)圖。
在實(shí)際應(yīng)用中我們的數(shù)據(jù)源可能會(huì)有多種來源冠胯，比如多個(gè)業(yè)務(wù)部門的數(shù)據(jù)庫火诸，或是收集的日志，或是在互聯(lián)網(wǎng)上爬取的數(shù)據(jù)荠察，對(duì)于這些來源的數(shù)據(jù)有各自不同的處理方式置蜀，比如異構(gòu)數(shù)據(jù)倉(cāng)庫同步可以選擇DataX，Sqoop悉盆，Heka等盯荤。日志收集可以使用filebeat，logstash等焕盟。爬取的數(shù)據(jù)可能還得需要放到自定義的清洗組件中進(jìn)行初步清洗秋秤，這些數(shù)據(jù)經(jīng)過初步的ETL（提取-轉(zhuǎn)換-裝載）可以進(jìn)行統(tǒng)一的數(shù)據(jù)管理，在方法論中我們稱為數(shù)據(jù)湖脚翘。
之后根據(jù)不同業(yè)務(wù)功能會(huì)做進(jìn)一步的數(shù)據(jù)計(jì)算處理灼卢，技術(shù)棧基本選為spark等来农，可以使用spark+kafka的stream處理實(shí)時(shí)的任務(wù)芥玉，也可以直接提交離線任務(wù)。
計(jì)算完畢的數(shù)據(jù)备图，可以存入放入數(shù)據(jù)倉(cāng)庫中灿巧，通過數(shù)據(jù)倉(cāng)庫建立的業(yè)務(wù)如數(shù)據(jù)API赶袄，基礎(chǔ)計(jì)算指標(biāo)，SSO,完整的訓(xùn)練模型等抠藕，我們稱為數(shù)據(jù)市場(chǎng)饿肺，數(shù)據(jù)倉(cāng)庫中的數(shù)據(jù)已經(jīng)具備了與業(yè)務(wù)交涉的能力，后續(xù)的可以根據(jù)數(shù)據(jù)市場(chǎng)提供的服務(wù)或者數(shù)據(jù)進(jìn)行報(bào)表展示盾似，監(jiān)控指標(biāo)可視化敬辣，智能決策等。
數(shù)據(jù)管理
從技術(shù)角度來看零院，google發(fā)表的Bigtable論文因?yàn)橛写罅繉?shí)際應(yīng)用的案例支撐溉跃，相關(guān)的設(shè)計(jì)可以很好的解決大規(guī)模多結(jié)構(gòu)數(shù)據(jù)的存儲(chǔ)與管理，可以很好的支撐數(shù)據(jù)湖的概念告抄。也就是說撰茎，我們可以把企業(yè)的所有數(shù)據(jù)資產(chǎn)放到數(shù)據(jù)湖中統(tǒng)一管理，根據(jù)AWS上給出數(shù)據(jù)湖的概念如下：
數(shù)據(jù)湖是一個(gè)集中式存儲(chǔ)庫打洼，允許您以任意規(guī)模存儲(chǔ)所有結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)龄糊。您可以按原樣存儲(chǔ)數(shù)據(jù)（無需先對(duì)數(shù)據(jù)進(jìn)行結(jié)構(gòu)化處理）
AWS數(shù)據(jù)湖概念
關(guān)于數(shù)據(jù)湖的具體方案基本都是基于Hadoop生態(tài)上的，可以選擇Bigtable對(duì)應(yīng)的開源實(shí)現(xiàn)HBase募疮，或是Hive炫惩，甚至也可以選擇RDBMS。
數(shù)據(jù)計(jì)算處理
這部分建設(shè)阿浓，其間處理的數(shù)據(jù)和業(yè)務(wù)細(xì)節(jié)息息相關(guān)他嚷，所以有各種千差萬別的方案，不同的方式會(huì)遇到各式各樣的問題芭毙，可以說爸舒，在這整個(gè)數(shù)據(jù)流水線上對(duì)數(shù)據(jù)的ETL決定了大數(shù)據(jù)平臺(tái)基礎(chǔ)的好壞。
通常有兩種任務(wù)方式
實(shí)時(shí)任務(wù)稿蹲，通常處理使用spark+kafka的流式計(jì)算扭勉，這種計(jì)算方案服務(wù)于一些可視化平臺(tái)需要的實(shí)時(shí)指標(biāo)計(jì)算，以及實(shí)時(shí)采集系統(tǒng)等苛聘。
離線任務(wù)涂炎，通過yarn資源管理提交的機(jī)器學(xué)習(xí)模型訓(xùn)練，數(shù)據(jù)打標(biāo)设哗，分類唱捣，預(yù)測(cè)，以及結(jié)構(gòu)化處理网梢。
針對(duì)之上的兩種任務(wù)震缭，自然衍生出了一些問題
- 數(shù)據(jù)治理，包括保證數(shù)據(jù)的質(zhì)量战虏，數(shù)據(jù)脫敏拣宰，血緣分析党涕，數(shù)據(jù)生命周期，以及數(shù)據(jù)分類估算數(shù)據(jù)價(jià)值等巡社。
- 發(fā)生故障時(shí)膛堤，需要及時(shí)的警報(bào)，尤其是實(shí)時(shí)任務(wù)出現(xiàn)故障晌该， 該如何快速定位肥荔？該如何構(gòu)建出一套全鏈路追蹤系統(tǒng)？
- 復(fù)雜的workflow朝群，這可能不適用于大多數(shù)企業(yè)燕耿，往往一個(gè)定時(shí)系統(tǒng)完全cover的住整個(gè)workflow，但是隨著業(yè)務(wù)發(fā)展姜胖，各個(gè)業(yè)務(wù)之前相互依賴誉帅，構(gòu)建一套完成的workflow體系就成了整個(gè)平臺(tái)的重點(diǎn)。
- 資源管理谭期，雖然有了yarn可以幫助我們做資源調(diào)度堵第。但是有些時(shí)候吧凉，任務(wù)的優(yōu)先級(jí)可能基于各種指標(biāo)隧出，一些任務(wù)的資源調(diào)度得根據(jù)實(shí)際的集群資源需求來合理分配，整個(gè)資源調(diào)度流程該如何把控阀捅？
- 權(quán)限管理胀瞪，當(dāng)建設(shè)的大數(shù)據(jù)平臺(tái)屬于各部門間通用的基礎(chǔ)設(shè)施，權(quán)限管理饲鄙，以及用戶行為的審計(jì)凄诞。
總結(jié)
當(dāng)然之后的數(shù)據(jù)倉(cāng)庫存儲(chǔ)，以及數(shù)據(jù)市場(chǎng)已經(jīng)逐漸偏離出大數(shù)據(jù)平臺(tái)基礎(chǔ)功能的范疇忍级。在這里不在詳細(xì)展開討論帆谍。
總結(jié)來說，搭建一套大數(shù)據(jù)計(jì)算平臺(tái)并不難轴咱，我們可以選擇現(xiàn)成的開源方案apache ambari在很短的時(shí)間內(nèi)完成搭建汛蝙。但正所謂“家家有本難念的經(jīng)”，各個(gè)業(yè)務(wù)部門的垂直化朴肺，以及workflow的差異窖剑，在開源組件之上，還需要有大量的開發(fā)工作戈稿。在企業(yè)內(nèi)部西土，我們究竟有沒有必要搭建一套通用的大數(shù)據(jù)平臺(tái)？還是先根據(jù)各個(gè)部門垂直業(yè)務(wù)定制化各自搭建開發(fā)管理鞍盗？通用化建設(shè)方案方便管理需了，各部門業(yè)務(wù)更加整合跳昼，集中統(tǒng)一協(xié)調(diào)調(diào)度方便快速，做決策代價(jià)更低援所。但是隨之而來的是平臺(tái)技術(shù)棧的急劇提升庐舟，以及在平臺(tái)建設(shè)初期遇到的各種故障，是否是企業(yè)當(dāng)前可以接受的住拭？可以說一套通用的大數(shù)據(jù)平臺(tái)建設(shè)得投入一定的人員成本挪略，且經(jīng)過一段時(shí)間的沉淀才能產(chǎn)生實(shí)際的效益。垂直化方案可以快速的搭建一套簡(jiǎn)單定制化的平臺(tái)滔岳，一個(gè)部門只需要一兩個(gè)人力維持平臺(tái)業(yè)務(wù)的穩(wěn)定杠娱，以及對(duì)應(yīng)的個(gè)性化開發(fā)。相反的谱煤，在整體的資源利用率以及數(shù)據(jù)整合方面就需要打些折扣了摊求。
適合自己的才是最好的，如果一味照搬沒有任何出路可言刘离。
