大數據浪潮下，諸葛io平臺的技術演化之路

本文做者主要以諸葛io背後的大數據平臺設計爲重點展開講解。

從本質上來說，大數據平臺的目標都是完成對數據的採集、清洗、加工、加載、建模分析，可視化的過程。

1、大數據平臺的通用架構

1. 數據採集:
採集是指集中企業待分析的原始數據的過程，例如多是包含但不限於如下：

1. 企業服務器的日誌；

2. 企業各類信息系統的數據（CRM/ERP/數據庫）；

3. 企業的網站/App/小程序等客戶端的用戶行爲記錄；

4. 使用的第三方系統（客服、IM、HR）提供的API；
   採集的方式基本上分爲兩種：

PUSH模式：企業的數據通常來說都是散落在不少地方，各類系統或者各類服務器，因此有一個數據採集中心，而後在各個數據產生的位置都有一個agent（能夠認爲是採集程序）而後朝數據採集中心發送數據的過程就是PUSH，好比在App或者網站植入了SDK，按期發送採集到的用戶行爲數據到服務端的過程就是PUSH模式；

PULL模式：企業有數據採集中心，從採集中心去訪問獲取各個數據產生點的數據，這個過程就是PULL，好比從企業的數據中心去調用第三方系統的API獲取數據，就是PULL模式。

2. 數據的清洗

數據清洗的過程是指對數據進行一些處理，過濾無用的信息，規範獲得咱們能用到的數據。包括但不限於如下狀況：

1. 過濾SPAM垃圾數據，例如被攻擊/造假/BUG產生的大量數據

2. 抽取有用字段，例如上傳的數據包含的信息不少，咱們只用到一小部分

3. 原始數據有不少格式不規範，要統一格式

4. 數據的加工

數據加工是指清洗後的數據，還須要補充一些信息，多是經過數據庫查詢出來的，也多是經過計算規則計算出來的，或者算法技術加工出來的新字段。
例如，數據裏面有個ip地址，須要計算出用戶的地理位置，那麼地理位置就是加工出來的字段。通常來說，對於大多數大數據分析平臺而言，加工是很重要的過程，基本上最後可用來進行分析的數據，要經過這一步充分完成加工計算。

4. 數據加載
數據加載是指把加工後的數據加載到合適的存儲，多是Hadoop集羣的HDFS上，也多是某個數據庫，有多是文件等等其餘存儲類型。

5. 建模分析
建模分析是指在查詢前須要把數據進行處理，以優化查詢，例如如下：

1. 數據倉庫建好了倉庫模型，要把數據加載到數據倉庫中

2. 須要作數據索引，把數據進行索引優化

數據模型很重要，是整個數據處理分析的核心之一。每一個企業都有本身的核心業務，以及核心目標，而且也有各自的數據源以及數據類型，因此也就意味着每一家企業的數據模型多少都會有些差別，也就是最個性化的一個地方，數據倉庫就是這個數據模型的載體，通常來說數據就是數據庫技術，常見數據庫以外，還有Infobright，Greenplum，Vertica，也有基於Hadoop技術的，用HDFS做爲基礎的存儲，而後使用的查詢引擎，包括Imapla，Presto，SparkSQL等等。

一般而言，數據團隊要進行復雜的查詢和分析，都是在此基礎之上，經過SQL語言或者代碼查詢來實現的。

6. 可視化
可視化是最終分析結果要展現的過程，例如「雙十一」酷炫的圖表，通常企業都有本身的數據看板等等。

可視化背後主要是執行SQL或者運行代碼獲得的數據結果，多是一維，也多是二維，還有多是多維，而後選擇合適的圖表類型進行展現，例如「線狀圖」、「柱狀圖」、「餅狀圖」、「雷達圖」、「中國地圖」等等。

剛剛講的主要是通用的大數據平臺整個數據處理的方式，不知道是否講的通俗易懂，接下來我就從諸葛io與通用的數據平臺的差別入手，而後帶入咱們的技術設計。
首先，諸葛io的整套技術可以作到的是，對企業分析流程的效率提高。

大多數企業的分析現狀：自建或者第三方統計平臺（百度統計/友盟/Talkingdata）+ 數據BI團隊（早期團隊人數不多，甚至是一兩個工程師兼任）；

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

數據BI團隊：完成基礎數據平臺的搭建，而且梳理核心業務分析目標，對基礎數據進行採集建模，並完成各個部門的分析需求。

因此你們能夠看到最開始上面那張圖就是大多數企業如今的分析現狀：

基本上先統一由大數據部門整理輸出各部門平常固定的數據指標，而後作個可視化，好比一個簡單的頁面。

若是有新的分析需求，已經建模好的，那麼數據團隊就須要根據業務去寫SQL而後獲得結果，若是沒有建模好的，就須要開始採集原始數據，而後從新開始清洗，這樣一個過程，每每都比較反覆耗時，分析效率很低。

主要緣由是，這樣一種分析流程，是由固定的業務指標驅動數據的採集和處理，而後數據處理的過程基本上都是多維彙總的統計和計算。因此也就形成了問題：各個業務部門的分析需求須要依賴數據團隊專業的數據分析能力進行問題建模，而且依賴他們SQL語言或者代碼能力完成分析目標。但數據部門每每也有核心的分析需求和任務，因此公司變大過程當中不少問題變得很低效。

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

諸葛io的整個數據處理也是符合上面的整個流程，咱們和其餘數據分析平臺，尤爲是傳統數據平臺，按照處理過程抽象的差別主要以下：

諸葛io的分析能力遠遠大於目前大多數的統計平臺，咱們把不少深刻的分析場景，依賴數據團隊進行建模以及SQL/代碼等專業能力，變成了可視化的分析組件。這樣極大的提升了企業的數據分析效率，而且咱們還有專業的數據分析看板，輔助企業梳理了解分析需求和目標。

諸葛io的亮點以下：

1. 在線實時多維查詢，用交互式組件替代SQL和代碼。例如之前須要SQL完成的查詢，如今只須要以下：
   

2. 豐富的分析組件，支持市場/產品/運營部門的大多數場景分析；
   用戶羣：根據用戶的新增狀況，觸發行爲，用戶字段篩選待分析的用戶；

事件分析：對某個業務行爲的參與狀況；

漏斗分析：用戶的轉化狀況；

用戶行爲路徑：用戶的行爲路徑；

自定義留存：某個功能或者某個業務用戶的持續參與；

分析API和數據API，徹底掌控您的數據，基於諸葛io靈活擴展：

除此以外，細緻入微的產品設計，貫穿分析過程，例如：
點擊數字到用戶畫像的洞察；
漏斗的無序和有序；
用戶羣「新增後X天」；
還有更多的場景，能夠去感覺和體驗；
這樣一來，回到剛剛的圖片：

咱們在建模時很是抽象，而且基於獨立用戶跟蹤了整個業務的流程，因此不僅是指標任意的配置可視化，不少之前依賴於SQL和清洗代碼的邏輯，也變成了交互式的查詢組件，因此能提升效率，那咱們是怎麼作到的呢？先來看看咱們總體的架構：

首先看看數據採集端，咱們提供豐富的接口和SDK，可以採集到企業各個有用戶行爲數據的地方，目前來說，主要分爲如下：

Android客戶端 ： Android SDK
iOS客戶端 ： iOS SDK
網站或微站H5 ：Javascript SDK
小程序：小程序SDK
日誌:：服務端Restful接口
CRM數據庫 ：導入工具

也就是採用了「PUSH」模式，各個端採集用戶的行爲，而後再按照規則發送給咱們的數據收集中心，各個端也就寫了一些SDK，讓開發者調用採集，而後就是咱們的數據收集端:

上圖是咱們的數據收集架構: 核心就是LVS+Nginx+Lua，咱們沒有用比較重的後端語言來採集，而是選擇了比較輕的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把基於數據倉庫的SQL查詢訪問抽象了一層服務，分爲對內和對外兩部分，用以控制對數據訪問的統一管理。主要分爲兩部分：

對內是經過統一的API服務來進行訪問
對外是有Open API的開放平臺

可視化查詢在諸葛主要是經過諸葛io的網站進行完成，而且在技術上也是基於數據訪問層實現。可視化在諸葛主要分爲兩部分：

1. 數據指標展示的可視化

2. 查詢操做的可視化

指標展示可視化，包括不限於表格、柱狀圖、線圖、漏斗。回到整個架構上：

能夠看到有消息中心，諸葛io的消息中心是以Kafka爲中心進行設計的。

消息中心主要處理包含如下業務消息的聚集和分發：

各類SDK或者工具上傳的數；
數據清洗產生的中間的數據；
模型結果數據；
備份數據；
其餘流式處理數據；

Kafka具備多消費組的特色，也就意味着，咱們能夠在不一樣應用場景下對統一數據進行多種處理，併產生多種應用，例以下面場景：

咱們收集到各類數據，並會添加到Kafka消息中心，而後會有如下不一樣消費應用：

進行元數據統計管理
進行備份
進入數據倉庫模型前的清洗
進行實時的統計計算;

實時計算中心，咱們用的是Spark Streaming進行處理，也有其餘套件輔助咱們進行一些數據挖掘，實時數據和關係緩存，咱們用的是Codis以及SSDB，Codis是分佈式的Redis實現框架（由前豌豆莢團隊開源）咱們會用來作分佈式的消息以及狀態存儲，而SSDB是基於Redis協議的硬盤實現（做者是懶投資的CTO吳總）咱們會存儲一些鍵值比較大或者多的數據，例如實時數據以及數據緩存。

基礎存儲剛剛講過了主要是S3，索引用的是Elasticsearch，好比查詢時的提示等等，在線多維實時數據處理查詢就是Redshift和Greenplum了，而後咱們統一了整個數據訪問層以及API，而且分爲內部和外部API，對外就是網站和開放平臺了。