編者按
現代社會每天都有大量資訊產生，抖音、小紅書等自媒體的普及，不斷豐富著人們表達看法、傳播訴求、分享資訊的渠道和形式。如何完成多源異構資料的收集和處理，挖掘海量資訊中的價值，洞察事件背後的觀點和情緒，是做好政府和企業輿情監測工作不可忽視的問題。
百分點輿情洞察系統（Mediaforce）是一款面向政企客戶的輿情監測SaaS 產品，自2014年上線至今，已累計服務客戶近萬家，積累了逾20 PB的全網資料，透過構建豐富的上層應用，為客戶提供精準、實時、全面、多維度的洞察服務。
本文從底層資料治理、上層應用架構，以及資料個性化和智慧化角度，分享了大資料平臺架構、AI平臺架構和微服務架構在輿情產品上的實踐。
一、平臺架構簡介
伴隨著網際網路內容形態的蓬勃發展，Mediaforce 平臺資料量增長迅速，在產品創新和迭代過程中，自身平臺架構也在不斷的演進。
網際網路輿情本質上是對網際網路公開資訊的採集、分析、研判，併產生業務價值，是一個價值資料探勘的過程，我們覆蓋了90%以上的網路公開資料，包含但不限於以下信源：
線上新聞、報刊、貼吧、部落格、論壇、微博、微信、APP客戶端；
電視、廣播等；
社交自媒體：抖音、快手、小紅書等。
百分點科技透過對以上資料進行儲存、挖掘、視覺化分析等一系列處理，最終為使用者呈現多終端觸達、一站式的輿情監測和價值分析平臺。
到目前為止，大體分為如下三個平臺架構，對應職責如下：
大資料平臺架構
資料共享：統一業務資料儲存，結合業務實際場景對資料進行關聯使用，避免資料重複儲存，降低溝通成本；
服務共享：統一服務架構，避免服務孤島，統一服務的訪問入口和訪問規則；
易於使用：透過平臺服務和工具的形式暴露平臺能力，遮蔽平臺底層細節。
AI平臺架構
資料層：以平臺化能力應對資料收集、資料準備等繁重工作，同時結合業務，構建資料流轉閉環；
深度學習平臺層：實現多租戶及彈性的資源分配、模型庫擴充套件、視覺化訓練和調整、滾動更新等能力；
應用和工具層：藉助Rest\Grpc模型開放能力，對接金融領域輿情、定製化行業標籤、離線資料預測等場景。
微服務架構
拆分：按照業務垂直拆分和功能水平拆分的總原則，以及從業務側儘量規避分散式事務等考慮；
雲原生：減少微服務架構的運維成本，藉助容器化技術，實現資源動態感知、擴縮容等特性。
二、大資料平臺架構
百分點輿情洞察系統最初是透過自主構建IDC來支撐，IaaS層由單獨的運維團隊來進行維護。
大資料平臺（IaaS層除外）分層如下：
輿情的資料應用場景不同於海量日誌、海量商品檢索等的側重於簡單標籤聚合，輿情應用完全基於自然語言全文檢索，同時結合記憶體複雜聚合計算。為了保證檢索準確率，往往會配置複雜的關鍵詞和距離限定，因此對於檢索引擎的記憶體最佳化策略要求很高。可以說，資料儲存和檢索架構的升級，是輿情業務的核心之一。在百分點科技大資料平臺架構演進歷程中，大致可以分為三個階段：業務共享資料倉儲階段、業務自建資料集市階段、湖倉一體階段。
1. 共享資料倉儲階段
在業務規模初期，大部分精力集中於業務系統的迭代和開發，採用共享資料倉儲的解決方案。流程如下：
可以看到，隨著客戶規模和資料量的增大，以及業務複雜度的提升，僅僅依靠共享的資料倉儲，已經無法滿足需求。產生的主要問題如下：
業務側查詢響應時長無法保證；
複雜查詢以及聚合操作，加重Elasticsearch Cluster負擔，甚至引起節點OOM；
冷熱資料未分離。
2. 自建資料集市階段
隨著客戶量及資料量的增多，百分點科技對資料倉儲進行了冷熱資料隔離，並透過自主構建資料集市來滿足業務的快速響應。
下面將從資料倉儲層、資料集市層進行介紹。
ES Cluster從2.3.4升級到6.0.0(當時最新版本)；
資料倉儲核心做了冷熱資料分離，熱資料使用SSD硬碟儲存，且只儲存近一週資料，冷資料使用HDD硬碟，儲存近兩年資料，網際網路資料具有良好的時序性，按天拆分，在保證叢集運維便利的同時，滿足資料變更\刪除的業務需求；
資料集市以業務最小查詢單位-話題為粒度進行拆分和構建，可以認為是將上層業務需要的結果，預計算儲存至資料集市層，這樣業務查詢只需查詢自己獨有的庫便可以進行分析和響應，其中需要相對複雜的機制保障資料一致性，這裡不做介紹。
調整後，業務查詢響應延遲基本可控，並且具有良好的隔離性。但同時也面臨著下述挑戰：
離線資料（2年以上歷史資料）以HDFS為儲存介質，不支援更新、無法查詢複用；
在目前資料集市層的拆分力度下，由於業務邏輯複雜性，需要藉助記憶體計算，在以年為跨度查詢週期，顯得力不從心；
資料集市層實時資料的計算具有一定的延遲，需要保留熱資料叢集來支援實時資料的查詢，架構不夠優雅。
3. 湖倉一體化階段
隨著輿情在客戶群中深入使用，在保證查詢低延遲的情況下，需要能支撐3~5年的長跨度資料檢索。同時為應對SaaS產品矩陣的擴充，需要易用、可擴充套件的資料平臺支撐。本次架構最佳化的核心目標為：
低響應延遲下，大跨度查詢可擴充套件至3~5年（秒級）；
靈活的為其他業務應用做好平臺支撐，加強ODS、DW建設；
減少ES Cluster資料冗餘；
簡化資料集市層計算鏈路，提高資料時效性。
3.1 資料集市層
對客戶和線上日誌進分析，得到如下結果：
（1）客戶資料量級
對線上客戶資料量進行取樣，統計一年資料量，千萬級資料量的客戶群體佔1%。所以我們將目標定義為千萬級資料量下的，複雜聚合查詢分析響應時長在3~5秒內。
（2）查詢型別統計
藉助資料集市，將大量的依據全文檢索聚合統計分析場景轉化為OLAP場景。對線上日誌進行分析，二次全文檢索查詢流量佔比不到20%。
依據上述結論，將資料集市層要解決的問題進行彙總如下：
80%查詢是OLAP場景，20%查詢是全文檢索；
需要支援實時更新；
資料規模支援千萬級別，並支援擴充套件；
查詢響應時長在3~5秒。
通常來說，面對海量資料的低成本儲存+高效檢索的需求，業界通常使用HBase+ Elasticsearch的組合方案，但該方案除了開發維護複雜、資料一致性弱等常見問題，通常還要由Elasticsearch來承擔OLAP，以及全文檢索的功能職責。對於重OLAP查詢場景，使用MPP查詢引擎往往能獲得較低的查詢延遲，如：Clickhouse、DorisDB等。在考慮支援實時更新等多種條件下，我們將方案集中於Elasticsearch、TiDB+ Elasticsearch、DorisDB+Elasticsearch三種技術進行嘗試：
Elasticsearch
ES是一款面向OLAP場景的全文檢索分析引擎，下面是在Elasticsearch 7.8.0環境中的測試：
（1）叢集環境
（2）測試索引
使用單shard、無副本、百萬級別索引32個，十萬級別索引18個。
（3）測試結論
將客戶端併發數等價於索引數目，持續20輪進行壓測。對業務進行抽象，選取如下測試用例：
{"size":0,"query":{"bool":{"filter":[{"bool":{"adjust_pure_negative":true,"boost":1}},{"range":{"pubTime":{"from":1551430186000,"to":1615366186000,"include_lower":true,"include_upper":true,"boost":1}}},{"bool":{"adjust_pure_negative":true,"boost":1}}],"must_not":[{"term":{"mask":{"value":true,"boost":1}}}],"adjust_pure_negative":true,"boost":1}},"track_total_hits":2147483647,"aggregations":{"termsAgg":{"terms":{"field":"titleSimHash","size":2000,"min_doc_count":1,"shard_min_doc_count":0,"show_term_doc_count_error":false,"order":[{"_count":"desc"},{"_key":"asc"}]}},"carAgg":{"cardinality":{"field":"titleSimHash","precision_threshold":10000}}}}
測試中發現叢集相對穩定，相對於單執行緒，多執行緒下的平均延遲高於1s也較少。在Elasticsearch6.0.0上進行相同的測試，其中平均延遲延遲高於1s佔80%。
TiDB+Elasticsearch
TiDB 4.0版本已經是一款HTAP混合型分析引擎，將測試資料集限定為千萬級，在測試中設定：tidb_hashagg_final_concurrency=20和tidb_hashagg_partial_concurrency = 20，平均耗時穩定在 8s~9s。由於聚合後的基數較大，壓力都集中在TiDB側，未能達到去ES的OLAP的場景。更多資訊請參照AskTUG：千萬級資料group by效能調優[1]。隨著TiDB 5.0釋出，TiFlash已經不僅僅是一個列式儲存引擎這麼簡單。TiFlash引入了MPP模式，使得整個TiFlash從單純的儲存節點升級成為一個全功能的分析引擎。
[1] https://asktug.com/t/topic/68474/1
DorisDB+Elasticsearch
Mpp引擎列式儲存設計對於資料更新是極其不友好的。藉助DorisDB的更新模型引擎，內部透過版本號，可以支援大規模的資料實時更新，當然在查詢時需要完成多版合併。同時Doris-On-ES將Doris的分散式查詢規劃能力和ES(Elasticsearch)的全文檢索能力相結合，提供更完善的OLAP分析場景解決方案。目前Doris On ES不支援聚合操作如sum，avg， min/max 等下推，計算方式是批次流式的從ES獲取所有滿足條件的文件，然後在Doris中進行計算。在測試場場景下，效能是可以滿足OLAP場景。實踐中發現，由於自建IDC機器較為老舊，無法支援SIMD指令，致使無法安裝DorisDB。
在目前的業務場景下，百分點科技最終選擇單一的Elasticsearch來作為資料集市層的儲存和計算引擎。後續如果資料集市有更大的資料量以及業務低延遲的OLAP查詢場景，還是會考慮結合MPP查詢引擎來滿足業務的擴充套件。
3.2 資料倉儲層
在之前的很長一段時間內，Elasticsearch Cluster承擔了大量數倉的職能。透過多叢集進行冷熱資料隔離。在本次調整中，百分點科技藉助索引生命週期管理(ILM)和Hot\Warm架構來實現在一個叢集中進行資料的管理。在實踐中，我們將Elasticsearch率先升級到7.12.0，以滿足向量化檢索等更多場景。
3.3 源資料層
之前會將採集的資料儲存至kafka，作為資料傳輸中轉。但kafka一般儲存的時間週期較短，且功能單一。因此需要一套統一的儲存計算平臺，需要滿足如下要求：
全量的離線資料是透過ES-Hadoop進行按天備份，後續的變更就無法做到同步，複用性、靈活性較差；
圖片、音影片等非結構化資料的接入，需要方便與上層機器學習應用深度融合；
輔助資料倉儲，構建資料集市，保證實時性。
在最新的架構中，百分點科技將資料先入湖，構建ODS，輔助構建上層DW和DM。關於Data Lake，最終選取Hudi作為源資料層儲存計算方案，並做了以下嘗試：
Iceberg
Iceberg工程架構具有極高的抽象，可以與各種引擎無縫融合。字串模糊匹配是一種重要場景，測試中遇到以下問題：如果某個欄位儲存為空字串，在匹配中就會出現異常：java.lang.IllegalArgumentException: Truncate length should be positive[2]。另外就是查詢對Stream相關支援還處於開發階段，對於增量資料處理只能以Java Api方式實現。
[2] https://github.com/apache/iceberg/issues/2065
Hudi
Hudi顯得尤為成熟，但是與 Spark 引擎繫結的較為緊密。在Hudi 0.6中對底層程式碼進行抽象，以適配Flink等主流計算引擎。同時其完善的增量查詢機制非常適合實時資料集市的構建。另外Hudi Table並不需要提前建立，可以在寫入資料時自動建立，這也是區別於Iceberg的一個點。
Hudi的引入，為底層資料平臺帶來了ACID能力，並且提供較好實時性。特別是為資料集市實時資料構建帶來便捷，提供可擴充套件性。目前的簡易資料架構如下：
三、AI平臺架構
在海量的文字資料上，利用豐富的資料探勘、深度學習、人工智慧演算法，訓練線上和離線語義模型，一站式挖掘滿足客戶需要的輿情分析需求。在這一歷程中，大致分為兩個階段：
文字分析平臺：將通用文字能力服務化；
深度學習建模平臺：高效、易用、低門檻的模型定製開發平臺。
在上述演進中，最主要的變化在於各行各業都已經積累了較多的高價值資料，並且越來越需要定製滿足自己場景的個性化模型。下面主要從這兩個階段分別展開對應的工作。
文字分析平臺
在輿情分析場景中，依賴於分詞、詞性、新詞發現、命名實體、主體分類、文字聚類、關鍵詞提取、自動摘要、文字去重、情感分析、內容轉換（簡繁、拼音）、自動糾錯、自動補全、文件解析等各種功能。產品架構和資料流程如下：
深度學習建模平臺
隨著深度遷移學習成熟和行業應用，帶來最大的益處在於可以依據少量的訓練資料便可以得到較好的訓練結果。從下述對比中：可以看到Bert在少訓練集下就能達到較好的結果，也為後續的定製化模型奠定了基礎。
輿情繫統本身可以看作為資訊工程架構，客戶可以容忍資料精準度，但是不允許相同的資料持續犯錯。可學習、可持續、可定製已經變的尤為重要。這也是深度學習建模平臺的由來。
下面是整體的業務架構和流程分析，具體技術細節可參照：NLP模型開發平臺在輿情分析中的設計和實踐。
四、微服務架構
下面對網際網路架構演進之路進行總結如下，其中帶顏色標記的為實踐中的產物。
輿情業務應用系統從最核心幾個業務功能，目前已經擴充套件至幾十個業務模組。同時藉助成熟的底層模組，快速沉澱出金融輿情、行業版等眾多專案。大致經過以下三個階段。
1. 單體架構
在業務初期，使用SpringBoot作為單體應用開發程式，可極大加快業務推進速度，簡易架構如下：
單體架構的優點在於其易開發、易測試、易部署、易擴充套件，但是業務耦合嚴重，也為業務擴充套件、服務治理帶來了新的挑戰。例如：登入服務和查詢服務在一個單體應用中，因為查詢服務是一個耗記憶體的操作，高峰時會引起FullGC，致使登入功能異常。
2. 微服務架構
微服務可以定義如下：
⼀種架構⻛格，將單體應⽤劃分成⼀組⼩的服務，服務之間相互協作，實現業務功能。每個服務運⾏在獨⽴的程式中，服務間採⽤輕量級的通訊機制協作（通常是HTTP/JSON）;
每個服務圍繞業務能⼒進⾏構建，並且能夠透過⾃動化機制獨⽴地部署；
很少有集中式的服務管理，每個服務可以使⽤不同的語⾔開發，使⽤不同的儲存技術；
參考：https://www.martinfowler.com/articles/microservices.html。
隨著業務擴充套件，業務耦合嚴重，開發效率低下、排查問題困難等。秉承業務維度垂直拆分和功能維度水平拆分的原則，同時儘量避免分散式事務等複雜度問題。拆分後架構圖如下：
微服務拆分功效：
業務邏輯層：拆分後服務模組30+；
監控體系建立：日誌監控、Metrics監控、呼叫鏈監控、告警系統、健康檢查；
配置中心：靈活視覺化的配置管理中心；
開發效率、團隊協作能力提升。
3. 雲原生架構
雲原生包含了一組應用的模式，用於幫助企業快速，持續，可靠，規模化的交付業務軟體。其特點如下：
容器化封裝：以容器為基礎，提高整體開發水平，形成程式碼和元件重用，簡化雲原生應用程式的維護，在容器中執行應用程式和程式，並作為應用程式部署的獨立單元，實現高水平資源隔離；
動態管理：透過集中式的編排排程系統來動態的管理和排程；
面向微服務：明確服務間的依賴，互相解耦。
藉助百分點科技內部雲平臺，將微服務結構容器化封裝，極大的降低了部署、運維的成本，也為服務的穩定性增加了保證機制。下面主要介紹一下雲平臺的基礎概念和應用成效。
平臺基礎概念：
名稱空間
管理常規使用者的資源訪問許可權的中央載體，讓一組使用者組織和管理他們的內容，並與其它群體區隔開來。是使用者賬號的唯一公共URL訪問地址。
容器
Docker容器為資源分割和排程的基本單位，封裝整個軟體執行時的環境，為開發者和管理員設計的，用於構建、釋出和執行分散式應用平臺。
映象
含有啟動Docker容器所需的檔案系統結構及其內容，因此是啟動一個Docker容器的基礎。採用分層的結構構建。
專案
透過標籤標識的多個版本的映象組成。
構建
將輸入引數轉換為結果物件的過程；通常用於將輸入引數或原始碼轉換為可執行的映象從構建映象建立Docker容器並將它們推送到整合的容器映象倉庫（Harbor）
S2I構建：透過注入應用原始碼到Docker映象並且組建新的Docker映象來生成可執行的映象新映象中融合基礎映象和構建的原始碼，並可搭配docker run命令使用。S2I支援遞增構建，可重複利用以前的下載依賴項和過去構建的構件等。
服務
平臺部署應用的最小單位，一個服務為一個功能單元，如mysql資料庫服務。是定義容器例項的邏輯集合以及訪問它們的策略，一個服務至少包含一個容器例項，服務通常用於為一組相似的容器提供永久IP。在內部，服務在被訪問時實行負載均衡並代理到相應的支援容器例項，可以在服務中任意新增或者刪除支援容器,而一直保持服務可用。
配額
在同一個名稱空間內可以建立的最大物件資源數量，以及每個容器請求的計算/記憶體/儲存資源。
高階編排
編排模板：描述可以引數化和處理一系列物件，生成的服務、構建配置和部署配置。可以為開發人員即時建立可部署的應用。
平臺資源物件層級關係：
目前平臺程式碼構建支援三種模式：
智慧構建
基於平臺所提供的Builder映象，自動下載應用原始碼進行編譯。在基礎映象之上，自動編譯程式碼。
Dockerfile構建
使用者自己編寫Dockerfile，指定程式碼庫、Dockerfile位置及程式碼分支後可以構建專案映象。
自定義的Dockerfile，可以指定自定義基礎映象以及編譯環境變數、配置資訊等構建出更復雜的編譯或執行環境，構建靈活性相比前者更高。
Push構建
透過平臺提供的push構建流程，將本地定製化映象上傳到映象倉庫，匯入後的映象可以在平臺中進行部署、除錯、使用。
平臺Scale功能包含水平伸縮和垂直伸縮，以下是水平伸縮的例子：
平臺提供容器例項監控，可以按照時間區間圖形化展示容器的CPU、記憶體和網路的使用情況：
總結
企業SaaS一般是圍繞獲客、轉化、留存這三個階段展開，平臺的易用性、資料的準確性和實時性等都是客戶留存的核心要素。在多年的實踐中，大資料架構以資料湖為ODS層，來保證對原始資料高效、靈活的處理，同時為其他業務線開放資料處理能力。AI平臺架構提供一套端到端的閉環流水線，打造個性化、智慧化的業務。微服務架構透過容器化，極大的降低維護成本，同時保證線上穩定性。隨著SaaS產品矩陣的擴充，百分點科技在金融輿情、企業品牌監測等多個方向進行積極嘗試，底層平臺架構在業務的快速落地中起到了重要作用。