轉載於：紮心了，老鐵

我們的數據從哪來？

互聯網行業：網站、APP、系統（交互系統）。
傳統行業：電信、上網、打電話、發短信等等。
數據源：網站、APP。
等等，這些用戶行為都回向我們的後臺發送請求各種各樣的請求，和進行各種邏輯交互、交易和結賬等等。

請求轉發

網站/APP會發送請求到後臺服務器，通常會有Nginx接受請求，然後進行轉發。

後臺服務器，例如Tomcat、Jetty

通常在面向大量用戶和高並發（每秒請求量過萬）時，都不是直接使用Tomcat來接收請求。而是使用Nginx來接收請求，並且後端介入Tomcat集群/jetty集群，來進行高並發下的負載均衡。
比如說，Nginx/Tomcat，經過適當配置之後，所有的請求數據都會以log的形式存儲起來；或者接收請求的後臺，也可以按照自己制定的的規範，沒接收一個請求或者沒執行一個邏輯，就往日誌裏發一條log。

日誌文件

日誌文件（按照我們預先設定的格式）通常每天一份，當然也可以多分日誌，因為有多個web服務器。
一個日誌轉移的工具，比如自己用Linux的crontab定時調度一個shell腳本/python腳本；或者自己用java開發一個後臺服務，用quartz這樣的架構進行定時調度。這個工具負責當天的所有日誌的數據都采集起來，進行合並和處理等操作 ，然後整合成一份日誌文件，轉移到flume agent正在監控的文件夾中。

flume 監控日誌文件

flume agent啟動之後，可以實時的監控某個指定的文件，看是否有新的文件進來。只要發現有新的日誌文件進來時，那麽flume就會走後續的channel和sink。通常來說，sink都會配置為HDFS。

日誌文件存儲在HDFS之中

因為HDFS可以用來存儲大數據。

數據清洗

HDFS中的原始日誌數據會經過清洗，因為原始數據中可能很多是不符合預期的臟數據。
使用MapReduce開發自己的MR作業，可以用crontab來定時執行，也可以用Ooize或者bat京東美團自己開發的復雜、大型、分布式的調度系統，來承擔全公司所有MapReduce/Hive作業的調度（對於大公司來說，可能每天除了負責數據清洗的MR作業之外，後續的建立數據倉庫、進行數據的統計分析的Hive ETL可能高達上萬個，上十萬個，上百萬等），針對HDFS中的原始日誌數據清洗之後，寫入HDFS的另外一個文件之中。

Hive

把HDFS清洗後的數據導入到Hive的某個表中，Hive可以使用動態分區，Hive使用分區表，每個份去放一天的數據。
Hive底層也是基於HDFS，作為一個大數據的數據倉庫。數據倉庫內部，再往後，其實就是一些數據倉庫建模的ETL。ETL會將原始日誌所在的一個表轉化為幾十個、幾百個表，這些表就是我們的數據倉庫。然後公司的統計分析人員就會根據數據倉庫中的表，執行臨時的或者每天定時的 Hive SQL ETL作業進行大數據的統計分析。
Spark/Hadoop/Storm，大數據平臺/系統可能都會采用Hive中的數據倉庫內部的表。

大數據平臺/系統

我們的大數據平臺/系統，其實通常來說，都會針對Hive中的數據進行開發。數據源都是來自Hive中的表，這些表都是經過大量的Hive SQL ETL以後建立起來的數據倉庫，然後進行特殊的、符合業務需求的大數據平臺。通過大數據平臺來給公司的用戶使用，來提供大數據的支持，推動公司的發展。

用戶行為分析之離線數據采集