大數據生態之數據處理框架探索

數據處理框架

數據處理是一個非??矸旱母拍?數據處理框架在數據架構中,主要是用于數據移動和分析這兩大功能當中.對于數據移動,有離線數據移動和實時數據移動,也可以叫做是批量數據移動和流式數據移動.而對于分析這一塊,有離線數據分析和實時數據分析,也可以稱作是批量數據分析和流式數據分析.離線和實時,批量和流式,針對這兩種不同的形式,就出現了多種不同的數據處理框架.有批量的數據處理框架,有流式的數據處理框架,也有批流融合的框架.

批量數據處理框架

批量數據處理框架最經典的就是 mapreduce 了,這也是 apache hadoop 最早期的形態,使用 mapreduce 對 hdfs 上面大批量的數據進行計算和處理.基于它寫出來的應用程序能夠運行在由上千個商用機器組成的大型集群上,并以一種可靠容錯的方式并行處理大批量的數據集。但是由于 mapreduce 的編寫并不很直觀,對于開發人員的門檻較高,之后在 mapreduce 之上出現了新的產品,做為 mapreduce 的升級產品.那就是 apache pig 和 apache hive. Apache pig 和 apache hive 都是基于 mapreduce ,并給開發人員提供了更加簡便使用的方法和接口以及更加豐富的語義處理.

  • Apache Pig是MapReduce的一個抽象。它是一個工具/平臺,用于分析較大的數據集,并將它們表示為數據流。Pig通常與 Hadoop 一起使用;我們可以使用Apache Pig在Hadoop中執行所有的數據處理操作.
Apache Pig MapReduce
Apache Pig是一種數據流語言。 MapReduce是一種數據處理模式。
它是一種高級語言。 MapReduce是低級和剛性的。
任何具備SQL基礎知識的新手程序員都可以方便地使用Apache Pig工作。 沒有相關經驗難以編寫
在Apache Pig中執行Join操作非常簡單。 在MapReduce中執行數據集之間的Join操作是非常困難的。
Apache Pig使用多查詢方法,從而在很大程度上減少代碼的長度。 MapReduce將需要幾乎20倍的行數來執行相同的任務。
沒有必要編譯。執行時,每個Apache Pig操作符都在內部轉換為MapReduce作業。 MapReduce作業具有很長的編譯過程。
  • hive是基于Hadoop的一個數據倉庫工具,可以將結構化的數據文件映射為一張數據庫表,并提供簡單的SQL查詢功能,可以將SQL語句轉換為MapReduce任務進行運行。其優點是學習成本低,可以通過類SQL語句快速實現簡單的MapReduce統計,不必開發專門的MapReduce應用,十分適合數據倉庫的統計分析。
Apache Hive MapReduce
通過SQL輕松訪問數據的工具,從而實現數據倉庫任務,如提取/轉換/加載(ETL),報告和數據分析。 需要使用 java 等編程語言編寫 mapreduce 程序來實現
對于各種不同的數據格式,可為之添加各種抽象的結構化信息,比如表,分區,桶 只能對原始數據進行手動的原始的文件管理
可以直接訪問多種數據存儲系統,包括 hdfs 和 hbase 等 只能直接訪問 hdfs
可以使用更加除了 mapreduce 之外更加高級的執行引擎,比如 apache tez,apache spark 只能以 hadoop 作為執行引擎,效率低

Hive 和 Pig 最大的不同就是一種使用 Latin 語言,一種使用 HiveQL 語言.這就導致了如今 Hive 成為了絕對的主流,Pig 已經很少人用了.HiveQL 這種類 SQL 語言解決了批量數據處理的易用性問題,現在不僅開發人員能夠編寫大數據處理程序,普通的分析人員和業務人員也能夠使用Hive進行大數據處理和分析. 但是 Hive 并沒有解決速度問題,于是在 Hive 之上,基于 Hive,又出現了新的數據處理技術和框架,比如 impala,presto,kylin 等,這個領域技術方案非常繁榮.這里不贅述。

流式數據處理框架

流式數據處理,也稱實時數據處理.數據是一條一條產生的,當數據產生的時候,我們可以把它先存起來,供后續處理,這就是上面所說的離線(批量)數據處理.而現在越來越多的做法是數據產生時就立馬對它進行計算和分析,而這就是實時數據處理或者叫實時計算.而數據理論上是不斷產生的,不斷產生的數據不斷的發往數據處理框架進行計算和分析,就像一條流,所以實時計算也稱作是流式計算.還有一種做法是把批量數據讀成一條一條的進行處理(比如 nifi).所以流式計算處理的不一定是實時數據,也可能是離線數據.
流式框架最經典,也是最老的就是 Storm,Storm 一款開源分布式實時計算框架.它相對比較穩定,具有高容錯性,也比較高效.

Storm 的基本概念:

  • Stream
    以Tuple為基本單位組成的一條有向無界的數據流
  • Tuple
    Integer,long,short,byte,string,double,float,boolean和byte array,包括自定義類型.
  • Topology
    計算邏輯的封裝
    由spouts和bolts組成的圖,通過stream grouping將圖中的spouts和bolts連接起來
    類同MapReduce中的job.

Storm 是一款比較老的框架,流式計算的開創者,推出后也有非常廣泛的應用.流式計算的框架技術一直不斷發展,后來也出現了Storm的類似框架 samza.
國內阿里巴巴也對 Storm 進行了改良 : jstorm ,jstorm 更加穩定,功能更強大. 對 Storm 來說,現在處于一個英雄垂暮的階段,很多特性是在它那個時代是沒有考慮過的.

最近幾年,流式數據處理領域,又出現了一些新的參與者.由于流式數據往往不是直接發往流式計算平臺進行處理,它需要一個中間層過渡,進行數據的緩沖,緩存和分發,這個中間層就是通常我們所說的消息系統,消息中間件.(老的說法也叫消息隊列,但現在的消息系統要比消息隊列復雜和強大很多倍).幾乎所有的流式計算過程都會前置一個消息系統.所以后來消息系統就干脆集成上流式數據處理的功能,把流式數據處理也一并做了.現在最流行的消息系統就是 kafka ,kafka 在2017 年就推出了 kafka streams.消息系統的后起之秀: apache pulsar ,自帶 Pulsar Functions,一個流式數據處理引擎(pulsar 號稱是 kafka 的替代品 ,這部分內容待補充)。

Kafka Stream 現在是一個 lib 庫,使用這個庫可以很方便的構建以 kafka 集群為數據來源的應用和微服務. Kafka streams 最大的特點就是它較為簡單,對于開發人員來說門檻比較低:

  • 開發只需要一個簡單 lib 包,除了 kafka 外沒有其余外部依賴了
  • 保證只處理一次的語義,開發人員不需要額外關心
  • 不僅支持一條條處理數據,也能夠基于窗口操作處理多條數據
  • 對于流式處理提供高級簡單的DSL ,也提供比較低級的處理接口

Kafka Stream 處理的拓撲圖:

  • stream 是一個抽象概念,代表了沒有邊界的,持續更新的數據 record 流. Data record 是一個鍵值對.
  • stream processor 整個拓撲圖中的一個節點,代表中間的一個處理步驟.有2個特殊的processor: source processor ; sink processor
  • stream processing application 一個流式處理應用可由多個處理流程構成:

批流融合數據處理框架

無論是批量處理還是流式處理,技術框架的發展最終都要走向統一,變得更加簡單,更加易用.而Spark 就是這個統一者.Spark 框架一經出現,立馬就流行起來.如今 Spark 是一個統一的大規模數據處理和分析計算引擎,并且也有非常豐富的spark 生態,官方生態有 DataFrames and SQL (批處理引擎,其中SQL 是比hive 更快的查詢引擎),Spark Streaming(流處理引擎),MLib(機器學習庫),GraphX(圖計算引擎).還有很多基于Spark 的第三方生態.比如 apache mahout(用于開發機器學習應用的框架),Koalas(Python庫 pandas 的 Spark 版本).
還有前不久開源的Delta Lake,一個基于 Spark 的數據湖解決方案,它作為一個數據存儲層(storage layer),具有非常強大的特性.

Spark 是這個領域老牌框架,但是也有后來者.那就是 Flink,這個數據流計算的新貴.

Flink 的出現是為了解決 Spark Streaming 的一個設計缺陷,Spark Streaming 的設計是通過 micro-batch 微批處理來模擬流處理,實際上并不是真正的流處理.也就是說 Spark Streaming 是達不到 Storm 那樣毫秒級的低延時的.Flink 解決了這個問題,它是真正的流處理,真毫秒級的低延時.
雖然,Spark Streaming 在新版本中推出了 Structure streaming,廢棄了之前的微批處理,也達到了真正的低延時.不過,目前,國內的公司還是越來越多選擇 Flink 作為核心的數據處理框架.這里引用 OPPO 大數據平臺負責人張俊的一句話:
但是我們認為,整個技術框架發展,技術最終肯定是趨同的。為什么選擇 Flink?還有一個很重要的原因是最近兩年 Flink 在國內的發展普及程度。包括像阿里團隊,他們也在大力地宣傳跟投入,包括今天 QCon 大會上大沙和云邪兩位老師,他們也是阿里團隊社區的資深大 V。


批流融合處理框架還一個小眾的框架 Apache Apex,跟 Flink 差不多.

批流融合之上

上面說過,技術框架的發展最終都要走向統一.如今批流數據和流式數據處理現在統一了,那還能繼續統一嗎.答案是能.目前批流一體數據處理框架有Spark,有 Flink ,還有基于公有云的 google cloud dataflow.由于開源,這些技術框架都會相互借鑒,最終都會是大同小異.所以就有辦法把這些處理框架再統一起來,形成一個統一的編程模型.這個就是 Apache Beam.
Apache Beam 不是一個數據處理引擎,它不自己處理數據.它只是一層 layer.這層 layer 可運行在各種不同的數據處理引擎之上,比如 spark ,flink 等.它的作用簡單來說,就是beam編寫的一套代碼,可以直接運行在 spark,flink 等各種不同的數據處理引擎中.


Apache beam 本質上是一套 sdk ,這一套 sdk 使用統一的編程模型來編寫批處理和流處理程序,并且還提供了不同語言的比如python,go ,java的版本.
Beam 提供的這個編程模型就是 Pipeline,使用 beam 來編程,其實就是構建好一個 pipeline ,也可以叫做是數據處理程序的抽象.

這就是一個基本的pipeline,其實跟spark ,flink 中的DAG 圖都差不多.

Pipeline 編寫時,我們要指定它的runner,這就是 apache beam 的另一個抽象
Runner 即 pipeline 的執行引擎,例如 spark Runner,flink runner 等.beam 就是通過這個 runner 使得 pipeline 可以運行在多種不同的分布式運算框架上.

未完待續

數據處理框架一直飛速發展,但總體來說,有一個清晰的內在發展邏輯:那就是在易用性上,統一性上,經濟性上不斷向前。目前的國內的一個趨勢是整個大數據棧也在往云上走,因為云完全契合這三點。

posted @ 2020-03-03 09:33  hdpdriver  閱讀(...)  評論(...編輯  收藏