離線日誌採集流程
步驟一：
| 我們的資料從哪裡來？ 網際網路行業：網站、app、系統（交易系統。。） 傳統行業：電信，人們的上網、打電話、發簡訊等等資料
資料來源：網站、app
都要往我們的後臺去傳送請求，獲取資料，執行業務邏輯；app獲取要展現的商品資料；傳送請求到後臺進行交易和結賬 |
連線線（網站/app會發送請求到後臺伺服器，通常會由Nginx接收請求，並進行轉發）
步驟二：
| 後臺伺服器，比如Tomcat、Jetty；但是，其實在面向大量使用者，高併發（每秒訪問量過萬）的情況下，通常都不會直接是用
比如說，Nginx，或者是Tomcat，你進行適當配置之後，所有請求的資料都會作為log儲存起來；接收請求的後臺系統（J2EE、PHP、Ruby On Rails），也可以按照你的規範，每接收一個請求，或者每執行一個業務邏輯，就往日誌檔案裡面打一條log。 |
連線線（到這裡為止，我們的後臺每天就至少可以產生一份日誌檔案，這個是沒有疑問了）
步驟三：
| 日誌檔案（通常由我們預先設定的特殊的格式）通常每天一份。此時呢，由於可能有多份日誌檔案，因為有多個 |
連線線（一個日誌轉移的工具，比如自己用linux的crontab定時排程一個shell指令碼/python指令碼；或者自己用java開發一個後臺服務，用quartz這樣的框架進行定時排程。這個工具，負責將當天的所有日誌的資料，都給採集起來，進行合併和處理，等操作；然後作為一份日誌檔案，給轉移到flume agent正在監控的目錄中。）
步驟四：
| flume，按照我們上節課所講的；flume agent啟動起來以後，可以實時的監控linux系統上面的某一個目錄，看其中是否有新的檔案進來。只要發現有新的日誌檔案進來，那麼 |
連線線（flume負責將每天的一份log檔案，傳輸到HDFS上）
步驟五：
| HDFS，Hadoop Distributed File System。Hadoop分散式檔案系統。用來儲存每天的log資料。為什麼用hadoop進行儲存呢。因為Hadoop可以儲存大資料，大量資料。比如說，每天的日誌，資料檔案是一個T，那麼，也許一天的日誌檔案，是可以儲存在某個Linux系統上面，但是問題是，1個月的呢，1年的呢。當積累了大量資料以後，就不可能儲存在單機上，只能儲存在Hadoop大資料分散式儲存系統中。 |
連線線（使用Hadoop MapReduce，自己開發MR作業，可以用crontab定時排程工具來定時每天執行一次；也可以用Oozie來進行定時排程；也可以（百度、阿里、騰訊、京東、美團）自己組建團隊來研發複雜、大型、分散式的排程系統，來承擔全公司所有MapReduce / Hive作業的排程（對於大型公司來說，可能每天除了負責資料清洗的MR作業以外，後續的建立資料倉庫、進行資料分析和統計的Hive ETL作業可能高達上萬個，上十萬、百萬個），針對HDFS裡的原始日誌進行資料清洗，寫入HDFS中另外一個檔案）
步驟六：
| Hadoop HDFS中的原始的日誌資料，會經過資料清洗。為什麼要進行資料清洗？因為我們的資料中可能有很多是不符合預期的髒資料。
HDFS：儲存一份經過資料清洗的日誌檔案。 |
連線線（把HDFS中的清洗後的資料，給匯入到Hive的某個表中。這裡可以使用動態分割槽，Hive使用分割槽表，每個分割槽放一天的資料。）
步驟七：
| Hive，底層也是基於HDFS，作為一個大資料的資料倉庫。資料倉庫內部，再往後，其實就是一些資料倉庫建模的ETL。ETL會將原始日誌所在的一個表，給轉換成幾十張，甚至上百張表。這幾十，甚至上百張表，就是我們的資料倉庫。然後呢，公司的統計分析人員，就會針對資料倉庫中的表，執行臨時的，或者每天定時排程的Hive SQL ETL作業。來進行大資料的統計和分析。 |
連線線（Spark/Hdoop/Storm，大資料平臺/系統，可能都會使用Hive中的資料倉庫內部的表）
步驟八：
| 我們的Spark大型大資料平臺/系統（比如我們這套課程要講解的這個），其實，通常來說，都會針對Hive中的資料來進行開發。也就是說，我們的Spark大資料系統，資料來源都是Hive中的某些表。這些表，可能都是經過大量的Hive ETL以後建立起來的資料倉庫中的某些表。然後來開發特殊的，符合業務需求的大資料平臺。通過大資料平臺來給公司裡的使用者進行使用，來提供大資料的支援，推動公司的發展。 |