大數據從哪裏來？

現代商業市場是一個數據驅動的環境，能夠說不論技術怎麼更新換代，數據都有着不可替代的地位，並且拋開數據談大數據就是瞎扯，沒有數據做支撐的大數據平臺就是一個空殼。不管是公司內部的數據仍是外部的數據均可以構成咱們大數據平臺的來源數據，大數據平臺的數據來源主要有數據庫、日誌、前端埋點、爬蟲。

1 從數據庫導入

在大數據技術風靡起來前，關係型數據庫（RDMS）是主要的數據分析與處理的途徑。發展至今數據庫技術已經至關完善，當大數據出現的時候，行業就在考慮可否把數據庫數據處理的方法應用到大數據中，因而 Hive、Spark SQL 等大數據 SQL 產品就這樣誕生。

雖然出現 Hive 大數據產品，可是在生產過程當中業務數據依舊使用 RDMS 進行存儲，這是由於產品須要實時響應用戶的操做，在毫秒級完成讀寫操做，而大數據產品不是應對這種狀況出現的。到這裏你可能就有一個疑問，如何把業務的數據庫同步到大數據平臺中？通常來講業務數據咱們使用實時和離線採集數據來將數據抽取到數據倉庫中。而後再進行後續數據處理和分析，一些常見的數據庫導入工具備 Sqoop、Datax 和 Canal 等。

Sqoop 是 Apache 旗下一款 Hadoop 和關係型數據庫之間傳送離線數據的工具。實現關係型數據庫（MySQL 、Postgres 等）同 Hadoop 集羣的 Hdfs、Hbase、Hive 進行數據同步， 是鏈接傳統關係型數據庫和 Hadoop 的橋樑。datax 與 sqoop 相似也是進行離線數據傳輸，支持阿里數據庫系列數據同步。

Canal 則是經過讀取 MySql的 BinLog 日誌 實時傳輸數據到大數據平臺，實現數據的實時介入。

2 日誌導入

日誌系統將咱們系統運行的每個情況信息都使用文字或者日誌的方式記錄下來，這些信息咱們能夠理解爲業務或是設備在虛擬世界的行爲的痕跡，經過日誌對業務關鍵指標以及設備運行狀態等信息進行分析。

Apache Flume 是大數據日誌收集經常使用的工具。從圖中能夠看出 Flume 運行的核心是 Agent，以 Agent 爲最小的獨立運行單位。Agent 主要由三個組件：Source，Channel、Sink。

Source： 收集數據，封裝數據爲事件（Event）後發送到 Channel，數據來源能夠是企業服務器、文件系統、雲、數據存儲庫等。

Channel： 一般，讀取速度比寫入速度快。所以，咱們須要一些緩衝區來匹配讀寫速度差別。基本上，Channel 提供一個消息隊列的功能，用於存儲 Source 發送的事件，對事件進行消息排序，發送到 Sink。

Sink： 從 Channel 收集數據，將數據輸送大數據存儲設備，好比 HDFS、Hive、Hbase 等，Sink 也能夠做爲新的 Source 輸入源，兩個Agent 進行級聯，根據需求開發各類處理結構。

3 前端埋點

爲何須要埋點？如今的互聯網公司愈來愈關注轉化、新增、留存，而不是簡單的統計 PV、UV。這些分析數據來源經過埋點獲取，前端埋點分爲三種：手工埋點、可視化埋點、自動化埋點。

手工埋點：

前端須要返回數據的位置調用寫好的埋點 SDK 的函數，按照規範傳入參數經過 Http 方式傳入後代服務器中。這種方式能夠下鑽並精準採集數據，但工程量巨大。

自動化埋點：

也叫無埋點，便是無需埋點，在所有位置都設置埋點，對用戶全部操做進行採集，這種方式經過統一的 SDK 返回數據，再選擇須要的數據進行分析，這種方式加大服務器的壓力，採集許多不須要的數據，浪費資源。在實踐中，能夠採用對部分用戶或者部分簡單操做頁面進行全埋點採集。

可視化埋點：

是介於手工埋點和自動化埋點之間方式，經過可視化交互設置埋點，能夠理解爲人爲干預的自動化埋點形式。

那如何選擇埋點方式？對於一個按鈕，若是採用可視化埋點或者自動化埋點時，能夠輕易採集用戶什麼時候點擊按鈕，對於須要運行獲取得到的數據是沒法採集，好比訂單的商品詳細信息等，對這種狀況應該採用手動埋點處理採集。對此，埋點問題不該該經過單一的技術方案來解決，在不一樣場景下咱們須要選擇不一樣的埋點方案。

4 爬蟲

時至至今， 爬蟲的數據成爲公司重要戰略資源，經過獲取同行的數據跟本身的數據進行支撐對比，管理者能夠更好的作出決策。並且越難爬蟲獲取競爭對手的數據，對於公司來講是越有價值。

小結

數據採集自己不是目的，只有採集到的數據是可用、能用，且能服務於最終應用分析的數據採集纔是根本。數據採集的科學性決定了這個數據分析報告是否是有使用價值。只有當數據採集具備科學性、客觀、嚴密的邏輯性時，創建在這樣的數據分析基礎之上的的出來的結論才具備現實的價值和意義。