了得網圖書_大數據平臺架構與原型實現：數據中臺建設實戰計算機與互聯網大

精彩書評

這本書的架構理論、方案和一些重要建議都經過了實踐檢驗，並取得了良好的效果，我相信書中的知識和見解可以復用於很多企業，幫助他們打破信息孤島，將線上與線下渠道連接在一起，為消費者提供更佳的用戶體驗，並幫助企業在激烈的市場競爭中迅速而敏捷地捕捉商機。

——歐萊雅集團亞太區首席信息官 Rita Lau

本書涵蓋了大數據平臺建設的全部環節，通讀下來，整體上實操性很強，架構原理融於了工程原型的搭建過程，對於希望自己動手實踐的讀者會很有幫助，同時在操作步驟中介紹了相應的邏輯及設計，有利於讀者更好地領會背後的原理。在今天這個時代，我們不見得要自己搭建整個平臺，但是了解原理可以讓自己工作起來事半功倍，不管是自己搭建，還是利用成熟平臺，懂得理論，明白實踐，再開始在企業中搭建數據驅動內部經營的完善體繫就會胸有成竹、遊刃有餘。

——彩食鮮CTO、鯤鵬會榮譽導師、蘇寧科技集團原副總裁喬新亮

這本書的理論基礎扎實，架構方案完備，更難能可貴的是它還有豐富翔實的原型繫統代碼供讀者參考和學習，這對很多讀者來說是一份寶貴的“禮物”，而作為企業的CTO，這本書給我的驚喜除技術外，它還對企業的數據戰略和中臺架構做了精彩的論述，對很多企業構建數據中臺都有指導意義。這是一本很有誠意、干貨滿滿的書，不僅對程序員、架構師有幫助，也適合CIO、CTO參考。

——華住集團技術副總裁及盟廣CTO 王曉光

數據中臺的概念滿天飛，但是數據中臺的落地始終是一個難點，很難統一。將數據中臺的核心通用組件抽像出來，一步步地指導企業如何去構建，這會是數據中臺領域的下一個課題。這本書率先在這一方向上進行了繫統闡述，它從數據中臺的概念出發，快速落地到實踐指導層面，講解如何從零開始構建數據中臺的核心組件。這是一本靠“堅實的”實踐積累出來的好書！

——精益數據體繫創始人、ThoughtWorks數據智能總經理史凱

在進行各類數據分析時，都離不開強大而完善的大數據平臺。然而常規的IT數據團隊對於業務方的需求及數據應用不甚了解，這本書對數據工程師有很大的參考價值，可以幫助他們對大數據平臺有一個全面的認識，了解數據從獲取到產出為分析結果這一過程中發生的事情，以便更好地與業務部門協作，實現大數據賦能。

——歐萊雅（中國）有限公司大眾化妝品部大數據總監唐雯

本書作者曾經分享過很多在中臺繫統落地過程中遇到的問題及解決方案，這些在我們搭建營銷相關的業務中臺過程中很有啟示作用。在每日千萬級交易數據的中臺建設過程中，我們深刻地體會到數據中臺在數據驅動創新方面的價值。本書詳細介紹了數據中臺的技術選型和架構方案，以及落地過程中的一些關鍵要素。希望本書能夠幫助讀者快速搭建自己企業的數據中臺，為業務發展助力。

——餓了麼營銷中臺架構師宋艷飛

本書作者是一位深耕於大數據領域，並一直奮戰在一線編寫代碼的架構師，作者憑借自身十多年的設計和研發經驗，歸納總結出了這本通俗易懂的大數據架構和技術書籍。內容從企業數據戰略規劃到架構方案設計與技術選型，並從開發人員的實際需要出發給出了詳細的工程代碼，可以說，從理論到實戰都進行了專業而細致的講解。

——埃森哲（中國）有限公司技術架構經理張俊

這是一本富有實戰色彩的大數據新作，彙聚了作者寶貴的經驗與獨到的觀點。本書涵蓋的知識與內容非常豐富，並呈縱深化結構，除技術內容外，還包括與大數據平臺配套的人纔能力、組織架構與管理方法論，適合不同級別的讀者。

——希爾頓酒店集團亞太區數據保護官、國際信息隱私專家協會上海分會前主席李宵聲

介紹完原型項目的業務場景之後，接下來就該考慮如何設計原型項目了。盡管原型項目的業務場景可以被設計得足夠簡單（如果作為一個單純的繫統去開發，隻需要非常簡單的架構就可以支撐了），但是如前所述，我們設計原型項目的目的並不是實現具體的業務功能，而是在原型項目的開發過程中帶領讀者廣泛和深入地接觸大數據平臺上的各種技術並進行工程實踐，所以我們要構建一個盡可能完善的大數據平臺。一個完備的全堆棧大數據平臺涵蓋數據采集、主數據管理、實時處理、批處理、數據服務和數據展示等若干個重要環節。完備而通用的大數據平臺架構參考如圖4-5所示。

首先，外部數據需要被數據采集組件采集到大數據平臺，然後針對實時處理和批處理分別寫入消息隊列和分布式文件繫統兩類不同的存儲介質上，因此從一開始，原始數據就冗餘了兩份，然後在實時處理和批處理兩條通道上同時對數據進行一繫列的驗證、清洗、轉換和計算。實時處理的計算結果通常會寫入一個NoSQL數據庫，以便後續實時查詢，批處理的計算結果往往寫回分布式文件繫統。實時處理和批處理在計算過程中都會用到主數據，批處理可以將主數據繫統視為一個數據源，將全部主數據導入大數據平臺上使用，這樣處理主數據就與處理普通數據無異，架構上無須做改動。但是對於流處理而言，在處理原始數據時需要實時獲取主數據，必須要有增強的主數據繫統為其提供服務。數據經過處理之後，就需要為外部提供服務了。通俗地說，數據服務就是將處理後的數據提供給請求方，不同的數據供給方式將服務於不同的數據應用。常規的數據服務有：

——將體量較小的結果集同步到傳統關繫型數據庫，供報表工具或各種應用繫統隨時查詢；

——通過構建前端API向前端應用直接提供數據查詢服務；

——通過OLAP引擎構建Cube，支持實時的、多維度的即時查詢。

最後，在數據服務的支撐下，會有一繫列的數據可視化工具將數據展示給終端用戶。數據可視化工具一般分為兩大類：一類是傳統的報表工具，另一類是基於Web的頁面或移動端App。前者定制靈活，開發效率高，但是實時性較差，後者需要針對性地開發，定制性較差，成本較高，但是實時性好。

總之，一個完整的大數據平臺都要有數據采集、數據處理（實時處理和批處理）、數據服務和數據展示環節，而這些環節上都有多種實現技術做支撐。每一種產品或工具又各有差異，所以我們接下來要討論一下技術選型。不過要事先說明的是，我們以下對於平臺各個環節上的技術選型隻是簡單地給出了最終結果，對於更多候選技術的對比和分析會在後續章節中專門展開。

1. 數據采集

數據采集的技術選型主要的考量點是看其支持的數據源種類和協議是否豐富，對接與開發是否便捷。目前業界較為主流的數據采集工具有Flume、Logstash及Kafka Connect等。其實有一個一直被人忽視但卻是非常理想的數據采集組件——Apache Camel，它主要應用於企業應用集成領域，也被一些繫統作為ESB（企業服務總線）使用，其作用是在應用繫統林立的企業IT環境中扮演“萬向接頭”的角色，讓數據和信息在各種不同的繫統間平滑地交換和流轉。經過多年的積累，Camel已經支持近200種協議或數據源，並且可以完全基於配置實現。我們希望原型項目未來能夠對接非常多的數據源，同時盡可能地通過配置去集成數據源並采集數據，避免編寫大量的代碼，Camel很好地滿足了這些需求，所以，看上去選擇Camel有一些“非主流”，但實際上這個選型是非常明智的，它特別適合企業平臺。當然，作為一個非大數據組件，對於Camel的性能和吞吐量我們要有清醒的認識，這個問題可以通過對數據源進行分組、使用多個Camel實例分區采集數據來解決。

2. 消息隊列

消息隊列的選型是最明朗的，Kafka幾乎是唯一的選擇，原型項目也不例外。

3. 流處理

流處理和批處理都是業務邏輯最集中的地方，也是繫統的核心。目前用於流處理的主流技術是Storm和Spark Streaming，對兩者進行比較的文章很多，通常認為Storm具有更高的實時性，可以做到亞秒級的延遲，相比之下Spark Streaming的實時性要差一些，因為它以“micro batch”的方式進行流處理，但是依托Spark這個大平臺，使用Spark Streaming既統一了技術堆棧，又能與其他Spark組件無縫交互，這使得它越來越流行。鋻於在業務上秒級延遲已經可以滿足需求，我們在原型項目上最終選擇了後者。另外，在寫作本書時，Flink在社區的呼聲越來越高，在未來有望成為流計算領域的“新王者”。

4. 批處理

傳統大數據的離線處理多選擇Hive，這在很多項目上被證明是可靠的解決方案。後來隨著Spark的不斷壯大，Spark SQL的使用越來越廣泛，並且Spark SQL完全兼容Hive，這使得遷移工作幾乎沒有任何障礙。對於復雜的業務邏輯或非結構化數據，在Hadoop平臺上一般通過MR編程處理，而在Spark平臺上則是通過Spark Core的RDD編程實現的。如今Spark在大數據處理的很多方面已經取代Hadoop成為大數據的首選技術平臺，所以在批處理的技術選型上我們選擇了“Spark Core + Spark SQL”。

5. 主數據管理

為什麼我們要單獨把主數據管理列出來討論呢？實際上在批處理的場景下，主數據和其他數據並沒有質的區別，隻是經常會被關聯查詢。但是，對於實時處理情況就完全不同了，實時處理也需要頻繁地用到主數據，但卻不能長期駐留在流計算節點上，因為流計算隻能處理當前流經繫統的數據，為此，我們必須構建一個統一的主數據管理模塊來為流計算提供主數據服務。當然，如果企業內部已經存在主數據管理繫統，也可以在原有繫統的基礎上進行改造，改造的重點是提供一種高性能、低延時的數據讀取能力。一般來說，最為常見的做法是將主數據加載到內存數據庫Redis中，同時考慮到主數據日常的增刪查改等日常維護工作，將高性能、低延時的主數據並入主數據管理繫統一起維護是常見的做法。所以主數據管理模塊本質上是一個傳統的Web應用，可以選擇基於Spring-Boot構建，使用MySQL作為後臺數據庫，使用Redis同步主數據，對外通過Restful API提供主數據供給服務。

6. 數據服務

企業對於數據的需求是非常多樣化的，盡管大數據平臺提供了一致的、功能強大的數據處理體繫，但當數據處理完畢供用戶使用時，根據時效性、數據展示方式、用戶使用習慣等諸多方面的需求，數據需要能以不同的方式和方法提供出去，這就要求企業的數據服務必須多樣化。圖4-5中的數據服務部分，給出了三種代表性的服務形態：面向結果集的關繫型數據庫（報表數據庫）、數據API和OLAP引擎。對於批處理而言，雖然外部繫統可以通過Hive或Spark SQL提供的JDBC或ODBC驅動獲取數據，但是這種數據請求需要被轉換為批處理作業去執行，無法滿足在線的用戶請求，所以批處理的結果一般都會同步到一個關繫型數據庫上，我們可以稱之為報表數據庫，通過這個數據庫對外提供數據。同時，為了能夠讓分析人員迅速、一致、交互地從各個方面觀察信息，很多企業還會建立自己的OLAP引擎，也就是以Cube模型對數據進行建模，提供多維度、實時的分析能力，在大數據平臺上也有相對成熟的OLAP產品，如Kylin。對於實時處理來說，處理結果一般會寫入一個NoSQL數據庫，目前能夠存儲大體量數據的主流NoSQL數據庫有HBase、Cassandra和MongoDB，我們的原型項目選擇的是HBase。NoSQL數據庫相較於Hive或Spark SQL具備完全的時實訪問能力，但不一定有面向應用的成熟的API接口，所以可以基於Web應用技術搭建一個數據訪問服務，這個服務通過NoSQL提供的客戶端類庫訪問數據庫，然後對外暴露Restful API。

7. 數據展示

數據展示有很多技術可以實現，BI報表可以使用Tableau或Qlik Sense，Web頁面上可以使用D3.js、Echarts等圖形庫，但這已經不是我們原型項目的重點了，本書不做過多討論。

綜上所述，基於前面的繫統架構，本書推薦的技術堆棧如圖4-6所示。

限於本書的篇幅和定位，我們不對數據服務和數據展示做深入探討，原型項目也沒有配套的實現模塊，我們將集中精力處理數據采集、主數據管理、流處理、批處理和作業調度這幾個環節。另外，考慮到有的繫統可能隻會建設批處理這一條管道，並且企業內部絕大多數的數據源以關繫型數據庫為主，原型項目也為批處理單獨配備了一個基於Sqoop的采集模塊，從而便於全面介紹數據導入技術，並盡可能地讓原型項目便於拆分和組合。所以，本書的原型項目最終呈現的架構如圖4-7所示。

商品搜索

商品分类

【醫學】

【各大出版社】

【医学】

【各大出版社】

產品特色

編輯推薦

內容簡介

作者簡介

精彩書評

目錄

精彩書摘