數(shù)據(jù)源：原始數(shù)據(jù)，支持各種類型的數(shù)據(jù)，如結構化數(shù)據(jù)，RDBMS、NOSQL、MQ中的數(shù)據(jù)，也可能是各種半結構化的數(shù)據(jù)，如HTML、PDF、TEXT等各種文檔或音頻、視頻等多媒體數(shù)據(jù)。同時，系統(tǒng)也支持配置URL，通過互聯(lián)網(wǎng)爬取的網(wǎng)頁數(shù)據(jù)。

知識管理：知識管理的核心在于對多源異構的數(shù)據(jù)建立統(tǒng)一的模型，并將不同的源數(shù)據(jù)映射到統(tǒng)一的知識模型上，最后配置知識的融合規(guī)則與沖突解決規(guī)則，以形成統(tǒng)一的知識體系。

知識存儲：核心的知識庫，原始數(shù)據(jù)經(jīng)過離線或?qū)崟rETL處理后的轉(zhuǎn)換為知識，并與庫中存量數(shù)據(jù)按照模型的配置進行知識拉通、融合、沖突解決后，供上游系統(tǒng)消費。

后臺管理：實現(xiàn)對系統(tǒng)的監(jiān)控、告警、日志審計以及資源管理、調(diào)度管理，并對采集到的數(shù)據(jù)進行統(tǒng)計分析，以改善整個動態(tài)知識圖譜的運作效率。

知識應用：支持全局知識庫聯(lián)合搜索、圖譜分析、地圖分析、知識的多維度分析、多人多機協(xié)同分析以及戰(zhàn)法分析，除通用的各種分析手段外，還支持特定行業(yè)的定制化分析應用。

由上可知，整個架構中最重要的部分為以知識管理為核心的知識圖譜建模方式，以及知識存儲為核心的動態(tài)存儲設計，本文也將著重對以上兩點進行解讀。

以知識管理為核心的知識圖譜建模

本體模型是數(shù)據(jù)世界對現(xiàn)實世界的映照，同時也是一種數(shù)據(jù)的分類、建模方式。在實際項目中，用戶面對著海量多源的、異構的數(shù)據(jù)，非常難以進行數(shù)據(jù)分析。

為了解決這一問題，本項目引入了本體模型，對異構數(shù)據(jù)進行統(tǒng)一建模，并在字段級別進行了歸一化，多源異構數(shù)據(jù)源通過抽取、轉(zhuǎn)換、清洗變成統(tǒng)一的本體模型后，可為上層應用或分析人員暴露更加友好的接口，從而提供便利。

值得注意的是，在本項目中，本體模型是由業(yè)務人員進行配置的。業(yè)務人員可以建立四種類型的本體，包括實體、事件、文檔、關系，具體解釋如下：

實體：能夠獨立存在的人或事物，例如：

1. 人物: 凡是可以用于標識“人”的東西，都可以當作人物，包括虛擬的社交賬號，實際中的手機號，具體的人等；

2. 物品: 包括真實的手機，電腦，各種真實物品；也包括IM工具，各類軟件等虛擬物品；

3. 組織: 包括真實的各類組織，如ISIS組織，政府單位，慈善組織等各類真實的組織；也包括QQ群，聊天室等各類虛擬組織；

4. 位置: 包括某具體的地理位置，如政府大樓；也包括LAC地址，IP地址等虛擬空間。

事件：有時間屬性，視為一種特殊的關系，用于連接實體與實體，實體與文檔。本項目中，事件主要指現(xiàn)實生活中的內(nèi)容，如發(fā)郵件、發(fā)短信、轉(zhuǎn)發(fā)帖子、發(fā)表評論等。

文檔：文檔特指非結構化文檔，如郵件中的各種格式的附件，包括但不限于PDF文檔、Word文檔，以及各種格式的視頻、音頻。

關系：用于連接實體之間，實體與事件、文檔等的相互關系，如人與人之間的親屬關系，人與物品之間的擁有關系，人與事件之間的主導關系。

在創(chuàng)建本體時，不光要指定本體的類型，還需要對本體所包含的字段與對應的字段類型進行配置，從而進行字段級別的歸一化。此項目支持的字段類型有date、long、int、double、string和geo。特殊字段還會進行數(shù)值的歸一化，如時間格式有多種表現(xiàn)形式，這里會轉(zhuǎn)換為統(tǒng)一的形式，方便后續(xù)處理。

以車管所數(shù)據(jù)為例，通過車管所的數(shù)據(jù)可以建立一種人-車-罰單的本體模型，人與車之間為擁有關系；人與罰單之間通過“闖紅燈”事件相連接，而罰單本身則以文檔的形式展現(xiàn)。完成本體模型后，就完成了對元數(shù)據(jù)的描述。

接下來，就需要將真實的數(shù)據(jù)映射到本體模型上。同時，要在字段級別上對多源異構數(shù)據(jù)進行歸一化。還以車管數(shù)據(jù)為例，具體過程如下圖所示，可以看出，通過本體映射將車管所3張表的數(shù)據(jù)映射到了 7個本體上（2個實體、3個關系、1個事件和1個文檔），并將車主名稱和姓名進行了統(tǒng)一，將日期的不同表示方式進行了歸一化。

通過以上建模過程，在應用側(cè)就建立了一個多源數(shù)據(jù)的統(tǒng)一的邏輯視圖，即從分析人員的角度對所有數(shù)據(jù)構建成了一個圖模型，分析人員無需關注底層數(shù)據(jù)源差異和存儲細節(jié)，只需關注如何在此圖模型上進行分析即可。

對于知識庫的存儲設計，由HBase核心存儲、Elasticsearch全文索引、neo4j關系索引組成。HBase存儲了完整的數(shù)據(jù)，Elasticsearch建立全文索引方便用戶搜索，neo4j建立關系索引，以加速關系查詢。

四種數(shù)據(jù)集成架構

以上內(nèi)容描述了整個數(shù)據(jù)模型構建的過程，任何數(shù)據(jù)要集成進來，必須先進行以上過程，在元數(shù)據(jù)層面進行拉通、融合。

接下來的問題就是如何將客戶的數(shù)據(jù)快速接入知識庫的存儲中去，以提供統(tǒng)一的數(shù)據(jù)查詢服務，也就是數(shù)據(jù)層面的集成。

由于數(shù)據(jù)具有多樣化特點：

從數(shù)據(jù)類型上看，存在結構化數(shù)據(jù)、半結構化數(shù)據(jù)、非結構化數(shù)據(jù)；

從業(yè)務價值上來看，又分為高價值密度數(shù)據(jù)，如賬戶信息、轉(zhuǎn)賬信息、低價值密度數(shù)據(jù)，如日志信息；

從數(shù)據(jù)規(guī)模上來看，有超大規(guī)模數(shù)據(jù)，如萬億級數(shù)據(jù)，大規(guī)模數(shù)據(jù)，如億級數(shù)據(jù)，小規(guī)模數(shù)據(jù)，如百萬級以下數(shù)據(jù)。

百分點經(jīng)歷多個大型數(shù)據(jù)集成項目洗禮后發(fā)現(xiàn)，通常高價值密度的數(shù)據(jù)，數(shù)據(jù)規(guī)模都不會太大。比如公安領域的重點人員數(shù)據(jù)、卡口設備數(shù)據(jù)、網(wǎng)絡安全領域的高危IP、重點監(jiān)控網(wǎng)站等“實體”數(shù)據(jù)，此類數(shù)據(jù)特征是數(shù)據(jù)量有限，價值密度高。

而如果數(shù)據(jù)規(guī)模超過10億級，通常都是“事件”類型的數(shù)據(jù)，比如車輛通過卡口的事件、手機連wifi的事件和手機上網(wǎng)的HTTP日志。這類數(shù)據(jù)還有一個典型特征，就是數(shù)據(jù)量巨大且無限增長，但數(shù)據(jù)價值密度很低，通常也只關心最近一段時間的日志。

因此，針對不同的數(shù)據(jù)場景，百分點提供了不同的數(shù)據(jù)集成方法，分別應對不同場景下的數(shù)據(jù)集成需求。

整體數(shù)據(jù)集成架構如下：

小規(guī)模數(shù)據(jù)集成：這類數(shù)據(jù)往往是客戶提供了小規(guī)模的樣本，通過前臺Import功能，直接上傳各種類型的文件，即可導入。

高價值密度數(shù)據(jù)集成：通常是客戶提供的關鍵數(shù)據(jù)，這類數(shù)據(jù)首先需要業(yè)務人員根據(jù)需求進行建模，然后通過后臺離線/實時數(shù)據(jù)流將數(shù)據(jù)接入到本體庫中。

低價值密度數(shù)據(jù)集成：通常是“事件”數(shù)據(jù)，數(shù)據(jù)量極大，并有一定時效性，需要定期House Keeping。當前的實現(xiàn)方式是通過存放在外部OLAP型數(shù)據(jù)庫中，應用層通過直連的方式進行adhoc查詢，將其中有價值的數(shù)據(jù)選擇性地導入到本體庫中。

互聯(lián)網(wǎng)半結構化數(shù)據(jù)集成：通過給定URL，會啟動后臺爬蟲，爬取對應的網(wǎng)頁進入知識庫，跟存量知識進行協(xié)同分析。

實現(xiàn)“動態(tài)性”的核心邏輯

百分點動態(tài)知識圖譜實現(xiàn)“動態(tài)性”的核心邏輯在于，采用元數(shù)據(jù)與存儲分離查詢的方案，來賦予知識圖譜“動態(tài)”特性，包含數(shù)據(jù)模型的動態(tài)性、模型變更的動態(tài)性、融合的動態(tài)性和“事件”數(shù)據(jù)的動態(tài)性。

1

數(shù)據(jù)模型的動態(tài)性

由于數(shù)據(jù)模型有一個專門的后臺管理系統(tǒng)進行配置管理，業(yè)務可以根據(jù)實際客戶需求進行模型設計與數(shù)據(jù)源接入，節(jié)省了大量開發(fā)成本。

2

模型變更的動態(tài)性

進行新增字段、修改字段、刪除字段，以及模型修改的時候，在應用端不用重新導入數(shù)據(jù)。

實現(xiàn)方式如下：

本體庫中的數(shù)據(jù)元數(shù)據(jù)的存儲與物理數(shù)據(jù)的存儲是分離的，應用層查詢MySQL獲取元數(shù)據(jù)并進行緩存，然后在Elasticsearch中檢索到數(shù)據(jù)后，會在應用層的內(nèi)存中進行元數(shù)據(jù)與物理數(shù)據(jù)的拼裝。

因此，當元數(shù)據(jù)變更后，只需要更新MySQL數(shù)據(jù)庫與應用層的緩存，無需對實際的物理數(shù)據(jù)進行變更。

這里需要注意的是，在Elasticsearch中存儲的是融合完成的數(shù)據(jù)。因此當融合規(guī)則變更后，需要重建索引。

3

融合的動態(tài)性

當融合規(guī)則變更后，只需要對特定表重建索引，無需重新導入用戶數(shù)據(jù)。

這是因為，在HBase中是按照每種本體類型一張表進行存儲的，而需要融合的數(shù)據(jù)必然是多個源的數(shù)據(jù)寫到HBase的一張表中，HBase的rowkey設計為MD5(PK)，而column設計為數(shù)據(jù)源ID，因此若多源數(shù)據(jù)存在相同的主鍵，則會存儲到HBase同一行的不同列中。而后續(xù)的ETL任務，則會將多列的數(shù)據(jù)按照融合規(guī)則進行融合后在Elasticsearch中建立索引。

由此可見，不同本體數(shù)據(jù)寫入互不影響，而同一本體新增數(shù)據(jù)源，若發(fā)生融合，會寫入到不同列中。此時下一次ETL任務就會用新的數(shù)據(jù)覆蓋Elasticsearch中舊的數(shù)據(jù)，完成索引重建。而當融合規(guī)則發(fā)生變更時，同樣不需要再從客戶數(shù)據(jù)源接入數(shù)據(jù)，只需要進行索引重建即可。

4

“事件”數(shù)據(jù)的動態(tài)性

由于本體庫中的數(shù)據(jù)，是固化的高價值密度數(shù)據(jù)，而“事件”數(shù)據(jù)天然是低價值密度的，并且具有時效性。

因此，為了不“污染”本體庫，在實現(xiàn)中將事件數(shù)據(jù)存放到單獨的OLAP存儲中，用戶可以進行預分析，然后將其中具有價值的部分導入到本體庫中。

受益于這種分離存儲的架構，無需對客戶數(shù)據(jù)提前進行大量轉(zhuǎn)換、融合處理，單純的寫入OLAP存儲是十分高效的，對1KB數(shù)據(jù)能輕松達到10W+ TPS。在實際的場景中，客戶當天提供的數(shù)TB數(shù)據(jù)，第二天就能完成建模、接入到應用端可見。

總結與展望

在本文中，我們介紹了如何通過知識圖譜對多源異構的數(shù)據(jù)進行數(shù)據(jù)集成，以及百分點使用知識圖譜進行數(shù)據(jù)集成的幾種方案和如何通過元數(shù)據(jù)與存儲分離查詢的方案賦予知識圖譜“動態(tài)”的特性。

從實際項目的落地情況來看，這些特性和方案無疑能很好地助力客戶落地各種場景下的數(shù)據(jù)集成、分析需求。從另一個角度講，當前方案還是有很多進步空間的，比如目前應用層的開發(fā)還需要對底層知識庫的存儲方式有很深的認識，并且應用與底層存儲耦合嚴重，若底層架構需要升級往往會影響到所有的下游應用。

未來，可將底層知識庫進行邏輯抽象，封裝出統(tǒng)一查詢層API，應用層可以像使用圖數(shù)據(jù)庫一樣使用知識庫，簡化與解耦應用層開發(fā)，也可助力快速開發(fā)行業(yè)應用。另外，外部的“事件”庫如何更好的與本體庫進行協(xié)同、統(tǒng)一管理，也是目前百分點進一步探索的方向。

xiesc

<tr id="tqhyc"></tr>