轉載於：扎心了，老鐵

我們的資料從哪來？

網際網路行業：網站、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。
flume負責講每天的日誌傳輸到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以後建立起來的資料倉庫，然後進行特殊的、符合業務需求的大資料平臺。通過大資料平臺來給公司的使用者使用，來提供大資料的支援，推動公司的發展。