基于 Spark 和SimHash算法的文章原創(chuàng)性檢測系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

摘要：傳統(tǒng)的基于文本的原創(chuàng)性檢測建立在平臺的投稿機(jī)制上，無法對現(xiàn)存的文章進(jìn)行原創(chuàng)性檢測。文章提出了基于Spark和SimHash算法的文章原創(chuàng)性檢測系統(tǒng)，利用大數(shù)據(jù)技術(shù)進(jìn)行非原創(chuàng)文章和原創(chuàng)文章配對，實(shí)現(xiàn)動(dòng)態(tài)“閱讀原文”功能。

關(guān)鍵詞：Spark ;原創(chuàng)性檢測; SimHash

中圖法分類號：TP391文獻(xiàn)標(biāo)識碼：A

Design and implementation of article originality detection system based onSpark and SimHash

Li Changdong

（East China Normal University，Shanghai 200241，China）

Abstract：The traditional text-based originality detection is based on the contribution mechanism of theplatform，which can not detect the originality of existing articles.This paper proposes an article originalitydetection system based on spark and SimHash algorithm，which uses big data technology to pair non-originalarticles and original articles to realize the function of “reading the original text”dynamically.

Key words： Spark ， originality detection，SimHash

1? 背景

互聯(lián)網(wǎng)內(nèi)容平臺是內(nèi)容的聚集地。隨著知識付費(fèi)等創(chuàng)新模式的普及，很多作者希望通過文章寫作的方式獲取粉絲、流量、打賞、獎(jiǎng)勵(lì)等。正是因?yàn)樵诨ヂ?lián)網(wǎng)內(nèi)容平臺進(jìn)行文章寫作可以帶來收益，很多公司或者個(gè)人選擇使用抄襲、改編、洗稿等手段將外部平臺的優(yōu)質(zhì)原創(chuàng)內(nèi)容轉(zhuǎn)變成“自己的作品”，借此不斷提升公司或者個(gè)人在平臺內(nèi)的影響力。然而，抄襲、搬運(yùn)、非授權(quán)轉(zhuǎn)載等手段極大地打擊了原創(chuàng)文章作者的寫作積極性和熱情。

2? SimHash文本相似度計(jì)算方法

相似哈希（ SimHash）是最早由谷歌于2007年的論文[1]中提出的，用于檢測長文本相似度。SimHash是一種局部敏感哈希，其哈希值在一定程度上可以表示文本特征。SimHash的設(shè)計(jì)思路是將文本轉(zhuǎn)化為特征向量的形式，將高維特征向量轉(zhuǎn)化為低維特征向量，最終通過哈希值之間的海明距離大小判斷文本間的相似性。根據(jù)谷歌論文中的結(jié)論，在64位SimHash簽名場景中，當(dāng)兩個(gè)文本的海明距離小于等于3 時(shí)，可以被認(rèn)為是相似的。依據(jù)抽屜原理，海明距離小于等于3 為相似判定標(biāo)準(zhǔn)時(shí)，在分成4 段的情況下，至少有一段簽名完全相同。

從實(shí)驗(yàn)角度比較SimHash指紋不分段和分為4 段的執(zhí)行效率，如圖 1 所示。實(shí)驗(yàn)步驟如下：（1 ） SparkSQL讀取數(shù)據(jù)庫內(nèi)數(shù)據(jù)，并暫存于內(nèi)存中;（2）生成一個(gè)SimHash指紋，并與數(shù)據(jù)庫內(nèi)數(shù)據(jù)指定數(shù)據(jù)量的數(shù)據(jù)進(jìn)行相似度計(jì)算，結(jié)果中僅保留海明距離小于等于3 的數(shù)據(jù);（3）分別測量SimHash指紋不分段（Divide By 1）和分為4 段（Divide By 4）時(shí)的執(zhí)行時(shí)間。

從圖1 可以看出，使用分段方式篩選后，有效減少了指紋的比較數(shù)量，提升了SimHash算法相似度計(jì)算效率。

3? 系統(tǒng)需求分析

系統(tǒng)的目標(biāo)是使用大數(shù)據(jù)技術(shù)對內(nèi)容進(jìn)行原創(chuàng)性檢測，建立原創(chuàng)文章和非原創(chuàng)文章之間的關(guān)聯(lián)關(guān)系，將檢測結(jié)果提供給每一個(gè)希望從互聯(lián)網(wǎng)內(nèi)容平臺查看優(yōu)質(zhì)內(nèi)容的用戶，可最終實(shí)現(xiàn)提升原創(chuàng)作者利益與提升普通用戶使用體驗(yàn)的效果。

系統(tǒng)用戶角色可以分為四類，即谷歌瀏覽器插件用戶、版權(quán)管理服務(wù)普通用戶、版權(quán)管理服務(wù)審核員、版權(quán)管理服務(wù)系統(tǒng)管理員。

（1）谷歌瀏覽器插件用戶

在用戶瀏覽搜索引擎的結(jié)果頁面時(shí)，不需要打開結(jié)果鏈接即可知道鏈接關(guān)聯(lián)的文章的各種分析數(shù)據(jù)，包括文章狀態(tài)、文章版權(quán)說明、文章最近似的原創(chuàng)文章等。如果某篇文章被系統(tǒng)認(rèn)定為非原創(chuàng)文章用戶，可以點(diǎn)擊谷歌瀏覽器插件提供的原文鏈接跳轉(zhuǎn)到原創(chuàng)文章的地址。在用戶瀏覽互聯(lián)網(wǎng)內(nèi)容平臺時(shí)，谷歌瀏覽器插件會(huì)自動(dòng)收集網(wǎng)頁內(nèi)所有鏈接地址，篩選出符合文章類型的網(wǎng)頁并定時(shí)發(fā)送至后端服務(wù)。

（2）版權(quán)管理服務(wù)普通用戶

普通用戶可以在版權(quán)管理服務(wù)中提交已經(jīng)擁有的文章版權(quán)信息，由專業(yè)審核人員進(jìn)行版權(quán)信息真實(shí)性、一致性校驗(yàn)。在通過版權(quán)認(rèn)證后，文章會(huì)在谷歌瀏覽器插件中顯示為原創(chuàng)文章，并帶有版權(quán)標(biāo)志。

（3）版權(quán)管理服務(wù)審核員

審核員負(fù)責(zé)審核用戶提交的版權(quán)申請并進(jìn)行真實(shí)性、一致性校驗(yàn)。

（4）版權(quán)管理服務(wù)系統(tǒng)管理員

系統(tǒng)管理員負(fù)責(zé)管理普通用戶信息、管理審核員信息、審核版權(quán)申請、查看審核日志。

系統(tǒng)用例圖如圖2 所示。

4? 系統(tǒng)整體設(shè)計(jì)

本系統(tǒng)可以劃分成五個(gè)服務(wù)，即谷歌瀏覽器拓展程序、爬蟲服務(wù)、后端服務(wù)、版權(quán)管理服務(wù)、Spark 分析服務(wù)。本文主要介紹其中的后端服務(wù)與 Spark 分析服務(wù)。

谷歌瀏覽器拓展程序?yàn)橛脩籼峁?shí)時(shí)查詢最近一次文章原創(chuàng)性分析結(jié)果的功能;爬蟲服務(wù)為系統(tǒng)提供文章的原始數(shù)據(jù)，包括文章發(fā)布時(shí)間、文章正文內(nèi)容、文章標(biāo)題等;后端服務(wù)提供 HTTP 請求接口，用于接收用戶側(cè)提交的網(wǎng)頁地址。提交接口有兩種，一種用于查詢某些文章的原創(chuàng)性檢測結(jié)果，另一種用于捕捉未被數(shù)據(jù)庫收錄的互聯(lián)網(wǎng)內(nèi)容平臺文章鏈接。后端服務(wù)起到服務(wù)間溝通的作用，通過 Kafka 消息隊(duì)列向爬蟲服務(wù)發(fā)送爬蟲任務(wù)請求并監(jiān)聽爬蟲任務(wù)執(zhí)行結(jié)果、向 Spark 分析服務(wù)發(fā)送 Spark 分析任務(wù)請求并監(jiān)聽 Spark 分析任務(wù)執(zhí)行結(jié)果;版權(quán)管理服務(wù)提供一套人工審核文章版權(quán)信息的管理方案，用戶負(fù)責(zé)提交版權(quán)申請，審核員負(fù)責(zé)審核版權(quán)申請的真實(shí)性與一致性;Spark 分析服務(wù)通過大數(shù)據(jù)方法建立原創(chuàng)文章與非原創(chuàng)文章之間的關(guān)聯(lián)，通過 Kafka 消息隊(duì)列接收 Spark 分析請求和發(fā)送 Spark 分析結(jié)果。

5? 后端系統(tǒng)實(shí)現(xiàn)

后端服務(wù)是一組運(yùn)行在 Docker 容器中的服務(wù)，并且以 Linux 系統(tǒng)中的 Open JDK11作為容器內(nèi)的運(yùn)行環(huán)境。后端服務(wù)對外主要提供提交接口 （路徑/ submit）—用于查詢一組文章的原創(chuàng)性檢測結(jié)果和定時(shí)提交接口（路徑/schedule/submit）—用于盡最大努力發(fā)現(xiàn)未知的鏈接，捕捉未被數(shù)據(jù)庫收錄的互聯(lián)網(wǎng)內(nèi)容平臺文章鏈接。

后端服務(wù)的主要接口包括：后端服務(wù)提交接口和后端服務(wù)定時(shí)提交接口。

（1）后端服務(wù)提交接口

后端服務(wù)提交接口負(fù)責(zé)向用戶提供最近一次的文章原創(chuàng)性檢測結(jié)果。當(dāng)用戶發(fā)送一組請求鏈接后，所有符合條件的鏈接根據(jù)互聯(lián)網(wǎng)內(nèi)容平臺的文章網(wǎng)頁正則表達(dá)式規(guī)則進(jìn)行匹配，并篩選出不重復(fù)的鏈接。匹配成功后根據(jù)響應(yīng)緩存記錄和爬蟲任務(wù)緩存記錄判斷下一步的操作。如果響應(yīng)緩存記錄不存在，則向 Kafka 的 update 主題發(fā)送異步消息，通知更新響應(yīng)緩存記錄，執(zhí)行 Spark 分析任務(wù)。如果爬蟲任務(wù)緩存記錄不存在，則向 Kafka 的spidertask主題發(fā)送異步消息，通知爬蟲服務(wù)爬取文章的原始數(shù)據(jù)。

（2）后端服務(wù)定時(shí)提交接口

后端服務(wù)定時(shí)提交接口負(fù)責(zé)接收來自用戶的各種鏈接。與提交接口類似，定時(shí)提交接口也使用正則表達(dá)式規(guī)則對鏈接進(jìn)行匹配，并從地址中篩選出符合互聯(lián)網(wǎng)內(nèi)容平臺文章網(wǎng)頁地址特點(diǎn)的地址。與提交接口不同的是，定時(shí)提交接口僅通過爬蟲緩存記錄執(zhí)行不同的操作。當(dāng)爬蟲緩存記錄存在時(shí)不進(jìn)行任何處理;當(dāng)爬蟲緩存記錄不存在時(shí)向 Kafka 的spidertask主題發(fā)送異步消息，通知爬蟲服務(wù)爬取文章的原始數(shù)據(jù)。

6? Spark 分析服務(wù)實(shí)現(xiàn)

Spark 分析服務(wù)通過監(jiān)聽 Kafka 主題sparktask獲取來自后端系統(tǒng)的 Spark 分析任務(wù)。借助 Spark Streaming 和 Spark SQL 技術(shù)，Spark 分析服務(wù)可以定時(shí)獲取并解析 Spark 分析任務(wù)的 Kafka 消息，從大數(shù)據(jù)角度進(jìn)行文章原創(chuàng)性檢測。

詳細(xì)運(yùn)行機(jī)制如下：（1）關(guān)系型數(shù)據(jù)庫篩選并讀取所有原創(chuàng)文章;（2）從原創(chuàng)文章的集合中查詢所有與請求信息中文章的SimHash簽名距離小于 K 的原創(chuàng)文章的集合;（3）從第2 步的結(jié)果集合中分別按照文本相似度優(yōu)先和時(shí)間優(yōu)先的多維排序規(guī)則找到相關(guān)的原創(chuàng)文章。

針對排序規(guī)則，實(shí)踐后發(fā)現(xiàn)，文章發(fā)布時(shí)間的精度無法完全統(tǒng)一并且存在作者“一稿多投”的情況。基于此，本系統(tǒng)引入版權(quán)標(biāo)識與文章瀏覽量作為額外的排序條件。通常來說，經(jīng)過人工版權(quán)審核的文章一定是原創(chuàng)文章;未完成版權(quán)審核的文章，在平臺推送機(jī)制下或者瀏覽器搜索排名機(jī)制下，瀏覽量越高的文章往往被看作原創(chuàng)文章。因此，只有采用多維度立體式的分析方法才能在實(shí)踐中找到最貼合實(shí)際的原創(chuàng)文章判斷的標(biāo)準(zhǔn)。

7? Spark 分析服務(wù)優(yōu)化

根據(jù)新榜2019年微信公眾號大數(shù)據(jù)信息，2019年發(fā)表的原創(chuàng)文章占2019年發(fā)表的文章總數(shù)的6%以下。根據(jù)上述信息可以推測，隨著年份的增加，原創(chuàng)文章的增長速率遠(yuǎn)小于文章總數(shù)的增長速率，那么原創(chuàng)文章的數(shù)量級保持在一個(gè)穩(wěn)定的范圍內(nèi)。讀取原創(chuàng)文章可以最小化數(shù)據(jù)庫記錄讀取數(shù)量，不必將所有記錄全部加載至數(shù)據(jù)庫。因?yàn)?Spark 分析服務(wù) SQL查詢中僅涉及排序和篩選操作，數(shù)據(jù)量非常大，符合聯(lián)機(jī)分析處理（On ?Line Analytical Processing）的場景。MySQL 數(shù)據(jù)庫盡管擁有價(jià)格低廉、性能穩(wěn)定的特性，但是在頻繁讀取大量數(shù)據(jù)的場景下并不能為系統(tǒng)帶來處理時(shí)間上的增益。ClickHouse是一款開源的列式數(shù)據(jù)庫，其以優(yōu)異的查詢速率而聞名。在帶寬相同的情況下，ClickHouse讀取數(shù)據(jù)的速率遠(yuǎn)超 MySQL 等傳統(tǒng)行式數(shù)據(jù)庫。

經(jīng)過實(shí)驗(yàn)，以100萬條測試數(shù)據(jù)為例，隨機(jī)傳入1000條分析請求，除去讀取請求的時(shí)間，ClickHouse方案平均耗時(shí) 94s ，MySQL 方案平均耗時(shí) 135s。ClickHouse方案速度快的原因如下：一方面ClickHouse數(shù)據(jù)加載速度快;另一方面數(shù)據(jù)幾乎全部在內(nèi)存中執(zhí)行各種操作，處理一條請求的速度是 MySQL 方案的1.5倍。ClickHouse的數(shù)據(jù)庫表結(jié)構(gòu)如下：

數(shù)據(jù)庫設(shè)計(jì)的思路是在ClickHouse內(nèi)對每一個(gè) id 維持一份最新版本的數(shù)據(jù)，所有讀取到的數(shù)據(jù)都是最新版本數(shù)據(jù)。由于ClickHouse自身的結(jié)構(gòu)不支持唯一主鍵，并且不支持?jǐn)?shù)據(jù)刪除，因此需要為ClickHouse設(shè)計(jì)一套適合特性的處理邏輯。ClickHouse的VersionedCollapsingMergeTree引擎可通過標(biāo)識位和版本號機(jī)制實(shí)現(xiàn)數(shù)據(jù)版本折疊功能。在查詢的時(shí)候需要執(zhí)行分組與聚合操作，ClickHouse SQL 示例如下：

8? 結(jié)束語

隨著各類技術(shù)的不斷發(fā)展，相信未來版權(quán)保護(hù)方面一定會(huì)有更新更完善的方法，讓每一個(gè)擁有原創(chuàng)文章的創(chuàng)作者獲益。

參考文獻(xiàn)：

[1] Manku G S ，Jain A ，Das Sarma A.Detecting near?duplicates for web crawling [ C]∥ International? Conference? on World Wide Web.ACM ，2007：141.

作者簡介：

李昌東（1996—） ，碩士，研究方向：大數(shù)據(jù)技術(shù)。