想看而不是讀?看看這個視頻在這裏。
數據湖的承諾
Michael時常要:
今天我超級興奮,談論如何使Apache火花更好使用三角洲湖。然而,在我進入之前,我想先討論這個概念數據湖和為什麼這麼多人感到興奮,為什麼有很多的挑戰當他們試圖設置這些東西。
所以,首先,什麼是數據湖,我這是什麼意思?所以,三角洲湖的承諾基本上是這樣,組織有很多的數據。這可能是精心策劃客戶數據在OLTP係統。可能是原始的點擊流來自您的web服務器,或者非結構化數據來自一群傳感器。
湖和承諾的一個數據是,你可以把所有數據並將它的湖。這是真的強大當你比較傳統的數據庫。因為在傳統的數據庫中,你必須首先提出一個模式和做清潔。這通常被稱為schema-on-write。
湖和一個數據允許您做的是它可以讓你放棄這一過程就開始通過收集一切。因為有時你不知道為什麼直到很久以後數據是有價值的。如果你還沒有存儲它,那麼你已經失去了它。所以,湖的數據隻是一堆文件在文件係統中。它可能是S3或者HDFS, Azure Blob存儲。你可以拋棄一切,然後再回來看看。
和我們的想法是當你完成,一旦你收集了這一切,然後你可以得到的見解。你可以做數據科學和機器學習。您可以構建強大的工具為您的業務,如推薦引擎或欺詐檢測算法。你甚至可以做瘋狂的事情就像使用基因組學和DNA測序治愈癌症。
然而,這個故事我看過很多次。通常,發生的是,不幸的是,一開始的數據是垃圾。所以,你的數據存儲在你的數據湖是垃圾。結果,得到垃圾從這些更高級的過程,你要做的。
挑戰與數據湖
為什麼會這樣呢?為什麼這麼難得到質量和可靠性這些數據的湖泊和這典型項目看起來像什麼呢?我想介紹一個故事,我看過一遍又一遍地發生,在許多組織中,當他們坐下來,試圖從數據中提取的見解。它通常是這樣的。這是今天被認為是先進的,但在三角洲湖。
很常見的模式是你有一連串的事件進入一些係統像Apache卡夫卡。你的任務是做兩件事,你需要做流媒體分析,這樣你就可以實時知道發生了什麼在您的業務。你也想做人工智能和報告,您可以看看更長一段時間,進行縱向分析,實際上看看曆史和趨勢,並對未來做出預測。
所以,我們要怎麼做呢?第一步,我坐在我的電腦。我知道火花很好的閱讀api從Apache卡夫卡。您可以使用數據幀,數據集和SQL和SQL過程和做聚合引發和時間窗口和各種各樣的東西,拿出你的流分析。
所以,我們開始了蝙蝠,它工作得很好。但是這給我們帶來了挑戰第一,這是曆史查詢。獲取實時分析卡夫卡是偉大的,但它隻能存儲一天或一周的數據。你不想被存儲在卡夫卡年複一年的數據。因此,我們可以解決這個問題。實時很適合此時此刻發生的事情,但這是不擅長尋找曆史趨勢。
所以,我一直在閱讀大量的博客文章。這裏很常見的模式發生是有這個東西叫做λ架構,,據我所知,基本上是你隻是盡兩次。你有一個實時的事情做一個近似和給你此時此刻到底發生了些什麼。你有另一個管道,也許更多的策劃,並運行更慢。但它是湖歸檔所有的數據到你的數據。所以,這是第一步。所以,如果我們想要解決這一曆史查詢問題,我們也要設置λ架構之上的香草Apache火花。
一旦我有所有數據在數據湖,我們的想法是,現在我可以運行的SQL查詢。我可以做人工智能和報告。這是一個額外的工作和一些額外的協調。但幸運的是,引發了一個統一的API,用於批處理和流。因此,它是可能的,你可以設置。
但這給我們帶來了挑戰。就像我之前說的,現實世界中的數據往往是混亂的。一些團隊上遊從你的變化模式,沒有告訴你,現在你有問題。所以,一個模式,我看到的是您需要添加驗證。所以,你需要編寫額外的火花SQL的檢查程序,以確保你的假設是正確的數據。如果他們錯了,發送了一封電子郵件,這樣你就可以改正它。
當然,因為我們所做的λ架構,我們必須做驗證在兩個不同的地方。但是,這是我們能做的東西。我們可以用火花。所以,現在我們設置驗證,他們處理混亂的數據。第三,不幸的是給我們帶來了挑戰,這是錯誤和失敗。
這些驗證是偉大的,但有時你忘了把一個地方或在代碼中有一個bug,或者更加困難,如果你的代碼隻是崩潰EZ2上運行的中間,因為你和你的現貨情況下死亡。現在你需要擔心清洗。真正的問題與使用這些類型的分布式係統和分布式文件係統,如果一份工作崩潰在中間,這意味著垃圾需要清理結果。因此,你不得不做所有自己推理的正確性。這個係統不是給你很多幫助。
很常見的模式是人,而不是致力於整個表,因為如果出現問題,我們需要再計算整個表,他們會把它分成分區。所以,你有一個不同的文件夾。每個文件夾的商店一天或一個小時,一個星期無論對你的用例粒度是有意義的。你可以建造很多腳本,以便我做閱讀很容易計算。
所以,如果其中一個分區由於任何原因被損壞,是否它是一個錯誤在我的代碼或失敗隻是一份工作,我可以刪除整個目錄和再加工,從頭開始一個分區的數據。因此,通過構建這個分區和後處理引擎,現在我可以處理這些錯誤和失敗。有一點額外的代碼編寫,但現在我可以睡平安知道這是去工作。
不過,這給我們帶來了挑戰4號。更新。很難做點更新。很容易添加數據,但很難改變數據在數據湖和正確。你可能需要這樣做原因GDPR。你可能需要做保留。你可能不得不做匿名化,或者其他的事情,或你可能會有錯誤的數據。所以,現在你必須寫一個不同的群體,他們的火花工作做更新和合並,因為這可以是非常困難的。
通常,因為它是如此困難,我看到人們做的是而不是做單獨的更新,這將是非常便宜的,他們實際上隻是當他們需要做些什麼,隻要他們得到一組安全域每月一次,他們會複製整個表,刪除的人由於GDPR要求被遺忘。他們可以這樣做,但這是另一個火花工作運行,非常昂貴。
和這裏有微妙,額外的困難,那就是,如果你有人閱讀時修改一個表生成一個報告,他們將會看到不一致的結果,報告將是錯誤的。所以,你需要非常小心安排,避免衝突,當你執行這些修改。但這些都是問題,人們可以解決。這個晚上,你白天運行您的報告。所以,現在我們有一個機製來做更新。
但是,這裏的問題是這已經變得很複雜。這意味著你在浪費大量的時間和金錢解決係統問題,而不是做你真正想要做的,就是從數據中提取價值。我看這是這些數據的幹擾湖實際上阻止你完成你的工作。
和總結我認為這些是什麼,一個大的原子性。當您運行一個分布式計算,如果工作失敗在中間,你還有一些部分結果。這不是全有或全無。原子性意味著當一個工作運行時,它完全正確地完成或如果發生錯誤,它完全回滾,什麼也不會發生。所以,你不再離開你的數據在一個腐敗的國家需要沉悶地建立這些工具執行手動恢複。
另一個關鍵問題是沒有質量的執行。由你在每個工作手工檢查的數據的質量。再一次,這是你所有的假設。沒有像不變量的幫助係統在傳統的數據庫,你可以說,“不,這列是必需的或這一定是這種類型的模式。“所有的東西留給你的程序員來處理。
最後,沒有控製的一致性或隔離。這意味著你可以隻做一個湖正確操作任何數據表。和使它很難混流和批處理或做操作人們閱讀。這些都是你希望從你的數據存儲係統。你會希望能夠做這些事情,人們應該能夠看到自動一致的快照。
解決這些挑戰與三角洲湖
現在讓我們退後一步,看看這個過程看起來與三角洲湖。和三角洲湖的想法是我們把這個相對複雜的體係結構,在很多的正確性和其他東西都留給你手工編寫火花程序和我們改變它,這樣,你隻考慮數據流,你把所有的數據從您的組織和流程通過不斷改進,直到它準備消費質量。
和這個架構的特點是首先,三角洲湖給Apache火花帶來完整的ACID事務。運行的,這意味著每一個火花工作將完成整個工作或什麼都沒有。的人閱讀和寫作的同時保證一致的快照。當寫出的東西,它絕對是寫出它不會丟失。這些都是酸的特點。這允許你關注實際的數據流,而不是思考所有這些額外的係統問題和解決這事一遍又一遍。
三角洲湖的另一個關鍵方麵是它是基於開放標準,它是開源的。所以,這是一個完整的Apache許可證。沒有愚蠢的常見條款或類似的東西。你可以把它和使用它為任何你想要的應用程序完全免費的。,就我個人而言,這將是非常重要的,如果我是存儲海量數據。數據有很大的重力。有很多的慣性,當你收集大量的數據。我想把它放在一些黑盒,這對我來說是非常困難的提取。
這意味著您可以存儲大量的數據而不用擔心質量鎖定。所以,它是開源的,但它也是基於開放標準。所以,我將更詳細地討論這個在說話。但在封麵,δ在拚花實際上是存儲你的數據。所以,你可以閱讀它與其他引擎。三角洲湖周圍有越來越多的社區建設這個原生支持。
但是,最糟糕的情況,如果你決定你想離開三角洲湖,所有您需要做的就是刪除事務日誌,它就變成了一個正常的拚花表。最後,三角洲湖深深由Apache火花。這意味著,如果你有現有火花工作,無論是流或批處理,您可以很容易地轉換得到各種好處的三角洲,而無需從頭重寫這些項目。和我要談的到底是什麼,看起來就像在說話。
三角洲湖架構:青銅、白銀和黃金表
但是現在,我想把這張照片和簡化一點談論一些其他的特點我看到三角洲湖架構的,我見過的人是非常成功的。
所以,首先,我想在這個區域的數據質量水平。這些都不是三角洲湖的基本東西。我認為這些都是人們使用各種係統。但我看到人們非常成功,這一模式與三角洲的特點。所以,這些隻是數據質量的一般類。這裏的想法是把數據轉換成三角洲湖,而不是試圖使它完美的一次,你要逐步提高數據的質量直到準備消費。和我將討論為什麼我認為這其實是一個非常強大的模式,可以幫助你更有效率。
所以,從一開始就是你的青銅級別的數據。這是一個原始數據的傾倒場所。它仍然是著火了。實際上,我認為這是一件好事。因為這裏的核心思想是,如果你抓住一切沒有做很多綠豆或解析,沒有辦法,您可以在解析和綠豆代碼錯誤。你讓一切從頭開始。實際上,您通常可以保持一年值得保留。我會說一下為什麼我認為這是非常重要的。
但這意味著您可以收集一切。你不需要花很多時間提前決定哪些數據是寶貴的數據沒有什麼。你可以弄清楚,當你做分析。
從青銅繼續,我們繼續銀級數據。這是還沒有準備好數據消費。這不是一個報告,你要給你的CEO。但是我已經做了一些清潔。我過濾掉一個特定事件類型。我解析JSON並給它一個更好的模式。或者我加入增強不同的數據集。他們有我想要的所有信息在一個地方。
你可能會問,如果這個數據並不準備消費,我為什麼要花時間創建一個表來實現它。實際上有兩種不同的原因。一是,通常,這些中間結果有用的很多人在你的組織。通過創建這些銀水平表,你在你的領域知識和清理數據,你讓他們受益於自動,而不必自己做這工作。
但更有趣和更微妙的一點是它還可以幫助調試。當有一個錯誤在我的最終報告,能夠查詢這些中間結果是非常強大的,因為我可以看到哪些數據產生那些壞結果,看的管道是有意義的。這是一個好的理由有多個跳在你的管道。
最後,我們進入黃金類的數據。這是幹淨的數據。這是準備消費。實際上這些業務水平總量,談論如何運行和如何工作和這幾乎是準備一份報告。
在這裏,您開始使用各種不同的引擎。所以,就像我說的,三角洲湖與火花已經很好。還有很多興趣添加支持很快和別人。所以,你可以做你的流分析和人工智能和報告。
在三角洲湖流和批處理
所以,現在我想談談人們如何通過三角洲湖移動數據,通過這些不同的質量類。的一個模式,我看到一次又一次,流媒體實際上是一個非常強大的概念。在我走得深流之前,我想正確的一些誤解,我經常聽到。
所以,一件事,人們通常認為當他們聽到流,他們認為這是超級快。它必須是非常複雜,因為你想要非常快。和火花確實支持模式,如果你的應用程序。有連續處理,你不斷地把新數據的服務器,堅持核心支持毫秒延遲。
但這不是唯一的應用,流媒體是有意義的。流對我是真正關於增量計算。它是關於一個查詢,我想持續運行新數據到來。而不是思考這一堆離散的工作,把所有的這些離散的管理工作,我有一些工作流引擎,流,帶走了。
你寫一個查詢一次,你說“我想從青銅讀取表,我想做這些操作。我要寫在銀表,“你隻是不斷運行它。你不用考慮複雜的日期什麼是新的,什麼數據已經處理,如何處理數據和提交下遊以事務的方式,我如何檢查點狀態如果工作崩潰和重啟,我不要失去在流。結構化流為您處理所有這些問題。
而不是更複雜,我認為這可以簡化你的數據架構。和流媒體在Apache火花確實有這很好的權衡成本延遲,你可以調整。因此,在遠端,您可以使用連續處理模式。你可以抓住那些核心流持續和你可以得到毫秒延遲。
在中間區域,您可以使用一個微批。微批處理的優點是你可以有許多小溪在集群上和他們的時間多路複用這些核心。所以,你運行一個非常快速的工作,然後你放棄核心然後別人進來,並運行它。這樣,你可以秒到幾分鍾延遲。對很多人來說這是一個甜點,因為很難知道什麼是最新的在最後一分鍾,但你介意這是最後一個小時內。
最後,還有這個東西叫trigger-once結構化流模式。所以,如果你有工作,數據隻到一天一次或每周或每月一次,它沒有任何意義,集群啟動並運行,特別是如果你在雲中運行,你可以放棄並停止支付。
和結構化流實際上有一個功能這個用例。基本上和它叫做trigger-once不斷而不是運行作業,隨時新數據到來時,你啟動它,你說觸發一次,它讀取任何新的數據到達時,下遊流程,提交事務,並關閉。因此,這可以給你流的好處,便於協調,沒有任何相關的成本通常總是運行集群。
當然,移動數據流並不是唯一的方法通過三角洲湖。批處理作業是非常重要的。就像我之前提到的,你可能已經GDPR,或者你需要這些修正。你可能改變了數據捕獲來自其他係統,你有一組更新來自你經營商店。你隻是想反映,在三角洲湖。,為此,我們更新插入。當然,我們也支持標準的插入和刪除,這些命令。
所以,真正的優點三角洲湖是支持這兩種模式,您可以使用合適的工具,正確的工作。你可以無縫混合流和批而不用擔心正確性或協調。
和最後一個模式在這裏,我想談談這是重新計算的想法。所以,當你有這種早期表讓你所有的原始結果,當你有很長時間保留,所以年的原始數據。
和當你使用流在不同的節點之間的三角洲湖數據圖,很容易為你重新計算。你可能會想要重新計算,因為在代碼中有一個bug,或者你可能想要重新計算,因為有一些新東西,你已經決定你想提取。這裏真的很不錯,因為,流的工作方式,這是非常簡單。
所以,隻是給你一個心智模型在Apache火花結構化流是如何工作的,我們的模型主要有流查詢應該總是返回相同的批處理查詢的結果相同數量的數據。所以,這意味著當你開始一個新的流對三角洲表,它開始通過快照的表目前流啟動。
和你這樣做回填操作過程中所有的數據快照,打破它分成小塊,檢查點狀態,下遊提交它。當你得到的快照,我們切換到尾礦事務日誌,隻處理新數據查詢開始以來已經到來。,這意味著你會得到同樣的結果,好像你有運行查詢最後不管怎樣,但隨著工作顯著低於運行它從頭一遍又一遍又一遍。
所以,如果你想重新計算在這種模式下,所有你需要做的就是清除下遊表,創建一個新的檢查點,並重新開始。和它會自動過程從一開始的時間和今天趕上我們。所以,這是一個強大的模式,糾正錯誤和做其他事情。
三角洲湖客戶用例
所以,現在我們已經在高水平,我想談談一些特定的用例,三角洲湖方麵降低成本和使用Apache的管理引發這些湖泊三角洲之上。
所以,三角洲湖,我想給一點曆史。三角洲湖是幾歲。我們以前在過去兩年的磚作為一個專有的解決方案。我們有我們的一些大客戶使用它。beplay体育app下载地址我特別是談論Comcast,而且防暴遊戲,果醬和英偉達的城市,一群大的名字,你知道的。他們已經使用了許多年。
大約兩個月前,在火花峰會上,我們決定開源,大家甚至人on-prem或者在其他地方可以獲得三角洲湖的力量。
康卡斯特公司
所以,我想談談一個特定的用例,我覺得真的很酷。這是康卡斯特。他們的問題是他們有世界各地的機頂盒。為了了解人們與他們交互編程,他們需要sessionize這個信息。所以,你看這個電視節目,你換頻道,你到這裏,你回到另一個電視節目。這樣,他們可以創造更好的內容通過了解人們如何使用它。
你可以想象,康卡斯特有很多用戶。所以,pb的數據。在三角洲湖之前,他們運行這個Apache火花。這個問題是引發工作sessionization太大,火花調度器會翻倒。
因此,而不是運行一個工作,他們實際所需要做的就是他們不得不接受這個工作,分區用戶ID。所以,他們的用戶ID,散列。他們國防部它,我認為,10。所以,他們把它成10份不同的工作。然後他們獨立運行的工作。
這意味著有10倍的開銷方麵的協調。您需要確保這些都是跑步。你需要支付所有的實例。你需要處理失敗和十倍的工作。這是很複雜的。和很酷的故事這個三角洲是他們能夠開關切換很多這些類型的手工流程流。和他們能夠大大降低成本通過把下來到一份工作中1/10的硬件上運行。現在計算同樣的事情,但10倍減少開銷和10倍的成本。
所以,這是一個很強大的東西,三角洲的可擴展的元數據能使Apache火花。我將談談如何說話,所有的作品。但在我進入之前,我想告訴你到底是多麼容易開始如果你已經使用Apache與三角洲湖火花。
所以,開始是微不足道的。所以,你發表在火花包。所有您需要做的火花集群上安裝三角洲湖是使用火花包。所以,如果你正在使用pySpark,你可以做衝刺,衝刺包。然後δ,如果您正在使用火花殼,同樣的事情。如果您正在構建一個Java或Scala jar,和你想要取決於三角洲,所有您需要做的就是添加一個Maven的依賴。
然後修改代碼也同樣簡單。如果您正在使用的數據幀的讀者和作家火花SQL,所有您需要做的就是更改數據源從拚花,或JSON或CSV或其他使用今天三角洲。和其他所有的事情應該是一樣的。唯一的區別是現在一切都將可伸縮和事務,這正如我們之前看到的可能是非常強大的。
到目前為止我已經講過的一切主要是這些類型的係統問題的正確性。如果我的工作崩潰了,我不想讓它腐敗的桌子上。如果兩個人寫表在同一時間,我希望他們都看到一致的快照。但實際上數據質量是更多。您可以編寫代碼,運行正確,但是可以有一個錯誤在代碼中並得到錯誤的答案。
這就是為什麼我們擴大數據質量的概念允許您以聲明的方式談論質量約束。這是工作在接下來的季度。但是這裏的想法是我們讓你,在一個地方,指定的布局和約束三角洲湖。所以,你知道第一個我們可以看到一些重要的數據在哪裏之類的東西。存儲,您可以選擇打開檢查嚴格的模式。
三角洲湖有兩種不同的模式。我經常看到人們使用他們作為他們穿過數據質量的旅程。在前麵的表,您將使用一個模式並打印,也許你剛讀了一堆JSON和把它完全像三角洲湖。我們這裏有很好的工具將自動執行安全模式遷移。
所以,如果你寫數據到三角洲湖,你可以打開合並模式標誌,它就會自動添加新列中的數據表,以便你可以捕捉一切沒有花很多時間寫DDL。
我們當然也支持標準的嚴格模式檢查,你說,創建一個表的模式,拒絕任何不匹配的數據模式。你可以使用alter table改變表的模式。經常,我看到這個使用道路和黃金級別表,你真正想要嚴格執行的。
最後,你可以在蜂巢metastore注冊表,支持快到了。也把人類可讀的描述,所以人們來此表可以看到這個數據來自源和解析。這是屬於這個團隊。這種額外的人類信息,您可以使用它們來了解數據會讓你你想要的答案。
最後,我最興奮的特點是這一概念的期望。一個期望允許你把你的數據質量的概念和實際編碼成係統。所以,你可以這樣說,例如,在這裏,我說我希望這個表有一個有效的時間戳。我能說什麼是一個有效的時間戳對我和對我的組織。
所以,我希望時間戳。我希望它發生在2012年之後,因為我的組織在2012年開始。所以,如果你看到資料說1970由於深人錯誤,我們知道這是錯誤的,我們要拒絕它。所以,這非常類似於那些熟悉的傳統的數據庫。這聽起來很像一個變量,你可以把not null或其他東西放在桌子上。
但是有一個微妙的區別。不變量的想法是,你可以說事情表。如果違反了其中的一個不變量,該事務將自動中止,並將失敗。
我認為大數據的問題,為什麼不變量本身是不夠的,如果你停止加工,每一次你看到一些意想不到的,尤其是在那些早期的青銅表,你永遠不會處理任何事情。這真的可以傷害你的敏捷性。
所以,最酷的期望是我們實際上有一個可調的嚴重性。這不能阻止我們做支持,你可能想要使用的表上你的財務部門使用,因為你不希望他們看到的東西是不正確的。但是我們也有這類較弱的東西,您可以監視有多少記錄是有效的和有多少未能解析和警告閾值。
甚至更強大,我們有這個概念的數據隔離,你可以說,任何記錄,不符合我的期望不填充管道,但也不能讓它通過。檢疫在這裏,另一個表,所以我可以過來看後,決定我需要做些什麼來糾正這種情況。所以,這允許您繼續處理,但是沒有腐蝕下遊結果無效的記錄。
所以,就像我說的,這是一個功能,我們現在積極工作。請繼續關注GitHub的更多的工作。我認為這從根本上改變你的思維方式,對數據質量與Apache火花和三角洲湖。
現在,他們一直在高水平的三角洲是什麼,你為什麼要關心它嗎?我想進入的細節細節δ實際上是如何運作的。因為它聽起來幾乎好得令人難以置信,我們可以將這些完整的ACID事務到像Apache火花和分布式係統仍然保持良好的性能。
首先,我們先來看看一個增量表看起來像當它實際上是存儲在磁盤上。的你,有一個三角洲湖,這應該很熟悉。它隻是一個目錄文件係統存儲在S3, HDFS, Azure Blob存儲,abl。它隻是一個目錄和一幫鋪文件。
還有一個額外的一點,是非常重要的。這是我們商店這個事務日誌。事務日誌裏麵,都有不同的表版本。和我將談一談這些表版本。但我們仍然將數據存儲在分區目錄。然而,這實際上是主要用於調試。他們也三角洲模式,我們可以直接與存儲係統以最優的方式。
例如,在S3中,他們建議如果你要寫大量的數據定期而不是創建日期分區,創建熱點的時間局部性。相反,你隨機散列分區因為δ的元數據的力量,我們也可以這樣做。最後,編碼標準數據文件,這隻是正常的拚花可以讀取文件,任何係統。
所以,實際上在這些表的版本是什麼?我們如何思考一個表的當前狀態是什麼嗎?所以,每一個表的版本有一組操作,適用於表,並以某種方式改變它。此刻,一個表的當前狀態的結果所有這些行動的總和。所以,什麼樣的行動,我在說什麼?
對於一個例子,我們可以改變的元數據。所以,我們可以說這是表的名稱,這是表的模式,您可以添加一個列到表或東西,你可以設置表的分區。所以你可以采取什麼行動來改變元數據。
另一個行為是添加一個文件和刪除文件。所以,我們寫出一個拚花文件。然後讓它可見表中,它也需要被添加到事務日誌。和我將討論為什麼額外的間接層是一個非常強大的技巧。另一個細節是,當我們將文件添加到三角洲,我們可以讓很多可選的統計數據。
在一些版本,我們可以保持每一列的最大和最小值,我們可以用它來做數據跳過或快速計算聚合值在桌子上方。最後,你也可以從表中刪除數據通過刪除文件。再一次,這是一個懶散的操作。這種級別的間接真的很強大。當我們從表中刪除一個文件時,我們不一定立即刪除這些數據,允許我們做其他很酷的東西,比如說時間旅行。
所以,所有這些事情的結果在這裏是你最終與當前元數據,文件的列表,然後還有一些細節的列表已經提交的事務,我們在協議版本。
如何讓我們得到酸得到這些漂亮的事務數據庫的屬性?這裏的一個細節是,當我們創建這些表版本,我們將它們存儲有序原子單元稱為提交。所以,我之前談過這個問題。我們創建表的版本0通過創建這個文件,0. json。這裏的想法是,當三角洲構造該文件在文件係統中,我們將使用基本原子原語。
在S3,為了保證原子性,所有你需要做的就是上傳係統。他們這樣做的方式是你開始你的上傳,說我希望上傳這麼多字節。實際上除非你成功上傳,許多字節,S3不接受的權利。所以,你保證在7月得到整個文件或所有的文件。
另一個係統是Azure或HDFS。我們要做的是我們將創建一個臨時文件的全部內容。然後我們會做一個原子重命名,這樣整個文件創建。然後你可以有連續的版本。所以,在一個版本中,我們增加了這兩個文件,抱歉,在零版本中,我們增加了這兩個文件。在一個版本中,我們刪除它們,把第三。舉個例子,你在這裏可以做壓實,你自動地把這兩個文件並壓縮成一個大文件。
現在,另一個重要的細節是,我們要為每一個提交添加原子性,但是我們也希望可串行性。我們想要每個人都同意的變化穩定,我們可以正確地做事情像並入變化數據捕獲和其他東西需要這個屬性。
所以,為了達成這些變化即使有多個作者,我們需要這個屬性稱為互斥。如果兩個人試圖創建一個增量的相同版本表,隻有一個人能成功。所以,為了清楚地說明這一點,用戶可以編寫版本表的零。用戶可以寫兩個版本。但如果他們都試著寫兩個版本,其中一個可以成功,但另一個必須得到一個錯誤消息說,“對不起,您的交易沒有通過。”
現在你可能會說,“等一下。但如果兩個人做,失敗。這聽起來像我浪費了大量的時間和大量的工作。這對我來說聽起來像很多複雜性。“不幸的是,這就是我們用第三個酷技巧叫做樂觀並發。和樂觀並發的想法是對表執行一個操作時,你要樂觀地認為它會工作。如果你有一個衝突,你就看看衝突問題。如果沒有,你可以樂觀地再試一次。
然後在大多數情況下,實際的交易不重疊,你可以自動修複。所以,給你一個具體的例子,假設有兩個用戶,這些用戶都是湧向相同的表。
所以,當他們開始他們的流吧,他們開始通過閱讀的版本表在那一刻。他們都讀版本0。他們讀表的模式中。因此,他們確保他們的數據添加正確的格式。然後寫一些數據文件流的內容將被記錄在這批處理。他們記錄是什麼從表中讀取和寫入。
現在,他們都試圖提交。在這種情況下,用戶一個贏得比賽和用戶兩個失去。但用戶兩個要做的是他們會查看是否有變化。因為他們唯一了解表的模式,模式沒有改變,他們允許自動再試一次。這是隱藏在您的開發人員。這些都是自動進行的。所以,他們會嚐試提交和他們會成功。
現在,最後一個技巧,我們這裏是表可以有大量的元數據。和那些試圖把數以百萬計的分區放在蜂巢metastore可能是熟悉這個問題。一旦這些數據大小、元數據本身可以帶來係統的東西。
所以,我們有一個訣竅,其實我們已經有了一個分布式處理係統能夠處理大量的數據,我們將隻使用火花。所以,我們組的事務日誌的采取行動,我們讀與火花,我們可以編碼在拚花作為一個檢查點。一個檢查點基本上是整個表在一些版本的狀態。
所以,當你正在讀事務日誌,而不是閱讀整個事務日誌,你可以從一個檢查站,然後任何後續之後發生了變化。然後這本身可以處理火花。
所以,當你走到一個大表,有數以百萬計的文件,和你問的問題,有多少記錄昨天說,我們要做的是我們將運行兩種不同的火花工作。第一個宇航員是元數據和昨天說哪些文件是相關的。它會回來的文件列表,然後您將運行另一個火花實際上的工作流程並計數。
在兩個階段通過這樣做,我們可以大大減少需要處理的數據量。我們隻看與查詢相關的文件。我們將使用火花過濾。
所以,在我們去之前的問題,我想談談路線圖。就像我說的,雖然這個項目已經有幾年了,隻是最近開源的。我們有一個非常令人興奮的今年餘下的路線圖。基本上,我們的目標是完全開源三角洲湖項目的API兼容是什麼磚內可用。所以,其餘的路線圖季度基本上是開源很多很酷的功能。
所以,實際上我們幾周前0.2.0發布版本,添加支持閱讀從S3和閱讀從Azure Blob存儲和Azure三角洲湖。本月,我們打算做一個0.3.0釋放,將添加Scala api更新,刪除、合並和真空。和Python api將在不久之後。然後剩下的這個季度,我們有幾件事情我們的計劃。我們想要添加完整的DDL支持。這就是創建表和修改表。
我們也想給你的能力來存儲蜂巢metastore三角洲表,我認為這是非常重要的數據發現在不同的組織。我們想把這些DML命令之前的更新、刪除和合並實際上鉤到火花SQL解析器。因此,您可以使用標準的SQL執行這些操作。
然後向前,讓我們知道你想要什麼。所以,如果你感興趣,我建議你在Delta.io查看我們的網站。它有一個高水平項目的概述。有一個快速的入門指南如何開始。和它也有GitHub的鏈接,你可以看,看看我們的路線圖是什麼進展並提交自己的問題你認為這個項目應該去的地方。
所以,我肯定鼓勵你這麼做。但是,我認為我們將問題。所以,我先把這些,看看我們有什麼。
問答
Michael時常要:
三角洲湖增加性能開銷嗎?
我想要打破它。所以,首先,三角洲湖被設計成一個高吞吐量的係統。所以,每個操作,有一點表演它的開銷。所以,你基本上因為而不是寫文件,我們還需要寫出文件和事務日誌寫出來。所以,這增加了幾秒鍾火花的工作。
現在,重要的是我們設計了三角洲是大規模並行和高吞吐量。所以,你找幾秒鍾添加到您的火花工作。但這主要是獨立於火花的大小工作。所以,三角洲湖是真的,真正擅長的是攝取數萬億的記錄數據或pb的數據或字節的數據。不擅長什麼數據插入個人記錄。如果你運行一個記錄每火花工作,會有很大的開銷。
訣竅是你想用δ的火花最意義的地方,這是相對較大的工作分散在很多機器。在這些情況下,開銷可以忽略不計。
因為它有酸性質,將我的係統高可用性?
三角洲,再一次,這是專門利用雲計算和利用這些好的特性。
所以,對我來說,有幾個不錯的雲的屬性。一個是雲很可伸縮。你可以把大量的數據到S3和任意隻是處理它。通常漂亮的高可用性。所以,你總是可以從S3讀取數據,不管你在哪裏。如果你真的,真的在乎,甚至還有諸如複製,你可以複製數據到多個地區。和δ扮演得很好。所以,閱讀從三角洲表應該非常高可用性,因為它隻是底層存儲係統的可用性。
現在,那些熟悉的上限定理可能會說,但是等等,所以對於權利當我們考慮一致性、可用性和分區容忍,三角洲選擇一致性。所以,如果你不能跟中央協調器,取決於你在S3,可能自己的服務,你跑步,在Azure他們采取一致性的方法,我們使用一個原子操作,係統將會暫停。
但值得高興的是,由於樂觀並發機製,這並不意味著你失去了整個工作,你可能已經運行幾個小時。它隻是意味著你要等到你能夠跟服務。所以,我想說讀起來非常高可用性而言,在權利方麵,我們選擇的一致性,但總的來說,還是很不錯的。
接下來是你保留所有級別的數據。好吧,我想我要澄清青銅的背後,銀,金。不是每個人都讓周圍的原始數據,並不是每個人都讓所有的數據。你可能會保留要求說,你隻允許保留兩年的數據。
所以,真的,我認為這是由你來決定哪些數據可以抓住。我唯一想說的是,我認為優點三角洲湖泊和三角洲一般適用於他們是如何你有權保持原始數據和盡可能多的你想要的。
所以,不存在技術上的限製,允許你保持所有的數據。結果,許多和我一起工作的組織實際上把所有他們在法律上被允許保持很長一段時間,和你隻刪除它當他們不得不擺脫它。
你寫邏輯?我們可以用Scala編寫邏輯嗎?
三角洲湖插入現有的API的所有Apache的火花,這意味著您可以使用任何這些。所以,如果你是一個Scala程序員,您可以使用Scala。如果你是一個Java程序員,工作。我們也有在Python綁定。如果你和你不想項目分析師,我們也支持純SQL。
真的如此,我們的想法是底層引擎用Scala編寫和δ也用Scala編寫的。但是你的邏輯可以用您熟悉的語言寫的。這是另一個情況,我認為你需要正確的工具,正確的工作。
就我個人而言,我做很多我的東西在Scala中,但當我需要圖表,我切換到Python。但是,三角洲給我過濾大量數據的能力,把它縮小東西會適合熊貓,然後我做一些繪圖。
轉眼間三角洲湖的一部分還是隻有火花嗎?
這是現在發展的很快。所以,有幾個不同的答案。所以,我要告訴你,我們在和我們去的地方。
現在,裏麵的一個特性的磚,我們致力於開源,它允許您為三角洲,作家寫這些東西稱為manifest文件允許您查詢一個增量表以一致的方式從轉眼間或雅典娜知道任何其他基於轉眼間的係統。
然而,我們正在深入的亮光,一轉眼間背後的公司,建立一個本地連接器很快。我們也有活躍的蜂巢的興趣社區,在滾燙的社區。所以,有很多的興趣建立連接器。今天,三角洲的核心構建在火花,但我認為真正強大的開源和開放標準是,任何人都可以與它集成。和我們的項目,我們致力於發展生態係統和使用任何人。
所以,如果你對其中一個項目提交者,請加入我們的郵件列表,加入我們的鬆弛頻道,檢查一下,讓我們知道我們如何可以幫助您構建這些額外的連接器。
我們可以嚐試三角洲湖community edition的磚嗎?
是的,你可以。三角洲湖在community edition是可用的。檢查出來。一切都應該有。讓我們知道你的想法。
和蜂巢三角洲表可以創建嗎?
是的。所以,轉眼間基本上相同的答案。有活躍的興趣社區建設的支持。今天沒有,但絕對是我們想構建。
三角洲湖是怎樣處理緩慢變化維度從原始到黃金?
實際上還有一個博客在m.eheci.com上。如果你穀歌,緩慢變化維度三角洲,它將引導您完成所有的細節。但我認為,正確的答案是,合並操作符和加上權力或火花,它實際上很容易構建的所有不同類型的緩慢變化維度。
三角洲和神奇的一件事是添加的火花,使這些交易。修改一個表會非常危險沒有交易和三角洲使這成為可能。因此,它使這種類型的用例。
我們通常處理Azure。我們想知道是否三角洲湖有什麼不同的行為在Azure上運行時事件中心而不是卡夫卡?
我將回答這個問題有點更普遍。所以,我認為我談到一個強大的三角洲,它集成了火花。和一個主要的原因就是我認為火花的瘦腰大數據的生態係統。有火花連接器世界上幾乎每一個大數據係統。
所以,如果火花可以閱讀它,它適用於三角洲湖。活動中心,特別是,既有本地連接器插頭到火花數據源,並作為卡夫卡API與火花卡夫卡作品。所以,你可以很容易地讀取事件中心和做所有的東西我今天談論使用事件中心而不是卡夫卡。其實,這適用於任何係統,火花可以讀取。
就一般而言,回答Azure一點,δ在Azure上完全支持,包括ADLS,我們最近改進的支持ADLS代。它可以為您下載。這也是Azure磚從盒子裏的一部分。
到底是Scala API DML命令,喜歡更新嗎?
答案是,它看起來像這樣的火花SQL。火花SQL,您傳遞一個字符串,並更新。答案是,我們會同時支持。所以,如果你真的去GitHub庫,我相信這段代碼已經被合並。所以,你可以看到Scala API。如果不是,有設計,討論細節添加更新的票。
但這裏的想法是,都將是一個Scala函數叫做更新可以使用編程方式無需執行字符串插值。還有一個SQL的方法,這樣你就可以創建一個SQL字符串,並傳遞。再說一遍,這就像你用你最熟悉的語言,已經工具包的一部分,和δ應與自動工作。
三角洲湖與HDFS工作嗎?
是的,這完全與HDFS。HDFS有我們需要的所有原語,所以你不需要任何額外的細節。這裏我所說的是HDFS支持原子重命名失敗如果目的地已經存在。
所以,隻要你足夠運行一個新的版本的HDFS,這甚至不是新的,應該自動工作。如果你查看入門指南,在δδ文檔。io,所有不同的存儲係統,我們支持和細節你需要做什麼設置。
更新、刪除一行或記錄水平?
這個問題有兩種答案。所以,是的,三角洲允許你做細粒度的個人行更新。所以,你不一定要做更新或刪除在分區級別。如果你在分區級別,他們是重要的。如果你喜歡刪除,例如,在分區級別,這是更有效,因為我們可以將元數據。我們不需要做任何手動修改。
但是如果他們不是在分區級別,如果你做一個細粒度的單行更新或刪除,我們要做的是我們會找到相關的拚花文件,修改,提交添加和刪除操作發生。然後,它的事務。它支持它,但它確實涉及重寫單個文件。
所以,我在這裏要說的是如果δ絕對不是設計成一個OLTP係統,你不應該使用它如果你有大量的個人行更新。但是我們支持細粒度的用例。
你知道什麼時候三角洲湖的Scala api可以嗎?
嗯,有幾個答案。所以,三角洲湖閱讀和寫作和流媒體和批處理工作今天已經在Scala中可用。如果你專門談論更新、刪除和合並,我相信大部分的代碼已經被放入存儲庫。所以,如果你下載和構建它自己,它的存在。我們希望7月發布。希望這個月,會有下一個版本,其中包含額外的Scala api。
讓我們來看看。是的。所以,下一個問題是關於數據質量。我們可以有其他字段進行驗證的目的除了時間戳?是的。所以,我們之前談論的預期,隻是一般的SQL表達式。所以,任何期望,您可以在SQL編碼是允許的。
因此,在這個示例中,它是一個非常簡單的比較操作和一些具體日期。但它可以是任何你想要的。它甚至可以是一個UDF,檢查數據的質量。真的,最重要的是,我們隻是讓你把這些作為屬性的數據流,而不是手動驗證你自己記住要做的事。所以,實施全球在任何人使用該係統。
三角洲湖是否支持合並的數據幀而不是臨時表?
是的。所以,一旦Scala和Python api可用,然後你可以通過在一個數據幀。今天,磚,唯一可用的是SQL DML。在那種情況下,你需要注冊一個臨時表。但就像我說的,請繼續關注本月底。我們將有一個釋放Scala api,然後你就可以通過自己在數據幀。
我見過幾次這個問題,所以我隻回答一次。我們同時支持ADLs Gen1和代,盡管代會更快,因為我們有一些額外的優化。
在檢查點的例子中,是引發工作計算三角洲湖檢查點內部需要手寫嗎?
所以,當你使用流讀取或者寫入三角洲表,如果你隻是使用它在兩個不同的三角洲表、檢查點是由結構化流處理。
所以,你不需要做任何額外的工作來構造檢查站。內置的引擎。火花的結構化流的工作方式是每一個源和一切,有一個合同,允許我們做自動檢查點。所以,源需要能夠說,從這裏到這裏我處理數據。和那些在流的概念,我們稱之為補償,這些需要是可序列化的。我們商店的檢查站。我們基本上使用檢查點作為正前方日誌。
所以我們說批號10將是這些數據。然後我們試圖過程批號10。然後我們把它同步。這裏的擔保是必須項強大的同步。因此,它必須隻接受批號10次。如果我們試圖把它寫兩次由於失敗,它必須拒絕就跳過它。把所有這些約束在一起,你實際上得到一次處理自動檢查點沒有你需要做任何額外的工作。
為什麼不使用通曉多種語言的持久性和使用RDBMS存儲acid事務?
我們嚐試這一點。事實上,早期的三角洲使用MySQL版本之一。這裏的問題是,MySQL是一個單獨的機器。所以,剛剛的列表文件為一個大桌子可以成為瓶頸。而當你將元數據存儲在一個表單,火花本身可以本地過程中,您可以利用火花加工。
所以,沒有什麼阻止你實現三角洲事務協議的存儲係統。事實上,有一個很長的談話在GitHub庫現在的什麼來回需要建立基礎數據庫版本的三角洲。是的,這當然是可能的。但在我們最初的可伸縮性測試,我們發現火花是最快的方法,至少我們的係統測試,這就是為什麼我們決定這樣做。
這是否意味著我們不需要數據幀和可以做所有轉換三角洲湖呢?
我說不。哦,我想你隻能更新、刪除和合並不使用任何實際的數據幀代碼可以使用/ SQL。但實際上,我認為這是正確的工具,正確的工作。
三角洲湖深深地集成引發數據幀。,就我個人而言,我覺得這是一個非常強大的工具進行轉換。就像SQL + +,因為你有這些關係的概念,但嵌入在一個完整的編程語言。其實我覺得可以是一個非常有效的方式寫你的數據管道。
三角洲湖如何管理引發的較新版本?
三角洲湖需要2.4.3火花,這是一個非常最近的版本。因為有蟲子在火花的早期版本中,阻止數據源正確插進去。但總的來說,我們正在努力火花兼容性。這是本季度我們的核心項目之一是確保一切三角洲插入好穩定公共api的火花在未來我們可以處理多個版本。
三角洲湖是否支持獸人?
再次,討論GitHub添加支持。所以,我鼓勵你去檢查在這個問題上投票如果這是對你很重要的東西。
這個問題有兩種答案。一個是三角洲湖事務協議。我認為這實際上是在事務日誌和實際支持指定的格式存儲的數據。所以,它實際上可以用於任何不同的文件格式,txt, JSON、CSV、內置協議了。今天,我們不公開,作為一個選擇當你創建一個增量表時,我們隻做拚花。
原因很簡單。我隻是覺得調諧旋鈕通常是越少越好。但RFC,如果有很好的理由為什麼您的組織可以切換,我認為會很支持,很容易添加。這是我們社區的討論。所以,請到GitHub,發現問題和填補它。
之間的區別是什麼附帶的三角洲湖磚和開源的版本嗎?
這是一個問題,我有很多,我認為思考這個問題的方法是我想談談我的哲學是什麼開源背後。那就是我認為的api通常需要開放。
所以,任何程序可以正確運行的內部磚也應該在開源工作。現在,今天這並不完全正確,因為開源版本的三角洲湖隻有兩個月大。所以,我們要做的是我們正在努力開源存在的所有不同的api。所以、更新、刪除、合並的曆史,你可以做所有這些事情的磚也將可用的開源版本。
管理三角洲湖是我們提供的版本。這將是更容易建立。它會與所有其他的集成塊磚。所以,我們做緩存。我們有一個更快版本的火花。因此,運行更快。但在功能方麵,我們的目標是為這裏特性校驗完成,因為我們致力於使這個開源項目成功。我認為開放api是正確的方法。
所以,我想我們會結束它。今天非常感謝你加入我。
