大數據架構
- 源數據層(原始數據存儲位置)
sdk日志埋點
日志文件：爬蟲日志、業務日志
關系型數據庫：mysql,oracle等
- 數據采集層(抽取源數據至數據存儲層)
離線：flume、Sqoop、Nifi
實時：filebeat、nginx+lua
補充：當數據量達到5億左右的時候，filebeat+logstash采集數據到hdfs，數據會出現丟失的情況，所以此種方案不適合用於大數據存儲到hdfs
- 數據存儲層
hdfs用於存儲離線大數據量
kudu用於存儲mysql關系數據庫更新變化的數據
es存儲一些log日志，比如說我們需要快速的定位某一個業務的log情況
kafka作為消息中間件，存儲filebeat或者是flume采集的日志
- 數據分析層（進行數據分析）
es,分析一些log
hive用於分析一些離線大數據（基於磁盤IO分析）
impala、presto 適用於分析一些准實時日志（要求快速出數據，基於內存分析）
spark core+spark sql 適用於分析一些離線數據，自定義解析規則
spark streaming 適用於分析一些實時（不是完全實時）數據
flink,jstorm 用於分析完全實時的數據
- 數據調度層（對數據分析任務進行調度）
airflow 適用大集群，阿里的調度系統就是根據airflow二次開發，配置復雜,python 腳本實現
azkaban :cpu和內存要求不高，主從配置支持的不算太好，適用於小集群，以job的文件實現，配置簡單
oozie：通常hue集成，單獨的使用oozie的情況下，配置復雜，不建議使用，所有的任務都是以mr形式進行的，可支持復雜的依賴調度
jobX: cpu使用高，bug還沒修復，所以造成agent的cpu維持在一個左右，配置簡單，只支持依賴調度，並行調度不支持。
crontab：一般用於每分鍾調度一次的任務，不支持依賴調度，並行調度（配置復雜，通過腳本自定義控制），沒有可視化界面，不能准確的判斷任務是否成功或者是失敗
NIFI: 不但支持任務調度，還支持ETL
自定義，公司自己開發使用的
- 數據同步層（調度任務，執行完畢后，還要寫入應用程序中。采用sqoop等將數據同步到mysql（olap存儲層）中）
sqoop 用的是1.x系列版本
datax
kettle
NIFI
- 數據olap存儲層
mysql es tidb redis hbase clickhouse
有時間的話研究tidb和clickhouse
- 數據展示層（展示mysql中的數據）
PowerBI,帆軟等BI可視化工具。
技術選型
實時分析
可以使用lua或者filebeat將nginx數據采集到kafka，數據經過spark streaming或者是jstorm進行分析后，盡可能的存入一些高吞吐量的數據庫（非關系型，redis,hbase），但是有時必須要存入一些關系型數據庫，比如說mysql。
但是spark streaming發現僅僅通過一個map操作，每個執行的batch 期間，就超過了我們所設置的batch時間，這時候我們需要一個措施。
增加一個緩沖層，不直接mysql或者是redis,先寫入kafka(消息中間件)，然后通過kafka推送到獨立的寫入服務，這樣會發現實時處理服務的時間明顯的降低。
離線分析
-- 采集這塊用flume的tailf形式，或者使用sqoop和NIFI
-- 數據分析使用Hive，SparkSql,數據存儲用HDFS
-- 最終將數據導出到mysql等常用的關系型數據庫當中。
組件版本號
Cloudera Manager: 6.2.1
CDH: 6.2.1
Hadoop:3.0.0-cdh6.2.1
HBase:2.1.0-cdh6.2.1
Hive:2.1.1-cdh6.2.1
Kafka:2.1.1-cdh6.2.1
Kudu:1.9.0-cdh6.2.1
Oozie:5.1.0-cdh6.2.1
Spark:2.4.0-cdh6.2.1
Sqoop:1.4.7-cdh6.2.1
Zookeeper:3.4.5-cdh6.2.1