萬師傅使用雲產品，上手簡單、開箱即用、省去運維煩惱

雲棲號案例庫： 【點擊查看更多上雲案例】 不知道怎麼上雲？看雲棲號案例庫，瞭解不一樣行業不一樣發展階段的上雲方案，助力你上雲決策！

總體架構

---

每當我在思考技術選型方案的時候，翻翻阿里雲的官網，總能找到我想要的東西。因而，咱們的大數據體系就變成了這樣，如圖：

離線

---

2.1 選型原則

團隊成員，大都是Hive方向或是算法方向出身。爲追求上手簡單、專一數據的分析和挖掘、減小沒必要要的學習成本和費用成本，使用了阿里雲MaxCompute。

2.2 數據採集

數據源共包含三類：

（1）關係型數據庫中的數據； （2）服務器上的日誌文件； （3）前端埋點日誌；

採集方式如圖：

關係型數據庫中的數據，使用dataworks中的「數據集成」功能，定時離線同步到MaxCompute中； 其餘兩類數據，以及關係型數據庫的Binlog，直接使用了萬能的「日誌服務SLS」。WebTracking支持直接收集HTML、H五、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/

本文爲阿里雲原創內容，未經容許不得轉載。