TOP100summit：【分享實錄】鏈家網大數據平臺體系構建歷程

本篇文章內容來自2016年TOP100summit 鏈家網大數據部資深研發架構師李小龍的案例分享。
編輯：Cynthia

李小龍：鏈家網大數據部資深研發架構師，負責大數據工具平臺化相關的工做。專一於數據倉庫、任務流調度、元數據管理、自助報表等領域。以前在百度從事了四年的數據倉庫和工具平臺的研發工做。

導讀：鏈家網大數據部門負責收集加工公司各產品線的數據，併爲鏈家集團各業務部門提供數據支撐。本文分享鏈家網大數據部成立後，在發展變革中遇到的一些問題和挑戰，架構團隊是如何構建一站式的數據平臺來解決獲取數據的效率問題，如何構建多層次系統來組建大數據架構體系。重點介紹團隊早期做爲數據報表支持者，向當下數據平臺方轉變的這一歷程，經過對數據處理流程的梳理，構建一體化的數據接入/計算/展現的開放平臺，提高數據運轉效率，快速知足集團內數據需求。

1、背景簡介

鏈家網自2014年成立後，全面推動020戰略，打造線上線下房產服務閉環，公司業務迅速增加，覆蓋全國28個地區，門店數量超過8000家。隨着鏈家集團積累數據的不斷增多，在2015年專門成立了大數據部，推動集團內各公司數據資產的整合，以數據驅動公司業務的發展。

鏈家將房地產交易大數據分爲物的數據、人的數據、行爲數據三大塊來進行研究。
● 物的數據主要是構建了全國的樓盤字典，擁有專業的攝影測量團隊實地勘測，收錄了7000萬套房屋的詳細信息，包括小區周邊、人文素養等等。
● 人的數據，包括買家、業主、經紀人三方，目前在全國有13萬經紀人，對經紀人的背景、從業年限、資歷、專業能力、歷史行爲有詳細記錄，給客戶更加精準的參考。目前鏈家網服務的買家和賣家超過兩千多萬，對用戶進行畫像，而後推薦更加合適的房屋。
● 行爲數據，包括線上行爲和多樣的線下行爲，譬如線上的瀏覽日誌，線下的看房行程等。

經過分析這些數據，找到與業務的結合點，目前大數據在鏈家網具體的應用場景有房屋估價、智能推薦、房客圖譜、BI報表。

2、大數據從0到1的架構落地

大數據部成立之後，借鑑業界成熟的數據倉庫方案，設計的早期架構圖如圖1所示：

圖1 數據倉庫早期架構

在這個階段咱們主要作了三件事：
● 搭建hadoop集羣，初期只有10多臺機器，隨着業務的發展，集羣規模也在不斷增加。
● 採用HIVE構建數據倉庫，數據倉庫裏的數據來源於業務方的mysql數據庫和log日誌。
● 定製化報表開發，按照業務方的需求，case by case作一些BI報表展現，知足業務方對數據的分析。

這個架構簡單清晰，這樣作有三個好處：
● 使用開源的組件，方便擴展和運維；
● 採用業界成熟的數據倉庫方案，數據倉庫分層模型設計；
● 有利於技術人員培養，技術團隊在成長初期技術選型須要考慮市場上人員狀況，因此選擇了使用範圍廣的技術。

具體講講HIVE數據倉庫的模型，該模型一共分爲5層。
● 最下面是STG層，用來存儲源數據，保持與數據源徹底一致；
● 第二層是ODS層，會進行數據清理等工做，譬如不一樣業務系統的城市編碼不一致，有的001表明北京，有的110表明北京，在ODS層進行維度編碼的統一處理。還有不一樣業務系統的金錢單位不一致，有的是元、有的是分，在此統一採用分爲單位，保留兩位小數；
● 最上面是報表層，根據業務需求進行加工處理，產出報表數據。至於數據倉庫遵循的範式結構，目前沒有嚴格一致地規範，星型模型和雪花模型都有采用。

早期的大數據架構落地後，支撐了將近一年時間，從2015年初到2016年初，取得了不錯的效果。
● 收集彙總了集團內各個分公司、各條產品線的數據，便於交叉分析。經過對比分析數據，能幫助業務系統更好的發展。
● 支撐集團內大部分報表需求，幫助運營人員改進決策，數據驅動。 巧婦難爲無米之炊，當數據倉庫積累了大量歷史數據，數據挖掘的同窗就能進行深度分析。

3、大數據平臺化體系的建設

爲何要作平臺化？

主要緣由仍是隨着公司業務的快速發展，數據需求迅速增多，早期的大數據架構遇到一些新挑戰。
● 數據需求快速增加：鏈家業務增加到全國多個城市，各個城市的報表需求不少，並且因爲各個地方的政策不太同樣，報表需求也有所差別，此外還有大量的臨時統計數據需求。爲了能快速響應需求，咱們提出平臺化，經過提供各類數據處理和探索工具，讓用戶自助高效地獲取一些數據。
● 數據治理亟需規範：各條產品線的數據都進入倉庫之後，因爲需求很急迫，一些建模規範未能有效執行，致使倉庫裏數據冗餘繁雜，wiki更新維護不及時，難以清晰掌握數據倉庫裏數據總體概況。指標定義不清晰，一些數據需求人員按照本身的理解制定指標含義，結果上線後，發現不一樣的人對指標理解不一致，致使返工。
● 數據安全迫在眉睫：對數據的申請須要進行集中的審批管理，對數據的使用須要進行持續的追蹤備案，防止數據泄露。

爲了解決存在的這些問題，咱們提出了新的平臺化架構圖。平臺化架構數據流圖如圖2所示：

圖2 平臺化架構數據流圖

對比新老架構圖能夠看出，首先是多了紅色的實時數據流部分，日誌log採用flume對接Kafka消息隊列，而後使用SparkStreaming/Storm進行日誌的分析處理，處理後的結果寫入到Hbase供API服務使用。

另外，在OLAP部分，引入了Kylin做爲MOLAP處理引擎，會按期將Hive裏面的星型模型數據處理後寫入Hbase，而後Kylin對外提供數據分析服務，提供亞秒級的查詢速度。

圖中右邊是數據治理相關組件，有數據權限、數據質量、元數據等。在新的平臺化架構圖中，咱們將大數據工程平臺分爲三層，由上到下分別是應用層、工具層、基礎層，如圖3所示：

圖3 大數據工程平臺

3.1 應用層
應用層，主要面向數據開發人員和數據分析師，重點解決三類問題：
● BI報表產出速度如何加快，縮短業務方從提出數據需求到報表產出的時間週期。
● 數據治理，對公司的核心數據指標進行統必定義，對元數據進行管理，集中數據的審批流程。
● 數據流轉集中管控，數據在各個系統間的流轉統一走元數據管理平臺，能很方便排查定位問題。

爲了加快BI報表產出，咱們開發了地動儀自助報表，在數據源已經就緒的狀況下，目標是5分鐘完成一個通用報表的配置，獲得相似 excel表格、柱狀圖這種圖表效果，目前已經支持 mysql、presto 、kylin等各類數據源。另外，若是須要定製化的Dashboard報表，自助報表也支持複用一些圖表組件。

元數據管理系統

元數據對公司的全部數據信息進行管理維護，經過數據地圖，能夠看到公司數據倉庫裏的全部數據以及數據信息的變動狀況，方便用戶進行搜索查詢。指標圖書館對指標進行詳細的描述定義，並且能夠對每一個指標關聯的維度進行管理，維度表以及維度取值的描述。另外，基於元數據咱們還能夠作數據血緣關係，方便追蹤數據的上下游關係，可以快速定位排查問題。

元數據管理系統上線後，取得了如下三個成果：
● 全部表的建立修改都通過元數據系統，能夠實時清晰掌握倉庫裏的數據狀況。
● 成立了公司級別的數據委員會，統一制定公司的核心指標，各個部門能夠自定義二級指標。
● 數據的接入和流出都經過元數據系統集中管控，全部的日誌接入、mysql接入經過元數據來配置，數據申請也是走的元數據，方便集中管理運維。

3.2 工具層
工具層定位於通用工具組件的開發，爲上層應用提供能力支撐，同時解決用戶在使用大數據計算中遇到的實際困難。譬如ETL做業任務不少、追蹤排查問題比較麻煩、數據修復時間長、Hue hive查詢速度比較慢、一個sql須要等待幾分鐘。

圖4是實際工做中一個典型的數據任務鏈路圖，抽取了做業鏈路中的一部分。

圖4 數據任務鏈路圖

從圖中咱們能夠看到如下信息：
● 任務鏈路特別長，可能有6層之多；
● 任務種類多，既有mysql導入任務，也有hive-sql加工任務，還有發送郵件的任務；
● 依賴類型比較複雜，有小時級別依賴分鐘任務，也有日周月季互相依賴的任務。

對於這種複雜的數據鏈路，以前咱們採用oozie+python+shell解決，任務量有5000多個，維護困難，且遇到數據修復問題，難以迅速定位。爲了解決這些問題，咱們參考了oozie、airflow等開源軟件，自主研發了新的任務調度系統。

在新的任務調度系統上，用戶能夠自助運維，對任務進行上線或者重跑，並且能夠實時看到任務的運行日誌。之前可能要登錄到集羣機器上上查看日誌，很是麻煩。

調度系統上線後，取得了很是好的效果：
● 任務配置簡單，在圖形上簡單的拖曳便可操做。
● 提供經常使用的ETL組件，零編碼。舉個例子，之前發送數據郵件，須要本身寫腳本，目前在咱們界面只需配置收件人和數據表便可。
● 一鍵修復追溯，將排查問題修復數據的時間由一人天縮減到10分鐘。
● 集羣的資源老是緊張的，目前咱們正在作的智能調度、錯峯運行，保證高優先級任務優先運行。

Adhoc即席查詢，以前咱們使用的hue，速度比較慢。經過調研市面上的各類快速查詢工具，咱們採用了Presto和Spark SQL雙引擎，架構圖如圖5所示：

圖5 雙引擎架構圖

3.3 基礎層
基礎層偏重於集羣底層能力的建設和完善。遇到的問題集中在兩個方面：
● 任務量劇增，目前天天有一萬多JOB，形成集羣資源至關緊張，排隊嚴重。
● 集羣的數據安全須要規劃，並且因爲多個部門都在使用集羣，以前未劃分帳號和隊列，你們共同使用。　

針對這些問題，咱們在基礎層作了一些改進。

在集羣性能優化方面，經過劃分單獨的帳號隊列，資源預留，保證核心做業的執行，同時與應用層的權限管理打通，對不一樣的目錄按照用戶歸屬限制不一樣的權限。隨着集羣數據的膨脹，很多冷數據無人管理，咱們在梳理後，將冷數據遷移到AWS S3存儲。

4、案例啓示
● 傳統企業或者初創團隊如何快速落地大數據，首先要採用成熟的業界方案，大的互聯網公司的作法能夠直接借鑑，穩定的開源軟件直接使用；其次要深刻梳理公司業務，找到契合點，譬如鏈家網的房屋估價、個性化搜索、交叉報表分析。
● 面對公司業務的迅速增加，平臺化思惟是解決問題的一個法寶。首先要經過梳理用戶的流程和使用習慣，將這些服務自動化，讓用戶能自助排查一些問題；其次平臺化開發的產品，先得實實在在解決用戶痛點問題，本身願意使用，而後才能推廣給其餘人使用。
● 平臺化的產品須要梳理清楚流程，制定規範。先經過梳理調研公司的現狀，而後規範流程，固然梳理的過程比較痛苦，須要不少人配合；制定了標準之後，須要保證標準的權威性和執行力，能夠成立公司級別的數據治理委員會，發佈核心指標，保證流程的推廣執行。

TOP100全球軟件案例研究峯會已舉辦六屆，甄選全球軟件研發優秀案例，每一年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。

第六屆TOP100大會日程已經肯定，更多TOP100案例信息及日程請前往官網查閱。4天時間集中分享2017年最值得學習的100個研發案例實踐。

免費體驗票申請入口