今天我們主要來說一下典型技術架構的分析和構建。這是我們實操的第一步。

典型技術架構的分析和構建

可能聽了我的分享或者別人的分享，大家都會躍躍欲試。我們需要從哪一個方面去入手去改造大數據業(yè)務呢?我整理了一下，一個大數據應用的一個完整流程，其實是分4個步驟，在我這兒看是4個步驟。但其中可以說是4個也可以說是3個，因為有一個可以省略的，如果你的數據體量不大的情況下。

 

 

第一個流程是數據的匯總。

數據的匯總其實是通過各種各樣的方式把數據源的數據做一個整合或者哪一個平臺里面。把所有的數據能夠打通都打通，能把數據整合到一個池子里面的都整合到一個池子里面，至于這個打通的渠道和通道是什么，以及這個池子是什么，我后一步會去說，但是你要第一步去思考這個問題，你手上有什么數據你先搞搞清楚。這是大數據的第一步，數據匯總。你得匯總什么，你得要一個明確的概念。

第二步，數據清洗。數據匯總完了以后，我們要對數據進行一個清洗，就是這一步是我剛剛說的可以省略的一步，因為有一些同學他的業(yè)務比較單純或者相對來說數據比較標準化，沒有太多的一些需要清洗的東西，他能直接應用在大數據應用和開發(fā)里面，這個看你的業(yè)務需要，清洗不是一個必須的過程，可做可不做。

正常來說，大部分的數據都要去做一次或者多次的清洗。那么對匯總數據進行清洗主要是篩掉一些沒有用的信息，然后將數據轉化成可讀性高一點的、關聯(lián)完整度高一點的數據。因為我們很多很多數據來源于不同的系統(tǒng)，來源于不同的業(yè)務，甚至來源于不同的數據庫。這種情況下你的數據過來之后會導致一個問題，因為你本身是從各個數據孤島過來的，那你原先可能是通過各種各樣的ID去關聯(lián)或者是通過各種各樣的消息ID或者是任務ID去關聯(lián)，其實這種關聯(lián)是挺碎的，需要在一個合理的范圍內去把這些數據去打平。我們上一期內容也著重說了一個打平的內容，我覺得打平是數據清洗一個比較核心的點，就是多表打平，就是做一個寬表的概念是比較重要的，甚至它占到數據清晰50%以上重要度，這是我個人的理解。因為你只有把它打平之后，它的可利用率才高，而不是說東一塊西一塊的，這個數據放在各個不同的區(qū)塊里面或者是還要通過各種關聯(lián)問題才可以查到，這種對我們后續(xù)去運用這個大數據的時候，會帶來很多很多的不方便，效率會很低，對開發(fā)人員的要求會變的很高。

第三步，數據計算。

完成數據清洗之后，我們可以通過各種各樣的方式去計算，去做一個數據的深加工。做深加工的目的是什么呢?為了把數據的價值更好的體現出來，你要去打一個比較好的基礎，我覺得數據計算這一步是整個大數據算是一個靈魂。因為你清洗完的數據其實也不具備什么的價值，你無非是把各個系統(tǒng)的數據打通，然后清洗到幾張寬表里面，那么最終這些寬表數據意味著什么呢?產生什么呢?能挖掘出什么呢?有這些東西都是由數據計算去決定的，所以數據計算是整個大數據應用核心一個靈魂。

第四步數據應用。

我們在數據加工完成之后，為一項或者多項加工成果披上外衣，把它變成一個可以讓用戶使用或者是可以被用戶感知到的一個具體應用或者是功能模塊。這是我覺得大數據應用你前面三個流程做完以后，最后一個產出物，就相當于我們從樹上摘一個果子，然后把這個果子洗干凈，洗干凈之后我們通過一系列的加工手段，把它加工成一個糖水罐頭，然后我們最終把這個糖水罐頭送到用戶面前讓他去吃，他覺得這個東西好吃，這個就達到效果了。

這是我覺得這個大數據應用是這樣一個流程，4步。打個比方，有的果子可能是在無菌環(huán)境下生長的，所以它很干凈不需要清洗，那可能就省掉了第二步，那就直接從樹上采下來之后放在加工中心，加工完去生產出一個罐頭給到用戶去吃，那這個可能會把數據清洗這一環(huán)省掉。但是我覺得大部分，絕大部分的公司可能數據清洗這一步都是需要去做的。所以大家不需要太糾結這個過程，但是理論上來說都是這4步都要走的，而且應該是按順序去走的。

數據匯總-清洗-計算-應用四步如何走?

 

 

我們先說一下數據匯總，數據匯總我們前面說過我們的數據來源有幾塊，一個是服務器的日志或者是我們的監(jiān)控數據或者是我們業(yè)務數據，乃至更多數據渠道。這個可以大家發(fā)揮自己的想象力，把它串聯(lián)起來。

為什么要這樣去做呢?大家看我們在這個圓形的圖式中，寫了哪些字：Kafka Rabbit MQ Redis，都是一些像消息隊列一樣的一些工具或者是平臺。那么原因是什么呢?因為我們要估量出數據的規(guī)模，我們不能直接把數據，未清洗的數據直接統(tǒng)一導到某一個數據池也好，數據庫也好。不能直接去導原因是什么?很簡單的一個道理。就是我們任何一個數據庫或者是數據池都是有性能上限的，特別是它應用在業(yè)務中的時候，可能正在被查詢，可能正在進行生產或者是正在進行模型訓練等等這樣一些事情。那么這個過程中，如果你有突發(fā)的數據過來，因為對數據的吞吐量你是沒有辦法去預測的，所以有突發(fā)的數據過來可能會影響到你正在生產或者是正在操作的數據庫的穩(wěn)定性。所以我們在中間放了一套緩沖機制，把所有的信息投遞到我們消息隊列，然后再由消費消息隊列的方式去把數據讀出來，然后存到我們原始數據池中去。我這兒寫的原始數據池寫的是ES。

但是具體你的業(yè)務使用環(huán)境或者是過程中是不是使用ES，你自己去考量，并不一定是絕對，只是我用順手了，所以我更喜歡用ES，因為它比較方便。這是匯聚方式。其實主要還是為了這種匯聚方式，這個架構主要目的為了提高我們數據池的一個穩(wěn)定性。然后削平峰谷這是一個比較好的彈性方案，不會因為突發(fā)寫入IO性能瓶頸影響到整個ES的業(yè)務使用，影響到這個數據庫的使用。而且我們現在大部分隊列服務都是分布式的，也可以去水平擴容，做儲存等等，就各種各樣的方式就相對來說它的抗壓能力會比一個常規(guī)的數據庫要強一些。

那么從經驗上來說，像大數據量級吞吐，我們可以用Kafka作為前端一個緩沖隊列，中小量級可能用Rabbit MQ，或者是Redis或者是阿里云的MAS或者是MQ等等，就是這樣一些服務去作為一個中間層去緩沖一下，去做常規(guī)的隊列就可以了。

那至于說我從這一步導向這一步的過程我就不贅述了，其實方案挺多的，但是你可能要根據實際的情況去選擇，比較常見的有l(wèi)ogstash或者是我們自己寫一個程序去消費隊列，去消費kafka，消費redis或者是MAS，消費之后把它存到我們的ES里面去，這樣一種方式。因為這個過程可以選擇的工具鏈以及方案很多，而且差異性很強，所以我沒有辦法去給大家畫一張這個區(qū)域的圖，這個區(qū)域的圖相對來說比較簡單，就消費存入就行了，就各家有各家的方案去處理，但是萬變不離其宗，不是一個高難度的操作。這是我們的一個匯聚方式。

 

 

說完匯聚方式之后，我們說一下就是數據清洗，數據清洗就是我們剛剛說我們拿到了一個原始大數據池，比如說ES，我們需要對它進行清洗。

清洗主要做幾件事情。一個是清洗掉沒有用的字段或者是過濾不符合預期的數據，直接表現為我們有一些日志中的數據，它可能跟我們業(yè)務沒有什么太大的關系，只是純粹是一些CPU的數據或者是內容的占用率或者是磁盤占用率，可能這些數據大部分公司是不需要，大部分公司只需要把這些屬于給到監(jiān)控室就可以了，不需要把它攙和到我們大數據計算這個過程中。所以在這個環(huán)節(jié)我們可以把這部分的數據清洗掉，過濾掉，只留下我們想要的一些數據。

第二個就是統(tǒng)一字段類型和格式。這個階段主要做的內容是哪些，我下面舉了個小例子，比如說我們java的時間戳是13位，PHP的時間戳為10位，這種情況下，要么你把13位最后面3位抹掉，降低它的精度，要么你是把PHP的時間戳后面再補三個0提高它的精度，讓它變成13位的。一定要做成統(tǒng)一格式，做成標準化的，要么你全系統(tǒng)都是13位，要么都是10位。如果你不補0補到13位或者降低精度變成10位，它在后續(xù)使用過程中會出現很多奇奇怪怪的問題，因為你的數據預期不一樣，所以表示年月日或者是換算年月日的時候最后算出來的數據是不一樣的，可能對你的業(yè)務來說會多很多的邏輯錯誤。這個例子可能最好理解的例子了，就是時間戳補0或者是降低精度的問題，主要是為了統(tǒng)一我們的字段類型和格式。

有的系統(tǒng)里面我的字段類型可能是數據性或者是字符串類型的。我們需要在我們的清洗過程中，把它統(tǒng)一的轉化成一樣的格式，或者說我們有一些小數點類型，我們在精度上有要求的，這一步就要統(tǒng)一的清洗好，就是這一塊。

那么完成格式和字段類型的清洗和調整之后，我們需要把關聯(lián)表打平到單表，就是合成寬表，這個就是我們上一期內容主要講的內容，做寬表的目的是為了讓我們后期使用這個數據的時候能夠在一個較低的成本下去應用到更多的有效數據。因為比如說當我們想要去用一個數據的時候，如果我還要產生很多的關聯(lián)查詢，在大數據應用的時候去產生很多的關聯(lián)查詢，會影響到我們的效率，一定產生關聯(lián)查詢還會產生一個更大的問題，就是你的數據池的性能以及你的數據標準化做的是不是好，你的關聯(lián)出來的數據是否準確等等一系列的問題都要考慮。相當你把一個簡單的問題可以在前期做好預防工作就可以避免的問題，留到了后期變成了一個麻煩。所以我覺得這個是一個很重要的一個。所以我打一個五角星，我覺得這個是比較重要的一環(huán)。

那么下面我簡單提煉了一下，數據清洗的意義不是單純過濾掉無用的信息或者是統(tǒng)一一下格式。因為它更多是完成前置，就是一定要把這個事情做在前面，前置的完成關聯(lián)關系的處理。比如說我們現在有幾張表，用戶，商品，訂單表，三張表。如果是我們各自獨立的，在后期我們去應用它的時候會出現性能瓶頸，就是我剛剛說的關聯(lián)查詢等等。還會大幅度提高數據計算邏輯復雜性，就是我們寫一個運算算法的人或者是寫這個邏輯代碼的人，他腦子會比較痛，也許他這個人并不是很懂業(yè)務，他可能是一個純技術人員，他不一定很懂業(yè)務，他還要去找各個相關崗位去問這個表，這個字段，這個數據有什么含義，跟我們業(yè)務結合的時候有什么用等等，就是會提高他的工作復雜程度。所以我們會把多張表打平到一層，制作一張寬表來容納三個表所有的字段。

舉個例子，我有用戶表、商品、訂單表，通常會是打平的時候會用最末端的一張表來打平，也就是說用訂單表來打平。那有的人說為什么不用商品表或者是用戶表來打平。因為最終會進到池里面的時候，我們是太在意這個數據的量級和大小，我只在意這個數據的完整性。也就是說在這個訂單表里面可能有一件商品賣給了10萬人，那就會產生10萬個訂單，如果你以訂單表去作為打平的對象的話，那會產生一個大量的數據冗余，也就是說你的訂單表只有5個字段，訂單、用戶ID、創(chuàng)建訂單時間、數量、單價、總價，這幾個字段，但是一旦跟用戶表和商品表整合進去之后這個寬表就會變的很寬，可能會變成50個字段甚至100個字段，這個情況下是合理的，這個方式跟我們常規(guī)的開發(fā)是不太一樣，也不能說我們，就是我的實際應用過程中我更提倡大家在這一步去把這個寬表一次性打到位。哪怕說明明三張表可能加起來只有5個G數據，這樣一清洗一搞就變成了50個G數據，我覺得沒有關系的，我覺得我能接受。因為你這樣后期你應用的時候你會很爽，訂單號可以帶出來訂單號所有的數據，這個訂單號是跟哪一個用戶關聯(lián)的，張三李四，然后關聯(lián)的是什么商品，那么衣服手表還是包包，這些都可以弄出來，可以統(tǒng)一弄出來，這樣后期去做的時候就會很方便，所以這個是我們打平的邏輯。

那么當我們的數據清洗完成之后，再講一下漏掉了，就是數據清洗幾個方向，我們剛剛前面這一頁說的，三件事情，我們有幾個方向去做呢?第一個是標準化，標準化就是我剛剛說的把字段格式統(tǒng)一，然后把邏輯做好，關聯(lián)做好，這叫標準化。然后做減法是什么含義呢?我們那個數據會有冗余會有繁雜的部分，所以這部分數據是我們不需要的，就比如說我們前面剛剛說的CPU的占用率內存的占用率，這些數據其實我們是用不到的，這些數據可以在這個地方去做減法，減掉。還有一種情況就是做清洗的時候，我們需要去做加法。做加法是什么含義呢?就是說我清洗之前，可能這張表只有15個字段，清洗完成之后可能會有25個字段，這樣是怎么去產生的。舉個最簡單的例子，這也是我上一期內容里面講過的，就是說我們去清洗這個字段叫IP地址，我可以通過IP地址一個字段去延伸出來至少3，4個字段，一個是你IP地址本身，然后IP地址本身還有運營商，因為IP地址可以查到你的運營商，然后你的國家、省份、地市一級、區(qū)縣一級，甚至現在更精確可以查到IP地址所在街道，但是這個準不準我不知道，但是至少至少你可以圍繞IP地址去做五六個字段的加法，這是我覺得很有意義的事情。因為相當于你擴充了數據的維度，本身IP地址只是一串數字，本身沒有什么具體的含義，只是說一個人在網絡上身份一個標識而已。但是你通過這個方式，可以讓這個數據維度更多了，首先多了運營商的維度，還多了地理位置的維度，這些維度可以讓你在后期去做大數據計算的時候有更多依據一個方式和方法。這是我覺得做清洗最主要三個方向。

 

 

清洗完了之后我們還需要去做數據計算，這是數據計算就是我們第三塊靈魂。我們可以分兩條線去看，一個是我們阿里云路線走法和我們開源路線的一個走法。

第一個我們先說一下我們有效數據池，有效數據池就是我們剛剛說的清洗數據完成之后得到一個有效數據池，這個有效數據池可以是ES也可以是其他的，這個隨你喜歡就好，你覺得可以勝任場景和性能要求，你就可以去換別的。那么當我們從有效數據池開始做計算的時候，我們需要做幾件事情，如果你選擇阿里云路線，那么我們可以先把這個數據投遞到我們ODPS表中。那可能現在ODPS表，最近數加會對它的名字有一些變化，但是我還是比較習慣叫ODPS表，就是大家如果去找產品的時候可以去到數加平臺里面去找MAX computer這個產品。當你把產品導入到ODPS表里面，你就可以去使用數加平臺去完成后續(xù)的計算。比如說它有離線計算或者是留計算，然后機器學習，深度學習等等，就這一些是在一個平臺里面去完成的，相當于有一套數據開發(fā)IDE去完成，就是這一步工作都是在數加平臺里面去完成。這是阿里云的路線。

有的同學可能說，我們還沒有辦法一下子適應阿里云，那我們希望了解一下開源路線。其實這個業(yè)界方案也很成熟的，比如說我們開源路線就是把有效的數據池，數據最終還是要導一下的，比如說導到HBase，然后通過HBase數據導進去之后，我們后面繼續(xù)可以用Spark或者是MR這種計算工具去對它數據進行計算。這套流程純開源去做的。好處是什么呢?好處相對阿里的產品，它自由度更高一點，然后可選擇開源產品更多一些。當然阿里也有流計算，但是兩邊的產品各有優(yōu)劣，可能阿里的產品有一個學習曲線，然后開源路線就是它的學習曲線可能比較透明，因為是開源產品，只要你有動手能力都可以搭的。阿里這個路線比較簡單，就是花錢就行了，就是花錢享受，這是相互的，各有利弊。

我們目前是有一部分是用了開源，然后大部分都是用阿里云的路徑。原因是什么?可能是大部分企業(yè)剛剛開始做大數據轉型的時候，都會有一個問題，我好像沒有那么多的數據，我只是嘗嘗味道，簡單的試一下，所以我是不是一上來就很重來個全家桶，開源全家桶這種方案呢，好像又覺得有點猶豫，所以這種情況下我們可以考慮說用一下阿里云按量付費就可以了，就這樣肯定花不了幾十塊錢，就可以把這個業(yè)務跑通，就可以試一下。我覺得這個方式學習成本可能會更低一點，試錯成本稍微更低一點。

 

 

數據計算完成之后，會進入到最后一個環(huán)節(jié)，就是數據應用，那么數據應用有幾個方面。第一個你可以去基于大數據去做一些淺層的機器學習，就是簡單的機器學習，挖掘更多的業(yè)務價值，就是基于你原有的業(yè)務數據和用戶行為，偏好等等這些數據，你可以去做挖掘，淺層的挖掘。比如說是電商和媒體，因為我本身是做媒體的，可以基于用戶行為數據去做智能推薦，這個方案很多，甚至很多教程都有的，這種方式可能是成本最低，也是對業(yè)務幫助立竿見影的一種方式。除了這種方式以外，我們還可以說基于歷史的交互數據，比如說我們汽車里面有記錄汽車信息的模塊，其他的設備里面有記錄各種設備操作的日志等等，基于這些數據去做深度學習去開發(fā)一個定向垂直AI類的應用，我覺得也是沒問題的。特別是像現在智能客服挺火的，像文字類客服，基本上是可以做到以假亂真，基本你去咨詢問題，你是感受不到跟你聊天的客服是真人還是機器人，但是背后還是有一些深度學習的內容在里面。還有一個是自動駕駛，這個不用我說大家都比較清楚，像特斯拉等等之類的。

第三個就是說把所有業(yè)務數據全部喚醒，然后實施可視化，把數據直觀展現出來，讓所有人感知數據。其實這一塊比較好理解，這種常見數據像我們數據報表，數據化大屏，可視化大屏，就這些都是這種類型的應用很多的，這也是一個實施周期短，然后立竿見影的一個方向。

然后第四個基于行業(yè)大數據和模型調測去做一些預測分析，這個可能看各個行業(yè)的情況不同，可能能做的事情也不一樣。比如說像氣象領域去預測一下臺風的行走路徑，或者是臺風發(fā)生的概率，下雪的概率。像交通可以預測一下什么什么時間段，這個路有什么規(guī)模的車流量，會不會擁堵，以便于他及時的去調配紅綠燈，這些也都是比較成熟應用的案例。

那么講完這些應用方向之后，我們來說一下對我們數據應用大體一個流程，就像我剛剛說，我們在大數據池無你是用ODPS還是用HBase，都是可以的，就是阿里云路線和開源路線的區(qū)別。

然后把這個數據導到大數據池之后，我們可以通過阿里云的工具或者是開源工具去做離線計算，留計算，機器學習和深度學習等等，這一系列的事情都是通過這樣的步驟去完成。那么最后的產出也就是我剛剛右邊說的智能類的推薦，AI類的應用，數據可視化，然后其他更多的一些內容。這是數據應用的一個方向。

數據應用的方向講完之后，那我們整體回顧一下我們方案內容，架構的內容，就像我剛剛說的，前面就像我說的這一層，我們前面這一層業(yè)務數據、監(jiān)控數據、服務器日志這一塊匯聚到消息隊列，然后從消息隊列消費到原始數據池中去。然后在原始數據池中的基礎上去做一次清洗，清洗完了之后把數據存入到我們有效數據池，也就是說原始數據池和有效數據池是隔離的。有效數據池完了之后，把數據導入到我們大數據池中去，比如說HBase或者是ODPS這一塊。那么導入進去之后我們可以再通過離線計算還有留計算，機器學習，深度學習等等去開發(fā)我們應用。也就是說我們全程，我們可能會用到三塊數據庫，一個是我們原始數據池數據庫，一個是有效數據池數據庫，然后我們大數據池一個數據庫，也就是說我們會有三個數據池。

那么有的人可能會說，那這樣搞來搞去好像成本和維護代價太高了，那有一個簡單的方式可以告訴大家，就是說我們原始數據池和有效數據池可以合并成一個。無非就是一個清洗完了之后重回到本身就可以了。但是我把它分開的一個原因是，我們踩過一些坑，就是你一層遞進這樣是最安全的，你不會因為說性能可靠性或者是一些這樣那樣的網絡問題導致的風險去影響到線上業(yè)務，主要是一個考慮，這個是從安全性和穩(wěn)定性去考慮我們會有三塊數據池。但是你從最小可用角度來說，你甚至可以直接把原始數據寫到大數據池里面，然后再大數據池里面去做清洗，還有打平這些事情都在大數據池里面做也沒事，具體去看，按照你自己需求和場景去進行一些調整就可以了。

標簽： 安全 大數據 大數據應用 代碼 電商 服務器 基于大數據 媒體 數據庫 網絡 行業(yè)大數據 轉型

版權申明：本站文章部分自網絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。