7月8日，深信服大數(shù)據(jù)負責人Letian在信服云《云集技術(shù)學社》系列直播課上進行了《大數(shù)據(jù)技術(shù)原理和發(fā)展趨勢解析》的分享，對Hadoop、流處理、內(nèi)存計算、檢索、消息隊列、大數(shù)據(jù)OLAP等技術(shù)進行了詳細分析。以下是他的分享內(nèi)容簡要，想要了解更多可以點擊http://sangfor.bizconf.cn/live/watch/technology/?id=mn1x3enl觀看直播回放。

看點一：什么是Hadoop？經(jīng)典的Hadoop技術(shù)能做什么？

Hadoop是大數(shù)據(jù)的經(jīng)典技術(shù)，是一個開源的可運行于大規(guī)模集群上的分布式文件系統(tǒng)和運行處理框架。Hadoop擅長于在廉價機器搭建的集群上進行海量數(shù)據(jù)(結(jié)構(gòu)化與半結(jié)構(gòu)化)的存儲與離線處理。

Hadoop的核心是HDFS、Mapreduce和YARN

（1）HDFS

HDFS是Hadoop體系中數(shù)據(jù)存儲管理的基礎。它是一個高度容錯的系統(tǒng)，能檢測和應對硬件故障，用于在低成本的通用硬件上運行。HDFS簡化了文件的一致性模型，通過主從式的數(shù)據(jù)存儲方式，為分析程序提供高吞吐量的數(shù)據(jù)訪問能力，適合帶有大型數(shù)據(jù)集的分析應用。

（2）MapReduce

MapReduce是一種計算模型，分為"Map（映射）"和"Reduce（歸約）"兩個部分。基于MapReduce和HDFS，Hadoop的生態(tài)生長出了HIVE和Hbase。其中，HIVE定義了一種類似SQL的查詢語言(HQL)，將SQL“轉(zhuǎn)化為”MapReduce的任務執(zhí)行。HIVE的特點是非常穩(wěn)定，極大的數(shù)據(jù)量都能計算出結(jié)果，例如，長達幾個小時甚至幾天的離線分析就很適合采用HIVE。

（3）Hbase

Hbase是一種基于HDFS的NOSQL，它有稀疏表存儲、LSM、二級索引等功能特點，更適合高并發(fā)讀寫訪問、實時讀寫訪問，例如推薦畫像的標簽存儲與訪問、時空數(shù)據(jù)（如行車軌跡）、消息/訂單（話費詳單查詢）等場景，很適合運用Hbase。

（4）YARN

YARN是一個資源管理和調(diào)度工具，當大數(shù)據(jù)生態(tài)中越來越多類型的計算組件和計算任務類型出現(xiàn)，YARN通過雙層調(diào)度機制，可以幫助系統(tǒng)管理多種類型組件的計算任務，從而把集群中的計算資源都管理起來，提升資源利用率。比如，在用戶提交一個mapreduce計算job之后，多個Map和Reduce的任務就是分別運行在YARN分配的資源容器中。

看點二：近年來常用的大數(shù)據(jù)生態(tài)技術(shù)有哪些？

（1）Spark

Spark是基于RDD實現(xiàn)的分布式計算框架，輸出和結(jié)果保存在內(nèi)存中，不需要頻繁讀寫HDFS，因此比mapreduce的數(shù)據(jù)處理效率高。Spark擴展了Mapreduce的原語，除了map和reduce類型的任務之外，還有g(shù)roupby、union等原語任務。Spark因為是內(nèi)存計算，適用于“相對近線的或離線”的數(shù)據(jù)查詢（通過sparksql或者原生接口）和實時監(jiān)控場景（通過SparkStreaming）。另外，內(nèi)存計算的特點也特別適合迭代計算的場景，例如圖計算、機器學習場景。

（2）Flink

Flink是開源流處理框架，與SparkStreaming的區(qū)別在于，Spark是微批（一小批）地處理數(shù)據(jù)，而Flink則可以一條一條地處理數(shù)據(jù)。在運行時，F(xiàn)link對實時數(shù)據(jù)的處理也被分為原語任務（map、keyby等），并將所有的原語任務分布到不同節(jié)點上進行并行處理。Flink適用于完全實時的數(shù)據(jù)分析與機器學習應用場景，例如醫(yī)療集成平臺的CDC、反欺詐、異常檢測、基于規(guī)則的報警、業(yè)務流程監(jiān)控等等。

（3）ElasticSearch（ES）

ES是一個基于Lucene的搜索引擎，無論在開源還是專有領域，Lucene可以被認為是迄今為止最先進、性能最好的、功能最全的搜索引擎庫。ES實現(xiàn)了Lucene的分布式化：可以擴展到上百臺服務器，處理PB級數(shù)據(jù)。當下不少商品搜索、APP搜索、知識庫搜索、日志檢索、地理位置查詢等，都是使用ES實現(xiàn)的。

（4）Kafka

Kafka是一個分布式、高吞吐量、高擴展性的消息隊列系統(tǒng)。在數(shù)據(jù)需要“總線”來分發(fā)給不同的消費者，或者數(shù)據(jù)產(chǎn)生很快，如果數(shù)據(jù)消費不夠快，需要暫存的場景下，可以提升系統(tǒng)的效率。

看點三：超火的大數(shù)據(jù)數(shù)據(jù)倉庫與OLAP有哪些關鍵組件及特性？

大數(shù)據(jù)數(shù)據(jù)倉庫的主要功能是對大量的數(shù)據(jù)做系統(tǒng)的分析整理，以便于各種分析方法如聯(lián)機分析處理(OLAP)、數(shù)據(jù)挖掘(Data Mining)能夠順利進行，并進而支持如決策支持系統(tǒng)(DSS)、實時分析和查詢系統(tǒng)等。

（1）Presto

HDFS、S3、HIVE、KUDU、cassandra、mongoDB、ES、Mysql...越來越多的存儲架構(gòu)，而且各有特點，難以舍棄，那我們能不能用一個引擎統(tǒng)一做查詢計算，而不用使用不同的API呢？多源異構(gòu)分析引擎Presto/Trino就可以解決這個問題。Presto是一款內(nèi)存計算型的引擎，適用于交互式分析場景，同時其開源社區(qū)的良好集成，支持底層數(shù)據(jù)來自多種異構(gòu)數(shù)據(jù)源的交互式分析場景，比如工程師的交互式查詢分析、業(yè)務人員的交互式查詢分析、ETL等。在很多時候，Presto只連接HDFS，那么它就變成了一個OLAP引擎，在這個場景下，Presto最大特點是性能均衡。Presto單表查詢僅次于clickhouse，多表join查詢性能也很突出。但值得注意的是，Presto雖然比HIVE快，但到了PB級數(shù)據(jù)時，Presto沒辦法把所有數(shù)據(jù)放在內(nèi)存中處理。所以，需要邊讀數(shù)據(jù)、邊計算、邊清內(nèi)存。join的時候，可能產(chǎn)生大量的臨時數(shù)據(jù)，反而比HIVE慢。

（2）ClickHouse（CK）

ClickHouse（CK）是一個真正的列式數(shù)據(jù)庫管理系統(tǒng)，主要解決的是“大寬表”的多維分析問題。在很多數(shù)據(jù)倉庫的分析中，報表、交互式分析針對的目標表常常是一個大寬表（列很多），那是否能夠把大寬表的性能做極致呢？CK因此應運而生。CK的存儲模型MergeTree是最基礎的表引擎，提供主鍵索引、數(shù)據(jù)分區(qū)和數(shù)據(jù)采樣等所有的基本能力。其他能力，比如replace、sum等構(gòu)建在之上。目前，CK主要應用于BI報表、用戶行為分析系統(tǒng)、監(jiān)控系統(tǒng)、A/Btest等場景下。

（3）kylin

kylin是一個開源的、分布式的分析型數(shù)據(jù)倉庫。查詢分析有一些是常用的指標，那能不能將這些指標結(jié)果提前計算好，這樣一來，交互式查詢分析時只查詢預先計算好的結(jié)果，以此來達到亞秒級響應呢？預計算技術(shù)kylin就能實現(xiàn)。但需要注意，預計算計算技術(shù)可能會引發(fā)維度爆炸。如果一個表有N個維度的話，那么可能會產(chǎn)生2的N次方個預計算結(jié)果（類似2的N次方個物化視圖），如果計算方式很多的話，那會更多，導致嚴重膨脹，這時候需要從源頭上解決爆炸問題，比較好的方法是分析用戶行為，進而只對有必要的結(jié)果進行預計算。

看點四：大數(shù)據(jù)生態(tài)中，計算和存儲模型的總結(jié)！

本期直播也總結(jié)了不同的計算模型的優(yōu)劣勢，包括從計算視角的scatter/gather、mapreduce、MPP模型分類，從資源共享視角的share everthing、share disk、share nothing的存儲計算模型分類。