2. 需求調(diào)研
在系統(tǒng)建設初期的需求調(diào)研階段，數(shù)倉工程師需要承擔的任務，主要有業(yè)務系統(tǒng)調(diào)研和業(yè)務數(shù)據(jù)分析，基于業(yè)務確定系統(tǒng)應用需求范圍之后，設計數(shù)據(jù)需求。
2.1 業(yè)務系統(tǒng)調(diào)研
在業(yè)務系統(tǒng)調(diào)研過程中，由于客戶技術能力所限，很難將系統(tǒng)的業(yè)務流程和數(shù)據(jù)解釋清楚，所以我們主要采用調(diào)研問卷、E-R圖和數(shù)據(jù)字典等方式進行系統(tǒng)分析。
（1）調(diào)研問卷
調(diào)研問卷主要幫助我們了解系統(tǒng)概況，主要包括：
· 是否有電子化系統(tǒng)
· 系統(tǒng)是B/S還是C/S架構
· 業(yè)務系統(tǒng)主要功能
· 與中心機房的網(wǎng)絡情況
· 系統(tǒng)數(shù)據(jù)的存儲方式
· 增、全量數(shù)據(jù)量
· 是否有備份庫
· 可以用何種方式提供數(shù)據(jù)
有了以上信息，我們能夠?qū)λ杞尤霐?shù)據(jù)有個基本的了解，判斷數(shù)據(jù)接入可行性以及所需的軟硬件條件。
（2） E-R圖
E-R圖主要幫助我們在客戶技術人員無法說明系統(tǒng)業(yè)務邏輯的情況下，了解系統(tǒng)的業(yè)務流程，通過表與表之間的主外鍵關系，結合對國內(nèi)相關業(yè)務的了解，推測業(yè)務數(shù)據(jù)流向，從而作為之后模型設計的輸入。
（3）數(shù)據(jù)字典
數(shù)據(jù)字典是業(yè)務調(diào)研過程中最重要的資料，有了數(shù)據(jù)字典之后，我們才能進行下一步的業(yè)務數(shù)據(jù)分析工作。在收集數(shù)據(jù)字典的過程中，我們會盡量與客戶的測試環(huán)境進行比對，確保拿到的數(shù)據(jù)字典是最新版本，避免因為版本更新問題，影響系統(tǒng)功能設計和數(shù)據(jù)接入流程的開發(fā)。
2.2 業(yè)務數(shù)據(jù)分析
業(yè)務數(shù)據(jù)分析主要包含兩個部分：
（1）數(shù)據(jù)項分析
數(shù)據(jù)項分析基于客戶提供的數(shù)據(jù)字典，對業(yè)務核心屬性進行確認，確保上層業(yè)務功能有相應的數(shù)據(jù)可以支撐
（2）數(shù)據(jù)質(zhì)量分析
數(shù)據(jù)質(zhì)量分析，基于客戶提供的測試或脫敏數(shù)據(jù)，對關鍵屬性進行空值、規(guī)則等判斷，確保數(shù)據(jù)本身具有實際的業(yè)務意義，以便之后的業(yè)務分析。
2.3 數(shù)據(jù)需求設計
對于整體系統(tǒng)的功能，我們從系統(tǒng)的兩端入手：首先參考國內(nèi)優(yōu)秀的建設方案和思路，基于當?shù)貙嶋H業(yè)務情況，規(guī)劃系統(tǒng)可能的整體功能；同時調(diào)研可接入系統(tǒng)的業(yè)務數(shù)據(jù)和業(yè)務流程，對整體功能進行裁剪和補充，形成符合當?shù)氐男枨笏{圖。確定系統(tǒng)功能之后，我們將系統(tǒng)功能對應的數(shù)據(jù)應用需求分為以下幾類：
（1）報表展現(xiàn)類
主要以維度和指標為主，利用報表或者大屏做業(yè)務指標分析或宏觀態(tài)勢監(jiān)控。
（2）人物事件分析類
主要以”對象-關系”方式進行實體、事件、文檔及相互關系、以及時間、空間的分析。
（3）數(shù)據(jù)比對類
主要以多數(shù)據(jù)集比對為主，發(fā)現(xiàn)不同數(shù)據(jù)集之間的相互匹配的數(shù)據(jù)。
（4）網(wǎng)絡信息分析類
主要以互聯(lián)網(wǎng)爬取信息為主，通過文本分析服務，發(fā)現(xiàn)熱點事件，熱點話題，熱點人物等信息。
（5）數(shù)據(jù)共享類
主要以各部門之間數(shù)據(jù)交換共享為主，保證數(shù)據(jù)共享過程中的穩(wěn)定和安全。按照以上不同的數(shù)據(jù)應用需求，結合百分點自有的產(chǎn)品以及使用的大數(shù)據(jù)開源組件，我們構建了數(shù)據(jù)中臺的5大信息庫：
（1）專題業(yè)務庫（MySQL）
以基于維度的指標匯總，按照不同業(yè)務專題構建的分析庫，方便高分大屏和CBI（百分點智能BI）系統(tǒng)進行報表展示。
（2）動態(tài)本體庫（ES+Neo4j）
利用百分點 DEEP FINDER產(chǎn)品，構建知識圖譜，以API方式為上層應用提供對象-關系分析，從繁雜的圖譜中發(fā)現(xiàn)類似的行為模式以及關鍵信息。
（3）比對資源庫（PostgreSQL）
利用比對分析系統(tǒng)，構建常用的基礎比對資源數(shù)據(jù)，與各個部門提供的數(shù)據(jù)進行可視化比對，發(fā)現(xiàn)匹配的對象，進行進一步分析。
（4）網(wǎng)絡信息庫（ES）
網(wǎng)絡爬取的數(shù)據(jù)，通過流式數(shù)據(jù)處理，導入以ES為存儲的網(wǎng)絡信息庫，利用規(guī)則、文本分析，情感分析等分析方法，發(fā)現(xiàn)熱點事件、熱點話題和信息傳播關鍵節(jié)點，進行后續(xù)處理。
（5）共享資源庫（MySQL）
利用百分點數(shù)據(jù)共享交換平臺，構建數(shù)據(jù)資源，對外提供安全、清晰的數(shù)據(jù)資源目錄，同時提供文件、數(shù)據(jù)庫、API等多種對接方式進行內(nèi)外部數(shù)據(jù)交換。
3. 項目設計
3.1 框架思路
完成了信息庫的設計，下一步就是建模、數(shù)據(jù)集成處理、調(diào)度以及監(jiān)控，上述任務均在大數(shù)據(jù)平臺（BD-OS）中完成。BD-OS作為基于大數(shù)據(jù)開源組件的一站式數(shù)據(jù)處理平臺，提供了數(shù)據(jù)接入、數(shù)據(jù)建模、ETL開發(fā)、流式開發(fā)、數(shù)據(jù)調(diào)度、數(shù)據(jù)監(jiān)控、數(shù)據(jù)治理等模塊，滿足數(shù)據(jù)處理全鏈路的所需功能。
我們采用了流批一體的經(jīng)典Lambda架構，分別處理實時接入的網(wǎng)絡數(shù)據(jù)和批量接入的業(yè)務數(shù)據(jù)；同時，我們采用分層設計，將數(shù)據(jù)倉庫層分為：STG層、ODS層和DW層，保證每一層清晰的數(shù)據(jù)處理邏輯。整體數(shù)據(jù)流圖如下：
部分整體分為三層：（1）數(shù)據(jù)源層
· 按數(shù)據(jù)來源分：包括爬蟲抓取的網(wǎng)絡數(shù)據(jù)，內(nèi)網(wǎng)環(huán)境業(yè)務系統(tǒng)數(shù)據(jù)，以及外網(wǎng)環(huán)境業(yè)務系統(tǒng)數(shù)據(jù)。
· 按數(shù)據(jù)格式：分為數(shù)據(jù)庫和文件。
· 按數(shù)據(jù)傳輸頻率：分為流式和批量（T+1）傳輸。
（2）數(shù)據(jù)接入層
· 流式數(shù)據(jù)的接入：我們主要利用Kafka作為存儲媒介，通過Spark Streaming進行數(shù)據(jù)處理，流式作業(yè)可以以jar包的形式通過BD-OS上傳服務器，從而實時監(jiān)控進程的執(zhí)行情況。
· 批量數(shù)據(jù)接入：對于內(nèi)網(wǎng)數(shù)據(jù)，我們直接使用BD-OS的數(shù)據(jù)導入功能進行接入；對于外網(wǎng)數(shù)據(jù)，考慮到系統(tǒng)數(shù)據(jù)交換的功能以及對外數(shù)據(jù)鏈路的安全性，我們使用數(shù)據(jù)共享交換平臺進行數(shù)據(jù)的導入。
· 多媒體數(shù)據(jù)接入：對于視頻或圖片等多媒體數(shù)據(jù)，我們使用OSS（對象存儲）來進行管理。對象存儲中包含兩種存儲組件：Hbase和Ceph。根據(jù)兩者存儲特性的不同，我們首先判斷多媒體文件的大小，對于1M內(nèi)的小文件，存入Hbase；超過1M的大文件，存儲至Ceph，對外通過統(tǒng)一的API進行訪問，通過文件的key來調(diào)用，提升多媒體文件的存儲和讀取效率。
（3）數(shù)據(jù)層
STG：用來接收文件形式的源頭數(shù)據(jù)并臨時存放。該部分的數(shù)據(jù)文件，除了業(yè)務系統(tǒng)批量導出的數(shù)據(jù)，還包含流式處理中需要進行批量統(tǒng)計的數(shù)據(jù)。
ODS：以Hive表形式來存放源頭數(shù)據(jù)。ODS作為數(shù)據(jù)中臺主體部分的最底層，存儲包含存放在STG層（臨時數(shù)據(jù)存放層）的文件數(shù)據(jù)，以及通過sqoop同步數(shù)據(jù)庫數(shù)據(jù)。當數(shù)據(jù)入表之后，數(shù)倉工程師就可以方便地使用SQL進行數(shù)據(jù)處理，降低門檻。
DW：根據(jù)不同的數(shù)據(jù)應用，我們采用了不同的建模方式，在DW層中建立了三類模型，數(shù)據(jù)均存儲在Hive中。選擇Hive的原因，一是方便傳統(tǒng)數(shù)倉工程師使用SQL和UDF進行數(shù)據(jù)處理；二是批量數(shù)據(jù)處理要求的時效性不高但數(shù)據(jù)量大，Hive的特性可以滿足需求。
· DW-CSM：標準化模型，采用范式建模，將底層數(shù)據(jù)按照參與人、地址 、事件、物品、組織、關系六大主題域進行整合。這樣做的好處，一是將繁雜的源頭系統(tǒng)的數(shù)據(jù)做拆分組合，使得業(yè)務邏輯更加清晰；二是在拆分組合的過程中，進行標準化處理，保證數(shù)據(jù)中臺內(nèi)部碼值和規(guī)則的統(tǒng)一，對外提供統(tǒng)一的數(shù)據(jù)標準；三是上層的動態(tài)本體，同樣是對象-關系的模式，底層數(shù)據(jù)拆分之后，可以方便地集成至本體中，無需在導入本體過程中做額外的處理。在底層業(yè)務系統(tǒng)數(shù)量多，業(yè)務繁雜，同時需要不斷集成新系統(tǒng)的情況下，范式建模能夠幫助數(shù)據(jù)人員理清業(yè)務關系，統(tǒng)一數(shù)據(jù)標準，經(jīng)過不斷地業(yè)務沉淀，最終可以建立行業(yè)模型。在這個部分，我們將網(wǎng)絡爬取數(shù)據(jù)單獨存放在ES中，方便之后的網(wǎng)絡信息庫應用，這部分數(shù)據(jù)直接一一映射，不做其他的處理。
· DW-CDM：維度模型，采用維度建模，按照上層的分析統(tǒng)計需求，建立維度表和事實表。為了提升查詢效率，我們使用標準的星型模型，同時由于Hive表關聯(lián)效率較低，我們在生成事實表時，對性別，年齡段等枚舉值維度做了退化處理，即用碼值名稱代替code存儲在事實表中，避免在數(shù)據(jù)處理過程中需要關聯(lián)過多維度表導致處理效率低下，影響用戶體驗。該部分模型主要支持多維分析和大屏的數(shù)據(jù)應用。
· DW-CBM：業(yè)務資源模型，采用寬表建模，將關鍵信息進行整理合并，形成屬性信息完整的寬表，方便之后的數(shù)據(jù)比對和內(nèi)外部數(shù)據(jù)共享。寬表的優(yōu)點是查詢效率極高，一次查詢無需關聯(lián)；缺點是靈活性很差，不適應頻繁的表結構變更，對于比對和數(shù)據(jù)共享需求來說，所需的主要信息變化很小，使用寬表，能夠大大提升比對和數(shù)據(jù)共享的效率。
另外，為了服務上層應用，我們單獨搭建了本體模型。Ontology：本體模型，采用本體建模方式，構建對象-關系的本體模型，來反映真實世界。對象信息主要存儲在ES中，而關系信息主要存放于Neo4j。這樣既能支持全文檢索來發(fā)現(xiàn)對象的關鍵信息，又可以通過圖的挖掘發(fā)現(xiàn)相同的行為模式，其中對象又可以分為：實體，事件，文檔。
· 實體：業(yè)務主體：包括人，車，物理地點等等。
· 事件：由業(yè)務主體實施的行為，基于事件可以進行時間和空間的分析。
· 文檔：文本類信息，單獨將文檔拆分出來的原因，是文檔會有特殊的處理方式，比如文本分析，話題抽象，情感分析等等。
3.2 設計思路
3.2.1 批量部分
（1）數(shù)據(jù)接入
數(shù)據(jù)接入的兩種方案概述：
目前海外項目中批量數(shù)據(jù)接入主要有兩種方案。一種是使用BD-OS自帶的數(shù)據(jù)導入功能，一種是使用數(shù)據(jù)共享平臺。這兩種方案均有各自的優(yōu)缺點，可以根據(jù)不同的業(yè)務場景按需采用。
BD-OS自帶的數(shù)據(jù)導入功能，實際上是集成了Hadoop生態(tài)的Sqoop組件。這種方式的優(yōu)點在于Sqoop是將導入命令翻譯成為MapReduce程序，與Hive集成較好，對導入到指定的分區(qū)表具有較好的支持。缺點只支持導入Hive或者是HDFS文件，并且由于與BD-OS綁定，通常會部署在內(nèi)網(wǎng)中。對于生產(chǎn)環(huán)境都會進行內(nèi)外網(wǎng)隔離，導致使用此方案時無法接入外網(wǎng)數(shù)據(jù)數(shù)據(jù)。
數(shù)據(jù)共享平臺核心功能有兩點，一點是資源共享，主要在于提供數(shù)據(jù)服務（通常是API），另外一點就是數(shù)據(jù)交換，本部分內(nèi)容重點討論數(shù)據(jù)交換這點。數(shù)據(jù)共享平臺的數(shù)據(jù)交換功能實際上是集成了阿里的開源離線數(shù)據(jù)同步工具DataX，它的優(yōu)勢在于支持的數(shù)據(jù)源豐富多樣，比如某個項目中不需要數(shù)據(jù)接入到Hive，而是直接接入到Phoenix，就可以使用數(shù)據(jù)共享交換系統(tǒng)的數(shù)據(jù)交換功能。另外相對于上一種方案，它相對比較輕量級，不需要部署整個大數(shù)據(jù)平臺BD-OS，因此通常也用于在生產(chǎn)環(huán)境上部署到DMZ網(wǎng)絡區(qū)域中，用于接入外網(wǎng)數(shù)據(jù)。它的缺點就是在于目前DataX對于Hive分區(qū)表支持不太完善，僅僅支持一次導入到一個分區(qū)表。
兩種方案詳細介紹：
我們先看一下BD-OS導入功能的界面：
由上述選項可以看出BD-OS的導入功能支持增量、全量導入，支持編寫查詢SQL，可以選擇是否覆蓋，另外對于導入的隊列、每次讀取數(shù)據(jù)條數(shù)等等有較為細節(jié)的控制。再看一下數(shù)據(jù)共享交換的界面：
可以看出與BD-OS導入功能對比，數(shù)據(jù)交換功能對于數(shù)據(jù)讀取條數(shù)等資源占用控制相關沒有提供更為細節(jié)的控制。但是也提供了SQL支持，字段映射設置、增量\全量同步、是否覆蓋、另外還提供了前置后置腳本功能。數(shù)據(jù)交換功能還提供了API用于其他ETL工具集成，調(diào)用API可以獲取到任務的執(zhí)行狀態(tài)。
總結：在數(shù)據(jù)導入的增量\全量，是否覆蓋、支持SQL等常用的需求點上，BD-OS的數(shù)據(jù)導入功能和數(shù)據(jù)共享平臺交換功能都提供了對應的支持，這兩種方案主要的區(qū)別還是在于體量級別以及其他的細節(jié)需求點上，實際項目中按需分別采用或者兩者都使用均可。
（2）數(shù)據(jù)治理
數(shù)據(jù)治理部分，主要包括：元數(shù)據(jù)管理、數(shù)據(jù)標準管理、數(shù)據(jù)質(zhì)量稽核評估。
a. 元數(shù)據(jù)管理
隨著被接入系統(tǒng)的數(shù)據(jù)越來越多，相應的元數(shù)據(jù)也愈加豐富多樣，因此對于元數(shù)據(jù)的管理尤為重要。我們通過BD-OS來進行元數(shù)據(jù)的自動整合和管理，主要從表，腳本和工作流等方面進行元數(shù)據(jù)管理。
b. 數(shù)據(jù)標準管理
為提升數(shù)據(jù)開發(fā)的效率，規(guī)范整體的開發(fā)流程，基于數(shù)據(jù)中臺開發(fā)規(guī)范，我們通過BD-OS來定義一套標準體系，包括命名標準，數(shù)據(jù)元標準，編碼標準和字段標準。在進行后續(xù)模型開發(fā)時，可以直接引用對應的數(shù)據(jù)標準。
c. 數(shù)據(jù)質(zhì)量稽核評估
數(shù)據(jù)接入之后，數(shù)據(jù)質(zhì)量是非常重要的指標，數(shù)據(jù)質(zhì)量的好壞，直接影響數(shù)據(jù)后續(xù)使用的效果和產(chǎn)生的價值。針對關鍵信息，我們會確認數(shù)據(jù)的格式之后準確性，然后將具體的檢查點配置在BD-OS中。
· 數(shù)據(jù)規(guī)則校驗
· 數(shù)據(jù)格式校驗
通過BD-OS的數(shù)據(jù)質(zhì)量稽核功能，我們針對關鍵表配置了數(shù)據(jù)質(zhì)量稽核任務，通過稽核任務監(jiān)控，我們可以清晰的看到每個稽核規(guī)則執(zhí)行的結果。
同時，對于每張表，我們可以配置字段級的校驗任務，根據(jù)結果得到數(shù)據(jù)質(zhì)量分數(shù)。
（3）數(shù)據(jù)建模
應用BD-OS模型開發(fā)模塊，開發(fā)可以通過可視化配置的方式進行層級/主題域劃分，按照分層對邏輯模型配置邏輯表和表字段，生成對應的物理模型并進行物理表管理；也可以直接在數(shù)據(jù)庫中創(chuàng)建物理表后，通過逆向工程生成對應的邏輯模型。海外項目中將模型分層劃分為STG、ODS和DW層，實現(xiàn)對數(shù)據(jù)的標準化處理和規(guī)范化管理，滿足應用端對數(shù)據(jù)的業(yè)務需求。
（4）數(shù)據(jù)開發(fā)
STG
STG層主要臨時存儲源系統(tǒng)數(shù)據(jù)文件，一般通過兩種方式同步文件，一種是共享交換平臺的周期性任務同步數(shù)據(jù)文件，另一種是流式數(shù)據(jù)處理后的結構化數(shù)據(jù)文件。海外項目中通常將兩種方式的數(shù)據(jù)文件存放在HDFS系統(tǒng)中，以便BD-OS文件加載至Hive數(shù)據(jù)表中。
ODS
ODS層會對各業(yè)務系統(tǒng)數(shù)據(jù)進行匯聚，保留業(yè)務系統(tǒng)全量的原始數(shù)據(jù)，并作為數(shù)據(jù)倉庫建設的數(shù)據(jù)源，以便數(shù)據(jù)倉庫中查詢到所有業(yè)務數(shù)據(jù)，為后面的DW層數(shù)據(jù)建設做準備。海外項目中，以Hive表形式存儲ODS層數(shù)據(jù)，其包括STG層文件數(shù)據(jù)和BD-OS數(shù)據(jù)接入的源系統(tǒng)數(shù)據(jù)，并添加一些標識性的屬性字段，如系統(tǒng)名稱、數(shù)據(jù)插入時間等；并且按照源數(shù)據(jù)表業(yè)務邏輯和數(shù)據(jù)量大小采取增量或者全量的數(shù)據(jù)抽取方式。
DW
DW層的目標是建設一套覆蓋全系統(tǒng)、全歷史的業(yè)務數(shù)據(jù)體系，可以利用這套數(shù)據(jù)體系還原和查看系統(tǒng)任意時刻的業(yè)務運轉(zhuǎn)狀態(tài)。應用BD-OS的ETL開發(fā)功能，將ODS層的數(shù)據(jù)按照數(shù)據(jù)倉庫模型，結構化的存儲起來，為上層分析應用提供易理解、易使用、易擴展的結構化數(shù)據(jù)。在海外項目中，一般按照上層應用的不同業(yè)務需求，采用不同的建模方式。DW-CSM：作為數(shù)據(jù)中臺建模中的數(shù)據(jù)底座，采用范式建模的方式，對項目中全系統(tǒng)數(shù)據(jù)進行整合，將各個系統(tǒng)中的數(shù)據(jù)以整個項目角度按照主題進行相似性組合和合并，并進行一致性處理。海外項目中，按照項目需求和源系統(tǒng)數(shù)據(jù)業(yè)務流程，將業(yè)務數(shù)據(jù)拆分為參與人、地址、事件、物品、組織、關系六大主題域，同時也滿足上層的動態(tài)本體模型構建。項目開發(fā)中，應用BD-OS數(shù)據(jù)工廠下的數(shù)據(jù)開發(fā)模塊，通過編寫hive sql腳本抽取ODS層數(shù)據(jù)，并在抽取過程中對數(shù)據(jù)清洗加工，具體有如下幾種操作：（1）數(shù)據(jù)質(zhì)量檢查：數(shù)據(jù)質(zhì)量檢查會過濾掉垃圾數(shù)據(jù)和不規(guī)范數(shù)據(jù)，確保數(shù)據(jù)質(zhì)量足夠好，能夠幫助業(yè)務人員理解真實的業(yè)務情況。
· 垃圾數(shù)據(jù)刪除：測試數(shù)據(jù)和虛擬用戶等數(shù)據(jù)，需要在系統(tǒng)中刪除，以免對業(yè)務數(shù)據(jù)產(chǎn)生影響。
· 錯誤數(shù)據(jù)刪除：由于系統(tǒng)錯誤而產(chǎn)生的錯誤數(shù)據(jù)需要刪除，例如錯誤的用戶狀態(tài)，或錯誤的金額等等。該部分需要源頭系統(tǒng)確認。
· 重復數(shù)據(jù)刪除：對于源頭系統(tǒng)已確認的重復數(shù)據(jù)，或者是在ETL過程中產(chǎn)生的重復數(shù)據(jù)，需要刪除以消除對真實業(yè)務數(shù)據(jù)的影響。
（2）數(shù)據(jù)轉(zhuǎn)換：來自不同源頭系統(tǒng)的數(shù)據(jù)，需要經(jīng)過一系列轉(zhuǎn)化，使數(shù)據(jù)業(yè)務含義統(tǒng)一。
· 編碼轉(zhuǎn)換：來自于不同源頭系統(tǒng)的編碼，對于相同的業(yè)務含義，會有不同的編碼定義，例如從A系統(tǒng)的數(shù)據(jù)，用0，1，2定義性別，從B系統(tǒng)來的數(shù)據(jù)，用M，F(xiàn)，Others定義性別，需要對這些編碼進行轉(zhuǎn)換，使得對相同的業(yè)務含義，有相同的編碼與之對應。
· 按照應用需求的數(shù)據(jù)類型轉(zhuǎn)換：按照上層應用對數(shù)據(jù)的特殊要求，對ODS層數(shù)據(jù)進行處理，例如經(jīng)緯度類型轉(zhuǎn)換，ODS層的地理經(jīng)度和緯度字段，處理為可寫入ES geo_point類型的數(shù)據(jù)格式。
（3）元數(shù)據(jù)字段添加：在上層應用動態(tài)本體建模中，需要知道每條數(shù)據(jù)的實體標識、事件時間，所以需要在每個DW表中添加實體名稱，事件時間等字段。DW-CDM：該層用于支持多維分析和大屏的數(shù)據(jù)應用，因此需要滿足用戶如何更快速進行需求分析，且需要良好的查詢響應性能，故從分析決策的需求出發(fā)構建維度模型。海外項目中，一般采用星型模型構建事實表和維度表的關聯(lián)關系。大致分為以下步驟：
· 選取業(yè)務流程，按照系統(tǒng)數(shù)據(jù)和相關業(yè)務選擇對應的分析決策需要的業(yè)務過程；
· 定義業(yè)務粒度，按照分析需要細分的程度選擇對應的粒度；
· 選取相關維度，按照定義的業(yè)務粒度，設計維度表，包括維度屬性；
· 選擇事實，按照分析需求確定需要計算的指標。
項目實施中，采用星型模型對各個維度做大量的預處理，如按照維度進行預先的排序、分類和統(tǒng)計，能夠極大地提升數(shù)據(jù)倉庫的處理能力；同時維度建模圍繞業(yè)務模型，可以直觀地展現(xiàn)業(yè)務流程，方便用戶快速開發(fā)指標和自定義創(chuàng)建指標，以支持多維分析的業(yè)務需求。另一方面，為了滿足大屏需求，基于維度建模指標表和維度表，結合大屏指標具體業(yè)務需求，設計開發(fā)滿足大屏指標展示的結果表，并通過BD-OS數(shù)據(jù)導出功能將結果表數(shù)據(jù)導出至Mysql數(shù)據(jù)表，大屏應用通過API讀取Mysql結果表數(shù)據(jù)后不再需要任何處理直接展示，提高大屏指標展示體驗效果。DW-CBM：該層用于支持數(shù)據(jù)比對和數(shù)據(jù)共享的應用需求，為滿足應用端快速查詢和查詢的易操作性。海外項目中，一般采用寬表模型設計構建業(yè)務分析相關的大寬表，通常在BD-OS中基于DW-CSM層數(shù)據(jù)將業(yè)務實體相關的維度、描述信息、指標等關聯(lián)后存儲在一張表中，例如把人員的基本信息、編號、出生日期、新進人員標識、特殊人員標識、相關案件數(shù)量等信息合成一張表存儲，再將Hive中寬表數(shù)據(jù)同步至ES中。應用端可按照業(yè)務需求在ES中任意查詢對應的數(shù)據(jù)信息，并且不需要進行表數(shù)據(jù)關聯(lián)，提高查詢效率。Ontology本體庫采用本體建模方式，與數(shù)據(jù)倉庫建模不同，數(shù)據(jù)倉庫建模主要考慮的是數(shù)據(jù)的存儲方式和應用端使用的便捷程度，同時考慮存儲；而本體的建模，主要考慮創(chuàng)建的模型是否能夠表達真實世界的情況，例如在數(shù)據(jù)倉庫范式建模中，是站在項目全系統(tǒng)面向主題的抽象，而本體模型是按照對象和關系表達真實世界。項目中，基于DW-CSM層各主題數(shù)據(jù)進行抽象分類，按照業(yè)務需求端的對象和關系進行數(shù)據(jù)映射。例如在DW-CSM層，參與人主題下有人員、新進人員、特殊人員三張獨立的表，每張表中會以編號作為人員標識，但是在本體模型中，會將三張表數(shù)據(jù)按照編號融合為一條數(shù)據(jù)，即人員實體的對象數(shù)據(jù)。應用端按照本體模型的設計查詢和擴展對象和關系數(shù)據(jù)展現(xiàn)業(yè)務場景。（5）數(shù)據(jù)應用基于上述模型，我們就可以靈活地支持設計好的數(shù)據(jù)應用需求：DW-CSM：經(jīng)過人地事物組織關系的標準化拆分后，為網(wǎng)絡信息庫提供賬號和帖子數(shù)據(jù)，為動態(tài)本體庫提供對象和關系數(shù)據(jù)；DW-CBM：經(jīng)過基于業(yè)務數(shù)據(jù)整合之后，為共享資源庫提供業(yè)務數(shù)據(jù)，為比對資源庫提供常用基礎數(shù)據(jù)；DW-CDM：生成維度表和事實表之后，為專題業(yè)務庫提供維度和指標數(shù)據(jù)。特別地，由于當?shù)豂T技術落后，各個部門之間的信息通路不暢，數(shù)據(jù)共享開始作為客戶重點建設內(nèi)容。我們依托百分點數(shù)據(jù)共享交換平臺，管理、審計、訂閱數(shù)據(jù)資源，對外提供安全高效的數(shù)據(jù)共享交換服務。
3.2.2 流式部分
（1） 數(shù)據(jù)接入
流式數(shù)據(jù)以Kafka為存儲媒介，通過數(shù)據(jù)處理引擎持續(xù)不斷地消費，進行實時的指標統(tǒng)計和數(shù)據(jù)存儲。數(shù)據(jù)接入方案主要有兩種：
· 利用大數(shù)據(jù)操作系統(tǒng)（BD-OS）的數(shù)據(jù)接入功能，實時的將數(shù)據(jù)從Kafka接入到HDFS，也可以直接接入Hive表中。
· 通過Spark Streaming實時消費Kafka中的數(shù)據(jù)，進行數(shù)據(jù)加工處理后寫入動態(tài)本體和ElasticSearch中，方便上層應用進行數(shù)據(jù)的分析和全文檢索。
（2）數(shù)據(jù)處理流式數(shù)據(jù)大部分是網(wǎng)絡社交媒體數(shù)據(jù)和行為事件類數(shù)據(jù)，比較突出的特征是數(shù)據(jù)量大，其次單條消息的業(yè)務價值有限，實時性要求不高。因此采用了具有微批處理功能的Spark Streaming，可以提升整體吞吐量，并且每批次的數(shù)據(jù)量可控。這類數(shù)據(jù)的清洗加工工作直接在流里完成，主要功能有靜態(tài)維度表關聯(lián)，數(shù)據(jù)打標和保證數(shù)據(jù)完整消費等。
· 靜態(tài)數(shù)據(jù)關聯(lián)：數(shù)據(jù)流通過在啟動時初始化靜態(tài)維度表，將數(shù)據(jù)緩存到內(nèi)存中，當有數(shù)據(jù)流過時，進行數(shù)據(jù)關聯(lián)操作。
· 數(shù)據(jù)打標：在流中為數(shù)據(jù)打上時間標識，通過事件發(fā)生時間，數(shù)據(jù)接入時間，數(shù)據(jù)處理時間和數(shù)據(jù)寫入時間等標識整條數(shù)據(jù)的完整生命周期和事件路徑。
· 保證數(shù)據(jù)的完整消費：在數(shù)據(jù)處理完成后手動提交offset，做到數(shù)據(jù)最少一次消費。在數(shù)據(jù)處理過程中，梳理完整的數(shù)據(jù)異常管理機制，將錯誤數(shù)據(jù)輸出到Kafka中存儲。對數(shù)據(jù)格式正常，但因網(wǎng)絡波動等原因?qū)е挛磳懭胱罱K存儲的數(shù)據(jù)實施數(shù)據(jù)回寫，保證數(shù)據(jù)完整消費。
實時流程序的運行依托于大數(shù)據(jù)操作系統(tǒng)（BD-OS），通過平臺來進行整個任務的調(diào)度和監(jiān)控。將相關jar包和配置文件傳到平臺上，之后在流任務開發(fā)模塊中進行啟動的具體參數(shù)配置和外部文件依賴等操作。
（3） 數(shù)據(jù)應用
流式數(shù)據(jù)最終寫入動態(tài)本體和ElasticSearch，分別進行數(shù)據(jù)分析統(tǒng)計和內(nèi)容全文檢索。將行為事件類數(shù)據(jù)寫入動態(tài)本體，通過知識圖譜構建實體和實體，實體和事件之間的關系，方便業(yè)務系統(tǒng)擴線分析。網(wǎng)絡社交媒體相關的內(nèi)容數(shù)據(jù)，采用ElasticSearch存儲，支持模糊搜索和關鍵詞精確匹配，便于分析；相關內(nèi)容文件存儲在OSS（對象存儲服務）中，可根據(jù)數(shù)據(jù)ID標識獲取具體的文件，圖片和視頻支持直接在前端展示。
4. 系統(tǒng)運營
對于數(shù)據(jù)項目，系統(tǒng)上線，只是萬里長征第一步，接下來需要通過系統(tǒng)運營，讓系統(tǒng)持續(xù)發(fā)揮作用，同時收集更多的數(shù)據(jù)提升系統(tǒng)價值。
4.1 數(shù)據(jù)接入跟蹤
針對每個單位的每個系統(tǒng)，我們跟蹤每一個細節(jié)業(yè)務數(shù)據(jù)在系統(tǒng)落地的情況，從數(shù)據(jù)接入的各個環(huán)節(jié)，到數(shù)據(jù)處理到達的各個層級，都有非常準確的狀態(tài)標示。通過狀態(tài)的跟蹤，我們可以清楚地了解到每個部分數(shù)據(jù)接入情況，以及是否還有有價值但未接入的數(shù)據(jù)可以持續(xù)接入分析。
4.2 數(shù)據(jù)使用跟蹤
對于每一類數(shù)據(jù)，我們會按月統(tǒng)計使用情況，從而判斷數(shù)據(jù)熱度。對于熱度較高的數(shù)據(jù)，保證數(shù)據(jù)服務的穩(wěn)定和高效；對于熱度較低的數(shù)據(jù)，必要時將資源下架，以節(jié)省系統(tǒng)資源。
（1）內(nèi)部數(shù)據(jù)服務使用統(tǒng)計
（2）外部數(shù)據(jù)服務使用統(tǒng)計
4.3 系統(tǒng)維護
由于客戶現(xiàn)場IT支持能力缺失，我們配置的很多自動化告警措施無法正常運行，為了保證系統(tǒng)的穩(wěn)定運行，現(xiàn)場運維人員制定了系統(tǒng)的巡檢表格，每天由專人來進行系統(tǒng)巡檢，發(fā)現(xiàn)問題之后，根據(jù)故障處理流程，通知客戶，處理故障，排查原因，從根本上解決問題，并持續(xù)監(jiān)控一段時間，最終產(chǎn)出事故報告，形成問題處理的閉環(huán)。
數(shù)據(jù)運營是系統(tǒng)是否能夠順利落地并持續(xù)產(chǎn)生價值的非常重要的工作。同時，利用已有數(shù)據(jù)不斷地產(chǎn)生價值，可以推動未接入數(shù)據(jù)部門參與到數(shù)據(jù)平臺建設中，集成更多的數(shù)據(jù)，從而使數(shù)據(jù)發(fā)揮更大的價值，產(chǎn)生良性循環(huán)。
結語
海外數(shù)據(jù)中臺項目，歷經(jīng)三年的臥薪嘗膽，砥礪前行，系統(tǒng)逐步落地運行，開花結果。在項目實施過程中，我們積累了很多實施經(jīng)驗：
1. 專業(yè)、耐心地引導：要發(fā)揮專業(yè)優(yōu)勢，從業(yè)務場景上給客戶引導，耐心地了解客戶真正的痛點，有的放矢地設計出真正能發(fā)揮價值的系統(tǒng)。
2. 近距離感受炮火：不能因為上萬公里的距離使需求的傳遞打折、失真，要站在客戶的身邊，與客戶一起分析需求，明確客戶的當務之急。
3. 充分估計困難：疫情下諸多因素使得海外項目面臨重重風險，在項目實施過程中，需要充分識別風險，并按照周、月、里程碑等粒度來監(jiān)控，確保項目順利進行。
4. 高效遠程協(xié)作：為了提升遠程協(xié)作效率，需要做好設計文檔的維護，研發(fā)需求、任務和缺陷的管理，同時進行實時地遠程視頻溝通，保證信息準確、及時的傳遞。
5. 多走一步：海外項目人員需要不斷擴展自己的職責范圍，多走一步，有計劃有條理地互相補位，緩解人員輪換的壓力，在艱難環(huán)境下實現(xiàn)節(jié)本增效。
最后，在項目執(zhí)行過程中，我們不斷地總結沉淀，積累經(jīng)驗教訓和實施的最佳實踐。我們按照地區(qū)進行解決方案、交付工藝和技術棧的沉淀，然后與其他地區(qū)進行交流互補，互相促進提升，使得交付的質(zhì)量和效率不斷提升，形成一套標準的項目實施套路，讓后續(xù)的新項目有章可循。該數(shù)據(jù)項目實施的方法論，在系統(tǒng)落地、成本節(jié)約、團隊協(xié)作、流程優(yōu)化、以及持續(xù)運營方面，都取得了很好的效果，有很高的參考價值。
