數據采集的重要性故善戰(zhàn)者，立于不敗之地，而不失敵之敗也?！惹蟛粩《笄髣贁祿治龅母词菙祿?，構建好數據源是為數據分析的打好根基。——數據采集是基礎數據采集的挑戰(zhàn)傳統(tǒng)數據源對數據采集支持較差：業(yè)務數據庫是為了支撐業(yè)務，數據表關聯復雜，且一般針對高并發(fā)及低延遲的小操作進行設計；Web日志往往是為了方便業(yè)務調試來做。數據團隊與業(yè)務團隊配合困難：數據分析讓路產品升級；對于業(yè)務團隊而言，數據采集屬于額外工作。數據采集遵循法則大全細時海量數據，包括業(yè)務的各個角度。按需求將不同維度的數據都進行采集。多種數據源，全量數據，全面覆蓋。強調時效性，實時采集保障分析價值。常用數據采集的手段埋點——用戶行為數據采集ETL——系統(tǒng)業(yè)務數據整合網絡爬蟲——互聯網數據采集ApacheFlume——日志數據采集ApacheKafka——數據分發(fā)中間件其他常用數據采集的手段埋點——用戶行為數據采集ETL——系統(tǒng)業(yè)務數據整合網絡爬蟲——互聯網數據采集ApacheFlume——日志數據采集ApacheKafka——數據分發(fā)中間件其他埋點什么是埋點？埋點：在正常的業(yè)務邏輯中，嵌入數據采集的代碼。埋點方法的來源：早期的網站統(tǒng)計，往往只能收集頁面的打開；通過谷歌分析定義好的可擴展接口，編寫少量javascript代碼實現自定義事件和自定義指標的跟蹤和分析。埋點埋點優(yōu)勢：數據是手動編碼產生的，易于手機，靈活性大，擴展性強。埋點劣勢：必須十分清楚目標，即需要收集什么樣的數據必須提前確定；容易發(fā)生漏埋現象；產品迭代過程中，忽略了埋點邏輯的更改。埋點埋點方式有哪些？無埋點：“全部采集，按需選取”；在產品中嵌入SDK，做個統(tǒng)一埋點，一般用于采集APP的用戶行為。代碼埋點：前端代碼埋點和后端代碼埋點。更適合精細化分析的場景，采集各種細粒度數據。埋點基于無埋點技術的第三方統(tǒng)計工具無埋點優(yōu)勢：技術門檻低，部署使用簡單；用戶友好性強；收集的是全量數據，不會出現漏埋、誤埋等現象。無埋點劣勢：適用通用場景、標準化采集，自定義屬性采集覆蓋不了；采集全量數據，給數據傳輸和服務器增加壓力；兼容性有限等。埋點埋點采集數據的過程需求收集和分析確定場景和目標針對需求制訂數據采集規(guī)劃方案埋點采集數據的具體實施數據質量的評估及數據分析設計優(yōu)化方案實施優(yōu)化方案評估解決方案的效果重點環(huán)節(jié)：梳理產品，清晰產品的脈絡和架構收集統(tǒng)計，明確統(tǒng)計目的和意義收集事件，設置事件的參數和參數值數據團隊與開發(fā)團隊的溝通埋點常用app數據分析工具GrowingIO百度移動統(tǒng)計神策分析騰訊移動分析谷歌GA未來的王牌職位——首席增長官常用數據采集的手段埋點——用戶行為數據采集ETL——系統(tǒng)業(yè)務數據整合網絡爬蟲——互聯網數據采集ApacheFlume——日志數據采集ApacheKafka——數據分發(fā)中間件其他ETL(Extract-Transform-Load)什么是ETL？ETL：用來描述將數據從來源端經過抽?。╡xtract）、轉換（transform）、加載（load）至目的端的過程。ETL是將業(yè)務系統(tǒng)的數據經過抽取、清洗轉換之后加載到數據倉庫的過程，目的是將企業(yè)中的分散、零亂、標準不統(tǒng)一的數據整合到一起，為企業(yè)的決策提供分析依據。是BI的重要一環(huán)，在BI項目中占至少三分之一的時間。ETL(Extract-Transform-Load)ETL的設計分為三部分：數據的抽取、數據的清洗轉換、數據的加載。花費時間最長的是Transform（清洗轉換）部分，一般情況下是整個ETL的2/3。ETL常用的三種實現方法：借助ETL工具；SQL方式實現；ETL工具和SQL相結合。ETL工具解決的問題：數據來自不同物理主機、數據來自不同數據庫或者文件、異構數據處理等。ETL——數據抽取數據抽?。喊言磾祿槿〉綌祿}庫中，為處理及展示奠定基礎。需要思考的問題：數據來自哪些業(yè)務系統(tǒng)？各個業(yè)務系統(tǒng)的使用哪種DBMS？是否存在外部數據，數據量有多大？是否存在非結構化的數據？如何實現增量抽??？ETL——數據轉換數據轉換：對數據進行清洗，進行一些業(yè)務規(guī)則的計算和聚合，針對數據倉庫進行數據轉換。需要思考的問題：空值處理，規(guī)范化數據格式，拆分數據，數據驗證，統(tǒng)一數據標準，數據粒度的轉換，商務規(guī)則的計算，等等。ETL——數據加載數據加載：把清洗好的數據加載到數據倉庫中，服務后續(xù)使用，或者進行可視化展示。需要思考的問題：明確所執(zhí)行操作的類型；明確需要加載的數據量；設計加載數據的最佳方法。ETL(Extract-Transform-Load)常用的ETL工具Kettle：一款國外開源的etl工具，純java編寫，數據抽取高效穩(wěn)定(數據遷移工具)。Apatar：開源ETL項目，模塊化架構，支持所有主流數據源，提供靈活的基于GUI、服務器和嵌入式的部署選項。Scriptella：一個開源的ETL工具和一個腳本執(zhí)行工具，支持跨數據庫的ETL腳本。ETLAutomation：提供了一套ETL框架，重點是提供對ETL流程的支持。常用數據采集的手段埋點——用戶行為數據采集ETL——系統(tǒng)業(yè)務數據整合網絡爬蟲——互聯網數據采集ApacheFlume——日志數據采集ApacheKafka——數據分發(fā)中間件其他網絡爬蟲網絡爬蟲：是一種按照一定的規(guī)則，自動抓取萬維網信息（網頁）的程序或者腳本。為搜索引擎從萬維網上抓取網頁，是搜索引擎的重要組成部分。搜索引擎基本框架網絡爬蟲網絡爬蟲可分為通用網絡爬蟲和聚焦網絡爬蟲通用網絡爬蟲基本工作流程1.選取部分種子URL放入待抓取隊列。2.取出待抓取URL，進行相應處理。3.將處理過的URL，放入已抓取隊列。4.將未處理過的新URL，放入待抓取隊列。網絡爬蟲網絡爬蟲可分為通用網絡爬蟲和聚焦網絡爬蟲聚焦網絡爬蟲基本工作流程與通用爬蟲相比，通過增加新模塊實現有目的地爬取。新增：目標的定義、無關鏈接的過濾、下一步要爬取的URL地址選取。網絡爬蟲網絡爬蟲視角下的網頁：處理完的待處理的可以被爬取的無法爬取下載的網絡爬蟲網絡爬蟲的抓取策略：深度優(yōu)先遍歷策略：從起始頁開始，一個個鏈接跟蹤下去。寬度優(yōu)先遍歷策略：抓取當前網頁中鏈接的所有網頁，再從待抓取隊列中選取下一個URL。反向鏈接數策略：反向鏈接數是指一個網頁被其他網頁鏈接指向的數量。使用這個指標評價網頁的重要程度，從而決定抓取先后順序?；趦?yōu)先級計算的策略：針對待抓取網頁計算優(yōu)先級值，通過排序來確定抓取順序。如：PartialPageRank，OPIC等。大站優(yōu)先策略：對于待抓取隊列中的所有網頁，根據所屬的網站進行分類，對于待下載頁面數多的網站優(yōu)先下載。網絡爬蟲網站往往是實時更新的，在網頁更新后，需要對網頁進行重新爬取。問題——什么時候更新合適？定期更新策略歷史參考策略：在網頁的歷史更新數據基礎上，利用建模等手段，預測網頁下一次更新的時間，確定爬取周期。用戶體驗策略：依據網頁多個歷史版本的內容更新、搜索質量影響、用戶體驗等信息，來確定爬取周期。聚類分析策略：首先對海量的網頁進行聚類分析，每個類中的網頁一般具有類似的更新頻率。通過抽樣計算，確定針對每個聚類的爬行頻率。網絡爬蟲網絡爬蟲系統(tǒng)架構：往往是一個分布式系統(tǒng)。主從式系統(tǒng)架構負責網頁下載工作維護待抓取URL隊列負責爬取工作分發(fā)負責Slave負載調節(jié)網絡爬蟲網絡爬蟲系統(tǒng)架構：往往是一個分布式系統(tǒng)。對等式系統(tǒng)架構所有服務器分工相同獲取URL計算主域名的hash值計算Hmodm的值得到處理該URL的主機編號思考：是否存在問題？網絡爬蟲網絡爬蟲系統(tǒng)架構：往往是一個分布式系統(tǒng)。對等式系統(tǒng)架構基于一致性哈希運算，將URL的主域名映射為一個指定范圍內的某個數。根據事先的分配策略，判斷由哪臺服務器來進行抓取該URL。網絡爬蟲一致性哈希算法：1997年由麻省理工學院提出把服務器通過hash算法映射到環(huán)上；把URL通過hash算法映射到環(huán)上，按順時針方向找到處理該URL的服務器服務器增刪，對系統(tǒng)影響較小，架構擴展性強一般被用來解決分布式系統(tǒng)中負載均衡的問題常用數據采集的手段埋點——用戶行為數據采集ETL——系統(tǒng)業(yè)務數據整合網絡爬蟲——互聯網數據采集ApacheFlume——日志數據采集ApacheKafka——數據分發(fā)中間件其他Flume什么是Flume？分布式、可靠、和高可用的海量日志采集、聚合和傳輸的日志收集系統(tǒng)。由Cloudera公司開源，連接數據源和數據存儲系統(tǒng)的管道，屏蔽數據源和數據存儲系統(tǒng)異構性的中間件。Flume-OG(originalgeneration)：初始發(fā)行版本Flume-NG(nextgeneration)：重構后的版本，被Apache納入旗下FlumeFlume-OG基本架構Agent：代理節(jié)點，從各個數據源收集日志數據Collector：收集節(jié)點，收集來自各個代理的日志數據，匯總至存儲節(jié)點。Master：主節(jié)點，負責管理agent和collector的活動Agent與Collector都稱為node，由source、sink組成，數據是從source傳送到sink。Flume基于Flume-OG的美團日志收集系統(tǒng)每個機器部署一個進程，負責單機的日志收集部署在中心服務器上，負責接收日志，并根據規(guī)則寫到相應的存儲層提供永久或者臨時的日志存儲服務，或者將日志流導向其它服務器。FlumeFlume-NG基本架構外部（Client）數據，發(fā)送Event到SourceSource捕獲Event，進行特定格式化，再把Event推入單個或多個Channel中Channel可以看作是一個緩沖區(qū)，保存Event直到Sink處理完Sink負責將Event傳輸到下一跳或最終目的地，成功完成后將Event從Channel移除FlumeFlume-NG核心概念Event：Flume數據傳輸的基本單元，由可選的header和載有數據的bytearray構成，bytearray可以攜帶日志數據。Client：將原始日志文件包裝成Events并發(fā)送它們到一個或多個Agent實體，由獨立的線程運行。Agent：Flume的運行實體，包含Source,Channel,Sink等組件。利用這些組件將Events從一個節(jié)點傳輸到另一個節(jié)點或最終目的地。每臺機器運行一個Agent。Source：負責接收Event或通過特殊機制產生Event，并將Events批量的放到一個或多個Channel。Channel：連接Source和Sink，類似event的緩存隊列。Sink：接收Event，進行下一步轉發(fā)。FlumeFlume-OGV.SFlume-NGFlume-OG有三種角色的節(jié)點，Flume-NG只有一種角色節(jié)點，降低臃腫性，更加靈活。在OG版本中，Flume的使用穩(wěn)定性依賴zookeeper；而在NG版本中，不再需要zookeeper對各類節(jié)點進行協(xié)調。在Flume-NG中，agent節(jié)點的組成也發(fā)生了變化，由source、sink、channel組成。FlumeFlume拓撲結構多Agent串聯：前一個Agent的Sink和下一個Agent的Source相連，Sink指向Source的主機名（或IP地址）和端口。一般情況下，應該控制這種順序連接的Agent的數量。FlumeFlume拓撲結構單Source，多Channel、Sink：并行配置多個Channel，Sink與Channel一一對應，通過不同的Sink將數據發(fā)送到不同的地方。也稱為多級流模式FlumeFlume拓撲結構聚合模式：每個集群都會產生日志文件，為了將每個日志文件進行收集，就采用該模式。每個節(jié)點都配置一個Agent來單獨收集日志數據，數據最終匯聚到一個對接存儲系統(tǒng)的Agent上。FlumeFlume拓撲結構Agent1可看成是一個路由節(jié)點，將Event均衡到多個Sink組件上負載均衡模式：適用于大容量數據處理。將大容量數據拆分給多個Agent來處理。常用數據采集的手段埋點——用戶行為數據采集ETL——系統(tǒng)業(yè)務數據整合網絡爬蟲——互聯網數據采集ApacheFlume——日志數據采集ApacheKafka——數據分發(fā)中間件其他數據分發(fā)中間件前端數據采集后，需要送到后端進行分析處理。前端采集與后端處理往往是多對多的關系。之間需要數據分發(fā)中間件負責消息轉發(fā)，保障消息可靠性，匹配前后端速度差。分布式系統(tǒng)構件之間通過數據分發(fā)可以解除相互之間的功能耦合，從而減輕子系統(tǒng)之間的依賴，使得各個子系統(tǒng)或構件可以獨立演進、維護或者重用。為什么需要數據分發(fā)？數據分發(fā)中間件數據分發(fā)解決方案——消息隊列消息隊列是在消息傳輸過程中保存消息的容器或中間件，主要目的是提供消息路由并保障消息可靠傳遞。目前常見的消息隊列中間件產品包括：ActiveMQ、ZeroMQ、RabbitMQ和Kafka。一般消息中間件支持兩種模式：消息隊列模式及Pub-Sub模式。KafkaKafka：分布式發(fā)布-訂閱消息系統(tǒng)（Pub-Sub模式），最初由LinkedIn公司開發(fā)，之后成為Apache項目的一部分。具有極高的消息吞吐量，較強的可擴展性和高可用性，消息傳遞低延遲，能夠對消息隊列進行持久化保存，且支持消息傳遞的"至少送達一次"語義。Kafka架構：消息生產者：產生指定Topic(主題)的消息并將其傳到代理服務器集群。代理服務器集群：在磁盤上存儲并維護各種Topic的消息隊列。消息消費者：訂閱某個Topic，從代理服務器集群中拉取(Pull)出新產生的消息并對其進行處理。KafkaBroker和Consumer都會在Zookeeper中進行注冊，Zookeeper保障負載均衡。Kafka基本概念——Topics&PartitionTopics是消息的分類名（或Feed的名稱），一個Topic可以認為是一類消息，每個topic將被分成多個partition(區(qū))。partition是以log文件的形式存儲在文件系統(tǒng)中，任何發(fā)布到partition的消息都會被直接追加到log文件的尾部。Logs文件根據配置要求,保留一定時間后刪除來釋放磁盤空間。Partition： Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。KafkaPartition設計目的：通過分區(qū),可以將日志內容分散到多個server上,來避免文件尺寸達到單機磁盤的上限,每個partiton都會被當前server(kafka實例)保存可以將一個topic切分多任意多個partitions,來提升消息保存/消費的效率越多的partitions意味著可以容納更多的consumer，有效提升并發(fā)消費的能力基本概念——Topics&PartitionKafka基本概念——ProducerProducer將消息發(fā)布到指定的Topic中,同時Producer也能決定將此消息歸屬于哪個partition;比如基于"round-robin"方式或者通過其他的一些算法等消息和數據生產者，向Kafka的一個topic發(fā)布消息的過程叫做producers。異步發(fā)送：批量發(fā)送可以很有效的提高發(fā)送效率。Kafkaproducer的異步發(fā)送模式允許進行批量發(fā)送，先將消息緩存在內存中，然后一次請求批量發(fā)送出去。Kafka基本概念——Consumer消息和數據的消費者，訂閱相關topics，并處理Producer發(fā)布的消息。允許consumergroup（包含多個consumer）對一個topic進行消費，不同的consumergroup之間獨立訂閱。每個consumer屬于一個consumergroup；發(fā)布的消息,只會被訂閱此Topic的每個group中的一個consumer消費。同一個group中不能有多于partitions個數的consumer同時消費,否則將意味著某些consumer將無法得到消息。Kafka基本概念——BrokerBroker：緩存代理，Kafka集群中的一臺或多臺服務器統(tǒng)稱為broker。為了減少磁盤寫入的次數，broker會將消息暫時buffer起來，當消息的個數(或尺寸)達到一定閥值時，再flush到磁盤，這樣減少了磁盤IO調用的次數。Broker不保存訂閱者的狀態(tài)，由訂閱者自己保存。Broker沒有副本機制，一旦broker宕機，該broker的消息將都不可用。Kafka基本概念——MessageMessage消息：是通信的基本單位，每個producer可以向一個topic（主題）發(fā)布一些消息。Kafka中的Message是以topic為基本單位組織的，不同的topic之間是相互獨立的。每個topic又可以分成幾個不同的partition(每個topic有幾個partition是在創(chuàng)建topic時指定的)，每個par