2018 年 11 月 9 日下午 ,由七牛雲主辦的第 31 期架構師實踐日——大數據技術實踐與分享，在南京舉行。有貨架構師兼運維總監張春華為我們帶來了題為《有貨大數據系統的演進之路》的分享。
張春華，有貨架構師兼運維總監，負責有貨電商中臺系統、大數據系統的架構設計。對微服務框架、電商大數據系統、運維繫統等有一定的認識和豐富的實踐。
本文是對分享內容的整理。
有些同學可能不是特別瞭解有貨， 我先為大家介紹一下有貨。有貨總部位於南京。我們公司主要有三塊業務，一塊是媒體，包括線上 APP YOHO!NOW 和潮流雜誌 YOHO!BOYS & YOHO!GIRL ； 另一塊是零售，包括電商 APP YOHO!BUY 和線下店 YOHO!STORE，最後一塊就是分享潮流生活方式的 mars。
我擔任有貨的架構師，同時也負責運維，加入有貨之前我是華為的工程師。
有貨是七牛很早的早期存儲用戶。早在 2014 年的時候，我們就是七牛雲存儲的一個用戶，我們全網所有的圖片、小文件、視頻都存在七牛雲上。到 2015 年、2016 年，我們開始變成七牛 CDN 的用戶。
我先分享一下有貨從 2013 年到 2015 年大數據的一個基本架構，這個是最原始大數據的一個系統。關於基礎設施，我們在北京有自己租用的 IDC，在這個 IDC 的機器上我們部署了基於 Hadoop 的系統，主要提供 hive 的計算。我們做一些簡單的業務報表，提供給老闆看一些日活月活，包括店鋪的銷售數據、商品的銷售數據等等，是一個很簡單的系統。
這個系統主要的問題有兩點：
一是存儲能力不足，因為你需要自己去買磁陣，而且這個費用是非常高的，而且容易壞掉。另外存儲分為冷熱存儲，自己在 IDC 很難做這個冷熱分離。
二是計算能力不足，因為 hive，大家都知道它很難去支撐一些實時或者近實時的業務。我相信大部分公司，第一個大數據平臺都是類似這樣的，基於 hive 的一個簡單的東西。
在 2015 年的時候，我們也做了一個最大的變化，就是從 IDC 遷移到公有云上，遷移到公有云上以後，我們的大數據也一併遷移到公有云上。原來的物理計算機變成了雲的虛擬機，在這個虛擬機上我們也搭建了自己的 Hadoop 集群。同時為了支撐一些實時或者近實時的業務，我們也搭建了 Spark 的集群。
有了這個 Sprak 之後我們就能支撐一些實時的業務，比如說老闆看一個小時內哪個商品賣得好或者哪個商品點擊率高等等，它可以支持實時的查詢。從 2015 年到 2017 年，這個系統運行了將近一年多到兩年的時間。
這個系統也有一些問題，第一個問題就是計算和存儲是耦合的，因為我們是公有云虛擬機搭建的一個 Hadoop 集群，計算能力不足時，你需要加節點，存儲也順帶必須要加上，可能存儲是夠的，加的存儲就是浪費。這是一個問題。同時自己搭建集群維護成本很高。
另一方面，Spark 在毫秒級延遲下的 Streaming 計算能力是不足的。基於 hive 的數據倉庫也是比較慢的，一般快的需要二三十秒，慢的可能要幾百秒。
現在的架構大概是這個樣子，最下面是系統的數據源，還有來自外部廣告投放的一些點擊數據。我們現在存儲都是用的雲的對象存儲，簡稱 OSS。計算包括流計算、OLAP 和批處理計算。流處理我們使用 Spark streaming + Flink 的架構；OLAP 主要使用了 Druid 和 Spark ；數據倉庫方面，我們在 hive 的基礎上添加 GreenPlum 來支撐一些更快的查詢。
為什麼引入 Greenplum 呢？因為這個數據庫是 MPP 界開源裡面一個比較好的選擇。能夠支持 PB 級的數據，而且在性能上、可靠性上經過了很多商業案例的檢驗。我們國內銀行、證券等金融行業客戶用這個用得比較多。我們做的一些 CRM 人群畫像使用寬表存儲在 Greenplum 中，業務系統取這些數據的時候就會非常快，如果用 hive 取這些數據就會很慢。
有了這套系統，我們可以支撐報表、運營、CRM、風控、推薦等等業務。
我們重點看一下 Flink 在我們這邊的一些應用。以惡意請求檢測的場景來介紹，我們電商系統或者其他系統應該都會遇到一些惡意的攻擊，比如說羊毛黨、撞庫等等。系統入口的請求日誌通過 Filebeat 收集到管道-即 Kafka 集群中，一個 Flink Straming 任務是對原始日誌做清理。清理完之後再把結構化的數據寫到 Kafka 集群裡面。然後再有另外一個任務讀取這些清理過的事件，然後根據規則判斷請求是否惡意。 我們通過 spring cloud config server 來提供規則配置服務。如果 IP 是惡意的，就會寫入到 Redis 中，Openresty 會 subscribe 到惡意 IP，並且實時攔截請求。
這是一個簡單的惡意 IP 識別的系統。這個識別是基於規則。我們也嘗試過去做一些所謂的人工智能基於有標籤的歷史數據集就行訓練。經過我們實踐之後，發現基於特徵和基於規則的結果都是差不多的，所以我們沒有上線基於機器學習的惡意檢測系統。
這個系統，我們現在能夠支撐到 5 萬每秒的請求，所以如果你用 Spark Streaming 這個來做，同樣的延遲和吞吐量，可能會需要更大的 yarn 集群資源。
接著介紹一下 OLAP。我們做過 POC 後最終選了 Druid 來做 OLAP。
Druid 可以直接對接 Kafka 流數據，可以很方便地做一些數倉的切片、切塊等等，可以支持匯聚，能夠支持快速的 count-distinct。count-distinct 電商系統裡面是非常常見的，你要計算 PV、UV 等等。我們用 Druid 主要做留存分析，包括熱門店鋪、熱門商品、熱門品類等等。運營系統裡面很多數據、很多計算都是來自於 Druid。我們有一個簡單的 APM 系統，我們也用 Druid 來分析 APP 上報的數據，能知道哪個地區可能網絡質量不是很好，哪個版本可能崩潰率比較高等等。
下面是 Druid 的一個架構圖，簡單介紹一下，Druid 可主要包括歷史節點、實時節點，Broker 節點和協調節點，它們各司其職。
Druid 的歷史數據存儲有很多選擇，例如 Hadoop HDFS、OSS 等。大家知道 Druid 只存儲匯聚後的數據，原始數據我們是存儲在 Greenplum 中。
接下來分享一下我們在構建大數據一路演進下來的一些經驗或者一些教訓。
第一個是存儲空間的優化，我們最初在公有云上用 EMR 的時候，我們的存儲空間是非常非常大的，用了一個月之後我們發現這個存儲賬單爆掉了，光存儲就是十幾萬的賬單。為什麼？我們發現我們犯了一個低級錯誤，沒有清理一些 Trash 目錄，這個釋放掉之後空間就會省出很多。第二個是存儲格式，一開始沒有做壓縮，存儲空間就很大。後面我們切換了 orc+snappy 的方式，存儲空間就很小。
下圖展示了各種存儲方式空間大小。切換存儲方式應用也要有一些變化，所以這個工作最好在一開始就做好。
第二個是對象存儲文件的一個前綴優化，如果大家做過 HDFS 應該都知道，這個會造成所謂的熱點。要怎麼做呢？可能說你把這個前綴做一些 random 的東西，例如對路徑做 HASH，這樣的話，這些文件就會分佈到不同的節點上。但是做了這個之後也會變得很麻煩。 Hadoop 集群在 IDC 中，你會感受不到熱點的問題。當你的數據量變得很大的時候，並且你的數據都是通過網絡從 OSS 中獲取的，你會發現這個問題很嚴重。我們當時幾乎每天都會出現熱點問題，會報超時，但是沒有太好的辦法，就需要做前綴的這些優化。
當然，各個公有云廠商也在不斷對 OSS 產品做改進。我相信其他的公有云廠商，比如說阿里雲、華為雲或者七牛雲，他們都在做優化，我相信再過一年兩年這個優化就會成為歷史，可能不需要自己做，OSS 廠商就會幫你做。
第二個就是 AutoScaling，這個是非常重要。 公有云 EMR 中 task 節點是無狀態的，可以方便的伸縮。我們現在每天凌晨擴展一些 task 節點支持大批量的 ETL 計算。計算結束之後，到第二天早上大概到 9 點時，我們會把這些 task 節點全部都縮掉。這個能降低成本，這也是使用公有云的一個好處。
這就是我今天分享的主要內容 ：有貨大數據系統從基本的 Hadoop 集群進化到現在一個包括 Streaming、OLAP、Batch 的基於公有云的數據平臺，也有從 IDC 遷移到公有云的經驗。 謝謝大家。
Q
&
A
Q
我想請教一下，我剛才看到我們有圖片存儲，是放在哪兒的？
答：我們這些圖片都是放在七牛雲上的。圖片我們這邊沒有什麼特別的處理。如果你的 APP 或者客戶端要請求圖片的時候會做一個壓縮裁剪，這是七牛雲做的比較好的，提供了裁剪、壓縮的接口。
Q
使用本地 Hadoop 集群 HDFS 與使用 OSS，會不會需要一些額外的比如關於壓縮算法或者傳輸方面需要額外考慮的東西？
答：其實不需要的。你原來是本地的 Hadoop 的集群，怎麼樣建立 hive 表，你在公有云上使用 OSS，比如說不管你用的是七牛雲，還是用的騰訊雲或者阿里雲或者 AWS，你不需要做任何變化，只需要把原來的 hdfs:// 改為 s3:// 或者 cosn://, qiniu:// 等等，其實對應用來說幾乎是沒有任何感知的。另外要注意一點就是 OSS 是通過網絡來獲取文件，需要考慮熱點問題。
Q
你們應該嘗試過多種分析引擎，有沒有關於 hive 的幾種分析引擎，我想問一下您有什麼可以給我們的意見或者推薦？
答：我們其實嘗試過很多引擎，最開始的我們是用裸 hive，後面是 hive on tez with LLAP。經過我們的實踐發現還是用 Spark SQL 是最快的，如果你的 Yarn 集群有足夠的內存資源。
閱讀更多 七牛雲 的文章
