網易數據湖探索與實踐

導讀: 今天主要和大家交流的是網易在數據湖Iceberg的一些思考與實踐。從網易在數據倉庫建設中遇到的痛點出發,介紹對數據湖Iceberg的探索以及實踐之路。

主要內容包括:

  • 數據倉庫平臺建設的痛點
  • 數據湖Iceberg的核心原理
  • 數據湖Iceberg社區現狀
  • 網易數據湖Iceberg實踐之路

01 數據倉庫平臺建設的痛點

痛點一

我們凌晨一些大的離線任務經常會因爲一些原因出現延遲,這種延遲會導致核心報表的產出時間不穩定,有些時候會產出比較早,但是有時候就可能會產出比較晚,業務很難接受。

爲什麼會出現這種現象的發生呢?目前來看大致有這麼幾點要素:

  • 任務本身要請求的數據量會特別大。通常來說一天原始的數據量可能在幾十TB。幾百個分區,甚至上千個分區,五萬+的文件數這樣子。如果說全量讀取這些文件的話,幾百個分區就會向NameNode發送幾百次請求,我們知道離線任務在凌晨運行的時候,NameNode的壓力是非常大的。所以就很有可能出現Namenode響應很慢的情況,如果請求響應很慢就會導致任務初始化時間很長。
  • 任務本身的ETL效率是相對低效的,這個低效並不是說Spark引擎低效,而是說我們的存儲在這塊支持的不是特別的好。比如目前我們查一個分區的話是需要將所有文件都掃描一遍然後進行分析,而實際上我可能只對某些文件感興趣。所以相對而言這個方案本身來說就是相對低效的。
  • 這種大的離線任務一旦遇到磁盤壞盤或者機器宕機,就需要重試,重試一次需要耗費很長的時間比如幾十分鐘。如果說重試一兩次的話這個延遲就會比較大了。

原文鏈接:【https://www.infoq.cn/article/HBJ9semJsyytltjQQ2wg】。未經作者許可,禁止轉載。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章