輿情的數(shù)據(jù)應(yīng)用場景不同于海量日志、海量商品檢索等的側(cè)重于簡單標(biāo)簽聚合，輿情應(yīng)用完全基于自然語言全文檢索，同時(shí)結(jié)合內(nèi)存復(fù)雜聚合計(jì)算。為了保證檢索準(zhǔn)確率，往往會配置復(fù)雜的關(guān)鍵詞和距離限定，因此對于檢索引擎的內(nèi)存優(yōu)化策略要求很高?？梢哉f，數(shù)據(jù)存儲和檢索架構(gòu)的升級，是輿情業(yè)務(wù)的核心之一。在百分點(diǎn)科技大數(shù)據(jù)平臺架構(gòu)演進(jìn)歷程中，大致可以分為三個(gè)階段：業(yè)務(wù)共享數(shù)據(jù)倉庫階段、業(yè)務(wù)自建數(shù)據(jù)集市階段、湖倉一體階段。

1. 共享數(shù)據(jù)倉庫階段

在業(yè)務(wù)規(guī)模初期，大部分精力集中于業(yè)務(wù)系統(tǒng)的迭代和開發(fā)，采用共享數(shù)據(jù)倉庫的解決方案。流程如下：

可以看到，隨著客戶規(guī)模和數(shù)據(jù)量的增大，以及業(yè)務(wù)復(fù)雜度的提升，僅僅依靠共享的數(shù)據(jù)倉庫，已經(jīng)無法滿足需求。產(chǎn)生的主要問題如下：

業(yè)務(wù)側(cè)查詢響應(yīng)時(shí)長無法保證；

復(fù)雜查詢以及聚合操作，加重Elasticsearch Cluster負(fù)擔(dān)，甚至引起節(jié)點(diǎn)OOM；

冷熱數(shù)據(jù)未分離。

2. 自建數(shù)據(jù)集市階段

隨著客戶量及數(shù)據(jù)量的增多，百分點(diǎn)科技對數(shù)據(jù)倉庫進(jìn)行了冷熱數(shù)據(jù)隔離，并通過自主構(gòu)建數(shù)據(jù)集市來滿足業(yè)務(wù)的快速響應(yīng)。

下面將從數(shù)據(jù)倉庫層、數(shù)據(jù)集市層進(jìn)行介紹。

ES Cluster從2.3.4升級到6.0.0(當(dāng)時(shí)最新版本)；

數(shù)據(jù)倉庫核心做了冷熱數(shù)據(jù)分離，熱數(shù)據(jù)使用SSD硬盤存儲，且只存儲近一周數(shù)據(jù)，冷數(shù)據(jù)使用HDD硬盤，存儲近兩年數(shù)據(jù)，互聯(lián)網(wǎng)數(shù)據(jù)具有良好的時(shí)序性，按天拆分，在保證集群運(yùn)維便利的同時(shí)，滿足數(shù)據(jù)變更\刪除的業(yè)務(wù)需求；

數(shù)據(jù)集市以業(yè)務(wù)最小查詢單位-話題為粒度進(jìn)行拆分和構(gòu)建，可以認(rèn)為是將上層業(yè)務(wù)需要的結(jié)果，預(yù)計(jì)算存儲至數(shù)據(jù)集市層，這樣業(yè)務(wù)查詢只需查詢自己獨(dú)有的庫便可以進(jìn)行分析和響應(yīng)，其中需要相對復(fù)雜的機(jī)制保障數(shù)據(jù)一致性，這里不做介紹。

調(diào)整后，業(yè)務(wù)查詢響應(yīng)延遲基本可控，并且具有良好的隔離性。但同時(shí)也面臨著下述挑戰(zhàn)：

離線數(shù)據(jù)（2年以上歷史數(shù)據(jù)）以HDFS為存儲介質(zhì)，不支持更新、無法查詢復(fù)用；

在目前數(shù)據(jù)集市層的拆分力度下，由于業(yè)務(wù)邏輯復(fù)雜性，需要借助內(nèi)存計(jì)算，在以年為跨度查詢周期，顯得力不從心；

數(shù)據(jù)集市層實(shí)時(shí)數(shù)據(jù)的計(jì)算具有一定的延遲，需要保留熱數(shù)據(jù)集群來支持實(shí)時(shí)數(shù)據(jù)的查詢，架構(gòu)不夠優(yōu)雅。

3. 湖倉一體化階段

隨著輿情在客戶群中深入使用，在保證查詢低延遲的情況下，需要能支撐3~5年的長跨度數(shù)據(jù)檢索。同時(shí)為應(yīng)對SaaS產(chǎn)品矩陣的擴(kuò)充，需要易用、可擴(kuò)展的數(shù)據(jù)平臺支撐。本次架構(gòu)優(yōu)化的核心目標(biāo)為：

低響應(yīng)延遲下，大跨度查詢可擴(kuò)展至3~5年（秒級）；

靈活的為其他業(yè)務(wù)應(yīng)用做好平臺支撐，加強(qiáng)ODS、DW建設(shè)；

減少ES Cluster數(shù)據(jù)冗余；

簡化數(shù)據(jù)集市層計(jì)算鏈路，提高數(shù)據(jù)時(shí)效性。

3.1 數(shù)據(jù)集市層

對客戶和線上日志進(jìn)分析，得到如下結(jié)果：

（1）客戶數(shù)據(jù)量級

對線上客戶數(shù)據(jù)量進(jìn)行采樣，統(tǒng)計(jì)一年數(shù)據(jù)量，千萬級數(shù)據(jù)量的客戶群體占1%。所以我們將目標(biāo)定義為千萬級數(shù)據(jù)量下的，復(fù)雜聚合查詢分析響應(yīng)時(shí)長在3~5秒內(nèi)。

（2）查詢類型統(tǒng)計(jì)

借助數(shù)據(jù)集市，將大量的依據(jù)全文檢索聚合統(tǒng)計(jì)分析場景轉(zhuǎn)化為OLAP場景。對線上日志進(jìn)行分析，二次全文檢索查詢流量占比不到20%。

依據(jù)上述結(jié)論，將數(shù)據(jù)集市層要解決的問題進(jìn)行匯總?cè)缦拢?/p>

80%查詢是OLAP場景，20%查詢是全文檢索；

需要支持實(shí)時(shí)更新；

數(shù)據(jù)規(guī)模支持千萬級別，并支持?jǐn)U展；

查詢響應(yīng)時(shí)長在3~5秒。

通常來說，面對海量數(shù)據(jù)的低成本存儲+高效檢索的需求，業(yè)界通常使用HBase+ Elasticsearch的組合方案，但該方案除了開發(fā)維護(hù)復(fù)雜、數(shù)據(jù)一致性弱等常見問題，通常還要由Elasticsearch來承擔(dān)OLAP，以及全文檢索的功能職責(zé)。對于重OLAP查詢場景，使用MPP查詢引擎往往能獲得較低的查詢延遲，如：Clickhouse、DorisDB等。在考慮支持實(shí)時(shí)更新等多種條件下，我們將方案集中于Elasticsearch、TiDB+ Elasticsearch、DorisDB+Elasticsearch三種技術(shù)進(jìn)行嘗試：

Elasticsearch

ES是一款面向OLAP場景的全文檢索分析引擎，下面是在Elasticsearch 7.8.0環(huán)境中的測試：

（1）集群環(huán)境

（2）測試索引

使用單shard、無副本、百萬級別索引32個(gè)，十萬級別索引18個(gè)。

（3）測試結(jié)論

將客戶端并發(fā)數(shù)等價(jià)于索引數(shù)目，持續(xù)20輪進(jìn)行壓測。對業(yè)務(wù)進(jìn)行抽象，選取如下測試用例：

{“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}}}}

測試中發(fā)現(xiàn)集群相對穩(wěn)定，相對于單線程，多線程下的平均延遲高于1s也較少。在Elasticsearch6.0.0上進(jìn)行相同的測試，其中平均延遲延遲高于1s占80%。

TiDB+Elasticsearch

TiDB 4.0版本已經(jīng)是一款HTAP混合型分析引擎，將測試數(shù)據(jù)集限定為千萬級，在測試中設(shè)置：tidb_hashagg_final_concurrency=20和tidb_hashagg_partial_concurrency = 20，平均耗時(shí)穩(wěn)定在 8s~9s。由于聚合后的基數(shù)較大，壓力都集中在TiDB側(cè)，未能達(dá)到去ES的OLAP的場景。更多信息請參照AskTUG：千萬級數(shù)據(jù)group by性能調(diào)優(yōu)[1]。隨著TiDB 5.0發(fā)布，TiFlash已經(jīng)不僅僅是一個(gè)列式存儲引擎這么簡單。TiFlash引入了MPP模式，使得整個(gè)TiFlash從單純的存儲節(jié)點(diǎn)升級成為一個(gè)全功能的分析引擎。

[1] https://asktug.com/t/topic/68474/1

DorisDB+Elasticsearch

Mpp引擎列式存儲設(shè)計(jì)對于數(shù)據(jù)更新是極其不友好的。借助DorisDB的更新模型引擎，內(nèi)部通過版本號，可以支持大規(guī)模的數(shù)據(jù)實(shí)時(shí)更新，當(dāng)然在查詢時(shí)需要完成多版合并。同時(shí)Doris-On-ES將Doris的分布式查詢規(guī)劃能力和ES(Elasticsearch)的全文檢索能力相結(jié)合，提供更完善的OLAP分析場景解決方案。目前Doris On ES不支持聚合操作如sum，avg， min/max 等下推，計(jì)算方式是批量流式的從ES獲取所有滿足條件的文檔，然后在Doris中進(jìn)行計(jì)算。在測試場場景下，性能是可以滿足OLAP場景。實(shí)踐中發(fā)現(xiàn)，由于自建IDC機(jī)器較為老舊，無法支持SIMD指令，致使無法安裝DorisDB。

在目前的業(yè)務(wù)場景下，百分點(diǎn)科技最終選擇單一的Elasticsearch來作為數(shù)據(jù)集市層的存儲和計(jì)算引擎。后續(xù)如果數(shù)據(jù)集市有更大的數(shù)據(jù)量以及業(yè)務(wù)低延遲的OLAP查詢場景，還是會考慮結(jié)合MPP查詢引擎來滿足業(yè)務(wù)的擴(kuò)展。

3.2 數(shù)據(jù)倉庫層

在之前的很長一段時(shí)間內(nèi)，Elasticsearch Cluster承擔(dān)了大量數(shù)倉的職能。通過多集群進(jìn)行冷熱數(shù)據(jù)隔離。在本次調(diào)整中，百分點(diǎn)科技借助索引生命周期管理(ILM)和Hot\Warm架構(gòu)來實(shí)現(xiàn)在一個(gè)集群中進(jìn)行數(shù)據(jù)的管理。在實(shí)踐中，我們將Elasticsearch率先升級到7.12.0，以滿足向量化檢索等更多場景。

3.3 源數(shù)據(jù)層

之前會將采集的數(shù)據(jù)存儲至kafka，作為數(shù)據(jù)傳輸中轉(zhuǎn)。但kafka一般存儲的時(shí)間周期較短，且功能單一。因此需要一套統(tǒng)一的存儲計(jì)算平臺，需要滿足如下要求：

全量的離線數(shù)據(jù)是通過ES-Hadoop進(jìn)行按天備份，后續(xù)的變更就無法做到同步，復(fù)用性、靈活性較差；

圖片、音視頻等非結(jié)構(gòu)化數(shù)據(jù)的接入，需要方便與上層機(jī)器學(xué)習(xí)應(yīng)用深度融合；

輔助數(shù)據(jù)倉庫，構(gòu)建數(shù)據(jù)集市，保證實(shí)時(shí)性。

在最新的架構(gòu)中，百分點(diǎn)科技將數(shù)據(jù)先入湖，構(gòu)建ODS，輔助構(gòu)建上層DW和DM。關(guān)于Data Lake，最終選取Hudi作為源數(shù)據(jù)層存儲計(jì)算方案，并做了以下嘗試：

Iceberg

Iceberg工程架構(gòu)具有極高的抽象，可以與各種引擎無縫融合。字符串模糊匹配是一種重要場景，測試中遇到以下問題：如果某個(gè)字段存儲為空字符串，在匹配中就會出現(xiàn)異常：java.lang.IllegalArgumentException: Truncate length should be positive[2]。另外就是查詢對Stream相關(guān)支持還處于開發(fā)階段，對于增量數(shù)據(jù)處理只能以Java Api方式實(shí)現(xiàn)。

[2] https://github.com/apache/iceberg/issues/2065

Hudi

Hudi顯得尤為成熟，但是與 Spark 引擎綁定的較為緊密。在Hudi 0.6中對底層代碼進(jìn)行抽象，以適配Flink等主流計(jì)算引擎。同時(shí)其完善的增量查詢機(jī)制非常適合實(shí)時(shí)數(shù)據(jù)集市的構(gòu)建。另外Hudi Table并不需要提前創(chuàng)建，可以在寫入數(shù)據(jù)時(shí)自動創(chuàng)建，這也是區(qū)別于Iceberg的一個(gè)點(diǎn)。

Hudi的引入，為底層數(shù)據(jù)平臺帶來了ACID能力，并且提供較好實(shí)時(shí)性。特別是為數(shù)據(jù)集市實(shí)時(shí)數(shù)據(jù)構(gòu)建帶來便捷，提供可擴(kuò)展性。目前的簡易數(shù)據(jù)架構(gòu)如下：

三、AI平臺架構(gòu)

在海量的文本數(shù)據(jù)上，利用豐富的數(shù)據(jù)挖掘、深度學(xué)習(xí)、人工智能算法，訓(xùn)練在線和離線語義模型，一站式挖掘滿足客戶需要的輿情分析需求。在這一歷程中，大致分為兩個(gè)階段：

文本分析平臺：將通用文本能力服務(wù)化；

深度學(xué)習(xí)建模平臺：高效、易用、低門檻的模型定制開發(fā)平臺。

在上述演進(jìn)中，最主要的變化在于各行各業(yè)都已經(jīng)積累了較多的高價(jià)值數(shù)據(jù)，并且越來越需要定制滿足自己場景的個(gè)性化模型。下面主要從這兩個(gè)階段分別展開對應(yīng)的工作。

文本分析平臺

在輿情分析場景中，依賴于分詞、詞性、新詞發(fā)現(xiàn)、命名實(shí)體、主體分類、文本聚類、關(guān)鍵詞提取、自動摘要、文本去重、情感分析、內(nèi)容轉(zhuǎn)換（簡繁、拼音）、自動糾錯(cuò)、自動補(bǔ)全、文檔解析等各種功能。產(chǎn)品架構(gòu)和數(shù)據(jù)流程如下：

深度學(xué)習(xí)建模平臺

隨著深度遷移學(xué)習(xí)成熟和行業(yè)應(yīng)用，帶來最大的益處在于可以依據(jù)少量的訓(xùn)練數(shù)據(jù)便可以得到較好的訓(xùn)練結(jié)果。從下述對比中：可以看到Bert在少訓(xùn)練集下就能達(dá)到較好的結(jié)果，也為后續(xù)的定制化模型奠定了基礎(chǔ)。

輿情系統(tǒng)本身可以看作為信息工程架構(gòu)，客戶可以容忍數(shù)據(jù)精準(zhǔn)度，但是不允許相同的數(shù)據(jù)持續(xù)犯錯(cuò)?？蓪W(xué)習(xí)、可持續(xù)、可定制已經(jīng)變的尤為重要。這也是深度學(xué)習(xí)建模平臺的由來。

下面是整體的業(yè)務(wù)架構(gòu)和流程分析，具體技術(shù)細(xì)節(jié)可參照：NLP模型開發(fā)平臺在輿情分析中的設(shè)計(jì)和實(shí)踐。

四、微服務(wù)架構(gòu)

下面對互聯(lián)網(wǎng)架構(gòu)演進(jìn)之路進(jìn)行總結(jié)如下，其中帶顏色標(biāo)記的為實(shí)踐中的產(chǎn)物。

輿情業(yè)務(wù)應(yīng)用系統(tǒng)從最核心幾個(gè)業(yè)務(wù)功能，目前已經(jīng)擴(kuò)展至幾十個(gè)業(yè)務(wù)模塊。同時(shí)借助成熟的底層模塊，快速沉淀出金融輿情、行業(yè)版等眾多項(xiàng)目。大致經(jīng)過以下三個(gè)階段。

1. 單體架構(gòu)

在業(yè)務(wù)初期，使用SpringBoot作為單體應(yīng)用開發(fā)程序，可極大加快業(yè)務(wù)推進(jìn)速度，簡易架構(gòu)如下：

單體架構(gòu)的優(yōu)點(diǎn)在于其易開發(fā)、易測試、易部署、易擴(kuò)展，但是業(yè)務(wù)耦合嚴(yán)重，也為業(yè)務(wù)擴(kuò)展、服務(wù)治理帶來了新的挑戰(zhàn)。例如：登錄服務(wù)和查詢服務(wù)在一個(gè)單體應(yīng)用中，因?yàn)椴樵兎?wù)是一個(gè)耗內(nèi)存的操作，高峰時(shí)會引起FullGC，致使登錄功能異常。

2. 微服務(wù)架構(gòu)

微服務(wù)可以定義如下：

?種架構(gòu)?格，將單體應(yīng)?劃分成?組?的服務(wù)，服務(wù)之間相互協(xié)作，實(shí)現(xiàn)業(yè)務(wù)功能。每個(gè)服務(wù)運(yùn)?在獨(dú)?的進(jìn)程中，服務(wù)間采?輕量級的通信機(jī)制協(xié)作（通常是HTTP/JSON）;

每個(gè)服務(wù)圍繞業(yè)務(wù)能?進(jìn)?構(gòu)建，并且能夠通過?動化機(jī)制獨(dú)?地部署；

很少有集中式的服務(wù)管理，每個(gè)服務(wù)可以使?不同的語?開發(fā)，使?不同的存儲技術(shù)；

參考：https://www.martinfowler.com/articles/microservices.html。

隨著業(yè)務(wù)擴(kuò)展，業(yè)務(wù)耦合嚴(yán)重，開發(fā)效率低下、排查問題困難等。秉承業(yè)務(wù)維度垂直拆分和功能維度水平拆分的原則，同時(shí)盡量避免分布式事務(wù)等復(fù)雜度問題。拆分后架構(gòu)圖如下：

微服務(wù)拆分功效：

業(yè)務(wù)邏輯層：拆分后服務(wù)模塊30+；

監(jiān)控體系建立：日志監(jiān)控、Metrics監(jiān)控、調(diào)用鏈監(jiān)控、告警系統(tǒng)、健康檢查；

配置中心：靈活可視化的配置管理中心；

開發(fā)效率、團(tuán)隊(duì)協(xié)作能力提升。

3. 云原生架構(gòu)

云原生包含了一組應(yīng)用的模式，用于幫助企業(yè)快速，持續(xù)，可靠，規(guī)?；慕桓稑I(yè)務(wù)軟件。其特點(diǎn)如下：

容器化封裝：以容器為基礎(chǔ)，提高整體開發(fā)水平，形成代碼和組件重用，簡化云原生應(yīng)用程序的維護(hù)，在容器中運(yùn)行應(yīng)用程序和進(jìn)程，并作為應(yīng)用程序部署的獨(dú)立單元，實(shí)現(xiàn)高水平資源隔離；

動態(tài)管理：通過集中式的編排調(diào)度系統(tǒng)來動態(tài)的管理和調(diào)度；

面向微服務(wù)：明確服務(wù)間的依賴，互相解耦。

借助百分點(diǎn)科技內(nèi)部云平臺，將微服務(wù)結(jié)構(gòu)容器化封裝，極大的降低了部署、運(yùn)維的成本，也為服務(wù)的穩(wěn)定性增加了保證機(jī)制。下面主要介紹一下云平臺的基礎(chǔ)概念和應(yīng)用成效。

平臺基礎(chǔ)概念：

命名空間

管理常規(guī)用戶的資源訪問權(quán)限的中央載體，讓一組用戶組織和管理他們的內(nèi)容，并與其它群體區(qū)隔開來。是用戶賬號的唯一公共URL訪問地址。

容器

Docker容器為資源分割和調(diào)度的基本單位，封裝整個(gè)軟件運(yùn)行時(shí)的環(huán)境，為開發(fā)者和管理員設(shè)計(jì)的，用于構(gòu)建、發(fā)布和運(yùn)行分布式應(yīng)用平臺。

鏡像

含有啟動Docker容器所需的文件系統(tǒng)結(jié)構(gòu)及其內(nèi)容，因此是啟動一個(gè)Docker容器的基礎(chǔ)。采用分層的結(jié)構(gòu)構(gòu)建。

項(xiàng)目

通過標(biāo)簽標(biāo)識的多個(gè)版本的鏡像組成。

構(gòu)建

將輸入?yún)?shù)轉(zhuǎn)換為結(jié)果對象的過程；通常用于將輸入?yún)?shù)或源代碼轉(zhuǎn)換為可運(yùn)行的鏡像從構(gòu)建鏡像創(chuàng)建Docker容器并將它們推送到集成的容器鏡像倉庫（Harbor）

S2I構(gòu)建：通過注入應(yīng)用源代碼到Docker鏡像并且組建新的Docker鏡像來生成可運(yùn)行的鏡像新鏡像中融合基礎(chǔ)鏡像和構(gòu)建的源代碼，并可搭配docker run命令使用。S2I支持遞增構(gòu)建，可重復(fù)利用以前的下載依賴項(xiàng)和過去構(gòu)建的構(gòu)件等。

服務(wù)

平臺部署應(yīng)用的最小單位，一個(gè)服務(wù)為一個(gè)功能單元，如mysql數(shù)據(jù)庫服務(wù)。是定義容器實(shí)例的邏輯集合以及訪問它們的策略，一個(gè)服務(wù)至少包含一個(gè)容器實(shí)例，服務(wù)通常用于為一組相似的容器提供永久IP。在內(nèi)部，服務(wù)在被訪問時(shí)實(shí)行負(fù)載均衡并代理到相應(yīng)的支持容器實(shí)例，可以在服務(wù)中任意添加或者刪除支持容器,而一直保持服務(wù)可用。

配額

在同一個(gè)命名空間內(nèi)可以創(chuàng)建的最大對象資源數(shù)量，以及每個(gè)容器請求的計(jì)算/內(nèi)存/存儲資源。

高級編排

編排模板：描述可以參數(shù)化和處理一系列對象，生成的服務(wù)、構(gòu)建配置和部署配置?？梢詾殚_發(fā)人員即時(shí)創(chuàng)建可部署的應(yīng)用。

平臺資源對象層級關(guān)系：

目前平臺代碼構(gòu)建支持三種模式：

智能構(gòu)建

基于平臺所提供的Builder鏡像，自動下載應(yīng)用源碼進(jìn)行編譯。在基礎(chǔ)鏡像之上，自動編譯代碼。

Dockerfile構(gòu)建

用戶自己編寫Dockerfile，指定代碼庫、Dockerfile位置及代碼分支后可以構(gòu)建項(xiàng)目鏡像。

自定義的Dockerfile，可以指定自定義基礎(chǔ)鏡像以及編譯環(huán)境變量、配置信息等構(gòu)建出更復(fù)雜的編譯或運(yùn)行環(huán)境，構(gòu)建靈活性相比前者更高。

Push構(gòu)建

通過平臺提供的push構(gòu)建流程，將本地定制化鏡像上傳到鏡像倉庫，導(dǎo)入后的鏡像可以在平臺中進(jìn)行部署、調(diào)試、使用。

平臺Scale功能包含水平伸縮和垂直伸縮，以下是水平伸縮的例子：

平臺提供容器實(shí)例監(jiān)控，可以按照時(shí)間區(qū)間圖形化展示容器的CPU、內(nèi)存和網(wǎng)絡(luò)的使用情況：

總結(jié)

企業(yè)SaaS一般是圍繞獲客、轉(zhuǎn)化、留存這三個(gè)階段展開，平臺的易用性、數(shù)據(jù)的準(zhǔn)確性和實(shí)時(shí)性等都是客戶留存的核心要素。在多年的實(shí)踐中，大數(shù)據(jù)架構(gòu)以數(shù)據(jù)湖為ODS層，來保證對原始數(shù)據(jù)高效、靈活的處理，同時(shí)為其他業(yè)務(wù)線開放數(shù)據(jù)處理能力。AI平臺架構(gòu)提供一套端到端的閉環(huán)流水線，打造個(gè)性化、智能化的業(yè)務(wù)。微服務(wù)架構(gòu)通過容器化，極大的降低維護(hù)成本，同時(shí)保證線上穩(wěn)定性。隨著SaaS產(chǎn)品矩陣的擴(kuò)充，百分點(diǎn)科技在金融輿情、企業(yè)品牌監(jiān)測等多個(gè)方向進(jìn)行積極嘗試，底層平臺架構(gòu)在業(yè)務(wù)的快速落地中起到了重要作用。

xiesc