貝殼一站式大數據開發平臺實踐

01

背景介紹

貝殼一開始的數據體量非常小，那時候需求也非常簡單，所以那時候都是業務自己負責處理業務需求的獲取。隨着業務規模的增長，業務的需求逐漸的複雜化，直到最後業務方已經無法獨立承載數據的需求了。所以我們從 14 年就開始成立了一個大數據部，專門來研究數據需求，也就是數據開發的一些探索。我們當時針對貝殼數據需求分析了下，貝殼的數據基本上是會圍繞物的數據，人的數據，行爲的數據這三大塊來進行探究。

1. 數據業務

①物的數據

我們早在 08 年就開始籌建羅盤字典，當時我們是以接到小區單元門樓盤以及戶型圖之類的這些多維度信息進行描述，我們的房子到目前爲止已經承載了兩億多的房屋信息

②人的數據

基本上就是買家，實際上就是買房子的人，還有租戶以及業主，經紀人，以及後續我們升級爲貝殼品牌，還有介入了品牌以及我們後續的裝修人員這些數據

③行爲數據

買家在我們平臺上進行的線上瀏覽行爲，以及經紀人會在線下帶買家去業主家去看房行爲，等等線上和線下的信息

2. 設計準則

準則：

總之，就是降低數據處理的成本，快速爲各個業務方提供各種規範化的數據。

02

探索歷程

1. 最初階段

最初的數據開發平臺架構，就是使用 Hadoop 開源組件 Hadoop/Hive/Sqoop。因爲開源框架的文檔比較多，而且它對應的那些解決方案也比較成熟，也方便組件擴展跟運維。開發過程中，也可以通過衆多的文檔資料能快速的熟悉架構模塊。

在數據存儲方面，使用了業界比較成熟的一個數據倉庫的方案，就是分層模型。第一層是接入層，然後數倉層加報表層三個模型，可以避免踩很多一些不必要的坑。

在業務上，數據開發與業務緊密結合，使用了 Case By Case 的定製化開發方式來滿足業務的需要。

當然，這種開發架構的缺點也是非常明顯。

缺點：

後來開始進行了我們平臺化的探索

2. 平臺化架構

本次架構升級，引入了數據管理平臺， AdHoc 查詢平臺。

數據管理平臺包括了元數據管理 、數據質量、數據安全、調度系統。所有的元數據查詢、數據開發操作，都可以在一個平臺進行管控。

AdHoc 查詢的功能，可以讓業務分析人員結合元數據管理裏面的數據地圖，針對臨時的業務查詢，自主的在數據開發平臺進行分析，不在需要數據開發工程師的介入。讓業務開發的人員，自己去承載具體的業務需求, 自主的維護業務數據。

同時，針對調度系統進行重構，借鑑了 Airflow/ 宙斯的相關框架，使用 workflow 的形式，將運行日誌集成到了平臺，節點的運行情況，使用流程圖的形式進行一個展現，方便業務進行問題定位。

優點：

缺點：

3. 平臺化架構 - 飛躍階段

我們就做了一個下面的一些優化，比如說第一個就是我們的資產資源，我們就加了一個數據資產的管理，以及第二個就是我們對應的這些數據開發的一些流程都提供給業務了，業務它怎麼樣很方便地來我們的平臺去玩兒，怎麼樣去開發，那就提供了一些數據開發的一些套件，然後這些數據怎麼樣的能健康及時準確地流轉給業務，實際上就是我們做了一些統一的一些監控智能的一些運維的工作。架構如下圖：

在數據接入層，從原來 Sqoop 我擴展到了 DataX/Dbus。：Log 日誌接入，我們使用了 Flumn 接入進來的，然後中間的數據加工計算，實際上就是在我們手機管理平臺有一個一站式開發的一些組件，然後建完了之後就可以通過我的任務調度系統能去週期性地運行我們的任務，然後這些數據通過我們的開放平臺，比如說 API 交換訂閱的一些消息隊列釋放給業務，能產生我們的數據的價值，然後這些也沉澱了幾個底層的一些服務，比如說像權限這一塊兒，能負責我們整個大數據的一些權限流程，然後數據質量實際是保證我們從接入到開發到我們釋放之後，整個的一些質量能及時準確，然後還有元數據管理是能保證我們數據是唯一準確的。

03

平臺介紹

1. 數據管理

數據管理的特點

第一個實際上就是一個統一的元數據模型，就是我們所有的人數據，包括關於基因數據，非關係型的一些數據，以及那些 log 的這些元數據，還有半結構化的，這些我們都是通過一個元數據模型去管控

實際上就是通過業務的數據源到我們的數據獲取存儲，到我們的應用分析然後帶到我們的產品服務，以及它產生的一些數據，迴流到我們的一數據源，整個的原數據進行匯聚，

我們的元數據，它具備了第一有技術上數據的一些管理，第二是業務的人數據的一些管理，還有第三是管理的人數的數據管理，以及我們的自帶血緣加數據血緣這一塊兒，這些管理起來了之後，我們可以去做一些資產化的一些管理，相當於說我們能知道我們貝殼有哪些數據了。

第二個我們就可以去做一些賦能的問題，例如說我這些軟數據進行一個數據地圖或者說數據資產的一些功能的一些展示提供，可以讓用戶能知道我們大數據平臺有哪些數據，這些數據都長成什麼樣子的，應該怎麼去獲取，應該找誰去申請之類的。

數據管理的實現效果

①數據錄入

有些數據我們是主動採集的，比如說像 DB 類的，這些都是業務系統的一些數據，都是由數據管理平臺去採集。但是對於有一些數倉開發的一些任務表，我們是通過平臺制定一些規範，在平臺進行錄入的。同時，我們現在還支持 CK 跟 Kafka 的元數據。

②數據導航

我們怎麼讓業務找到數據，讓用戶找找到數據，首先是通過我們的數據導航，我們通過業務圖譜能找到，比如從業務從數據錄入到帶看，然後到我們成交這一套的業務路徑，然後它每一個環節對應的一些表，我們就可以通過業務圖譜去找到。還有一些我們可以有個性化的一些模塊，比如說我個人的表，我有權限的表，我創建的表，就可以快速地找到這些數據。

③智能搜索

如果說數據導航還找不着，那麼可以使用智能搜索，我們已經具備了模糊匹配表中文名，英文名兒，然後描述以及字段名裏的描述，能讓用戶能去自動的去找到這些表。元數據詳情內容有，有基本信息，字段信息，還有一些邏輯處理，調度任務這些詳情數據，血緣可以讓用戶能很明顯的去看到我這張表是做了什麼事情，而且它的數據是從哪來的，而且它是怎麼加工來的，那麼它就可以通過我們的權限資質查詢去看這些數據是什麼樣的，而且能去自助的去分析。

 ④資產管理

第一場景，假如說是工作交接了，涉及到一些權限轉移之類的，可以通過我們平臺做到權限一個閉環。

第二個是我們的資產管理，大數據平臺肯定是承載了所有的業務的數據，如果說我們不做一些生命週期的管控的話，它肯定會一直膨脹，它的膨脹速度一定是隨着我業務的增長而增長的，我們就會涉及到一個生命週期的一些管理。關於生命週期的管理這一塊，我們做了一些規則，以及表維度的一些沉澱，然後可以給用戶進行一些確認，然後就可以達到平臺的一些規生命週期的一個管理。

生命週期管理：

第一是我們能把冷數據備份，能把無效的數據是無效的任務下線，一些不必要的表進行清理之類的一些操作，而且還做了一個引入了一個工作空間的概念，就是說我們會把我們的數據資產按照我們不同的一些業務進行化作工作空間，然後這些工作空間進行一個配額限制，然後能從而達到正向的去引導用戶去做。

資產空間信息展示：

資產的生命週期的一些管控，並且在我們的資產空間管理裏面有做到數據質量的一些分析，分析的內容包括：

工作空間：

我們工作空間還可以做到團隊協作，估計大家應該做過，數據工廠應該都會有這些有團隊協作的一個概念，應該大家都是用什麼角色 / 組或者說一些角色去做的，這些事情實際上我們拿到工作空間去做，就是說我們工作空間的人都能去操作這些數據，這樣的話我們就能知道我們貝殼有哪些資產，這些資產都是什麼樣的，我們哪些沒有接入到大數據。

2. 數據集成

可以通過數據集成，把未接入的數據能快速的集成到我們的大數據平臺。已經支持的數據源類型包括 MySQL/Oracle/SQL Server/TiDB/MongoDB/Kafka 等等 。現在可以滿足 99% 以上的一些業務數據接入場景。接入能力以配置的方式自動化實現。比如說新建庫表這一塊，我們就能自動化接入到我們的大數據平臺。還可以支持數據遷移，從一個實例遷移到另一個實例。同時也支持業務拆分場景，把某一個業務裏面的一張表拆到另外一個業務裏面去，我們能夠做到自助的一些遷移，能保證我們的數據的一些完整性。

從時效性上來講，能做到 T+1，如果說要更小粒度，目前能夠做到小時 + 1。

業務變更實時提醒：

業務變更的情況下，我們能自動同步跟提醒怎麼說？業務人員與數據開發人員及下游相關人員，那麼他們怎麼樣去建立互通？信息的不對稱，所以導致我們的數據業務會是失敗，或者說沒接到大數據。所以我們做到，就是說業務的原數據變更了，我們能自動感知到，然後我們自動同步到大數據，並提醒到相關人員，讓他去做一些變更，有一些我們可以也能自動做到，就是說我們直接去同步。

3. 作業調度

業務數據都接到我們大數據來了，那麼我們數倉同學他就要去做一些開發操作，那麼它的數據建模，它數據建設怎麼去做？

開發流程簡介

在平臺創建一張表，填一些表的一些基本信息，它屬於哪個層級的，它屬於哪個庫的，按照模型去定義好對應的表名，然後它的負責人是誰之類的一些基本信息。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

然後再說我們這張表應該有哪些字段信息，這些我們可以通過可視化添加，比如說我們去新加字段還可以，就是說我們通過語句添加生成這個字段。

然後去做一個業務邏輯。

大家都知道，我們數據開發基本上就是要麼寫個 INSERT OVERWRITE AS SELECT，可以直接在平臺完成開發操作。寫完之後我們就可以簡單的去做一個調度的配置，就是說我們這個任務，計劃該是明天幾點跑，或者說每週的幾點跑，每月的幾點跑，我們依賴的上游任務有哪些，我們任務失敗報警應該報給誰之類的，這些在這做簡單的配置之後，我們就會生成一個版本。

那麼這個版本，我們就可以進入到測試階段。測試過程包括，SQL 語法校驗，任務結果準確性測試。

做完發現這數據沒有問題了，就可以達到上線的環境進行調度，實際上就是我們的調度系統。它能幫助我們把週期性的任務，按照時間順序，基於工作流依賴進行調度起來。而且能支持許多豐富的數據交換場景。

第一，它是個簡單配置，剛纔看的頁面就能完成我整個配置的一些需求，然後還提供了一些常用的一些 ETL 組件，比如說我們的報警監控這一塊兒，原來我們是每次報警，我們寫一段代碼，把所有的信息寫進去，然後告訴他我要報給誰，我應該是怎麼報之類的。那麼這一塊我們就直接假如說我要發一個失敗了發一個郵件，那不就只用填一個 Email 郵箱，或者說發給短信就直接填個手機號就能搞定。

同時，我們得有一個依賴，那麼還有個推薦依賴，這一塊就可以有一個依賴關係的一個可視化，能知道我們數據是從哪個節點出現問題了，假如說我這個數據一直沒運行，哪個點判定了，導致了這個事情沒運行。現在問題修復時間從原來的一天縮減到現在的十分鐘。

還有一個就是我們這些數量數據任務都已經很多了，那麼它怎麼樣讓它能高效地運轉，讓業務能快速的拿到數據，實際上就是這一塊就引入了一些調度算法，這塊應該引入的一些參數，實際上就是我們的依賴度，執行時長之類的一些因素，還能保證我們高優先的運行。

4. 數據質量

① 提出問題

這些數據已經都能跑了。那麼它對應的質量怎麼樣？實際上它有的一個及時性和準確性的概念，就是說我們數據怎麼能讓他及時的讓用戶拿到，即使拿到了之後，它怎麼樣是準確的。比如說我今天拿了一個表，發現裏面數據是空的，或者說裏面本來是個交易額，結果是個零，這個數據肯定是不準確的，所以它就會有一個數據質量這一塊兒。大部分場景下，我們數據開發人員都是通過 SQL 的形式完成業務表達，寫好的 SQL 邏輯放在調度上，我們怎麼樣去測試？這是一個問題。第二個是我們數據每日運行的任務，這到底是失敗的還是成功的？我這任務有沒有運行，這是另外一個問題。

② 及時性問題

然後及時性這一塊實際上就是我們任務這一塊，有一些就是說無法感知的一些東西。假如說老闆要我一個集團日報，他要在早上 6 點產出，我們應該怎麼辦？

我們在上一家公司做的時候，我們集團制日報是也是保證六點產出，但是我們鏈路比較短，所以我們當時做法是，把所有的 SLA 時間壓縮一半，就相當於說三點能夠產出。所以我們集團日報最後一個葉子節點在三點能產出，如果產出不了，發現即使它是最源頭的一個任務失敗了，我們改了之後，我也可以拿剩下的時間去運行，也能保證到我們六點能夠及時產出到這個日報。

但是對於貝殼這個業務場景非常複雜，它的鏈路非常長。即有些任務它運行的時間超過半小時，或者說一小時，那麼整個鏈路跑下來估計有五六個小時。如果是說我們到五六點的時候纔去發現葉子節點沒跑完，結果是我們最上層一個節點是失敗的，那麼我們改完之後再去跑，結果肯定是到 12 點才能說拿到這些數據，這還是如果順利的話。如果不順利的話，可能我到 12 點還拿不到這個數據。

③ SQL 解析

第一，就是測試環節，關於 SQL 需要進行檢驗。第一個方式是我們 SQL 邏輯寫完之後，我們會經過 SQL 解析去看他寫語法有沒有錯誤，比如說我寫了個 Left Join，但是後面沒沒有 on 的一些關鍵字；或者說我在這裏面寫了一個 select 沒有 from，它是能通過 SQL 語法解析解釋出來的。但是還有可能存在其他的問題，就可以通過第二種方式，使用 Explan 模式去讓它去生成一個執行計劃，看看它是不是有問題。

這裏面的一個我們當時遇到一些場景，我們 SQL 解析出來了，但是它沒有語法錯誤，但是我們這裏字段裏面發現有一個多了個字段，或者說少了一個字段，以及他沒法去捕獲，結果他任務失敗了，所以這就需要我們用 Explan 模式 去生成一個執行計劃。

然後及時做了這些，你還不放心，就可以去測試，真真實實地跑一遍，然後去驗證它的數據量，驗證它的波動性。最後就可以放心的去上線。

④ 監控任務鏈路

在任務運行中，我們提供了監控任務鏈路。覆蓋了任務失敗，任務超時的場景。我們的做法就是，針對每一個任務，會基於它的平均時間去算每一個任務的今天預計理想的一個產生時間，然後再加一些 buffer 時間。基於這個時間去做關於鏈路下的任務監控。比如說我計算日報應用了上游哪些表，每個表它對應的基準時間是多少，然後基於上下游完成時間的監控，去保證正常且及時的去產出。

⑤ 準確性

然後對於那位數據，還有一個數據的一個準確性，就是我們接入的時候，它是不是完成了完整的接進來。比如說我們一張表，它可能有 3000 萬行，結果我們接進來了就 2 萬行的數據，那麼我們怎麼樣去監控？然後另外一個就是說我們字段的變化，比如說我們一個表，它知道你改變了，我們怎麼樣去讓它感知了，實際上就是通過我們的採集完整性，做到變化監控，還有一些數據閾值的一些波動性監控。那麼這些數據我們都能保證它是正確的及時的完成的。

5. 數據開放

那麼怎樣數據開放出去，如果沒有開放出去，那麼它對應的數據實際上就是一個成本，它就是個垃圾。如果是說你不給開放出去了，給業務應用了，那麼就是相當於我們的數據釋放了價值，

① 對接業務人員

我們數據開放會有兩種場景，第一種就是有人來找我們要數據，有人也想經過我們大數據去分析數據，看數據，那麼這些就是人。業務人員來找我們大數據要數據的時候，實際上是通過我們奧丁平臺去搞定的。奧丁平臺是我們自研的一個可視化系統，以及 AdHoc 的一個自身平臺的一個集合。可視化的這一塊分析可以通過奧丁的可視化報表去看。奧丁的自助分析，比如說我們要做一個 BI 分析師，我要出這個數也要出那個數，我要改口徑，那麼可以用我們的 AdHoc 自助查詢引擎去做這些事情。

② 對接業務系統

第一個場景，貝殼找房裏面的地圖數據以及我們指表數據，是通過我們數據開放去拿的。它的應用場景，就是我們直接應用到 APP 端，提供了 Hive 明細的一些元數據以及指標。然後還有一些實時的一些數據，實際上就是我們通過實時去計算得到的一些數據。

第二個場景是拿到我們大數據的數據，然後再跟業務的一些部分數據進行融合，得到了一些最終數據。通過數據交換，實際上就是支持端對端的傳輸能力，把我們的數據直接交換到他們的系統裏面，比如說業務系統的 MySQL、MongoDB 等等。

還有一種應用場景，也可以通過大數據 API 拿到數據。去通過一個簡單的方式，讓用戶無編碼的方式，去拿到我們這些指標數據。

具體的做法就是，通過基本信息 / 請求信息 / 返回信息，進行排序預覽能完成上線，實際上就是拿到了一個大數據 API，然後它在業務進行調用就夠了。在技術架構上我們使用了一箇中間層，因爲它的數據查詢需求會影響資源，還有就是查詢的時效性上有要求，比如我們對應的 APP 端它需要的一個性能要求是比較高的，在技術實現上，所以我們藉助了一些中間層，比如說 HBASE/CK/MySQL 這些中間層把數據緩存，然後通過 API 的配置，應用到我們的業務。

③ 業務變更通知

然後第三個實際上就是一些數據通知訂閱的能力，實際上就是我們數據改變了，或者說我們數據有個結構變了，那麼怎麼樣讓業務去感知到，我這邊增加了一些房子，就是房源系統裏面我添加了一個房子，我怎麼樣在業務房源列表裏面能實時看到，實際上就接助了一個 EPX 的一個訂閱能力。

這就是我們整個大數據平臺，從輸入的集成管理，然後到開發到運維以及到開放出去整個流程的能力建設，目前來看能達到一個很好的一些成果。

04

總結與展望

在未來我們會集成更多的能力，例如說我們的 IDE 的一些能力；還有一個就是我們的數據治理的能力；賦能前臺實現智能的一些管理，以及提升我們整體的一個開發跟使用的一些效率。目前，數據都集成在我們大數據平臺，我們怎麼樣讓它更安全的保障數據的存儲，訪問跟傳輸過程，打造我們企業界的一個大數據平臺是我們的一個方向。

今天的分享就到這裏，謝謝大家。

分享嘉賓：

仰宗強

貝殼 | 資深工程師

仰宗強，貝殼找房資深數據工程師, 現負責貝殼找房一站式大數據開發平臺建設。曾就職於百度，參與百度流量數據倉庫和工具平臺的研發工作。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/NgCABp5BEYcGfFhlhzn5bA

猜你喜歡