大資料與 AI 生態中的開源技術總結
> 本文由雲 + 社群發表
> 作者:堵俊平
在資料爆炸與智慧革命的新時代,新的平臺與應用層出不窮,開源專案推動了前沿技術和業界生態快速發展。本次分享將以技術和生態兩大視角來看大資料和人工智慧技術的發展,通過分析當下熱門的開源產品和技術,來梳理未來的行業生態以及技術趨勢。
我們今天的主題分為三塊,第一是從開源的角度看技術、產品和生態,第二,我們從騰訊雲大資料的角度梳理開源的實踐,並跟大家分享一下我們最近一段時間或者最近一年以來我們的貢獻和成果。最後會跟大家一起探討一下開源的大資料以及 AI 這個生態當中的一些熱點和趨勢。
開源:技術、產品與生態
最近在大資料這個圈子裡,開源圈或者是整個大資料的圈子裡有一個公共性的事件,做發行版的廠商,大資料領域兩大技術巨頭 Cloudera 和 Hortonworks 突然宣佈合併,這兩個公司其實從開源界從商業界,都是互相打的不可開交的兩個公司。從歷史上去觀察這兩個公司,我們當時認為是完全不可能合併的兩個公司,為什麼呢會突然合併?
開源大資料的危機?
我之前曾經在其中一家公司工作過,長達 4 年時間。當時從我的觀察,這兩個公司在這段時間裡面到了老死不相往來的地步,四年的時間只有一個工程師跳到了對方公司。但這樣的公司在今天這樣一個時代,大資料、AI 或者雲時代,這兩個公司合併了。合併意味著什麼?外界有很多猜想,這是強強聯手,還是抱團取暖,是主動求變,還是來自資本的壓力,一千個人有一千個答案。我們從外部角度可以看出一些端倪,或者說從整個開源的運動或者開源的社群,生態發展可以看出一些端倪。
第二個開源重要的訊息就是說有些開源的廠商在最近這段時間裡面,從完全開源的許可證協議轉向了部分開源,或者說有條件的開源,把一個完全開放的生態變成了變更的許可證協議,mongoDB 更改開源協議是可以繼續用我的程式碼,如果把它作為一個服務開放出來的話,要開放所有的支撐服務程式碼。Redis 加了一個規定是可以正常使用分發,但不能銷售這個產品。我們看到這些曾經樂於開源的廠商,現在對開源的許可證加了很多限制和條款。
開源產品的 “冰山困境”
總體來說,站在支援純開源的、個人的角度來看,這是從開源到部分限制性的一種倒退。造成倒退的原因是什麼呢?對於基於開源專案的產品,我的總結是可能面臨所謂的冰山困境。什麼意思?就是說從使用者視角去看開源產品也好,或者說非開源的產品也好,可能很多時候關注的是產品的功能和效能。冰山下面的這些技術的複雜性、成熟度可能關注不足,可能在挑選類似功能產品的時候往往從功能、效能、價格等外部的維度角度來考慮。
基於使用者對於功能、效能以及價效比的追求,軟體供應商可能更加放大或者專注於這些差異化的軟體的開發和研發。對於冰山底部的大開源平臺,這個開源部分的能力,他本質上是屬於同質化的。很多軟體供應商會去想:如果我在這裡投入大規模的研發,實際上與市場上的競爭對手的產品之間就體現不出差異性。所以這裡的冰山困境是指對開源產品,不管是使用者還是商業組織,會更多的關注水面以上的部分。造成的結果會是什麼呢?如果大家真的只關注水面上的部分,只關心上層建築是否搭的越來越高,越來越好看,而不注意維護冰山底座的部分,會造成底部消融,如果底部不穩,整座冰山都會出現問題,圍繞開源專案所構建的生態體系就會垮掉。這樣的事情發生的多了,會影響公眾對開源專案與軟體的信心,我們這樣一個開源大發展的時代又會回退到閉源的狀態。
開源的產品發展到今天,我們一起要反思一下,為什麼會出現所謂的冰山困境,怎麼樣突破這些冰山困境。我覺得從一個開源軟體的整個生命週期來看,我們可能有不一樣的觀點。對於開源軟體供應商來說,開發階段用所謂的拿來主義,基於現成的軟體來構建,可以降低他的開發成本,包括在社群裡面利用一些社群外部的資源來促進開發流程或者開發的進度,這些都是很好的佈局。
但是對於測試部分和維護部分,不管是開源軟體的發行商或是雲廠商,可能都有關注不足的部分。什麼意思?剛剛我們說到基於開源可以做開發,可以降低所謂的開發成本,但相應的測試成本並沒有太多的降低,因為測試的複雜度很高,這些開源軟體都是獨立的社群去開發的。它們之間在版本釋出的時間點上無法做到同步,所以這些不同步造成了很多時候版本之間有版本或者時間點上的衝突,需要你去測試不同軟體之間的邊界與協同。
所以在這個層面上,雖然使用基於開源的軟體去打造一個企業化的軟體,我們可以降低一些開發成本,但是在測試成本這塊,不要輕易降低這部分的成本和投入。在這塊,需要廠商並且清醒的認識和嚴謹的態度。如果測試不到位,對使用者的感覺是開源軟體很不穩定,實際上這不是開源軟體的錯,而是軟體提供商沒有經過嚴格意義上的測試。不管是開源還是閉源,沒有經過充分測試的軟體是不穩定的。
不管是開源的,還是閉源產品。重要的不是程式碼,重要的是後面的社群、後面的人,如果沒有後面精通這些程式碼的人,拿了這些程式碼也沒用,因為有些技術債,是遲早要還的。對於維護階段的技術債,現在的開源軟體提供商、尤其是開源社群投入資源不足的發行商,完全沒有這個概念。如果從軟體整個生命週期來看這個問題,如果在使用者側和軟體提供商側達成這樣一個共識,就自然不僅會專注冰山上面的一層,冰山下的廣大的底座也會相應的重視和加強投入。這樣整個開源生態就會走一個正向、積極的迴圈。
從維護開源生態健康的角度來說,騰訊雲也有一些相關的嘗試,這裡以雲上的大資料產品為例,做一些分享,包括後面的一些實際的成果。
騰訊雲大資料的開源實踐與貢獻
舉一款產品,我們叫騰訊雲資料倉儲產品 Sparkling,是基於很多開源的技術,打造了一款雲倉庫,它可以對雲上多種資料來源進行儲存,比如說雲物件儲存 COS,雲資料庫,彈性 MapReduce 等等,還有傳統的關係型資料庫也可以對接。後面通過資料整合來構建數倉,資料集市來滿足 BI 等資料應用。它基於非常強大的 Hadoop 以及 Spark 開源大資料技術,並進行了相應的一些優化。這些優化已經以 patch 的方式回饋給社群。同時它提供一個資料開發 IDE,這樣使用者可以寫傳統的資料分析 SQL,也可以支援機器學習常用的 python,R 等語言。除此之外,對於資料資產管理、資料門戶、資料質量控制這塊也都有相應的解決方案。
值得一提的是,因為它是一款針對雲的特性而設計的一款數倉產品,所以對於雲特性的利用已經到了一個比較高的階段。我們把所有的節點分為三種,主節點、核心節點和彈性計算節點。主節點是一些重要的控制性節點,核心節點包含資料節點和計算節點,而彈性計算節點只有計算節點,所以支援可伸縮的部署。我們對開源的專案做了很多改進,比如說支援一些企業級的安全特性,包括對於資料授權和鑑權的支援等等,我們還跟英特爾一起合作,在社群裡面持續優化 SparkSQL 的任務執行器,在執行的時候可以動態調整執行計劃。我們對於數倉的列式儲存層,也做了很多優化工作,包括我們也回饋到 Parquet 社群裡的 bloomfliter 功能來支援更快速的資料掃描。我們當前也在針對於列存做基於 MVCC 的 ACID 支援,也有計劃把相應的方案和程式碼回饋給社群。我們的這款產品會在開源的基礎上把相應的技術優化提升之後,再回饋給開源社群。
所以我們試圖為這些開源專案做更多的貢獻,如果每一個雲廠商都能夠積極主動的貢獻技術力量、技術資源給開源社群,這對開源的生態健康是非常有意義的。我們還是 Apache 開源軟體基金會的白金贊助商,這個組織有很多大廠來支援它,為什麼會有這些大廠來支援?因為它是很多軟體,包括大資料,包括人工智慧等核心軟體背後的一個很重要的源泉,是水源地,我們做這些貢獻和贊助不是因為有相應的權利保障,而是為了保護好這個水源地,這對開源生態是非常重要的。我們是國內第一家白金贊助商,我們以後也會持續贊助下去。我們今年也幫助 Hadoop,Spark 社群釋出了最新的 release,我們投入了團隊的 committer 和 PMC 在社群裡組織協調這些 release 的釋出,促進社群的健康發展,也開了國內大資料廠商的先河。我們還是很多開源專案的積極參與方之一,比如 Hadoop 社群的 Ozone 專案以及 Spark 社群的 Hydrogen 專案等,與社群裡的其他開發者一起協同開發這些專案,尤其把雲廠商的能力和經驗帶進來,最終會使整個社群受益。
大資料與 AI 領域的熱點開源技術
開源大資料技術發展歷程
Apache Hadoop 是在 2006 年左右成立的,這十幾年有了很大的發展,甚至可以說是如日中天的過程。近期的熱點主要在雲原生,包括與 AI 平臺的整合與協同。還有一個簡單的列表,列出大資料每個細分領域,比如:SQL,流計算等等,可以看到在每個領域都會有很多競品和精品,為什麼會有這麼多出來?總有人對之前的專案不認同,或者認為還有改進的空間。從研發資源的組織來說,開源這種跨企業和組織的協同和傳統的企業內組織是很不一樣的。但從結果來看,開源是一種很有效的資源組織方式,既避免了大量的重複車輪子的工作,又保證了更新、更好的輪子能及時出現。
大資料與 AI 技術相互融合
對於資料的訪問之間,我們計算和物理分離,有很強的優勢。資料平臺還會往外進展,可以把 GPU 能力整合,在這上面通過加強排程,統一資料的訓練以及推理。包括 Spark 社群也提出了氫計劃,在應用層把大資料和 AI 開源的框架全部串聯在一起,通過分散式的排程方式,把這些框架排程到分散式資料與 AI 平臺之上。
傳統的機器學習和大資料,兩個社群、兩套技術,能不能做一個融合,或者有沒有關聯?相對於傳統的機器學習,深度學習對於資料、大資料的利用,應該說效率更高。因為傳統的機器學習到一定規模之後,訓練的指標和效果就上不去了,但是 Deep Learning 是不一樣的,海量的資料可以讓大規模神經網路有更好的訓練效果。騰訊也開源了 Angel 的框架。所以在融合的基礎上,我們認為未來的技術方向,會是 AI 與大資料技術相互融合的過程,從原始資料匯入到資料準備、資料訓練到模型部署,整個是一套閉環,這是未來的一個趨勢。
總結
最後做一個簡單的總結,我們認為開源專案屬於社會公共資源,就像是水,上善若水,水潤萬物,雖然需要有人來維護,但其核心屬性仍然是免費的公共品。在開源生態圈的利益相關方,包括我們的使用者,包括我們的軟體提供商,包括我們的開發者,我們都是有義務來投入資源,來維護這片水源地的。我們需要建設好社群生態,讓開發者可以對接使用者的需求。未來這個社群的開發方向和使用者實際的需求可以做直接的對接,而不一定通過軟體供應廠商,因為廠商的優先順序很多時候體現了付費客戶的需求,尤其是大客戶的優先需求。面對海量的開發者與社群使用者,我們需要這樣一個平臺,讓長尾的使用者能夠把聲音傳遞到社群,和社群長尾的開發者對接,這樣才有助於社群的健康發展。
我們要重視社群、重視人,而不是重視程式碼本身。有些公司開源的程式碼,會有人跳出來會說你這個程式碼寫的不好,我覺得這是一個對開源非常不友好的行為。不管是任何公司開放任何程式碼,這都是值得鼓勵的一個現象。如果程式碼寫的不好,你可以幫助它變好,哪怕是寫一個類似的東西開放出來和它競爭。開源在中國還是一個萌芽期,在這個情況下過分強調程式碼質量,而不是開源本身的行為,我覺得會有點拔苗助長。
最後一句話總結今天的演講,第一個是作為我們的開發者來說應該大膽開源,把一些產品還有技術大膽的開源出去,開源有很多的商業模式,我覺得開源軟體的商業模式在雲時代下會越來越成功。第二個是對於使用者來說,要放心、大膽的使用開源軟體和技術,因為這個時代基於開源技術的產品完全可以滿足大多數的場景和需求,而且能夠保證你不被少數的閉源軟體所綁架。
此文已由騰訊雲 + 社群在各渠道釋出
獲取更多新鮮技術乾貨,可以關注我們騰訊雲技術社群-雲加社群官方號及知乎機構號
- 加微信實戰群請加微信(註明:實戰群):gocnio
相關文章
- 大資料生態圈技術框架總攬大資料框架
- 專注AI框架與資料開源生態,這場技術工作坊邀你來看!AI框架
- 大咖說·對話開源|與 Tapdata 論道資料技術開放生態
- 開源大資料技術線上Meetup大資料
- 資料探勘中的資料歸約技術總結
- 大資料開源框架特點大總結大資料框架
- 開源資料庫大會技術分享資料庫
- Go 大資料生態開源專案 CDS 中 ClickHouse 使用的建表方案Go大資料
- 大資料生態中的 RocketMQ 5.0大資料MQ
- 大資料分析與雲技術結合大資料
- Oracle中的資料字典技術及常用資料字典總結Oracle
- 盤點九大熱門開源大資料技術大資料
- 開源大資料生態下的 Flink 應用實踐大資料
- 汪源做客阿里雲大咖說,論道資料庫開源與儲存生態阿里資料庫
- PHP 中 9 大快取技術總結PHP快取
- 封仲淹:OceanBase開源技術生態全景解析
- 大資料基礎知識總結和大資料方面的核心技術大資料
- 擁抱開源DevOps引領大資料生態系統dev大資料
- 大資料技術人員的工具包——開源大資料處理工具list大資料
- [總結] 容器技術架構、網路和生態詳解架構
- C#與資料庫訪問技術總結(十七)C#資料庫
- C#與資料庫訪問技術總結(十八)C#資料庫
- 胡思亂想:AI模型開發與中臺技術結合AI模型
- 【同行說技術】JavaScript開發的資源總結和心靈雞湯JavaScript
- 大資料開發的儲存技術探索與實踐大資料
- 大資料技術原理與應用——大資料概述大資料
- 國產資料庫的開源生態之路 | 直播預告資料庫
- 一文教你看懂大資料的技術生態圈 Hadoop,hive,spark大資料HadoopHiveSpark
- 大資料技術大會參會小結大資料
- 大資料領域內的十大開源技術、十大公司大資料
- 大資料技術之Hadoop(入門) 第2章 從Hadoop框架討論大資料生態大資料Hadoop框架
- 大資料技術原理與應用大資料
- 巨杉資料庫加入CNCF雲原生應用計算基金會,共建開源技術生態資料庫
- 開源分散式資料庫RadonDB的核心技術與實現分散式資料庫
- 擁抱開源,共建生態 - 開源生態與效能提升專場 | CIF 精彩看點
- 技術支援在大資料分析中的作用大資料
- C#與資料庫訪問技術總結(七)綜合示例C#資料庫
- 開源大資料排程系統 Taier 技術公開課 ——Taier 資料開發介紹大資料AI