編者按

踏上一帶一路的新絲路，北京百分點信息科技有限公司從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. 多走一步：海外項目人員需要不斷擴展自己的職責范圍，多走一步，有計劃有條理地互相補位，緩解人員輪換的壓力，在艱難環境下實現節本增效。

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

總結

以上是生活随笔為你收集整理的百分点大数据技术团队：乘风破浪 海外数据中台项目实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。