Data Lake Analytics - Deprecated：資料湖管理FAQ

什麼是Lakehouse？

“Lakehouse”是基於資料湖的數倉，一種新的巨量資料範式，最根本出發點就是為瞭解決單純Data Lake應用下的各種問題，例如不支援UPSERT，不支援多版本，不支援增量ETL，小檔案太多，格式不是分析型的，元資訊不統一，Schema沒有約束，缺乏合理的資料索引等等。

圍繞OSSObject Storage Service等資料湖儲存，構建上層可擴充的資料入湖能力，把Hudi、Delta等高效的對象管理格式和Parquet、ORC等對象格式，寫入到資料湖中，並在寫入過程中支援UPSERT、小檔案合并、MVCC多版本、快照讀等能力，用數倉的特性來解決單純Data Lake下所不能提供的能力；在寫入過程中維護海量的庫表元資訊，給上層的SQL和分析引擎提供統一的資料訪問視圖。

Lakehouse資料入湖時，對線上RDS有壓力嗎？如何控制建倉的限流能力？

如果是即時入湖的話，資料來自DTS，使用的是Binlog，對線上RDS無壓力；

如果是建倉入湖的話會有一些壓力，通過參數來控制。

詳情請參見進階選項功能。

Lakehouse工作負載為什麼運行失敗，沒有Spark Log日誌可以看？

點擊查看workload“詳情”彈框，如果job status顯示：“specified driver resource spec:[xlarge]+executor resource spec:[xlarge] * executor instances:[2] exceed the max CPU:[16.0] or max Memory:[64.0], errorCode=InvalidParameter ” 類似資訊時，表示您在建立workload時，設定的Spark CU使用數超過了對應Virtual Cluster的Max使用限制。

解決方案有：

• 調整Virtual Cluster的Max CU限制。

• 調整workload使用的Spark CU個數, 確保任務使用的CU數小於Virtual Cluster的Max CU限制。

為什麼配置了中繼資料發現，並在“手動執行”之後，發現任務執行時間點之後的新的資料看不到了？

原因：“手動執行”在手動觸發執行完一次時，只能發現執行當時已存在的資料，不會發現手動執行後又新增的資料。

解決方案：您需要修改成“定時執行”模式，新增的資料才能被感知增加進來。

OSS資料來源配置數倉模式和自由模式的差異以及適用情境是什嗎？

為什麼Excel匯出的CSV檔案沒有被識別建表？

目前中繼資料發現支援的是CSV文字格式設定，因此需要確認Excel檔案匯出的是CSV文字檔。

為什麼一個目錄下面是同樣Schema的JSON檔案，但是沒有建表？

目前中繼資料發現只支援對只包含檔案的目錄進行識別，如果一個目錄下既有檔案又有目錄，會被過濾掉。

使用SLS中繼資料發現的批量模式，為什麼有的Logstore產生了表，有的沒有？

您需要確認沒有產生表的Logstore是否配置了投遞到OSS。

為什麼SLS中繼資料發現報錯：Make sure the bucket you specified be in the same region with DLA？

原因：SLS是運行投遞到跨region的OSS bucket上，而目前DLA 發現是不能跨region訪問的。所以在SLS發現任務運行時，可能會報如下錯誤“OSS object [oss://test-bucket/] is invalid. Make sure the bucket you specified be in the same region with DLA. Detailed message: The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.”

解決方案：在SLS投遞資料所在的OSS region上，使用“OSS中繼資料發現”來替代“SLS中繼資料發現”任務，進而實現自動建表時查詢SLS所投遞的資料。

OSS儲存CSV格式檔案時，為什麼OSS中繼資料發現不出任何錶？

這種情況一般原因有：

• 某個欄位值超過了4096位元組長度，導致採樣中斷。

• 相同目錄下多個檔案採樣推斷出不同的Schema，導致無法確定以這個目錄下的哪個Schema為準 。

• 檔案格式不是CSV格式。

OSS儲存CSV格式檔案時，為什麼OSS中繼資料發現的欄位類型不對？

這種情況一般原因有：

• 這個欄位存在空值，採樣推斷會向上設定為string類型 。

• CSV檔案資料某個欄位有不同的類型值。

• CSV的分隔字元格式不對，導致識別的都是string。

OSS中繼資料發現，是否支援CSV檔案第一行是說明，第二行是檔案頭，第三行才是資料？

不支援這種類型。

目前OSS中繼資料發現支援的CSV格式為：

1. 無檔案頭，只有資料行的情況。

2. 有第一行作為檔案頭的情況。

其他非標準CSV情況都不支援。

如何處理一鍵建倉串連資料庫報錯：Access denied for user？

原因：一般是由於修改了使用者名稱或密碼。

解決方案：請確認是否修改了串連資料庫的使用者名稱和密碼。如果修改了使用者名稱或者密碼，可以點擊Schema管理，找到您的一鍵建倉任務，點擊詳細資料>配置>更新，修改一鍵建倉任務的配置。

如何處理一鍵建倉串連資料庫報錯：because Could not create connection to database server. Attempted reconnect 3 times. Giving up？

原因：RDS源庫壓力過大。

解決方案：您可以採取如下措施。

• 調整一鍵建倉同步時間，與高負載的讀寫業務錯峰運行。

• 調整一鍵建倉的並發進階配置，降低並發數，如：connections-per-job=10、total-allowed-connections=30，表明一個表將由10個並發串連去讀，並且最大有30個串連，即最多3個表並發進行同步。您可以針對您的RDS執行個體規格進行適當調整，詳情請參見文檔進階選項功能。

如何處理一鍵建倉串連資料庫報錯：because Encountered too many errors talking to a worker node. The node may have crashed or be under too much load. This is probably a transient issue, so please retry your query in a few minutes？

原因：此時DLA公用版整體負載過高。

解決方案：您可以再次點擊“執行”來重試建倉任務。若還未成功，請聯絡 “DLA答疑”。

為什麼多庫合并、一鍵建倉報錯：No such instance with ID: rm-xxxxxx？

該報錯資訊表示當前建倉任務涉及的資料來源端RDS執行個體rm-xxxxxx已經釋放了。

如何處理一鍵建倉任務報錯：because Communications link failure？

詳細如報錯The last packet successfully received from the server was 900,120 milliseconds ago. The last packet sent successfully to the server was 900,120 milliseconds ago.), 23 out of 110 jobs are finished。

這種情況一般有如下兩種原因。

• 使用者資料庫有視圖。

• RDS源庫壓力過大，RDS/MySQL 重啟中斷或者無響應。

解決方案：排除視圖，降低並發數。

哪些區支援資料湖構建服務？

中國內地的地區都支援，中國內地以外的地區支援列表如下。

為什麼一鍵建倉任務成功了，有的表沒有同步過來？

您可以在任務運行狀態處查看跳過了多少張表，且在運行詳情的extraWarnTips資訊中查看跳過了哪些表。例如一鍵建倉會跳過表名、欄位名為中文的表。

如果您發現表名和欄位名都不是中文可以檢查所填寫的JDBC賬戶是否具有該表的存取權限。

如何處理一鍵建倉任務失敗，報錯：mppErrorCode=30101, because Direct buffer memory...？

原因：Presto公用叢集負載過高。

解決方案：您可以手動再次執行重試建倉任務，如果還失敗，請聯絡 “DLA答疑”。

如何處理一鍵建倉任務失敗，報錯關鍵字：because Failed to rename <OSS Path>？

原因：建倉時，所設定的OSS路徑位置是一個OSS歸檔型的Bucket，導致DLA無法正常重新命名這個目錄。

解決方案：您可以重建一個建倉任務，設定一個非歸檔類型的OSS bucket目錄位置。

如何處理一鍵建倉MongoDB失敗，報錯：Cannot allocate slice larger than XXXXX bytes？

詳細報錯如下。

because Error reading from mongodb: Cannot allocate slice larger than 2147483639 bytes。

原因：Presto拉取MongoDB資料時，有的欄位數值特別大。

解決方案：您可以修改建倉進階配置，通過sensitive-columns配置過濾掉大欄位的同步。詳情請參見文檔進階選項功能。

為什麼一鍵建倉運行了十幾個小時然後失敗了？

這種情況一般有如下兩種原因。

• 您的庫表中表的數量過多，有幾千個表，可能會導致同步逾時。

• 同步逾時的表沒有索引欄位或者整型UNIQUE KEY欄位，導致Presto計算Split任務運行逾時。

解決方案：您可以調整建倉進階配置，設定並發數為connections-per-job=1。詳情請參見文檔進階選項功能。