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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

從業(yè)務(wù)價值上來看，又分為高價值密度數(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ī)模都不會太大。比如公安領(lǐng)域的重點人員數(shù)據(jù)、卡口設(shè)備數(shù)據(jù)、網(wǎng)絡(luò)安全領(lǐ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ù)價值密度很低，通常也只關(guān)心最近一段時間的日志。

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

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

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

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

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

互聯(lián)網(wǎng)半結(jié)構(gòu)化數(shù)據(jù)集成：通過給定URL，會啟動后臺爬蟲，爬取對應(yīng)的網(wǎng)頁進(jìn)入知識庫，跟存量知識進(jìn)行協(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)進(jìn)行配置管理，業(yè)務(wù)可以根據(jù)實際客戶需求進(jìn)行模型設(shè)計與數(shù)據(jù)源接入，節(jié)省了大量開發(fā)成本。

2

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

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

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

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

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

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

3

融合的動態(tài)性

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

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

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

4

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

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

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

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

總結(jié)與展望

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

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

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

xiesc