整體架構
每當我在思考技術選型方案的時候，翻翻阿里雲的官網，總能找到我想要的東西。於是，我們的大數據體系就變成了這樣，如圖：
離線
2.1 選型原則
團隊成員，大都是Hive方向或是算法方向出身。為追求上手簡單、專注數據的分析和挖掘、減少不必要的學習成本和費用成本，使用了阿里雲MaxCompute。
2.2 數據採集
數據源共包含三類：
（1）關係型資料庫中的數據；（2）伺服器上的日誌文件；（3）前端埋點日誌；
採集方式如圖：
關係型資料庫中的數據，使用dataworks中的「數據集成」功能，定時離線同步到MaxCompute中；其他兩類數據，以及關係型資料庫的Binlog，直接使用了萬能的「日誌服務SLS」。WebTracking支持直接收集HTML、H5、iOS和 Android的日誌；Logtail支持收集伺服器上的日誌文件，以及關係型資料庫的Binlog。數據都收集過來之後，再定時將數據投遞到MaxCompute中；如上兩個步驟，完成了三類數據的收集。比業界常見的Flume+Kafka、Kettle、Logstash等方式，上手更快、維護更簡單。
2.3 數據倉庫
2.3.1 分層
數據倉庫的分層模型，大體的思路和網上爛大街的數倉分層原則相似，總體分ODS、DW、RPT三層。具體實踐的過程中，根據我們的實際情況，慢慢形成了我們自己的風格。
ODS層，大部分是和數據源中的數據一模一樣的，也有極少部分經過了簡單的ETL、或者只截取了與統計有關的欄位。數據已採用了其他備份方式，所以這裡不再需要使用MaxCompute做冷備。
DW層是最核心的數據倉庫層。由於公司技術正在朝著微服務轉型，系統、資料庫拆分得越來越細，對數據的統計分析很不利。所以我們依靠數據倉庫層，將相關的數據放到一起，便於上層的開發、更有利於日常的臨時數據需求的快速響應。數據倉庫層的數據結構，不會隨著微服務系統和數據的拆分而變化，讓系統拆分對於這套離線數據分析的影響終結在這一層，不滲透到更上層。
RPT層的具體做法，市面上有很多種。根據我們的實際情況，決定採用按業務劃分的方式。曾經我們也嘗試過按數據產品劃分，但是時間長了，出現了幾個嚴重的問題。首先，不同數據產品中對於相同指標的定義混亂，導致各個部門對於數據沒有一個統一的概念。其次，技術上的系統拆分的影響範圍，隨著數據產品的增多而大面積擴大，極易出現修改遺漏的現象。
2.3.2 DATAWORKS
配套MaxCompute一起使用的Dataworks，是一個全能型的可視化工具，集成了幾乎一切我們使用MaxCompute時所需要配套的功能，也解決了很多開源產品中無法解決的痛點，例如：可視化調度、智能監控告警、數據權限控制等。
實際使用時，我們的數據在MaxCompute中的流轉，全部是通過MaxCompute SQL節點和機器學習節點進行的。定時依賴+調度依賴+跨周期依賴，也讓方案的設計變得更靈活。
業務流程是按實際業務模塊劃分、沒有按照數據產品劃分，這樣可以解決「找任務難」、「不同團隊對相同指標的定義不一致」等問題。當某個業務有變更時，可以快速定位到需要配合修改的任務都有哪些，有效地避免了遺漏。
技術文檔的同步更新一直是業界難以解決的痛點，數據字典也不例外。按照業務模塊劃分了之後，在新增指標時，更容易發現是否已有相同或相似的指標，即使數據字典更新不及時也不會有大影響。
實時
3.1 選型原則
團隊初始成員均為Java出身，並且我們當前沒有、未來也不準備擁有自己的Hadoop集群。綜合考慮，採用了阿里開源的JStorm作為核心的流式計算引擎，同時也在嘗試業界最新的Flink，為未來做準備。至於沒有使用阿里雲商業版的「實時計算」，完全是出於成本考慮，在我們的場景下，自建JStorm集群的成本會遠低於使用「實時計算」。
與核心的流式計算引擎相配套的中間件及數據存儲，使用的全部都是阿里雲的產品，開箱即用、省去運維煩惱。
3.2 實踐
3.2.1 消息隊列
消息隊列類的產品，主要使用了「日誌服務SLS」和「消息隊列RocketMQ」兩種。
「日誌服務SLS」這款產品，大於等於開源組合ELK，不僅有日誌採集、搜尋引擎、分析展示，還有消息隊列、監控告警等功能，價格也很合理。尤其，這幾個功能的組合，可以輕鬆實現業務日誌告警、nginx監控等等使用傳統方式要開發很久的需求。如果單純作為消息隊列使用，還可以關閉索引，以節省費用。
「消息隊列RocketMQ」的使用，主要看中了「定時延時消息」這一功能，可以實現很多定時延時任務的需求場景。
3.2.2 緩存
Redis，不需要過多介紹。
3.2.3 資料庫
阿里雲包含了非常多的資料庫類產品，根據我們的實際需求，主要使用了以下幾款：
（1）RDS for MYSQL，與MYSQL一致，不需要過多介紹；（2）PolarDb，阿里雲自研的雲原生資料庫，與RDS價格一致。對於我們使用者來說，它是一個可以支持更高讀並發、單實例容量更大的MYSQL。可以幫助我們建立離線數據中心，也解決了「所有資料庫的查詢都要先經過Redis緩存」的問題，節省了少量Redis的費用；（3）TableStore，這款產品的初衷應該是想要對標開源的HBase，主要用於單一索引、龐大數據量、單條或小範圍檢索、高並發、低延時的查詢場景。在單條查詢時，性能幾乎可以媲美Redis，而且也擁有TTL功能。被我們大量使用在用戶畫像、冪等校驗等場景中；其他產品，例如DRDS、AnalyticDb，或MongoDb、Elasticsearch等，由於目前的場景不需要，所以沒有投入使用。
數據展示
4.1 選型原則
前端產品的選型原則很簡單，由於我們的團隊沒有專門的前端開發，所以只能選擇阿里雲的產品、或者免費的、可對接的開源產品。
4.2 實踐
- 阿里雲的可視化產品主要有兩個：QuickBI和DataV。我們都在使用。
- QuickBI主要用於日常的數據展示、分析，幫助運營、產品等部門進行決策；
- DataV主要用於「非交互式」的數據展示場景，例如展會、大屏等。
查看更多：https://yqh.aliyun.com/detail/6520
上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/