網購、叫車、訂外賣、看電影...... 移動網際網路各種場景的背後都離不開大資料技術。經過十幾年的發展，大資料技術已經成為網際網路企業的基礎設施。
1源起谷歌“三駕馬車”
聊起大資料，就繞不開谷歌的“三駕馬車“。早在 2003 年，谷歌發表第一篇論文——谷歌檔案系統（GFS）；第二年，谷歌再次發表一篇論文——分布式計算架構 MapReduce；2006 年，谷歌發表第三篇論文——NoSQL 資料庫系統 BigTable。這三篇論文由此開啟了大資料時代。
徐飛在《大資料浪潮之巅：新技術商業制勝之道》一書中寫道，“通過‘三駕馬車’這一利器，谷歌具備了存儲和分析海量資料的能力，其個性化廣告系統猶如永動的印鈔機，不斷為谷歌賺取财富。”
受谷歌“三駕馬車”的影響，其他網際網路公司也在嘗試大規模分布式系統，希望建構強大的資料存儲、分析和處理平台。不過，當時正處于前 Hadoop 時期，網際網路公司基本上都在摸着石頭過河。
2資料收集和計算領域的先驅
在衆多的網際網路公司中，成立于 2006 年的秒針系統無疑是這個領域的先行者。據秒針系統産研中心負責人劉沛介紹，2008 年 Hadoop 還沒有成熟，他們從零研發了自己的大資料平台，“思路跟 Hadoop MapReduce 類似，一天也能處理幾十億資料”。劉沛在 2007 年加入秒針，那時他還在讀大三。一年後，他正式畢業，留在秒針系統。他先後上司了包括廣告監測系統 AdMonitor 等核心産品的研究和開發。作為秒針系統的老人，他見證了秒針系統大資料平台從 0 到 1 的過程。
據悉，秒針系統的業務是廣告監測，核心産品是 AdMonitor。在 AdMonitor 的服務鍊路中，前端負責收集資料。每個廣告會被嵌入一個發送到秒針系統域名的代碼。一旦廣告在媒體端被點選，它就會把被嵌入的代碼發回到秒針系統的伺服器。這樣，系統就知道完成了一次廣告曝光。這樣的一個廣告業務流程主要涉及資料采集、資料存儲、資料計算和資料分析技術。
多端收集資料
那麼，第一個問題來了，秒針系統怎麼收集資料？據劉沛介紹，在 PC 時代，大多使用 JavaScript 來采集資料。這就要求秒針系統的産品要适配每一個浏覽器，包括 Firefox、IE、傲遊浏覽器、海豚浏覽器等。據悉，cookie 是當時資料收集使用的主要技術之一。除 cookie 之外，結合 Flash。那時，幾乎所有的廣告都是 Flash，因為 Flash 本身是一個可執行程式，是以能在其内部程式設計，把監測代碼放在裡面，收集資料。
劉沛表示，“Flash 也有 cookie 的概念，技術術語叫 FSO。把 FSO 和 cookie 做各種關聯，實作持久化。這邊删了，那邊能恢複；那邊删了，這邊再恢複。在保護使用者隐私的前提下更精準地識别出一個獨立使用者。”
到了 2012 年，智能手機出現，Android 和 iOS App 數量不斷增多，秒針系統又在 AdMonitor 産品中增加移動端廣告測量能力。SDK 技術成為當時移動端資料收集的主要方式。劉沛稱，“Android、iOS 都是新事物，不僅要學習新的程式設計語言，還要面對新技術環境進行開發。做出一款應用後，要适配廠商不同機型的不同型号。除硬體外，還要适應手機上運作的各種 App”。
舉個例子，愛奇藝、優酷和騰訊視訊是三大主流視訊 App。SDK 要在之上運作，前期要做各種對接測試，保證運轉正常。“不能讓 App 當機，也不能拖慢了它的系統運轉。另外，資料采集結果要和他們上報的一緻。是以，每加入一款主流 App，都得做技術對接和資料測試。”他說。
2012 年 8 月，秒針系統正式推出中國第一個移動端廣告加載 SDK，“很快就被加進了主流的 App 中”。
用 RAID 5 搞定資料存儲難題
時任秒針系統大資料平台運維負責人任鑫琦向 InfoQ 記者透露，秒針系統的業務量當時非常大，占到全國所有廣告監測流量的 60%，收集資料的伺服器每天 PV 量超過 100 億。
這麼多資料，如何存儲？據劉沛介紹，當時使用了 RAID（獨立磁盤備援陣列）技術，具體說是 RAID 5 技術：資料在寫入磁盤時，将資料分成 N-1 份，并發寫入 N-1 塊磁盤，校驗資料螺旋式寫入所有磁盤。這樣保證了 RAID 5 既有較快的通路速度，又有較高的資料可靠性。
用劉沛的話解釋，“一個叢集中，一份資料被切片後存在不同地方。如果一塊磁盤銷毀了，還能從别處恢複”。
百億規模的資料計算問題，怎麼解？
資料收集上來後，關鍵是資料計算。任鑫琦介紹，計算分為兩類：第一類是按小時進行批量計算，這要求平台具備大規模資料的處理能力。第二類是實時計算，這要保證明時計算的可靠性，否則計算延遲，“客戶看到的資料就不準确”。
據悉，秒針系統當時一天有 100 多億資料。其單台日志伺服器的承載性能是“滿負荷運作，一天可以處理 4 個億的資料”。實際中，一般按照 50% 的負載使用率，即一台日志伺服器一天要處理 2 億資料。這樣算下來，大概需要 50 台日志伺服器。
當資料量超過一台伺服器的承載能力時，前端要分成很多台伺服器做負載均衡。比如，監測代碼加在各種各樣的媒體上，每個廣告主在多個媒體上投放，而每個媒體同時又承載多個廣告主，每個媒體又有不同的廣告位，“是以要把這些全部用監測代碼 ID 索引好”。
劉沛稱，“每個廣告被曝光或點選時，這條請求是發到了哪台伺服器，都要有一套統一的排程規則，保證每台伺服器的承壓一緻，保證每台伺服器分工合理。這樣整體性能就會最好”。
在資料計算架構上，由于 Hadoop 當時不成熟，是以秒針系統使用了一個開源的分布式檔案系統 KFS。任鑫琦說：“基于 KFS，我們沒有用 Hadoop 零點幾版本的架構，因為不太穩定，其管理節點不是高可用的。”Hadoop 在 2.0 版本之前，其 NameNode 隻有一個，一旦壞了，整個叢集就會崩潰。是以，自己維護了一套分布式計算任務的排程工具，把順序排程和背序排程相結合，再加入一些針對局部的排程技巧和優化。
Hadoop 助力，技術能力再上一層樓
2012 年，Hadoop 釋出 2.0 版本。它是一套全新架構，包含 HDFS Federation 和 Yarn 兩個系統。相比 1.0 版本，它更穩定，也更成熟。是以，秒針系統開始逐漸采用。但系統遷移并不是那麼容易，花了一年的時間才成功切換到 Hadoop 上。
劉沛說，一方面，版本不穩定；另一方面，所有人都是新手。出現問題找不到原因時，劉沛他們就到 Hadoop 開源社群去問，有沒有人遇到同樣問題。如果其他人也遇到這個問題，大家就一起讨論怎麼辦。而有的問題，”沒有其他人遇到，就隻能自己看源代碼，想辦法解決，解決不了的，再找别的解決方案，用别的東西來實作或自己寫代碼實作“。後來，随着故障的不斷減少，技術人員的經驗越來越豐富，遷移到 Hadoop 上的大資料平台也愈加成熟和穩定，能力變得更強。
2014 年，秒針系統達到一個新高度——實作日均最高千億級廣告請求處理能力。
3站在秒針系統肩上的明略
2012 年，大資料的概念開始火起來。此時，Hadoop 生态圈的重要角色都已入局，包括 Facebook、LinkedIn 和 Twitter 以及 Hadoop 三大發行商 Cloudera、MapR、Hortonworks。整個生态的蓬勃發展和日益完善讓 Hadoop 的市場前景變得更美好。于是，從秒針系統孵化出一個小團隊，目标是做定制化大資料平台。這樣，明略誕生了。
任鑫琦被抽調到明略，開發大資料平台。相比以前，開發一個大資料平台相對更容易，因為秒針系統的實踐積累了一些經驗，并且 Hadoop 生态發展越來越完善，有更多的工具可以利用。
技術選型
據任鑫琦介紹，技術選型的一個标志是 Hadoop 在 2.0 時提出了 NameNode HA 架構，加入選舉機制和控制元件，可以實作大于 3 的奇數個管理節點的配置。當一個管理節點宕掉，馬上會選出第二個管理節點，這是一個真正的高可用狀态。
此前，他們雖然一直關注 Hadoop，但是卻沒采用，原因之一是 Hadoop 1.0、1.1 版本，隻有一個核心管理節點 NameNode。後來，它引入 Second NameNode，即有一個主活管理節點，有一個備用節點，這兩個節點實時同步。如果主節點服務宕掉了，備用節點會提醒并繼續管理這個叢集。但是，它其實并非高可用，“因為服務要切換，并且 Second NameNode 也會有問題”。
他說：“在 Hadoop 2.0 時，我們認為它達到一個基本工業級可用的狀态。隻要整個叢集不出太嚴重的問題，一些細節問題，比如計算效率問題、任務排程問題等，我們可以通過修改開源代碼，或調整執行任務，優化任務政策，慢慢改進。”
是以，明略就把所有的技術體系切到 Hadoop 上面。
2014 年 7 月，明略釋出大資料平台 1.0 版本。據悉，1.0 版本已經相當成熟，“在叢集上架的伺服器系統裝完情況下，網都通了，不能說完全一鍵部署，但是點幾鍵就能搞定部署。半小時左右就可以完成一個大資料整個生态體系的部署和安裝“。
這一年，明略資料成功中标中國銀聯項目，這是它在國内第一個大的企業級客戶。任鑫琦稱，“當時，任何成熟的（大資料）部署體系都無法做到半小時完成整個叢集的部署安裝和配置工作。這是我們成熟的一個标志”。
發力知識圖譜
基于已有的大資料技術，明略在 2015 年繼而研發出知識圖譜，核心産品是 SCOPA。
自己的大資料發展蒸蒸日上，為什麼要去做知識圖譜？現任明略科技集團副總裁任鑫琦解釋，第一，知識圖譜技術源于搜尋引擎，它把所有網頁和内容做知識化管理，這樣能更好地了解使用者搜尋意圖，提供使用者想要的内容和結果。第二，差異化競争。他說：“如果能把大量的結構化資料，從原來簡單數倉的計算一些報表，做一些查詢，轉換思路，從中抽出它本身的含義，組織成業務知識，更有效地組織資料，并且實作資料增值。這就可以跟業界很多做通用大資料處理的公司實作差異化。“
不過，他也坦承，基于大量資料做知識圖譜有着不小的難度。
難度一，資料量非常大，這涉及到整個的實時資料處理能力，包括資料融合問題、資料沖突問題。同時，業界也沒有參考的。
難度二，每個行業要建立領域知識圖譜。“這與過去的專家系統很像。知識圖譜的價值有多大，關鍵在于行業領域知識圖譜的定義，每個行業都要跟業務專家探讨知識圖譜的設計，同時不停地疊代，做各種改進，這很難“。
難度三，知識圖譜要與一些 AI 技術相結合。知識圖譜的主力場景是“從大資料裡撈知識”，最基礎的是實體與關系。據任鑫琦介紹，針對實體要做兩件事：一是資料融合，二是給實體打上明确标簽。但是實體種類非常多，怎麼打标簽，要使用很多 AI 技術。而關系的品質和數量決定了整個知識圖譜組織形式的品質，”關系沒有處理好，整個知識圖譜的可用性就會降低，它的推薦、推理、交叉分析就用不起來。關系的處理也要用到很多的 AI 技術“。
更重要的是，與之前相比，知識圖譜對背後支撐的技術平台要求更高。為此，任鑫琦他們在 2015 年決定做一個混合型知識圖譜資料庫。那麼，這個混合型知識圖譜要解決三個核心問題：
- 一是知識圖譜要能實作全文式的定位式索引查詢，比如根據一個關鍵詞定位到知識圖譜的某個點，這需要有一個全文的檢索系統；
- 二是知識圖譜會有很多的條件查詢，比如正常的大資料計算，按照哪一個 Key 和 ID，做查詢、統計分析；
- 三是知識圖譜要有圖，要完成關系的推演，包括關系存儲。
這就要求既有全文，又有大資料，還有圖。同時，還要把這三個存儲融合在一起，做好統一索引和管理。
據任鑫琦透露，他們的解決辦法是把 Elasticsearch、HBase 和圖資料庫 Titan 做了一緻性索引的融合，包括統一的資料存儲的路由、性能優化。
他說：“這個問題解決後，像怎麼做業務定義、怎麼描述圖譜的語義等問題都可以用這個混合型資料庫實作。大規模資料的融合、實時資料計算或高性能計算，這個混合型知識圖譜資料庫都可以用不同的特性支援每天更新，甚至是實時更新。”
明略知識圖譜的技術架構
據悉，明略知識圖譜的架構如下圖所示：
這個架構體系中，前端有資料接入、資料彙總。之後，資料清洗，進行知識圖譜建構。在知識圖譜裡，還有實體建構、實體标簽的建構、關系建構等。同時，還有圖譜事件類或者行為類資料的建構。這是一整套資料處理的基礎流程。往後，把這些資料加載到圖資料庫。在這之上是基于知識圖譜的可視化互動分析系統。
知識圖譜的技術架構仍以 Hadoop 為核心，資料接入上，最早用 Flume（現已切換到 Kafka）。據任鑫琦介紹，”如果對接的是資料庫系統，用的是 Scoop 1.0 和 2.0。資料抽取上來後，如果不屬于日志型、庫表型，用腳本方式抽取到平台上，落地到 HDFS；如果是結構化資料，直接落成 Hive 表。基于 Hive 層完成整個資料清洗、融合、轉換和知識圖譜建構工作，基本上用 Spark 實作整個的資料治理過程。如果是實時計算，用的是準實時 Spark Streaming 的技術選型，因為這可以減少更多相關元件的引入”。
簡言之，核心圖譜庫的架構和支撐基本是一個以 Elasticsearch、HBase 和 Titan 三個庫為核心的綜合混合型資料庫。
據悉，2015 年底，明略知識圖譜就在國内一個省會市級警察局落地，為公安做資料分析，包括線索挖掘、團夥預警，協助公安破案。
2016 年到 2017 年，任鑫琦帶領團隊探索知識圖譜在更多行業的落地和應用，目前，明略知識圖譜在公安、金融、工業和數字城市等領域得到廣泛應用。
4回看大資料 15 年發展
2019 年，大資料進入後 Hadoop 時代，各種實時架構群組件大規模發展，大資料技術也與雲原生、人工智能深度融合。
回顧大資料過去幾年的發展，任鑫琦把它概括成三個階段：
階段一，大資料初期，以賣硬體和炒作概念為主。2010 年左右，很多大型企業受市場和宣傳影響建設了大資料平台，但沒有發揮出作用，因為脫離業務。
階段二，大資料進一步發展，以分析型為主。2014 年，企業對大資料的認識進一步深入，通過收集更多資料，幫助業務決策。
階段三，大資料發展成熟和穩定，以實時性分析為主。架構上，Lambda 架構和 Kappa 架構廣受歡迎， Flink、Kafka 的使用越來越廣，業務對實時性要求越來越高。“實時分析意味着實時性的決策和實時的價值，這對業務系統直接産生影響”。以銀行為例，一個人申請貸款，是否放貸，銀行要做大資料風控，進行實時分析。是以，這個階段要求大資料的實時性更高，更輕量級的元件和更先進的技術。
任鑫琦說：“現在，大資料已經發展到一個精細化階段。”
以前，人們對資料的認識是單點的、孤立的，了解很淺，比如先彙總資料，再慢慢挖掘和分析，但這可能彙總大量無效、無關的資料，這些資料對整個資料體系的業務價值會有負面影響。這些年，人們對資料有了新認識，比如資料并非越多越好，要規劃好資料怎麼存、怎麼用、怎麼産生更大價值。這就要求大資料越來越精細化和精準化！
5寫在最後：
從 2003 年谷歌的“三駕馬車”到現在，大資料技術曆經十餘年發展，明略也見證了它從風口到落地再到大規模的普及應用。2007 年，明略就投身大資料行業，從零到一研發出一套成熟的大資料平台，解決了大資料存儲和大資料計算問題。此後，基于秒針系統積累的大資料能力，明略成功研發出知識圖譜平台，并在行業裡得到廣泛應用。今天，大資料技術正與雲原生、AI 技術相融合，資料驅動成為共識，作為行業先行者，明略一直深耕技術，從未止步，讓資料産生更大價值、發揮更大作用。