前言

互聯(lián)網(wǎng)的飛速發(fā)展促進(jìn)了很多新媒體的發(fā)展，不論是知名的大V，明星還是圍觀群眾都可以通過手機(jī)在微博，朋友圈或者點評網(wǎng)站上發(fā)表狀態(tài)，分享自己的所見所想，使得“人人都有了麥克風(fēng)”。不論是熱點新聞還是娛樂八卦，傳播速度遠(yuǎn)超我們的想象?？梢栽诙潭虜?shù)分鐘內(nèi)，有數(shù)萬計轉(zhuǎn)發(fā)，數(shù)百萬的閱讀。如此海量的信息可以得到爆炸式的傳播，如何能夠?qū)崟r的把握民情并作出對應(yīng)的處理對很多企業(yè)來說都是至關(guān)重要的。大數(shù)據(jù)時代，除了媒體信息以外，商品在各類電商平臺的訂單量，用戶的購買評論也都對后續(xù)的消費者產(chǎn)生很大的影響。商家的產(chǎn)品設(shè)計者需要匯總統(tǒng)計和分析各類平臺的數(shù)據(jù)做為依據(jù)，決定后續(xù)的產(chǎn)品發(fā)展，公司的公關(guān)和市場部門也需要根據(jù)輿情作出相應(yīng)的及時處理，而這一切也意味著傳統(tǒng)的輿情系統(tǒng)升級成為大數(shù)據(jù)輿情采集和分析系統(tǒng)。

分析完輿情場景后，我們再來具體細(xì)化看下大數(shù)據(jù)輿情系統(tǒng)，對我們的數(shù)據(jù)存儲和計算系統(tǒng)提出哪些需求：

海量原始數(shù)據(jù)的實時入庫：為了實現(xiàn)一整套輿情系統(tǒng)，需要有上游原始輸出的采集，也就是爬蟲系統(tǒng)。爬蟲需要采集各類門戶，自媒體的網(wǎng)頁內(nèi)容。在抓取前需要去重，抓取后還需要分析提取，例如進(jìn)行子網(wǎng)頁的抓取。原始網(wǎng)頁數(shù)據(jù)的處理：不論是主流門戶還是自媒體的網(wǎng)頁信息，抓取后我們需要做一定的數(shù)據(jù)提取，把原始的網(wǎng)頁內(nèi)容轉(zhuǎn)化為結(jié)構(gòu)化數(shù)據(jù)，例如文章的標(biāo)題，摘要等，如果是商品點評類消息也需要提取有效的點評。結(jié)構(gòu)化數(shù)據(jù)的輿情分析：當(dāng)各類原始輸出變成結(jié)構(gòu)化的數(shù)據(jù)后，我們需要有一個實時的計算產(chǎn)品把各類輸出做合理的分類，進(jìn)一步對分類后的內(nèi)容進(jìn)行情感打標(biāo)。根據(jù)業(yè)務(wù)的需求這里可能會產(chǎn)生不同的輸出，例如品牌當(dāng)下是否有熱點話題，輿情影響力分析，轉(zhuǎn)播路徑分析，參與用戶統(tǒng)計和畫像，輿論情感分析或者是否有重大預(yù)警。輿情分析系統(tǒng)中間和結(jié)果數(shù)據(jù)的存儲，交互分析查詢：從網(wǎng)頁原始數(shù)據(jù)清洗到最終的輿情報表這中間會產(chǎn)生很多類型的數(shù)據(jù)。這些數(shù)據(jù)有的會提供給數(shù)據(jù)分析同學(xué)進(jìn)行輿情分析系統(tǒng)的調(diào)優(yōu)，有的數(shù)據(jù)會提供給業(yè)務(wù)部門根據(jù)輿情結(jié)果進(jìn)行決策。這些查詢可能會很靈活，需要我們的存儲系統(tǒng)具備全文檢索，多字段組合靈活的交互分析能力。重大輿情事件的實時預(yù)警：對于輿情的結(jié)果除了正常的搜索和展示需求以外，當(dāng)有重大事件出現(xiàn)我們需要能做到實時的預(yù)警。

我們計劃分兩篇介紹完整的輿情新架構(gòu)，第一篇主要是提供架構(gòu)設(shè)計，會先介紹時下主流的大數(shù)據(jù)計算架構(gòu)，并分析一些優(yōu)缺點，然后引入輿情大數(shù)據(jù)架構(gòu)。第二篇會有完整的數(shù)據(jù)庫表設(shè)計和部分示例代碼。大家敬請期待。

系統(tǒng)設(shè)計

需求分析

結(jié)合文章開頭對輿情系統(tǒng)的描述，海量大數(shù)據(jù)輿情分析系統(tǒng)流程圖大體如下：

圖1 輿情系統(tǒng)業(yè)務(wù)流程

原始網(wǎng)頁存儲庫，這個庫需要能支持海量數(shù)據(jù)，低成本，低延時寫入。網(wǎng)頁數(shù)據(jù)寫入后，要做實時結(jié)構(gòu)化提取，提取出來的數(shù)據(jù)再進(jìn)行降噪，分詞，圖片ocr處理等。對分詞文本，圖片進(jìn)行情感識別產(chǎn)生輿情數(shù)據(jù)結(jié)果集。傳統(tǒng)的離線全量計算很難滿足輿情系統(tǒng)的時效性需求。計算引擎在做數(shù)據(jù)處理時，可能還需要從存儲庫中獲取一些元數(shù)據(jù)，例如用戶信息，情感詞元數(shù)據(jù)信息等。除了實時的計算鏈路，對存量數(shù)據(jù)定期要做一些聚類，優(yōu)化我們的情感詞識別庫，或者上游根據(jù)業(yè)務(wù)需要觸發(fā)情感處理規(guī)則更新，根據(jù)新的情感打標(biāo)庫對存量數(shù)據(jù)做一次輿情計算。輿情的結(jié)果數(shù)據(jù)集有不同類的使用需求。對于重大輿情，需要做實時的預(yù)警。完整的輿情結(jié)果數(shù)據(jù)展示層需要支持全文檢索，靈活的屬性字段組合查詢。業(yè)務(wù)上可能根據(jù)屬性字段中的置信度，輿情時間，或者關(guān)鍵詞組合進(jìn)行分析。

根據(jù)前面的介紹，輿情大數(shù)據(jù)分析系統(tǒng)需要兩類計算，一類是實時計算包括海量網(wǎng)頁內(nèi)容實時抽取，情感詞分析并進(jìn)行網(wǎng)頁輿情結(jié)果存儲。另一類是離線計算，系統(tǒng)需要對歷史數(shù)據(jù)進(jìn)行回溯，結(jié)合人工標(biāo)注等方式優(yōu)化情感詞庫，對一些實時計算的結(jié)果進(jìn)行矯正等。所以在系統(tǒng)設(shè)計上，需要選擇一套既可以做實時計算又能做批量離線計算的系統(tǒng)。在開源大數(shù)據(jù)解決方案中，Lambda架構(gòu)恰好可以滿足這些需求，下面我們來介紹下Lambda的架構(gòu)。

Lambda架構(gòu) （wiki）

圖2 Lambda架構(gòu)圖

Lambda架構(gòu)可以說是Hadoop，Spark體系下最火的大數(shù)據(jù)架構(gòu)。這套架構(gòu)的最大優(yōu)勢就是在支持海量數(shù)據(jù)批量計算處理（也就是離線處理）同時也支持流式的實時處理（即熱數(shù)據(jù)處理）。

具體是如何實現(xiàn)的呢，首先上游一般是一個隊列服務(wù)例如kafka，實時存儲數(shù)據(jù)的寫入。kafka隊列會有兩個訂閱者，一個是全量數(shù)據(jù)即圖片中上半部分，全量數(shù)據(jù)會被存儲在類似HDFS這樣的存儲介質(zhì)上。當(dāng)有離線計算任務(wù)到來，計算資源（例如Hadoop）會訪問存儲系統(tǒng)上的全量數(shù)據(jù)，進(jìn)行全量批計算的處理邏輯。經(jīng)過map/reduce環(huán)節(jié)后全量的結(jié)果會被寫入一個結(jié)構(gòu)化的存儲引擎例如Hbase中，提供給業(yè)務(wù)方查詢。隊列的另一個消費訂閱方是流計算引擎，流計算引擎往往會實時的消費隊列中的數(shù)據(jù)進(jìn)行計算處理，例如Spark Streaming實時訂閱Kafka的數(shù)據(jù)，流計算結(jié)果也會寫入一個結(jié)構(gòu)化數(shù)據(jù)引擎。批量計算和流計算的結(jié)果寫入的結(jié)構(gòu)化存儲引擎即上圖標(biāo)注3的"Serving Layer"，這一層主要提供結(jié)果數(shù)據(jù)的展示和查詢。

在這套架構(gòu)中，批量計算的特點是需要支持處理海量的數(shù)據(jù)，并根據(jù)業(yè)務(wù)的需求，關(guān)聯(lián)一些其他業(yè)務(wù)指標(biāo)進(jìn)行計算。批量計算的好處是計算邏輯可以根據(jù)業(yè)務(wù)需求靈活調(diào)整，同時計算結(jié)果可以反復(fù)重算，同樣的計算邏輯多次計算結(jié)果不會改變。批量計算的缺點是計算周期相對較長，很難滿足實時出結(jié)果的需求，所以隨著大數(shù)據(jù)計算的演進(jìn)，提出了實時計算的需求。實時計算在Lambda架構(gòu)中是通過實時數(shù)據(jù)流來實現(xiàn)，相比批處理，數(shù)據(jù)增量流的處理方式?jīng)Q定了數(shù)據(jù)往往是最近新產(chǎn)生的數(shù)據(jù)，也就是熱數(shù)據(jù)。正因為熱數(shù)據(jù)這一特點，流計算可以滿足業(yè)務(wù)對計算的低延時需求，例如在輿情分析系統(tǒng)中，我們往往希望輿情信息可以在網(wǎng)頁抓取下來后，分鐘級別拿到計算結(jié)果，給業(yè)務(wù)方充足的時間進(jìn)行輿情反饋。下面我們就來具體看一下，基于Lambda架構(gòu)的思想如何實現(xiàn)一套完整的輿情大數(shù)據(jù)架構(gòu)。

開源輿情大數(shù)據(jù)方案

通過這個流程圖，讓我們了解了整個輿情系統(tǒng)的建設(shè)過程中，需要經(jīng)過不同的存儲和計算系統(tǒng)。對數(shù)據(jù)的組織和查詢有不同的需求。在業(yè)界基于開源的大數(shù)據(jù)系統(tǒng)并結(jié)合Lambda架構(gòu)，整套系統(tǒng)可以設(shè)計如下：

圖3 開源輿情架構(gòu)圖

系統(tǒng)的最上游是分布式的爬蟲引擎，根據(jù)抓取任務(wù)抓取訂閱的網(wǎng)頁原文內(nèi)容。爬蟲會把抓取到的網(wǎng)頁內(nèi)容實時寫入Kafka隊列，進(jìn)入Kafka隊列的數(shù)據(jù)根據(jù)前面描述的計算需求，會實時流入流計算引擎（例如Spark或者Flink），也會持久化存儲在Hbase，進(jìn)行全量數(shù)據(jù)的存儲。全量網(wǎng)頁的存儲可以滿足網(wǎng)頁爬取去重，批量離線計算的需求。流計算會對原始網(wǎng)頁進(jìn)行結(jié)構(gòu)化提取，將非結(jié)構(gòu)化網(wǎng)頁內(nèi)容轉(zhuǎn)化為結(jié)構(gòu)數(shù)據(jù)并進(jìn)行分詞，例如提取出網(wǎng)頁的標(biāo)題，作者，摘要等，對正文和摘要內(nèi)容進(jìn)行分詞。提取和分詞結(jié)果會寫回Hbase。結(jié)構(gòu)化提取和分詞后，流計算引擎會結(jié)合情感詞庫進(jìn)行網(wǎng)頁情感分析，判斷是否有輿情產(chǎn)生。流計算引擎分析的輿情結(jié)果存儲Mysql或者Hbase數(shù)據(jù)庫中，為了方便結(jié)果集的搜索查看，需要把數(shù)據(jù)同步到一個搜索引擎例如Elasticsearch，方便進(jìn)行屬性字段的組合查詢。如果是重大的輿情時間，需要寫入Kafka隊列觸發(fā)輿情報警。全量的結(jié)構(gòu)化數(shù)據(jù)會定期通過Spark系統(tǒng)進(jìn)行離線計算，更新情感詞庫或者接受新的計算策略重新計算歷史數(shù)據(jù)修正實時計算的結(jié)果。開源架構(gòu)分析

上面的輿情大數(shù)據(jù)架構(gòu)，通過Kafka對接流計算，Hbase對接批計算來實現(xiàn)Lambda架構(gòu)中的“batch view”和“real-time view”，整套架構(gòu)還是比較清晰的，可以很好的滿足在線和離線兩類計算需求。但是把這一套系統(tǒng)應(yīng)用在生產(chǎn)并不是一件容易的事情，主要有下面一些原因。

整套架構(gòu)涉及到非常多的存儲和計算系統(tǒng)包括：Kafka，Hbase，Spark，F(xiàn)link，Elasticsearch。數(shù)據(jù)會在不同的存儲和計算系統(tǒng)中流動，運維好整套架構(gòu)中的每一個開源產(chǎn)品都是一個很大的挑戰(zhàn)。任何一個產(chǎn)品或者是產(chǎn)品間的通道出現(xiàn)故障，對整個輿情分析結(jié)果的時效性都會產(chǎn)生影響。為了實現(xiàn)批計算和流計算，原始的網(wǎng)頁需要分別存儲在Kafka和Hbase中，離線計算是消費hbase中的數(shù)據(jù)，流計算消費Kafka的數(shù)據(jù)，這樣會帶來存儲資源的冗余，同時也導(dǎo)致需要維護(hù)兩套計算邏輯，計算代碼開發(fā)和維護(hù)成本也會上升。輿情的計算結(jié)果存儲在Mysql或者Hbase，為了豐富組合查詢語句，需要把數(shù)據(jù)同步構(gòu)建到Elasticsearch中。查詢的時候可能需要組合Mysql和Elasticsearch的查詢結(jié)果。這里沒有跳過數(shù)據(jù)庫，直接把結(jié)果數(shù)據(jù)寫入Elasticsearch這類搜索系統(tǒng)，是因為搜索系統(tǒng)的數(shù)據(jù)實時寫入能力和數(shù)據(jù)可靠性不如數(shù)據(jù)庫，業(yè)界通常是把數(shù)據(jù)庫和搜索系統(tǒng)整合，整合下的系統(tǒng)兼?zhèn)淞藬?shù)據(jù)庫和搜索系統(tǒng)的優(yōu)勢，但是兩個引擎之間數(shù)據(jù)的同步和跨系統(tǒng)查詢對運維和開發(fā)帶來很多額外的成本。新的大數(shù)據(jù)架構(gòu)Lambda plus

通過前面的分析，相信大家都會有一個疑問，有沒有簡化的的大數(shù)據(jù)架構(gòu)，在可以滿足Lambda對計算需求的假設(shè)，又能減少存儲計算以及模塊的個數(shù)呢。Linkedin的Jay Kreps提出了Kappa架構(gòu)，關(guān)于Lambda和Kappa的對比可以參考"云上大數(shù)據(jù)方案"這篇，這里不展開詳細(xì)對比，簡單說下，Kappa為了簡化兩份存儲，取消了全量的數(shù)據(jù)存儲庫，通過在Kafka保留更長日志，當(dāng)有回溯重新計算需求到來時，重新從隊列的頭部開始訂閱數(shù)據(jù)，再一次用流的方式處理Kafka隊列中保存的所有數(shù)據(jù)。這樣設(shè)計的好處是解決了需要維護(hù)兩份存儲和兩套計算邏輯的痛點，美中不足的地方是隊列可以保留的歷史數(shù)據(jù)畢竟有限，難以做到無時間限制的回溯。分析到這里，我們沿著Kappa針對Lambda的改進(jìn)思路，向前多思考一些：假如有一個存儲引擎，既滿足數(shù)據(jù)庫可以高效的寫入和隨機(jī)查詢，又能像隊列服務(wù)，滿足先進(jìn)先出，是不是就可以把Lambda和Kappa架構(gòu)揉合在一起，打造一個Lambda plus架構(gòu)呢？

新架構(gòu)在Lambda的基礎(chǔ)上可以提升以下幾點：

在支持流計算和批計算的同時，讓計算邏輯可以復(fù)用，實現(xiàn)“一套代碼兩類需求”。統(tǒng)一歷史數(shù)據(jù)全量和在線實時增量數(shù)據(jù)的存儲，實現(xiàn)“一份存儲兩類計算”。為了方便輿情結(jié)果查詢需求，“batch view”和“real-time view”存儲在既可以支持高吞吐的實時寫入，也可以支持多字段組合搜索和全文檢索。

總結(jié)起來就是整套新架構(gòu)的核心是解決存儲的問題，以及如何靈活的對接計算。我們希望整套方案是類似下面的架構(gòu)：

圖4 Lambda Plus架構(gòu)

數(shù)據(jù)流實時寫入一個分布式的數(shù)據(jù)庫，借助于數(shù)據(jù)庫查詢能力，全量數(shù)據(jù)可以輕松的對接批量計算系統(tǒng)進(jìn)行離線處理。數(shù)據(jù)庫通過數(shù)據(jù)庫日志接口，支持增量讀取，實現(xiàn)對接流計算引擎進(jìn)行實時計算。批計算和流計算的結(jié)果寫回分布式數(shù)據(jù)庫，分布式數(shù)據(jù)庫提供豐富的查詢語意，實現(xiàn)計算結(jié)果的交互式查詢。

整套架構(gòu)中，存儲層面通過結(jié)合數(shù)據(jù)庫主表數(shù)據(jù)和數(shù)據(jù)庫日志來取代大數(shù)據(jù)架構(gòu)中的隊列服務(wù)，計算系統(tǒng)選取天然支持批和流的計算引擎例如Flink或者Spark。這樣一來，我們既可以像Lambda進(jìn)行無限制的歷史數(shù)據(jù)回溯，又可以像Kappa架構(gòu)一樣一套邏輯，存儲處理兩類計算任務(wù)。這樣的一套架構(gòu)我們?nèi)∶麨椤癓ambda plus”，下面就詳細(xì)展開如何在阿里云上打造這樣的一套大數(shù)據(jù)架構(gòu)。

云上輿情系統(tǒng)架構(gòu)

在阿里云眾多存儲和計算產(chǎn)品中，貼合上述大數(shù)據(jù)架構(gòu)的需求，我們選用兩款產(chǎn)品來實現(xiàn)整套輿情大數(shù)據(jù)系統(tǒng)。存儲層面使用阿里云自研的分布式多模型數(shù)據(jù)庫Tablestore，計算層選用Blink來實現(xiàn)流批一體計算。

圖5 云上輿情大數(shù)據(jù)架構(gòu)

這套架構(gòu)在存儲層面，全部基于Tablestore，一個數(shù)據(jù)庫解決不同存儲需求，根據(jù)之前輿情系統(tǒng)的介紹，網(wǎng)頁爬蟲數(shù)據(jù)在系統(tǒng)流動中會有四個階段分別是原始網(wǎng)頁內(nèi)容，網(wǎng)頁結(jié)構(gòu)化數(shù)據(jù)，分析規(guī)則元數(shù)據(jù)和輿情結(jié)果，輿情結(jié)果索引。我們利用Tablestore寬行和schema free的特性，合并原始網(wǎng)頁和網(wǎng)頁結(jié)構(gòu)化數(shù)據(jù)成一張網(wǎng)頁數(shù)據(jù)。網(wǎng)頁數(shù)據(jù)表和計算系統(tǒng)通過Tablestore新功能通道服務(wù)進(jìn)行對接。通道服務(wù)基于數(shù)據(jù)庫日志，數(shù)據(jù)的組織結(jié)構(gòu)按照數(shù)據(jù)的寫入順序進(jìn)行存儲，正是這一特性，賦能數(shù)據(jù)庫具備了隊列流式消費能力。使得存儲引擎既可以具備數(shù)據(jù)庫的隨機(jī)訪問，也可以具備隊列的按照寫入順序訪問，這也就滿足我們上面提到整合Lambda和kappa架構(gòu)的需求。分析規(guī)則元數(shù)據(jù)表由分析規(guī)則，情感詞庫組層，對應(yīng)實時計算中的維表。

計算系統(tǒng)這里選用阿里云實時流計算產(chǎn)品Blink，Blink是一款支持流計算和批計算一體的實時計算產(chǎn)品。并且類似Tablestore可以很容易的做到分布式水平擴(kuò)展，讓計算資源隨著業(yè)務(wù)數(shù)據(jù)增長彈性擴(kuò)容。使用Tablestore + Blink的優(yōu)勢有以下幾點：

Tablestore已經(jīng)深度和Blink進(jìn)行整合，支持源表，維表和目的表，業(yè)務(wù)無需為數(shù)據(jù)流動開發(fā)代碼。整套架構(gòu)大幅降低組建個數(shù)，從開源產(chǎn)品的6～7個組建減少到2個，Tablestore和Blink都是全托管0運維的產(chǎn)品，并且都能做到很好的水平彈性，業(yè)務(wù)峰值擴(kuò)展無壓力，使得大數(shù)據(jù)架構(gòu)的運維成本大幅降低。業(yè)務(wù)方只需要關(guān)注數(shù)據(jù)的處理部分邏輯，和Tablestore的交互邏輯都已經(jīng)集成在Blink中。開源方案中，如果數(shù)據(jù)庫源希望對接實時計算，還需要雙寫一個隊列，讓流計算引擎消費隊列中的數(shù)據(jù)。我們的架構(gòu)中數(shù)據(jù)庫既作為數(shù)據(jù)表，又是隊列通道可以實時增量數(shù)據(jù)消費。大大簡化了架構(gòu)的開發(fā)和使用成本。流批一體，在輿情系統(tǒng)中實時性是至關(guān)重要的，所以我們需要一個實時計算引擎，而Blink除了實時計算以外，也支持批處理Tablestore的數(shù)據(jù)， 在業(yè)務(wù)低峰期，往往也需要批量處理一些數(shù)據(jù)并作為反饋結(jié)果寫回Tablestore，例如情感分析反饋等。那么一套架構(gòu)既可以支持流處理又可以支持批處理是再好不過。這里我們可以參考之前的一篇文章《實時計算最佳實踐：基于表格存儲和Blink的大數(shù)據(jù)實時計算 https://yq.aliyun.com/articles/692526》。一套架構(gòu)帶來的優(yōu)勢是，一套分析代碼既可以做實時流計算又可以離線批處理。

整個計算流程會產(chǎn)生實時的輿情計算結(jié)果。重大輿情事件的預(yù)警，通過Tablestore和函數(shù)計算觸發(fā)器對接來實現(xiàn)。Tablestore和函數(shù)計算做了增量數(shù)據(jù)的無縫對接，通過結(jié)果表寫入事件，可以輕松的通過函數(shù)計算觸發(fā)短信或者郵件通知。完整的輿情分析結(jié)果和展示搜索利用了Tablestore的新功能多元索引，徹底解決了開源Hbase+Solr多引擎的痛點：

運維復(fù)雜，需要有運維hbase和solr兩套系統(tǒng)的能力，同時還需要維護(hù)數(shù)據(jù)同步的鏈路。Solr數(shù)據(jù)一致性不如Hbase，在Hbase和Solr數(shù)據(jù)語意并不是完全一致，加上Solr/Elasticsearch在數(shù)據(jù)一致性很難做到像數(shù)據(jù)庫那么嚴(yán)格。在一些極端情況下會出現(xiàn)數(shù)據(jù)不一致的問題，開源方案也很難做到跨系統(tǒng)的一致性比對。查詢接口需要維護(hù)兩套API，需要同時使用Hbase client和Solr client，索引中沒有的字段需要主動反查Hbase，易用性較差。參考文獻(xiàn)

1.Lambda大數(shù)據(jù)架構(gòu)

https://mapr.com/tech-briefs/stream-processing-mapr/

2.Kappa大數(shù)據(jù)架構(gòu)

https://xintu.oreilly.com/ideas/questioning-the-lambda-architecture

3.Lambda和Kappa架構(gòu)對比

https://xintu.ericsson.com/en/blog/2015/11/data-processing-architectures--lambda-and-kappa

總結(jié)

本文基于《百億級全網(wǎng)輿情分析系統(tǒng)存儲設(shè)計 https://yq.aliyun.com/articles/265024》并結(jié)合Tablestore的新功能做了現(xiàn)代大數(shù)據(jù)輿情系統(tǒng)的架構(gòu)升級，實現(xiàn)了海量信息下的實時輿情分析存儲系統(tǒng)。也介紹了開源方案，并和我們的方案做了詳細(xì)的對比。

作者：宇珩

原文鏈接：https://yq.aliyun.com/articles/704171?utm_content=g_1000060603