ID：-
結合的常見應用需求，我們從生態鏈中選取了一些重要技術和實現方法。用于支撐的平臺可采用如圖1所示的架構模式。
圖1 大數據生態鏈的網絡安全態勢感知應用架構
的核心就是從大量數據中挖掘出價值，而我們的首要工作就是要明確有哪些數據以及怎樣采集。
在計算機信息系統中，一般按照形態的不同可將數據分為結構化數據和非結構化數據。結構化數據的特點是結構固定，每個字段都有特定的語義和長度，可用二維表結構來邏輯表達實現，領域常見的這類數據包括報警、事件日志、數據、摘要分析結構化描述記錄以及各種相關的信息。非結構化數據是不規則或不完整的數據，其特點是格式非常多樣，不方便用二維邏輯表來表現，需要先對數據進行格式轉換或信息提取，領域常見的這類數據包括各類辦公文檔、文本、報表、HTML、XML、聲音、圖像文件等。
在應用中，按照應用場景計算需求的不同可將分為靜態數據和動態數據（流式數據）。靜態數據就像水庫里的水一樣，看上去靜止不動，很多數據倉庫系統存儲的就是這類數據；這些數據一般來自不同數據源，利用ETL工具加載到數據倉庫中，也一般不會更新，技術人員可利用數據挖掘和OLAP分析工具從這些靜態數據中發現價值。動態數據也就是流式數據，是一組順序、大量、快速、連續到達的數據序列，被視為一個隨時間延續而無限增長的動態數據集合。它像流水一樣，不是一次過來而是一點一點“流”過來，處理流式數據時也是一點一點處理，因為如果全部收到數據后再處理會有較大延遲，消耗大量內存，如對PM2.5的監測，因為需要實時顯示空氣質量情況，監測系統會對數據源源不斷地回傳并進行實時分析，預判空氣質量變化趨勢。
在的應用中，按照數據來源和特點可以將數據分為四類。一是環境業務類數據，主要包括被感知環境中的各類資產和屬性；二是網絡層面數據，主要包括包捕獲數據、會話或流數據、包字符串數據；三是層面日志數據，包括各種系統、應用所產生的日志數據等；四是告警數據，通常來自、等安全設備或軟件的報警信息。當然，如果對涉及的重要數據進行羅列，大致可以包括以下類型：完整內容數據、提取內容數據、會話數據、統計數據、元數據、日志數據和告警數據等。
對于不同類型、不同來源的數據，我們采用的數據采集方法也是不盡相同的。總的來說可分為主動式采集和被動式采集。其中與平臺關聯性較強的技術和方法主要有以下幾種：
● 傳感器
● 網絡爬蟲
● 日志收集系統
● 數據抽取工具
● 分布式消息隊列系統
1、傳感器
傳感器（）俗稱探針，以軟件和硬件的形式安裝在網絡中，用于采集和發送數據，以及監控網段內各類資產的信息，它工作在網卡的嗅探模式。比較常見的情況是，一個傳感器是由代理和插件所共同構成的具有網絡行為監控功能的組合。傳感器的功能主要包括數據采集、、、異常檢測、協議識別等。
根據放置的位置不同，可將傳感器分為內置型和外置型。前者一般部署在、等網絡設備中以直接采集數據，大部分現代企業級和都能配置成傳感器，并可以通過網絡將所采集的數據導出來，當然也可以將許多開源的工具軟件安裝在硬件上并配置成傳感器。后者即各種網絡設備已經部署完畢，無法移動原有網絡，需要外置部署，往往與線纜、網絡分路器、匯聚和探針配合使用。
根據網絡規模的大小及其所面臨的威脅類型，傳感器有著不同的作用和類型，如表1所示。
表1 傳感器類型
有的傳感器只需將采集到的數據記錄在磁盤上，有時會基于已采集的數據再生成其他數據，這種類型的傳感器功能簡單，屬于輕量化的傳感器，通常沒有額外安裝的插件。有的傳感器則不僅需要采集數據，還需要執行檢測任務，當需要分析數據時會把數據“拉”到分析設備上進行，而非在傳感器上，這種傳感器最為常見，即帶有一定檢測能力的傳感器。還有一種類型的傳感器，其功能十分強大，集采集、檢測和分析理解于一身，這種傳感器除了配備采集和檢測工具之外，還會安裝一些分析插件，其好處是節約硬件資源，但缺點是容易因為對數據進行了不恰當的處理而導致一些重要數據的損失。畢竟機器的分析能力有限，還是需要一些人工輔助，才能更好地進行。
在這三種類型的傳感器中，第二種傳感器最為常見，也是優先推薦的類型。因為僅僅采集數據的傳感器的功能確實過于單一有限，而集采集、檢測和分析于一體的傳感器又容易造成數據的缺失和分析能力的受限。兼具采集和檢測功能是傳感器較為有效且合理的功能設置，更安全且更有保障，對數據進行檢測后再提交給平臺，也方便平臺以及安全管理人員進行進一步的深度分析理解。
由于傳感器主要負責截取數據，因此需要具有較好的數據轉發能力和較高的容量。為了對數據進行檢測和解析處理，傳感器還應具備一定的端口檢測能力，對于一些高級的傳感器還可增加自動學習并識別高層次協議的能力，即協議智能識別能力。總之，根據我們的實際需要，選擇并設計合適的傳感器進行數據采集。
2、網絡爬蟲
隨著的迅速發展，產生了大量的信息，如何獲取并利用這些海量信息成為一個重要問題，于是應運而生。（Web ）又常稱為網頁蜘蛛、網絡機器人、網絡鏟，它是一種按照一定規則自動抓取萬維網信息的程序或者腳本。其行為一般是先“爬”到對應的網頁上，再把需要的信息“鏟”下來，它比普通的網絡搜索引擎（比如百度、谷歌）更具有針對性、更精準，能定向抓取相關網頁資源。當然，其也可以作為搜索引擎抓取系統的重要組成部分。
（1）網絡爬蟲的工作原理
簡單的能夠從一個或若干個網頁的URL（統一資源定位符）開始，獲得初始網頁上的URL，在抓取網頁的過程中不斷從當前頁面上抽取新的URL放入隊列，直到滿足一定停止條件。復雜一些的能夠根據一定的網頁分析，過濾與主題無關的鏈接，只保留有用的鏈接，并將其放入等待抓取的URL隊列中，然后根據一定的搜索策略從隊列中選擇下一步要抓取的網頁URL并重復上述過程，直到達到系統的某一條件時停止。所有被抓取的網頁將會被系統存儲，并進行一定的分析、過濾，最后建立索引硬件信息收集 腳本，以便之后的查詢和檢索。一個通用的工作流程框架如圖2所示。
圖2 網絡爬蟲工作流程
● 首先選取一部分種子URL。
● 然后將這些URL放入待抓取URL隊列中。
● 從待抓取URL隊列中取出待抓取的URL，解析其，獲得IP，將URL對應的網頁下載下來，存儲到已下載網頁庫中，并將這些URL放入已抓取URL隊列。
● 分析已抓取到的網頁內容中的其他URL，再將這些URL放入待抓取URL隊列中，進入下一個循環過程。
（2）網絡爬蟲的類型結構
已逐漸成為人們主動獲取萬維網上信息的重要方式，其種類多樣、可性強。按照系統結構和實現技術，大致可分為以下幾種類型：通用、聚焦、增量式、深層等。在現實中，抓取系統往往是一個分布式的三層結構，最底層分布在不同地理位置的數據中心，在每個數據中心有若干臺抓取，而每臺抓取上可以部署若干套爬蟲程序。對于一個數據中心的不同抓取，其協同工作方式大致有主從式和對等式兩種，可根據實際需要進行選擇。
（3）網絡爬蟲的爬取和更新策略
在系統中，待抓取URL隊列是很重要的一部分。如何對URL進行排序是一個重要的問題，這也就是我們要介紹的的爬取策略，因為它決定了抓取頁面的順序。比較常見的爬取策略有深度優先遍歷策略、寬度優先遍歷策略、反向鏈接數策略、大站優先策略、OPIC策略以及策略等。對于何時更新以前已經下載過的頁面，也有相應的網頁更新策略，常見的有歷史參考策略、用戶體驗策略和聚類抽樣策略等。
總的來說，技術還是比較成熟的，提供了很多很好的類庫，用實現一個簡單的爬蟲程序并不難，且所需的代碼量非常少。
3、日志收集系統
數據中有相當一大部分是各種設備、系統和應用中所產生的日志數據，它們往往隱藏了許多有用信息。在過去，因為采集分析手段的缺失，這些日志常常存儲一段時間就被清理了。而隨著技術的成熟，日志的價值重新得到重視。如何將分布在各個設備、系統和應用中的日志數據收集起來進行高效的匯總？我們會用到一些高性能的分布式日志收集系統，如Flume、 、 等，這里重點介紹Flume。
（1）Flume的產生背景
Flume是提供的一個高可用、高可靠、分布式海量日志采集、聚合和傳輸的系統。設計Flume的宗旨是向批量導入基于事件的海量數據。Flume支持在日志系統中定制各類數據發送方，用于收集數據，同時Flume具有對數據進行簡單處理并寫到各種數據接收方的功能。一個典型的例子就是利用Flume從一組中收集日志文件，然后將這些文件中的日志事件轉移到一個新的HDFS匯總文件中以做進一步的處理，其終點通常為HDFS。
（2）Flume系統架構
Flume采用三層架構，分別為Agent（代理）、（收集器）和（存儲器），每一層都可以水平擴展。在這三個層次中，Agent和均由統一管理，進行統一監控和維護，并且可以有多個（用進行管理和），能有效地避免單點故障。Flume系統架構如圖3所示。
圖3 Flume系統架構
（3）Flume的工作原理
在使用Flume的時候，需要運行Flume代理（Agent），因為Flume由一組以分布式拓撲結構相互連接的代理所組成。Flume代理是由持續運行的（數據來源）、Sink（數據目標）和（連接數據源和數據目標的渠道）所構成的進程。“代理們”是這樣運作的：產生事件并將其傳送給，存儲這些事件并轉發給Sink。這種--Sink的組合即為基本的Flume構件。因此，使用Flume的主要工作就是通過配置代理使得各個組件連接在一起。Flume工作過程大致如圖4所示。
圖4 Flume工作過程
在實際應用當中，可以采用多Agent串聯（一個接一個）的方式，也可以采用多Agent合并（并聯）的方式，此外，還可以對單一進行多種處理（即一個有多個和Sink），多種使用模式可任意挑選。
4、數據抽取工具
最大的優勢就在于能夠支持不同形式和不同來源的數據，并對其進行存儲和解析，進而抽取出相關信息將多個數據集組成非常有用的結果。目前的實際情況是很多有價值的數據都是以結構化形式存儲在許多組織的關系型系統中，如何將這些關系型所存儲的結構化數據抽取到平臺中；以用于進一步的分析處理，是一項重要且有意義的工作。這里，我們介紹一款專門用于數據抽取的工具Sqoop。
（1）Sqoop簡介
Sqoop是SQL-to-的縮寫，它也是生態系統中的一員，主要用于在和關系型（結構化存儲器）之間交換數據，可以改進數據的互操作性。通過Sqoop可以很方便地將數據從、等關系型中導入，或者將數據從導出到關系型中，使得傳統關系型和之間的數據遷移變得非常方便。Sqoop主要通過JDBC與關系型進行交互，理論上，支持JDBC的關系型都可以使用Sqoop與進行數據交互。Sqoop專門為集而設計，支持增量更新，可以將新記錄添加到最近一次導出的數據源上，或者指定上次修改的時間戳。Sqoop已經過兩個版本的發展，是命令行工具，不提供 API，很難嵌入其他程序中，其中所有的連接器都必須掌握所有輸出格式，而具有用以運行作業的組件和一整套客戶端，包括命令行接口、網站用戶界面、 API等，還能使用其他執行引擎（如Spark）。
（2）Sqoop基礎組件——連接器
Sqoop擁有一個可擴展的框架，使得它可以從（向）任何支持批量數據傳輸的外部存儲系統中導入（導出）數據。一個Sqoop連接器（）就是這個框架下的基礎模塊化組件，用于支持Sqoop的導入和導出。這種連接器有很多種類，比如通用的JDBC連接器可以連接所有支持JDBC協議的，還有針對、、DB2、 SQL 等關系型的專用連接器。這些常用的連接器一般會內置在Sqoop中。還有很多針對各種數據存儲器的第三方連接器可以使用，如支持企業級數據倉庫如和NoSQL存儲器的連接器，它們往往需要另外單獨下載安裝。
（3）Sqoop的工作原理
Sqoop最重要的功能就是把數據導入。它通過一個作業從中導入一個表，這個作業從表中抽取一行行記錄，然后將記錄寫入HDFS中，圖5展示了Sqoop的導入過程。
圖5 Sqoop導入過程
在向HDFS導入數據時，最重要的是確保訪問的數據源是一致的，而從中并行讀取數據的Map任務分布運行在不同的進程中，因此不可能共享同一個事務。保持一致性的最好方法就是在導入時不允許運行任何對表中現有數據進行更新的進程。
Sqoop的導出功能架構與其導入功能架構非常相似。在執行導出操作之前，Sqoop會根據連接字符串來選擇一個導出方法，對于大多數系統來說，Sqoop都會選擇JDBC；然后Sqoop會根據目標表的定義生成一個類（class），這個類能從文本文件中解析出記錄，并且能夠向表中插入類型合適的值；然后會啟動一個作業，從HDFS中讀取源數據文件，使用生成的類解析出記錄，并且執行選定的導出方法。圖6展示了使用并行執行導出的過程。
圖6 Sqoop導出過程
5、分布式消息隊列系統
在大規模分布式系統中常使用消息隊列，它是在消息傳輸過程中保存消息的容器或，主要目的是提供消息路由、數據分發并保障消息可靠傳遞，為分布式系統的各個構件之間傳遞消息并提供承載。目前常見的分布式消息隊列產品有Kafka、、和等。從性能和可擴展性上看，、Kafka、、依次遞減。從功能種類和應用廣度上看和強于Kafka和。綜合比較的話，與和相比較Kafka算是輕量級系統，同時又能提供消息持久化保證（不像），性能、高可用和可擴展方面表現也很優異，平均得分最高，目前應用場景較多，也非常適合用于平臺，因此我們重點介紹Kafka消息隊列。
（1）Kafka的產生背景
在系統中常常會遇到一個問題：整個由各個子系統組成，數據需要在各個子系統中高性能、低延遲地不停流轉。傳統的企業消息系統并不適合大規模數據處理。為了既能處理在線應用（消息），也能處理離線應用（數據文件和日志），Kafka應運而生。Kafka是開源的分布式消息隊列系統，誕生于2010年，具有極高的吞吐量和較強的擴展性和高可用性，主要用于處理活躍的流式數據。
最初，Kafka被用于進行日志收集、用戶行為實時收集以及機器狀態監控等，后來，還可作為流式計算系統的底層構件，如的流式計算系統Samza就是構建在Kafka和YARN之上的。對于像這樣的傳統日志分析系統，其能夠提供離線處理日志消息的能力，但要是進行實時處理，就會有較大延遲，而通過的并行加載機制加載Kafka消息隊列系統后就能夠統一線上和離線的消息，提供實時或近實時消息處理能力。總的來說，Kafka可以起到兩個作用：一是降低系統組網復雜度，二是降低復雜度，各個子系統不再是相互協商接口，各個子系統類似插口插在插座上，Kafka承擔高速數據總線的作用。
（2）Kafka的整體架構
Kafka的整體架構非常簡單，是顯式的分布式架構，主要涉及三個角色：
消息生產者（）：消息（）和數據的生產者，產生特定主題（Topic）的消息并傳入代理集群。
代理服務器（）：也稱緩存代理，是Kafka集群中的一臺或多臺。
消息消費者（）：消息和數據消費者，訂閱Topic并處理其發布的消息。
Kafka的架構如圖7所示。
圖7 Kafka整體架構圖
其中，、和都可以有多個。和實現Kafka注冊的接口，數據從發送到，承擔一個中間緩存和分發的作用。的作用類似于緩存，是活躍的數據和離線處理系統之間的緩存，主要把數據分發注冊到系統中的。客戶端和端的通信是基于簡單、高性能且與語言無關的實現的。
（3）Kafka消息發送流程
Kafka消息發送流程如圖8所示。
圖8 Kafka消息發送流程
首先補充一個基本概念——（分區），它是Topic物理上的分組，一個Topic可以分為多個，每個是一個有序、可持續添加的隊列，中的每條消息都會被分配一個有序的序列號id，稱之為（偏移量），在每個中此偏移量都是唯一的。
Kafka消息發送的流程大致為：根據指定的分區方法（例如Round-robin、Hash等），將消息發布到指定Topic的中；Kafka集群接收到發過來的消息后，將其持久化到硬盤，并保留消息指定時長（可配置），而不關注消息是否被消費；從Kafka集群里pull（拉）數據，并控制獲取消息的。
（4）Kafka的主要特點
Kafka有以下幾個主要特點：
● 同時為發布和訂閱提供高吞吐量。據了解，Kafka每秒可以生產約25萬條消息（50 MB），每秒處理55萬條消息（110 MB）。
● 可進行持久化操作。將消息持久化到磁盤，因此可用于批量消費，如ETL等。通過將數據持久化到硬盤以及實現多副本，從而防止數據丟失。
● 分布式系統，易于向外擴展，可以與結合。所有的、和都會有多個，均為分布式的，無需停機即可擴展機器。
● 消息被處理的狀態是在端維護，而不是由端維護，當失敗時能自動平衡。
● 支持在線應用和離線應用的場景。
（5）Kafka的應用場景
Kafka的應用場景主要有以下幾種：
消息隊列：比起大多數傳統的消息系統，如或，Kafka有更好的吞吐量、內置的分區、冗余及容錯性，這使得Kafka成為一個很好的大規模消息處理應用的解決方案。普通的消息系統一般吞吐量相對較低，當需要更小的端到端延時的時候，可依賴于Kafka提供的強大的持久性保障。
行為跟蹤：可用于跟蹤用戶瀏覽頁面、搜索及其他行為，以發布–訂閱的模式實時地記錄到對應的Topic中。當這些結果被訂閱者拿到后，就可以做進一步的實時處理或放到離線數據倉庫里進行處理。
日志收集：用于日志收集的開源系統有很多硬件信息收集 腳本，如前面介紹的Flume等。Kafka也能進行日志收集或者說是日志聚合，其特別之處在于，Kafka會忽略文件的細節，將其更清晰地抽象成一個個日志或事件的消息流，這就讓Kafka處理過程延遲更低，更容易支持多數據源和分布式數據處理，在提供同樣高效的性能的同時具有更高的耐用性。
數據監控和交換：可作為操作記錄的監控模塊來使用，即匯集和記錄一些操作信息。在很多組織的生態系統中可以把Kafka作為數據交換樞紐，將不同類型的分布式系統（如關系、NoSQL、離線系統、流處理系統、圖計算系統等）統一接入Kafka，從而實現與各個組件之間的不同類型數據的實時高速交換，很好地解決不同系統之間的數據生成/消費速率不同的問題。
流處理：這是最為廣泛的應用場景，通過收集并保存流式數據，提供之后與之對接的Storm或其他流式計算框架來進行處理。很多用戶會將原始Topic的數據進行階段性處理、匯總和擴充，或者以其他的方式轉換到新的Topic下再繼續后續處理，Storm和Samza就是非常著名的用于實現這種類型數據轉換的計算框架。
持久性日志：Kafka可以為一種外部的持久性日志的分布式系統提供服務。這種日志可以在節點間備份數據，并為故障節點數據恢復提供一種重新同步的機制，Kafka中的日志壓縮功能為這種用法提供了條件。