網(wǎng)購、叫車、訂外賣、看電影...... 移動互聯(lián)網(wǎng)各種場景的背后都離不開大數(shù)據(jù)技術(shù)。經(jīng)過十幾年的發(fā)展，大數(shù)據(jù)技術(shù)已經(jīng)成為互聯(lián)網(wǎng)企業(yè)的基礎(chǔ)設(shè)施。

源起谷歌“三駕馬車”

聊起大數(shù)據(jù)，就繞不開谷歌的“三駕馬車“。早在 2003 年，谷歌發(fā)表第一篇論文——谷歌文件系統(tǒng)（GFS）；第二年，谷歌再次發(fā)表一篇論文——分布式計算框架 MapReduce；2006 年，谷歌發(fā)表第三篇論文——NoSQL 數(shù)據(jù)庫系統(tǒng) BigTable。這三篇論文由此開啟了大數(shù)據(jù)時代。

徐飛在《大數(shù)據(jù)浪潮之巔：新技術(shù)商業(yè)制勝之道》一書中寫道，“通過‘三駕馬車’這一利器，谷歌具備了存儲和分析海量數(shù)據(jù)的能力，其個性化廣告系統(tǒng)猶如永動的印鈔機(jī)，不斷為谷歌賺取財富?！?/p>

受谷歌“三駕馬車”的影響，其他互聯(lián)網(wǎng)公司也在嘗試大規(guī)模分布式系統(tǒng)，希望構(gòu)建強(qiáng)大的數(shù)據(jù)存儲、分析和處理平臺。不過，當(dāng)時正處于前 Hadoop 時期，互聯(lián)網(wǎng)公司基本上都在摸著石頭過河。

數(shù)據(jù)收集和計算領(lǐng)域的先驅(qū)

在眾多的互聯(lián)網(wǎng)公司中，成立于 2006 年的秒針系統(tǒng)無疑是這個領(lǐng)域的先行者。據(jù)秒針系統(tǒng)產(chǎn)研中心負(fù)責(zé)人劉沛介紹，2008 年 Hadoop 還沒有成熟，他們從零研發(fā)了自己的大數(shù)據(jù)平臺，“思路跟 Hadoop MapReduce 類似，一天也能處理幾十億數(shù)據(jù)”。劉沛在 2007 年加入秒針，那時他還在讀大三。一年后，他正式畢業(yè)，留在秒針系統(tǒng)。他先后領(lǐng)導(dǎo)了包括廣告監(jiān)測系統(tǒng) AdMonitor 等核心產(chǎn)品的研究和開發(fā)。作為秒針系統(tǒng)的老人，他見證了秒針系統(tǒng)大數(shù)據(jù)平臺從 0 到 1 的過程。

據(jù)悉，秒針系統(tǒng)的業(yè)務(wù)是廣告監(jiān)測，核心產(chǎn)品是 AdMonitor。在 AdMonitor 的服務(wù)鏈路中，前端負(fù)責(zé)收集數(shù)據(jù)。每個廣告會被嵌入一個發(fā)送到秒針系統(tǒng)域名的代碼。一旦廣告在媒體端被點(diǎn)擊，它就會把被嵌入的代碼發(fā)回到秒針系統(tǒng)的服務(wù)器。這樣，系統(tǒng)就知道完成了一次廣告曝光。這樣的一個廣告業(yè)務(wù)流程主要涉及數(shù)據(jù)采集、數(shù)據(jù)存儲、數(shù)據(jù)計算和數(shù)據(jù)分析技術(shù)。

多端收集數(shù)據(jù)

那么，第一個問題來了，秒針系統(tǒng)怎么收集數(shù)據(jù)？據(jù)劉沛介紹，在 PC 時代，大多使用 JavaScript 來采集數(shù)據(jù)。這就要求秒針系統(tǒng)的產(chǎn)品要適配每一個瀏覽器，包括 Firefox、IE、傲游瀏覽器、海豚瀏覽器等。據(jù)悉，cookie 是當(dāng)時數(shù)據(jù)收集使用的主要技術(shù)之一。除 cookie 之外，結(jié)合 Flash。那時，幾乎所有的廣告都是 Flash，因為 Flash 本身是一個可執(zhí)行程序，所以能在其內(nèi)部編程，把監(jiān)測代碼放在里面，收集數(shù)據(jù)。

劉沛表示，“Flash 也有 cookie 的概念，技術(shù)術(shù)語叫 FSO。把 FSO 和 cookie 做各種聯(lián)動，實現(xiàn)持久化。這邊刪了，那邊能恢復(fù)；那邊刪了，這邊再恢復(fù)。在保護(hù)用戶隱私的前提下更精準(zhǔn)地識別出一個獨(dú)立用戶?！?/p>

到了 2012 年，智能手機(jī)出現(xiàn)，Android 和 iOS App 數(shù)量不斷增多，秒針系統(tǒng)又在 AdMonitor 產(chǎn)品中增加移動端廣告測量能力。SDK 技術(shù)成為當(dāng)時移動端數(shù)據(jù)收集的主要方式。劉沛稱，“Android、iOS 都是新事物，不僅要學(xué)習(xí)新的編程語言，還要面對新技術(shù)環(huán)境進(jìn)行開發(fā)。做出一款應(yīng)用后，要適配廠商不同機(jī)型的不同型號。除硬件外，還要適應(yīng)手機(jī)上運(yùn)行的各種 App”。

舉個例子，愛奇藝、優(yōu)酷和騰訊視頻是三大主流視頻 App。SDK 要在之上運(yùn)行，前期要做各種對接測試，保證運(yùn)轉(zhuǎn)正常?！安荒茏?App 死機(jī)，也不能拖慢了它的系統(tǒng)運(yùn)轉(zhuǎn)。另外，數(shù)據(jù)采集結(jié)果要和他們上報的一致。因此，每加入一款主流 App，都得做技術(shù)對接和數(shù)據(jù)測試。”他說。

2012 年 8 月，秒針系統(tǒng)正式推出中國第一個移動端廣告加載 SDK，“很快就被加進(jìn)了主流的 App 中”。

用 RAID 5 搞定數(shù)據(jù)存儲難題

時任秒針系統(tǒng)大數(shù)據(jù)平臺運(yùn)維負(fù)責(zé)人任鑫琦向 InfoQ 記者透露，秒針系統(tǒng)的業(yè)務(wù)量當(dāng)時非常大，占到全國所有廣告監(jiān)測流量的 60%，收集數(shù)據(jù)的服務(wù)器每天 PV 量超過 100 億。

這么多數(shù)據(jù)，如何存儲？據(jù)劉沛介紹，當(dāng)時使用了 RAID（獨(dú)立磁盤冗余陣列）技術(shù)，具體說是 RAID 5 技術(shù)：數(shù)據(jù)在寫入磁盤時，將數(shù)據(jù)分成 N-1 份，并發(fā)寫入 N-1 塊磁盤，校驗數(shù)據(jù)螺旋式寫入所有磁盤。這樣保證了 RAID 5 既有較快的訪問速度，又有較高的數(shù)據(jù)可靠性。

用劉沛的話解釋，“一個集群中，一份數(shù)據(jù)被切片后存在不同地方。如果一塊磁盤銷毀了，還能從別處恢復(fù)”。

百億規(guī)模的數(shù)據(jù)計算問題，怎么解？

數(shù)據(jù)收集上來后，關(guān)鍵是數(shù)據(jù)計算。任鑫琦介紹，計算分為兩類：第一類是按小時進(jìn)行批量計算，這要求平臺具備大規(guī)模數(shù)據(jù)的處理能力。第二類是實時計算，這要保證實時計算的可靠性，否則計算延遲，“客戶看到的數(shù)據(jù)就不準(zhǔn)確”。

據(jù)悉，秒針系統(tǒng)當(dāng)時一天有 100 多億數(shù)據(jù)。其單臺日志服務(wù)器的承載性能是“滿負(fù)荷運(yùn)行，一天可以處理 4 個億的數(shù)據(jù)”。實際中，一般按照 50% 的負(fù)載使用率，即一臺日志服務(wù)器一天要處理 2 億數(shù)據(jù)。這樣算下來，大概需要 50 臺日志服務(wù)器。

當(dāng)數(shù)據(jù)量超過一臺服務(wù)器的承載能力時，前端要分成很多臺服務(wù)器做負(fù)載均衡。比如，監(jiān)測代碼加在各種各樣的媒體上，每個廣告主在多個媒體上投放，而每個媒體同時又承載多個廣告主，每個媒體又有不同的廣告位，“所以要把這些全部用監(jiān)測代碼 ID 索引好”。

劉沛稱，“每個廣告被曝光或點(diǎn)擊時，這條請求是發(fā)到了哪臺服務(wù)器，都要有一套統(tǒng)一的調(diào)度規(guī)則，保證每臺服務(wù)器的承壓一致，保證每臺服務(wù)器分工合理。這樣整體性能就會最好”。

在數(shù)據(jù)計算架構(gòu)上，由于 Hadoop 當(dāng)時不成熟，所以秒針系統(tǒng)使用了一個開源的分布式文件系統(tǒng) KFS。任鑫琦說：“基于 KFS，我們沒有用 Hadoop 零點(diǎn)幾版本的架構(gòu)，因為不太穩(wěn)定，其管理節(jié)點(diǎn)不是高可用的?！盚adoop 在 2.0 版本之前，其 NameNode 只有一個，一旦壞了，整個集群就會崩潰。所以，自己維護(hù)了一套分布式計算任務(wù)的調(diào)度工具，把順序調(diào)度和背序調(diào)度相結(jié)合，再加入一些針對局部的調(diào)度技巧和優(yōu)化。

Hadoop 助力，技術(shù)能力再上一層樓

2012 年，Hadoop 發(fā)布 2.0 版本。它是一套全新架構(gòu)，包含 HDFS Federation 和 Yarn 兩個系統(tǒng)。相比 1.0 版本，它更穩(wěn)定，也更成熟。因此，秒針系統(tǒng)開始逐漸采用。但系統(tǒng)遷移并不是那么容易，花了一年的時間才成功切換到 Hadoop 上。

劉沛說，一方面，版本不穩(wěn)定；另一方面，所有人都是新手。出現(xiàn)問題找不到原因時，劉沛他們就到 Hadoop 開源社區(qū)去問，有沒有人遇到同樣問題。如果其他人也遇到這個問題，大家就一起討論怎么辦。而有的問題，”沒有其他人遇到，就只能自己看源代碼，想辦法解決，解決不了的，再找別的解決方案，用別的東西來實現(xiàn)或自己寫代碼實現(xiàn)“。后來，隨著故障的不斷減少，技術(shù)人員的經(jīng)驗越來越豐富，遷移到 Hadoop 上的大數(shù)據(jù)平臺也愈加成熟和穩(wěn)定，能力變得更強(qiáng)。

2014 年，秒針系統(tǒng)達(dá)到一個新高度——實現(xiàn)日均最高千億級廣告請求處理能力。

站在秒針系統(tǒng)肩上的明略

2012 年，大數(shù)據(jù)的概念開始火起來。此時，Hadoop 生態(tài)圈的重要角色都已入局，包括 Facebook、LinkedIn 和 Twitter 以及 Hadoop 三大發(fā)行商 Cloudera、MapR、Hortonworks。整個生態(tài)的蓬勃發(fā)展和日益完善讓 Hadoop 的市場前景變得更美好。于是，從秒針系統(tǒng)孵化出一個小團(tuán)隊，目標(biāo)是做定制化大數(shù)據(jù)平臺。這樣，明略誕生了。

任鑫琦被抽調(diào)到明略，開發(fā)大數(shù)據(jù)平臺。相比以前，開發(fā)一個大數(shù)據(jù)平臺相對更容易，因為秒針系統(tǒng)的實踐積累了一些經(jīng)驗，并且 Hadoop 生態(tài)發(fā)展越來越完善，有更多的工具可以利用。

技術(shù)選型

據(jù)任鑫琦介紹，技術(shù)選型的一個標(biāo)志是 Hadoop 在 2.0 時提出了 NameNode HA 框架，加入選舉機(jī)制和控制組件，可以實現(xiàn)大于 3 的奇數(shù)個管理節(jié)點(diǎn)的配置。當(dāng)一個管理節(jié)點(diǎn)宕掉，馬上會選出第二個管理節(jié)點(diǎn)，這是一個真正的高可用狀態(tài)。

此前，他們雖然一直關(guān)注 Hadoop，但是卻沒采用，原因之一是 Hadoop 1.0、1.1 版本，只有一個核心管理節(jié)點(diǎn) NameNode。后來，它引入 Second NameNode，即有一個主活管理節(jié)點(diǎn)，有一個備用節(jié)點(diǎn)，這兩個節(jié)點(diǎn)實時同步。如果主節(jié)點(diǎn)服務(wù)宕掉了，備用節(jié)點(diǎn)會提醒并繼續(xù)管理這個集群。但是，它其實并非高可用，“因為服務(wù)要切換，并且 Second NameNode 也會有問題”。

他說：“在 Hadoop 2.0 時，我們認(rèn)為它達(dá)到一個基本工業(yè)級可用的狀態(tài)。只要整個集群不出太嚴(yán)重的問題，一些細(xì)節(jié)問題，比如計算效率問題、任務(wù)調(diào)度問題等，我們可以通過修改開源代碼，或調(diào)整執(zhí)行任務(wù)，優(yōu)化任務(wù)策略，慢慢改進(jìn)?！?/p>

因此，明略就把所有的技術(shù)體系切到 Hadoop 上面。

2014 年 7 月，明略發(fā)布大數(shù)據(jù)平臺 1.0 版本。據(jù)悉，1.0 版本已經(jīng)相當(dāng)成熟，“在集群上架的服務(wù)器系統(tǒng)裝完情況下，網(wǎng)都通了，不能說完全一鍵部署，但是點(diǎn)幾鍵就能搞定部署。半小時左右就可以完成一個大數(shù)據(jù)整個生態(tài)體系的部署和安裝“。

這一年，明略數(shù)據(jù)成功中標(biāo)中國銀聯(lián)項目，這是它在國內(nèi)第一個大的企業(yè)級客戶。任鑫琦稱，“當(dāng)時，任何成熟的（大數(shù)據(jù)）部署體系都無法做到半小時完成整個集群的部署安裝和配置工作。這是我們成熟的一個標(biāo)志”。

發(fā)力知識圖譜

基于已有的大數(shù)據(jù)技術(shù)，明略在 2015 年繼而研發(fā)出知識圖譜，核心產(chǎn)品是 SCOPA。

自己的大數(shù)據(jù)發(fā)展蒸蒸日上，為什么要去做知識圖譜？現(xiàn)任明略科技集團(tuán)副總裁任鑫琦解釋，第一，知識圖譜技術(shù)源于搜索引擎，它把所有網(wǎng)頁和內(nèi)容做知識化管理，這樣能更好地理解用戶搜索意圖，提供用戶想要的內(nèi)容和結(jié)果。第二，差異化競爭。他說：“如果能把大量的結(jié)構(gòu)化數(shù)據(jù)，從原來簡單數(shù)倉的計算一些報表，做一些查詢，轉(zhuǎn)換思路，從中抽出它本身的含義，組織成業(yè)務(wù)知識，更有效地組織數(shù)據(jù)，并且實現(xiàn)數(shù)據(jù)增值。這就可以跟業(yè)界很多做通用大數(shù)據(jù)處理的公司實現(xiàn)差異化?！?/p>

不過，他也坦承，基于大量數(shù)據(jù)做知識圖譜有著不小的難度。

難度一，數(shù)據(jù)量非常大，這涉及到整個的實時數(shù)據(jù)處理能力，包括數(shù)據(jù)融合問題、數(shù)據(jù)沖突問題。同時，業(yè)界也沒有參考的。

難度二，每個行業(yè)要建立領(lǐng)域知識圖譜?！斑@與過去的專家系統(tǒng)很像。知識圖譜的價值有多大，關(guān)鍵在于行業(yè)領(lǐng)域知識圖譜的定義，每個行業(yè)都要跟業(yè)務(wù)專家探討知識圖譜的設(shè)計，同時不停地迭代，做各種改進(jìn)，這很難“。

難度三，知識圖譜要與一些 AI 技術(shù)相結(jié)合。知識圖譜的主力場景是“從大數(shù)據(jù)里撈知識”，最基礎(chǔ)的是實體與關(guān)系。據(jù)任鑫琦介紹，針對實體要做兩件事：一是數(shù)據(jù)融合，二是給實體打上明確標(biāo)簽。但是實體種類非常多，怎么打標(biāo)簽，要使用很多 AI 技術(shù)。而關(guān)系的質(zhì)量和數(shù)量決定了整個知識圖譜組織形式的質(zhì)量，”關(guān)系沒有處理好，整個知識圖譜的可用性就會降低，它的推薦、推理、交叉分析就用不起來。關(guān)系的處理也要用到很多的 AI 技術(shù)“。

更重要的是，與之前相比，知識圖譜對背后支撐的技術(shù)平臺要求更高。為此，任鑫琦他們在 2015 年決定做一個混合型知識圖譜數(shù)據(jù)庫。那么，這個混合型知識圖譜要解決三個核心問題：

一是知識圖譜要能實現(xiàn)全文式的定位式索引查詢，比如根據(jù)一個關(guān)鍵詞定位到知識圖譜的某個點(diǎn)，這需要有一個全文的檢索系統(tǒng)；

二是知識圖譜會有很多的條件查詢，比如常規(guī)的大數(shù)據(jù)計算，按照哪一個 Key 和 ID，做查詢、統(tǒng)計分析；

三是知識圖譜要有圖，要完成關(guān)系的推演，包括關(guān)系存儲。

這就要求既有全文，又有大數(shù)據(jù)，還有圖。同時，還要把這三個存儲融合在一起，做好統(tǒng)一索引和管理。

據(jù)任鑫琦透露，他們的解決辦法是把 Elasticsearch、HBase 和圖數(shù)據(jù)庫 Titan 做了一致性索引的融合，包括統(tǒng)一的數(shù)據(jù)存儲的路由、性能優(yōu)化。

他說：“這個問題解決后，像怎么做業(yè)務(wù)定義、怎么描述圖譜的語義等問題都可以用這個混合型數(shù)據(jù)庫實現(xiàn)。大規(guī)模數(shù)據(jù)的融合、實時數(shù)據(jù)計算或高性能計算，這個混合型知識圖譜數(shù)據(jù)庫都可以用不同的特性支持每天更新，甚至是實時更新?！?/p>

明略知識圖譜的技術(shù)架構(gòu)

據(jù)悉，明略知識圖譜的架構(gòu)如下圖所示：

這個架構(gòu)體系中，前端有數(shù)據(jù)接入、數(shù)據(jù)匯總。之后，數(shù)據(jù)清洗，進(jìn)行知識圖譜構(gòu)建。在知識圖譜里，還有實體構(gòu)建、實體標(biāo)簽的構(gòu)建、關(guān)系構(gòu)建等。同時，還有圖譜事件類或者行為類數(shù)據(jù)的構(gòu)建。這是一整套數(shù)據(jù)處理的基礎(chǔ)流程。往后，把這些數(shù)據(jù)加載到圖數(shù)據(jù)庫。在這之上是基于知識圖譜的可視化交互分析系統(tǒng)。

知識圖譜的技術(shù)架構(gòu)仍以 Hadoop 為核心，數(shù)據(jù)接入上，最早用 Flume（現(xiàn)已切換到 Kafka）。據(jù)任鑫琦介紹，”如果對接的是數(shù)據(jù)庫系統(tǒng)，用的是 Scoop 1.0 和 2.0。數(shù)據(jù)抽取上來后，如果不屬于日志型、庫表型，用腳本方式抽取到平臺上，落地到 HDFS；如果是結(jié)構(gòu)化數(shù)據(jù)，直接落成 Hive 表?；?Hive 層完成整個數(shù)據(jù)清洗、融合、轉(zhuǎn)換和知識圖譜構(gòu)建工作，基本上用 Spark 實現(xiàn)整個的數(shù)據(jù)治理過程。如果是實時計算，用的是準(zhǔn)實時 Spark Streaming 的技術(shù)選型，因為這可以減少更多相關(guān)組件的引入”。

簡言之，核心圖譜庫的架構(gòu)和支撐基本是一個以 Elasticsearch、HBase 和 Titan 三個庫為核心的綜合混合型數(shù)據(jù)庫。

據(jù)悉，2015 年底，明略知識圖譜就在國內(nèi)一個省會市級公安局落地，為公安做數(shù)據(jù)分析，包括線索挖掘、團(tuán)伙預(yù)警，協(xié)助公安破案。

2016 年到 2017 年，任鑫琦帶領(lǐng)團(tuán)隊探索知識圖譜在更多行業(yè)的落地和應(yīng)用，目前，明略知識圖譜在公安、金融、工業(yè)和數(shù)字城市等領(lǐng)域得到廣泛應(yīng)用。

回看大數(shù)據(jù) 15 年發(fā)展

2019 年，大數(shù)據(jù)進(jìn)入后 Hadoop 時代，各種實時架構(gòu)和組件大規(guī)模發(fā)展，大數(shù)據(jù)技術(shù)也與云原生、人工智能深度融合。

回顧大數(shù)據(jù)過去幾年的發(fā)展，任鑫琦把它概括成三個階段：

階段一，大數(shù)據(jù)初期，以賣硬件和炒作概念為主。2010 年左右，很多大型企業(yè)受市場和宣傳影響建設(shè)了大數(shù)據(jù)平臺，但沒有發(fā)揮出作用，因為脫離業(yè)務(wù)。

階段二，大數(shù)據(jù)進(jìn)一步發(fā)展，以分析型為主。2014 年，企業(yè)對大數(shù)據(jù)的認(rèn)識進(jìn)一步深入，通過收集更多數(shù)據(jù)，幫助業(yè)務(wù)決策。

階段三，大數(shù)據(jù)發(fā)展成熟和穩(wěn)定，以實時性分析為主。架構(gòu)上，Lambda 架構(gòu)和 Kappa 架構(gòu)廣受歡迎， Flink、Kafka 的使用越來越廣，業(yè)務(wù)對實時性要求越來越高?！皩崟r分析意味著實時性的決策和實時的價值，這對業(yè)務(wù)系統(tǒng)直接產(chǎn)生影響”。以銀行為例，一個人申請貸款，是否放貸，銀行要做大數(shù)據(jù)風(fēng)控，進(jìn)行實時分析。因此，這個階段要求大數(shù)據(jù)的實時性更高，更輕量級的組件和更先進(jìn)的技術(shù)。

任鑫琦說：“現(xiàn)在，大數(shù)據(jù)已經(jīng)發(fā)展到一個精細(xì)化階段?！?/p>

以前，人們對數(shù)據(jù)的認(rèn)識是單點(diǎn)的、孤立的，理解很淺，比如先匯總數(shù)據(jù)，再慢慢挖掘和分析，但這可能匯總大量無效、無關(guān)的數(shù)據(jù)，這些數(shù)據(jù)對整個數(shù)據(jù)體系的業(yè)務(wù)價值會有負(fù)面影響。這些年，人們對數(shù)據(jù)有了新認(rèn)識，比如數(shù)據(jù)并非越多越好，要規(guī)劃好數(shù)據(jù)怎么存、怎么用、怎么產(chǎn)生更大價值。這就要求大數(shù)據(jù)越來越精細(xì)化和精準(zhǔn)化！

寫在最后：

從 2003 年谷歌的“三駕馬車”到現(xiàn)在，大數(shù)據(jù)技術(shù)歷經(jīng)十余年發(fā)展，明略也見證了它從風(fēng)口到落地再到大規(guī)模的普及應(yīng)用。2007 年，明略就投身大數(shù)據(jù)行業(yè)，從零到一研發(fā)出一套成熟的大數(shù)據(jù)平臺，解決了大數(shù)據(jù)存儲和大數(shù)據(jù)計算問題。此后，基于秒針系統(tǒng)積累的大數(shù)據(jù)能力，明略成功研發(fā)出知識圖譜平臺，并在行業(yè)里得到廣泛應(yīng)用。今天，大數(shù)據(jù)技術(shù)正與云原生、AI 技術(shù)相融合，數(shù)據(jù)驅(qū)動成為共識，作為行業(yè)先行者，明略一直深耕技術(shù)，從未止步，讓數(shù)據(jù)產(chǎn)生更大價值、發(fā)揮更大作用。