如今，數據分析能力正逐漸成為企業發展的標配，企業通過數據分析的過程將數據中的信息提取出來，進行處理、識別、加工、呈現，最后成為指導企業業務發展的知識和智慧。而處理、識別、加工、呈現的過程從本質上來講，就是實現對數據的采集、清洗、加工、加載、建模分析，再到可視化的過程。 
大數據平台的通用架構
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的亮點如下：
-
在線實時多維查詢，用交互式組件替代SQL和代碼。例如以前需要SQL完成的查詢，現在只需要如下：
-
豐富的分析組件，支持市場/產品/運營部門的大多數場景分析；
用戶群：根據用戶的新增情況，觸發行為，用戶字段篩選待分析的用戶；
事件分析：對某個業務行為的參與情況；
漏斗分析：用戶的轉化情況；
用戶行為路徑：用戶的行為路徑；
自定義留存：某個功能或者某個業務用戶的持續參與；
分析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主要加載的目標位置有以下：
-
原始數據備份：
AWS S3
HDFS（私有部署） -
加工后的數據：
AWS S3
HDFS（私有部署） -
模型數據倉庫
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，對外就是網站和開放平台了。
文章來源：http://mp.weixin.qq.com/s/-ABHRWcLmQObs-Qgh7Y5YQ