文 | 呂毅，鏈家網(wǎng)平臺(tái)架構(gòu)師

鏈家網(wǎng)于2015年成立大數(shù)據(jù)部門(mén)，開(kāi)始構(gòu)建基于Hadoop的技術(shù)體系，初期大數(shù)據(jù)部門(mén)以運(yùn)營(yíng)數(shù)據(jù)報(bào)表需求、公司核心指標(biāo)需求為主。隨著2015年鏈家網(wǎng)發(fā)力線上業(yè)務(wù)，toB與toC業(yè)務(wù)齊頭并進(jìn)，數(shù)據(jù)需求量激增的情況也隨之在2016年突顯，數(shù)據(jù)量增至PB級(jí)。我們開(kāi)始思考如何改變現(xiàn)狀，如何高效支撐未來(lái)可預(yù)見(jiàn)的眾多數(shù)據(jù)需求。

基于ROLAP技術(shù)的報(bào)表平臺(tái)

鏈家網(wǎng)大數(shù)據(jù)部門(mén)成立之初，面對(duì)著零散的數(shù)據(jù)需求，最早期的辦法是配置定時(shí)任務(wù)跑腳本，將結(jié)果通過(guò)郵件方式發(fā)送給需求方。2015年期間，隨著運(yùn)營(yíng)數(shù)據(jù)需求的增加、希望查閱數(shù)據(jù)的人員增多，郵件的方式不方便人員間信息傳遞，并且查找歷史數(shù)據(jù)也不方便，在技術(shù)上也因數(shù)據(jù)相關(guān)人太多導(dǎo)致郵件發(fā)送阻塞。

因此，考慮到運(yùn)營(yíng)數(shù)據(jù)需求、公司核心指標(biāo)需求相對(duì)固定，并且維度可枚舉，特在2015年基于ROLAP技術(shù)方案，搭建了早期的報(bào)表系統(tǒng)。

圖1 鏈家網(wǎng)早期的報(bào)表系統(tǒng)

早期的報(bào)表系統(tǒng)，由數(shù)據(jù)開(kāi)發(fā)工程師提交數(shù)據(jù)任務(wù)，通過(guò)配置Oozie定時(shí)任務(wù)，定時(shí)的基于Hive數(shù)據(jù)做ETL過(guò)程，將報(bào)表系統(tǒng)所需的數(shù)據(jù)推入關(guān)系型數(shù)據(jù)庫(kù)(MySQL)中。該系統(tǒng)從接收需求到報(bào)表系統(tǒng)里看到數(shù)據(jù)，需要比較長(zhǎng)的一段時(shí)間過(guò)程，涵蓋過(guò)程如下：

1. 溝通需求，由數(shù)據(jù)開(kāi)發(fā)工程師理解數(shù)據(jù)需求;
2. 對(duì)接數(shù)據(jù)，將數(shù)據(jù)源對(duì)接入HDFS;
3. 構(gòu)造數(shù)據(jù)，將數(shù)據(jù)加工處理到Hive中，逐層由STG到ODG，再到DW層;
4. 數(shù)據(jù)任務(wù)，數(shù)據(jù)開(kāi)發(fā)工程師根據(jù)需求方需求、DW層數(shù)據(jù)，編寫(xiě)基于Oozie的調(diào)度任務(wù);
5. 發(fā)布任務(wù)，將Oozie調(diào)度任務(wù)發(fā)布到線上，定時(shí)執(zhí)行，數(shù)據(jù)運(yùn)行結(jié)果將被推送到MySQL;
6. 數(shù)據(jù)展示，由自研的報(bào)表系統(tǒng)，根據(jù)需求方展示需求，添加維度篩選能力，開(kāi)發(fā)一些對(duì)結(jié)果數(shù)據(jù)的再加工程序，部署上線。

流程過(guò)程較長(zhǎng)，角色間傳遞信息較多，前后依賴太強(qiáng)，都是制約當(dāng)時(shí)報(bào)表系統(tǒng)快速產(chǎn)出數(shù)據(jù)的根本問(wèn)題。該系統(tǒng)在之后的迭代中，通過(guò)增加選取MySQL數(shù)據(jù)、自助勾選維度，實(shí)現(xiàn)了自助報(bào)表系統(tǒng)，命名為“地動(dòng)儀”并服務(wù)至今。然而，流程長(zhǎng)、傳遞信息多、依賴強(qiáng)的問(wèn)題依舊沒(méi)有根本解決，對(duì)于逐漸增多的數(shù)據(jù)分析需求，更不能及時(shí)響應(yīng)。

地動(dòng)儀在一定程度上解決了郵件方式的弊端，提供Web界面化的查詢，支持歷史查詢和多人使用。但對(duì)于非訂制化需求、數(shù)據(jù)探索需求、數(shù)據(jù)分析需求支持的力度并不好。我們開(kāi)始規(guī)劃更好的數(shù)據(jù)分析平臺(tái)服務(wù)。

鏈家網(wǎng)大數(shù)據(jù)平臺(tái)的誕生

大數(shù)據(jù)工作劃分，通常分為大數(shù)據(jù)應(yīng)用、大數(shù)據(jù)平臺(tái)兩大部分。常見(jiàn)的大數(shù)據(jù)應(yīng)用形態(tài)有數(shù)據(jù)挖掘、數(shù)據(jù)分析、個(gè)性化推薦、數(shù)據(jù)報(bào)表等，大數(shù)據(jù)應(yīng)用形式相對(duì)更多樣，可以根據(jù)業(yè)務(wù)不同而有具體的大數(shù)據(jù)應(yīng)用產(chǎn)品。大數(shù)據(jù)平臺(tái)，在一家公司中則應(yīng)相對(duì)統(tǒng)一，以方便做好公司統(tǒng)一的數(shù)據(jù)接入規(guī)范、統(tǒng)一的數(shù)據(jù)管理機(jī)制、統(tǒng)一的數(shù)據(jù)處理能力等，做好數(shù)據(jù)管控。

因此，在對(duì)歷史大數(shù)據(jù)架構(gòu)進(jìn)行梳理后，鏈家網(wǎng)將原有大數(shù)據(jù)部門(mén)工作細(xì)化，將大數(shù)據(jù)應(yīng)用交由業(yè)務(wù)線團(tuán)隊(duì)或其他技術(shù)團(tuán)隊(duì)承擔(dān)，便于業(yè)務(wù)線開(kāi)展多樣化的數(shù)據(jù)工作，同時(shí)將大數(shù)據(jù)部門(mén)聚焦于構(gòu)建公司統(tǒng)一的大數(shù)據(jù)平臺(tái)，負(fù)責(zé)公司內(nèi)各部門(mén)數(shù)據(jù)相關(guān)需求的統(tǒng)一規(guī)劃與實(shí)現(xiàn)，建設(shè)公司統(tǒng)一的數(shù)據(jù)倉(cāng)庫(kù)與數(shù)據(jù)服務(wù)。至此，鏈家網(wǎng)大數(shù)據(jù)平臺(tái)團(tuán)隊(duì)誕生，我們開(kāi)始著手建立平臺(tái)，支持好未來(lái)公司內(nèi)對(duì)數(shù)據(jù)使用上的各類需求。

在2016年中期，通過(guò)梳理各部門(mén)數(shù)據(jù)需求，將數(shù)據(jù)需求分類為：數(shù)據(jù)探索需求、報(bào)表需求、數(shù)據(jù)分析需求、數(shù)據(jù)API需求這四類。為滿足這些數(shù)據(jù)需求，我們相應(yīng)規(guī)劃了下面這些數(shù)據(jù)產(chǎn)品：

AdHoc系統(tǒng)：解決數(shù)據(jù)探索性需求，基于SQL查詢，查詢速度要求高;

地動(dòng)儀：解決報(bào)表需求，承接較固化報(bào)表需求、公司級(jí)報(bào)表需求;

BI產(chǎn)品：解決數(shù)據(jù)分析需求，支持多維查詢，支持?jǐn)?shù)據(jù)分析中常用的下鉆、上卷等功能;

數(shù)據(jù)API：解決數(shù)據(jù)API需求，大數(shù)據(jù)API統(tǒng)一出口，支持各部門(mén)的格式化數(shù)據(jù)獲取。

結(jié)合數(shù)據(jù)產(chǎn)品層面的規(guī)劃，大數(shù)據(jù)平臺(tái)在技術(shù)工作上做了重新規(guī)劃，技術(shù)工作上劃分出了四個(gè)部分：平臺(tái)服務(wù)、數(shù)據(jù)管理、工具鏈與集群。

其中平臺(tái)服務(wù)包含報(bào)表系統(tǒng)、BI系統(tǒng)與大數(shù)據(jù)API;大數(shù)據(jù)工具鏈包括OLAP引擎、即席查詢AdHoc系統(tǒng)、調(diào)度系統(tǒng)三部分;大數(shù)據(jù)集群層面除集群性能、穩(wěn)定性工作外，還包括集群安全、集群資源隔離兩部分;貫穿服務(wù)、工具鏈、集群三層的數(shù)據(jù)管理部分，更加關(guān)注數(shù)據(jù)治理，內(nèi)含元數(shù)據(jù)管理、指標(biāo)管理、數(shù)據(jù)權(quán)限管理三大數(shù)據(jù)管理工作。技術(shù)工作劃分情況如圖2：

圖2 鏈家網(wǎng)大數(shù)據(jù)平臺(tái)

大數(shù)據(jù)平臺(tái)的建設(shè)過(guò)程，是由下而上逐步完成的。首先要有Hadoop集群，在有HDFS與Hive后，才能開(kāi)展數(shù)據(jù)接入工作，才能基于集群建設(shè)工具鏈;當(dāng)工具鏈部分的OLAP引擎構(gòu)建好，才有上層BI、報(bào)表系統(tǒng)和數(shù)據(jù)API，只有AdHoc能力構(gòu)建好，才能提供基于SQL的數(shù)據(jù)探索平臺(tái)，工具鏈中特別需要建設(shè)好調(diào)度系統(tǒng)，才能在實(shí)現(xiàn)好數(shù)據(jù)ETL任務(wù)的同時(shí)，管控?cái)?shù)據(jù)流向與數(shù)據(jù)關(guān)系。

最后則是服務(wù)層面的建設(shè)，重心在于迎合需求的同時(shí)，服務(wù)做得更加易用。數(shù)據(jù)管理系統(tǒng)會(huì)穿插于整個(gè)大數(shù)據(jù)平臺(tái)中。

大數(shù)據(jù)平臺(tái)中銜接服務(wù)與集群的樞紐——工具鏈，正是整個(gè)平臺(tái)能力的傳送帶，它肩負(fù)著將大數(shù)據(jù)能力輸送到上層服務(wù)層的重任，也承擔(dān)著上層多項(xiàng)服務(wù)被使用時(shí)的數(shù)據(jù)能力支持。

建設(shè)大數(shù)據(jù)平臺(tái)樞紐——工具鏈

大數(shù)據(jù)平臺(tái)內(nèi)部工作，完全可以簡(jiǎn)單劃分為集群與服務(wù)兩部分，為何要在它們之間構(gòu)建一層工具鏈層呢?由圖1可以看到，原大數(shù)據(jù)架構(gòu)中，因產(chǎn)品層面單一，數(shù)據(jù)從收集入HDFS后，數(shù)據(jù)流向單一，均由Oozie調(diào)度任務(wù)從Hive獲取數(shù)據(jù)，并向上推送。

考慮到平臺(tái)服務(wù)層面的多個(gè)產(chǎn)品形態(tài)，數(shù)據(jù)流向也需擴(kuò)展才能滿足產(chǎn)品所需能力，而數(shù)據(jù)流的管理與集群工作強(qiáng)制規(guī)劃在一起，太過(guò)生硬。故全新開(kāi)辟一層工具鏈層，通過(guò)借助集群能力，通過(guò)或使用開(kāi)源或自研，來(lái)擴(kuò)展數(shù)據(jù)轉(zhuǎn)換與輸出的能力，提供更多種的數(shù)據(jù)流形式，以滿足上層數(shù)據(jù)服務(wù)需求。

對(duì)于工具鏈層面的設(shè)計(jì)，我們按照數(shù)據(jù)流向設(shè)計(jì)了下圖中的工具鏈結(jié)構(gòu)：

圖3 大數(shù)據(jù)工具鏈數(shù)據(jù)流向規(guī)劃

數(shù)據(jù)探索類需求

數(shù)據(jù)探索類需求，即數(shù)據(jù)查詢需求，若都基于Hive采用MapReduce運(yùn)算，速度上會(huì)大大影響用戶的使用體驗(yàn)，然而即席查詢AdHoc技術(shù)方面，F(xiàn)acebook開(kāi)源的基于內(nèi)存計(jì)算的Presto進(jìn)入了我們的視野，考慮到Presto與Hive均為Facebook開(kāi)源技術(shù)，在SQL兼容性方面通用性更強(qiáng)，特對(duì)Hive、Presto、Spark在SQL on Hadoop方面進(jìn)行測(cè)試對(duì)比：

1. 數(shù)據(jù)樣本：2000萬(wàn)行數(shù)據(jù)集、7000萬(wàn)行數(shù)據(jù)集;
2. SQL樣例：簡(jiǎn)單SQL(select count)、復(fù)雜SQL(線上真實(shí)SQL);
3. 機(jī)器資源：
4. Hive：3臺(tái)機(jī)器;
5. Spark：4個(gè)節(jié)點(diǎn);
6. Presto：3個(gè)節(jié)點(diǎn)，每節(jié)點(diǎn)最大內(nèi)存4G。

通過(guò)多次測(cè)試結(jié)果顯示，在處理速度方面，Presto < Spark SQL < Hive，大部分情況下，Presto時(shí)間開(kāi)銷(xiāo)上遠(yuǎn)少于Hive SQL，速度優(yōu)勢(shì)稍微好于Spark SQL。考慮到公司內(nèi)探索性數(shù)據(jù)查詢需求由人發(fā)起，數(shù)量可控，Presto技術(shù)選型完全滿足我們對(duì)響應(yīng)速度的要求。

故采用Presto引擎搭建AdHoc平臺(tái)，AdHoc的Web界面我們通過(guò)自研，除基礎(chǔ)的數(shù)據(jù)查詢功能外，實(shí)現(xiàn)了數(shù)據(jù)導(dǎo)出、轉(zhuǎn)發(fā)、生成報(bào)表等功能，其中生成報(bào)表功能與調(diào)度系統(tǒng)打通，將數(shù)據(jù)探索工作成果進(jìn)一步延伸，由AdHoc發(fā)起的調(diào)度任務(wù)，則是使用MapReduce離線運(yùn)算。關(guān)于Presto UI部分，Airbnb開(kāi)源的Airpal界面簡(jiǎn)潔清晰，也是不錯(cuò)的選擇。

圖4 Airbnb開(kāi)源的基于Presto的UI界面

數(shù)據(jù)分析類需求

數(shù)據(jù)分析性需求按照工作方式細(xì)分，還可以分為非技術(shù)人員使用Web工具分析數(shù)據(jù)、技術(shù)型人員直連Hadoop集群提交分析任務(wù)兩種類型。前者更多是運(yùn)營(yíng)、研究院、產(chǎn)品線數(shù)據(jù)PM等角色使用，后者則是做數(shù)據(jù)挖掘、推薦的工程師們?cè)谑褂茫瑢?duì)于工程師們，我們內(nèi)網(wǎng)開(kāi)放集群運(yùn)算能力，供工程師們提交任務(wù)，通過(guò)集群中的資源隔離保障大家的任務(wù)高效運(yùn)行。工具鏈中，則更關(guān)注前者的分析類場(chǎng)景，如何方便地滿足。

非技術(shù)人員的數(shù)據(jù)分析需求，相對(duì)于比較固話的數(shù)據(jù)報(bào)表型需求，指標(biāo)、維度的組合上希望靈活性更高，并且有著下鉆、上卷分析數(shù)據(jù)的需求，更多維的查詢數(shù)據(jù)。因?yàn)榉治龉ぷ饕话闶沁B續(xù)查詢數(shù)據(jù)，所以對(duì)于查詢速度也有一定的期望。

鑒于此，我們考慮通過(guò)預(yù)置數(shù)據(jù)的方式，通過(guò)空間換時(shí)間，來(lái)解決查詢速度問(wèn)題。對(duì)于多維查詢需求，我們考慮通過(guò)構(gòu)建多維Cube方案解決。這正是MOLAP解決數(shù)據(jù)查詢問(wèn)題的方式，而MOLAP方案的有限技術(shù)選型中，我們更看好Apache Kylin項(xiàng)目。

Apache Kylin項(xiàng)目的一些特性，匹配我們的數(shù)據(jù)需求以及我們當(dāng)時(shí)的現(xiàn)狀。數(shù)據(jù)需求已經(jīng)梳理清晰，要快、要多維查詢，Kylin項(xiàng)目對(duì)于已創(chuàng)建了Cube并構(gòu)建好數(shù)據(jù)的數(shù)據(jù)集上，提供亞秒級(jí)的快速查詢。并且Kylin還提供工具方便構(gòu)建Cube、提供API方便對(duì)接上游BI產(chǎn)品。

另一方面我們當(dāng)時(shí)的現(xiàn)狀是，海量數(shù)據(jù)庫(kù)方面我們擁有穩(wěn)定且調(diào)優(yōu)過(guò)的HBase集群，這恰巧是Apache Kylin所依賴的數(shù)據(jù)庫(kù)選型。綜合這些情況，我們通過(guò)調(diào)研Kylin系統(tǒng)自身能力、Kylin與Sarku的對(duì)接情況，以及有Apache Kylin研發(fā)團(tuán)隊(duì)成員現(xiàn)場(chǎng)交流，逐步啟動(dòng)了基于Kylin的MOLAP引擎構(gòu)建。預(yù)計(jì)不久我們將以Kylin為基礎(chǔ)，為BI產(chǎn)品、數(shù)據(jù)API兩項(xiàng)數(shù)據(jù)平臺(tái)服務(wù)提供數(shù)據(jù)查詢能力，以滿足公司內(nèi)的多維數(shù)據(jù)分析需求。

通過(guò)MOLAP建設(shè)，與原有地動(dòng)儀ROLAP相輔相成，面向公司內(nèi)有數(shù)據(jù)分析訴求的同事，提供更全面的數(shù)據(jù)分析平臺(tái)。

調(diào)度系統(tǒng)

調(diào)度系統(tǒng)，是大數(shù)據(jù)工具鏈的核心環(huán)節(jié)，乃至是大數(shù)據(jù)平臺(tái)化的基礎(chǔ)。數(shù)據(jù)ETL任務(wù)完全基于任務(wù)調(diào)度在有計(jì)劃地執(zhí)行，數(shù)據(jù)任務(wù)的關(guān)系、數(shù)據(jù)血緣也需要基于調(diào)度系統(tǒng)的能力來(lái)自動(dòng)化構(gòu)建。

在鏈家網(wǎng)大數(shù)據(jù)平臺(tái)建設(shè)之初，最先對(duì)原有的Oozie調(diào)度系統(tǒng)進(jìn)行調(diào)研分析，發(fā)現(xiàn)Oozie與Hadoop集群綁定太過(guò)緊密，任務(wù)間的狀態(tài)傳遞必須依賴HDFS中的文件狀態(tài)來(lái)傳遞任務(wù)狀態(tài)，這導(dǎo)致一些數(shù)據(jù)任務(wù)需要我們用Hack的手段處理。

例如我們的任務(wù)是定時(shí)“先將Hive數(shù)據(jù)導(dǎo)到MySQL，再運(yùn)行一個(gè)遠(yuǎn)程服務(wù)器腳本對(duì)MySQL統(tǒng)計(jì)數(shù)據(jù)，再將腳本統(tǒng)計(jì)的結(jié)果發(fā)送到xxx@lianjia.com郵箱”，這樣的需求，整個(gè)過(guò)程沒(méi)有產(chǎn)生HDFS文件的必要，但在使用Oozie時(shí)，我們不得不在每一步執(zhí)行完后在HDFS中創(chuàng)建文件以便傳遞信息。

我們已經(jīng)可預(yù)見(jiàn)未來(lái)數(shù)據(jù)任務(wù)需求會(huì)有所增加，隨之而來(lái)的數(shù)據(jù)任務(wù)種類也將會(huì)擴(kuò)充，若不做調(diào)度系統(tǒng)上的改變，大數(shù)據(jù)平臺(tái)的數(shù)據(jù)任務(wù)能力，將會(huì)受限于Oozie的使用場(chǎng)景，這與平臺(tái)設(shè)計(jì)理念不符，工具應(yīng)當(dāng)更好的支持平臺(tái)建設(shè)，而非阻礙平臺(tái)發(fā)展。

所以在那時(shí)，我們決定自研大數(shù)據(jù)調(diào)度系統(tǒng)，在參考了行業(yè)內(nèi)一些調(diào)度系統(tǒng)解決方案的同時(shí)，我們梳理了現(xiàn)有的任務(wù)種類與可能的未來(lái)需求，逐步排期的實(shí)現(xiàn)調(diào)度系統(tǒng)必須的兩大環(huán)節(jié)：調(diào)度環(huán)節(jié)、執(zhí)行環(huán)節(jié)，并且抽象的設(shè)計(jì)了他們之間的傳輸協(xié)議，為未來(lái)擴(kuò)展新型執(zhí)行單元提供了可能。

圖5 調(diào)度系統(tǒng)前端功能

圖6 調(diào)度系統(tǒng)后端能力

工具鏈作為數(shù)據(jù)驅(qū)動(dòng)紐帶，工具化的為上層平臺(tái)服務(wù)提供各類能力，上層平臺(tái)服務(wù)包裝大數(shù)據(jù)平臺(tái)能力，開(kāi)放給用戶使用。圍繞著工具鏈的建設(shè)，大數(shù)據(jù)平臺(tái)較改造前的數(shù)據(jù)加工模式，提供了更豐富的上層數(shù)據(jù)服務(wù)。

通過(guò)Apache Kylin技術(shù)構(gòu)建MOLAP引擎，與原有的ROLAP引擎相輔相成，搭配基于Presto的AdHoc服務(wù)，提供了一站式的快速數(shù)據(jù)查詢、分析平臺(tái)，并且提供了統(tǒng)一的大數(shù)據(jù)API，為公司各業(yè)務(wù)線、數(shù)據(jù)分析團(tuán)隊(duì)、數(shù)據(jù)應(yīng)用方提供高可用穩(wěn)定的數(shù)據(jù)格式化出口。隨著調(diào)度系統(tǒng)的逐漸成熟，工具鏈層面的建設(shè)逐漸完善，平臺(tái)化的大數(shù)據(jù)服務(wù)，整體較從前有全面的改善。鏈家網(wǎng)的大數(shù)據(jù)工作逐漸從報(bào)表階段，步入了平臺(tái)化自助服務(wù)的階段。

技術(shù)挑戰(zhàn)

當(dāng)然，在建設(shè)大數(shù)據(jù)工具鏈的過(guò)程中，依然還有不少技術(shù)問(wèn)題需要攻堅(jiān)。例如Presto中還未完全兼容Hive SQL語(yǔ)法，需要涉及到Presto SQL解析器部分的調(diào)整工作，又例如Kylin如何能夠根據(jù)指標(biāo)系統(tǒng)中的指標(biāo)自動(dòng)構(gòu)建Cube，需要考慮打通指標(biāo)系統(tǒng)與Kylin系統(tǒng)，或通過(guò)自動(dòng)化的程序來(lái)避免數(shù)據(jù)開(kāi)發(fā)人員的重復(fù)操作。

工具鏈中的技術(shù)挑戰(zhàn)還有不少，但我們清晰的發(fā)展路線，讓我們有堅(jiān)定的信心去逐個(gè)攻克，也歡迎有志之士加入，一同建設(shè)鏈家網(wǎng)大數(shù)據(jù)平臺(tái)。

大數(shù)據(jù)平臺(tái)的規(guī)劃

目前大數(shù)據(jù)工具鏈的技術(shù)問(wèn)題，在陸續(xù)解決的同時(shí)，我們的平臺(tái)服務(wù)、集群、數(shù)據(jù)管理相關(guān)的工作也都在緊鑼密鼓的進(jìn)行中。整體大數(shù)據(jù)平臺(tái)長(zhǎng)線的一些工作，也在逐漸規(guī)劃著，例如自動(dòng)化構(gòu)建數(shù)據(jù)血緣、調(diào)度系統(tǒng)中任務(wù)DAG實(shí)時(shí)關(guān)系圖、MOLAP與ROLAP的融合、數(shù)據(jù)API的全自助服務(wù)等技術(shù)問(wèn)題。相信未來(lái)半年到一年的大數(shù)據(jù)平臺(tái)發(fā)展過(guò)程中，在將平臺(tái)服務(wù)包裝的更為優(yōu)秀的同時(shí)，將會(huì)積累更多實(shí)用的技術(shù)沉淀，促成公司、團(tuán)隊(duì)、個(gè)人共同成長(zhǎng)與進(jìn)步。

在建設(shè)鏈家網(wǎng)大數(shù)據(jù)平臺(tái)期間，我們與百度、美團(tuán)、滴滴和Kyligence有著良好的溝通交流，他們?cè)诖髷?shù)據(jù)平臺(tái)上的沉淀與經(jīng)驗(yàn)在平臺(tái)設(shè)計(jì)規(guī)劃階段，對(duì)我們的幫助很大，我們也將會(huì)在建設(shè)鏈家網(wǎng)大數(shù)據(jù)平臺(tái)的同時(shí)，通過(guò)技術(shù)分享的方式與行業(yè)內(nèi)大數(shù)據(jù)相關(guān)的朋友分享交流，幫助營(yíng)造行業(yè)內(nèi)大數(shù)據(jù)領(lǐng)域共同進(jìn)步的良好氛圍。