WOT技術門診寄語：沒有天生的信心，只有不斷培養的信心

為大數據和較新的快速數據架構提供基礎設施并不是一個餅干切割的問題。兩者對硬件和軟件基礎設施都有著顯著的調整或改變。較新的快速的數據架構與大數據架構有著顯著區別，并且快速數據提供了真正的聯機事務處理工具。理解大數據基礎設施建設能夠幫助你做出正確的硬件和軟件選擇。

11月8日 ，鏈家網大數據資深架構師 趙國賢做客WOT技術門診第四期群友互動課堂，針對鏈家網在大數據基礎設施建設 ，從最初的技術支持報表需求，到年初的技術實現自助報表需求，到現在的技術搭建平臺提供數據分析、數據獲取服務所遇到的問題分享了自己的經驗。，希望能給更多對大數據基礎設施建設感興趣的小伙伴帶來幫助。

趙國賢

現就職鏈家網資深工程師，負責鏈家網大數據平臺的基礎架構方向，專注構建大數據基礎平臺。2011曾供職于新浪，改造過scribe，把當時的全網的行為數據收集方式從離線改造為實時收集，參與了大數據平臺從無到有的整個發展歷程，負責了當時新浪的實時數據統計系統storm并改造部分統計需求，極大提升了數據的實時性，2013年供職于搜狗數據分析平臺高級工程師，建立一套完備的數據平臺，支撐了公司的數據需求。

以上語音主要分三塊介紹：大數據的演進、大數據的架構、大數據安全，重點介紹數據安全遇到的一些具體的問題。

以下為語音直播實錄：

1.介紹鏈家網大數據的演進之路

鏈家已經成立十五年，線下經紀人13萬名，圍繞的線下房產交易，有大量的運營需求需要數據支撐，分城市、分商圈、分門店的情況都需要細分。所以，在鏈家網成立初期，集團運營數據需求就已經有了，故在2015年初就搭建了第一套系統來支持數據報表，逐漸圍繞著上層需求，構建起了鏈家網大數據架構。也是在那時，成立的大數據部門，為公司做好數據支撐。鏈家已經成立十五年，線下經紀人13萬名，圍繞的線下房產交易，有大量的運營需求需要數據支撐，分城市、分商圈、分門店的情況都需要細分。所以，在鏈家網成立初期，集團運營數據需求就已經有了，故在2015年初就搭建了第一套系統來支持數據報表，逐漸圍繞著上層需求，構建起了鏈家網大數據架構。也是在那時，成立的大數據部門，為公司做好數據支撐。

2.介紹鏈家網大數據的架構

鏈家網大數據從最初的技術支持報表需求，到年初的技術實現自助報表需求，到現在的技術搭建平臺提供數據分析、數據獲取服務，這正是鏈家網大數據這一年多所經歷的，其中涉及到的架構變遷、新技術方案的引入、大數據平臺化等等，鏈家網大數據的架構。

3.鏈家網大數據的數據安全

鏈家網是一家極其重視數據的公司，更加重視數據安全，大數據部門無論從上層的API服務，中間層的工具鏈、一直到底層的基礎平臺集群都有都有相應的權限控制和認證方案，我們采用分層的方法保證數據安全，防止滲透。采用最小可用的原則讓需要的人接觸到需要的數據，但是不會過度授權。另外數據安全是一個比較大的議題，包括服務的認證、用戶的授權、數據的加密等，如果發散講的話，我估計一天也講不完，下面我重點介紹一下鏈家網大數據集群的數據安全方案以及遇到的一些坑，集群我們采用開源的Hadoop、Spark、以及一些相應的組件，比如Hive、Presto、HBase等，基本上所有的存儲、計算都會在集群內完成，這就對集群的安全提出非常大的挑戰，經過前期的調研和實踐，當前我們主要采用Kerberos + 基于自研的權限分配方案 + 自研的審計功能，Kerberos主要解決機器與服務的認證、自研的權限分配方案主要解決用戶的授權、自研的審計功能主要解決記錄誰使用了集群都做了什么。當然在實踐安全方案的過程中，我們也遇到各種各樣的問題。下面簡單列舉幾點給大家分享一下

1)kerberos本身的復雜性

Kerberos是一種網絡認證協議， 其設計目標是通過密鑰系統為客戶機 / 服務器應用程序提供強大的認證服務。該認證過程的實現不依賴于主機操作系統的認證，無需基于主機地址的信任，不要求網絡上所有主機的物理安全，并假定網絡上傳送的數據包可以被任意地讀取、修改和插入數據。在以上情況下， Kerberos 作為一種可信任的第三方認證服務，是通過傳統的密碼技術(如：共享密鑰)執行認證服務的。我們這邊也用了一段時間去熟悉kerberos的認證流程，實現Kerberos的HA方案等，這里也建議如果想啟用Kerberos的用戶一定要弄清楚kerberos的認證流程，這樣實現安全方案的時候會事半功倍。

2) 安全Yarn使用Linuxcontainer

鏈家使用的是基于Hadoop2.4.1的定制開發版本，安全集群的Yarn必須使用Linux Container，但是 Container-executor 和 Container-executor.cfg 必須 做特殊的權限配置，對運維提出更高的要求。

3) datanode的啟動方式

Datanode必須使用JSVC啟動，并且啟動的Datanode必須有Sudo權限，因為安全Datanode使用低于1000的端啟動的，但是Hadoop2.6.1的版本以后就不存在這個問題，鏈家這邊也在考慮升級到Hadoop2.6.1版本上。

4) 集群的組件多，Hive(HiveServer2、Metastoreserver)、Oize、Spark等，需要逐一的測試保證平滑的過渡。

5) 剛才在第四點的時候我們談到平滑過渡，是指從無安全的集群過渡到有安全的集群，比較突出的問題是保證業務的平滑過渡和保證集群的平滑升級，這里給出的建議是在確保安全方案的執行性，平滑過渡性的同時，一定要保證準備好完備的Rollback方案。

6) kerberos的過期失效問題

我們現在采用的方案是定期刷新Ticket sss，另外在加上一點就是關于數據加密的問題，因為數據加密的話就會對易用性等產生影響，鏈家這邊得規劃是對數據分層管理，根據不同的層級選擇不同的加密措施來保證數據的安全。

公告：以下為11月8日 WOT技術門診群 交流互動內容

問題一：您認為在云上開發大數據平臺可能會面臨哪些技術難點，特別是在穩定性和高可用方面，您有哪些好的建議?

關于在云上開發大數據平臺，現在無論是Aws還是阿里云都提供了大數據的相關組件，能夠比較容易的組建公司的底層數據平臺，可能談不上技術難點，比較關鍵的是云平臺都會依賴相關的云的相關組件，比如AWS的EMR可能和s3結合起來會更容易使用，另外就是大數據平臺都會根據業務做專有化定制開發與底層優化。云上也比較難于實現各種組件的靈活搭配。穩定性和高可用方面的話，大部分云廠商都會提供高穩定性和高可用的保證，這里提供的經驗就是，一定要自己在上層或者其他方法實現內部的高可用方案。

問題二：像搭建鏈家這樣的地產大數據架構時，數據結構和類型有什么樣的特點?您如何進行數據存儲架構的選型?

和其他公司相通性的就是數據都有行為數據與業務數據，但不同點就是業務數據更復雜，維度更多，比如商圈、門店等等，另外就是我們對數據的實時性要求更高，維度的組合更多，在選型上我們既有傳統的MySQL、也有列式存儲HBASE，也有部分的ES來解決我們的業務需求。

問題三：更新、查詢都比較頻繁的大增量數據時如何存儲?每天會新增10G+吧，ES的話，更新會造成大量的版本數據，造成冗余;關系型數據庫的話，感覺數據量一大，查詢、更新效率是個問題。HBase可行嗎?之前用HBase時rowkey設計考慮寫負載，導致spark讀取很慢。

我覺得這種場景首先要做一下壓測看一下，系統的瓶頸在哪里，是由于網卡的壓力大，還是磁盤IO大，還是內存的壓力等等，只有有了這些壓測數據，我們才能夠知道我們的存儲系統的瓶頸在哪里，你所說的rowkey設計考慮寫負載，導致spark讀很慢，也如上所說系統的瓶頸在哪里，才能夠基于瓶頸做優化和提升性能，另外我們專門做過HBase的優化，通過做二級緩存、升級ssd等來提升HBase的性能，還得根據業務的特點做一些優化，你所說的這種場景HBase是完全能夠滿足需求的。

【本文由趙國賢于2016年11月8日，在WOT技術門診第四期《大鏈家網大數據基礎設施建設》語音直播分享以及和群成員答疑互動的內容整理而成。如需轉載請注明出處為WOT】