本篇文章內容來自2016年TOP100summit 鏈家網大資料部資深研發架構師李小龍的案例分享。
編輯：Cynthia
李小龍：鏈家網大資料部資深研發架構師，負責大資料工具平臺化相關的工作。專注於資料倉儲、任務流排程、後設資料管理、自助報表等領域。之前在百度從事了四年的資料倉儲和工具平臺的研發工作。
導讀：鏈家網大資料部門負責收集加工公司各產品線的資料，併為鏈家集團各業務部門提供資料支撐。本文分享鏈家網大資料部成立後，在發展變革中遇到的一些問題和挑戰，架構團隊是如何構建一站式的資料平臺來解決獲取資料的效率問題，如何構建多層次系統來組建大資料架構體系。重點介紹團隊早期作為資料包表支持者，向當下資料平臺方轉變的這一歷程，通過對資料處理流程的梳理，構建一體化的資料接入/計算/展示的開放平臺，提升資料運轉效率，快速滿足集團內資料需求。
一、背景簡介
鏈家網自2014年成立後，全面推進020戰略，打造線上線下房產服務閉環，公司業務迅速增長，覆蓋全國28個地區，門店數量超過8000家。隨著鏈家集團積累資料的不斷增多，在2015年專門成立了大資料部，推進集團內各公司資料資產的整合，以資料驅動公司業務的發展。
鏈家將房地產交易大資料分為物的資料、人的資料、行為資料三大塊來進行研究。
● 物的資料主要是構建了全國的樓盤字典，擁有專業的攝影測量團隊實地勘測，收錄了7000萬套房屋的詳細資訊，包括小區周邊、人文素養等等。
● 人的資料，包括買家、業主、經紀人三方，目前在全國有13萬經紀人，對經紀人的背景、從業年限、資歷、專業能力、歷史行為有詳細記錄，給客戶更加精準的參考。目前鏈家網服務的買家和賣家超過兩千多萬，對使用者進行畫像，然後推薦更加合適的房屋。
● 行為資料，包括線上行為和多樣的線下行為，譬如線上的瀏覽日誌，線下的看房行程等。
通過分析這些資料，找到與業務的結合點，目前大資料在鏈家網具體的應用場景有房屋估價、智慧推薦、房客圖譜、BI報表。
二、大資料從0到1的架構落地
大資料部成立以後，借鑑業界成熟的資料倉儲方案，設計的早期架構圖如圖1所示：
圖1 資料倉儲早期架構
在這個階段我們主要做了三件事：
● 搭建hadoop叢集，初期只有10多臺機器，隨著業務的發展，叢集規模也在不斷增長。
● 採用HIVE構建資料倉儲，資料倉儲裡的資料來源於業務方的mysql資料庫和log日誌。
● 定製化報表開發，按照業務方的需求，case by case做一些BI報表展示，滿足業務方對資料的分析。
這個架構簡單清晰，這樣做有三個好處：
● 使用開源的元件，方便擴充套件和運維；
● 採用業界成熟的資料倉儲方案，資料倉儲分層模型設計；
● 有利於技術人員培養，技術團隊在成長初期技術選型需要考慮市場上人員情況，所以選擇了使用範圍廣的技術。
具體講講HIVE資料倉儲的模型，該模型一共分為5層。
● 最下面是STG層，用來儲存源資料，保持與資料來源完全一致；
● 第二層是ODS層，會進行資料清理等工作，譬如不同業務系統的城市編碼不一致，有的001代表北京，有的110代表北京，在ODS層進行維度編碼的統一處理。還有不同業務系統的金錢單位不一致，有的是元、有的是分，在此統一採用分為單位，保留兩位小數；
● 最上面是報表層，根據業務需求進行加工處理，產出報表資料。至於資料倉儲遵循的正規化結構，目前沒有嚴格一致地規範，星型模型和雪花模型都有采用。
早期的大資料架構落地後，支撐了將近一年時間，從2015年初到2016年初，取得了不錯的效果。
● 收集彙總了集團內各個分公司、各條產品線的資料，便於交叉分析。通過對比分析資料，能幫助業務系統更好的發展。
● 支撐集團內大部分報表需求，幫助運營人員改進決策，資料驅動。 巧婦難為無米之炊，當資料倉儲積累了大量歷史資料，資料探勘的同學就能進行深度分析。
三、大資料平臺化體系的建設
為什麼要做平臺化？
主要原因還是隨著公司業務的快速發展，資料需求迅速增多，早期的大資料架構遇到一些新挑戰。
● 資料需求快速增長：鏈家業務增長到全國多個城市，各個城市的報表需求很多，而且由於各個地方的政策不太一樣，報表需求也有所差異，此外還有大量的臨時統計資料需求。為了能快速響應需求，我們提出平臺化，通過提供各種資料處理和探索工具，讓使用者自助高效地獲取一些資料。
● 資料治理亟需規範：各條產品線的資料都進入倉庫以後，由於需求很急迫，一些建模規範未能有效執行，導致倉庫裡資料冗餘繁雜，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儲存。
四、案例啟示
● 傳統企業或者初創團隊如何快速落地大資料，首先要採用成熟的業界方案，大的網際網路公司的做法可以直接借鑑，穩定的開源軟體直接使用；其次要深入梳理公司業務，找到契合點，譬如鏈家網的房屋估價、個性化搜尋、交叉報表分析。
● 面對公司業務的迅速增長，平臺化思維是解決問題的一個法寶。首先要通過梳理使用者的流程和使用習慣，將這些服務自動化，讓使用者能自助排查一些問題；其次平臺化開發的產品，先得實實在在解決使用者痛點問題，自己願意使用，然後才能推廣給其他人使用。
● 平臺化的產品需要梳理清楚流程，制定規範。先通過梳理調研公司的現狀，然後規範流程，當然梳理的過程比較痛苦，需要很多人配合；制定了標準以後，需要保證標準的權威性和執行力，可以成立公司級別的資料治理委員會，釋出核心指標，保證流程的推廣執行。
TOP100全球軟體案例研究峰會已舉辦六屆，甄選全球軟體研發優秀案例，每年參會者達2000人次。包含產品、團隊、架構、運維、大資料、人工智慧等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線網際網路企業的最新研發實踐。
第六屆TOP100大會日程已經確定，更多TOP100案例資訊及日程請前往官網查閱。4天時間集中分享2017年最值得學習的100個研發案例實踐。
免費體驗票申請入口：www.top100summit.com/?qd=juejin