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

引言

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

大資料（big data）的定義

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的複雜度。