從火星的古海洋,讀懂藍星的資料湖之變
大家想必都聽說了天問一號探測器“祝融號”成功在火星著陸的訊息。在它傳回的家書中,提到科學家們為自己選擇的著陸地,火星的烏托邦平原,可能是一個古海洋所在地,地形平緩,確保了安全性。
當我們將目光投回到身處的這顆“藍星”,也時時面臨著需要為產業要素選擇著陸地——比如說大資料。
相比傳統的資料倉儲架構,資料湖(Data Lake)已經成為數字化程式中,對現代企業和組織極具吸引力的大資料“著陸地”。
簡單來說,資料湖指的是如同湖泊一樣,將各種業務及軟硬體中源源不斷產生的各類資料,全部容納其中。
在AI+雲的大趨勢下,資料湖還可以與機器學習等相結合,指導企業進行效率最佳化及智慧決策;與雲端計算結合,利用雲服務彈性擴充套件、靈活部署、高可用高可靠、按使用量付費等特點,打造出投資回報更高的大資料解決方案。
如果說烏托邦平原是探測火星的絕佳地點,那麼資料湖就是承載企業資料資產的最佳場所。
目前來看,資料湖有巨大的想象空間,也吸引著各大雲廠商下足功夫,AWS、微軟、谷歌等都推出了各自的資料湖產品。
5月13日,騰訊雲也首次對外展示完整雲端資料湖產品圖譜,並推出兩款“開箱即用”資料湖產品,資料湖計算服務DLC和資料湖構建DLF。
相比單一產品或服務,在騰訊雲的資料湖版圖中,可以看到概念的“拓維”:雲原生智慧資料湖,對產業來說意味著什麼?圖譜式的產品矩陣,能給企業帶來哪些價值?“開箱即用”會給資料湖及數字化程式帶來什麼影響?
我們以資料湖的需求與挑戰為開端,來探秘騰訊雲帶來的“致用紀元”。
數字山河,需要怎樣的大資料之湖?
先回答一個疑問,什麼樣的企業需要資料湖。答案是,所有。
IDC報告顯示,到2025年全球資料總量將超過160ZB。數字化程式中,對大資料的管理與應用已經成為企業的競爭要素之一。飛速增長的資料規模自然也需要新的資料儲存策略,資料湖的特殊之處在於:
所有資料可以一直儲存,不管是實時使用的,還是可能永遠不會被使用的,不僅讓單位儲存成本更低,也讓任意時間點的資料回溯與分析成為可能;
所有型別可以全部容納。無論是定量指標的結構化資料,還是感測器、社交網路、影像影片等等多樣化資料來源的非結構化資料;
所有使用者可以得到支援。在資料湖中,所有資料都以原始形式儲存,需要使用資料的人可以快速找到資料來源的單一位置,避免了資料孤島、資料重複、協作困難等問題。
此外,資料湖也易於適應變化。資料倉儲的開發和更改都需要花費大量的時間,消耗開發人員資源。而在雲端部署的資料湖,可以根據企業業務需求靈活擴充套件,比傳統方案具有更大的靈活性,最大限度地減少僱傭專業資料運維團隊的支出。
Aberdeen 的一項調查表明,實施資料湖的組織比同類公司在收入增長方面高出 9%。
看到這裡,是不是已經心動想要拿起電話訂購了?別急!並不是將所有資料一股腦丟進湖中就大功告成了。
正如Gartner分析師尼克·休德克所說,將資料湖看做是大資料專案的靈丹妙藥,是一個謬論,資料湖是一個概念,而不是一種技術。
也就是說,企業在引入資料湖時,要注重從搭建、效益到應用的整體平衡。
比如,如果沒有適當的工具,資料湖可能會遭遇資料可靠性的問題,出現資料損壞、髒資料等等,讓資料科學家、AI工程師難以利用資料進行推理,或是訓練出不準確的業務模型;
再比如,一直往資料湖裡面儲存資料,而缺乏資料治理及應用輸出,就會形成“資料沼澤”,隨著時間的推移變得混亂、低質量;
最關鍵的是,目前市場上大多數資料湖產品都在強調對資料的儲存及計算,在具體業務場景之中究竟該怎樣去應用資料湖,並沒有清晰一致的答案。不解決技術的致用問題,就會讓很多企業望而卻步。
這種局面該怎麼辦?中國人的智慧早有提示,流水不腐戶樞不蠹,比起挖坑引水的“單向湖”,從山川河流的源頭、湖泊的常規治理,再到流向產業田野的應用,這樣的一整套資料湖解決方案,顯然更符合產業使用者的期待。
開啟紀元,騰訊雲的多米諾骨牌
技術產業週期的開啟,從來不是一蹴而就的。雲原生的資料湖,需要在儲存、計算、應用等層面解決諸多挑戰才能完成。
而騰訊雲首次披露的雲端資料湖產品矩陣,就是這樣一套組合式的產品,包括了資料湖儲存、資料湖算力排程、資料湖大資料分析、資料湖AI能力、資料湖應用、雲上基礎服務等六個層面,如同一副多米諾骨牌,將企業應用資料湖過程中可能遇到的階段性問題一一推倒。
我們可以從三個層面來看騰訊雲資料湖的新紀元開啟:
1.資料底座。
資料湖的本質是為企業乃至全社會的數字化轉型提供堅實可靠的資料基礎設施架構,對高效能、高安全、高可靠、低成本等綜合實力提出了高要求。
對此,騰訊雲資料湖在整個資料生命週期都進行了周全的設計。在儲存層,以物件儲存COS服務為核心,理論上可以儲存任意規模的異構資料,也支援將其他雲端資料設施,為企業打消後顧之憂;
(騰訊雲原生智慧資料湖產品圖譜)
在資料分析層,既提供半托管的泛Hadoop服務,滿足使用者自定義需求,也提供全託管的資料服務,便於使用者獲取海量資料的洞察力。
此外,使用者還可利用騰訊雲提供的資料協作工具對計算服務進行編排和呼叫,提升企業資料的便捷性和敏捷度。
2.智慧源頭。
今天,企業選擇資料湖的考量與上雲有著異曲同工之處,那就是為業務增長引入AI能力,達到提質增效的目的。騰訊雲也沒有令人失望,給出了一系列助力資料智慧的解決方案。
比如在算力排程上,基於騰訊雲彈性容器服務EKS,開放的容器化的分析架構讓資料分析功能可組合性更強,擴充套件性更強,降低企業訓練AI、應用AI的綜合成本;
此外,騰訊雲資料湖也提供豐富的AI服務,為影像處理、音訊處理、自然語言處理、影片處理等提供有力的資料支撐,當企業想要引入這些音影片能力時,更加簡單快捷。
3.致用工具。
和所有新技術一樣,資料湖的最終評價標準是要落進現實。這就需要降低企業應用門檻,讓技術價值能夠從真實業務場景中生長出來。
為此,騰訊雲在資料湖產品圖譜中,推出了企業畫像、聯邦計算、商業智慧分析等資料應用服務,企業直接選擇自身所需要的能力,就可以把資料湖應用構建起來。
同時,透過資料湖計算(Data Lake Compute,簡稱DLC)和資料湖構建(Data Lake Formation ,簡稱DLF)這樣“開箱即用”的產品,降低企業應用資料湖的難度。相比於本地自建大資料叢集,基於這兩款產品,資料湖構建時間減少了60%,資料分析計算效能提升35.5%。
這樣一步步推導,也就連成了“從入湖到出湖”端到端的完整鏈路,也清晰地指出了騰訊雲資料湖所帶來的差異化價值:希望借資料湖產品圖譜,引領資料湖進入“致用紀元”,與數字山河相映照。
向文明進發:資料能源的里程碑
1964年,蘇聯天文學家尼古拉·卡爾達肖夫提出理論,根據一個文明所能夠利用的能源量級,來量度文明層次及技術先程式度。
按照等級劃分,地球目前正處於0.73級左右,還沒有達到利用行星本身所擁有的能量規模。
換個角度思考,大資料,何嘗不也是這顆藍色星球上的新興能源,讓智慧更快、產業更優、經濟動力更強,對資料的利用與開發也將助推一國數字文明的加速發展。
正如同“祝融號”標誌著中國人開始走出地球“搖籃”,騰訊雲資料湖產品圖譜也為智慧時代的大資料管存用提供了一個全新的選擇:在業內首先提出了“圖譜式資料湖產品”,從資料入湖時怎樣存、算,到在湖中如何分析與應用,滿足使用者的所有需求。這不正是產業一直在期待的資料“能源開採裝置”嗎?
這時候我們會想問,為什麼率先打出連招的中國雲廠商會是騰訊雲?有三個背景是不可忽略的。
首先,騰訊自身龐大且多元的業務體系,無時無刻不在產生著大量的非結構化資訊,這時就需要資料湖技術去解決資料分散、重複資料等問題,正是在騰訊新聞等諸多內部場景中孵化,打磨到一定程度之後,將相應能力開放給產業客戶,可謂是恰逢其時。
第二,來自騰訊雲的基礎服務與技術積累,比如前文提到的能幫助使用者快速構建企業資料湖技術架構的資料湖構建(DLF)產品,所提供的統一後設資料管理與湖構建能力,就需要在資料規模很大的時候也能實現高效能的訪問,來讓資料儲存、計算等速度更快,這就依賴於騰訊雲在雲服務領域的技術壁壘,為資料湖體系提供了保障。
最後,正如騰訊雲大資料專家所說,要深入業務場景才會發現鮮活的痛點,方案要落在各行各業、不同企業客戶的實際場景中去。
事實上,成功的資料湖採用者大都是使用“業務回頭”的方法,即先確定業務可以從資料湖中獲得的最大價值情境,然後將這些場景納入到解決方案中,再逐步填充資料。這就需要做大量定製開發工作,考驗著雲廠商的企業服務能力與意識,也是今天數字化轉型中最難的一道關卡。
在這方面,我們看到騰訊雲直指現實需求和應用場景,將採用決定權交給業務,與客戶的技術人員一起梳理核心需求,最終選擇更適合自己的方案。騰訊雲資料湖產品之所以率先選擇向“技術致用”延伸,或許正來自於這一份對業務的尊重。
范仲淹曾形容洞庭湖“浩浩蕩蕩,橫無際涯”,也是今天企業面對資料洪潮的現實寫照。
對於資料湖這類新技術的出現,也容易出現了兩種截然相反的情緒:過度質疑,會令企業躊躇不前,錯過超越競爭者的機遇;過於樂觀,又會導致對困難缺乏充足的估計。
或許更理性的態度應該是,和科技企業攜手,一起去探索並撬動未知,駛向氣象萬千的數字文明。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31561483/viewspace-2772854/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 消除資料重力,從智慧湖倉(Lake House)讀懂實現資料價值的未來
- 一文讀懂:本地資料湖丨資料倉儲丨雲資料湖的利與弊
- 一文讀懂選擇資料湖還是資料倉儲
- 讀資料湖倉03不同型別的資料型別
- 讀資料湖倉05資料需要的層次
- 讀資料湖倉08資料架構的演化架構
- 讀資料湖倉02資料抽象抽象
- 讀資料湖倉06資料整合
- 讀資料湖倉01讓資料可信
- 讀資料湖倉07描述性資料
- 讀資料湖倉04資料架構與資料工程架構
- Kettle 從資料庫讀取資料存到變數中資料庫變數
- 資料湖
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 資料變金礦:一文讀懂序列模型(附用例)模型
- 讀資料湖倉09讀後總結與感想兼導讀
- 資料湖從前世到今身的演進與選型探索
- 關於資料湖、資料倉儲的想法
- 資料湖 VS 資料倉儲之爭?阿里提出大資料架構新概念:湖倉一體阿里大資料架構
- Elasticsearch在資料湖中的地位Elasticsearch
- 遨翔在知識的海洋裡----(apicloud之dot模板渲染資料)APICloud
- 資料倉儲、資料湖與湖倉一體的區別與聯絡
- 一文讀懂SpringMVC中的資料繫結SpringMVC
- 阿里云云原生資料湖體系全解讀——資料湖開發治理平臺 DataWorks阿里
- 讀懂自己,讀懂他人之MBTI性格分析是什麼
- 資料湖和中央資料倉儲的設計
- jquery ajax從後臺讀取的資料無法賦值給變數jQuery賦值變數
- 資料湖中加熱資料?
- 從程式碼層讀懂 Java HashMap 的實現原理JavaHashMap
- 一文讀懂資料平臺的發展歷史
- 漫談“資料湖”之價值與架構架構
- 日誌服務之資料清洗與入湖
- 資料湖--架構師如何助力“湖加速”?架構
- 從 "垃圾 "資料到資料完整性的轉變
- 一文讀懂SpringBoot、微服務架構和大資料治理之間的故事Spring Boot微服務架構大資料
- 一文讀懂 OceanBase 資料庫的SLog日誌資料庫
- 十種程式語言幫你讀懂大資料的“祕密”大資料
- Hiptype:讓出版商更懂讀者的大資料分析工具大資料