数据运营平台-数据采集
目錄
行為數據采集
業務數據采集與轉換
第三方系統API對接
用戶數據關聯
人工數據采集
數據輸出
行為數據采集
1.埋點采集
①跨平臺打通
確定性方法識別
利用用戶帳號體系中，可以是系統生成的 UserID，可以是手機號，也可以是郵箱，不同的產品情況略有差異，總之就是用戶唯一的標識。 如果應用在 Android、iOS、Web、微信公眾號四個平臺上運營，各個平臺用統一的帳號體系。假如小明有Android、iOS、PC三臺設備，早上在Android 的微信公眾號上看了一個推薦的，中午登錄了網頁查看了詳細信息，晚上回家在iOS 手機上下了單，那么完全可以通過UserID將用戶行為連貫起來。
概率論方法匹配
使用設備相關的間接數據來匹配，Cookie、IDFA、上網時間、Wifi、IP 等等，通過機器學習或者其他復雜的規則來分析。但是嚴重依賴于數據的多樣性和算法，相對確定性的方法來說，準確性差距很大，不推薦。
②埋點方案設計
用戶行為是由用戶一系列的事件組成，包含5個基本要素：何人，何時，何地，通過何種方式，發生了何種行為，一份完整的埋點方案由事件、事件屬性和用戶屬性三部分組成：
事件：記錄用戶在使用網站、APP 或小程序的過程中觸發的行為。
用戶的行為有一部分會在他們使用的過程中自動被采集上來，常見的如：與訪問有關的“頁面瀏覽”，“停留時長”；另外一部分包含具體業務含義的，則需要通過埋點才能得到，例如：“注冊”、“登錄”、“支付”等等。
事件屬性：通過屬性為事件補充相關的信息，例如：位置，方式和內容。
用戶產生行為時就會上報具體的屬性值，比如對“購買事件”定義了“支付方式”的屬性值，則根據不同的行為可能上報的是微信支付，支付寶支付。
例如：在采購平臺上花十萬元購買一輛汽車。這個動作就產生一個名為“購買”的事件； 而“購買”事件，同時也可以包含：“品牌”，“價格”這兩個屬性，而“東風”和“十萬元”就是屬性的具體值了。
| Event要素 | 要素說明 | 采集的數據 | 示例 |
| Who | 參與事件的用戶 | 用戶唯一ID | H522a3bd525a2af |
| When | 事件發生的時間 | 自動獲取事件當時時間 | 11月11日00:02:03 |
| Where | 事件發生的地理位置 | 自動獲取 IP、GPS信息 | 114.242.249.113 |
| How | 事件發生的方式 | 使用的環境 | 設備品牌：Apple 設備型號：iPhone 6s 操作系統：iOS 屏幕分辨率：1920*1680 運營商：中國聯通 網絡類型：Wifi …… |
| What | 事件的內容 | 自定義采集的事件：EventID 事件屬性：Key-Value | add_to_cart product_name：耳麥 product_price：666 |
用戶、時間、地理位置、事件發生的環境等可以自動采集，采集哪些事件、事件更豐富的屬性需要用戶自己來上報。
事件模板：
| 事件ID | 事件名稱 | 事件說明 | 屬性ID | 屬性名稱 | 屬性說明 | 屬性值類型 |
| PayOrder | 支付訂單 | 點擊支付按鈕時觸發 | paymentMethod | 支付方式 | ? | 字符型 |
| ViewDetailPage | 瀏覽頁詳情 | 點擊詳情頁時觸發 | PageID | 頁面ID | ? | 字符型 |
模板例子：
| 平臺 | 事件ID | 事件顯示名稱 | 事件說明 | 屬性ID | 屬性顯示名稱 | 屬性說明 | 屬性值數據類型 |
| Android,iOS | $signup | 注冊 | 注冊成功時觸發 | username | 用戶名 | 用戶輸入的用戶名 | 字符串 |
| ? | ? | ? | ? | company | 所在公司 | 所在公司信息 | 字符串 |
| ? | ? | ? | ? | age | 年齡 | 用戶年齡 | 字符串 |
| Android,iOS | login | 登錄 | 點擊登錄成功時觸發 | ? | ? | ? | ? |
分析應用當前所處的階段，設置合理的目標，拉新、促活等等；
分析實現目標需要采集哪些數據；
按照模板梳理需要埋點的事件、事件屬性
????平臺：輸入需要埋點的平臺，僅支持輸入 Android、iOS、Web/H5、小程序、其他、未知這6個選項，多個平臺時，英文逗號分隔
????事件ID：用于工程師埋點，唯一標識事件，僅支持$、字母、數字和下劃線，不能以數字或下劃線開頭，上限125個半角字符，$僅用于預置事件
????事件顯示名稱：用于在產品中顯示事件名稱，不支持特殊字符，上限50個半角字符
????事件說明：用于說明事件的觸發條件、埋點位置等幫助工程師理解埋點需求，不支持特殊字符，上限100個半角字符
????屬性ID：更豐富的描述事件，屬性ID用于唯一標識事件屬性，命名規則同事件ID，當有多個屬性時，自行增加行
????屬性顯示名稱：用于顯示屬性名稱，不支持特殊字符，上限50個半角字符
????屬性說明：用于說明事件的屬性，不支持特殊字符，上限100個半角字符
????屬性值類型：選擇不同的屬性值類型，不同的類型在分析時會有不同的處理方式，僅支持定義為 字符串、數值、布爾、日期或集合類型
用戶屬性：分析過程中，需要引入注冊用戶的更多維度，比如注冊用戶ID、姓名、用戶等級等等，也需要進行梳理，方法同事件屬性。
| 用戶屬性ID | 用戶屬性名稱 | 屬性說明 | 屬性值類型 | ||||
| UserLevel | 用戶等級 | 上傳用戶的等級信息 | 字符型 | ||||
| 用戶屬性ID | 屬性顯示名稱 | 屬性說明 | 屬性值數據類型 | ||||
| username | 用戶名 | 用戶名 | 字符串 | ||||
| company | 所在公司 | 所在公司名稱 | 字符串 | ||||
| age | 年齡 | 用戶年齡 | 字符串 | ||||
確定要分析的用戶維度；
按照模板格式梳理需要埋點上傳的用戶屬性：
用戶屬性ID：唯一標識描述的用戶維度，僅支持$、字母、數字和下劃線，不能以數字或下劃線開頭，上限125個半角字符，$僅用于預置屬性，當有多個屬性時，自行增加行；
屬性顯示名稱：用于顯示屬性名稱，不支持特殊字符，上限50個半角字符；
屬性說明：用于說明用戶屬性的含義、上報時機等，不支持特殊字符，上限100個半角字符；
屬性值類型：選擇不同的屬性值類型，不同的類型在分析時會有不同的處理方式，僅支持定義為 字符串、數值、布爾、日期 或 集合 類型；
對采集到的埋點寫入到 Kafka 中，對于各個業務的實時數據消費需求，我們為每個業務提供了單獨的 Kafka，流量分發模塊會定期讀取埋點管理平臺提供的元信息，將流量實時分發的各業務 Kafka 中。
③客戶端埋點數據驗證
對埋點后的執行進行驗證，最佳辦法是根據實際驗證需求做出可視化埋點驗證工具，或對接第三方埋點驗證服務。但是如果不想花費此成本，也可以做以下的方案處理：
客戶端有操作時，驗證是否會正確觸發上報；
查看上報事件的屬性（名稱、屬性名稱及類型）是否符合預期；
了解到客戶端操作的行為序列；
網站埋點（JS）
調試模式開啟時：
debugMode: 1 或 2；SDK 會向瀏覽器的控制臺中輸出日志。日志中會包含一些告警、錯誤，也會包含上報事件的內容。
以 Chrome 為例，步驟如下：
· ?啟動 Chrome，并訪問已經埋好點的網站
·??按 F12 或 Ctl/Cmd + Alt/Opt + I 打開 “開發者工具”
·??點擊 “Console” 頁簽進入控制臺
·??正常瀏覽頁面，接可以看到控制臺有大量的日志
接下來，為了方便查看事件報文的內容，我們可以在過濾器中設定關鍵字“analysys”篩選出報文。
· ?SDK初始化相關日志
· ?Send message to server: **實際上報地址**
· ?上報數據相關日志
如日志發送成功，控制臺會輸出：Send message success
調試模式未開啟時：
debugMode: 0，生產環境通常會關閉調試模式，在調試模式未開啟時SDK不會向瀏覽器的控制臺發送任何日志，這對調試造成了一些不利。但通過瀏覽器自帶的開發者工具也查看到上報的事件內容。下面以 Chrome 為例，介紹相應的測試方法。
步驟如下：
· ?啟動 Chrome，并訪問已經埋好點的網站
· ?按 F12 或 Ctl/Cmd + Alt/Opt + I 打開 “開發者工具”
· ?如上圖，點擊“Network”頁簽
· ?正常瀏覽頁面，就能在瀏覽器中看到上報的埋點日志
· ?如上圖，在左上方紅框位置的過濾器中輸入“up?”
· ?點擊每條記錄，就能在右側紅框“Request Payload”中看到上報報文的內容了。
APP埋點（iOS/Android）
移動端 SDK 也會輸出日志，開發者可以按照下面的說明開啟調試模式，通過 SDK 的日志調試。同時我們也提供一種面向非開發者的，通過抓包工具來查看上報日志的方式。
開發者，先在代碼中設置調試狀態開啟：
Andorid環境
AnalysysAgent.setDebugMode(this, 2);
0：關閉 Debug 模式
1：打開 Debug 模式，但該模式下發送的數據僅用于調試，不計入平臺數據統計
2：打開 Debug 模式，該模式下發送的數據可計入平臺數據統計
iOS環境
AnalysysAgent setDebugMode:AnalysysDebugButTrack
AnalysysDebugOff：關閉 Debug 模式
AnalysysDebugOnly：打開 Debug 模式，但該模式下發送的數據僅用于調試，不計入平臺數據統計
AnalysysDebugButTrack：打開 Debug 模式，該模式下發送的數據可計入平臺數據統計
使用 Eclipse、AndroidStudio 或 Xcode 工具等，請在 Console 中搜索 tag 為“Analysys”
初始化成功后，控制臺會輸出:
· ?SDK初始化相關日志
· ?Send message to server: **實際上報地址**
· ?上報數據相關日志
日志發送成功，控制臺會輸出：Send message success
非開發者，往往 App 已經安裝在手機上，若想調試需要將 App 的流量發送到流量分析工具中進行調試。以下有幾個知名度比較高的工具可供參考：
mitmproxy
https://mitmproxy.org/#mitmweb
Charles
https://www.charlesproxy.com/download/
Fiddler
https://www.telerik.com/fiddler
步驟如下：
從上述流量監控工具中選擇適合您的，安裝并按提示將您 app 的流量轉發到工具里
· ?在工具中的過濾器中輸入“up?”
· ?正常使用 app，就能在工具中看到上報的埋點日志
· ?點擊每條記錄，就能查看上報報文的內容了
④Matomo采集
- Matomo統計添加方法
A.在Matomo上創建網站
編輯內容
項目網址就是要統計的目標網址，統計代碼添加后凡以此開頭的都會被記錄到Matomo，添加后就會產生如下網站記錄，注意那個ID后面的統計代碼里面都要用到
B.添加統計代碼
Vue的方式
import Vue from 'vue'import VueMatomo from 'vue-matomo'// matomo用戶統計--類似于友盟
Vue.use(VueMatomo, {
????// 這里配置你自己的piwik服務器地址和網站ID
????host: 'https://bayes.test.com/piwik',
????siteId: 412,
????// 根據router自動注冊
????router: router,
????// 是否需要在發送追蹤信息之前請求許可
????// 默認false
????requireConsent: false,
????// 是否追蹤初始頁面
????// 默認true
????trackInitialView: true,
????// 最終的追蹤js文件名
????// 默認 'piwik'
????trackerFileName: 'piwik'
})
純Js的方式
<!-- Matomo --><script type="text/javascript">
??var _paq = _paq || [];
??/* tracker methods like "setCustomDimension" should be called before "trackPageView" */
??_paq.push(['trackPageView']);
??_paq.push(['enableLinkTracking']);
??(function() {
????var u="//bayes.test.com/piwik/";
????_paq.push(['setTrackerUrl', u+'piwik.php']);
????_paq.push(['setSiteId', '412']); // 注意這里的setSiteId，后面的數字就是你的網站id，在matomo網站上可以查到
????var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
????g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
??})();</script>
<!-- End Matomo Code -->
- vue+vue-matomo實現埋點
在安裝好vue腳手架后，首先引入vue-matomo：npm i vue-matomo
在 main.js中配置：
import VueMatomo from 'vue-matomo'
Vue.use(VueMatomo, {
??host: `你自己的matomo地址`,
??siteId: '這個值頁需要去matomo上去申請', // siteId值
??// 根據router自動注冊,需要注意的是如果有路由傳值值太長的話會matomo會監聽不到并報414，就不能使用此方法了
???router: router,
??// 是否需要在發送追蹤信息之前請求許可
??// 默認false
??requireConsent: false,
??enableLinkTracking: true,
??// 是否追蹤初始頁面
??// 默認true
??trackInitialView: false,
??// 最終的追蹤js文件名，因為我這邊的matomo版本比較老，所以使用的是piwik，現在版本新的話此值應該為matomo
??trackerFileName: 'piwik',
??debug: true,
??userId:'當前用戶登錄Id,可根據需求來設置，非必傳，也可以在用戶登錄成功之后設置'})
到此，就已經可以監聽到頁面訪問、加載時間、訪問次數、訪問時間、實時訪客等等數據。如圖：
- matomo數據收集案例
內容收集-例：
<div id="class1" class="class1" data-track-content data-content-name="employee_id_list" data-content-piece="show_id_list">
<span align="center"><a id="btn_exit" href="{{ url_for('.stat')}}" data-track-content data-content-name="stat_pagelink" data-content-piece="stat_pagelink">統計分析 </a></span>
事件收集-例：
_paq.push(['trackPageView']);
_paq.push(['trackEvent', 'Img', 'Clicked', 'handle']);
_paq.push(['trackAllContentImpressions']);
2、日志采集
方式一、通過采集架構的日志數據，從而形成基于日志的用戶行為分析機制，其執行流程如下：
日志分析的總體架構就是使用Flume從nginx所在服務器上采集日志文件，并存儲在HDFS文件系統上，使用mapreduce清洗日志文件，最后使用HIVE構建數據倉庫做離線分析。任務的調度使用Shell腳本完成，當然大家也可以嘗試一些自動化的任務調度工具，比如說AZKABAN或者OOZIE等。分析所使用的點擊流日志文件主要來自Nginx的access.log日志文件，需要注意的是在這里并不是用Flume直接去生產環境上拉取nginx的日志文件，而是多設置了一層FTP服務器來緩存所有的日志文件，然后再用Flume監聽FTP服務器上指定的目錄拉取目錄里的日志文件到HDFS服務器上。從生產環境推送日志文件到FTP服務器的操作可以通過Shell腳本配合Crontab定時器來實現。一般在WEB系統中，用戶對站點的頁面的訪問瀏覽，點擊行為等一系列的數據都會記錄在日志中，每一條日志記錄就代表著上圖中的一個數據點；而點擊流數據關注的就是所有這些點連起來后的一個完整的網站瀏覽行為記錄，可以認為是一個用戶對網站的瀏覽session。比如說用戶從哪一個外站進入到當前的網站，用戶接下來瀏覽了當前網站的哪些頁面，點擊了哪些圖片鏈接按鈕等一系列的行為記錄，這一個整體的信息就稱為是該用戶的點擊流記錄。本次設計的離線分析系統就是收集WEB系統中產生的這些數據日志，并清洗日志內容存儲分布式的HDFS文件存儲系統上，接著使用HIVE去統計所有用戶的點擊流信息。
PageViews建模例子
Visits建模例子
方式二、ELK日志分析系統
ELK是一組開源軟件的簡稱，其包括Elasticsearch、Logstash 和 Kibana，目前最流行的集中式日志解決方案。
Elasticsearch: 能對大容量的數據進行接近實時的存儲，搜索和分析操作。 主要通過Elasticsearch存儲所有獲取的日志。
Logstash： 數據收集引擎，支持動態的的從各種數據源獲取數據，并對數據進行過濾，分析，豐富，統一格式等操作，然后存儲到用戶指定的位置。
Kibana： 數據分析與可視化平臺，對Elasticsearch存儲的數據進行可視化分析，通過表格的形式展現出來。
Filebeat: 輕量級的開源日志文件數據搜集器。通常在需要采集數據的客戶端安裝Filebeat,并指定目錄與日志格式,Filebeat就能快速收集數據，并發送給logstash進行解析，或是直接發給Elasticsearch存儲。
Redis：NoSQL數據庫(key-value)，也數據輕型消息隊列，不僅可以對高并發日志進行削峰還可以對整個架構進行解耦
Logstash主要組成如下：
inpust：必須，負責產生事件（Inputs generate events），常用：File、syslog、redis、beats（如：Filebeats）
filters：可選，負責數據處理與轉換（filters modify them），常用：grok、mutate、drop、clone、geoip
outpus：必須，負責數據輸出（outputs ship them elsewhere），常用：elasticsearch、file、graphite、statsd
Filebeats作為一種輕量級的日志搜集器，其不占用系統資源，自出現之后，迅速更新了原有的elk架構。Filebeats將收集到的數據發送給Logstash解析過濾，在Filebeats與Logstash傳輸數據的過程中，為了安全性，可以通過ssl認證來加強安全性。之后將其發送到Elasticsearch存儲，并由kibana可視化分析。
業務數據采集與轉換
大數據平臺的數據來源廣泛，根據來源，大致分為兩類：
1)內部
a)手工填報
b)流+實時數據采集
c)批量
2)外部
a)文件導入
b)網絡爬蟲
c)對外接口服務
根據以上分類提供以下方案：
1、實時數據采集轉換
實時采集選用Flume技術、消息隊列選Kafka技術，在線實時處理選用Storm技術、關系型數據庫可以選MySQL、Oracle多種類型，實時內存數據庫選用Redis、歷史大數據存儲可選用MongoDB。數據采集系統體系結構如下圖所示：
Flume是一個分布式、高可靠和高可用的數據采集采集系統。可針對不同數據源、不同結構的海量數據進行高效收集、聚合和傳輸，具備良好的擴展性、伸縮性和容錯性。Flume由一系列的稱為Agent的組件構成，每一個Agent內部包含三個組件，分別是Source、Channel、Sink。Flume的每個組件是可插拔、可定制的，其本質上是一個中間件，有效屏蔽了數據源與目標源之間的異構性，便于系統的擴展和升級。Source可定制開發從外部系統或Agent接收數據，并寫入一個或多個Channel；Channel是一個緩沖區，緩沖Source寫入的數據，知道Sink發送出去；Sink負責從Channel中讀取數據，并發送給消息隊列或存儲系統，甚至于是另一個Agent。
針對不同通訊協議或者不同數據量級的數據源，定制開發一個Agent，在Agent內部采用Memory Channel緩存，以提升性能，采用Kafka Sink將Channel中的數據寫入Kafka。
在實際應用中，不同數據源（數據生產者）產生的實時數據，需要經過不同的系統進行邏輯和業務處理，同時被寫入歷史數據庫和Storm集群（數據消費者）進行離線大數據分析和在線實時分析。采用Kafka作為消息緩沖區，Kafka提供了高容錯性和可擴展性，允許可靠地緩存更多的實時數據，以便于多個消費者重復讀取。
Storm是為在線實時處理提供便利，實時采集數據，在Storm中實現模型化處理、簡單的統計分析、數據存儲等功能。Storm會根據實際業務應用的要求，將數據存儲在實時內存數據庫Redis、關系型數據庫MySQL、歷史大數據庫MongoDB、HDFS等系統。
Kafka和Storm由Zookeeper集群化管理，這樣即使Kafka宕機重啟后也能找到上次的消費記錄，接著從上次宕機點繼續從Kafka的Broker中進行消費。但是由于存在先消費后記錄日志或者先記錄后消費的非原子操作，如果出現剛好消費完一條消息并還沒將信息記錄到Zookeeper的時候就宕機的類似問題，或多或少都會存在少量數據丟失或重復消費的問題，可選擇Kafka的Broker和Zookeeper都部署在同一臺機子上。接下來就是使用用戶定義好的Storm Topology去進行數據的分析并輸出到Redis緩存數據庫中(也可以進行持久化)。
在Flume和Storm中間加入一層Kafka消息系統，就是因為在高并發的條件下， 數據會井噴式增長，如果Storm的消費速度(Storm的實時計算能力那是最快之一，但是也有例外， 而且據說現在Twitter的開源實時計算框架Heron比Storm還要快)慢于數據的產生速度，加上Flume自身的局限性，必然會導致大量數據滯后并丟失，所以加了Kafka消息系統作為數據緩沖區，而且Kafka是基于log File的消息系統，也就是說消息能夠持久化在硬盤中，再加上其充分利用Linux的I/O特性，提供了可觀的吞吐量。架構中使用Redis作為數據庫也是因為在實時的環境下，Redis具有很高的讀寫速度。
2、批量數據采集轉換
批量數據采集有多種方案，比如通過開源組件sqoop、kettle等，或者通過阿里的DataX離線同步服務完成。批量數據的執行周期可自寫定時任務，也可利用工具自帶定時機制完成。
1)Sqoop
主要用于在Hadoop(HDFS、Hive、HBase)與數據庫(mysql、postgresql、MongoDB…)間進行數據的傳遞，可以將一個數據庫中的數據導進到Hadoop的HDFS中，也可以將HDFS的數據導進到關系型數據庫中。
Sqoop Client 通過 shell 命令來使用 Sqoop，Sqoop 中的 Task Translater 將命令轉換成 Hadoop 中的 MapReduce 任務進行具體的數據操作。例如 Mysql 中某個表數據同步到 Hadoop 這個場景，Sqoop 會將表記錄分成多份，每份分到各自 Mapper 中去進行落地 Hadoop（保證同步效率），這里的 MapReduce沒有 reduce，只有 map。
2)Kettle
Kettle作為開源的ETL工具，具有比較完備的功能，同樣支持多種數據源的采集轉換功能，同時自帶任務機制，無需自行手動編寫定時任務；kettle提供Spoon可視化組件，可以視圖形式完成轉換任務及作業的創建，提高工作效率。
3)DataX
DataX 是阿里巴巴集團內被廣泛使用的離線數據同步工具/平臺，實現包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各種異構數據源之間高效的數據同步功能。
所支持的數據源如下，也可自行開發插件：
3、API接口
通過 Restful API 可以將歷史數據通過網絡上報到大數據平臺，這種方式一般適用于數據量不太大的情況。
調用該接口，把符合特定格式的數據以POST的方式上報至服務器。接收服務器對上報的數據進行校驗，不符合格式的返回相應的錯誤提示。上報后的數據會先暫存在 Kafka 中，流處理引擎大約會以3000條/秒的速度將數據落庫并可用于查詢，該過程性能受服務器影響，但偏差一般不會太大。
接口協議：HTTP(S)，POST方式
請求地址：http(s)://host:port/up
請求數據：請求的 Body 體里面存放具體要上報的數據，數據明文為 JsonArray 的形式。上報的數據明文示例如下：
[{
????"appid": "demo",
????"xwho": "8c0eebf0-2383-44bc-b8ba-a5c719fc6194",
????"xwhat": "confirmOrder",
????"xwhen": 1532514947857,
????"xcontext": {
????????"$channel": "豌豆莢",
????????"$app_version": "4.0.4.001",
????????"$model": "MI 6X",
????????"$os": "Android",
????????"$os_version": "8.1.0",
????????"$lib": "Android",
????????"$platform": "Android",
????????"$is_login": false,
????????"$lib_version": "4.0.4",
????????"$debug": 2,
????????"$importFlag": 1 ????//說明：$importFlag字段是專門用作導數
????}
}]
數據編碼：使用 UTF-8 編碼。上報數據可以使用明文上報，也可以對數據進行壓縮/編碼處理后進行上報。壓縮/編碼過程具體為：先進行Gzip壓縮，然后進行Base64編碼，最后把編碼后的數據直接放到Body體里面上報即可。
應答格式
上報成功：{"code":200}
上報失敗：{"code":500}
上報數據格式錯誤：{"code":xxx, "msg":"xxxxx"}，返回的應答消息中包含"msg"字段，內容為具體的異常信息。
4、網絡爬蟲
網絡爬蟲作為侵入式采集，特殊的存在，涉及諸多安全問題，需慎用。
第三方系統API對接
1、對接概要
從第三方平臺獲取數據最合理方式就是通過開放的接口獲取所需數據，獲取到所需接口后，首先需要做的有以下幾點：
1）需要賬號的要先申請賬號。
2）申請完賬號，嚴格對照接口文檔開發。
3）注意文檔的每個字段。都有它的特殊含義。
4）拼接第三方的參數接口最好寫在配置文件中，方便修改
5）如第三方（微信，qq）登錄授權，微信，銀聯支付等 需要拼接參數的，發送請求。成功后返回所需要的信息進行業務處理。
2、對接方案
1）對接方式
平臺與外部系統對接方式多以web?service方式。
系統接口標準：
以SOA體系架構為基礎，服務總線技術實現數據交換以及實現各業務子系統間、外部業務系統之間的信息共享和集成，因此SOA體系標準就是我們采用的接口核心標準。主要包括：
服務目錄標準：服務目錄API接口格式參考國家以及關于服務目錄的元數據指導規范，對于W3C UDDI v2 API結構規范，采取UDDI v2的API的模型，定義UDDI的查詢和發布服務接口，定制基于Java和SOAP的訪問接口。除了基于SOAP1.2的Web Service接口方式，對于基于消息的接口采用JMS或者MQ的方式。
交換標準：基于服務的交換，采用HTTP/HTTPS作為傳輸協議，而其消息體存放基于SOAP1.2協議的SOAP消息格式。SOAP的消息體包括服務數據以及服務操作，服務數據和服務操作采用WSDL進行描述。
Web服務標準：用WSDL描述業務服務，將WSDL發布到UDDI用以設計/創建服務，SOAP/HTTP服務遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs實現新的業務服務，根據需求提供SOAP/HTTP or JMS and RMI/IIOP接口。
業務流程標準：使用沒有擴展的標準的BPEL4WS，對于業務流程以SOAP服務形式進行訪問，業務流程之間的調用通過SOAP。
數據交換安全：與外部系統對接需考慮外部訪問的安全性，通過IP白名單、SSL認證等方式保證集成互訪的合法性與安全性。
數據交換標準：制定適合雙方系統統一的數據交換數據標準，支持對增量的數據自動進行數據同步，避免人工重復錄入的工作。
2）接口規范性設計
系統平臺中的接口眾多，依賴關系復雜，通過接口交換的數據與接口調用必須遵循統一的接口模型進行設計。接口模型除了遵循工程統一的數據標準和接口規范標準，實現接口規范定義的功能外，需要從數據管理、完整性管理、接口安全、接口的訪問效率、性能以及可擴展性多個方面設計接口規格。
接口定義約定
客戶端與系統平臺以及系統平臺間的接口消息協議采用基于HTTP協議的REST風格接口實現，協議棧如圖所示。
接口消息協議棧示意圖
系統在http協議中傳輸的應用數據采用具有自解釋、自包含特征的JSON數據格式，通過配置數據對象的序列化和反序列化的實現組件來實現通信數據包的編碼和解碼。
在接口協議中，包含接口的版本信息，通過協議版本約束服務功能規范，支持服務平臺間接口協作的升級和擴展。一個服務提供者可通過版本區別同時支持多個版本的客戶端，從而使得組件服務的提供者和使用者根據實際的需要，獨立演進，降低系統升級的復雜度，保證系統具備靈活的擴展和持續演進的能力。
業務消息約定
請求消息URI中的參數采用UTF-8編碼并經過URLEncode編碼。
請求接口URL格式：{http|https}://{host}:{port}/
{app name}/{business component name}/{action}；其中：
協議：HTTP REST形式接口
host：應用支撐平臺交互通信服務的IP地址或域名
port：應用支撐平臺交互通信服務的端口
app name：應用支撐平臺交互通信服務部署的應用名稱
business component name：業務組件名稱
action：業務操作請求的接口名稱，接口名字可配置
應答的消息體采用JSON數據格式編碼，字符編碼采用UTF-8。
應答消息根節點為“response”，每個響應包含固定的兩個屬性節點：“status”和“message”。它們分別表示操作的返回值和返回消息描述，其他的同級子節點為業務返回對象屬性，根據業務類型的不同，有不同的屬性名稱。
當客戶端支持數據壓縮傳輸時，需要在請求的消息頭的“Accept-Encoding”字段中指定壓縮方式(gzip)，如消息可以被壓縮傳輸則平臺將應答的數據報文進行壓縮作為應答數據返回，Content-Length為壓縮后的數據長度。詳細參見HTTP/1.1 RFC2616。
響應碼規則約定
響應結果碼在響應消息的“status”屬性中，相應的解釋信息在響應消息的“message”屬性中。解釋消息為終端用戶可讀的消息，終端應用不需要解析可直接呈現給最終用戶。響應結果碼為6位數字串。根據響應類型，包括以下幾類響應碼。如表4-1中的定義。
表4-1響應碼對應表
| 響應碼 | 描述 |
| 0 | 成功 |
| 1XXXXX | 系統錯誤 |
| 2XXXXX | 輸入參數不合法錯誤 |
| 3XXXXX | 應用級返回碼，定義應用級的異常返回。 |
| 4XXXXX | 正常的應用級返回碼，定義特定場景的應用級返回說明。 |
數據管理
A.業務數據檢查
接口應提供業務數據檢查功能，即對接收的數據進行合法性檢查，對非法數據和錯誤數據則拒絕接收，以防止外來數據非法入侵，減輕應用支撐平臺系統主機處理負荷。
對于接口，其業務數據檢查的主要內容有以下幾個方面：
? 數據格式的合法性：如接收到非預期格式的數據。包括接收的數據長度，類型，開始結束標志等。
? 數據來源的合法性：如接收到非授權接口的數據。
? 業務類型的合法性：如接收到接口指定業務類型外的接入請求。
對于業務數據檢查中解析出非法數據應提供以下幾種處理方式：
? 事件報警：在出現異常情況時自動報警，以便系統管理員及時進行處理。
? 分析原因：在出現異常情況時，可自動分析其出錯原因。如是數據來源非法和業務類型非法，本地記錄并做后續管理，如是數據格式非法，分析網絡傳輸原因或對端數據處理原因，并做相應處理。
? 統計分析：定期對所有的非法記錄做統計分析，分析非法數據的各種來源是否具有惡意，并做相應處理。
B.數據壓縮/解壓
接口根據具體的需求應提供數據壓縮/解壓功能，以減輕網絡傳輸壓力，提高傳輸效率，從而使整個系統能夠快速響應并發請求，高效率運行。
在使用數據壓縮/解壓功能時，應具體分析每一類業務的傳輸過程、處理過程、傳輸的網絡介質、處理的主機系統和該類業務的并發量、峰值及對于所有業務的比例關系等，從而確定該類業務是否需要壓縮/解壓處理。對于傳輸文件的業務，必須壓縮后傳輸，以減輕網絡壓力，提高傳輸速度。
在接口中所使用的壓縮工具必須基于通用無損壓縮技術，壓縮算法的模型和編碼必須符合標準且高效，壓縮算法的工具函數必須是面向流的函數，并且提供校驗檢查功能。
完整性管理
根據業務處理和接口服務的特點，應用系統的業務主要為實時請求業務和批量傳輸業務。兩類業務的特點分別如下：
1.實時請求業務：
(1) 采用基于事務處理機制實現
(2) 業務傳輸以數據包的方式進行
(3) 對傳輸和處理的實時性要求很高
(4) 對數據的一致性和完整性有很高的要求
(5) 應保證高效地處理大量并發的請求
2.批量傳輸業務：
(1) 業務傳輸主要是數據文件的形式
(2) 業務接收點可并發處理大量傳輸，可適應高峰期的傳輸和處理
(3) 要求傳輸的可靠性高
根據上述特點，完整性管理對于實時交易業務，要保證交易的完整性；對于批量傳輸業務，要保證數據傳輸的完整性。
3）接口雙方責任
消息發送方
遵循本接口規范中規定的驗證規則，對接口數據提供相關的驗證功能，保證數據的完整性、準確性；
消息發起的平臺支持超時重發機制，重發次數和重發間隔可配置。
提供接口元數據信息，包括接口數據結構、實體間依賴關系、計算關系、關聯關系及接口數據傳輸過程中的各類管理規則等信息；
提供對敏感數據的加密功能；
及時解決接口數據提供過程中數據提供方一側出現的問題；
消息響應方
遵循本接口規范中規定的驗證規則，對接收的數據進行驗證，保證數據的完整性、準確性。
及時按照消息發送方提供的變更說明進行本系統的相關改造。
及時響應并解決接口數據接收過程中出現的問題。
異常處理
對接口流程調用過程中發生的異常情況，如流程異常、數據異常、會話傳輸異常、重發異常等，進行相應的異常處理，包括：
對產生異常的記錄生成異常記錄文件。
針對可以回收處理的異常記錄，進行自動或者人工的回收處理。
記錄有關異常事件的日志，包含異常類別、發生時間、異常描述等信息。
當接口調用異常時，根據預先配置的規則進行相關異常處理，并進行自動告警。
4）接口的可擴展性規劃與設計
各個系統間的通信接口版本信息限定了各個系統平臺間交互的數據協議類型、特定版本發布的系統接口功能特征、特定功能的訪問參數等接口規格。通過接口協議的版本劃分，為客戶端升級、其他被集成系統的升級、以及系統的部署提供了較高的自由度和靈活性。
系統可根據接口請求中包含的接口協議版本實現對接口的向下兼容。系統平臺可根據系統的集群策略，按協議版本分別部署，也可多版本并存部署。由于系統平臺可同時支持多版本的外部系統及客戶端應用訪問系統，特別是新版本客戶端發布時，不要求用戶強制升級，也可降低強制升級安裝包發布的幾率。從而支持系統的客戶端與系統平臺分離的持續演進。
5）接口安全性設計
為了保證系統平臺的安全運行，各種集成的外部系統都應該保證其接入的安全性。
接口的安全是平臺系統安全的一個重要組成部分。保證接口的自身安全，通過接口實現技術上的安全控制，做到對安全事件的“可知、可控、可預測”，是實現系統安全的一個重要基礎。
根據接口連接特點與業務特色，制定專門的安全技術實施策略，保證接口的數據傳輸和數據處理的安全性。
系統應在接口的接入點的網絡邊界實施接口安全控制。
接口的安全控制在邏輯上包括：安全評估、訪問控制、入侵檢測、口令認證、安全審計、防(毒)惡意代碼、加密等內容。
安全評估
安全管理人員利用網絡掃描器定期(每周)/不定期(當發現新的安全漏洞時)地進行接口的漏洞掃描與風險評估。掃描對象包括接口通信服務器本身以及與之關聯的交換機、防火墻等，要求通過掃描器的掃描和評估，發現能被入侵者利用的網絡漏洞，并給出檢測到漏洞的全面信息，包括位置、詳細描述和建議改進方案，以便及時完善安全策略，降低安全風險。
安全管理人員利用系統掃描器對接口通信服務器操作系統定期(每周)/不定期(當發現新的安全漏洞時)地進行安全漏洞掃描和風險評估。在接口通信服務器操作系統上，通過依附于服務器上的掃描器代理偵測服務器內部的漏洞，包括缺少安全補丁、詞典中可猜中的口令、不適當的用戶權限、不正確的系統登錄權限、操作系統內部是否有黑客程序駐留，安全服務配置等。系統掃描器的應用除了實現操作系統級的安全掃描和風險評估之外還需要實現文件基線控制。
接口的配置文件包括接口服務間相互協調作業的配置文件、系統平臺與接口對端系統之間協調作業的配置文件，對接口服務應用的配置文件進行嚴格控制，并且配置文件中不應出現口令明文，對系統權限配置限制到能滿足要求的最小權限，關鍵配置文件加密保存。為了防止對配置文件的非法修改或刪除，要求對配置文件進行文件級的基線控制。
訪問控制
訪問控制主要通過防火墻控制接口對端系統與應用支撐平臺之間的相互訪問，避免系統間非正常訪問，保證接口交互信息的可用性、完整性和保密性。訪問控制除了保證接口本身的安全之外，還進一步保證應用支撐平臺的安全。
為了有效抵御威脅，應采用異構的雙防火墻結構，提高對防火墻安全訪問控制機制的破壞難度。雙防火墻在選型上采用異構方式，即采用不同生產廠家不同品牌的完全異構防火墻。同時，雙防火墻中的至少一個應具有與實時入侵檢測系統可進行互動的能力。當發生攻擊事件或不正當訪問時，實時入侵檢測系統檢測到相關信息，及時通知防火墻，防火墻能夠自動進行動態配置，在定義的時間段內自動阻斷源地址的正常訪問。
系統對接口被集成系統只開放應用定義的特定端口。
采用防火墻的地址翻譯功能，隱藏系統內部網絡，向代理系統提供翻譯后的接口通信服務器地址及端口，禁止接口對端系統對其它地址及端口的訪問。
對通過/未通過防火墻的所有訪問記錄日志。
入侵檢測
接口安全機制應具有入侵檢測(IDS)功能，實時監控可疑連接和非法訪問等安全事件。一旦發現對網絡或主機的入侵行為，應報警并采取相應安全措施，包括自動阻斷通信連接或者執行用戶自定義的安全策略。
實施基于網絡和主機的入侵檢測。檢測攻擊行為和非法訪問行為，自動中斷其連接，并通知防火墻在指定時間段內阻斷源地址的訪問，記錄日志并按不同級別報警，對重要系統文件實施自動恢復策略。
口令認證
對于需經接口安全控制系統對相關集成系統進行業務操作的請求，實行一次性口令認證。
為保證接口的自身安全，對接口通信服務器和其它設備的操作和管理要求采用強口令的認證機制，即采用動態的口令認證機制。
安全審計
為了保證接口的安全，要求對接口通信服務器的系統日志、接口應用服務器的應用日志進行實時收集、整理和統計分析，采用不同的介質存檔。
防惡意代碼或病毒
由于Internet為客戶提WEB服務，因此，對于Internet接口要在網絡分界點建立一個功能強大的防惡意代碼系統，該系統能實時地進行基于網絡的惡意代碼過濾。建立集中的防惡意代碼系統控制管理中心。
加密
為了提高接口通信信息的保密性，同時保證應用支撐平臺的安全性，可以對系統平臺與接口集成系統間的相關通信實施鏈路加密、網絡加密或應用加密，保證無關人員以及無關應用不能通過網絡鏈路監聽獲得關鍵業務信息，充分保證業務信息的安全。
3、具體實現
1）原生JDK構造HTTP請求客戶端，調用API
手動去創建HTTP連接，并將數據寫入流中，再將數據轉換為JSON對象進行解析
2）在SpringBoot下使用RestTemplate，以及抽取配置的方式調用API
將一些配置抽取出來，不同的環境運行不同的配置文件是常見的做法。例如我們可以將上面的appKey放到application.yml配置文件中。
3）使用OpenFeign以及抽取配置的方式調用API
將API調用變得更加像調用普通接口一樣方便。原版的OpenFeign不依賴Spring獨立使用（ https://github.com/OpenFeign/feign），SpringCloud整合了OpenFeign，在SpringCloud2.x，Feign成為SpringCloud的一級項目（ https://cloud.spring.io/spring-cloud-openfeign/）。
OpenFeign為微服務架構下服務之間的調用提供了解決方案，同時它可以結合其它組件可以實現負載均衡的HTTP客戶端。
用戶數據關聯
不同數據源采集的用戶數據的關聯可采用基于ID-Mapping技術實現id的數據關聯。
當下數據關聯實現主要選擇第三方提供的服務和自行開發兩種方式：
1、三方服務
三方服務選擇上有很多，可以利用阿里、華為、神策等廠商提供的各種相關解決方案或服務，有原生開發支持，也有直接的SAAS支持方式。以阿里的ID-Mapping體系的方案OneData體系為例
2、自行開發
1）基于ID-Mapping用戶數據關聯實現可總結為以下三種：
①基于賬號體系企業中最常用的是基于賬號體系來做ID的打通，用戶注冊時，給到用戶一個uid，以uid來強關聯所有注冊用戶的信息。
????②基于設備：那對于未注冊用戶可以通過終端設備ID精準識別，包含Android/iOS兩類主流終端的識別；通過SDK將各種ID采集上報，后臺利用的ID關系庫和校準算法，實時生成/找回終端唯一ID并下發。
③基于賬號&設備：結合各種賬戶、各種設備型號之間的關系對，以及設備使用規律等用戶數據；采用規則規律、數據挖掘算法的方法，輸出關系穩定的ID關系對，并生成一個UID作為唯一識別該對象的標識碼。
2）技術實現ID-Mapping
①借助redis
a.從日志數據中抽取各種標識id
b.將提取出的標識id，去redis標識id庫中查詢是否存在
c.如果不存在，則新建一個"統一標識"+“id set”
d.如果已存在，則使用已存在的統一標識
②借助圖計算
采用圖計算手段，來找到各種id標識之間的關聯關系，從而識別出哪些id標識屬于同一個人；
圖計算的核心思想：
將數據表達成“點”，點和點之間可以通過某種業務含義建立“邊”；然后，可以從點、邊上找出各種類型的數據關系：比如連通性、最短路徑規劃等；
整體實現流程：
A.將當日數據中的所有用戶標識字段，及標志字段之間的關聯，生成點集合 、邊集合
B.將上一日的ids->guid的映射關系，也生成點集合、邊集合
C.將上面兩類點集合、邊集合合并到一起生成一個圖
D.再對上述的圖執行“最大連通子圖”算法，得到一個連通子圖結果
E.在從結果圖中取到哪些id屬于同一組，并生成一個唯一標識
F.將上面步驟生成的唯一標識去比對前日的ids->guid映射表（如果一個人已經存在guid，則沿用原來的guid）
人工數據采集
主要通過實現數據導入工具，來實現對人工處理數據的采集；比如定制好數據模板，當人工填寫數據模板后，在數據工具中導入上傳，再進入大數據平臺的文件自動處理機制流程中。
數據輸出
數據導出方法包含API導出、文件導出、消費消息數據、數據庫導出、工具導出集中方式。
1）API導出
定制開發數據輸出API接口，實現對外數據查詢或導出數據文件，接口做成詳細參照《2.2.1.3第三方系統API對接-接口規范性設計》，輸出API的調用大概分為以下幾個步驟：
鑒權->獲取鏈接->下載/數據
通過做成的對外API接口，為外部提供數據輸出。
2）文件導出
可通可視化形式，提供頁面級別操作，導出所需數據文件，前提也是需要獲取到相應權限。
3）消費消息數據
以kafka為例，通過消費實時數據來滿足更多使用場景。服務端接到一條 SDK 發來的數據后，會對數據做一些預處理并將數據寫入到消息隊列 Kafka 中供下游各類計算模塊及對外使用。
注意點：
A.啟動消費的服務器需與數據服務器實行鑒權，讓消費服務器與數據服務器處于同一網段或者網絡互通，且可解析數據服務器的host。
B.盡量選用兼容性的kafka版本，高版本服務端兼容低版本客戶端，反之則容易出現兼容性問題
①消費參數
| 參數名稱 | 參數值 |
| topic | event{appid}/profile{appid}(其中{appid}表示項目的appid) |
| partition | partitionid(從0開始，至少3個partition） |
| zookeeper | ark1:2181,ark2:2181,ark3:2181 |
| broker | ark1:9092,ark2:9092, ark3:9092 |
②消費數據
消費有shell、原生API等多種方式，可以選擇一種適合使用場景的方式。
下面給出兩種 Shell 方式啟動消費的示例，使用 Shell 方式可以通過重定向標準輸出將數據寫入文件后處理或直接用管道作為其他進程的輸入，可以對接各種編程語言實現的處理程序。
使用 Kafka Console Consumer
·可以使用 Kafka 自帶的 Kafka Console Consumer 通過命令行方式消費，例如從最新數據開始消費：bin/kafka-console-consumer.sh --zookeeper ark1:2181 --topic event_topic
·可以將 stdout 輸出到文件或作為其他數據處理進程的輸入數據。
使用 Simple Consumer Shell
·使用 Simple Consumer Shell 可以實現更靈活的消費，例如：
bin/kafka-run-class.sh kafka.tools.SimpleConsumerShell \
????????--broker-list ark2:9092 ????????\
????????--offset 1234 ????????????????????????\
????????--partition 2 ?????????????????????????\
????????--topic event_topic ???????????????????\
????????--print-offsets
③數據格式
消費的數據的格式與導入時的數據格式基本一致。
4）數據庫導出
即 JDBC、presto-cli、python 或 R 進行數據查詢，達到更加高效、穩定的 SQL 查詢方式，本次采用JDBC方式。
JDBC 信息
| 字段 | 信息 |
| jdbc url | jdbc:presto://xxxx.xxxx.xxx:port/hive/default |
| driver | com.facebook.presto.jdbc.PrestoDriver |
| user | daxiang |
| SSL | true |
| password | 編輯 /etc/presto/presto-auth.properties 文件查看 |
| SSLKeyStorePath | presto.jks文件的路徑，一般是/etc/presto/presto.jks |
| SSLKeyStorePassword | 值可以在單機環境的ark1,集群環境的/etc/presto/config.properties文件中找到，對應http-server.https.keystore.key的值 |
5) 工具導出
可通過自行開發導出工具或第三方導出工具為外部，可通過下載授權數據導出工具獲取輸出的數據。
總結
以上是生活随笔為你收集整理的数据运营平台-数据采集的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 信管网
- 下一篇： Lync-用户-电话号码-更新