回首10年多的科研工作歷程，也是中國經濟高速發展的10多年，中國高鐵、核電、航空、互聯網、雲計算、大數據、人工智能等領域無不銘刻着“中國名片”，這就是科技是第一生產力的實踐驗證！12年前，獲得北郵計算機工學碩士後信心滿滿的踏上了科研之路，一干就是十多年，有苦有淚有艱辛，但收穫的是一種爲國防科技發展能奉獻和敢擔當的責任感。今天，更一次站在了移動互聯網這個朝陽產業的跑道上，和諸多大數據和人工智能的世界級大咖共商創新發展！7年前加入中國移動集團研究院，擔任資深大數據專家和研究員，主攻大數據和人工智能平臺架構設計和關鍵技術研究，並多次受邀在大數據行業和主流峯會進行學術交流，在見證我的學生們歷練爲BAT/TMD的技術專家同時，也悄然實現着我的技術夢想-讓高科技研發標準化和平民化。今天有幸分享商用大數據平臺研發經驗，讓大數據知識圖譜在各位的腦海裏轉起來，並形成商用產品的作戰體系，這是“作爲架構師，何謂正確？”的行動基礎。我分享四大部分：知識分類，系統架構，核心技術，經驗分享。具體如下：
一、大數據知識歸類:
文件存儲：Hadoop HDFS、Tachyon、KFS
離線計算：Hadoop MapReduce、Spark
流式、實時計算：Storm、Spark Streaming
K-V、NOSQL數據庫：HBase、Redis、MongoDB
資源管理：YARN、Mesos
日誌收集：Flume、Scribe、Logstash、Kibana
消息系統：Kafka、StormMQ、ZeroMQ、RabbitMQ
查詢分析：Hive、Impala、Pig、SparkSQL、Drill、Flink、Kylin、Druid
分佈式協調服務：Zookeeper
集羣管理與監控：Ambari、Ganglia、Nagios、Cloudera Manager
數據挖掘、機器學習：Mahout、Spark MLLib
數據同步：Sqoop
任務調度：Oozie
二、系統架構:
以物聯網大數據平臺的架構爲例，圍繞着這條主線：基礎架構-》離線分析-》離線遷移-》離線同步-》實時計算-》實時交換-》實時調度-》實時存儲-》智能分析
三、核心技術（10章）
第一章：Hadoop的崛起
Hadoop是一個由Apache基金會所開發的分佈式系統基礎架構。Hadoop是實現了真正意義上的去“IOE”，尤其是開啓了擺脫國外高科技公司的全球壟斷時代，讓全球用戶可以輕鬆地在免費的Hadoop上開發和運行處理海量數據的應用程序。建議先把Hadoop集羣構建起來，具體操作見我的博客：https://blog.csdn.net/peter_changyb/article/details/81195920。它主要有以下幾個優點：
高可靠性。Hadoop按位存儲和處理數據的能力值得人們信賴。
高擴展性。Hadoop是在可用的計算機集簇間分配數據並完成計算任務的，這些集簇可以方便地擴展到數以千計的節點中。
高效性。Hadoop能夠在節點之間動態地移動數據，並保證各個節點動態平衡，因此處理速度非常快。
高容錯性。Hadoop能夠自動保存數據的多個副本，並且能夠自動將失敗的任務重新分配。
Hadoop可以算是大數據存儲和計算的開山鼻祖，現在大多開源的大數據框架都依賴Hadoop或者與它能很好的兼容。具備如下：
Hadoop 1.0、Hadoop 2.0
MapReduce、HDFS
NameNode、DataNode
JobTracker、TaskTracker
Yarn、ResourceManager、NodeManager
1.1 HDFS是Hadoop的關鍵技術所在
HDFS目錄操作命令；上傳、下載文件命令；提交運行MapReduce示例程序；打開Hadoop WEB界面，查看Job運行狀態，查看Job運行日誌。知道Hadoop的系統日誌在哪裏。
1.2 瞭解並行計算的核心原理
MapReduce：分而治之的優秀思想；HDFS：數據分片和數據複製爲核心的技術。數據到底在哪裏，什麼是副本；
Yarn如何用分層管理思想革命性的改變了MapReduce的核心架構？NameNode職責？；Resource Manager職責？
1.3 親自寫MapReduce程序
Hadoop可以算是大數據存儲和計算的開山鼻祖，現在大多開源的大數據框架都依賴Hadoop或者與它能很好的兼容。具備如下：
Hadoop 1.0、Hadoop 2.0
MapReduce、HDFS
NameNode、DataNode
JobTracker、TaskTracker
Yarn、ResourceManager、NodeManager
1.1 Hadoop是雲計算產品代表
HDFS目錄操作命令；上傳、下載文件命令；提交運行MapReduce示例程序；打開Hadoop WEB界面，查看Job運行狀態，查看Job運行日誌。知道Hadoop的系統日誌在哪裏。
1.2 瞭解原理
MapReduce：如何分而治之；HDFS：數據到底在哪裏，什麼是副本；
Yarn到底是什麼，它能幹什麼；NameNode到底在幹些什麼；Resource Manager到底在幹些什麼；
1.3 自己寫一個MapReduce程序
請仿照WordCount例子，自己寫一個WordCount程序，
第二章：Hive做離線分析-查詢統計
2.1 SQL On Hadoop之Hive
什麼是Hive？官方給的解釋如下：The Apache Hive data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax.
爲什麼說Hive是數據倉庫工具，而不是數據庫工具呢？有的朋友可能不知道數據倉庫，數據倉庫是邏輯上的概念，底層使用的是數據庫，數據倉庫中的數據有這兩個特點：最全的歷史數據（海量）、相對穩定的；所謂相對穩定，指的是數據倉庫不同於業務系統數據庫，數據經常會被更新，數據一旦進入數據倉庫，很少會被更新和刪除，只會被大量查詢。而Hive，也是具備這兩個特點，因此，Hive適合做海量數據的數據倉庫工具，而不是數據庫工具。
Hive核心技術講解參見我的博客 https://blog.csdn.net/Peter_Changyb/article/details/81977665
2.2 安裝配置Hive
2.3 試試使用Hive
2.4 Hive是怎麼工作的
2.5 學會Hive的基本命令
創建、刪除表；加載數據到表；下載Hive表的數據
你具備以下技能和知識點：
MapReduce的原理（還是那個經典的題目，一個10G大小的文件，給定1G大小的內存，如何使用Java程序統計出現次數最多的10個單詞及次數）；
HDFS讀寫數據的流程；向HDFS中PUT數據；從HDFS中下載數據；
自己會寫簡單的MapReduce程序，運行出現問題，知道在哪裏查看日誌；
會寫簡單的SELECT、WHERE、GROUP BY等SQL語句；
Hive SQL轉換成MapReduce的大致流程；
Hive中常見的語句：創建表、刪除表、往表中加載數據、分區、將表中數據下載到本地；
第三章：數據採集與遷移
此處也可以叫做數據採集，把各個數據源的數據採集到Hadoop上。
3.1 HDFS PUT命令
這個在前面你應該已經使用過了。put命令在實際環境中也比較常用，通常配合shell、python等腳本語言來使用。建議熟練掌握。
3.2 HDFS API
HDFS提供了寫數據的API，自己用編程語言將數據寫入HDFS，put命令本身也是使用API。
實際環境中一般自己較少編寫程序使用API來寫數據到HDFS，通常都是使用其他框架封裝好的方法。比如：Hive中的INSERT語句，Spark中的saveAsTextfile等。建議瞭解原理，會寫Demo。
3.3 Sqoop
Sqoop是一個主要用於Hadoop/Hive與傳統關係型數據庫，Oracle、MySQL、SQLServer等之間進行數據交換的開源框架。就像Hive把SQL翻譯成MapReduce一樣，Sqoop把你指定的參數翻譯成MapReduce，提交到Hadoop運行，完成Hadoop與其他數據庫之間的數據交換。
自己下載和配置Sqoop（建議先使用Sqoop1，Sqoop2比較複雜）。瞭解Sqoop常用的配置參數和方法。
使用Sqoop完成從MySQL同步數據到HDFS；使用Sqoop完成從MySQL同步數據到Hive表；如果後續選型確定使用Sqoop作爲數據交換工具，那麼建議熟練掌握，否則，瞭解和會用Demo即可。Sqoop導入Hbase核心代碼見我的技術博客https://blog.csdn.net/Peter_Changyb/article/details/82557741
3.4 Flume
Flume是一個分佈式的海量日誌採集和傳輸框架，因爲“採集和傳輸框架”，所以它並不適合關係型數據庫的數據採集和傳輸。Flume可以實時的從網絡協議、消息系統、文件系統採集日誌，並傳輸到HDFS上。因此，如果你的業務有這些數據源的數據，並且需要實時的採集，那麼就應該考慮使用Flume。下載和配置Flume。使用Flume監控一個不斷追加數據的文件，並將數據傳輸到HDFS；Flume的配置和使用較爲複雜，如果你沒有足夠的興趣和耐心，可以先跳過Flume。核心技術參見我的技術博客https://blog.csdn.net/Peter_Changyb/article/details/81213997
第四章：數據同步
Hive和MapReduce進行分析了。那麼接下來的問題是，分析完的結果如何從Hadoop上同步到其他系統和應用中去呢？其實，此處的方法和第三章基本一致的。
4.1 HDFS GET命令
把HDFS上的文件GET到本地。需要熟練掌握。
4.2 HDFS API
4.3 Sqoop
同3.3.使用Sqoop完成將HDFS上的文件同步到MySQL；使用Sqoop完成將Hive表中的數據同步到MySQL。
4.4 DataX
DataX 是一個異構數據源離線同步工具，致力於實現包括關係型數據庫(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各種異構數據源之間穩定高效的數據同步功能。之所以介紹這個，是因爲我們公司目前使用的Hadoop與關係型數據庫數據交換的工具，就是之前基於DataX開發的，非常好用。現在DataX已經是3.0版本，支持很多數據源。你也可以在其之上做二次開發。有興趣的可以研究和使用一下，對比一下它與Sqoop。DataX本身作爲離線數據同步框架，採用Framework + plugin架構構建。將數據源讀取和寫入抽象成爲Reader/Writer插件，納入到整個同步框架中。
https://images2018.cnblogs.com/blog/948447/201807/948447-20180702134246476-1346908980.png
Reader：Reader爲數據採集模塊，負責採集數據源的數據，將數據發送給Framework。
Writer： Writer爲數據寫入模塊，負責不斷向Framework取數據，並將數據寫入到目的端。
Framework：Framework用於連接reader和writer，作爲兩者的數據傳輸通道，並處理緩衝，流控，併發，數據轉換等核心技術問題。
第五章：實時計算-SparkSQL
其實大家都已經發現Hive後臺使用MapReduce作爲執行引擎，實在是有點慢。因此SQL On Hadoop的框架越來越多，按我的瞭解，最常用的按照流行度依次爲SparkSQL、Impala和Presto.這三種框架基於半內存或者全內存，提供了SQL接口來快速查詢分析Hadoop上的數據。核心技術參考我的博客https://blog.csdn.net/Peter_Changyb/article/details/81904066
我們目前使用的是SparkSQL，至於爲什麼用SparkSQL，原因大概有以下吧：使用Spark還做了其他事情，不想引入過多的框架；Impala對內存的需求太大，沒有過多資源部署。
5.1 關於Spark和SparkSQL
什麼是Spark，什麼是SparkSQL。
Spark有的核心概念及名詞解釋。
SparkSQL和Spark是什麼關係，SparkSQL和Hive是什麼關係。
SparkSQL爲什麼比Hive跑的快。
5.2 如何部署和運行SparkSQL
Spark有哪些部署模式？
如何在Yarn上運行SparkSQL？
使用SparkSQL查詢Hive中的表。Spark不是一門短時間內就能掌握的技術，因此建議在瞭解了Spark之後，可以先從SparkSQL入手，循序漸進。
關於Spark和SparkSQL，如果你認真完成了上面的學習和實踐，此時，你的”大數據平臺”應該是這樣的。
第六章：數據交換-一次採集、多次消費
在實際業務場景下，特別是對於一些監控日誌，想即時的從日誌中瞭解一些指標（關於實時計算，後面章節會有介紹），這時候，從HDFS上分析就太慢了，儘管是通過Flume採集的，但Flume也不能間隔很短就往HDFS上滾動文件，這樣會導致小文件特別多。
爲了滿足數據的一次採集、多次消費的需求，這裏要說的便是Kafka。
6.1 關於Kafka
什麼是Kafka？Kafka的核心概念及名詞解釋。
6.2 如何部署和使用Kafka
使用單機部署Kafka，併成功運行自帶的生產者和消費者例子。使用Java程序自己編寫並運行生產者和消費者程序。Flume和Kafka的集成，使用Flume監控日誌，並將日誌數據實時發送至Kafka。
這時，使用Flume採集的數據，不是直接到HDFS上，而是先到Kafka，Kafka中的數據可以由多個消費者同時消費，其中一個消費者，就是將數據同步到HDFS。
爲什麼Spark比MapReduce快。
使用SparkSQL代替Hive，更快的運行SQL。
使用Kafka完成數據的一次收集，多次消費架構。
自己可以寫程序完成Kafka的生產者和消費者。
從前面的學習，你已經掌握了大數據平臺中的數據採集、數據存儲和計算、數據交換等大部分技能，而這其中的每一步，都需要一個任務（程序）來完成，各個任務之間又存在一定的依賴性，比如，必須等數據採集任務成功完成後，數據計算任務才能開始運行。如果一個任務執行失敗，需要給開發運維人員發送告警，同時需要提供完整的日誌來方便查錯。
第七章：實時調度
不僅僅是分析任務，數據採集、數據交換同樣是一個個的任務。這些任務中，有的是定時觸發，有點則需要依賴其他任務來觸發。當平臺中有幾百上千個任務需要維護和運行時候，僅僅靠crontab遠遠不夠了，這時便需要一個調度監控系統來完成這件事。調度監控系統是整個數據平臺的中樞系統，類似於AppMaster，負責分配和監控任務。
7.1 Apache Oozie
1. Oozie是什麼？有哪些功能？當你的系統引入了spark或者hadoop以後，基於Spark和Hadoop已經做了一些任務，比如一連串的Map Reduce任務，但是他們之間彼此右前後依賴的順序，因此你必須要等一個任務執行成功後，再手動執行第二個任務。
Oozie是管理Hadoop作業的工作流調度系統
Oozie的工作流是一系列的操作圖
Oozie協調作業是通過時間（頻率）以及有效數據觸發當前的Oozie工作流程
Oozie是針對Hadoop開發的開源工作流引擎，專門針對大規模複雜工作流程和數據管道設計
Oozie圍繞兩個核心：工作流和協調器，前者定義任務的拓撲和執行邏輯，後者負責工作流的依賴和觸發。
2. Oozie可以調度哪些類型的任務（程序）？
3. Oozie可以支持哪些任務觸發方式？
4. 安裝配置Oozie。
7.2 其他開源的任務調度系統
Azkaban，light-task-scheduler，Zeus，等等。另外，我這邊是之前單獨開發的任務調度與監控系統。
第八章：實時處理
在第六章介紹Kafka的時候提到了一些需要實時指標的業務場景，實時基本可以分爲絕對實時和準實時，絕對實時的延遲要求一般在毫秒級，準實時的延遲要求一般在秒、分鐘級。對於需要絕對實時的業務場景，用的比較多的是Storm，對於其他準實時的業務場景，可以是Storm，也可以是Spark Streaming。當然，如果可以的話，也可以自己寫程序來做。
8.1 Storm
1. 什麼是Storm？有哪些可能的應用場景？
2. Storm由哪些核心組件構成，各自擔任什麼角色？
3. Storm的簡單安裝和部署。
4. 自己編寫Demo程序，使用Storm完成實時數據流計算。案例實戰參見我的技術博客https://blog.csdn.net/Peter_Changyb/article/details/82380603
8.2 Spark Streaming
1. 什麼是Spark Streaming，它和Spark是什麼關係？
2. Spark Streaming和Storm比較，各有什麼優缺點？
3. 使用Kafka + Spark Streaming，完成實時計算的Demo程序。
至此，你的大數據平臺底層架構已經成型了，其中包括了數據採集、數據存儲與計算（離線和實時）、數據同步、任務調度與監控這幾大模塊。接下來是時候考慮如何更好的對外提供數據了。
第九章：規模遷移
通常對外（業務）提供數據訪問，大體上包含以下方面。
離線：比如，每天將前一天的數據提供到指定的數據源（DB、FILE、FTP）等；離線數據的提供可以採用Sqoop、DataX等離線數據交換工具。
實時：比如，在線網站的推薦系統，需要實時從數據平臺中獲取給用戶的推薦數據，這種要求延時非常低（50毫秒以內）。根據延時要求和實時數據的查詢需要，可能的方案有：HBase、Redis、MongoDB、ElasticSearch等。
OLAP分析：OLAP除了要求底層的數據模型比較規範，另外，對查詢的響應速度要求也越來越高，可能的方案有：Impala、Presto、SparkSQL、Kylin。如果你的數據模型比較規模，那麼Kylin是最好的選擇。
即席查詢：即席查詢的數據比較隨意，一般很難建立通用的數據模型，因此可能的方案有：Impala、Presto、SparkSQL。
這麼多比較成熟的框架和方案，需要結合自己的業務需求及數據平臺技術架構，選擇合適的。原則只有一個：越簡單越穩定的，就是最好的。
如果你已經掌握瞭如何很好的對外（業務）提供數據，那麼你的“大數據平臺”應該是這樣的：
第十章：機器學習
在我們的業務中，遇到的能用機器學習解決的問題大概這麼三類：
分類問題：包括二分類和多分類，二分類就是解決了預測的問題，就像預測一封郵件是否垃圾郵件；多分類解決的是文本的分類；
聚類問題：從用戶搜索過的關鍵詞，對用戶進行大概的歸類。
推薦問題：根據用戶的歷史瀏覽和點擊行爲進行相關推薦。
機器學習核心技術參見我的技術博客https://blog.csdn.net/Peter_Changyb/article/details/82347169。大多數行業，使用機器學習解決的，也就是這幾類問題。入門學習線路，數學基礎；機器學習實戰，懂Python最好；SparkMlLib提供了一些封裝好的算法，以及特徵處理、特徵選擇的方法。
四、經驗分享
總之，對商用大數據平臺而言，我們要考慮應用場景，用戶規模和數據處理能力，以及未來3年的目標等。在應用場景的設計中，會考慮業務和技術的結合度量，業務的規模和流程設計。用戶規模和數據處理能力，會考慮技術選型和架構設計。具體要考慮架構設計。架構中重要的核心指標：性能、可用性、伸縮性、擴展性的等架構指標。
一、性能
性能就是核心要素之一，具體如下：
CDN加速
反向代理
分佈式緩存
異步化：通過分佈式消息隊列來實現削峯的目的。通過業務配合技術來解決問題。
集羣：採用集羣也是服務虛擬化的一個體現。用以避免單點問題，同時提供更加高可用，高性能的服務。
代碼優化：多線程中，如果是密集型計算，線程數不宜超過CPU核數。如果是IO處理，則線程數=[任務執行時間/(任務執行時間-IO等待時間)] * CPU核數。除此之外，我們應該將對象設計成無狀態對象，多采用局部對象，適當將鎖細化。進行資源複用。比如採用單例模式，比如採用連接池。合理設置JVM參數。
存儲性能優化：關係型數據庫的索引採用B+樹進行實現。而很多的nosql數據庫則採用了LSM樹進行存儲。LSM在內存中保留最新增刪改查的數據，直到內存無法放下，則與磁盤的下一級LSM樹進行merge。所以對於寫操作較多，而讀操作更多的是查詢最近寫入數據的場景，其性能遠高於b+樹；採用HDFS結合map reduce進行海量數據存儲和分析。其能自動進行併發訪問和冗餘備份，具有很高的可靠性。其等於是實現了RAID的功能。
數據訪問接口優化：數據庫層其實是最脆弱的一層，一般在應用設計時在上游就需要把請求攔截掉，數據庫層只承擔“能力範圍內”的訪問請求，所以，我們通過在服務層引入隊列和緩存，讓最底層的數據庫高枕無憂。
二、高可用性
衡量一個系統架構設計是否滿足高可用的目標，就是假設系統中任何一臺或者多臺服務器宕機時，以及出現各種不可預期的問題時，系統整體是否依然可用。一般就三個手段、冗餘、集羣化、分佈式。高可用的主要手段就是冗餘，應用部署在多臺服務器上同時提供服務，數據存儲在多臺服務器上相互備份。安全服務是指計算機網絡提供的安全防護措施，包括認證服務、訪問控制、數據機密性服務、數據完整性服務和不可否認服務。特定的安全機制是用來實施安全服務的機制，包括加密機制、數據簽名機制、訪問控制機制、數據完整性機制、認證交換機制、流量填充機制、路由控制機制和公證機制。普遍性的安全機制不是爲任何特定的服務而特設的，屬於安全管理方面，分爲可信功能度、安全標記、事件檢測、安全審計跟蹤和安全恢復。
三、高擴展性
擴展性指對現有系統影響最小的情況下，系統功能可持續擴展或提升的能力。表現在系統基礎設施穩定不需要經常變更，應用之間較少依賴和耦合，當系統增加新功能時，不需要對現有系統的結構和代碼進行修改。擴展性依賴於前期良好的架構設計。合理業務邏輯抽象，水平/垂直切割分佈式化等等。可擴展架構的主要手段是事件驅動架構和分佈式服務。事件驅動通常利用消息隊列實現，通過這種方式將消息生產和處理邏輯分隔開。服務器服務則是將業務和可複用服務分離開來，通過分佈式服務框架調用。新增加產品可用通過調用可複用的服務來實現自身的業務邏輯，而對現有產品沒有任何影響。
四、高伸縮性
服務儘量同構。DB、cache在考慮分佈式時儘量提前設計好擴展方案。也可以採用一些主流的對水平伸縮支持較好的nosql、memcached、hbase等。
圍繞着大數據平臺的全棧技術，以及數據流主線：數據採集-》數據集成-》數據處理-》數據微服務-》數據應用，我設計並實現瞭如下的商用大數據平臺架構。
