導讀： 傳統行業面對數字化轉型往往會遇到很多困難，比如缺乏數據管理體系、數據需求開發流程冗長、煙囪式開發、過于依賴紙質化辦公等，美聯物業也有遇到類似的問題。本文主要介紹美聯物業基于 Apache Doris 在數據體系方面的建設，以及對數據倉庫搭建經驗進行的分享和介紹，旨在為數據量不大的傳統企業提供一些數倉思路，實現數據驅動業務，低成本、高效的進行數倉改造。

美聯物業屬于香港美聯集團成員，于 1973 年成立，并于 1995 年在香港聯合交易所掛牌上市(香港聯交所編號:1200)，2008 年美聯工商鋪于主板上市（香港聯交所編號:459）， 成為擁有兩家上市公司的地產代理企業。擁有 40 余載房地產銷售行業經驗，業務涵蓋中、小型住宅、豪宅及工商鋪，提供移民顧問、金融、測量、按揭轉介等服務，業務遍布中國香港地區、中國澳門地區和中國內地等多個重要城市。

本文主要介紹關于美聯物業在數據體系方面的建設，以及對數據倉庫搭建經驗進行的分享和介紹，旨在為數據量不大的傳統企業提供一些數倉思路，實現數據驅動業務，低成本、高效的進行數倉改造。

考慮隱私政策，本文不涉及公司任何具體業務數據。

業務背景

美聯物業早在十多年前就已深入各城市開展房地產中介業務，數據體系的建設和發展與大多數傳統服務型公司類似，經歷過幾個階段時期，如下圖所示。

我們的數據來源于大大小小的子業務系統和部門手工報表數據等，存在歷史存量數據龐大，數據結構多樣復雜，數據質量差等普遍性問題。此外，早期業務邏輯處理多數是使用關系型數據庫 SQL Server 的存儲過程來實現，當業務流程稍作變更，就需要投入大量精力排查存儲過程并進行修改，使用及維護成本都比較高。

基于此背景，我們面臨的挑戰可以大致歸納為以下幾點：

• 缺乏數據管理體系，統計口徑統一，已有數據無法降本復用。多部門、多系統、多字段，命名隨意、表違反范式結構混亂；對同一業務來源數據無法做到多份報表復用，反復在不同報表編寫同一套計算邏輯。
• 海量數據下性能不足，查詢響應慢。歷史大多數業務數據存儲在關系型數據庫中，分表分庫已無法做到上億數據秒級分析查詢。
• 數據需求開發流程冗長、煙囪式開發。每當業務部門提出一個數據需求，數據開發就需要在多個系統之間進行數據兼容編寫存儲過程，從而導致存儲過程的可移植性和可讀性都非常差。
• 部門之間嚴重依賴文本文檔處理工作，效率低下。由于長期的手工統計，用戶已形成習慣，導致對信息系統的信任程度也比較低。

早期架構

針對上述的?個需求，我們在平臺建設的初期選?了 Hadoop、Hive、Spark 構建最初的離線數倉架構，也是比較普遍、常見的架構，運作原理不進行過多贅述。

我們數據體系主要服務對象以內部員工為主，如房產經紀人、后勤人員、行政人事、計算機部門，房產經紀在全國范圍內分布廣泛，也是我們的主要服務對象。當前數據體系還無需面向 C 端用戶，因此在數據計算和資源方面的壓力并不大，早期基于 Hadoop 的架構可以滿足一部分基本的需求。但是隨著業務的不斷發展、內部人員對于數據分析的復雜性、分析的效率也越來越高，該架構的弊端日益越發的明顯，主要體現為以下幾點：

• 過于笨重：傳統公司的計算量和數據量并不大，使用 Hadoop 過于浪費。
• 效率低下：T+1 的調度時效和腳本，動輒需要花費 1 小時的計算時間導入導出，效率低、影響數據的開發工作。
• 維護成本高：組件過多，排查故障鏈路過長，運維成本也很高，且部門同事之間熟悉各個組件需要大量學習和溝通成本。

新數倉架構

基于上述業務需求及痛點，我們開始了架構升級，并希望在這次升級中實現幾個目標：

• 初步建立數據管理體系，搭建數據倉庫。
• 搭建報表平臺和報表快速開發流程體系。
• 實現數據需求能夠快速反應和交付（1小時內），查詢延遲不超過 10s。
• 最小成本原則構建架構，支持滾動擴容。

01 技術選型

經過調研了解以及朋友推薦，我們了解到了 Apache Doris ，并很快與社區取得了聯系，Apache Doris 的幾大優勢吸引了我們：

足夠簡單

美聯物業及大部分傳統公司的數據人員除了需要完成數據開發工作之外，還需要兼顧運維和架構規劃的工作。因此我們選擇數倉組件的第一原則就是"簡單"，簡單主要包括兩個方面：

• 使用簡單：Apache Doris 兼容 MySQL 協議，支持標準 SQL，有利于開發效率和共識統一，此外，Doris 的 ETL 編寫腳本主要使用 SQL進行開發，使用 MySQL 協議登陸使用，兼容多數 MySQL 語法，提供豐富的數據分析函數，省去了 UDF 開發工作。
• 架構簡單：Doris 的組件架構由 FE+BE 兩類進程組成，不依賴其他系統，升級擴容非常方便，故障排查鏈路非常清晰，有利于運維成本的降低。

極速性能

Doris 依托于列式存儲引擎、自動分區分桶、向量計算、多方面 Join 優化和物化視圖等功能的實現，可以覆蓋眾多場景的查詢優化，海量數據也能可以保證低延遲查詢，實現分鐘級或秒級響應。

極低成本

降本提效已經成為現如今企業發展的常態，免費的開源軟件就比較滿足我們的條件，另外基于 Doris 極簡的架構、語言的兼容、豐富的生態等，為我們節省了不少的資源和人力的投入。并且 Doris 支持 PB 級別的存儲和分析，對于存量歷史數據較大、增量數據較少的公司來說，僅用 5-8 個節點就足以支撐上線使用。

社區活躍

截止目前，Apache Doris 已開源數年，并已支持全國超 1500 企業生產使用，其健壯性、穩定性不可否認。另外社區非常活躍，SelectDB 為社區組建了專職的技術支持團隊，任何問題均能快速反饋，提供無償技術支持，使用起來沒有后顧之憂。

02 運行架構

在對 Apache Doris 進一步測試驗證之后，我們完全摒棄了之前使用 Hadoop、Hive、Spark 體系建立的數倉，決定基于 Doris 對架構進行重構，以 Apache Doris 作為數倉主體進行開發：

• 數據集成：利用 DataX、Flink CDC 和 Apache Doris 的 Multi Catalog 功能等進行數據集成。
• 數據管理：利用 Apache Dolphinscheduler 進行腳本開發的生命周期管理、多租戶人員的權限管理、數據質量監察等。
• 監控告警：采用 Grafana + Prometheus + Loki 進行監控告警，Doris 的各項監控指標可以在上面運行，解決了對組件資源和日志的監控問題。
• 數據服務：使用帆軟 Report 為用戶提供數據查詢和分析服務，帆軟支持表單制作和數據填報等功能，支持自助取數和自助分析。

03 數據模型

1）縱向分域

房地產中介行業的大數據主題大致如下，一般會根據這些主題進行數倉建模。建模主題域核心圍繞"企業用戶"、"客戶"、"房源"、"組織"等幾個業務實體展開，進行維度表和事實表的創建。

我們從前線到后勤，對業務數據總線進行了梳理，旨在整理業務實體和業務活動相關數據，如多個系統之間存在同一個業務實體，應統一為一個字段。梳理業務總線有助于掌握公司整體數據結構，便于維度建模等工作。

下圖為我們簡單的梳理部分房地產中介行業的業務總線：

2）橫向分層

數據分層是最常見的 5 層結構主要是利用 Apache Doris + Apache DolphinScheduler 進行層級數據之間 DAG 腳本調度。

存儲策略： 我們在 8 點到 24 點之間采用增量策略，0 點到 8 點執行全量策略。采用增量 + 全量的方式是為了在ODS 表因為記錄的歷史狀態字段變更或者 CDC 出現數據未完全同步的情況下，可以及時進行全量補數修正。

3）增量策略

1. where >= "業務時間-1天或-1小時"

增量的 SQL 語句不使用 where="業務時間當天"的原因是為了避免數據漂移情況發生，換言之，調度腳本之間存在時間差，如 23:58:00 執行了腳本，腳本的執行周期是 10 分鐘/次，但是源庫最后一條數據 23:59:00 才進來，這時候 where="業務時間當天" 就會將該數據漏掉。

2. 每次跑增量腳本前獲取表中最大的主鍵 ID 存入輔助表，where >= "輔助表記錄ID"

如果 Doris 表使用的是 Unique Key 模型，且恰好為組合主鍵，當主鍵組合在源表發生了變化，這時候 where >=" 業務時間-1天"會記錄該變化，把主鍵發生變化的數據 Load 進來，從而造成數據重復。而使用這種自增策略可有效避免該情況發生，且自增策略只適用于源表自帶業務自增主鍵的情況。

3. 表分區

如面對日志表等基于時間的自增數據，且歷史數據和狀態基本不會變更，數據量非常大，全量或快照計算壓力非常大的場景，這種場景需要對 Doris 表進行建表分區，每次增量進行分區替換操作即可，同時需要注意數據漂移情況。

4）全量策略

1. Truncate Table 清空表插入

先清空表格后再把源表數據全量導入，該方式適用于數據量較小的表格和凌晨沒有用戶使用系統的場景。

2. ALTER TABLE tbl1 REPLACE WITH TABLE tbl2 表替換

這種方式是一種原子操作，適合數據量大的全量表。每次執行腳本前先 Create 一張數據結構相同的臨時表，把全量數據 Load 到臨時表，再執行表替換操作，可以進行無縫銜接。

應用實踐

01 業務模型

• 業務模型是分鐘級調度 ETL
• 初次部署建議配置：8 節點 2FE * 8BE 混合部署
• 節點配置：32C * 60GB * 2TB SSD
• 對于存量數據 TB 級、增量數據 GB 級的場景完全夠用，如有需要可以進行滾動擴容。

02 具體應用

1. 離線數據和日志數據集成利用 DataX 進行增量和全量調度，Datax 支持 CSV 格式和多種關系型數據庫的Redear，而 Doris 在很早之前就提供了 DataX Doris writer 連接器。

2. 實時統計部分借助了 Flink CDC 對源表進行實時同步，利用 Doris 的物化視圖或者 Aggregate 模型表進行實時指標的匯總處理，因我們只有部分指標需要實時處理，不希望產生過多的數據庫連接和 Flink Job，因此我們使用 Dinky 的多源合并和整庫同步功能，也可以自己簡單實現一個Flink DataStream 多源合并任務，只通過一個 Job 可對多個 CDC 源表進行維護。值得一提的是， Flink CDC 和 Apache Doris 新版本支持 Schema Change 實時同步，在成本允許的前提下，可完全使用 CDC 的方式對 ODS 層進行改造。

EXECUTE CDCSOURCE demo_doris WITH (
  'connector' = 'mysql-cdc',
  'hostname' = '127.0.0.1',
  'port' = '3306',
  'username' = 'root',
  'password' = '123456',
  'checkpoint' = '10000',
  'scan.startup.mode' = 'initial',
  'parallelism' = '1',
  'table-name' = 'ods.ods_*,ods.ods_*',
  'sink.connector' = 'doris',
  'sink.fenodes' = '127.0.0.1:8030',
  'sink.username' = 'root',
  'sink.password' = '123456',
  'sink.doris.batch.size' = '1000',
  'sink.sink.max-retries' = '1',
  'sink.sink.batch.interval' = '60000',
  'sink.sink.db' = 'test',
  'sink.sink.properties.format' ='json',
  'sink.sink.properties.read_json_by_line' ='true',
  'sink.table.identifier' = '${schemaName}.${tableName}',
  'sink.sink.label-prefix' = '${schemaName}_${tableName}_1'
);

3. 腳本語言采用 Shell + SQL 或純 SQL 的形式，我們在 Apache DolphinScheduler 上進行腳本生命周期管理和發布，如 ODS 層，可以編寫通用的 DataX Job 文件，通過傳參的方式將 DataX Job 文件傳參執行源表導入，無需在每一個源表編寫不同的DataX Job ，支持統一配置參數和代碼內容，維護起來非常方便。另外我們在 DolphinsSheduler 上對 Doris 的 ETL 腳本進行管理，還可以進行版本控制，能有效控制生產環境錯誤的發生，進行及時回滾。

4. 發布 ETL 腳本后導入數據，可直接在帆軟 Report 進行頁面制作，基于登陸賬號來控制頁面權限，如需控制行級別、字段級別權限，可以制作全局字典，利用 SQL 方式進行控制。Doris 完全支持對賬號的庫表權限控制，這一點和 MySQL 的設置完全一樣，使用起來非常便捷。

除以上之外，在容災恢復、集群監控、數據安全等方面也有應用，比如利用 Doris 備份實現容災恢復、Grafana+Loki 對集群進行指標規則告警、Supervisor 對節點組件進行守護進程監控，開啟 Doris 審計日志對執行 SQL 效率進行監控等，因篇幅限制，此處不進行詳細說明。

03 優化經驗

1. 數據導入

我們使用 DataX 進行離線數據導入，DataX 采用的是 Stream Load 方式導入，該方式可以通過參數控制導入批次流量，DataX 導入不需要借助計算引擎，開箱即用的特點非常方便。另外，Stream Load 導入是同步返回結果的，其他導入方式一般是異步返回結果，針對我們的架構來說，在 Dolphinscheduler上執行異步導入數據會誤以為該腳本已經執行成功，影響其正常運行。如采用其他異步導入方式，建議在 Shell 腳本中 執行 show load 再利用正則過濾狀態進行判斷。

2. 數據模型

我們所有層級的表模型大部分采用 Unique Key 模型，該模型可有效保證數據腳本的結果冪等性，Unique Key 模型可以完美解決上游數據重復的問題，大家可以根據業務模式來選擇不同的模型建表。

3. 外部數據源讀取

Catalog 方式可以使用 JDBC 外表連接，還可以對 Doris 生產集群數據進行讀取，便于生產數據直接 Load 進測試服務器進行測試。另外，新版支持多數據源的 Catalog，可以基于 Catalog 對 ODS 層進行改造，無需使用 DataX 對ODS 層進行導入。

4. 查詢優化

盡量把非字符類型（如 int 類型、where 條件）中最常用的字段放在前排 36 個字節內，在點查表過程中可以快速過濾這些字段（毫秒級別），可以充分利用該特性進行數據表輸出。

5. 數據字典

利用 Doris 自帶的 information_schema 元數據制作簡單的數據字典，這在還未建立數據治理體系前非常重要，當部門人數較多的時候，溝通成本成為發展過程中最大的“攔路虎”，利用數據字典可快速對表格和字段的全局查找和釋義，最低成本形成數倉人員的數據規范，減少人員溝通成本，提高開發效率。

架構收益

• 自動取數導數：數據倉庫的明細表可以定時進行取數、導數，自助組合維度進行分析。
• 效率提升：T+1 的離線時效從小時計降低至分鐘級
• 查詢延遲降低：面對上億行數據的表，利用 Doris 在索引和點查方面的能力，實現即席查詢 1 秒內響應，復雜查詢 5 秒內響應。
• 運維成本降低：從數據集成到數據服務，只需維護少數組件就可以實現整體鏈路高效管理。
• 數據管理體系：Doris 數倉的搭建，使得數據管理體系初步形成，數據資產得以規范化的沉淀。
• 資源節省：只用了少數服務器，快速搭建起一套數據倉庫，成功實現降本賦能。同時 Doris 超高的壓縮比，將數據壓縮了 70%，相較于 Hadoop 來說，存儲資源的消耗大幅降低。

總結與規劃

目前我們已經完成數倉建設的初期目標，未來我們有計劃基于 Apache Doris 進行中臺化的改造，同時 Apache Doris在用戶畫像和人群圈選場景的能力十分強悍，支持 Bitmap 等格式進行導入和轉換，提供了豐富的 Bitmap 分析函數等，后續我們也將利用這部分能力進行客戶群體分析，加快數字化轉型。

最后，感謝 Apache Doris 社區和 SelectDB 團隊對美聯物業的快速響應和無償支持，希望 Doris 發展越來越好，也希望更多的企業可以嘗試使用 Apache Doris。