數據中心Web系統非結構化數據治理策略及措施

杜小丹， 吳成賓， 王惟潔，2， 何 源， 劉新躍， 羅德彪

（1． 成都大學信息網絡中心，成都610106；2． 成都理工大學地球物理學院，成都610059）

0 引 言

隨著科技的發展、競爭的加劇，以及進一步提高服務意識、服務質量的需求，許多組織機構需要對多年來信息化建設過程中積累和沉淀下來的最重要的資產之一，即數據資產進行統一治理和深度挖掘，以期獲得更好的收益。因此，近年來數據中心［1］的建設始終是一項重要的工作，智慧型數據中心建設的核心理念是數據治理［2-3］，數據治理包括數據的標準化、數據整合、數據集成、數據分析、數據質量分析、數據共享融合等諸多方面［4-7］。數據治理是一個漫長的過程，需要循序漸進地分步推進，才有可能建成一個良好的數據生態圈［8］。從目前的情況來看，對業務流程系統的數據治理相對比較重視，而對Web系統的數據治理則不夠重視。數據中心數據治理的目標是建成個人Web 數據中心平臺，形成個性化的數據微服務，不斷完善數據治理生態建設，建成數據治理免疫系統，全面保障數據資產，建成大數據智慧分析決策系統，為領導決策提供有力支撐。

1 Web系統數據存在的問題分析

MySQL［9］由于集開源、免費、使用方便以及高可靠性等諸多優點于一身而被廣泛使用，據第三方權威評測機構DB-Engines 提供的數據表明，近20 年來，MySQL一直雄踞全球Web數據庫市場占有率首位，但一些較早期設計的基于MySQL 的Web 系統往往對各種結構化和非結構化數據［10-11］沒有實行有效管控，隨著并發訪問量越來越大，系統性能下滑顯著，原因主要在于：①Web服務器上除了部署、運行程序文件之外，許多上傳的各種附件雖然其URL 信息保存在數據庫中，但是URL對應的實際的文件卻存放在Web 服務器上，導致其負載過重；②數據庫服務器本身負載也過重，部分Web 系統把包括文本、圖像、音頻、視頻等幾乎所有類型的結構化和非結構化數據都存入數據庫，而這類數據量往往較大，傳輸時非常耗費帶寬，如果數據庫和Web服務器不在同一臺服務器上，那么為了獲取一幅圖像（或者音視頻等），客戶端需要從Web服務器取數據，Web 端又需要從數據庫端獲取，這樣會同時在數據庫端和Web 端兩處I／ O 上都形成訪問瓶頸。進一步的分析發現，部分早期設計的不規范的Web系統中，通過Web頁面上傳的圖像、音頻、視頻等二進制非結構化數據文件，在數據庫中常以base64［12］編碼形式保存，且可能與結構化文本等信息混合存放在同一個字段中，因此需要設計算法來剝離以base64編碼形式保存的非結構化數據。base64 是互聯網上最常見的用于傳輸8 bit數據的編碼方式之一，通常用于把二進制數據編碼為可見的字符形式的數據，這是一種可逆的編碼方式。base64 編碼將每3 bit變成4 bit，因此編碼后長度增加1 ／ 3。編碼后的數據是一個字符串，其中包含的字符為：A-Z、a-z、0-9、+、／共64 種字符，規定將“＝”作為填充字符，因此base64 編碼實際上由65 種字符組成。

2 Web系統數據治理策略及措施

Web系統數據治理的主要策略是將非結構化數據從數據庫服務器和Web 服務器剝離出來單獨存放在不同的服務器上，治理的直接結果是減少帶寬占用，消除I／ O瓶頸，提高響應速度，并為下一步提升Web數據的標準化水平、提升數據質量和共享融合水平奠定基礎。為此需從兩個方面同時給Web 服務器和數據庫服務器減負：①將各種上傳的附件文件（包括普通文件，圖像、音頻、視頻等文件，其URL 鏈接信息保存在數據庫中）從Web服務器剝離出來，② 將數據庫中以base64 編碼保存的各種圖像、音視頻等非結構化數據從數據庫中剝離出來。剝離出來的各種非結構化的數據文件全部轉儲到單獨的文件、圖像、音頻、視頻服務器上，達到既減負又分流非結構化數據的目的。數據治理具體措施主要包括如下幾個處理步驟：初始化；非結構化數據識別、提取、剝離；剝離了非結構化數據后剩下的結構化數據回寫數據庫；最后將剝離出來的非結構化數據文件遷移到單獨的各類服務器上。

2.1 初始化

分別配置圖像、音頻、視頻、文件服務器，假設其根路徑分別為image，audio，video，file，分配相應的IP地址和域名，假設根域名為example． com，則圖像、音頻、視頻、文件服務器的域名可分別設置為image．example． com，audio． example． com， video． example．com，file． example． com。在運行本文提出的策略措施算法的計算機（以下簡稱為A 機）上創建目錄image，audio，video，file，分別用于暫時存儲剝離出來的圖像、音頻、視頻及普通文件。

2.2 非結構化數據識別、提取、剝離流程

對數據庫中存在非結構化數據的每個表執行base64 編碼以及URL鏈接信息數據掃描、識別、提取、剝離操作，直到整個數據庫處理完畢。假設某個表名為newsdata，其含有newsid，postdate，content 3 個字段，其中content字段混合存儲了結構化的文本數據、以base64 編碼的非結構化的圖像、音頻、視頻等數據，以及URL鏈接信息數據。從content 字段中掃描、識別、提取、剝離非結構化數據的主要流程為：

①A機連接數據庫，構建查詢語句：sql ＝＂ select newsid，postdate，content from newsdata where content！＝NULL ＂，執行該sql語句，將返回的表查詢結果集保存在結果集變量rs中，轉②。

②從結果集rs中讀取一條記錄，檢測是否讀到結果集尾，若是，轉⑧；若否，將當前記錄的newsid，postdate，content字段內容分別賦予全局變量newsid ，postdate，content，全局變量bChanged 賦初值FALSE，轉③。

③ 執行普通文件URL 識別、提取、剝離模塊，轉④。

④執行圖像文件base64 編碼及URL識別、提取、剝離模塊，轉⑤。

⑤執行視頻文件base64 編碼及URL識別、提取、剝離模塊，轉⑥。

⑥執行音頻文件base64 編碼及URL識別、提取、剝離模塊，轉⑦。

⑦執行剝離了非結構化數據后剩下的結構化數據回寫數據庫模塊，轉②。

⑧關閉結果集，關閉數據庫連接。

（1）普通文件URL識別、提取、剝離模塊流程

① 初始化int 型局部變量iPosH ＝iPosT ＝iCount＝0，轉②。

②以iPosT 為起始位置，掃描content 中有無“＜a”特征串［13］，將掃描到的特征串起始位置賦予iPosH，檢測“iPosH ＜ ＝ - 1”，若是，表明沒有掃描到該特征串，轉④；否則，以iPosH 為起始位置，掃描content中有無“＞”特征串，將掃描到的特征串起始位置賦予iPosT，檢測“iPosT ＜ ＝ - 1”，若是，轉④；否則，檢測“iPosT ＞iPosH”，若是，轉③，否則轉④。

③以iPosH為起始位置，掃描content中有無“href＝”特征串，若有，判斷“href ＝”后面引號中指明的文件鏈接URL是否為相對路徑，若否，說明該文件沒有存放在正被處理的Web 服務器上，無需剝離，更新下一次掃描的起始點位置為：iPosT ＝iPosH + 1，轉②；若是，從postdate串中提取出“年月”，根據“年月”在A機上的file 目錄下創建路徑，從URL中提取出文件名稱，并將文件按以下規則重新命名：文件名+ iCount．后綴名，拷貝URL 文件到A 機相應路徑下，修改content 串，將原來的URL 替換為“http：／ ／ file．example． com／路徑／新文件名”，然后刪除原來的URL文件，修改變量bChanged ＝TRUE，iCount + +，更新下一次掃描的起始位置：iPosT ＝iPosH + 1，轉②。

④本模塊處理完畢，轉下一模塊。

（2）圖像文件base64 編碼及URL 識別、提取、剝離模塊流程

① 初始化int 型局部變量iPosH ＝iPosT ＝iCount＝0，轉②。

②以iPosT為起始位置，掃描content 中有無“＜img ”特征串，將掃描到的特征串起始位置賦予iPosH，檢測“iPosH ＜ ＝ - 1”，若是，轉⑤；否則，以iPosH 為起始位置，掃描content中有無“＞”特征串，將掃描到的特征串起始位置賦予iPosT，檢測“iPosT ＜＝ - 1”，若是，轉⑤；否則，檢測“iPosT ＞ iPosH”，若是，轉③，否則轉⑤。

③ 以iPosH 為起始位置，掃描content 中有無“data：image ／”［14］特征串，將掃描到的特征串起始位置賦予iPicPosH，檢測“iPicPosH ＜ ＝ - 1”，若是，轉④；否則，以iPosH 為起始位置，掃描content 中有無“；base64，”特征串，將掃描到的特征串起始位置賦予iPicPosT，取得圖像類型：iPosHOff ＝length（＂ data：image ／＂ ），

ImgType ＝substr（content，iPicPosH + iPosHOff ，iPicPosT-iPicPosH-iPosHOff）。

這里iPosHOff 為圖像base64 編碼特征串（即“data：image ／”）長度，ImgType 為取得的圖像類型（如PNG，JPG 等），substr 為取子串函數，第1 個參數content為被取串，第2 個參數表示從被取串讀取的偏移量，第3 個參數為預截取的子串長度。

以iPicPosH為起始位置，掃描content 中有無“，”特征串，將掃描到的特征串起始位置賦予iPosComma，檢測“iPosComma ＜ ＝ - 1”，若是，更新下一次掃描的起始位置：iPosT ＝iPosH + 1，轉②。

為即將提取出的圖像文件按照如下規則命名：年月+ iCount． ImgType，然后指定文件的URL 地址為“http：／ ／ image． example． com／路徑／文件名”。

提取圖像文件base64 編碼數據：img ＝substr（content，iPosComma + 1，iPosT-iPosComma-1）。

上傳的圖像極有可能由于各種原因，致使其base64編碼被修改，使得提取出的img 不能還原成圖像文件，故需對img進行如下處理：去掉img 尾部單引號和／或雙引號及其后的所有數據；去掉img尾部的空格；將img非尾部的空格全部替換成“+”，這樣即可按照base64編碼規則將img還原成二進制的圖像文件。

還原的圖像文件暫存在A 機的image 目錄下，修改content串，將掃描到的圖像base64 編碼（即位于iPosH和iPosT之間的所有子串，含頭尾）替換為類似如下“http：／ ／ image． example． com／路徑／文件名”的URL ，修改變量bChanged ＝TRUE，iCount + +，更新下一次掃描的起始位置：iPosT ＝iPosH + iPosHOff ，轉②。

④以iPosH為起始位置，掃描content中有無“src＝”特征串，若有，判斷“src ＝”后面引號中指明的文件鏈接URL是否為相對路徑，若否，說明該文件沒有存放在正被處理的Web 服務器上，無需剝離，更新下一次掃描的起始位置：iPosT ＝ iPosH + 1，轉②；若是，則從postdate串中提取出“年月”，根據“年月”在A機上的image 目錄下創建路徑，從URL中提取出文件名稱，并將文件按以下規則更名為新文件：文件名+iCount．后綴名，拷貝URL文件到A 機相應路徑下，修改content 串，將原來的URL 替換為“http：／ ／ image．example． com／路徑／新文件名”，然后刪除原來的URL文件，修改變量bChanged ＝TRUE，iCount + +，更新下一次掃描的起始位置：iPosT ＝iPosH + 1，轉②。

⑤本模塊處理完畢，轉下一模塊。

接下來的視頻、音頻文件base64 編碼及URL 識別、提取、剝離模塊算法流程與圖像文件base64 編碼及URL識別、提取、剝離模塊算法流程類似，只是特征碼不一樣而已，不再贅述。

2.3 剝離了非結構化數據后剩下的結構化數據回寫數據庫模塊流程

檢測標志變量bChanged是否為TRUE，若是，說明該條記錄被修改了，需要重新回寫到數據庫中，構建SQL語句：

sql ＝ ＂ update newsdata set content ＝content where newsid ＝newsid＂；

execute（sql）；／ ／執行SQL回寫命令

2.4 剝離出來的非結構化數據文件遷移到單獨的各類服務器

將剝離出來的暫存在A 機上file、image、video、audio目錄下的所有非結構化數據文件分別轉儲到文件、圖像、音頻、視頻服務器上，這樣就完成了非結構化數據文件的遷移。

3 結 語

Web系統非結構化數據經過數據治理后獲得的新的扁平化的Web系統架構如圖1 所示，最終用戶訪問新Web系統時，如果要獲取圖像、音頻、視頻或者其他普通文件等非結構化數據，僅需訪問Web服務器和數據庫服務器各一次，取得URL 信息后，客戶端直接從相應的服務器去獲取實際的數據文件，不會給Web

服務器或數據庫服務器帶來多次訪問的壓力，消除了訪問瓶頸，提高了系統響應速度。扁平化的Web系統結構非常易于橫向擴展而無需對程序軟件做任何修改，保護了用戶投資的同時，也縮短了規模化部署周期。此外，新系統也可以很方便地部署負載均衡設備、CDN（Content Delivery Network，內容分發網絡）設備、以及實施靜態化頁面等Web 系統優化措施［15］，這些為下一步提升Web數據的標準化水平、提升數據質量和共享融合水平奠定了堅實的基礎，從而為最終邁向良好的數據中心數據生態圈提供了先決條件。

圖1 數據治理后的扁平化Web系統架構