大數據平臺架構--學習筆記

何謂五橫，基本仍是根據數據的流向自底向上劃分五層，跟傳統的數據倉庫其實很相似，數據類的系統，概念上仍是相通的，分別爲數據採集層、數據處理層、數據分析層、數據訪問層及應用層。同時，大數據平臺架構跟傳統數據倉庫有一個不一樣，就是同一層次，爲了知足不一樣的場景，會採用更多的技術組件，體現百花齊放的特色，這是一個難點。

具體見下圖示例，這張圖是比較經典的，也是妥協的結果，跟當前網上不少的大數據架構圖均可以做必定的映射。

數據採集層：既包括傳統的ETL離線採集、也有實時採集、互聯網爬蟲解析等等。

數據處理層：根據數據處理場景要求不一樣，能夠劃分爲HADOOP、MPP、流處理等等。

數據分析層：主要包含了分析引擎，好比數據挖掘、機器學習、 深度學習

數據訪問層：主要是實現讀寫分離，將偏向應用的查詢等能力與計算能力剝離，包括實時查詢、多維查詢、常規查詢等應用場景。

數據應用層：根據企業的特色不一樣劃分不一樣類別的應用，好比針對運營商，對內有精準營銷、客服投訴、基站分析等，對外有基於位置的客流、基於標籤的廣告應用等等。

 

數據管理層：這是一縱，主要是實現數據的管理和運維，它橫跨多層，實現統一管理。

邏輯上，通常都有數據採集層、數據存儲與分析層、數據共享層、數據應用層，可能叫法有所不一樣，本質上的角色都大同小異。

--------------------------------------------------

數據採集層：

實時採集如今也成了大數據平臺的標配，估計主流就是FLUME+KAFKA，而後結合流處理+內存數據庫吧，這個技術確定靠譜，但這類開源的東西好是好，但一旦出現問題每每解決週期每每比較長。除了用FLUME，針對ORACLE數據庫的表爲了實現實時採集，也能夠採用OGG/DSG等技術實現實時的日誌採集，能夠解決傳統數據倉庫抽全量表的負荷問題。

企業級的爬蟲中心的建設難度蠻大，由於不只僅是須要爬蟲，還須要創建網址和應用知識庫，須要基於網頁文本進行中文分詞，倒排序及文本挖掘等，這一套下來，挑戰很大，當前已經有很多開源組件了，好比solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修遠兮。

數據源的種類比較多：

• 網站日誌：

做爲互聯網行業，網站日誌佔的份額最大，網站日誌存儲在多臺網站日誌服務器上，通常是在每臺網站日誌服務器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；

• 業務數據庫：

業務數據庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，咱們迫切的須要一種能從各類數據庫中將數據同步到HDFS上的工具，Sqoop是一種，可是Sqoop太過繁重，並且無論數據量大小，都須要啓動MapReduce來執行，並且須要Hadoop集羣的每臺機器都能訪問業務數據庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案，有資源的話，能夠基於DataX之上作二次開發，就能很是好的解決。固然，Flume經過配置與開發，也能夠實時的從數據庫中同步數據到HDFS。

• 來自於Ftp/Http的數據源：

有可能一些合做夥伴提供的數據，須要經過Ftp/Http等定時獲取，DataX也能夠知足該需求；

------------------------------

總得來說，建設大數據採集平臺很是不易，從客戶的角度講，至少要達到如下三個要求：

多樣化數據採集能力：支持對錶、文件、消息等多種數據的實時增量數據採集（使用flume、消息隊列、OGG等技術）和批量數據分佈式採集等能力（SQOOP、FTP VOER HDFS），比基於傳統ETL性能有量級上的提高，這是根本。

可視化快速配置能力：提供圖形化的開發和維護界面，支持圖形化拖拽式開發，免代碼編寫，下降採集難度，每配置一個數據接口耗時很短，以下降人工成本。

統一調度管控能力：實現採集任務的統一調度，可支持Hadoop的多種技術組件（如 MapReduce、Spark 、HIVE）、關係型數據庫存儲過程、 shell腳本等，支持多種調度策略（時間/接口通知/手工）。

-------------------------------

數據處理層

MPP應該來講，是採用分佈式架構對於傳統數據倉庫最好的替代，畢竟其其實是變了種的關係型數據庫，對於SQL提供完整支持，在HIVE作了轉化分析後，數據倉庫的融合建模用它來作性能綽綽有餘，其性價比較傳統DB2更好一點，好比通過實用，Gbase30-40臺集羣就能超過2臺頂配的IBM 780。

MPP如今產品不少，很難作優劣判斷，但一些實踐結果能夠說下，GBASE不錯，公司不少系統已經在上面跑了，主要仍是國產的，技術服務保障相對靠譜，ASTER還有待觀望，自帶一些算法庫是有其一些優點，GreenPlum、Vertica沒用過，很差說。

-----------------------------------

只嘗試過STORM和IBM STREAM，推薦IBM STREAM，雖然是商業版本，但其處理能力超過STORM不是一點半點，聽說STORM也基本不更新了，但其實數據量不大，用啥均可以，從應用的角度講，諸如IBM這種商業版本，是不錯的選擇，支撐各種實時應用場景綽綽有餘。

流處理集羣以流處理技術結合內存數據庫，用以實時及準實時數據處理，基於IBM Streams流處理集羣承載公司的實時業務：

---------------------------------

數據開放層

　　HBASE很好用，基於列存儲，查詢速度毫秒級，對於通常的百億級的記錄查詢那也是能力槓槓的，具備必定的高可用性，咱們生產上的詳單查詢、指標庫查詢都是很好的應用場景。但讀取數據方面只支持經過key或者key範圍讀取，所以要設計好rowkey。

---如何設計好HBASE RowKey？

　　Redis是K-V數據庫，讀寫速度比HBASE更快，大多時候，HBASE能作的，Redis也能作，但Redis是基於內存的，主要用在key-value 的內存緩存，有丟失數據的可能，當前標籤實時查詢會用到它，合做過的互聯網或廣告公司大多采用該技術，但若是數據愈來愈大，那麼，HBASE估計就是惟一的選擇了？

　　另外已經基於IMPALA提供互聯網日誌的實時在線查詢應用，也在嘗試在營銷平臺採用SQLFire和GemFire實現分佈式的基於內存的SQL關聯分析，雖然速度能夠，但也是BUG多多，引入和改造的代價較大。

　　Kylin當前算是基於hadoop/SPARK的多維分析的殺手級工具，應用的場景很是多，但願有機會使用。

-------------------

數據應用層

每一個企業應根據本身的實際規劃本身的應用，其實搞應用藍圖很難，大數據架構越上層越不穩定，由於變化太快，如下是運營商對外變現當前階段還算通用的一張應用規劃圖，供參考：

-----------------

數據管理層

經過該平臺實現從數據設計、開發到數據銷燬的全生命週期管理，並把標準、質量規則和安全策略固化在平臺上，實現從事前管理、事中控制和過後稽覈、審計的全方位質量管理和安全管理。

其它諸如調度管理、元數據管理、質量管理固然不在話下，由於管住了開發的源頭，數據管理的複雜度會大幅下降。

-------------------

 什麼是Druid,Flink,phoenix,redis?

 

 

▲滴滴大數據體系架構圖

▲知乎大數據平臺架構圖

▲騰訊雲大數據平臺架構圖(EMR)

 -----------------------------

什麼是canal? Presto? Kylin? 

數據開發的平臺，這張圖比較細，這是詳細的總體數據流架構圖。包括最左邊是數據接入，上面是流式計算，而後是Hadoop離線計算。

將上圖左上角擴大來看，首先是數據接入與流式計算，電商系統產生數據分兩個場景，一個是追加型的日誌型數據，另外是關係型數據的維度數據。對於前一種是使用Flume比較標準化的你們都在用的日誌收集系統，最近使用了阿里開源的Canal，以後有三個下游，全部的流式數據都是走Kafka這套流走的。

數據收集特性：

對於數據收集平臺，日誌數據是多接口的，能夠打到文件裏觀察文件，也能夠更新數據庫表。關係型數據庫是基於Binlog獲取增量的，若是作數據倉庫的話有大量的關係型數據庫，有一些變動無法發現等狀況，能夠經過Binlog手段能夠解決。經過一個Kafka消息隊列集中化分發支持下游，目前支持了850以上的日誌類型，峯值每秒有百萬介入。

流式計算平臺特性：

構建流式計算平臺的時候充分考慮了開發的複雜度，基於Storm。有一個在線的開發平臺，測試開發過程都在在線平臺上作，提供一個至關於對Storm應用場景的封裝，有一個拓撲開發框架，由於是流式計算，咱們也作了延遲統計和報警，如今支持1100以上的實時拓撲，秒級實時數據流延遲。

這幅圖是離線數據平臺的部署架構圖，最下面是三個基礎服務，包括Yarn、HDFS、HiveMeta。不一樣的計算場景提供不一樣的計算引擎支持。若是是新建的公司，其實這裏是有一些架構選型的。Cloud Table是本身作的HBase分裝封口。咱們使用Hive構建數據倉庫，用Spark在數據挖掘和機器學習，Presto支持Adhoc上查詢，也可能寫一些複雜的SQL。對應關係這裏Presto沒有部署到Yarn，跟Yarn是同步的，Spark是on Yarn跑。

建設敏捷數據倉庫，除了對架構技術上的要求以外，還有一個很重要的方面，就是數據建模，若是一上來就想着創建一套能兼容全部數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難知足對業務變化的快速響應。應對這種狀況，通常是先將核心的持久化的業務進行深度建模（好比：基於網站日誌創建的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據創建的用戶模型），其它的業務通常都採用維度+寬表的方式來創建數據模型，這塊是後話。

 

數據共享

這裏的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關係型數據庫和NOSQL數據庫；

前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，仍是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就須要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS恰好相反，這裏須要一個從HDFS將數據同步至其餘目標數據源的工具，一樣，DataX也能夠知足。另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。

 

即席查詢通常是經過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，能夠用SparkSQL，它的響應速度較Hive快不少，並且能很好的與Hive兼容。

實時計算：Storm在這塊是比較成熟了，但我選擇Spark Streaming，緣由很簡單，不想多引入一個框架到平臺中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於咱們的須要能夠忽略。

咱們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。

作法也很簡單，由Flume在前端日誌服務器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務經過訪問Redis實時獲取。

 

當前，頭條每日處理數據量爲 7.8 PB、訓練樣本量 200 億條、服務器總量 40000 臺、Hadoop 節點 3000 臺。

數據生命週期分爲生成、傳輸、入庫和統計/分析/挖掘，每一個環節的難度都會隨着數據規模的變大而上升。平臺建設面臨的挑戰是由龐大的數據量和業務複雜度給數據生成、採集、傳輸、存儲和計算等帶來的一系列問題。

(1)數據生成與採集——SDK、用戶埋點

通常狀況下，數據生成與採集是很簡單的事，但對於頭條這個功能衆多的 APP 來說，難點就在於每一個功能背後都是一個團隊獨立運營。若是每一個團隊都用自研的數據採集方法，那會給後續的進程帶來巨大的困擾。

怎麼辦呢?由於頭條屬於 C 端業務公司，主要以日誌形式爲主，數據的主要來源是用戶行爲，那麼就採用事件模型來描述日誌，以 SDK 形式接入，支持客戶端、服務端埋點。

這裏須要注意的是：數據質量很重要，埋點規範趁早確立，髒數據是不可避免的，能夠引入必要的約束、清洗等。

• 埋點。埋點是用戶在使用某一個功能時，產生的一段數據。頭條初期，埋點由各業務場景自定義日誌格式，以後埋點統一到事件模型，保證了信息的結構化和自描述，下降了後續使用成本，並複用統一的解析和清洗流程、數據倉庫的入庫和行爲分析平臺的導入。

埋點的管理，也由經過文檔、Wiki 等方式演進成埋點管理系統，覆蓋整個埋點生命週期。這樣一來，也獲得了埋點元信息的描述，後續可應用在數據清洗、分析平臺等場景，同時埋點的上線流程實現標準化，客戶端也可進行自動化測試。

SDK。數據平臺實現了通用的客戶端埋點 SDK 和服務端埋點 SDK，放棄以前按約定生成數據的方式，能夠保證生成的日誌符合埋點規範，並統一 App 啓動、設備標識等的基本口徑，也減小了新 App 適配成本。

對數據的描述由使用 JSON 改成 Protobuf，這樣就可經過 IDL 實現強制約束，包括數據類型、字段命名等。

除了日誌數據，關係數據庫中的數據也是數據分析的重要來源。頭條在數據的採集方式上，用 Spark 實現類 Sqoop 的分佈式抓取替代了早期按期用單機全量抓取 MySQL 數據表的方式，有效的提高了抓取速度，突破了單機瓶頸。

再以後爲了減小 MySQL 壓力，選用 Canal 來接收 MySQL binlog，離線 merge 出全量表，這樣就再也不直接讀 MySQL 了，並且對千萬/億級大表的處理速度也會更快。

(2)數據傳輸——Kafka 作消息總線鏈接在線和離線系統

數據在客戶端向服務端回傳或者直接在服務端產生時，能夠認爲是在線狀態。當數據落地到統計分析相關的基礎設施時，就變成離線的狀態了。在線系統和離線系統採用消息隊列來鏈接。

頭條的數據傳輸以 Kafka 做爲數據總線，全部實時和離線數據的接入都要經過 Kafka，包括日誌、binlog 等。這裏值得注意的是：儘早引入消息隊列，與業務系統解耦。

頭條的數據基礎設施以社區開源版本做爲基礎，並作了大量的改進，也回饋給了社區，同時還有不少自研的組件。

由於以目前的數據和集羣規模，直接使用社區版本乃至企業版的產品，都會遇到大量困難。像數據接入，就使用自研 Databus，做爲單機 Agent，封裝 Kafka 寫入，提供異步寫入、buffer、統一配置等 feature。

Kafka 數據經過 Dump 落地到 HDFS，供後續離線處理使用。隨着數據規模的增長，Dump 的實現也經歷了幾個階段。最初實現用的是相似 Flume 模式的單機上傳，很快遇到了瓶頸，實現改爲了經過 Storm 來實現多機分佈式的上傳，支持的數據吞吐量大幅增長。

如今開發了一個叫 DumpService 的服務，做爲託管服務方便整合到平臺工具上，底層實現切換到了 SparkStreaming，並實現了 exactly-once 語義，保證 Dump 數據不丟不重。

(3)數據入庫——數據倉庫、ETL(抽取轉換加載)

頭條的數據源很複雜，直接拿來作分析並不方便。可是到數據倉庫這一層級，會經過數據處理的過程，也就是 ETL，把它建設成一個層次完備的適合分析的一個個有價值的數倉。在數倉之上，就可讓數據分析師和數據 RD 經過 SQL 和多維分析等更高效的手段使用數據。

數據倉庫中數據表的元信息都放在 Hivemetastore 裏，數據表在 HDFS 上的存儲格式以 Parquet 爲主，這是一種列式存儲格式，對於嵌套數據結構的支持也很好。

頭條有多種 ETL 的實現模式在並存，對於底層數據構建，一種選擇是使用 Python 經過 HadoopStreaming 來實現 Map Reduce 的任務，但如今更傾向於使用 Spark 直接生成 Parquet 數據，Spark 相比 MapReduce 有更豐富的處理原語，代碼實現能夠更簡潔，也減小了中間數據的落地量。對於高層次的數據表，會直接使用 HiveSQL 來描述 ETL 過程。

(4)數據計算——計算引擎的演進

數據倉庫中的數據表如何能被高效的查詢很關鍵，由於這會直接關係到數據分析的效率。常見的查詢引擎能夠歸到三個模式中，Batch 類、MPP 類、Cube 類，頭條在 3 種模式上都有所應用。

頭條最先使用的查詢引擎是 InfoBright，Infopight 能夠認爲是支持了列式存儲的 MySQL，對分析類查詢更友好，但 Infopight 只支持單機。隨着數據量的增長，很快換成了 Hive，Hive 是一個很穩定的選擇，但速度通常。

爲了更好的支持 Adhoc 交互式查詢，頭條開始調研 MPP 類查詢引擎，前後使用過 Impala 和 Presto，但在頭條的數據量級下都遇到了穩定性的問題。

頭條如今的方案是混合使用 Spark SQL 和 Hive，並自研 QAP 查詢分析系統，自動分析並分發查詢 SQL 到適合的查詢引擎。在 Cube 類查詢引擎上，頭條採用了 Kylin，如今也是Kylin 在國內最大的用戶之一。

(5)數據門戶——爲業務的數據分析提供總體解決方案

對於大部分需求相對簡單的公司來講，數據最終能夠產出報表就夠用了，如作一個面向管理層的報表，可讓老闆直觀的瞭解一些關鍵性指標，這是最基礎的數據應用模式。

再深刻一點，就須要彙總各類來源的業務數據，提供多種維度和指標來進行更深刻的探索型分析，獲得的結論用來指導產品的迭代和運營。頭條絕大部分業務都是數據驅動的，都須要產出和分析大量的數據，這就或多或少須要用到平臺提供的系列工具。

頭條開發了一套叫數據門戶的平臺系統，提供給業務部門使用，對數據生命週期各個環節都提供了相應支持。數據門戶提供的工具都是聲明式的，也就是讓使用者只須要說明要實現什麼目的，具體實現的複雜細節都隱藏起來，對使用者更友好。

經過這些工具，可讓業務部門的 RD 、分析師、PM 等將精力放在業務分析自己，而不是去學習大量數據基礎設施的使用方法。