大資料的緣起、發展和未來構思

ITPUB社群發表於2022-12-05

引言

當下,大資料技術已經進入了普惠期,企業可以低成本且快速的構建大資料技術能力,全面連線業務,創造價值。本文從大資料的定義出發、梳理大資料技術發展的重要里程碑,並立足當下,思考未來的大資料技術演進方向。


大資料(big data)的定義

無法在可承受的時間範圍內用常規軟體工具進行捕捉、管理和處理的資料集合。目前,針對大資料的特點綜述,比較公認的是大資料的4V特性

  1. Volume:資料量巨大,2020年全球共擁有35ZB的資料量。
  2. Variety:種類多,包括結構化資料、非結構化資料,如今的資料型別早已不是單一的文字形式,訂單、日誌、音訊,多型別的資料對資料處理能力提出了更高的要求。
  3. Velocity:時效性,海量資料處理的時效性要求很高。
  4. Value:價值密度低,如何更迅速地完成資料價值“提純”是目前海量資料背景下亟待解決的難題。

大資料的緣起

  1. 上世紀末,隨著資料庫技術的成熟,一些商業智慧工具和商業資料庫儲存技術開始被應用。
  2. 2000年初,社交網路流行導致的大量非結構化資料出現,且資料量飛速增長,資料處理系統、資料庫架構開始重新思考。
  3. 2011年麥肯錫全球研究院釋出《大資料:下一個創新、競爭和生產力的前沿》
  4. “雲端計算相遇大資料”為主題的EMC World 2011會議中,EMC丟擲了Big Data概念。
  5. 2012年維克托·舍恩伯格《大資料時代:生活、工作與思維的大變革》宣傳推廣,大資料概念開始風靡全球。
  6. 2013年5月,麥肯錫全球研究院釋出了《顛覆性技術:技術改進生活、商業和全球經濟》,其中12種新興技術,並且把大資料技術定義為了基石。
  7. 2014年5月,美國白宮釋出了2014年全球“大資料”白皮書的研究報告《大資料:抓住機遇,守護價值》。報告鼓勵使用資料推動社會進步。

大資料技術的發展

2000年初,提供搜尋服務的公司,Google陸續發表了三篇論文GFS(Google File System)、MapReduce(分散式平行計算框架)、BigTable(大資料分散式資料庫),除了創造了三項革命性技術以外,還拉開了hadoop發展的序幕。

2003-2004年,Google公佈了部分GFS和MapReduce思想的細節,受此啟發的Doug Cutting率先在Nutch(搜尋框架,包括爬蟲、索引、查詢)專案中使用分散式計算思想,使效能飆升。

2005年,Hadoop作為Nutch的一部分正式引入Apache基金會。

2006年1月,Doug Cutting加入雅虎,並在2月hadoop被分離出來,成為一套獨立的軟體,起名為Hadoop(Doug Cutting兒子毛絨玩具象命名)。

2006-2008年4月,雅虎網格計算團隊不停的最佳化和測試hadoop,叢集規模也從最初的100餘個節點發展到4000個節點,同時,也贏得世界最快1TB資料排序,在900個節點上用時209秒。

2008年9月,Hive成為Hadoop的子專案

2008年11月,Google宣佈其MapReduce用68秒對1TB的程式進行排序。

2008年, 淘寶開始投入研究基於Hadoop的系統–雲梯。

2009年5月, Yahoo的團隊使用Hadoop對1 TB的資料進行排序只花了62秒時間。

2009年,伯克利大學的實驗室研發出了Spark,主攻一站式分散式記憶體計算框架、同時支援批處理和準實時計算。

2010年,資料湖概念產生。

2010年-2011年,各大模組脫離hadoop成為apache頂級專案,包括avro、hbase、hive、pig、zookeeper,同時hadoop社群也在忙於建立大量的新元件,包括sqoop、oozie、flume等,來擴充套件hadoop的使用場景和可用性。

2014年,Stratosphere 0.6開始,正式更名為Flink,併成為apache孵化專案,Flink誕生,對Spark都發出了挑戰。flink被定義為統一的大資料分析和流計算引擎、下一代大資料處理引擎。

2017年-2019年,資料湖開源解決方案Delta、Hudi、Iceberg逐步完善。

2018年-至今,湖倉一體、一體化資料平臺、DataOps、資料編織等概念興起。

在2010年附近,圍繞hadoop生態體系構建的商業,也如雨後春筍般成長,國內外廠商紛紛佈局


2009年3月,Cloudera推出CDH。

2009年12月,運營商合作伙伴亞信提出橘雲戰略、開始對開源hadoop進行研究佈局。

2010年5月,IBM提供基於hadoop的大資料分析軟體InfoSphere BigInsights。

2011年3月,Platform Computing宣佈Symphony軟體支援hadoop。

2011年4月,SGI( Silicon Graphics International )基於SGI Rackable和CloudRack伺服器產品線提供Hadoop最佳化的解決方案。

2011年5月,Mapr Technologies公司推出分散式檔案系統和MapReduce引擎——MapR Distribution for Apache Hadoop。

2011年6月,資料整合供應商Informatica釋出了其旗艦產品,支援Hadoop。

2011年7月,雅虎建立了Hortonworks,併發行HDP產品,並迅速成為了hadoop三大發行版本之一,目前國內的很多發行版本都基於HDP進行二次封裝和改造。

    

大資料技術發展核心事件

hadoop發展至今,已經從最初HDFS、MapReduce、和Yarn的合稱,變成了大資料技術體系的代名詞。幾乎所有采用分散式理論解決海量資料的採、存、算、查的技術都可以稱為大資料技術。從大資料平臺(整合大資料技術能力、提供企業級解決方案)的發行版本來看,Hortworks的開源產品HDP、apache開源設計版本hadoop、以及cloudera付費版本CDH三足鼎立(18年末,CDH和HDP合併為CDP,並徹底閉源)。從技術生態來看,後續發展起來的大規模資料儲存、實時計算等框架,或多或少都受到了hadoop的啟發,同時,幾乎都天然適配hadoop。至此,圍繞hadoop生態圈構建的商業和技術體系也愈加完善。

縱觀hadoop生態技術的發展史,除了Google公佈GFS、MR、BigTable有劃時代的意義以外,還有幾個里程碑事件尤為重要。第一個是hive的產生,hive作為資料倉儲工具,支援開發人員基於sql完成大規模資料的分析、計算,大大降低了開發複雜度。第二個是spark的產生,基於彈性分散式資料集的一站式記憶體計算框架(支援批處理、準實時處理、機器學習、圖計算)等,面對大規模的資料計算場景,如果早期MapReduce是為了解決海量資料可以被計算的問題,那麼spark在計算層面的最佳化,解決的問題是算的更快。第三個flink的產生,同樣是以新的理念,最佳化了計算框架,解決的是有狀態資料的流式計算問題,同時,被定義為統一的大資料分析和流計算引擎、下一代大資料處理引擎。目前很多企業,包括 BAT、華為、滴滴、美團、餓了麼、攜程、360、順豐、愛奇藝、UBER等。都在大規模使用flink作為他們的核心計算引擎。第四個是資料湖概念的興起,尤其是與雲原生理念結合後,作為全新的企業資料底座,支撐企業資料活動,是當下乃至未來3-5年一個重要的發展方向。

從以上里程碑事件可以看出端倪,那就是大資料技術的發展趨勢,沿著更普惠(開發複雜度低)、效率更高(計算模型最佳化)的方向發展,同時,隨著人們對資料生產要素的重視逐步升級,如何去挖掘更大的價值?如何構建一套靈活的資料架構,來支撐圍繞資料的經營活動?是當下經營決策者思考的命題。大資料技術面臨最大的挑戰變成了,如何將資料生產要素快速連線到業務,實現資料的敏捷製造,讓資料要素釋放生產力。


大資料的緣起、發展和未來構思大資料技術發展


大資料技術體系一級架構

大資料的緣起、發展和未來構思大資料技術體系一級架構


前面提到過,所有采用分散式理論解決海量資料的採、存、算、查的技術都可以稱為大資料技術。所以,大資料技術體系一般包含以上幾個重要模組,可以看出,基本是圍繞業務更好的用數來發展的。其中有幾個需要注意的點。

  1. 多引擎分散式計算:目前大資料計算引擎很多,如專注於批處理的mapreduce,起步很早,但詬病於計算過程中多次刷寫磁碟,效能較低,目前已經逐步被淘汰掉。spark,將計算任務解析成DAG,並且大部分計算在記憶體中完成,可以很大程度的提高計算效率,同時支援批處理和準實時處理(SparkStreaming),完全可以當作mapreduce的替代,目前開源的資料湖解決方案內建的計算引擎就是spark,江湖地位逐步走穩。flink,下一代大資料處理引擎成為新銳,勢頭正猛。因為技術的不停發展迭代,當下很難評判孰優孰劣,所以,在不同的應用場景,會選擇不同的計算引擎。目前比較常見的做法是,在計算之上構建一個公共介面層,來遮蔽各個計算引擎的程式設計細節,對外開放SQL的介面,最大程度的降低開發門檻。
  2. 一站式資料工作臺:開發人員基於視覺化的方式,完成資料架構的設計、資料標準、資料質量的制定、同時,可以快速完成資料的採集、ETL開發排程、以及資料服務的編排、開放。基本涵蓋了所有的資料操作,並且很好的完成了開發即治理。一站式資料工作臺向上承接業務,向下連線基礎平臺。目前很多所謂的”中臺產品”做的基本就是這個事情。但是工具是工具、中臺是中臺,中臺的事情可不是一個工具可以解決的。
  3. 即席查詢:解決的是面向分析場景的互動式查詢問題。追求的是更快的儲存,更實時的資料更新,更牛的OLAP最佳化技術。我們一直強調資料架構的靈活性,其實這裡有一個矛盾點,如果要靈活,就要最輕程度的聚合資料,如果資料聚合度較低,資料就不能很好的被壓縮,那麼查詢就會變慢。即席查詢在技術棧上,有兩種方式,一個是採用MPP架構,如impala、ck等技術。另一個是偏向大資料架構,如presto、kudu。

大資料技術的未來構思

hadoop存算一體架構向存算分離架構演化:在大資料計算場景中,我們一般採用移動計算、不移動資料的策略來進行最佳化,會將計算節點和資料節點部署在一起,這會導致三個核心問題,叢集規劃難(存算耦合、機器帶狀態,無法彈性擴縮容)、運維負擔重(壞盤壞節點無法避免)、儲存成本高(容量預留)。在萬物雲原生的今天,資料儲存層可以物件儲存為主,計算資源基於K8S進行彈性擴縮容,可以很大程度的滿足潮汐計算的需要。

資料湖解決方案逐步替代傳統hive數倉:hive最大的問題在於對upsert的能力支援較弱,並沒有寫scheme的校驗。在歷史資料發生變化的資料整合場景中,需要設計複雜的ETL架構,如拉鍊表等,來做upsert的增強,這無疑增加了系統複雜度,同時提高了資料儲存和開發成本。如今,iceberg、hudi和delta都很好的支援了upsert能力,並支援資料的實時寫入,可以更好的簡化資料ETL的複雜度。

流批一體化:目前很多公司依舊採用lambda架構,這種架構的缺點是需要同時維護實時和批處理兩套架構,這樣會導致資料口徑不一致、資料維護成本高等等一系列問題。基於flink技術,實現計算引擎的統一、業務層邏輯的統一,以一套語義完成資料開發,可以更好的提高效率。
多雲一站式DataOps:一站式資料平臺的升級版,目前一站式資料平臺更多的是為了落地資料治理,來規約全鏈路資料開發的規範性,提高全鏈路的資料流轉效率。但這遠遠不夠,未來的企業的IT基礎設施會在多雲之上,如何同時實現多雲一站式DataOps,並且真正實現基於後設資料驅動的DataOps,才是當下要思考的問題

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024420/viewspace-2926739/,如需轉載,請註明出處,否則將追究法律責任。

相關文章