作者 李小龍：鏈家網(wǎng)大數(shù)據(jù)部資深研發(fā)架構(gòu)師，負責(zé)大數(shù)據(jù)工具平臺化相關(guān)的工作。專注于數(shù)據(jù)倉庫、任務(wù)流調(diào)度、元數(shù)據(jù)管理、自助報表等領(lǐng)域。之前在百度從事了四年的數(shù)據(jù)倉庫和工具平臺的研發(fā)工作。

導(dǎo)讀：鏈家網(wǎng)大數(shù)據(jù)部門負責(zé)收集加工公司各產(chǎn)品線的數(shù)據(jù)，并為鏈家集團各業(yè)務(wù)部門提供數(shù)據(jù)支撐。本文分享鏈家網(wǎng)大數(shù)據(jù)部成立后，在發(fā)展變革中遇到的一些問題和挑戰(zhàn)，架構(gòu)團隊是如何構(gòu)建一站式的數(shù)據(jù)平臺來解決獲取數(shù)據(jù)的效率問題，如何構(gòu)建多層次系統(tǒng)來組建大數(shù)據(jù)架構(gòu)體系。重點介紹團隊早期作為數(shù)據(jù)報表支持者，向當下數(shù)據(jù)平臺方轉(zhuǎn)變的這一歷程，通過對數(shù)據(jù)處理流程的梳理，構(gòu)建一體化的數(shù)據(jù)接入/計算/展示的開放平臺，提升數(shù)據(jù)運轉(zhuǎn)效率，快速滿足集團內(nèi)數(shù)據(jù)需求。

一、背景簡介

鏈家網(wǎng)自2014年成立后，全面推進020戰(zhàn)略，打造線上線下房產(chǎn)服務(wù)閉環(huán)，公司業(yè)務(wù)迅速增長，覆蓋全國28個地區(qū)，門店數(shù)量超過8000家。隨著鏈家集團積累數(shù)據(jù)的不斷增多，在2015年專門成立了大數(shù)據(jù)部，推進集團內(nèi)各公司數(shù)據(jù)資產(chǎn)的整合，以數(shù)據(jù)驅(qū)動公司業(yè)務(wù)的發(fā)展。

鏈家將房地產(chǎn)交易大數(shù)據(jù)分為物的數(shù)據(jù)、人的數(shù)據(jù)、行為數(shù)據(jù)三大塊來進行研究。

●物的數(shù)據(jù)主要是構(gòu)建了全國的樓盤字典，擁有專業(yè)的攝影測量團隊實地勘測，收錄了7000萬套房屋的詳細信息，包括小區(qū)周邊、人文素養(yǎng)等等。

●人的數(shù)據(jù)，包括買家、業(yè)主、經(jīng)紀人三方，目前在全國有13萬經(jīng)紀人，對經(jīng)紀人的背景、從業(yè)年限、資歷、專業(yè)能力、歷史行為有詳細記錄，給客戶更加精準的參考。目前鏈家網(wǎng)服務(wù)的買家和賣家超過兩千多萬，對用戶進行畫像，然后推薦更加合適的房屋。

●行為數(shù)據(jù)，包括線上行為和多樣的線下行為，譬如線上的瀏覽日志，線下的看房行程等。

通過分析這些數(shù)據(jù)，找到與業(yè)務(wù)的結(jié)合點，目前大數(shù)據(jù)在鏈家網(wǎng)具體的應(yīng)用場景有房屋估價、智能推薦、房客圖譜、BI報表。

二、大數(shù)據(jù)從0到1的架構(gòu)落地

大數(shù)據(jù)部成立以后，借鑒業(yè)界成熟的數(shù)據(jù)倉庫方案，設(shè)計的早期架構(gòu)圖如圖1所示：

圖1 數(shù)據(jù)倉庫早期架構(gòu)

在這個階段我們主要做了三件事：

●搭建hadoop集群，初期只有10多臺機器，隨著業(yè)務(wù)的發(fā)展，集群規(guī)模也在不斷增長。

●采用HIVE構(gòu)建數(shù)據(jù)倉庫，數(shù)據(jù)倉庫里的數(shù)據(jù)來源于業(yè)務(wù)方的mysql數(shù)據(jù)庫和log日志。

●定制化報表開發(fā)，按照業(yè)務(wù)方的需求，case by case做一些BI報表展示，滿足業(yè)務(wù)方對數(shù)據(jù)的分析。

這個架構(gòu)簡單清晰，這樣做有三個好處：

●使用開源的組件，方便擴展和運維；

●采用業(yè)界成熟的數(shù)據(jù)倉庫方案，數(shù)據(jù)倉庫分層模型設(shè)計；

●有利于技術(shù)人員培養(yǎng)，技術(shù)團隊在成長初期技術(shù)選型需要考慮市場上人員情況，所以選擇了使用范圍廣的技術(shù)。

具體講講HIVE數(shù)據(jù)倉庫的模型，該模型一共分為5層。

●最下面是STG層，用來存儲源數(shù)據(jù)，保持與數(shù)據(jù)源完全一致；

●第二層是ODS層，會進行數(shù)據(jù)清理等工作，譬如不同業(yè)務(wù)系統(tǒng)的城市編碼不一致，有的001代表北京，有的110代表北京，在ODS層進行維度編碼的統(tǒng)一處理。還有不同業(yè)務(wù)系統(tǒng)的金錢單位不一致，有的是元、有的是分，在此統(tǒng)一采用分為單位，保留兩位小數(shù)；

●最上面是報表層，根據(jù)業(yè)務(wù)需求進行加工處理，產(chǎn)出報表數(shù)據(jù)。至于數(shù)據(jù)倉庫遵循的范式結(jié)構(gòu)，目前沒有嚴格一致地規(guī)范，星型模型和雪花模型都有采用。

早期的大數(shù)據(jù)架構(gòu)落地后，支撐了將近一年時間，從2015年初到2016年初，取得了不錯的效果。

●收集匯總了集團內(nèi)各個分公司、各條產(chǎn)品線的數(shù)據(jù)，便于交叉分析。通過對比分析數(shù)據(jù)，能幫助業(yè)務(wù)系統(tǒng)更好的發(fā)展。

●支撐集團內(nèi)大部分報表需求，幫助運營人員改進決策，數(shù)據(jù)驅(qū)動。 巧婦難為無米之炊，當數(shù)據(jù)倉庫積累了大量歷史數(shù)據(jù)，數(shù)據(jù)挖掘的同學(xué)就能進行深度分析。

三、大數(shù)據(jù)平臺化體系的建設(shè)

為什么要做平臺化？

主要原因還是隨著公司業(yè)務(wù)的快速發(fā)展，數(shù)據(jù)需求迅速增多，早期的大數(shù)據(jù)架構(gòu)遇到一些新挑戰(zhàn)。

●數(shù)據(jù)需求快速增長：鏈家業(yè)務(wù)增長到全國多個城市，各個城市的報表需求很多，而且由于各個地方的政策不太一樣，報表需求也有所差異，此外還有大量的臨時統(tǒng)計數(shù)據(jù)需求。為了能快速響應(yīng)需求，我們提出平臺化，通過提供各種數(shù)據(jù)處理和探索工具，讓用戶自助高效地獲取一些數(shù)據(jù)。

●數(shù)據(jù)治理亟需規(guī)范：各條產(chǎn)品線的數(shù)據(jù)都進入倉庫以后，由于需求很急迫，一些建模規(guī)范未能有效執(zhí)行，導(dǎo)致倉庫里數(shù)據(jù)冗余繁雜，wiki更新維護不及時，難以清晰掌握數(shù)據(jù)倉庫里數(shù)據(jù)整體概況。指標定義不清晰，一些數(shù)據(jù)需求人員按照自己的理解制定指標含義，結(jié)果上線后，發(fā)現(xiàn)不同的人對指標理解不一致，導(dǎo)致返工。

●數(shù)據(jù)安全迫在眉睫：對數(shù)據(jù)的申請需要進行集中的審批管理，對數(shù)據(jù)的使用需要進行持續(xù)的追蹤備案，防止數(shù)據(jù)泄露。

為了解決存在的這些問題，我們提出了新的平臺化架構(gòu)圖。平臺化架構(gòu)數(shù)據(jù)流圖如圖2所示：

圖2 平臺化架構(gòu)數(shù)據(jù)流圖

對比新老架構(gòu)圖可以看出，首先是多了紅色的實時數(shù)據(jù)流部分，日志log采用flume對接Kafka消息隊列，然后使用SparkStreaming/Storm進行日志的分析處理，處理后的結(jié)果寫入到Hbase供API服務(wù)使用。

另外，在OLAP部分，引入了Kylin作為MOLAP處理引擎，會定期將Hive里面的星型模型數(shù)據(jù)處理后寫入Hbase，然后Kylin對外提供數(shù)據(jù)分析服務(wù)，提供亞秒級的查詢速度。

圖中右邊是數(shù)據(jù)治理相關(guān)組件，有數(shù)據(jù)權(quán)限、數(shù)據(jù)質(zhì)量、元數(shù)據(jù)等。在新的平臺化架構(gòu)圖中，我們將大數(shù)據(jù)工程平臺分為三層，由上到下分別是應(yīng)用層、工具層、基礎(chǔ)層，如圖3所示：

圖3 大數(shù)據(jù)工程平臺

3.1應(yīng)用層

應(yīng)用層，主要面向數(shù)據(jù)開發(fā)人員和數(shù)據(jù)分析師，重點解決三類問題：

●BI報表產(chǎn)出速度如何加快，縮短業(yè)務(wù)方從提出數(shù)據(jù)需求到報表產(chǎn)出的時間周期。

●數(shù)據(jù)治理，對公司的核心數(shù)據(jù)指標進行統(tǒng)一定義，對元數(shù)據(jù)進行管理，集中數(shù)據(jù)的審批流程。

●數(shù)據(jù)流轉(zhuǎn)集中管控，數(shù)據(jù)在各個系統(tǒng)間的流轉(zhuǎn)統(tǒng)一走元數(shù)據(jù)管理平臺，能很方便排查定位問題。

為了加快BI報表產(chǎn)出，我們開發(fā)了地動儀自助報表，在數(shù)據(jù)源已經(jīng)就緒的情況下，目標是5分鐘完成一個通用報表的配置，得到類似 excel表格、柱狀圖這種圖表效果，目前已經(jīng)支持 mysql、presto 、kylin等各種數(shù)據(jù)源。另外，如果需要定制化的Dashboard報表，自助報表也支持復(fù)用一些圖表組件。

元數(shù)據(jù)管理系統(tǒng)

元數(shù)據(jù)對公司的所有數(shù)據(jù)信息進行管理維護，通過數(shù)據(jù)地圖，可以看到公司數(shù)據(jù)倉庫里的所有數(shù)據(jù)以及數(shù)據(jù)信息的變更情況，方便用戶進行搜索查詢。指標圖書館對指標進行詳細的描述定義，而且可以對每個指標關(guān)聯(lián)的維度進行管理，維度表以及維度取值的描述。另外，基于元數(shù)據(jù)我們還可以做數(shù)據(jù)血緣關(guān)系，方便追蹤數(shù)據(jù)的上下游關(guān)系，能夠快速定位排查問題。

元數(shù)據(jù)管理系統(tǒng)上線后，取得了以下三個成果：

●所有表的創(chuàng)建修改都經(jīng)過元數(shù)據(jù)系統(tǒng)，可以實時清晰掌握倉庫里的數(shù)據(jù)情況。

●成立了公司級別的數(shù)據(jù)委員會，統(tǒng)一制定公司的核心指標，各個部門可以自定義二級指標。

●數(shù)據(jù)的接入和流出都通過元數(shù)據(jù)系統(tǒng)集中管控，所有的日志接入、mysql接入通過元數(shù)據(jù)來配置，數(shù)據(jù)申請也是走的元數(shù)據(jù)，方便集中管理運維。

3.2工具層

工具層定位于通用工具組件的開發(fā)，為上層應(yīng)用提供能力支撐，同時解決用戶在使用大數(shù)據(jù)計算中遇到的實際困難。譬如ETL作業(yè)任務(wù)很多、追蹤排查問題比較麻煩、數(shù)據(jù)修復(fù)時間長、Hue hive查詢速度比較慢、一個sql需要等待幾分鐘。

圖4是實際工作中一個典型的數(shù)據(jù)任務(wù)鏈路圖，抽取了作業(yè)鏈路中的一部分。

圖4 數(shù)據(jù)任務(wù)鏈路圖

從圖中我們可以看到以下信息：

●任務(wù)鏈路特別長，可能有6層之多；

●任務(wù)種類多，既有mysql導(dǎo)入任務(wù)，也有hive-sql加工任務(wù)，還有發(fā)送郵件的任務(wù)；

●依賴類型比較復(fù)雜，有小時級別依賴分鐘任務(wù)，也有日周月季互相依賴的任務(wù)。

對于這種復(fù)雜的數(shù)據(jù)鏈路，之前我們采用oozie+python+shell解決，任務(wù)量有5000多個，維護困難，且遇到數(shù)據(jù)修復(fù)問題，難以迅速定位。為了解決這些問題，我們參考了oozie、airflow等開源軟件，自主研發(fā)了新的任務(wù)調(diào)度系統(tǒng)。

在新的任務(wù)調(diào)度系統(tǒng)上，用戶可以自助運維，對任務(wù)進行上線或者重跑，而且可以實時看到任務(wù)的運行日志。以前可能要登陸到集群機器上上查看日志，非常麻煩。

調(diào)度系統(tǒng)上線后，取得了非常好的效果：

●任務(wù)配置簡單，在圖形上簡單的拖曳即可操作。

●提供常用的ETL組件，零編碼。舉個例子，以前發(fā)送數(shù)據(jù)郵件，需要自己寫腳本，目前在我們界面只需配置收件人和數(shù)據(jù)表即可。

●一鍵修復(fù)追溯，將排查問題修復(fù)數(shù)據(jù)的時間由一人天縮減到10分鐘。

●集群的資源總是緊張的，目前我們正在做的智能調(diào)度、錯峰運行，保證高優(yōu)先級任務(wù)優(yōu)先運行。

Adhoc即席查詢，之前我們使用的hue，速度比較慢。通過調(diào)研市面上的各種快速查詢工具，我們采用了Presto和Spark SQL雙引擎，架構(gòu)圖如圖5所示：

圖5 雙引擎架構(gòu)圖

3.3基礎(chǔ)層

基礎(chǔ)層偏重于集群底層能力的建設(shè)和完善。遇到的問題集中在兩個方面：

●任務(wù)量劇增，目前每天有一萬多JOB，造成集群資源相當緊張，排隊嚴重。

●集群的數(shù)據(jù)安全需要規(guī)劃，而且由于多個部門都在使用集群，之前未劃分賬號和隊列，大家共同使用。

針對這些問題，我們在基礎(chǔ)層做了一些改進。

在集群性能優(yōu)化方面，通過劃分單獨的賬號隊列，資源預(yù)留，保證核心作業(yè)的執(zhí)行，同時與應(yīng)用層的權(quán)限管理打通，對不同的目錄按照用戶歸屬限制不同的權(quán)限。隨著集群數(shù)據(jù)的膨脹，不少冷數(shù)據(jù)無人管理，我們在梳理后，將冷數(shù)據(jù)遷移到AWS S3存儲。

四、案例啟示

●傳統(tǒng)企業(yè)或者初創(chuàng)團隊如何快速落地大數(shù)據(jù)，首先要采用成熟的業(yè)界方案，大的互聯(lián)網(wǎng)公司的做法可以直接借鑒，穩(wěn)定的開源軟件直接使用；其次要深入梳理公司業(yè)務(wù)，找到契合點，譬如鏈家網(wǎng)的房屋估價、個性化搜索、交叉報表分析。

●面對公司業(yè)務(wù)的迅速增長，平臺化思維是解決問題的一個法寶。首先要通過梳理用戶的流程和使用習(xí)慣，將這些服務(wù)自動化，讓用戶能自助排查一些問題；其次平臺化開發(fā)的產(chǎn)品，先得實實在在解決用戶痛點問題，自己愿意使用，然后才能推廣給其他人使用。

●平臺化的產(chǎn)品需要梳理清楚流程，制定規(guī)范。先通過梳理調(diào)研公司的現(xiàn)狀，然后規(guī)范流程，當然梳理的過程比較痛苦，需要很多人配合；制定了標準以后，需要保證標準的權(quán)威性和執(zhí)行力，可以成立公司級別的數(shù)據(jù)治理委員會，發(fā)布核心指標，保證流程的推廣執(zhí)行。

TOP100全球軟件案例研究峰會已舉辦六屆，甄選全球軟件研發(fā)優(yōu)秀案例，每年參會者達2000人次。包含產(chǎn)品、團隊、架構(gòu)、運維、大數(shù)據(jù)、人工智能等多個技術(shù)專場，現(xiàn)場學(xué)習(xí)谷歌、微軟、騰訊、阿里、百度等一線互聯(lián)網(wǎng)企業(yè)的最新研發(fā)實踐。

更多TOP100案例信息及日程請前往[官網(wǎng)]查閱。4天時間集中分享2017年最值得學(xué)習(xí)的100個研發(fā)案例實踐。免費體驗票申請入口