Spark+Hbase 億級流量分析實戰（日誌存儲設計）

背景

接着上篇文章 百億級流量實時分析統計 - 數據結構設計 咱們已經設計好了日誌的結構，接下來咱們就準備要開始擼代碼了，我最喜歡這部分的環節了，但是一個上來連就擼代碼的程序確定不是好程序員，要不先設計設計流程圖？那來吧！！！

流程圖

設計一

1. 用戶發起文章操做，發起請求日誌
2. 日誌將由SLB服務器進行負載到日誌打點服務器。
3. NSA將做爲日誌收集中心進行存儲，也能夠使用rsync把節點上的日誌同步到日誌中心。
4. 做爲核心的ETL程序，將要對日誌中心上全部節點的數據進行抽取轉換加載。
5. 上圖中出現的Hbase比較好理解，可是爲何要出現Mysql？由於咱們要更細粒度地控制日誌的寫入時間點，主要用來記錄日誌時間的offset，後續會有詳細的介紹。

設計二

1. 用戶發起文章操做，發起請求日誌
2. 日誌將由SLB服務器進行負載到日誌打點服務器。
3. Filebeat 收集節點日誌 到Kafka，主要是用來日誌削峯使用。 **或者：**使用nginx直接將日誌寫入kafka,由於nginx也是生產級別的。
4. ETL 將消費Kafka 數據並寫到Hbase。
5. 與設計一相同

日誌中心

日誌中心的存儲會是下面這樣

├── log
│   ├── 2019-03-21
│   │   ├── 111.12.32.11
│   │   │   ├── 10_01.log
│   │   │   └── 10_02.log
│   │   ├── 222.22.123.123
│   │   │   ├── 0_01.log
│   │   │   ├── 0_02.log
│   │   │   └── 0_03.log
│   │   └── 33.44.55.11
│   ├── 2019-03-22
│   └── 2019-03-23
複製代碼

1. 每分鐘每節點會生成一個文件。
2. 一天一個文件夾。
3. 這樣子的設計能夠方便查錯。

日誌內容以下

{"time":1553269361115,"data":{"type": "read","aid":"10000","uid":"4229d691b07b13341da53f17ab9f2416","tid": "49f68a5c8493ec2c0bf489821c21fc3b","ip": "22.22.22.22"}}
{"time":1553269371115,"data":{"type": "comment","content":"666,支持一下","aid":"10000","uid":"4229d691b07b13341da53f17ab9f2416","tid": "49f68a5c8493ec2c0bf489821c21fc3b","ip": "22.22.22.22"}}
複製代碼

敲定方案

選擇設計一 由於咱們就看上了第5點,在線上業務穩定了一年的使用狀況來看，這種方案是可行的。

在下篇文章中，咱們將真實開始擼咱們的黃金代碼了，全部程序將使用scala進行實現，你想問我什麼嗎？四個字：

---