【文章內容簡介】 **電子政務公共數(shù)據(jù)開放共享平臺的用戶分為：領導、各部門、企業(yè)單位及社會公眾。 政府領導**電子政務公共數(shù)據(jù)開放共享平臺有價值的數(shù)據(jù)、行政地圖、決策方法和應急進行融合，采用大數(shù)據(jù)分析技術，有利于各級領導、管理決策人員方便、直觀、形象地進行各種分析，從而使統(tǒng)計決策的科學化、人性化、智能化管理走上一個新臺階。 政府部門可以向**電子政務公共數(shù)據(jù)開放共享平臺提供數(shù)據(jù)或使用平臺提供的數(shù)據(jù)；業(yè)務部門之間可以通過系統(tǒng)平臺交換共享數(shù)據(jù)；遵循標準規(guī)范進行業(yè)務系統(tǒng)的建造和改進，可實現(xiàn)業(yè)務系統(tǒng)和數(shù)據(jù)開放共享平臺的對接。 社會公眾可以依托**電子政務公共數(shù)據(jù)開放共享平臺提供的應用服務對公眾需求做出快速反應，公眾可以更直接廣泛的獲得政府提供的服務，如證照協(xié)同、社保電子傳遞等。 企業(yè)單位通過**電子政務公共數(shù)據(jù)開放共享平臺提供的應用服務可以方11
 **政務大數(shù)據(jù)交換共享平臺建設方案便企業(yè)進行業(yè)務級信息查詢，并可通過業(yè)務協(xié)同對企業(yè)提供事項審批、信息推送服務。 業(yè)務功能分析 數(shù)據(jù)共享在政府部門內部強調的是共享共用。先把政府部門內部及部門之間數(shù)據(jù)共享的工作做起來。各級政府都以數(shù)據(jù)應用為導向，需要什么數(shù)據(jù)就共享什么數(shù)據(jù)。部門間的信息共享，綜合考慮管理難度和技術難度建議分為三個階段：“條線內部門共享”、“平級跨部門共享”、“跨層級和跨區(qū)域的共享”，通過統(tǒng)一規(guī)劃，逐步推進的策略，打造部門間信息資源共享共用的新格局。 數(shù)據(jù)開放對社會的數(shù)據(jù)開放，先從方便百姓生活又不是很敏感的數(shù)據(jù)開始。特別是涉及公共安全、公共利益的數(shù)據(jù)，提供公共服務的機構或企業(yè)有義務在一定前提條件下開放，這樣一些可以預警、預防的群體性事件就能夠避免。按照社會關注程度、數(shù)據(jù)量大小和具體實施難度，數(shù)據(jù)開放建議分為三個階段：“業(yè)務統(tǒng)計數(shù)據(jù)”、“少量高頻數(shù)據(jù)”、“重點業(yè)務數(shù)據(jù)”。通過以安全為前提，重點關注優(yōu)先試點，逐步擴大范圍為原則，穩(wěn)步推行數(shù)據(jù)服務開放。12
 **政務大數(shù)據(jù)交換共享平臺建設方案 數(shù)據(jù)融合政務大數(shù)據(jù)歸根結底，還是要面向行業(yè)應用的，需要基于不同的業(yè)務部門開展，并和現(xiàn)有平臺建立聯(lián)系。融合應用可以分為“數(shù)據(jù)融合”、“業(yè)務融合”、“產(chǎn)業(yè)融合”三個層次：其中，數(shù)據(jù)融合是把本單位數(shù)據(jù)、從其他單位共享的數(shù)據(jù)，以及互聯(lián)網(wǎng)等社會相關的數(shù)據(jù)，相互融合，相互比對，建立融合數(shù)據(jù)資源中心，統(tǒng)一數(shù)據(jù)標準和口徑。業(yè)務融合主要圍繞各行業(yè)的特定業(yè)務場景，比如交通出行、醫(yī)療保障、民生服務等領域，建設智慧應用，形成行業(yè)業(yè)務的決策分析體系，支撐城市運行和城市治理的方方面面。產(chǎn)業(yè)融合，隨著一大批大數(shù)據(jù)處理、大數(shù)據(jù)分析、大數(shù)據(jù)運營企業(yè)的興起，政府數(shù)據(jù)將不單單是自建自用，通過建設數(shù)據(jù)運營平臺，數(shù)據(jù)交易平臺等形式，引入社會資本共同參與城市建設和社會治理，實現(xiàn)向集約型、服務型、智慧型政府的轉變。13
 **政務大數(shù)據(jù)交換共享平臺建設方案 業(yè)務流程開 始從 緩 沖 區(qū) 增 量 數(shù) 據(jù) 表 中 獲 取 人 口 增量 數(shù) 據(jù)根 據(jù) 證 件 類 型 判 斷 證 件 號 是否 符 合 規(guī) 范否通 過 證 件 號 判 斷 該 人 是 否 存在 于 人 口 主 表 中將 該 條 增 量 數(shù) 據(jù) 插 入 異 常 表 中否是將 人 口 庫 【 人 口 增 量 數(shù) 據(jù) 表 】中 該 人 口 記 錄 刪 除通 過 【 部 門 業(yè) 務 系 統(tǒng) 提 供 字 段 配 置表 】 得 到 該 業(yè) 務 系 統(tǒng) 需 采 集 的 字 段且 循 環(huán) 這 些 字 段判 斷 人 口 庫 該 字 段 值 的 來 源是 否 是 該 業(yè) 務 系 統(tǒng)將 該 人 口 記 錄 插 入 到 【 人 口 基礎 信 息 表 】 及 【 專 題 表 】是是否根 據(jù) 證 件 號 碼 和 類 型 更 新【 人 口 基 礎 信 息 表 】 及 【 專題 表 】 的 字 段否判 斷 新 采 集 的 字 段 值 是 否 為空否將 該 人 口 記 錄 字 段 來 源 插 入 到【 字 段 來 源 表 】判 斷 人 口 庫 庫 該 字 段 值 是 否為 空否否判 斷 該 業(yè) 務 系 統(tǒng) 的 數(shù) 據(jù)是是 否 是 業(yè) 務 上 的 新 增 ?否是根 據(jù) 證 件 號 碼 和 類 型 更 新 【 人 口 基礎 信 息 表 】 及 【 專 題 表 】 的 字 段 值是判 斷 該 業(yè) 務 系 統(tǒng) 是 否 為該 字 段 的 權 威 來 源更 新 【 字 段 來 源 表 】 中 該 字 段的 來 源循 環(huán) 人 口 庫 需 采 集 該 業(yè) 務 系統(tǒng) 的 字 段 是 否 結 束將 人 口 庫 【 人 口 增 量 數(shù) 據(jù) 表 】 中 該人 口 記 錄 刪 除結 束 業(yè)務量分析業(yè)務量分析可以從平臺交互量、每天總用戶數(shù)（個）、每天每個用戶平均執(zhí)行操作數(shù)、高峰時段交互量占全天交互量的百分比、高峰時段持續(xù)時間（小時）、高峰時段在線用戶數(shù)（個）等方面指標進行綜合估算。**互聯(lián)網(wǎng)大數(shù)據(jù)分析平臺的業(yè)務量估算如下表所示：表 31 業(yè)務量估算序號數(shù)據(jù)名稱平臺交互量數(shù)據(jù)量200（日均）100123每天總用戶數(shù)（個）每天每個用戶平均執(zhí)行操作數(shù)高峰時段交互量占全天交互量的百分比1000460%14
 **政務大數(shù)據(jù)交換共享平臺建設方案序號數(shù)據(jù)名稱數(shù)據(jù)量4（9：0011：00，15：0017：00）60（日均）56高峰時段持續(xù)時間（小時）高峰時段在線用戶數(shù)（個） 信息量分析和預測 存儲量分析本項目中存儲的數(shù)據(jù)主要包括兩大部分：系統(tǒng)網(wǎng)站群的在線行為數(shù)據(jù)和國內外互聯(lián)網(wǎng)重點渠道、信息源以及政府網(wǎng)站群的在線內容數(shù)據(jù)。在線用戶行為數(shù)據(jù)以符合 W3C格式標準的日志形式進行存儲。網(wǎng)站內容更新數(shù)據(jù)直接存到關系型數(shù)據(jù)庫或其他非關系型數(shù)據(jù)庫中。在線行為數(shù)據(jù)存儲量網(wǎng)站群的在線行為數(shù)據(jù)存儲主要分為三部分：（1）接收數(shù)據(jù)，是系統(tǒng)儲存的原始數(shù)據(jù)。（2）結構化數(shù)據(jù)，將原始數(shù)據(jù)進行數(shù)據(jù)清洗和去重后進行結構化后存儲。（3）分析數(shù)據(jù)庫，將結構化的數(shù)據(jù)進行分析預計算后存儲。按照本項目需要涵蓋**系統(tǒng)網(wǎng)站群的 500個網(wǎng)站，每個網(wǎng)站的日平均訪問按照 10000個 PV計算，預計每日需要處理的總的 PV數(shù)為 500萬。n 接收數(shù)據(jù)的測算依據(jù)及結論其中接收數(shù)據(jù)庫的主要條目占用空間，如下表所示：單個 PV所要儲存的信息空間大?。ㄗ止?jié)）訪問路徑信息160015
 **政務大數(shù)據(jù)交換共享平臺建設方案來源路徑信息1120其他信息（會話標識、Cookie標識、時間信息等）256匯總2976單個 Session所要儲存的信息(1個 Session大約產(chǎn)生 4PV）訪問路徑信息5121120128來源路徑信息客戶端信息（IP、瀏覽器等）其他信息（會話標識、Cookie標識、時間信息等）256匯總2016單個 Cookie所要儲存的信息(1個 Cookie大約產(chǎn)生)訪問路徑信息512256768其他信息（Cookie標識、時間信息等）匯總例如：按照其他同類項目的數(shù)據(jù)估算，PV和 Session數(shù)量比為 4：1，Session和 Cookie的數(shù)量比為 ：1。則 500萬的 PV會產(chǎn)生 125萬 的 Session 以 及 產(chǎn) 生 100 萬 的 Cookie， 總 占 據(jù) 空 間 為5000000*2976+1250000*2016+1000000*768=18G，包括索引以及其他表占用的空間之后，約為 20G。原始日志存儲到 SQL Server中會采用壓縮技術，大小將降為 5G。結論：對于接收數(shù)據(jù)庫，采用了壓縮和優(yōu)化技術后，每 500 萬PV 至少需要 25G 的儲存空間。n 結構化數(shù)據(jù)的測算依據(jù)及結論**系統(tǒng)政府網(wǎng)站群監(jiān)測分析調度系統(tǒng)的結構化數(shù)據(jù)庫和原始數(shù)據(jù)庫存儲的數(shù)據(jù)一致，但是經(jīng)過對原始數(shù)據(jù)庫的數(shù)據(jù)去冗余以及結構化，用外鍵壓縮了原來直接存儲在各表里的信息，大小會變?yōu)樵紨?shù)據(jù)的一半，也就是 。16
 **政務大數(shù)據(jù)交換共享平臺建設方案結論：對于結構化數(shù)據(jù)庫，采用了壓縮和優(yōu)化技術后，每 500萬 PV至少需要 。n 分析數(shù)據(jù)的測算依據(jù)及結論**系統(tǒng)政府網(wǎng)站群監(jiān)測分析調度系統(tǒng)的分析數(shù)據(jù)庫內容基本是結構化數(shù)據(jù)庫的拷貝，大小與結構化數(shù)據(jù)庫基本一致，也為 。結論：對于“決策支持系統(tǒng)”的分析數(shù)據(jù)庫，采用了壓縮和優(yōu)化技術后，每 500萬 PV至少需要 。綜上所述，在不做任何備份的情況下，每 500萬的 PV，需要文件存儲空間為：25GB + + =30G。到 2015年底的存儲量為 ，到 2019年底的存儲量為 ，具體測算如下表所示：接收日志明細匯總數(shù)據(jù)合計875G單月數(shù)據(jù)量(G)保留周期(月)25*30=750 *30= *30=60606060一年內需要存儲五年內需要存儲90004500075075037503750在線內容數(shù)據(jù)存儲量n 國內外互聯(lián)網(wǎng)重點渠道和信息源按照本項目需要面向國內外互聯(lián)網(wǎng)重點渠道和信息源進行在線內容采集爬取，按照覆蓋包括主流媒體在內的 200個信息源，每個信息源爬取 3級計算，平均每天可以爬取更新的總的頁面數(shù)約為 30萬 個 ， 每 個 頁 面 按 照 100KB 計 算 ， 共 需 要 占 用 的 空 間 為30W*1000KB=30G。17
 **政務大數(shù)據(jù)交換共享平臺建設方案到 2015年底的存儲量為 ，到 2019年底的存儲量為 54T，具體測算如下表所示：國內外互聯(lián)網(wǎng)重點渠道和信息源單月數(shù)據(jù)量(G)一年內需要存儲五年內需要存儲30萬*30=900G54Tn **級以上政府網(wǎng)站群**級以上政府網(wǎng)站群網(wǎng)站內容更新數(shù)據(jù)主要包括以下三部分：網(wǎng)站更新頁面、網(wǎng)站更新的入口，網(wǎng)站更新的白名單。按照本項目需要涵蓋**系統(tǒng)網(wǎng)站群及**各級政府網(wǎng)站群的6500個網(wǎng)站，平均每個網(wǎng)站每天更新 10個頁面，就是 。如果每天爬取 10次，就是 106500= 萬個入口，每個網(wǎng)站算 10個白名單，那就是 10650010=65 萬個白名單?？偣彩?++65萬=78萬，共需要占用的空間為 78萬頁*100KB/頁=78G。到 2015 年底的存儲量為 ，到 2019 年底的存儲量為，具體測算如下表所示：更新頁面數(shù)據(jù)*30=195網(wǎng)站入口數(shù)據(jù) 白名單數(shù)據(jù)合計單月數(shù)據(jù)量(G)一年內需要存儲五年內需要存儲*30=195 65*30=1950 2340G117T綜上所述，系統(tǒng)的數(shù)據(jù)存儲總量如下表所示：表 32 數(shù)據(jù)量估算表序號數(shù)據(jù)名稱初始量5年內的增量12在線行為數(shù)據(jù)54T互聯(lián)網(wǎng)重點渠道和信息源**團以上政府網(wǎng)站群3合計18
 **政務大數(shù)據(jù)交換共享平臺建設方案 處理量分析（1）網(wǎng)站群用戶訪問行為數(shù)據(jù)處理量分析以每天 725萬個客戶端訪問（包括 500萬 PV、100萬 Session、125萬 Cookie）并發(fā)計算，結合在線行為數(shù)據(jù)的接收主要集中在工作時間，7250000/8小時/60分鐘/60秒=251個/秒，日志接收服務器接受每秒鐘接收日志請求 251個，遠遠低于系統(tǒng)的每秒接收到的正常數(shù)（該值通常為 70009000）。根據(jù)日志接收每秒鐘的并發(fā)量為 251，因此系統(tǒng)的數(shù)據(jù)接收只需要再用兩臺服務器做負載均衡即可。但是為了防止數(shù)據(jù)接收網(wǎng)站的域名出現(xiàn)單點故障，因此系統(tǒng)的數(shù)據(jù)接收采用雙域名備份，即每個域名對應兩臺數(shù)據(jù)接收服務器，一共四臺。根據(jù)系統(tǒng)需要滿足**政府網(wǎng)站智能分析系統(tǒng)診斷的需要，目前系統(tǒng)的單臺服務器的數(shù)據(jù)處理能力為 400家左右，因此需要 4臺數(shù)據(jù)庫服務器，另外需要兩臺相同配置的數(shù)據(jù)庫服務器作為備份。（2）其他在線內容數(shù)據(jù)處理量分析一是系統(tǒng)需要支持對不少于 108萬個數(shù)據(jù)采集點每天至少一次輪詢抓取，同時對抓取回的數(shù)據(jù)進行數(shù)據(jù)預處理和清洗入庫工作，二是需要實現(xiàn)對存量數(shù)據(jù)和增量數(shù)據(jù)的指標自動抽取和更新工作，三是需要支持前臺交互系統(tǒng)的交互分析挖掘需求。結合以上幾部分需求，預計所需的內容數(shù)據(jù)處理服務器約 50臺。其中較高性能處理服務器（單機 20 核服務器 CPU:2660*2MEM:144G DISK:SSD 480G*2+SAS 4T*6，萬兆網(wǎng)卡，遠程管理，雙電19
 **政務大數(shù)據(jù)交換共享平臺建設方案源）10 臺，中等性能處理服務器（單機 12 核服務器,CPU:2620*2MEM:32G DISK:4T*10，萬兆網(wǎng)卡，遠程管理，雙電源）10臺。較低性能服務器（單機 12 核服務器,CPU:2620*2 MEM:72G DISK:SSD480G*2+SAS 600G*4，萬兆網(wǎng)卡，遠程管理，雙電源）30臺。 網(wǎng)絡流量分析按每天處理 725萬在線行為數(shù)據(jù)，每條數(shù)據(jù)為 10KB大小，108萬條在線內容數(shù)據(jù)，每條 100KB計算，需要的平均帶寬為 17Mbps，高峰時期按 3倍帶寬需求計算為：51Mbps，GE鏈路接入可以滿足需求，出于冗余考慮，