編者按

踏上一帶一路的新絲路，北京百分點資訊科技有限公司從2016年開拓海外業務，以大資料技術為基礎，結合中國先進的資料治國理念，用資料智慧推動社會進步。三年時間，百分點海外團隊在非洲某國實施大資料專案並取得階段性驗收，在提升客戶資料治理能力的同時，結合百分點國內大資料專案優秀實踐，積累了一套大資料專案實施的5大體系+20道工序的理論方法。

一、專案思路

在國內，大資料應用已經深入各個行業，不管是業務人員或是技術人員，對於大資料的技術優勢以及在業務中發揮的重要作用都非常瞭解。同時，各個行業發展迅猛，行業業務專家層出不窮。在專案中，客戶方有業務專家和技術專家把關業務痛點、業務需求，與承建方的業務、技術專家一同參與系統建設，保證系統的順利落地。

但在較為落後的第三世界國家，對於業務的瞭解處在矇昧階段，很難有比較清晰明確的業務需求，同時對於基本的IT技術掌握程度較低，大資料更是聞所未聞，對於中方提供的技術方案，很難理解其中的優勢以及能夠帶來的價值。

所以在專案建設過程中，我們需要將國內先進的管理思路傳導給客戶，簡明扼要地展示技術優勢，同時配合成熟的系統建設方法，主導從需求到系統運營的系統全週期建設，建立高效執行並且能持續運營的系統，利用資料智慧幫助客戶提升業務和管理能力。

總結來說，如何快速確定底層資料情況，幫助系統設計人員確定系統功能邊界，如何高效地進行資料接入，如何設計合理的資料模型支援上層應用，如何保證資料安全，如何持續運營以發揮資料價值，都是資料中臺建設的重中之重。

二、專案實施

1. 整體方案

整個專案依照百分點資料專案建設流程進行，主要包括：資料接入、資料治理、資料開發、資料資產和資料服務5大體系和20道工序，保證從資料接入到資料服務的完整流程落地。

2. 需求調研

在系統建設初期的需求調研階段，數倉工程師需要承擔的任務，主要有業務系統調研和業務資料分析，基於業務確定系統應用需求範圍之後，設計資料需求。

2.1 業務系統調研

在業務系統調研過程中，由於客戶技術能力所限，很難將系統的業務流程和資料解釋清楚，所以我們主要採用調研問卷、E-R圖和資料字典等方式進行系統分析。

（1）調研問卷

調研問卷主要幫助我們瞭解系統概況，主要包括：

• 是否有電子化系統
• 系統是B/S還是C/S架構
• 業務系統主要功能
• 與中心機房的網路情況
• 系統資料的儲存方式
• 增、全量資料量
• 是否有備份庫
• 可以用何種方式提供資料

有了以上資訊，我們能夠對所需接入資料有個基本的瞭解，判斷資料接入可行性以及所需的軟硬體條件。

（2） E-R圖

E-R圖主要幫助我們在客戶技術人員無法說明系統業務邏輯的情況下，瞭解系統的業務流程，透過表與表之間的主外來鍵關係，結合對國內相關業務的瞭解，推測業務資料流向，從而作為之後模型設計的輸入。

（3）資料字典

資料字典是業務調研過程中最重要的資料，有了資料字典之後，我們才能進行下一步的業務資料分析工作。在收集資料字典的過程中，我們會盡量與客戶的測試環境進行比對，確保拿到的資料字典是最新版本，避免因為版本更新問題，影響系統功能設計和資料接入流程的開發。

2.2 業務資料分析

業務資料分析主要包含兩個部分：

（1）資料項分析

資料項分析基於客戶提供的資料字典，對業務核心屬性進行確認，確保上層業務功能有相應的資料可以支撐

（2）資料質量分析

資料質量分析，基於客戶提供的測試或脫敏資料，對關鍵屬性進行空值、規則等判斷，確保資料本身具有實際的業務意義，以便之後的業務分析。

2.3 資料需求設計

對於整體系統的功能，我們從系統的兩端入手：首先參考國內優秀的建設方案和思路，基於當地實際業務情況，規劃系統可能的整體功能；同時調研可接入系統的業務資料和業務流程，對整體功能進行裁剪和補充，形成符合當地的需求藍圖。

確定系統功能之後，我們將系統功能對應的資料應用需求分為以下幾類：

（1）報表展現類

主要以維度和指標為主，利用報表或者大屏做業務指標分析或宏觀態勢監控。

（2）人物事件分析類

主要以“物件-關係”方式進行實體、事件、文件及相互關係、以及時間、空間的分析。

（3）資料比對類

主要以多資料集比對為主，發現不同資料集之間的相互匹配的資料。

（4）網路資訊分析類

主要以網際網路爬取資訊為主，透過文字分析服務，發現熱點事件，熱點話題，熱點人物等資訊。

（5）資料共享類

主要以各部門之間資料交換共享為主，保證資料共享過程中的穩定和安全。

按照以上不同的資料應用需求，結合百分點自有的產品以及使用的大資料開源元件，我們構建了資料中臺的5大資訊庫：

（1）專題業務庫（MySQL）

以基於維度的指標彙總，按照不同業務專題構建的分析庫，方便高分大屏和CBI（百分點智慧BI）系統進行報表展示。

（2）動態本體庫（ES+Neo4j）

利用百分點 DEEP FINDER產品，構建知識圖譜，以API方式為上層應用提供物件-關係分析，從繁雜的圖譜中發現類似的行為模式以及關鍵資訊。

（3）比對資源庫（PostgreSQL）

利用比對分析系統，構建常用的基礎比對資源資料，與各個部門提供的資料進行視覺化比對，發現匹配的物件，進行進一步分析。

（4）網路資訊庫（ES）

網路爬取的資料，透過流式資料處理，匯入以ES為儲存的網路資訊庫，利用規則、文字分析，情感分析等分析方法，發現熱點事件、熱點話題和資訊傳播關鍵節點，進行後續處理。

（5）共享資源庫（MySQL）

利用百分點資料共享交換平臺，構建資料資源，對外提供安全、清晰的資料資源目錄，同時提供檔案、資料庫、API等多種對接方式進行內外部資料交換。

3. 專案設計

3.1 框架思路

完成了資訊庫的設計，下一步就是建模、資料整合處理、排程以及監控，上述任務均在大資料平臺（BD-OS）中完成。BD-OS作為基於大資料開源元件的一站式資料處理平臺，提供了資料接入、資料建模、ETL開發、流式開發、資料排程、資料監控、資料治理等模組，滿足資料處理全鏈路的所需功能。

我們採用了流批一體的經典Lambda架構，分別處理實時接入的網路資料和批次接入的業務資料；同時，我們採用分層設計，將資料倉儲層分為：STG層、ODS層和DW層，保證每一層清晰的資料處理邏輯。整體資料流圖如下：

部分整體分為三層：

（1）資料來源層

• 按資料來源分：包括爬蟲抓取的網路資料，內網環境業務系統資料，以及外網環境業務系統資料。
• 按資料格式：分為資料庫和檔案。
• 按資料傳輸頻率：分為流式和批次（T+1）傳輸。

（2）資料接入層

• 流式資料的接入：我們主要利用Kafka作為儲存媒介，透過Spark Streaming進行資料處理，流式作業可以以jar包的形式透過BD-OS上傳伺服器，從而實時監控程式的執行情況。
• 批次資料接入：對於內網資料，我們直接使用BD-OS的資料匯入功能進行接入；對於外網資料，考慮到系統資料交換的功能以及對外資料鏈路的安全性，我們使用資料共享交換平臺進行資料的匯入。
• 多媒體資料接入：對於影片或圖片等多媒體資料，我們使用OSS（物件儲存）來進行管理。物件儲存中包含兩種儲存元件：Hbase和Ceph。根據兩者儲存特性的不同，我們首先判斷多媒體檔案的大小，對於1M內的小檔案，存入Hbase；超過1M的大檔案，儲存至Ceph，對外透過統一的API進行訪問，透過檔案的key來呼叫，提升多媒體檔案的儲存和讀取效率。

（3）資料層

STG：用來接收檔案形式的源頭資料並臨時存放。該部分的資料檔案，除了業務系統批次匯出的資料，還包含流式處理中需要進行批次統計的資料。

ODS：以Hive表形式來存放源頭資料。ODS作為資料中臺主體部分的最底層，儲存包含存放在STG層（臨時資料存放層）的檔案資料，以及透過sqoop同步資料庫資料。當資料入表之後，數倉工程師就可以方便地使用SQL進行資料處理，降低門檻。

DW：根據不同的資料應用，我們採用了不同的建模方式，在DW層中建立了三類模型，資料均儲存在Hive中。選擇Hive的原因，一是方便傳統數倉工程師使用SQL和UDF進行資料處理；二是批次資料處理要求的時效性不高但資料量大，Hive的特性可以滿足需求。

• DW-CSM：標準化模型，採用正規化建模，將底層資料按照參與人、地址 、事件、物品、組織、關係六大主題域進行整合。這樣做的好處，一是將繁雜的源頭系統的資料做拆分組合，使得業務邏輯更加清晰；二是在拆分組合的過程中，進行標準化處理，保證資料中臺內部碼值和規則的統一，對外提供統一的資料標準；三是上層的動態本體，同樣是物件-關係的模式，底層資料拆分之後，可以方便地整合至本體中，無需在匯入本體過程中做額外的處理。在底層業務系統數量多，業務繁雜，同時需要不斷整合新系統的情況下，正規化建模能夠幫助資料人員理清業務關係，統一資料標準，經過不斷地業務沉澱，最終可以建立行業模型。在這個部分，我們將網路爬取資料單獨存放在ES中，方便之後的網路資訊庫應用，這部分資料直接一一對映，不做其他的處理。
• DW-CDM：維度模型，採用維度建模，按照上層的分析統計需求，建立維度表和事實表。為了提升查詢效率，我們使用標準的星型模型，同時由於Hive表關聯效率較低，我們在生成事實表時，對性別，年齡段等列舉值維度做了退化處理，即用碼值名稱代替code儲存在事實表中，避免在資料處理過程中需要關聯過多維度表導致處理效率低下，影響使用者體驗。該部分模型主要支援多維分析和大屏的資料應用。
• DW-CBM：業務資源模型，採用寬表建模，將關鍵資訊進行整理合併，形成屬性資訊完整的寬表，方便之後的資料比對和內外部資料共享。寬表的優點是查詢效率極高，一次查詢無需關聯；缺點是靈活性很差，不適應頻繁的表結構變更，對於比對和資料共享需求來說，所需的主要資訊變化很小，使用寬表，能夠大大提升比對和資料共享的效率。

另外，為了服務上層應用，我們單獨搭建了本體模型。

Ontology：本體模型，採用本體建模方式，構建物件-關係的本體模型，來反映真實世界。物件資訊主要儲存在ES中，而關係資訊主要存放於Neo4j。這樣既能支援全文檢索來發現物件的關鍵資訊，又可以透過圖的挖掘發現相同的行為模式，其中物件又可以分為：實體，事件，文件。

• 實體：業務主體：包括人，車，物理地點等等。
• 事件：由業務主體實施的行為，基於事件可以進行時間和空間的分析。
• 文件：文字類資訊，單獨將文件拆分出來的原因，是文件會有特殊的處理方式，比如文字分析，話題抽象，情感分析等等。

3.2 設計思路

3.2.1 批次部分

（1）資料接入

資料接入的兩種方案概述：

目前海外專案中批次資料接入主要有兩種方案。一種是使用BD-OS自帶的資料匯入功能，一種是使用資料共享平臺。這兩種方案均有各自的優缺點，可以根據不同的業務場景按需採用。

BD-OS自帶的資料匯入功能，實際上是整合了Hadoop生態的Sqoop元件。這種方式的優點在於Sqoop是將匯入命令翻譯成為MapReduce程式，與Hive整合較好，對匯入到指定的分割槽表具有較好的支援。缺點只支援匯入Hive或者是HDFS檔案，並且由於與BD-OS繫結，通常會部署在內網中。對於生產環境都會進行內外網隔離，導致使用此方案時無法接入外網資料資料。

資料共享平臺核心功能有兩點，一點是資源共享，主要在於提供資料服務（通常是API），另外一點就是資料交換，本部分內容重點討論資料交換這點。資料共享平臺的資料交換功能實際上是整合了阿里的開源離線資料同步工具DataX，它的優勢在於支援的資料來源豐富多樣，比如某個專案中不需要資料接入到Hive，而是直接接入到Phoenix，就可以使用資料共享交換系統的資料交換功能。另外相對於上一種方案，它相對比較輕量級，不需要部署整個大資料平臺BD-OS，因此通常也用於在生產環境上部署到DMZ網路區域中，用於接入外網資料。它的缺點就是在於目前DataX對於Hive分割槽表支援不太完善，僅僅支援一次匯入到一個分割槽表。

兩種方案詳細介紹：

我們先看一下BD-OS匯入功能的介面：

由上述選項可以看出BD-OS的匯入功能支援增量、全量匯入，支援編寫查詢SQL，可以選擇是否覆蓋，另外對於匯入的佇列、每次讀取資料條數等等有較為細節的控制。

再看一下資料共享交換的介面：

可以看出與BD-OS匯入功能對比，資料交換功能對於資料讀取條數等資源佔用控制相關沒有提供更為細節的控制。但是也提供了SQL支援，欄位對映設定、增量\全量同步、是否覆蓋、另外還提供了前置後置指令碼功能。

資料交換功能還提供了API用於其他ETL工具整合，呼叫API可以獲取到任務的執行狀態。

總結：

在資料匯入的增量\全量，是否覆蓋、支援SQL等常用的需求點上，BD-OS的資料匯入功能和資料共享平臺交換功能都提供了對應的支援，這兩種方案主要的區別還是在於體量級別以及其他的細節需求點上，實際專案中按需分別採用或者兩者都使用均可。

（2）資料治理

資料治理部分，主要包括：後設資料管理、資料標準管理、資料質量稽核評估。

a. 後設資料管理

隨著被接入系統的資料越來越多，相應的後設資料也愈加豐富多樣，因此對於後設資料的管理尤為重要。我們透過BD-OS來進行後設資料的自動整合和管理，主要從表，指令碼和工作流等方面進行後設資料管理。

b. 資料標準管理

為提升資料開發的效率，規範整體的開發流程，基於資料中臺開發規範，我們透過BD-OS來定義一套標準體系，包括命名標準，資料元標準，編碼標準和欄位標準。在進行後續模型開發時，可以直接引用對應的資料標準。

c. 資料質量稽核評估

資料接入之後，資料質量是非常重要的指標，資料質量的好壞，直接影響資料後續使用的效果和產生的價值。針對關鍵資訊，我們會確認資料的格式之後準確性，然後將具體的檢查點配置在BD-OS中。

• 資料規則校驗

• 資料格式校驗

透過BD-OS的資料質量稽核功能，我們針對關鍵表配置了資料質量稽核任務，透過稽核任務監控，我們可以清晰的看到每個稽核規則執行的結果。

同時，對於每張表，我們可以配置欄位級的校驗任務，根據結果得到資料質量分數。

（3）資料建模

應用BD-OS模型開發模組，開發可以透過視覺化配置的方式進行層級/主題域劃分，按照分層對邏輯模型配置邏輯表和表欄位，生成對應的物理模型並進行物理表管理；也可以直接在資料庫中建立物理表後，透過逆向工程生成對應的邏輯模型。海外專案中將模型分層劃分為STG、ODS和DW層，實現對資料的標準化處理和規範化管理，滿足應用端對資料的業務需求。

（4）資料開發

STG

STG層主要臨時儲存源系統資料檔案，一般透過兩種方式同步檔案，一種是共享交換平臺的週期性任務同步資料檔案，另一種是流式資料處理後的結構化資料檔案。海外專案中通常將兩種方式的資料檔案存放在HDFS系統中，以便BD-OS檔案載入至Hive資料表中。

ODS

ODS層會對各業務系統資料進行匯聚，保留業務系統全量的原始資料，並作為資料倉儲建設的資料來源，以便資料倉儲中查詢到所有業務資料，為後面的DW層資料建設做準備。海外專案中，以Hive表形式儲存ODS層資料，其包括STG層檔案資料和BD-OS資料接入的源系統資料，並新增一些標識性的屬性欄位，如系統名稱、資料插入時間等；並且按照源資料表業務邏輯和資料量大小採取增量或者全量的資料抽取方式。

DW

DW層的目標是建設一套覆蓋全系統、全歷史的業務資料體系，可以利用這套資料體系還原和檢視系統任意時刻的業務運轉狀態。應用BD-OS的ETL開發功能，將ODS層的資料按照資料倉儲模型，結構化的儲存起來，為上層分析應用提供易理解、易使用、易擴充套件的結構化資料。在海外專案中，一般按照上層應用的不同業務需求，採用不同的建模方式。

DW-CSM：作為資料中臺建模中的資料底座，採用正規化建模的方式，對專案中全系統資料進行整合，將各個系統中的資料以整個專案角度按照主題進行相似性組合和合並，並進行一致性處理。海外專案中，按照專案需求和源系統資料業務流程，將業務資料拆分為參與人、地址、事件、物品、組織、關係六大主題域，同時也滿足上層的動態本體模型構建。專案開發中，應用BD-OS資料工廠下的資料開發模組，透過編寫hive sql指令碼抽取ODS層資料，並在抽取過程中對資料清洗加工，具體有如下幾種操作：

（1）資料質量檢查：資料質量檢查會過濾掉垃圾資料和不規範資料，確保資料質量足夠好，能夠幫助業務人員理解真實的業務情況。

• 垃圾資料刪除：測試資料和虛擬使用者等資料，需要在系統中刪除，以免對業務資料產生影響。
• 錯誤資料刪除：由於系統錯誤而產生的錯誤資料需要刪除，例如錯誤的使用者狀態，或錯誤的金額等等。該部分需要源頭系統確認。
• 重複資料刪除：對於源頭系統已確認的重複資料，或者是在ETL過程中產生的重複資料，需要刪除以消除對真實業務資料的影響。

（2）資料轉換：來自不同源頭系統的資料，需要經過一系列轉化，使資料業務含義統一。

• 編碼轉換：來自於不同源頭系統的編碼，對於相同的業務含義，會有不同的編碼定義，例如從A系統的資料，用0，1，2定義性別，從B系統來的資料，用M，F，Others定義性別，需要對這些編碼進行轉換，使得對相同的業務含義，有相同的編碼與之對應。
• 按照應用需求的資料型別轉換：按照上層應用對資料的特殊要求，對ODS層資料進行處理，例如經緯度型別轉換，ODS層的地理經度和緯度欄位，處理為可寫入ES geo_point型別的資料格式。

（3）後設資料欄位新增：在上層應用動態本體建模中，需要知道每條資料的實體標識、事件時間，所以需要在每個DW表中新增實體名稱，事件時間等欄位。

DW-CDM：該層用於支援多維分析和大屏的資料應用，因此需要滿足使用者如何更快速進行需求分析，且需要良好的查詢響應效能，故從分析決策的需求出發構建維度模型。海外專案中，一般採用星型模型構建事實表和維度表的關聯關係。大致分為以下步驟：

• 選取業務流程，按照系統資料和相關業務選擇對應的分析決策需要的業務過程；
• 定義業務粒度，按照分析需要細分的程度選擇對應的粒度；
• 選取相關維度，按照定義的業務粒度，設計維度表，包括維度屬性；
• 選擇事實，按照分析需求確定需要計算的指標。

專案實施中，採用星型模型對各個維度做大量的預處理，如按照維度進行預先的排序、分類和統計，能夠極大地提升資料倉儲的處理能力；同時維度建模圍繞業務模型，可以直觀地展現業務流程，方便使用者快速開發指標和自定義建立指標，以支援多維分析的業務需求。另一方面，為了滿足大屏需求，基於維度建模指標表和維度表，結合大屏指標具體業務需求，設計開發滿足大屏指標展示的結果表，並透過BD-OS資料匯出功能將結果表資料匯出至Mysql資料表，大屏應用透過API讀取Mysql結果表資料後不再需要任何處理直接展示，提高大屏指標展示體驗效果。

DW-CBM：該層用於支援資料比對和資料共享的應用需求，為滿足應用端快速查詢和查詢的易操作性。海外專案中，一般採用寬表模型設計構建業務分析相關的大寬表，通常在BD-OS中基於DW-CSM層資料將業務實體相關的維度、描述資訊、指標等關聯後儲存在一張表中，例如把人員的基本資訊、編號、出生日期、新進人員標識、特殊人員標識、相關案件數量等資訊合成一張表儲存，再將Hive中寬表資料同步至ES中。應用端可按照業務需求在ES中任意查詢對應的資料資訊，並且不需要進行表資料關聯，提高查詢效率。

Ontology

本體庫採用本體建模方式，與資料倉儲建模不同，資料倉儲建模主要考慮的是資料的儲存方式和應用端使用的便捷程度，同時考慮儲存；而本體的建模，主要考慮建立的模型是否能夠表達真實世界的情況，例如在資料倉儲正規化建模中，是站在專案全系統面向主題的抽象，而本體模型是按照物件和關係表達真實世界。專案中，基於DW-CSM層各主題資料進行抽象分類，按照業務需求端的物件和關係進行資料對映。例如在DW-CSM層，參與人主題下有人員、新進人員、特殊人員三張獨立的表，每張表中會以編號作為人員標識，但是在本體模型中，會將三張表資料按照編號融合為一條資料，即人員實體的物件資料。應用端按照本體模型的設計查詢和擴充套件物件和關係資料展現業務場景。

（5）資料應用

基於上述模型，我們就可以靈活地支援設計好的資料應用需求：

DW-CSM：經過人地事物組織關係的標準化拆分後，為網路資訊庫提供賬號和帖子資料，為動態本體庫提供物件和關係資料；

DW-CBM：經過基於業務資料整合之後，為共享資源庫提供業務資料，為比對資源庫提供常用基礎資料；

DW-CDM：生成維度表和事實表之後，為專題業務庫提供維度和指標資料。

特別地，由於當地IT技術落後，各個部門之間的資訊通路不暢，資料共享開始作為客戶重點建設內容。我們依託百分點資料共享交換平臺，管理、審計、訂閱資料資源，對外提供安全高效的資料共享交換服務。

3.2.2 流式部分

（1） 資料接入

流式資料以Kafka為儲存媒介，透過資料處理引擎持續不斷地消費，進行實時的指標統計和資料儲存。資料接入方案主要有兩種：

• 利用大資料作業系統（BD-OS）的資料接入功能，實時的將資料從Kafka接入到HDFS，也可以直接接入Hive表中。
• 透過Spark Streaming實時消費Kafka中的資料，進行資料加工處理後寫入動態本體和ElasticSearch中，方便上層應用進行資料的分析和全文檢索。

（2）資料處理

流式資料大部分是網路社交媒體資料和行為事件類資料，比較突出的特徵是資料量大，其次單條訊息的業務價值有限，實時性要求不高。因此採用了具有微批處理功能的Spark Streaming，可以提升整體吞吐量，並且每批次的資料量可控。

這類資料的清洗加工工作直接在流裡完成，主要功能有靜態維度表關聯，資料打標和保證資料完整消費等。

• 靜態資料關聯：資料流透過在啟動時初始化靜態維度表，將資料快取到記憶體中，當有資料流過時，進行資料關聯操作。
• 資料打標：在流中為資料打上時間標識，透過事件發生時間，資料接入時間，資料處理時間和資料寫入時間等標識整條資料的完整生命週期和事件路徑。
• 保證資料的完整消費：在資料處理完成後手動提交offset，做到資料最少一次消費。在資料處理過程中，梳理完整的資料異常管理機制，將錯誤資料輸出到Kafka中儲存。對資料格式正常，但因網路波動等原因導致未寫入最終儲存的資料實施資料回寫，保證資料完整消費。

實時流程式的執行依託於大資料作業系統（BD-OS），透過平臺來進行整個任務的排程和監控。將相關jar包和配置檔案傳到平臺上，之後在流任務開發模組中進行啟動的具體引數配置和外部檔案依賴等操作。

（3） 資料應用

流式資料最終寫入動態本體和ElasticSearch，分別進行資料分析統計和內容全文檢索。將行為事件類資料寫入動態本體，透過知識圖譜構建實體和實體，實體和事件之間的關係，方便業務系統擴線分析。網路社交媒體相關的內容資料，採用ElasticSearch儲存，支援模糊搜尋和關鍵詞精確匹配，便於分析；相關內容檔案儲存在OSS（物件儲存服務）中，可根據資料ID標識獲取具體的檔案，圖片和影片支援直接在前端展示。

4. 系統運營

對於資料專案，系統上線，只是萬里長征第一步，接下來需要透過系統運營，讓系統持續發揮作用，同時收集更多的資料提升系統價值。

4.1 資料接入跟蹤

針對每個單位的每個系統，我們跟蹤每一個細節業務資料在系統落地的情況，從資料接入的各個環節，到資料處理到達的各個層級，都有非常準確的狀態標示。透過狀態的跟蹤，我們可以清楚地瞭解到每個部分資料接入情況，以及是否還有有價值但未接入的資料可以持續接入分析。

4.2 資料使用跟蹤

對於每一類資料，我們會按月統計使用情況，從而判斷資料熱度。對於熱度較高的資料，保證資料服務的穩定和高效；對於熱度較低的資料，必要時將資源下架，以節省系統資源。

（1）內部資料服務使用統計

（2）外部資料服務使用統計

4.3 系統維護

由於客戶現場IT支援能力缺失，我們配置的很多自動化告警措施無法正常執行，為了保證系統的穩定執行，現場運維人員制定了系統的巡檢表格，每天由專人來進行系統巡檢，發現問題之後，根據故障處理流程，通知客戶，處理故障，排查原因，從根本上解決問題，並持續監控一段時間，最終產出事故報告，形成問題處理的閉環。

資料運營是系統是否能夠順利落地並持續產生價值的非常重要的工作。同時，利用已有資料不斷地產生價值，可以推動未接入資料部門參與到資料平臺建設中，整合更多的資料，從而使資料發揮更大的價值，產生良性迴圈。

結語

海外資料中臺專案，歷經三年的臥薪嚐膽，砥礪前行，系統逐步落地執行，開花結果。在專案實施過程中，我們積累了很多實施經驗：

1. 專業、耐心地引導：要發揮專業優勢，從業務場景上給客戶引導，耐心地瞭解客戶真正的痛點，有的放矢地設計出真正能發揮價值的系統。

2. 近距離感受炮火：不能因為上萬公里的距離使需求的傳遞打折、失真，要站在客戶的身邊，與客戶一起分析需求，明確客戶的當務之急。

3. 充分估計困難：疫情下諸多因素使得海外專案面臨重重風險，在專案實施過程中，需要充分識別風險，並按照周、月、里程碑等粒度來監控，確保專案順利進行。

4. 高效遠端協作：為了提升遠端協作效率，需要做好設計文件的維護，研發需求、任務和缺陷的管理，同時進行實時地遠端影片溝通，保證資訊準確、及時的傳遞。

5. 多走一步：海外專案人員需要不斷擴充套件自己的職責範圍，多走一步，有計劃有條理地互相補位，緩解人員輪換的壓力，在艱難環境下實現節本增效。

最後，在專案執行過程中，我們不斷地總結沉澱，積累經驗教訓和實施的最佳實踐。我們按照地區進行解決方案、交付工藝和技術棧的沉澱，然後與其他地區進行交流互補，互相促進提升，使得交付的質量和效率不斷提升，形成一套標準的專案實施套路，讓後續的新專案有章可循。該資料專案實施的方法論，在系統落地、成本節約、團隊協作、流程最佳化、以及持續運營方面，都取得了很好的效果，有很高的參考價值。