大規模使用結構化流Lakehouse實現

托馬斯Magdansk…:你好。我要告訴你,你不會找到任何書籍或一個博客。我將與你分享真正的障礙你會試圖建立大型數據時遇到湖。我將簡要談談Asurion。我們是如何走到這一步的?如何運行可伸縮的和具有成本效益的lakehouse嗎?最重要的是,教訓。
我們是一家大型保險公司和支持。每天超過10000的專家參與支持會話來幫助世界各地的超過3億人,從技術支持和服務跨越同一天設備修理和更換。隻是給你一個想法關於這個項目的大小,我們lakehouse吸入超過4000表,從100 +數據庫。我們創建七個半千datalake隻有兩個表的表裏麵,我以後再談。我們攝取流數據從卡夫卡、運動、社交和SQS,以及文件、平麵文件和數據api。
我們甚至做其他雲提供商的數據。從SQL server數據庫來源,甲骨文,PostGreSQL, MySQL動態開始紅移。在數據倉庫中,我們把成千上萬的那些表生產超過300 600年數據模型和數據集市。最後,在我們的消費層中,我們有超過10000個數據視圖和超過2000報告。我們之前的架構是基於Lambda架構。正如你可能知道,λ架構包含速度層和批處理層,還有幾個問題。首先,你有兩次來處理一切。你也必須驗證數據兩次,通常你需要使用不同的技術。或者你必須處理後期數據到不同的方麵,你需要擔心後處理的數據在大多數不變的空間。你必須擔心調度,重寫和查詢。 Data updates are also really difficult, which makes the data compliance more difficult.
我們沒有電腦存儲分離的困難和昂貴的可伸縮性。我們的數據延遲主要是d 1,我們也有一個非常廣泛的技術堆棧。從紅移到λ,運動,運動消防帶,EMR, rds,蜂巢,頻譜。很難管理。然後我們看了看湖的房子建築隻有一個單一的管道。我們有一個實時數據延遲功能,可伸縮性的Apache火花,一個很高程度的綜合生態係統,技術堆棧真的非常狹窄。這是非常,非常有前途。
另一個重要的進步,幫助開發了利用直接的生產數據。我們旨在盡可能最小化數據運動和利用計算機存儲分離。開發數據平台,獲得真實的生產數據Beplay体育安卓版本來識別並修複許多微妙的問題,以及處理實際規模是我們在開發環境中無法複製。這個結果對我們來說是非常可取的。我們用我的角色和掛載點透明連接pre-product計算集群在隻讀模式,我們也生產數據寫入數據回生產包。因此,數據沒有長期居住環境,真正的計算和存儲部分分離。這張照片很重要,我們會回到吸取的一個教訓。
現在在我們之前的體係結構中,我們有一個ETL每表映射工作,使平台非常嚴格。Beplay体育安卓版本4000年我們有有效的映射,如果你需要做出改變在許多映射,這是一個大量的工作平台是抵製改變,因為改變事物的複雜性。Beplay体育安卓版本在湖邊的房子,我們想創建一個火花攝入的工作是能流和批處理和閱讀所有的來源和完全可配置的,我們寫這份工作在Scala中使用設計模式和依賴注入允許非常富有的可配置性。我們選擇結構化流利用檢查點,確切或至少一個語義和我們統一的接口,我們的著陸區,S3和卡夫卡。數據庫,疾控中心管道、api、平麵文件都上傳到S3和SNS SQS和運動都是上傳到卡夫卡。然後我們安排我們的攝入工作使用磚作為股工作和臨時性集群。這完全允許高度測試,易於維護和非常靈活的代碼。
我們的數據湖三角洲表中的所有表。作為數據湖的一部分,我們需要保持一個緩慢變化維度隻類型附加表跟蹤更改所有行和列和分數,我們稱之為L1表,但是我們也需要存儲相關版本的每一行,像搜索引擎(聽不清)類型通過合並更改目標表和我們稱之為L2表。我們有一個選擇。你從著陸區結構流流數據從L1, L2 L1,然後呢?但這將有效工作從4000年到8000年的兩倍。因此,廣泛的測試後,我們決定利用權力為每個批處理API來編寫兩個表在同一時間。如果你…智力盒大大地簡化,但我們不實際使用裸火花。我們的讀者和作家環繞火花。我們也裝修我們的數據大量增加強製性元列在打造一批。
下一個選擇,我們必須在觸發選擇和一種原生方法問題是取出攝入的工作,這是一個流媒體工作,把它作為一個短暫的工作。的挑戰,現在的我們有4000個表運行和磚碎片隻允許1000個工作崗位。和最重要的是,這些短暫的集群會有司機和至少兩個節點,這將使我們在12000個節點環境中,這有點奢侈,我們不覺得這是最好的利用資源。下一步我們看著結合許多流工作在筆記本和運行作為一個短暫的工作,我們發現了一種甜點司機處理大約40流。
當然集群必須大處理所有流,但是我們也已經注意到相當高度的電腦浪費因為在這些40流,可能會有流經常沒有數據,但我們讓他們運行所有的時間。這種方法的另一個問題是,如果我們想要禁用一個單獨的數據流,我們有效地不得不停止工作,將停止所有40的流。所以我們想找出一種更好的方式能夠換一份工作或者把它從筆記本筆記本或集群,集群不需要停止所有其他工作。最後,我們選定了一個觸發器,以及那些可能不知道觸發一個選擇結構化流,將收集的所有數據到你的馬克斯•流或數量的文件或字節的過程數據,然後檢查點進程終止工作。
所以你真的負責調度微批次當你想讓他們運行。這意味著沒有連續執行,這允許我們在筆記本上把數以百計的工作在一個短暫的集群。現在,因為這些工作是運行在時間表,我們可以遷移他們的筆記本輪之間。我們還可以刷新在每一輪每一輪衝突,所以唯一的配置更改我們沒有任何重啟立即生效。我們也正在使用機器學習振興工作在不同的集群,以確保我們滿足我們學校圖書館的數據。我們有五種類型的筆記本電腦運行短暫的工作,和那些筆記本有一個小組分配給他們。他們去數據庫,配置數據庫,他們收集所有屬於這個群體的工作要處理,然後運行(聽不清)係列的這些工作,或通過使用集合力量,我們可以麻痹工作執行所有課程的數量,司機,這通常是16和32兩個工作同時運行。
我們有5個口味的筆記本。我們有一個經常更新的東西,我們可以把大約60個表每一個筆記本。我們的目標是在60分鍾內完成所有的更新和合並。我們有更少的頻繁更新的表,我們可以把300年到500年。然後經常更新表,我們可以把多達一千。這種方法的好處是,我們可以在頻率和表,日益增長的移動這些組之間無縫和無縫地平衡這些工作沒有資源或影響其他工作,組內運行的。
我們也可以實現我們稱之為偽流通過y-loop筆記本運行工作,我們測試和性能非常接近隻是運行處理觸發,讓火花處理micro-batches的執行。除了我們可以檢查每個y-loop的配置上,這意味著如果我們有五個工作運行,我們想禁用其中之一,我們隻是禁用其中一個,和下一個迭代是不會在其他四個沒有重新啟動運行。
好吧。所以讓我們繼續我們的教訓而建立這樣一個大規模的湖環境。嗯,首先,讓我們來談談雲文件。對於那些不知道,雲文件自動加載程序的一部分,提供的磚,當你使用AWS和試圖讀取一個文件夾,磚的文件夾將自動創建一個S3通知將使它成為一個社交網站,然後它會的SNS, SQS訂閱訂閱一個社交網絡。現在,首先,AWS隻允許每鬥100通知。所以你要寫一些自動化來知道你已經飽和通知後端,你可能需要部署一個新類型的工作在接下來的桶。
接下來,SQS和SNS不是標記在默認情況下,至少今天。如果你像我們一樣或需要標記的所有你的資源,你要騎某種λ或某種功能的通知和檢測到磚創建資源在您的帳戶,並適當地標記它們。最後,AWS api, SNS已經硬限製ListSubscriptions ListSubscriptionsByTopic,磚使用這些api來檢查是否已經有…SNS已經一個SQS訂閱。如果你運行足夠的就業機會,就像我們運行成千上萬的工作同時,我們已經看到時間達到這些限製,我們的工作失敗。今天唯一的選擇就是為了解決這一問題是是否存在非常緩慢的表不改變很多,在那裏我們可以做禁用通知,或者隻是傳播他們更多的時間來努力避免這樣做。但在某種程度上,我們將達到的規模,我們隻是會遇到這些問題。
好吧。另一個教訓,我們了解了雲文件。我回到數據計算隔離幻燈片,我之前講過。從另一個賬戶,所以當你pre-prod計算請求數據從生產賬戶,磚將設立一個通知,它將建立一個社交網站,然後它會建立一個SQS。但是如果你注意到,SNS和SQS的賬戶計算,不是的賬戶存儲。
這工作和你的測試工作,太好了,你準備部署到生產環境。你你的工作部署到生產環境中。你犯同樣的請求數據,而這一次磚創建一個SQS隊列僅僅是因為一個SNS已經存在,對嗎?現在,是的,你的生產數據,但是整個雲通知和文件貫穿pre-prod環境中,當然有問題。我們部署期間我們要做的是清理通知,生產運行工作第一,讓生產工作建立了SNS和SQS,然後開始SNS的預生產跳訂閱的主題。這是最後一步,但這是一個額外的步驟在我們我們要做和自動化部署過程。
好的,下一個。我們把數據從成千上萬的數據庫表通過AWS DMS,和我們使用CDC變化數據捕獲流動。所以當你第一次去嚐試使疾病預防控製中心在桌上,你必須做兩件事。你必須使負載和疾控中心。負載是什麼意思是,這是一個表的快照在那個特定的時間,然後疾控中心是一個過程,需要被記錄的數據庫後跳過每個角色的變化。現在,我們發現這個設置的挑戰是加載文件可能需要數小時和疾控中心文件正在被跟蹤一旦你開始你的工作。所以有機會有一個對象(聽不清)的中心部分管道之前,將有一個時間戳,加載文件完成,現在加載文件分配的時間戳。
所以你有一個加載文件版本的時間戳的行之前,疾病預防控製中心更新版本的行。所以我們重置DMS加載文件的時間戳為零,以避免這種競爭條件。再上一節課我們學過DMS和疾病預防控製中心是數據類型轉換,因為DMS可以連接到任何數據庫,我們發現有時候不交談正確的數據類型。舉個例子,我們是一個SQL服務器,一個小小的Int轉換為單位,我們已經看到一些溢出,我們必須應用的規則,你可以看到在底部幻燈片來迫使它返回一個整數。在Oracle中,例如數字轉換為小數(38歲,10),有一個選項來設置到38歲,38歲,但舉個例子,在Oracle數據庫、數字列是一個精密的50。所以我們沒有辦法把數據。我們必須設置設置稱為numberDataTypeScale - 2,這有效地轉換成一個字符串。
另一個教訓。加載文件可以大,他們可以當你讀斜數據。所以你可能需要做一些鹽。DMS文件不分區,所以考慮壓實或隻是意識到將會有很長一段時間被火花讀過你的DMS桶。如果你幾個月後重新啟動,會有成千上萬的小文件。我們將DMS刪除所有的文件當我們開始任務,隻是一張白紙,試圖緩解這問題,減少數據重複。數據庫上有消息來源可能有大量的事務。
讓我帶你回去。當我們有多個更新在一個micro-batch一行,我們必須決定哪一個是延遲。這個說我們想要合並到目標表,和開始的時候我們認為我們能使用時間戳,因為通常他們去毫秒或微秒,但我們發現,如果你手動打開一個大型事務數據庫中,和你把很多更新事務的同一行到你關閉交易,所有的更新有完全相同的時間戳。所以你是不可能的,以確定哪些是最新的。所以我們必須把所有數據庫的LSN通過DMS,以確保我們有某種確定的合並和獲得最新的行。
現在,我們已經學會了另一個教訓是,如果數據庫沒有主鍵,但有一個獨特的約束,您可以使用合並,約束包含null值,源的null值很多,Databrick合並三角洲不會認識到零,零匹配的時候,它會插入新行。所以我們必須做的是替換所有的null字符串null或空字符串確定的合並。
關於卡夫卡教訓。如果你使用卡夫卡對於某種疾病預防控製中心管道模式,也有可能,你可能已經表沒有很多交通,和你不想配置大量的分區和浪費大量的資源對卡夫卡的小桌子,但實際上初始加載的數據實際上可能帶來數百萬行到主題。現在你有一個主題,沒有大量的分區,但它有很多的數據和你不一定想re-partition主題僅一讀。所以我們建議設置最低分區和馬克斯抵消/觸發高數。在我們的例子中,我想我們分區4000和抵消10000強製引發癱瘓的重量這個話題,無需重新分配速度。
我們也使用我們的第一個我們寫的L1表。我們優化表內每一批,然後我們把它作為一個源L2合並。這是為了避免一個動作,第二個動作,回到源,因為源可以是緩慢的。DMS可以停止因為這個數字的文件或卡夫卡在這種特殊情況下也可以是緩慢的。總之,我們采用了模式添加一批數據幀ID列,我們寫L1,我們優化如果需要,然後使用相同的批ID來過濾數據從L1合並。我們發現這個模式比回到源,更快或者緩存如果你有大量的數據,也會慢一些。
我們學會了與卡夫卡的其他課程。嗯,我們想要使用觸發器一旦一切盡可能多我們有選擇,運動和其他來源不支持這個的。所以我們必須將所有的SNS, SQS,運動到卡夫卡使用卡夫卡連接,然後我們可以使用支持…我們可以用卡夫卡觸發一次做這份工作完全相同的方式為我們所做的工作,例如,在DMS。
對三角洲的教訓。第一次,當你把數據表手動優化你的,因為你會更快(聽不清),然後使三角洲優化寫道,因為合並重寫大量的數據。優化寫非常好合並和找出文件的大小,所以你不需要經常做壓實優化。移動你的批處理ID和合並列dataframe麵前。
所以Databrick收集統計數據幀的第一行。如果你有一個很寬的數據幀,你不會得到末期可能列上的統計信息,特別是如果你隻是增加了批ID,這將是最後一列。你需要批量ID過濾,例如。所以移動一切你要合並,尋找dataframe的前麵。如果你使用一個合並列增量,像汽車更新的數字,例如,等等,您還可以使用命令數據在同一個地點協同工作,進一步減少文件數量,需要閱讀和跳過它的數據。我們也一直推薦使用分區和使用i3與IO緩存實例類型三角洲。
所以其他的教訓。如果你有任何其他的工具,需要閱讀三角洲,像我們,例如,我們使用很快,你必須寫S3路徑,當你注冊你的蜂巢中δ表。因為很快不會理解DBFS,它不會明白(聽不清),所以我們必須手動創建表定義,把S3路徑。如果你想讓你的三角洲文件讀寫的雅典娜,或者隻是蜂巢一般來說,或者頻譜,您需要生成manifest文件manifest文件和啟用自動更新。這種方式,non-Delta或non-Delta事務,地方(聽不清)技術仍然可以manifest文件讀取鋪文件。
轉眼間和火花視圖不兼容。隻是需要注意的東西,因為如果你創建一個視圖在火花,轉眼間不會能夠利用它和其它的方法。我們還發現,提取δ統計行數,最後修改成熱緩存實際上是非常可取的,因為我們需要很多的工作負載前表更新,許多依賴表更新。假設你有任何TL要求30歲,40表更新。擁有一個運行集群和發行40描述命令是緩慢的隻是為了確定你可以運行工作。所以通過提交這些統計數據的每一個熱緩存,下一份工作隻是讀取現金和決定了我所有的表都更新,我很好,我現在可以去安排工作。
好吧。最後,三角洲和火花一起流的δ表,但目前,截至今天,它隻適用於附加。它是有意義的,因為當你添加三角洲表,您將新文件插入到表和事務日誌,和任何人聽表知道有新文件和讀取新文件。這很有道理。現在與合並,這是更複雜,因為合並重寫所有的數據。是的,有一個新創建的文件和文件可能有一百萬行,但我們隻在該文件更新一千行。如果你在該文件下管道,你必須過濾下來的幾百萬行幾千行,實際上已經改變了。和我們如何做呢?
再次,我們利用批處理ID,我們添加了早先知道新批,27歲,我隻接27日的數據,因此過濾大量小文件。這不是最有效的,但它工作得很好。最後,SQL分析一下我們如何使用SQL分析。所以我們的數據集市是由超過1000個SQL查詢和語句的集合。我們需要一個數據集市的方式解除,從以前的實驗室平台轉移到這個平台,所以我們需要良好的可擴展的SQL執行引擎。Beplay体育安卓版本當然,火花,我們想利用現有的框架我們已經到位並提交SQL語句通過JDBC連接器火花集群。第一個選項是使用交互式集群,但是他們是相當昂貴的。
所以我們更向也許EMR開源火花和和三角洲。當SQL分析產品走進我們的範圍和它仍然支持JDBC連接,所以這是一個完美的適合我們能夠發送這些SQL查詢和創建數據集市。一些經驗教訓到目前為止,因為它是一個早期的產品是我們必須收集所有的度量api和把它們放在三角洲表監視和性能。你是隻允許使用一元店/ SQL工作區,這意味著如果您有多個不同的SQL端點,他們都要分享一元商店,這是不同於集群,我們可以在每個集群配置不同的元商店。所以我們有點約束的分離計算和存儲和跨帳戶和使用元店真的綁在一起。
它還不支持UDF。所以如果你需要一個(聽不清),你仍然要依靠集群互動引發SQL,您可以附加罐子和這次將沒有罐子SQL分析。最後,你還要學會排除火花。所以你還是要學會理解熟練的技藝和火花的工作和SQL意見火花UI,因為這僅僅是一個引發下麵工作。因此可有效發現瓶頸在你的查詢,你仍然要這樣做。
好的,非常感謝。這是問答時間。謝謝你,請提供你的反饋。我們想要聽的。我們想提高內容的質量,我們與你分享,如果你有任何問題,如果你想聯係我離線,請隨時聯係我在LinkedIn。謝謝你！