BigQuery 上市檢查清單

簡介

這份「BigQuery 上市檢查清單」建議在推出使用 Google BigQuery 的商業應用程式時應完成的動作。此檢查清單建議的動作適用於 BigQuery。此外,建議您同時使用一般檢查清單 (Google Cloud Platform 上市檢查清單),瞭解應該完成且適用於所有服務的動作。

這份「BigQuery 上市檢查清單」適用於熟悉 BigQuery 的開發人員。假如您剛開始使用 BigQuery,這些指示並不會教您如何操作 BigQuery。

此檢查清單分成以下部分:

  • 結構設計原理與開發
  • 非正式推出
  • 最終推出

建議您按照上述順序查看相關內容,以便您在推出應用程式的每個階段做好相關準備。舉例來說,建議您先從「結構設計原理與開發檢查清單」開始;清單中包含我們建議您在應用程式開發週期早期完成的動作。同樣地,「非正式推出檢查清單」包含我們建議在即將正式推出時完成的活動。不過,檢查清單活動的確切時間表以及所需時間取決於您應用程式的開發時程。

結構設計原理與開發檢查清單

建議您在應用程式開發的早期階段使用此清單。您可以組成多個群組同時執行檢查清單動作;不過,建議您儘快開始軟體架構相關動作,因為這些動作需要較多時間才能完成。

動作
社群/群組/論壇
❑  
前往 Stack Overflow 尋求 BigQuery 社群支援,這是資訊與可行建議的絕佳來源。
❑  
訂閱 BigQuery - 通知群組。
結構定義設計
❑  
根據查詢需求設計結構定義。BigQuery 支援巢狀與重複 (type:RECORD) 的欄位,允許非標準化資料表含有一對多的邏輯關係。在適當的情況下充分利用這些資源,同時維持存取此類欄位的策略。考慮針對解除巢狀的重複欄位建立邏輯視圖。預估查詢成本。
❑  
重複欄位會提高查詢第一級和第二級以外巢狀層級的難度,因此請考慮適合您使用的巢狀深度。
❑  
雖然聯結在 BigQuery 代表效能高,但去標準化可提升部分查詢的效能。考量「聯結」位於資料模型的何處也很重要。
❑  
BigQuery 允許透過 DML 附加或更新資料表。DML 適用於大量更新、刪除和插入作業,而不是單一資料列修改作業。請確認您的更新模式與 OLAP 系統一致。
❑  
與傳統的 RDBMS 不同,沒有主要/次要或資料列 ID 金鑰的概念。如有需要,可為該目的指定資料表結構定義中的資料欄。
預估資料量
❑  
計算在首次上傳作業中要上傳多少資料,才能達到某個基礎級別。
❑  
計算要以漸進方式上傳多少資料以及上傳速率 (每小時/每天/每週)。
❑  
計算有多少資料 (如果有的話) 到期以及其頻率。
預估查詢處理
❑  
找出每天將對 BigQuery 資料集執行的查詢類型。Stackdriver Monitoring 提供有關資源使用率、並行查詢數及資料集大小的有用診斷資訊。
❑  
決定資料表分區/分割策略。舉例來說,假如某天發佈的查詢與當天收集的資料相關,則每天建立一份資料表。如要跨多日匯總資料,請使用資料表萬用字元或 \_PARTITIONTIME 虛擬資料欄執行查詢。
❑  
計算 BigQuery 每天處理多少資料 (查詢數量 x 每個查詢處理的資料量)。請注意,BigQuery 會針對您處理的個別資料欄 (而不是整個資料列) 收取費用,因此請在您的計算中說明。另請注意,查詢所參照的資料欄會叫用完整的資料欄掃描。
配額管理
❑  
瞭解 BigQuery 的預設配額
❑  
在適用情況下完成以下區域的配額分析:
  • 將資料載入 BigQuery 的每天所需的載入工作數。
  • BigQuery 每天每份資料表所需的載入工作數。
  • 串流資料插入數量、插入的資料列大小、每秒資料列上限、每次要求資料列上限,以及其他串流 API 專屬參數 (如果您使用串流 API 的話)。
  • 您的應用程式核發給 BigQuery 的查詢數。
  • 用於同時執行查詢的並行工作階段數量。
  • 每天為從 BigQuery 擷取資料而執行的匯出工作數。
  • 即使是叫用 BigQuery 作業的 API 也有使用頻率和每日限制。詳情請參閱 API 使用頻率限制相關說明。
❑  
如果配額不足,請透過 Google for Work 支援中心提出配額調整要求。
費用分析
❑  
根據預估的資料量和查詢處理,運用 BigQuery 定價資訊和/或使用 Pricing Calculator,計算 BigQuery 儲存空間和處理的費用。
❑  
考量下列費用最佳化建議做法:
  • 只選取查詢中相關的資料欄。請注意,不論 WHERE 子句的篩選器為何,BigQuery 都會對選取的資料欄執行完整的資料欄掃描 (並收取相關費用)。
  • 將資料表分區/分割成較小的單位以最佳化處理費用。費用與效能只能擇一最佳化。假如您的小型資料表過多,則在載入查詢所參照的每份資料表時會產生固定負擔,而這可能會影響效能。
  • 針對較小的資料表分區測試查詢,而非單一的大型資料表。
  • 驗證查詢語法並使用 dryRun 標記取得處理統計資料 (如果您使用 API 的話)。
  • 刪除不再需要查詢的舊資料表,或是使用資料表的 expirationTime 屬性。
安全性
❑  
詳閱 BigQuery 適用的身分與存取權管理政策,確認資料集存取權和工作執行權限正確無誤。 需要考量的重點:
  • 稽核專案成員的 BigQuery 權限,確保一切皆依循安全性政策。bigquery.User 角色可讓使用者在您的專案中執行工作,而 dataset.Viewer 可控管讀取指定資料集中所有資料表的權限。dataset.Editordataset.Owner 分別只在使用者需要修改資料表或資料集時才能授予。
  • 如果需要將特定資料集與小組成員共用,請改為使用共用資料集或確切的身分與存取權管理角色。
  • 如果您需要更精細的安全性功能,請考慮使用 Authorized Views 來管理存取權。
在 BigQuery 之前預先處理資料
❑  
請考慮在將資料載入 BigQuery 前預先處理資料,以最佳化費用與效能。舉例來說,您可以:
  • 預先處理不必要的類型轉換和計算。
  • 預先加入常見聯結。
  • 預先匯總指標和經常執行的分析。
❑  
使用 BigQuery 本身、Cloud DataflowCloud Dataproc 或 ETL 工具預先處理 (轉換、去標準化等) 資料。
❑  
考慮對相同資料集提供多種版本,以針對不同類型的查詢提供不同架構。
❑  
由於每份資料表的 DML 陳述式設有每日限制,因此請規劃透過階段式的批次修改來更新/刪除資料表。
調整及測試查詢
❑  
請根據以下原則,針對預期資料量測試查詢並進行調整:
  • 從 SELECT 子句中省略不必要的資料欄以降低費用並提高效能。
  • 在巢狀查詢的內容中,運用 WHERE 子句篩選最內層查詢中的資料,以減少外層查詢處理的資料量。
  • 如果可以的話,盡量向內整併,並搭配 WHERE 子句使用。
  • 將 regexp 等重量級篩選器移到最後面。
  • 避免將字串進行分組;如果原本對等的資料可供使用,請使用時間戳記與字串。
  • 試著在最外側查詢使用 ORDER BYLIMIT。在內部查詢中盡量避免使用 ORDER BY
  • 請注意,在處理偏移的 (大型) 群組時,使用 GROUP BY 可能會造成長尾延遲效應。請排除這些項目來改善查詢效能。
  • 考慮使用 IF/CASE 或分析 SQL 函式,而不是自我聯結,這是因為自我聯結相對需要較高的處理費用。
資料視覺化
❑  
BigQuery 是適用於查詢大型資料集資料的工具。就資料視覺化而言,BigQuery 與第三方工具擁有強大的連結:
  • Google Data Studio
  • 辦公室生產力工具,例如 Google 試算表和 Microsoft Excel
  • Tableau、BIME、Informatica 等商用工具
  • 開放原始碼替代方案,例如 redash

非正式推出檢查清單

在您的應用程式正式上市前,建議您完成「非正式推出檢查清單」中的活動,測試應用程式是否已準備就緒。

活動
❑  
假如您使用串流 API 載入資料,請模擬負載測試,確保資料可在不超出配額的情況下載入。
❑  
假如您使用批次工作載入資料,請模擬負載測試,確保資料可在不超出配額的情況下且合理的時間內載入至 BigQuery。
❑  
根據實際費用審視您的費用模型,確認營運成本都在預算範圍內,並視需要修改您的費用模型。雖然 Google Cloud Platform Pricing Calculator 能夠提供合理的估算,但必須等到負載測試後,才能明確得知一天到底會處理多少資料。

最終推出檢查清單

請在即將推出和正式推出應用程式時,使用「最終推出檢查清單」

活動
❑  
假如您已按照我們建議的順序完成所有檢查清單,您就可以讓應用程式 Google BigQuery 上推出,恭喜!同時建議您查看 Google Cloud Platform 上市檢查清單中的「最終推出檢查清單」
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁