2009年，Spark誕生於計算機系統的學術聖地加州大學伯克利分校的AMP Lab，最初是一個研究項目，後來於2010年正式開源，並在2013年貢獻給Apache基金會，翌年即畢業成爲Apache基金會頂級項目。對於一個具有相當技術門檻與複雜度的平臺，Spark從誕生到正式版本成熟，整個過程僅僅花了五年時間。誕生之初，Spark就致力於提供基於RDD/DataFrame的一體化解決方案，將批處理、流處理、SQL、機器學習、圖處理等模型統一到一個平臺下，並以一致的API公開，使得Spark在誕生後的十年間得以應用於更加廣泛的工程領域，快速成長爲大數據處理引擎中的佼佼者。
2019年是Spark誕生的第十個年頭，Spark引擎自身以及它孵化出來的Spark生態都在不斷迭代和演進。近日，InfoQ記者在AICon全球人工智能與機器學習大會 北京 2019 現場採訪了Databricks軟件工程師李元健，他與我們分享了根植於Spark各個發展階段的統一數據分析理念、Spark社區接下來工作的重點，以及大數據領域需要關注的變化和趨勢，以下爲採訪問答實錄。
InfoQ：李元健老師您好，非常高興這次能夠在AICon現場採訪到您。您這次準備的演講主題是《Databricks在構建統一數據分析平臺上的新一輪實踐》，能否先跟我們解釋一下，何爲“統一數據分析平臺”？其中的“統一”包含哪幾個層面的含義？
李元健：統一的數據分析平臺其實是各大互聯網公司和軟件公司始終奉行的一套設計準則，不僅植根於Databricks，我們期望用統一的一套平臺解決方案來滿足多種場景需求甚至跨場景需求。這個“統一”不僅僅是技術層面的API、底層抽象的統一，更是某種程度上的上層使用者協作方式的統一。Spark就是用統一的RDD/DataFrame API來配合現有的Hadoop生態，構造出來這樣一套系統，可以適用於多種環境，讓使用者和學習者可以用一套系統完成多樣的任務，不需要跨領域學習。
這需要在底層有一個完全統一的抽象，只有在抽象的時候就考慮得足夠深，纔可能在後續把各種各樣的場景完整地串在一起，打破邊界，做出全局的優化。但是這個抽象也不能太過，比如做成像MapReduce那樣最簡單的抽象，那上層實現需要做的東西會很多。這中間的難點就是要把握好抽象的度，能讓它籠罩的面足夠大，同時也要足夠小。
在Spark誕生之初，Hadoop作爲當時的大數據主流生態，涌現了各種相關的項目：用於批處理的MapReduce、Pig和Hive，用於流處理的Storm，用於機器學習的mahout，用於ETL的sqoop。這些產品由不同團隊、組織開發，API設計理念各不相同，使用複雜、集成困難、學習門檻陡、維護成本高。隨着Spark倡導的統一數據分析理念的發展，Hadoop各個項目由盛轉衰，逐漸被Spark的對應項目取而代之。我們相信，無論大數據還是小數據，無論公有云還是私有云，無論批處理還是流處理，無論數據查詢還是數據分析，數據分析行業未來將由單一的統一分析引擎主導，並應用於不同的平臺解決各式各樣的問題
InfoQ：爲什麼需要在上面提到的這幾個層面上達成“統一”？
李元健：統一意味着打破多系統邊界，數據計算的執行計劃將會全局優化，提升了總體的性能，數據不再來回從各系統中搬來搬去，極大降低數據治理、架構設計及運維成本。與此同時，統一也打破了團隊之間的邊界，大幅提高了協作的效率，跨領域的用戶可以在一套系統之下協作完成各項工作。從每個參與者角度來看，統一更意味着學習成本和協作成本的降低。
InfoQ：這樣一個統一的數據分析平臺對於大數據領域來說有什麼樣的意義？如果業內不只Databricks在做統一數據分析平臺，其他公司可能也想做自己的統一平臺，那最後怎麼真正做出一個能打通所有系統的平臺呢？
李元健：統一的數據分析平臺對降低數據處理成本、加速數據迭代、提升數據價值都有極大的促進作用。Databricks在業界首先提出統一數據分析平臺的理念，並將這一理念在過去若干年付諸於實踐，熔鑄於Databricks產品及參與、主導的開源項目中去。所以我們今日已經可以看到統一數據分析的概念已經逐漸被市場與友商所接受。
接上述回答，其他公司也想做自己的統一平臺恰恰也是市場認可的一部分，因爲模仿是最好的讚賞，Databricks也一直持開放的態度歡迎各方的合作與競爭，相信在百花齊放的前提下，市場會篩選出事實標準。
InfoQ：Databricks在很多公開場合多次強調過“統一數據分析平臺”的概念，這一點在你們當前的技術架構和主導的開源項目中有哪些體現？
李元健：首當其衝的開源體現是Apache Spark，Spark可以說是業界首個達成統一數據分析能力的數據分析平臺，對上，支持交互式查詢、批處理、流處理、機器學習、圖計算等使用場景；對下，支持基本上你能見到的所有數據格式類型，包括Parquet、Text、Json、ORC等，同時所有數據源類型，包括流式的kinesis、Kafka等Spark都能有機地統一起來，不會像原來Hadoop那樣，把一堆散落的零件丟給用戶，讓用戶自己去拿MapReduce拼。2019年是Spark誕生的第10個年頭，統一數據分析的理念始終植根於Spark的各個發展階段。
隨着Spark的成功，近幾年內Databricks主導的全部開源項目，也遵循統一數據分析的理念，讓Spark可以解決更多的使用場景，擴大使用的用戶羣體。Koalas解決了pandas的可伸縮性（scalability），讓使用單機pandas的數據科學家們也可以輕鬆利用Spark解決他們的大數據問題。 Delta Lake通過其優秀的事務性特點，簡化了複雜冗長的數據處理pipeline的建造，使得批流一體變得輕而易舉，對數據湖的場景提供了完美方案。MLflow致力於打破機器學習各階段跨系統的弊端，完成模型訓練、特徵工程、模型管理的各階段打通與統一。
InfoQ：那麼構建統一數據分析平臺存在哪些難點？你們在實踐中是如何解決這些問題的？
李元健：難點之一在於如何建立一個通用引擎去支持不同需求，讓複雜變簡單。抽象邏輯的統一及高效實現，比如Apache Spark中RDD的抽象概念是Spark的核心概念。同時這種核心抽象也是在不停迭代的，比如Apache Spark 1.6版本之後，實際上新的Spark核心抽象迭代爲Dataset API。
Databricks始終堅持data driven。這個也是我們公司文化的一個核心價值觀。我們通過用戶的使用日誌做大數據分析，來選擇如何改善我們的產品，推出什麼新的產品。對於一個初創公司，如何對需求說不，如何在有限的資源裏選擇最重要的事情是最大的挑戰。MLflow、Delta Lake、Koalas這些系統的誕生均是data driven。
InfoQ：能否請您進一步談談Spark的基因是什麼？和其他的相關項目（比如，Ray）有什麼不同？您預期Spark主流地位可能會在未來什麼時候受到威脅？
李元健：Spark來自學術圈，誕生於加州大學伯克利分校。這所學校對計算機學科和工業界的貢獻相當之大，尤其是操作系統和數據庫這些方向。在Spark初期的設計和技術討論氛圍非常濃厚，算是學術血統相當純正，後來加入Apache基金會後，工業界的各大公司參與了各方面的研發，做出了大大小小的貢獻。因此，Spark的基因也在不斷地優化，混入了更多工業圈研發基礎設施軟件的經驗和風格，產品漸漸趨於成熟和穩定。而Ray其實算是Spark的姐妹項目，都是出自於Ion教授的實驗室。如今，Ray還處於早期研發階段，工業界的參與還是相對比較少，將來的普及和成熟都言之尚早。
建立數據分析的統一平臺是創建Spark最初的一個方向和目標。如今，Spark SQL作爲新一代的Spark Core。我們相信我們可以通過同一套執行引擎解決各種計算和分析的需求，並且可以跨多個不同的用戶場景做全局優化。這個信念是從始至終在貫徹的。漸漸地，其他類似項目也都在追隨我們這個目標，甚至使用同一套術語在宣傳，這種認同，我們倍感欣慰。
事實也證明，Spark很好地解決了Hadoop生態系統分裂的難題。Hadoop生態圈越來越複雜，用戶體驗差，很多項目立項但是無法投產，更無法快速產生商業價值。而Spark通過構建一個統一數據分析平臺來填平各系統間的使用鴻溝，讓大數據問題變得簡單，讓更多的公司和機構從大數據中獲益，也改變了我們每個人的日常工作和生活。
從目前的發展情況來看，我們看到大數據產業鏈裏有不少優秀的產品在不斷髮力，通過新的硬件加速，或者提供更加豐富的功能來更好地解決某個細分領域問題。但是，作爲數據的統一分析和處理平臺，十年前 Spark 的發明在很多場景逐漸取代了 Hadoop計算層，未來若干年間，也隨時有可能有其他優秀項目出現並試圖取代或部分取代 Spark。此外，現在的系統集成度和兼容性要求都很高，完全取代一整個生態的難度相當大。Spark 也只是取代了 Hadoop 的 MapReduce 計算層，對生態中的其他組件仍然是兼容幷蓄。而且即便是取代單一組件，如果沒有 10x 的差異、不能推動關鍵的新型使用場景，極難推動現有用戶遷移。
Databricks 本身是一個強調持續創新的公司，我們致力於自己革新自己，這也是 Delta、Koalas、MLflow 等新近開源項目逐漸涌現的主要原因。當然我們期望能有更革命性的東西出現，不管是來自Spark社區，還是來自Databricks公司，還是來自其他團隊。
InfoQ：對於剛剛發佈的Apache Spark 3.0預覽版，很多開發者非常感興趣。能否請您給我們解讀一下，3.0版本中有哪些與統一數據分析相關的重要特性？
李元健：Spark SQL作爲新一代Spark的核心抽象，3.0中涉及衆多SQL層的性能提升，比如Dynamic Partition Pruning以及社區內呼聲很高的Adaptive Execution，SQL層的性能提升可以輻射到Spark的各個上層組件。
調度層面，Apache Spark 3.0新增GPU這種加速器的資源調度，並且逐步完善了Spark on K8s。
另外，Data Source API以及新的catalog支持可以讓Spark更好的接入各種數據源提供統一的計算和更準確的分析結果，是統一數據分析的最好體現。
當然，這裏只能列舉一小部分，Spark 3.0解決了近3000個問題。我們在release notes裏面會有更多的描述，歡迎大家去試用我們3.0的第一個預覽版本。
InfoQ：有讀者反饋在Spark 3.0的預覽版中好像沒有看到多少Streaming/Structed Streaming相關的ISSUE，能否解釋一下這是爲什麼？
李元健：如之前介紹，Spark SQL作爲新的Spark核心抽象，所有SQL層的迭代都可以體現在Structure Streaming之上。同時，Databricks對於流式計算領域的戰略可以理解爲Structure Streaming+Delta Lake=New Spark Streaming，解決了流處理的數據一致性問題。所以Delta Lake本身就是Structed Streaming的一部分。此外，Delta Lake作爲獨立的開源項目與Spark Structure Streaming 和 Spark SQL集成，提出了全新的一套Delta Lake架構，來取代當前最流行的Lambda架構。具體的feature層面，我們會有全新的Streaming UI，會有新的data source API去支持流入流出。
InfoQ：接下來Databricks和社區對於Spark還有哪些規劃？接下來有哪些方向是Spark社區會重點關注或重點去做的？
李元健：首先需要強調，Apache Spark的開發是由社區驅動的，Databricks只是Spark的主要貢獻者。雖然從Databricks成長出了大量的Committer，但是社區不應該由任何一家公司控制，任何所謂的控制都是違反Apache 開源精神的。所有Spark的重要feature以及關鍵的點都是由社區的需求驅動的。到目前爲止Spark已經有十年的歷史了，全世界大大小小的公司和組織都在使用和貢獻。Spark社區的多元化和活躍度是有目共睹的，來自全世界的貢獻也驅動着Spark去解決不同使用場景中的相關問題。Spark的committer來自於超過三十家公司和機構，有IT巨頭Apple、Google、Facebook等；有特定行業的領導者，Nvidia、Netflix、Uber、Linkedin、eBay等；也有獨角獸級別的創業公司，Databricks、Stripe等；還有頂尖院校，比如加州伯克利大學、斯坦福大學、普林斯頓大學；當然也有國內的IT大廠，比如阿里、騰訊、華爲和京東。大量用戶和社區的committers每天在報問題、報需求，提出自己的想法和解決方案。Databricks作爲主要的貢獻者，我們會繼續朝着統一分析平臺的方向發展，去更好地解決更多用戶場景問題，提升用戶體驗，增加用戶基數。
說回Spark社區接下來的幾個主要的發力點，Spark的成長方向始終就是兩條線，一個是Spark自身引擎的迭代，另外一個是藉助Spark孵化出來的Spark生態。首先是SQL的不斷演化，目前Apache Spark 3.0發佈的一系列工作還在推進當中，大家可能看到的，比方說DataSource API，比方說ANSI SQL的一系列的標準，都還在進行當中，這是對Spark Core持續不斷的優化。另外Spark從技術上還會生長出新的東西，這個大家也可以期待一系列新的場景和融合。Spark周邊生態的構建也是重點，相信我這次分享裏着重介紹的Koalas及Delta Lake就是很好的例子。隨着Data Source API 的不斷完善，我們相信Spark生態圈會進一步地擴展和加強。未來Databricks也會全力去完善Spark生態版圖，繼續保持Spark在數據處理和分析的領先優勢。
InfoQ：如果請您回顧大數據領域過去這一年，您認爲有哪些進展和變化值得一提？
李元健：雲的力量已經完全不可忽視了，雲化進程一直在持續往前推進，無論是從技術上還是商業上，都能看到2019年全年整個領域對於雲化的需求的不斷增長。與2018年頭部三大雲廠商增長50%不同的是，2019年增長的主角開始從頭部的大的雲廠商開始向小規模公司、初創公司轉移，Databricks也是其中的一員。在商業的刺激下，雲化技術如K8s及雲化生態持續蓬勃發展。大公司現在也變得越來越Open，不會什麼都想把控在自己手裏，而是更願意和小公司聯合，比如Databricks和Azure、AWS等一系列雲廠商都有合作關係。
大數據領域這一年是多事之秋。Hadoop在不斷萎縮，從Hadoop的三個發行商市值蒸發的速度就能看出。但相反，Databricks這一年獲得兩輪融資，估值大幅提升到62億美金。這種反差恰恰說明市場對Unified Analytics Platform + Open Source + Cloud + AI 的肯定。大數據和小數據的邊界會越來越模糊，客戶需要的是一個統一的分析平臺，解決實際的數據處理和分析問題。隨着數據急劇增長，未來數據存儲和處理都會逐漸遷移到更廉價的公有云，讓資源更合理的集中彈性調配。如何快速從數據中挖掘出信息來改善決策是重點。
InfoQ：未來大數據領域還有哪些重要的技術方向或趨勢值得關注？
李元健：個人認爲有一項趨勢已經持續了數年，就是多個數據分析領域的融合，包括傳統數據庫、分佈式計算以及檢索技術，這種趨勢也促成了統一分析理念的形成。雖然目前有數量繁多的新框架、引擎，但大家能夠注意到，數據管理能力依舊沒有跟上數據爆炸式增長的速度。所以在這種融合趨勢的推動下，立足於新的場景，原有的很多理念和設計會重新煥發光彩，舉個實際例子，Delta Lake本身就是最典型的例子，Delta Lake最核心的ACID支持就是傳統數據庫的基本功能，但Delta Lake基於Spark上的ACID Table解決了大量痛點，很快成爲關注度極高的開源項目。
我剛纔沒有提到Databricks的一個拳產品，就是MLflow，我們下一步希望融合的場景就是在智能計算，以及AI領域。如果我們把整個AI看作火箭，大數據是其中的發動機，我們如何能讓發動機的設計和火箭的設計一體化，在這個過程當中，我們能做的東西還有很多。大數據和AI當前的狀態其實多少有些割裂，就像一個公司的算法工程師和數據工程師一樣，現在還是分置的兩塊，如何進一步融合，也許會是一個新的藍海。
此外，未來公有云是數據處理和分析的最佳平臺，所以雲原生的解決方案是趨勢也是重點。比如，如何在pay as you go這種收費模式下，基於數據來驅動開發、定價和決策；如何提供Serverless的服務，在軟件架構、交付和部署上做創新；如何打破現有的大數據框架，去更好與現有的雲計算服務融合，提升用戶的使用體驗等。
採訪嘉賓介紹：
李元健，Databricks軟件工程師。曾於2011年加入百度基礎架構部，先後參與百度自研流式計算、分佈式Tracing及批量計算系統的研發工作，2017年轉崗項目經理，負責百度分佈式計算平臺研發工作。2019年加入Databricks Spark團隊，參與開源軟件及Databricks產品研發。