品友互動大數據平台的技術演化

大數據的誘惑：唯有複雜，才有魅力。

"Big data is like teenage sex.Everyone talks about it, nobody really knows how to do it."

----Dan Ariely

前言

品友是一個大數據和人工智慧公司，如何處理好每天超過260億的請求數據？如何清洗超過20T的數據？如何沉澱超過6000個用戶畫像標籤？如何秒級返回數十個維度的業務報表查詢？ 這都是品友雲平台的大數據平台的挑戰。

本篇文章將介紹2013年到2017年，品友大數據平台的技術演化之路。在發展過程中，我們踩過很多的技術坑，有時候在演化決策上也缺少原則而翻過錯誤。漸漸的，我們總結出我們在技術演化的兩個基本原則：

1.奧卡姆剃刀原則：「如無必要，勿增實體」。

2.追求性能，靈活度和成本的多贏和平衡。

第一代大數據平台

第一代大數據平台（2013-2014）

與其說第一代平台，不如說是軟體的疊加，需要什麼用什麼，搞定業務問題就好，數據能處理就好。

第一代架構是比較簡單的三層結構，如圖1. 第一層數據來源是從廣告交易平台（RTB）和私有化廣告交易平台（PDB）收集的數據，包括曝光、點擊、訪客、轉化，競價，未競價等日誌；還包括第三方監測平台（比如秒針、Admaster等）收集的數據。

第二層是數據處理，對收集的數據通過ETL處理存儲到hadoop中。接著對存儲的非結構化或半結構化數據進行離線計算，把結果（一般是結構化的數據）存入關係型資料庫中。在hadoop平台之上，還會通過machine learning相關演算法訓練數據，並把模型應用到投放系統。

一些考慮：

Hadoop版本選擇：

在2014年，雖然hadoop社區已經發布release從0.X的版本到2.X的版本，但那時品友採用比較保守的做法，採用的是apache Hadoop0.20，在當時技術架構可以滿足業務的需求。正如我很喜歡的一位stackoverflow工程師Marco Cecconi說過「running with scale but not at scale」。

數據流：

從下至上，ETL採用flume + rsync的方式，把收集清洗地數據存儲在HDFS。由Jobtracker進行離線計算的資源分配和調度。離線計算以MapReduce和PIG為主。每個離線的計劃任務通過Crontab和oozie來執行。sqoop 實現hdfs與RDBMS間數據交換。部分演算法模型通過mahout進行訓練。人群屬性在我們的場景下對延遲比較敏感，所以我們採用storm進行實時處理。

數據倉庫

第一代的數據倉庫還是用傳統的RDBMS（MySQL)，經過big data處理之後的數據，會存儲之上的關係型資料庫以及緩存中，支撐應用層的查詢和分析。

以上簡單介紹了第一代的技術棧。

第一代問題和解決方案:

問題一：對hadoop有一定了解的人，肯定會知道hadoop0.X版本，存在著namenode和jobtracker單點以及jobtracker負載過重，我們需要提升更好的穩定性指標.

問題二：隨著業務迅猛發展，品友也對接了中國絕大多數廣告交易平台流量以及海外交易平台流量，每天的增量數據有10TB左右，集群規模也從幾十台增加到上百台。集群管理、數據延遲是我們要解決的第二個問題。

問題三：計算效率。數據增加也會使計算任務總的完成時間增加。業務人員有時候是無法接受數據延遲的。

問題四：品友DSP在線上想要達到很好的投放效果，除了流量、人群、報表分析之外，還需要機器學習的演算法支撐。而機器學習的演算法需要進行反覆參數的調整，迭代計算訓練出一個最優模型。基於mahout的machine learning tool，已經不能滿足演算法的需要了。

針對這4大問題，我們分別採用了以下對應解決方案：

升級hadoop.從release 0.20 到 stable 2.4.0.

我們通過調研對比cloudera，hortonworks和MapR的大數據管理平台工具，最終選擇hortonworks的ambari作為我們的集群管理平台（網上有很多對比，這裡不再贅述）； 數據延遲是我們面臨的一大挑戰，當時開源的ETL工具都不能很好的滿足（輕量、低延遲、高吞吐）的需求，峰值30-40萬請求。除了使用比較強大且開源的Kafka作為數據流處理平台（stream processing platform），另外我們還自主研發了數據收集和數據傳輸的組件。

為了提高計算效率的目標，除了對MapReduce的任務做優化，我們還挑選了數據延遲敏感的任務進行改造，利用Spark作為計算引擎，提升了計算的效率，減少了任務完成的時間。

通過Spark還解決了我們部分機器學習模型訓練的問題。

第二代大數據平台

第二代大數據平台（2015-2016）

第二代大數據平台在數據延遲，集群管理，計算效率及演算法模型訓練方面都有了很大的提升。從下之上，數據來源除了對接廣告交易平台，也更加的多樣化（Variety），比如移動端SDK，爬蟲數據，webservice服務。各種數據由自研的數據收集組件（LogAggregator） 攝取到流處理平台（kafka）再通過數據傳輸組件（Kafka2Hdfs）把數據經過清洗，存儲到hdfs。通過分散式計算把結果存入數據倉庫。 數據查詢方面與第一代不同的是我們增加了多維度的報表查詢功能。

第二代比第一代的優勢，主要體現在穩定性，數據採集，數據管理，數據分析，計算效率以及演算法。NamenodeHA和Yarn提高了集群的健壯性。通過LogAggregator，Kafka，Kafka2HDFS（LogAggregator,Kafka2Hdfs為自研組件）提高了數據的低延遲、高吞吐。 通過Ambari，方便集群管理；hue，zeppelin提高了可視化操作的程度。Spark、presto提供更高效的離線計算、數據分析能力。

第三代大數據平台

品友數據湖

what is data lake - A data lake is a method of storing data within a system or repository, in its natural format,[1] that facilitates the collocation of data in various schemata and structural forms, usually object blobs or files. The idea of data lake is to have a single store of all data in the enterprise ranging from raw data (which implies exact copy of source system data) to transformed data which is used for various tasks including reporting, visualization, analytics and machine learning.

摘自wikipedia

大數據平台的幾點思考：

• 所有數據都有潛在的價值
• 不再以結構化數據為主，可能是非結構化或半結構化的數據
• Schema在查詢才會被轉換。
• 用戶會挑選適合的結果理解數據

數據湖概覽

舊的業務處理流程:

定義結構->攝取數據->查詢分析

新的業務處理流程:

攝取數據->查詢分析->定義結構

數據湖分為三層：

第一層: 數據存儲

未加工過的元數據以及歷史數據（冷數據）存儲在這一層。所有數據都有潛在的價值。

第二層:數據加工

通過我們的data catalog模塊把元數據按照不同的數據格式，數據類型加工，以及數據的時間等緯度進行加工。

第三層:數據應用

利用工作流引擎把具有各種依賴關係的任務結合起來，產生的結果提供給數據倉庫或者更高層級的數據分析和報表

第三代大數據平台（2016- 現在）：實時，大規模，成本

第三代的特點是數據倉庫不在以傳統的RDBMS為主，而是基於Data Lake與Data warehouse 相結合的模式，無論從數據的廣度和深度上，都更好地滿足業務需要，數據查詢分析也採用OLAP技術。

品友對接的各種數據先進入品友數據湖(Data Lake)，在經過一系列的離線計算(hive/pig/sparksql)存入數據倉庫中，再通過OLAP技術進行數據查詢和分析，結果到報表或者BI系統展示。

數據也會根據格式，類型以及時間等緯度進行分類，通過大數據處理提供互動式查詢和機器學習等應用。

第三代架構是以極少的成本最大化集群利用率為目標，實現更加彈性的的雲平台。利用虛擬化技術、容器技術，大數據技術為應用端提供更好的服務。最大的挑戰是如何把這些不同的集群和服務進行融合，形成一個整體（類似google的borg），該項目還在進行中。 請關注品友技術公眾號，及時了解最新技術動態。

藍色為第三代新增的技術。基礎設施服務硬體上 依託自建的數據中心和混合雲，軟體上依託docker，kubernates，mesos，marathon，kvm等技術，以及自動化運維和運維可視化等手段。引入Apache Ranger進行許可權管理，保證數據的安全性。

我們還採用了Airbnb的兩個開源工具：

Airflow--工作流引擎： 解決不同計劃任務之間的依賴；

superset：提供了豐富的報表展示功能，提高平台可視化能力。

工作流引擎

集群任務可視化

在第三代的架構中，我們在數據分析能力和機器學習平台上，也進行了大量的探索和深挖。數據分析方面我們嘗試使用Druid，ClickHouse和Palo尋求一種更加高效，環節更少，更易於維護的OLAP工具，目前已有初步的結論，請關注品友技術公眾號，及時了解品友技術動態。

人工智慧領域我們也在嘗試使用不同的平台（比如Google Tensorflow, Tencent Angel），解決機器學習的各類問題。對於Tensorflow，我們也積極擴大部署規模，希望在模型訓練上提供更加強大的基礎。

結束語

在數據平台的演化過程中，最痛苦的事情不是增加一個工具，而是做減法，把一個業務所需要的數據能力理解透徹，找到核心瓶頸，而不是在各種工具和系統之間盲目的技術選型。

在未來的日子裡，我們將繼續以業務需求為中心，優化大數據平台，提昇平台的靈活度，性能和降低成本。深度學習平台將是我們的一個工作重點，特別是對於圖片和視頻模型訓練支持！

我們將在精彩的大數據探索上，繼續前行！

推薦閱讀：