Apache Kylin在綠城客戶畫像系統中的實踐
前言
作為國內知名的房地產開發商，綠城經過24年的發展，已為全國25萬戶、80萬人營造了美麗家園，並將以“理想生活綜合服務提供商”為目標，持續為客戶營造高品質的房產品和生活服務。
2017年，綠城理想生活集團成立，圍繞客戶全生活鏈、房屋全生命週期，為客戶提供從買房子到房屋的保養維護，再到業主全方位的生活服務。為此構建了綠城+App生活服務平臺、房產營銷數字化平臺及房屋4S服務平臺，這些系統的構建為業主購房及生活服務提供了極大的便利，部分系統不僅開放給綠城客戶、業主使用，同時也服務於非綠城的客戶。通過一整套垂直行業的使用者畫像系統構建並使用Apache Kylin加速主要資料服務，有效提升了網際網路廣告推廣、營銷服務的效率。
一、綠城客戶畫像系統的背景
房產品的營造和線下銷售是當前綠城的主營業務，為有效提升服務質量、管理效能，降低營銷費用，實現客戶服務智慧化、銷售行為自動化、成本管理合理化，綠城積極擁抱網際網路，於2015年開始了數字化營銷（Digital Marketing）的探索和研究，通過+網際網路創新營銷業務。
經過2年的探索和模式驗證之後，2017年綠城成立了專門的大資料團隊，圍繞營銷全過程和客戶全生命週期， 構建了房地產行業首個全閉環的“房產營銷數字化平臺”，服務於營銷找客到成交回款全過程，如下圖所示:
圖1 綠城房產營銷數字化平臺
在“房產營銷數字化平臺”中，精準營銷和智慧案場為營銷線最核心的兩個系統，它們以廣告投放、客戶資料資產管理、經營指標分析為基礎，延展出集合營銷知識分享與學習、營銷與轉化工具、第三方供應商為一體的網際網路平臺，服務於房地產市場營銷產業鏈生態圈，為Marketing階段的客戶獲取提供了一站式程式化解決方案。另外接業綠城、掌上銷售等系統則為後續的Sales環節提供數字化服務。
精準營銷系統和智慧案場系統，基於DMP（Data Management Platform，資料管理平臺）的資料分析和處理能力支撐和流轉起所有業務邏輯，一方面，綠城DMP系統通過積累營銷投放過程中的迴流資料，另外一方面又採集置業綠城、全民營銷系統（綠粉匯）、掌上銷售系統中的埋點行為資料及資料庫資料。通過上述種種方式為數字化營銷建立更為準確優化的策略，從而真正做到“資料驅動營銷”。綠城DMP的資料包含第一、第二和第三方資料：
第一方資料，即完全自有的資料。企業自身的CRM系統資料、網站和APP等運營活動的應用資料；
第二方資料，主要包括程式化廣告投放過程中的交易資料；
第三方資料，主要為BAT資料、運營商資料等。
綠城DMP整體的業務架構圖如下：
圖2： 綠城DMP與系統間的邏輯架構
DMP作為服務於Marketing的核心工具，客戶畫像發揮著極其重要的作用。客戶畫像依賴於DMP的標籤管理、使用者歸一化以及營銷相關的客戶資料，它為房子的營銷推廣提供決策支援和依據。
另外一方面，營銷相關運營活動也需要畫像系統支援。營銷引擎基於使用者畫像系統，為精準營銷、智慧案場系統提供統一的廣告投放服務。
二、客戶畫像與Apache Kylin的結合
如前所述，客戶畫像服務於Marketing，其核心的業務流程可以用下圖表示：
圖3 客戶畫像的核心邏輯
通過DMP進行資料的採集、融合分析、歸一化處理，再基於行業標籤，為精準營銷系統提供精準的人群畫像，並投放到各類媒體及網站，實現對於受眾的精準觸達。
2015~2016年，綠城大資料平臺中的資料主要通過Hive + HBase進行儲存以及分析計算，後臺的資料服務尤其是畫像服務，均是基於HBase的Java API開發，那時基本能滿足業務秒級的響應需求。但經歷2017年的業務高速發展之後，隨著渠道及合作方的增多，資料的體量和維度的增加了數十倍，畫像等資料服務的響應速度逐漸降至5秒甚至30秒，部分業務查詢甚至超過了1min，而且資料來源頭繁雜、維度眾多，需要體系化地管理。為解決這個問題，綠城大資料團隊於17年上半年進行標籤體系建設形成共13大類、8000+細類的多維度標籤，客戶畫像的構建，便依賴於這個豐富成熟的標籤體系。
日均300G以上資料會沉澱在大資料平臺中，資料體量的增加導致效能瓶頸明顯，經過多輪測試、綜合對比分析Apache Kudu，Presto，Druid以及Apache Kylin之後，最終選擇Apache Kylin作為OLAP工具，最終優化並解決了資料服務查詢的效能問題。選擇Apache Kylin的主要原因有以下幾點：
成熟度來講：Apache Kylin和Druid 更為成熟（參照穩定性、效能、社群活躍度等因素）
查詢效率來講：Druid ≈ Apache Kylin，優於其他（主要業務場景）
實用和便捷性：Apache Kylin搭建和使用均較為便捷（同時也是華人的頂級開源專案）
另外，Apache Kylin還有以下優點：
Apache Kylin進行預計算，空間換時間，通過預定義、計算Cube的方式提升查詢的速度和效能，同時，查詢的效能隨業務的增長也不會受到影響；
資料管理及同步方便。預計算、構建Cube、資料管理都可基於Apache Kylin自行管理；有開放的API可以方便、快速地對接內部資料處理流程、與排程系統打通。
綠城大資料平臺每日增量構建數百GB的Cube，構建的時間從幾小時到十幾小時不等，之前後臺較慢的查詢時間範圍是從十幾到幾十秒，使用Apache Kylin後則基本都在1-2秒內即可予以響應。最終優化之後的客戶畫像構建流程如下：
圖4 客戶畫像構建流程
其中，業務系統資料和Log資料通過採集、傳輸後，基於Spark進行初步處理，之後包含埋點、運營活動等的結果資料會寫入HDFS以及HBase中。一部分客戶、樓盤的資料報告和分析服務通過Hive及Spark進行支撐和輸出，而主要的資料服務則通過Apache Kylin進行構建。
在Kylin中，對於小資料量的Cube，或者經常需要全表更新的Cube，使用全量構建需要更少的運維精力，以少量的重複計算降低生產環境中的維護複雜度。而對於大資料量的Cube，例如對於一個包含兩年曆史資料的Cube，如果需要每天更新，那麼每天為了新資料而去重複計算過去兩年的資料就會變得非常浪費，而在這種情況下需要考慮使用增量構建。
因為綠城大資料平臺的資料每天按日更新，並且日均資料量都會在百G以上，所以我們用到了Apache Kylin的增量構建Cube。Kylin在Web介面上提供了手動構建Cube的操作，此外，Apache Kylin也提供了Rest API進行增量構建。在綠城客戶畫像系統中，70%的自動化觸發增量構建都基於Rest API完成。
圖5 Apache Kylin構建Cube的Web頁面
我們基於Apache Kylin構建好的資料服務，又通過開源工具Superset進行客戶畫像中標籤資料的視覺化分析展示，如下圖：
圖6 基於Superset的標籤畫像展示
大資料視覺化工具的選擇非常豐富。在對比了開源工具Superset、Zeppelin以及商業工具FineBI後，最終採用Airbnb開源的Superset（曾用名Caravel）的主要原因如下：
資料安全性、許可權控制，僅Superset有表檢索的許可權控制
圖表多樣性，Superset擁有多達30張以上的圖表，多表的聯動性-filter支援多表聯動
資料庫多元性，Superset既支援關係型資料庫，也支援像Apache Kylin這樣的大資料框架
社群活躍度相對更高
Superset作為一款開源的BI工具，能夠滿足我們對於標籤畫像聯動分析的需求，節省了前端、UI的開發資源
客戶畫像依賴的資料、後臺計算引擎以及標籤都構建完成後，綠城客戶畫像的一瞥如下圖所示：
三、未來客戶畫像系統的展望
綠城客戶畫像系統目前只服務於房產營銷，隨著房屋4S、園區商業、綠城+App生活服務平臺的日益成熟，畫像系統將融合各業務系統資料，完成客戶全生活鏈使用者畫像的建設，同時客戶畫像會融入知識圖譜，建立業主與業主、業主與房子之間的連線，從而形成一套更加全面、視覺化的使用者畫像系統。綠城大資料團隊將積極擁抱開源、擁抱網際網路，擁抱變化，持續用技術和資料驅動綠城各條線的業務發展。
作者介紹：
秦海龍，綠城理想生活科技有限公司大資料平臺負責人。Java語言、Scala語言，Hadoop生態、Spark大資料處理技術愛好者。
公眾號推薦：
公眾號：VOA英語每日一聽
微訊號: voahk01
可長按掃碼關注，謝謝