跳轉到主要內容
工程的博客

如何YipitData從替代數據提取的見解用三角洲湖嗎

阿努普Segu
鮑比·馬爾登
通過阿努普Segu和鮑比·馬爾登

2021年9月21日 在工程的博客

分享這篇文章

得到一個O ' reilly的新電子書的早期預覽一步一步的指導你需要開始使用三角洲湖。

這篇文章從YipitData。我們感謝Anup Segu、數據工程技術主管和鮑比·馬爾登:YipitData數據工程,主管他們的貢獻。


選擇合適的存儲任何數據格式湖是一個重要的數據管理員負責。存儲成本之間的權衡,性能、遷移成本和兼容性的頭腦當評估選擇。一個選擇湖是絕對考慮為您的數據三角洲湖一個開源高性能存儲格式,可以從根本上改變如何與任何規模的數據集進行交互。

與三角洲湖及其流功能,YipitData有效地分析pb級原料,替代數據回答主要金融機構和企業的關鍵問題。這個博客將概述YipitData的總體設計和使用三角洲湖與替代數據方法。

YipitData如何為客戶生產的見解

productizing YipitData專門從事采購,分發替代數據世界上最大的投資基金和企業。產品團隊的數據分析師完成對原始數據集,深入研究設計精確的方法來回答客戶的問題,和分發,研究各種各樣的媒介。數據工程師操作管理員提供工具的磚平台進行數據操作方便,可靠和安全的產品團隊。Beplay体育安卓版本在早期,產品團隊關注的是分析公共web數據規模相對較小。拚花和轉換中存儲的數據是在一係列的批量轉換使用Apache火花™通知的分析報告、圖表和細粒度的數據文件交付給客戶。

YipitData產品團隊分析清洗各種數據源,聚合,並分發給客戶
清洗,聚合,並分發給客戶

在過去的幾年裏,團隊越來越多地使用各種新源數據,如信用卡、電子郵件、和許多其他數據類型,研究100 +公司和計數。這些新數據源大大增加YipitData提供市場的見解的能力在各種垂直和更好的服務客戶。

挑戰與替代數據

隨著數據源的數量增加,同時新數據集的規模和數量增長。傳統方法使用批處理轉換沒有擴展以滿足產品團隊的需求。

  • 大型、頻繁的數據交付需要不斷刷新的下遊分析在短時間內。
  • 批量轉換需要太長時間,這是一個重要的考慮因素為新客戶提供及時的分析的數據源。
  • 技術生產表上理解數據趨勢轉變成為分析師和數據在這個複雜的和不可靠的。
  • 嚐試使用增量流轉換被意想不到的困擾,無法核實的ETL管道的變化。

YipitData需要更新它的方法攝取,清潔,和分析非常大的數據集,繼續履行的使命幫助客戶回答的關鍵問題。

三角洲是一個健壯的數據存儲解決方案,提高了分析

現在YipitData分析師使用三角洲湖作為所有的存儲層ETL過程和特別的探索分析替代數據。這允許他們:

  • 利用三角洲的結構化流api,提供直觀、可靠和高效的轉換高容量的數據集。
  • 跟蹤的變化改變了數據並留住過去版本使用三角洲的事務層,以減少數據丟失的風險或腐敗。
  • 使用增量執行QA時間旅行在通過複雜的批量轉換生成的數據。
  • 獲得真理的“源”磚自動裝卸機可靠地將數據從第三方提供商獲得轉化為“青銅”三角洲表。

三角洲流促進攝入大量數據

產品團隊越來越關注從大型數據集提取價值,YipitData外部來源。這些原始數據集可以向上的幾個TBs的規模和添加10 - 20 GB的新數據每天成百上千的文件。前三角洲,通過批處理應用轉換是耗時和昂貴的。這樣的轉換效率後處理~ 99%每天刷新下遊分析的數據集。生成一個清潔表最新的記錄,使用下麵的代碼:

#一些授權數據是交付作為一個高容量,附加- - - - - -隻有數據提要的記錄#記錄可以標記作為要麼新(“N”)、更新(“U”),或刪除(“D”)從源方從pyspark。sql導入函數作為F DataFrame窗口new_or_updated=(spark.table (“records_feed”)。在哪裏(F.col (“record_status”)。isin ([“N”、“U”])))刪除=(spark.table (“records_feed”)。在哪裏(F.col (“record_status”)==“D”))clean_records=(new_or_updated.withColumn(“排名”,F。排名()。在(Window.partitionBy (record_id) .orderBy (F.desc (“record_created_timestamp”))))。在哪裏(F.col(排名)==1)。下降(“排名”)。加入(刪除“record_id”,如何做=“left_anti”))
              clean_records.write.format(“鋪”).mode(“覆蓋”).saveAsTable (“records_clean”)

δ流,分析師可以可靠地和專門操作增量數據傳遞和成倍增加ETL工作流的效率。三角洲的聲明式api方便手術添加、替換,或刪除數據從下遊三角洲目標表與事務保證烤在防止數據損壞:

從pyspark。sql導入函數作為F, DataFrame從三角洲。表s import DeltaTable
              def cdc_transformation (batch_df: DataFrame batch_id:int)- - - - - ->沒有一個:new_records=batch_df.where (F.col (“record_status”)==“N”)new_records.write.format(“δ”).mode(“追加”).saveAsTable (“records_clean”)表=DeltaTable。forName(火花,“records_clean”)table_df=table.toDF ()updated_records=batch_df.where (F.col (“record_status”)==“U”)(表。合並(updated_records updated_records.record_id==table_df.record_id).whenMatchedUpdateAll ()。執行())deleted_records=batch_df.where (F.col (“record_status”)==“D”)(表。合並(deleted_records deleted_records.record_id==table_df.record_id).whenMatchedDelete ()。執行())
              
              (spark.readStream.table (“records_feed”).writeStream.format(“δ”).option (“checkpointLocation”、“dbfs: / / records_clean / _checkpoints”).foreachBatch (cdc_transformation)。觸發(一次=真正的)。開始())

使用api如.merge .whenMatchedDelete .whenMatchedUpdate,這個數據集數據處理成本是50%,運行時減少了75%。

雖然有些ETL工作流由YipitData分析師有利於結構化流,許多人隻可能通過批量轉換。保留過時的數據批處理轉換是有用的審計和驗證數據的產品運往客戶。與δ,此功能的操作每個表創建一個新版本的表。分析師可以迅速了解操作進行他們發布的數據集,甚至恢複版本恢複任何意料之外的變化。

使用曆史操作,YipitData分析師獲得可見性,“誰,什麼,在那裏,當“關於行動在桌子上。他們還可以查詢曆史數據從一個表使用三角洲時間旅行理解表在任何時候的狀態。

δ表——顯示所有最近的交易描述曆史records_clean從過去的版本——查詢數據選擇*從records_clean版本作為的5——另外,查詢數據從一個特定的時間點選擇*從records_clean時間戳作為的“2021-01-01”
與previous_data作為(選擇date_trunc (“周”record_date)作為一個星期,數(record_id)作為時候,總和(數量)作為總從records_clean時間戳作為的“2021-01-01”集團通過1),current_data作為(選擇date_trunc (“周”record_date)作為一個星期,數(record_id)作為時候,總和(數量)作為總從records_clean集團通過1),選擇p.week,p.txns,c.txns,p.total,c.total,((c.txns- - - - - -p.txns)*100.0/p.txns)作為txns_diff_pct,((c.total- - - - - -p.total)*100.0/p.total)作為total_diff_pct從previous_data p左加入current_data c使用(周)

在場景表覆蓋不正確,三角洲提供了方便恢複操作撤銷相對迅速地變化。這大大提高了耐久性的生產數據,而無需複雜的解決方案從工程團隊。它還使分析師更具創造性和實驗在創建新的分析修改數據存儲在三角洲遠低風險。

創建一個與磚自動裝卸機的“真理”的來源

YipitData越來越接受替代數據從各種各樣的來源(web、卡、電子郵件等),保持一個有組織的數據湖是最重要的保證新數據源得到正確的產品負責人。磚自動裝卸機使得YipitData標準化的攝入這些數據源通過生成δ“青銅表”格式。銅表作為analyst-owned起點(s)新建產品化數據ETL工作流,下遊“銀”和“黃金”表。YipitData分析師完成他們的分析隻在三角洲表和不需要應對的挑戰處理原始數據格式,通常提供更糟糕的讀取性能,等缺點。

使用磚中的cloudFiles連接器流增量文件交付的任何原始格式
任何原始格式為“青銅”三角洲表事務擔保

自動裝卸機專門管理數據攝入從常見的文件格式(JSON、CSV、拚花等)和更新增量δ表作為數據的土地。表的曆史還用於更好的理解產生了多少數據和查詢過去版本的這些表調試問題下遊ETL工作流。

湖YipitData的數據遷移到三角洲

充分意識到三角洲的好處,所有現有工作負載遷移以三角洲格式存儲數據,而不是拚花是必要的。YipitData有超過60000個表住房pb的數據,所以遷移過程是重要的考慮。在此之前遷移,分析師此前內部PySpark功能開發的數據工程團隊從SQL查詢或dataframes生成表。這種“create table”實用程序標準化的表鑲花格式的作品通過包裝PySpark dataframe api。

三角洲操作支持所有火花dataframe api,所以直接切換到寫作δ而不是拚花。在拚花格式表,轉換操作表遷移到三角洲的地方沒有複製雲存儲文件。通過使用這兩個功能,創建表的效用是重新實現引擎蓋下和所有數據ETL工作流自動轉換為在三角洲或書麵。因此,YipitData轉而使用三角洲和湖的整個數據分析師對其影響最小。

結論

YipitData的成功是由它能夠快速、準確地回答客戶的問題。支持結構化流攝入的三角洲,YipitData能夠快速、可靠地攝取,清潔,和分析非常大的、有價值的替代數據集。

  • 聲明式流api大大減少ETL運行時導致及時,為客戶價值的見解。
  • δ為每個表提供了事務操作,該操作允許YipitData分析師創建彈性攝入管道監控。
  • 通過自動裝卸機數據湧入青銅三角洲表可以由任意數量的查詢和轉換下遊用戶,幫助滲透原始數據在許多產品團隊。

因此,YipitData獨立分析師可以將新數據源使用δ為多個數據產品,回答客戶的問題。這些來源甚至燃料公司的新產品開發。同時,三角洲演變,YipitData興奮地繼續通過其數據lakehouse平台解鎖商機。Beplay体育安卓版本

閱讀更多

如何yipitdata削減超過250萬的aws比爾

使用在Yipitdata磚作為一個分析的平台Beplay体育安卓版本

反複出現的數據交付和攝入與S3 bucket複製

Yipitdata如何使用磚與AWS集成的膠水嗎

數據在Yipitdata團隊效應

客戶的故事- - -YipitData轉向其數據團隊將金融市場信息過載的洞察力。

免費試著磚
開始
看到所有工程的博客的帖子
Baidu
map