如今，資料分析能力正逐漸成為企業發展的標配，企業通過資料分析的過程將資料中的資訊提取出來，進行處理、識別、加工、呈現，最後成為指導企業業務發展的知識和智慧。而處理、識別、加工、呈現的過程從本質上來講，就是實現對資料的採集、清洗、加工、載入、建模分析，再到視覺化的過程。 

大資料平臺的通用架構

1. 資料採集

採集是指集中企業待分析的原始資料的過程，例如可能是包含但不限於以下： 
- 企業伺服器的日誌； 
- 企業各種資訊系統的資料（CRM/ERP/資料庫）； 
- 企業的網站/App/小程式等客戶端的使用者行為記錄； 
- 使用的第三方系統（客服、IM、HR）提供的API；

採集的方式基本上分為兩種： 
PUSH模式：企業的資料一般來講都是散落在很多地方，各種系統或者各種伺服器，所以有一個數據採集中心，然後在各個資料產生的位置都有一個agent（可以認為是採集程式）然後朝資料採集中心傳送資料的過程就是PUSH，比如在App或者網站植入了SDK，定期傳送採集到的使用者行為資料到服務端的過程就是PUSH模式； 
PULL模式：企業有資料採集中心，從採集中心去訪問獲取各個資料產生點的資料，這個過程就是PULL，比如從企業的資料中心去呼叫第三方系統的API獲取資料，就是PULL模式。

2. 資料的清洗

資料清洗的過程是指對資料進行一些處理，過濾無用的資訊，規範得到能用到的資料。包括但不限於以下情況： 
- 過濾SPAM垃圾資料，例如被攻擊/造假/BUG產生的大量資料 
- 抽取有用欄位，例如上傳的資料包含的資訊很多，只用到一小部分 
- 原始資料有很多格式不規範，要統一格式

3.資料的加工

資料加工是指清洗後的資料，還需要補充一些資訊，可能是通過資料庫查詢出來的，也可能是通過計算規則計算出來的，或者演算法技術加工出來的新欄位。 
例如，資料裡面有個ip地址，需要計算出使用者的地理位置，那麼地理位置就是加工出來的欄位。一般來講，對於大多數大資料分析平臺而言，加工是很重要的過程，基本上最後可用來進行分析的資料，要通過這一步充分完成加工計算。

4. 資料載入

資料載入是指把加工後的資料載入到合適的儲存，可能是Hadoop叢集的HDFS上，也可能是某個資料庫，有可能是檔案等等其他儲存型別。

5. 建模分析

建模分析是指在查詢前需要把資料進行處理，以優化查詢，例如以下： 
- 資料倉庫建好了倉庫模型，要把資料載入到資料倉庫中 
- 需要做資料索引，把資料進行索引優化

資料模型很重要，是整個資料處理分析的核心之一。每個企業都有自己的核心業務，以及核心目標，並且也有各自的資料來源以及資料型別，所以也就意味著每一家企業的資料模型多少都會有些差異，也就是最個性化的一個地方，資料倉庫就是這個資料模型的載體，一般來講資料就是資料庫技術，常見資料庫之外，還有Infobright，Greenplum，Vertica，也有基於Hadoop技術的，用HDFS作為基礎的儲存，然後使用的查詢引擎，包括Imapla，Presto，SparkSQL等等。

通常而言，資料團隊要進行復雜的查詢和分析，都是在此基礎之上，通過SQL語言或者程式碼查詢來實現的。

6. 視覺化

視覺化是最終分析結果要展示的過程，例如“雙十一”酷炫的圖表，一般企業都有自己的資料看板等等。

視覺化背後主要是執行SQL或者執行程式碼得到的資料結果，可能是一維，也可能是二維，還有可能是多維，然後選擇合適的圖表型別進行展示，例如“線狀圖”、“柱狀圖”、“餅狀圖”、“雷達圖”、“中國地圖”等等。

以上是通用的大資料平臺整個資料處理的方式，接下來就從諸葛io與通用的資料平臺的差異入手，然後帶入諸葛io的技術設計。諸葛io的整套技術能夠做到的是，對企業分析流程的效率提升。

大多數企業的分析現狀

自建或者第三方統計平臺（百度統計/友盟/Talkingdata）+ 資料BI團隊（早期團隊人數很少，甚至是一兩個工程師兼任）；

自建或者第三方統計平臺：大多都是彙總統計指標平臺。對通用指標（例如PV、UV、DAU、留存）的計算，對企業設定好的業務行為（打車、訂單、參與、金額）等彙總統計人數或者次數，資料平臺儲存的都是指標的彙總結果。指標的選擇和下鑽分析都需要資料團隊的支撐。

資料BI團隊：完成基礎資料平臺的搭建，並且梳理核心業務分析目標，對基礎資料進行採集建模，並完成各個部門的分析需求。 
所以最上面那張圖就是大多數企業現在的分析現狀： 

基本上先統一由大資料部門整理輸出各部門日常固定的資料指標，然後做個視覺化，比如一個簡單的頁面

如果有新的分析需求，已經建模好的，那麼資料團隊就需要根據業務去寫SQL然後得到結果，如果沒有建模好的，就需要開始採集原始資料，然後重新開始清洗，這樣一個過程，往往都比較反覆耗時，分析效率很低

主要原因是，這樣一種分析流程，是由固定的業務指標驅動資料的採集和處理，然後資料處理的過程基本上都是多維彙總的統計和計算

所以也就造成了問題：各個業務部門的分析需求需要依賴資料團隊專業的資料分析能力進行問題建模，並且依賴他們SQL語言或者程式碼能力完成分析目標。但資料部門往往也有核心的分析需求和任務，所以公司變大過程中很多問題變得很低效。

諸葛io平臺技術的演化之路

諸葛io的整個資料處理也是符合上面的整個流程，和其他資料分析平臺，尤其是傳統資料平臺，按照處理過程抽象的差異主要如下： 

諸葛io的分析能力遠遠大於目前大多數的統計平臺，諸葛io把很多深入的分析場景，依賴資料團隊進行建模以及SQL/程式碼等專業能力，變成了視覺化的分析元件。這樣極大的提高了企業的資料分析效率，並且還有專業的資料分析看板，輔助企業梳理了解分析需求和目標。

諸葛io的亮點如下：

1. 線上實時多維查詢，用互動式元件替代SQL和程式碼。例如以前需要SQL完成的查詢，現在只需要如下： 
   

2. 豐富的分析元件，支援市場/產品/運營部門的大多數場景分析； 
   使用者群：根據使用者的新增情況，觸發行為，使用者欄位篩選待分析的使用者； 
   事件分析：對某個業務行為的參與情況； 
   漏斗分析：使用者的轉化情況； 
   使用者行為路徑：使用者的行為路徑； 
   自定義留存：某個功能或者某個業務使用者的持續參與； 
   分析API和資料API，完全掌控您的資料，基於諸葛io靈活擴充套件：

除此之外，細緻入微的產品設計，貫穿分析過程，例如： 
點選數字到使用者畫像的洞察； 
漏斗的無序和有序； 
使用者群“新增後X天”； 
還有更多的場景，可以去感受和體驗； 
這樣一來，回到剛剛的圖片： 

在建模時非常抽象，並且基於獨立使用者跟蹤了整個業務的流程，所以不只是指標任意的配置視覺化，很多以前依賴於SQL和清洗程式碼的邏輯，也變成了互動式的查詢元件，所以能提高效率，那諸葛io是怎麼做到的呢？先來看看整體的架構： 

首先看看資料採集端，提供豐富的介面和SDK，能夠採集到企業各個有使用者行為資料的地方，目前來講，主要分為以下： 
Android客戶端 ： Android SDK 
iOS客戶端 ： iOS SDK 
網站或微站H5 ：Javascript SDK 
小程式：小程式SDK 
日誌:服務端Restful介面 
CRM資料庫 ：匯入工具

也就是採用了“PUSH”模式，各個端採集使用者的行為，然後再按照規則傳送給資料收集中心，各個端也就寫了一些SDK，讓開發者呼叫採集，然後就是資料收集端: 

上圖是據收集架構: 核心就是LVS+Nginx+Lua，諸葛io沒有用比較重的後端語言來採集，而是選擇了比較輕的Lua指令碼語言，在nginx中整合就能完成高併發的複雜，LVS做解析伺服器的負載均衡，後面是多個Nginx，然後Nginx本身就是高效能高併發伺服器，所以併發的承載能力非常強。

諸葛io採用的是HTTPS加密傳輸，以及支援HTTP2協議：

採用HTTPS的原因是，防止資料在傳輸過程中被抓包截獲；

採用HTTP2協議，服務端的處理效能能夠極大的提升，連線也有優化。

使用LVS的原因是，雖然Nginx的效能很高，但是在高併發壓力情況下，能夠快速新增Nginx節點，再加上資料採集是非同步，所以大流量情況下，LVS+Nginx基本上都能保證不會出現連線等待的情況了。

Lua是一種輕型的指令碼語言，直接在nginx配置中嵌入，在很多遊戲的服務端架構以及電商秒殺的架構中使用。服務端接收到上傳資料之後，Lua會進行解析，並且新增上傳時一些資訊（ip，服務端時間，User-Agent）等等，然後push到Kafka的叢集。

這套架構也是在諸葛io的日上傳資料量逐步上漲過程中，逐步演化出來的。

簡單來講，資料採集具有高併發、高伸縮性性、HTTPS安全傳輸的特點。

然後就是資料清洗。諸葛io採集到的資料會有以下幾個問題需要處理： 
- 垃圾資料：亂碼或者埋點錯誤產生的資料 
- 作弊資料：惡意進行注入偽造的資料 
- 淘汰資料 ： 已經棄用的SDK版本資料 

所以會完成對於上述資料的清洗。清洗完的資料，諸葛io還會進行一些資訊加工，包括但不限於以下：

-識別使用者和裝置的身份關係 
-加工欄位：地理位置、UTM推廣資訊、裝置、系統版本（網站或者微站根據UA） 
-事件行為匹配系統id

加工資訊之後，還會對資料按照資料模型進行格式轉化和預計算處理，得到所需要的最優於查詢的資料。

關於資料清洗加工部分，和其他大資料技術還有一些差異： 
-獨立的使用者行為跟蹤； 
-基於使用者身份的資料整合； 
-精準的使用者和裝置關係識別； 
-事件的標籤化；

接下來是資料載入。資料載入的過程，就是把資料處理後的結果寫入儲存，這裡，諸葛io主要載入的目標位置有以下：

1. 原始資料備份： 
   AWS S3 
   HDFS（私有部署）

2. 加工後的資料： 
   AWS S3 
   HDFS（私有部署）

3. 模型資料倉庫 
   Redshift 
   Greenplum（私有部署）

因為諸葛io同時支援SaaS和私有部署，私有部署採用的方案會有差異，S3和HDFS都是檔案訪問，所以業務層基本是一致，S3是因為儲存成本低，HDFS是大多數企業的Hadoop平臺。加工後的資料同上。

模型倉庫，Redshift和Greenplum都是基於PostgreSQL的。加上自定義函式，在資料訪問層保持一致。

然後在建模分析的過程，建模分析的核心是諸葛io的資料模型，也就是資料倉庫設計，諸葛io現在的核心資料模型，分為以下主題：

使用者：使用者的屬性資訊；事件/行為（包含屬性資訊和觸發環境）；行為發生平臺：平臺（裝置）的基礎資訊；

諸葛io的資料模型底層都已經對使用者和行為進行建模，從上層指標的計算，可以直接下鑽使用者群體，並且對於使用者的行為歷史也有完整的還原和實時的洞察。

傳統的資料分析平臺都以裝置進行統計，諸葛io是基於使用者的，所以使用者和裝置的關係精準還原。

諸葛io的資料查詢和訪問： 
資料訪問層，是諸葛io把基於資料倉庫的SQL查詢訪問抽象了一層服務，分為對內和對外兩部分，用以控制對資料訪問的統一管理。主要分為兩部分： 
對內是通過統一的API服務來進行訪問 
對外是有Open API的開放平臺

視覺化查詢主要是通過諸葛io的網站進行完成，並且在技術上也是基於資料訪問層實現。視覺化在諸葛主要分為兩部分： 
1. 資料指標展現的視覺化 
2. 查詢操作的視覺化 
指標展現視覺化，包括不限於表格、柱狀圖、線圖、漏斗。回到整個架構上： 

可以看到有訊息中心，諸葛io的訊息中心是以Kafka為中心進行設計的。 
訊息中心主要處理包含以下業務訊息的彙集和分發： 
-各種SDK或者工具上傳的數； 
-資料清洗產生的中間的資料； 
-模型結果資料； 
-備份資料； 
-其他流式處理資料；

Kafka具有多消費組的特點，也就意味著，可以在不同應用場景下對統一資料進行多種處理，併產生多種應用，例如下面場景：

收集到各種資料，並會新增到Kafka訊息中心，然後會有以下不同消費應用。

實時計算中心，諸葛io用的是Spark Streaming進行處理，也有其他套件輔助進行一些資料探勘，實時資料和關係快取，諸葛io用的是Codis以及SSDB，Codis是分散式的Redis實現框架（由前豌豆莢團隊開源）諸葛io會用來做分散式的訊息以及狀態儲存，而SSDB是基於Redis協議的硬碟實現（作者是懶投資的CTO吳總）諸葛io會儲存一些鍵值比較大或者多的資料，例如實時資料以及資料快取。

基礎儲存剛剛講過了主要是S3，索引用的是Elasticsearch，比如查詢時的提示等等，線上多維實時資料處理查詢就是Redshift和Greenplum了，然後統一了整個資料訪問層以及API，並且分為內部和外部API，對外就是網站和開放平臺了。