一、
除了日誌數據，關係數據庫中的數據也是數據分析的重要來源。在數據的採集方式上，用Spark實現類 Sqoop 的分佈式抓取替代了早期定期用單機全量抓取 MySQL 數據表的方式，有效的提升了抓取速度，突破了單機瓶頸。
再之後爲了減少MySQL壓力，選用Canal來接收MySQL binlog，離線 merge 出全量表，這樣就不再直接讀 MySQL了，而且對千萬/億級大表的處理速度也會更快。
二、數據傳輸——Kafka做消息總線連接在線和離線系統
數據在客戶端向服務端回傳或者直接在服務端產生時，可以認爲是在線狀態。當數據落地到統計分析相關的基礎設施時，就變成離線的狀態了。在線系統和離線系統採用消息隊列來連接。
數據傳輸以Kafka作爲數據總線，所有實時和離線數據的接入都要通過 Kafka，包括日誌、binlog等。這裏值得注意的是：儘早引入消息隊列，與業務系統解耦。
因爲以目前的數據和集羣規模，直接使用社區版本乃至企業版的產品，都會遇到大量困難。像數據接入，就使用自研 Databus，作爲單機 Agent，封裝 Kafka 寫入，提供異步寫入、buffer、統一配置等 feature。
Kafka 數據通過 Dump 落地到 HDFS，供後續離線處理使用。隨着數據規模的增加，Dump 的實現也經歷了幾個階段。最初實現用的是類似 Flume 模式的單機上傳，很快遇到了瓶頸，實現改成了通過 Storm 來實現多機分佈式的上傳，支持的數據吞吐量大幅增加。
現在開發了一個服務，作爲託管服務方便整合到平臺工具上，底層實現切換到了 SparkStreaming，並實現了 exactly-once 語義，保證 Dump數據不丟不重。
三、數據入庫—數據倉庫、ETL
數據倉庫中數據表的元信息都放在 Hivemetastore 裏，數據表在 HDFS 上的存儲格式以Parquet爲主，這是一種列式存儲格式，對於嵌套數據結構的支持也很好。
有多種 ETL 的實現模式在並存，對於底層數據構建，一種選擇是使用 Python 通過 HadoopStreaming 來實現 Map Reduce 的任務，但現在更傾向於使用 Spark 直接生成 Parquet 數據，Spark 相比 MapReduce 有更豐富的處理原語，代碼實現可以更簡潔，也減少了中間數據的落地量。對於高層次的數據表，會直接使用 HiveSQL 來描述 ETL 過程。
四、數據計算——計算引擎的演進
數據倉庫中的數據表如何能被高效的查詢很關鍵，因爲這會直接關係到數據分析的效率。常見的查詢引擎可以歸到三個模式中：Batch 類、MPP 類、Cube 類。
Hive是一個很穩定的選擇，但速度一般。
爲了更好的支持 Adhoc 交互式查詢，調研 MPP 類查詢引擎，先後使用過 Impala 和 Presto，但在超大數據量級下都遇到了穩定性的問題。
現在的方案是混合使用 Spark SQL 和 Hive，並自研 查詢分析系統，自動分析並分發查詢 SQL 到適合的查詢引擎。在Cube類查詢引擎上，採用了Kylin。