雄關(guān)漫道真如鐵，而今邁步從頭越

高校數(shù)據(jù)治理是一項長期而龐雜的工程，早期由于建設(shè)經(jīng)驗不足，大家普遍經(jīng)歷了共享數(shù)據(jù)庫、主數(shù)據(jù)平臺、大數(shù)據(jù)平臺等“邊走邊建”的過程，因為建設(shè)年代不同、承建廠商不同、數(shù)據(jù)庫類型不同、代碼標準不一造成了數(shù)據(jù)治理“看似全、實則亂”的局面。

“數(shù)據(jù)中臺”因其高度規(guī)范集約的特性大火之后，很多高校便面臨了新的選擇困境：數(shù)據(jù)中臺要不要遷移升級？怎么遷移？

對于“要不要升級”這個問題，無論是使用我們2.0、3.0產(chǎn)品的老朋友，還是正在觀望4.0的新朋友，迪小數(shù)都可以說一句：“放心升！大膽升！”。為啥這么有底氣呢？不妨看看下面幾條理由：

1. 底層架構(gòu)足夠健壯：迪塔維數(shù)據(jù)中臺4.0采用的是成熟穩(wěn)定的分布式數(shù)據(jù)存儲與計算技術(shù)，可彈性擴展、平滑升級。搭載自研的批流一體數(shù)據(jù)集成引擎，實現(xiàn)海量異構(gòu)數(shù)據(jù)源的實時入湖、秒級計算，同時兼容國產(chǎn)數(shù)據(jù)庫、操作系統(tǒng)。在系統(tǒng)性能、計算效率、自主可控、實時性等方面都有質(zhì)的提升，能為學(xué)校構(gòu)建足夠強大健壯的數(shù)據(jù)底座。

2. 治理流程足夠規(guī)范：“知行合一”，我們將歷練多年的高校數(shù)據(jù)治理方法論全部融入到了4.0產(chǎn)品中；“芥子納須彌”，同時將分散的產(chǎn)品進行高度整合，統(tǒng)一收歸，并緊跟政策導(dǎo)向不斷迭代。我們可以按照中臺內(nèi)置的方法論流程進行引導(dǎo)式操作，從數(shù)據(jù)源連接、數(shù)據(jù)識別、數(shù)據(jù)湖集成、標準層集成最后到應(yīng)用層建設(shè)，每一步都有清晰的指引和KPI指標展示，讓數(shù)據(jù)治理工作更加規(guī)范透明。

3. 治理效果足夠可見：4.0產(chǎn)品的開發(fā)是從用戶視角出發(fā)，以引導(dǎo)式和低代碼思路進行界面功能的設(shè)計，多為選擇性、拖拽化操作，且加入智能輔助化工具，如自動識別、自動映射、智能sql轉(zhuǎn)換等，真正降低使用門檻。同時治理成效更可見，有建設(shè)進度看板、數(shù)據(jù)血緣流向、集成任務(wù)監(jiān)控、問題質(zhì)量報告、數(shù)據(jù)資源門戶等多種渠道展示治理成效，讓數(shù)據(jù)治理工作不再是“黑盒”。

4. 升級風險足夠可控：目前4.0是公司拳頭產(chǎn)品，技術(shù)投入有保障，且在開發(fā)時便規(guī)劃了適應(yīng)升級的相關(guān)功能模塊，3.0升級到4.0幾乎無風險。如果是從其他廠商產(chǎn)品遷移，主要風險接口遷移的適配和數(shù)據(jù)庫語法的兼容也均有完善的智能工具支持和技術(shù)解決方案，API接口遷移可做到第三方應(yīng)用零調(diào)整、無感知。另外，數(shù)據(jù)中臺升級是接口和腳本的遷移，不是重復(fù)建設(shè)，實施成本有但相比升級帶來的優(yōu)勢，迪小數(shù)相信是值得投入的。

對于第二個問題“怎么遷移”，涉及的內(nèi)容就比較多了，待我們細細道來。

數(shù)據(jù)中臺的遷移涉及到大量的數(shù)據(jù)遷移、系統(tǒng)重建和調(diào)整，通常包含平臺工具、標準層及數(shù)據(jù)遷移工作。為保證不影響學(xué)校業(yè)務(wù)的正常運行，新舊系統(tǒng)的切換需要在最短的時間內(nèi)完成，且應(yīng)用不能中斷，并要做好超時未完成的倒退方案。無論對信息辦的統(tǒng)籌協(xié)調(diào)能力，還是中臺產(chǎn)品的穩(wěn)定性、實施人員操作的規(guī)范性都是一項考驗。

下面我們就以迪塔維數(shù)據(jù)中臺4.0的升級遷移為例，從實施的角度介紹數(shù)據(jù)中臺遷移的方法和注意事項。

遷移前的準備工作

1、計劃：詳細分析學(xué)校數(shù)據(jù)中臺的設(shè)備、軟件、數(shù)據(jù)等情況，制定遷移計劃。重點關(guān)注遷移成本、網(wǎng)絡(luò)連接、臨時平臺和人員配備問題。

2、資源：準備好數(shù)據(jù)湖、批流一體數(shù)據(jù)集成引擎、數(shù)據(jù)中臺及按需集成工具所需的服務(wù)器資源（資源要求可詳詢項目經(jīng)理）。

3、驗證：對服務(wù)器資源配置、網(wǎng)絡(luò)環(huán)境、對時信息等進行檢測驗證，確保環(huán)境符合平臺部署要求。

4、部署：完成迪塔維數(shù)據(jù)中臺4.0、集成工具、批流一體引擎、分布式數(shù)據(jù)庫的部署工作，并對照《系統(tǒng)信息驗證自檢表》進行功能性驗證（由實施人員完成）。

數(shù)據(jù)中臺的遷移需要完成數(shù)據(jù)湖集成、標準層遷移、下行接口遷移、質(zhì)量規(guī)則遷移、API接口遷移幾項工作。因篇幅限制，本文首先介紹數(shù)據(jù)湖集成的操作，后續(xù)步驟將在下篇進行詳細說明。

數(shù)據(jù)湖集成是將原本數(shù)據(jù)源->標準層的數(shù)據(jù)集成方式轉(zhuǎn)換為數(shù)據(jù)源->數(shù)據(jù)湖->標準層的方式，調(diào)整策略，保障數(shù)據(jù)實時入湖。具體步驟如下：

◆ 確認需要入湖的業(yè)務(wù)系統(tǒng)信息

◆ 入湖的業(yè)務(wù)系統(tǒng)連接信息梳理

◆ 業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫連接測試

◆ 確定入湖方式

入湖的方式分為實時入湖和T+1周期調(diào)度，需提前確認需實時入湖的系統(tǒng)、表及周期調(diào)度的頻率。

◆ 數(shù)據(jù)庫開啟日志權(quán)限

對于需要實時入湖的業(yè)務(wù)系統(tǒng)，需開啟日志權(quán)限并進行驗證測試。

◆ 各業(yè)務(wù)系統(tǒng)入湖表范圍的確認

非必要入湖的表會占用一定的服務(wù)器資源和性能，也加大了后期的管理維護成本，因此需提前確認需要入湖的表級別范圍，若后續(xù)有需要仍可進行新增表入湖。

◆ 數(shù)據(jù)模型反向

根據(jù)已確認的入湖范圍，在迪塔維數(shù)據(jù)中臺4.0上進行業(yè)務(wù)數(shù)據(jù)庫模型的導(dǎo)入，并完成資源信息的識別。

數(shù)據(jù)庫模型獲取方式推薦：【自動反向】+【批量導(dǎo)入】≥【資源識別】

◆ 模型主鍵設(shè)置

對已反向的模型進行主鍵設(shè)置，若沒有物理主鍵，但可以組合出聯(lián)合主鍵的，可在模型中勾選多個字段設(shè)置成邏輯主鍵。

◆ 無主鍵數(shù)據(jù)表入湖

對于無物理主鍵及邏輯主鍵的表，需采用集成工具（或通用集成方式）進行全量數(shù)據(jù)的入湖抽取，通用集成支持低頻調(diào)度的方式進行任務(wù)調(diào)度設(shè)置。

◆ 入湖調(diào)度任務(wù)設(shè)置

根據(jù)現(xiàn)場實際情況，對有物理主鍵或邏輯主鍵的表進行不同的任務(wù)設(shè)置。

l 實時流

確認業(yè)務(wù)源頭數(shù)據(jù)庫開啟歸檔日志且數(shù)據(jù)庫表具備主鍵屬性的，可選用實時流方式。實時流提供三種更新策略，可根據(jù)現(xiàn)場數(shù)據(jù)情況進行選擇。

l 批處理

根據(jù)調(diào)度周期分為高頻輪詢和低頻調(diào)度兩種。對有實時性要求，但是源頭不具備開啟數(shù)據(jù)庫日志條件，但具備自增字段或時間戳字段的，可采用高頻輪詢的方式創(chuàng)建集成任務(wù)。

l 低頻調(diào)度

傳統(tǒng)的“T+1”調(diào)度方式，調(diào)度周期最小顆粒度可以到分鐘。

◆ 任務(wù)執(zhí)行狀態(tài)監(jiān)控

關(guān)注入湖任務(wù)的執(zhí)行狀態(tài)，對執(zhí)行失敗的任務(wù)進行日志查看與分析，確保入湖任務(wù)的正常運行。

◆ 代碼數(shù)據(jù)入湖

代碼表入湖與數(shù)據(jù)入湖操作類似，需要注意的是業(yè)務(wù)源在進行模型反向時分為數(shù)據(jù)表和代碼表，反向后需區(qū)分出數(shù)據(jù)表和代碼表，如下圖所示，調(diào)整平臺中模型的數(shù)據(jù)類別為：代碼表，后續(xù)操作可參考上文數(shù)據(jù)入湖的操作流程。