内容分類：
1、 企業大資料現狀及痛點
2、 大資料對企業的促進作用
3、 解析業務資料的特征
4、 典型技術架構的分析和建構
前三個為鋪墊類，最重要的是第四個。但前三個的重要性也非常高，把目錄調整下變成目标B，再來看就比較清楚：
1、 找出問題，才能解決問題；
2、 計算收益，大多數都是做企業型的，而非學術型，是以收益是企業必不可少要考慮的，并且也是要痛點痛到不能呼吸時，大多企業才會花費大量的精力去解決，而不是無關痛癢的東西也拿來占用大量企業資源解決，這樣一定情況上會影響業務增長與企業生存，這一點也是非常重要的；
3、 分析病竈，找到瓶勁，制定應對措施；
4、 給出解決方案，制定計劃，對症下藥，解決問題。這一點是最最重要的，涉及到架構搭建以及套路化的解決問題方法論。
下面就重點介紹目錄1的所有内容：如何發現問題。
一、大資料的概念
很多人都在聽大資料如何如何，怎樣怎樣。但大資料到底是怎樣的，并不是非常清晰。從表面現象來看，大資料是一個海量資料，但問題在于我們要讓這些海量的資料産生價值，就要通過一些挖掘工具來尋找它的價值 ，這是大資料尤為重要的方向。
大數制的标準定義：
1、從技術上看，大資料與雲計算的關系就像一枚硬币的正反面一樣密不可分。
2、大資料的特色在于對海量資料進行分布式資料挖掘，其戰略意義不在于掌握龐大的資料資訊，而在于對這些有意義的資料進行專業化處理。
3、如果把大資料比作一種産業，那麼這種産業實作盈利的關鍵，在于提高對資料的“加工能力”，通過加工實作資料的“增值”。
大資料和雲計算之間的關系是一體兩面的，沒有雲計算就沒有大資料。
二、大資料的前世今生
無論是大資料還是雲計算，都有一個非常重要的角度，2004~2007這三年，谷歌釋出了三篇論文，引爆了大資料時代的降臨。
這三篇論文是基于分布式資料庫、分布式檔案系統，以及彈性計算，它純屬理論，研究報告。
到了2008年，大資料之父”道格 · 卡丁把谷歌的三篇論文從理論變成了穩定産品。就是HADOOP生态逐漸起來。
2012年，聯合國、中、美等國釋出大資料白皮書。阿裡巴巴設立首席資料官一職。原來隻有CIO，沒有CDO，這也是從2012年之後才開始流行起來，有CDO這個職位。
三、本期内容的重要環節：企業資料現狀及痛點
資料的收集分三類
- 用戶端資料收集
- 業務端資料收集
- 服務端資料收集
《企業大資料實踐路線》之企業大資料的現狀與痛點
一）用戶端的資料收集主要分兩種：浏覽器資訊的收集/網絡特征資訊的收集，能收集到的和已收集到的基本上也就這兩類。
1、浏覽器資訊主要通過浏覽器請求過來，通過伺服器抓包日志裡面的一些資訊，包括它使用的什麼浏覽器、請求的參數、cookie等等，這樣的資料都是通過浏覽傳過來的，這部分資訊也是比較容易擷取的。
2、網絡特征資訊，存在CS架構程式裡面，BS主要是拿浏覽器資訊，而CS主要通過網絡特征資訊把它傳過來，傳到伺服器的同時傳到日志裡面去，這就是整個用戶端資料收集層面的資料。
二）業務端資料收集，是比較泛的，可以收集到核心業務資料和業務監控資料以及使用者互動行為資訊三部分的資料。
這些資料如何定義，分别代表什麼？
1） 核心業務資料：整個資料的業務資訊，如果你是做電商的，像商品資訊、購買資訊、訂單資訊、使用者資訊都是核心業務資料；
2） 業務監控資訊：像流量統計，庫存報警，短信發送量監控、賬号資金池餘額監控，退換貨等資訊；
3） 使用者互動行業資訊：如果一個使用者在你這裡檢視了一件商品，閱讀了一篇文章等資訊，它不是很敏感，也不是很核心的資訊，隻是使用者在操作中産生的一個互動資料，這個資料可能是有目的性的，比如他是需要買這件商品，是以他會浏覽，也可能是沒有目的性的，比如他可能是無意中點進來看看就走了。但是我們的交易資訊一般都存在庫裡面，但也可能是有，你沒有收集落地，但卻可以被收集。
三）服務端資料收集：分為三個部分的資料：伺服器日志/底層服務日志/伺服器監控資訊
1、伺服器日志收集：無論是使用Windows伺服器或是Linux伺服器，伺服器的日志都是非常關鍵的，同時比較容易收集，但也存在麻煩，它不單純是伺服器有一個什麼日志在某個地方，而是有無數個小服務，無數個核心服務組成的一個日志庫，就比較龐雜，會有各種各樣的服務及應用。
2、底層服務日志：今天在我們的伺服器上運作的一個網站，網站可能是通過我們的Apache去暴露的， 也可能是通過Nginx暴露出去的，Apache和Nginx是一個底層服務，它會産生很多很多的日志，這個日志是我們非常重要的一個分析源，是可以被收集的，也有很我公司收集這些資料進行分析。
舉個例子：通過分析Nginx日志了解到哪些頁面的性能是瓶頸，我的業務系統裡面有200個頁面，其中有15個頁面，響應時間是超過2~3秒鐘，這種情況明顯是不正常的，就需要進行性能優化處理，這是一種可能性。
第二種可能性：如果系統出現了問題，被攻擊，或入侵等問題，可能通知日志去分析哪些頁面可能成為入侵的一個點，或口子，包括有沒有一些畸形的請求産生，這些都是可以通過服務日志裡面看到的，這些分析也是非常重要的，一切的分析都是離不開日志的。
3、伺服器監控資訊：現在軟體越來越多了，都具備收集監控日志的能力，比如做監控開源用的比較多的有Zabbix，還有阿裡雲的雲監控，都是相對用的比較多的，它能監控我們整個伺服器CPU的使用，磁盤的使用以及記憶體的使用，IO的開銷等等，不一定是日志的方式去落地的，但會有一個程式去收集它，把資料發送到他的服務端上去。整個服務端收集到的資料都非常的豐富與多元化，也非常龐雜。
那麼以上資料能收集到的三大塊資料裡面的8小塊資訊又都有怎樣的表現形式呢？
用戶端資料樣例：
從下圖中可以看到時間、類型、頁面位址、浏覽器類型以及版本号、裝置資訊等，都是非常重要的資訊。
這些資訊通常來源于對浏覽器資訊的采集，資訊多為非結構化資料，而且量特别大。當業務表現為WEB形式時，通常拿到的資料是浏覽器的相關資訊，當業務表現為混開式APP時，拿到的資料會額外得到業務APP的其它資訊，比如機型、Android或IOS版本号等。
業務端的資料樣例：
上圖來源于資料庫，Mysql、MongDB 等，有結構化的也有非結構化的資料，通常在業務過程中産生，就如之前講的如果你是做電商平台的，那這些資料就是電商運作過程中産生的資料。這些資料非常重要，屬于核心資料，重要性遠遠大于用戶端資料和伺服器端資料。
可以肯定的說，其它兩個資料丢也就丢了，不會給公司造成緻命性的傷害，但業務資料如果丢失了，可能公司都沒了,重要性可想而知。
服務端的資料樣例：
通常來源于伺服器端的具體服務，一般為文本格式，且多為非結構化資料，比較枯燥，上圖這個日志就是一個Nginx的通路日志，這裡面也存在一些比較有差異化的地方。目前用的軟體都是比較新的，但有一些存量的業務使用的版本偏老，這種情況就會存在同一個業務線使用了不同的底層服務，比如說Apache可能使用了2.2的版本，也有可能使用2.4的版本，Nginx有可能使用了1.1的版本，甚至是1.0的版本，這種版本上的差異會帶來如幾個弊端：
1、 配制方式不一樣
2、 日志格式不一緻：這種情況就會導緻不同時期、不同版本的服務可能産生格式完全不一緻的日志，導緻模闆無法套用，這是一個需要引起注意的問題。服務端的資料相對說比較單純，多半都是文本形式存在。
以上三大類8小塊的資料，這些資料都有些什麼樣的問題？這個是需要我們任何一個人去思考的。
四、資料存在的問題
大部分企業的資料現狀，基本上就分如下四個部分，當然也有做好的，可能不存在如下這種情況，但絕大資料情況下，都多少會有一些問題。而我們本身就是一個有問題的企業，一步步從有問題到發現問題、解決問題這樣摸爬滾打過來的。
1、孤島化：各種各樣的業務線、系統、平台每時每刻都在産生資料，但是這些資料不彙聚，深入點講就是資料可能都不在一台伺服器上，業務起來也有先後順序，不一定都集在一套系統裡成。最常見的像用Java做的應用程式，幾年前開發的是一個IIS一個版本，Tomcat一個版本，今天開發的産品用的IIS是一個版本，Tomcat又是一個版本，這種問題理論上說是要優先考慮并且要避免的，要對老的版本進行疊代，保持到一個比較新的且穩定的版本，但大部分企業都聚焦在如何把業務更快速的疊代好，把産品上線，很多東西就在過程中慢慢孤島化。除了IIS與Tomcat外，像Mysql、日志平台的差異等，如果不能有效的統一起來，就無法有效的進行資料分析，這就是孤島化帶來的最大問題。
2、 多格式：企業手中的資料雜亂無章，格式不統一。不能有效整合成統一格式進行應用。如果今天我們要去分析我們的資料，資料要拿來用了，我們都希望資料統一，無論是結構化還是非結構化，大不了JS我們打散放到MongDB裡面去，變成一個個文檔到後面再去處理，要麼就是全部都處理好變成結構化資料，放到一個Mysql，或者是其它結構化的資料裡面，再進行統一的分析和處理，但這種狀态太理想化了，很難實作，像傳回日志的問題，有1000條PV就會有1000條日志，如果這是1天的量，那一年的量可想而知，這樣的資料量放到單一的資料庫裡面去，也不現實，是以多格式面臨的問題就是不能有效的整合成統一格式進行應用。
3、 低價值：除了核心業務資料擁有很大價值，最大的問題是所有業務資料的量隻占我們所有資料量的5%~10%，其他90%都是附加資料，不能有效的産生價值。是以大資料從字面意思了解，他隻是一個名詞，是一個海量資料的名詞，90%資料都不産生價值的話，它隻能屬于沉睡資料資産。大部分企業資料都存在這個問題就是低價值的問題。
4、 無應用：擁有大量的資料，90%的資料又不能被直接應用，無法被使用者直接感覺，它就是我們經常所說的，食之無味，棄之可惜，但又占用空間的無用産物，無應用就展現在占用磁盤，應用了你大量空間，卻未被轉化成客戶可感覺、可應用的資料。
五、内容總結
1、大資料的概念
2、大資料的前世今生
3、大資料的采集方式
4、資料的定義
5、資料存在的問題
六、問題答疑環節：
1：大資料在高校裡面有什麼樣的應用場景？
答：
1）實驗資料少時，用紙記錄；
2） 産生海量資料時，找個資料庫存下來，會存在幾個比較明顯的問題：
A、 實驗室比較機動，随機性強，資料格式無法定義
B、 資料不标準，多數情況下先收集，再分析
問題2：業務資料難道不是通過用戶端收集的嗎？
業務資料不一定是通過用戶端收集的，如果你的産品是通過異步方式處理的，APP端和WEB端隻負責請求丢給消息隊列，由後端服務去消費消息隊列，再進行後續的操作，這個過程中你是可以去收集消息隊列中的日志，再進行分析，進而留存使用者行為的效果。
通過用戶端收集會有一個問題，收集日志過程中都有一個原則，如果是通過非侵入式拿到日志，那就一定得通過非侵入式擷取日志，千萬不要通過破壞性的埋點、打空的方式拿日志，埋點打空本身會對我們的業務形成一定的破壞性，影響到性能，特别是不能預期這個場景時，這個性能破壞無限大。比如說當你在做一個秒殺活動的時候，你通過秒殺活動的APP同步參與秒殺，又同時存日志到資料池中去，秒殺可能有1秒中有幾十萬次，幾百萬次的請求，伺服器本身壓力已夠大，這種情況下，可能就會導緻雪崩，叢集有可能就會挂掉。這是一個非常典型的，不應該出現的低級錯誤，是以最好是龐路收集。
下一期内容《
大資料對企業的促進作用》将于11/28晚20：00直播，敬請期待。