Airbnb定製Superset實現更好BI商業智慧

• 使用雲原生CloudNative架構Web 伺服器（Gunicorn、Nginx、Apache）
• 後設資料資料庫引擎（MySQL、PostgreSQL、MariaDB）
• 訊息佇列（Redis、 RabbitMQ、SQS）
• 結果後端（S3、Redis、Memcached等）
• 快取層（Memcached、Redis）

快取預熱作業
在 Airbnb 每天檢視的所有儀表板中，90% 的儀表板被多次檢視。再加上目前大多數新資料每天只透過我們的 ETL（提取、轉換、載入）作業登陸一次，這意味著每天快取儀表板圖表的結果可以顯著提高大多數使用者的效能。使用Apache Airflow  ，我們實施了一種有效的離線快取預熱策略，專注於預熱最近檢視的儀表板，從而使 Presto 支援的圖表的快取命中率達到 86%。由於 Superset 在 Redis * 中本機支援快取圖表請求，我們能夠在非工作時間以程式設計方式載入流行的儀表板，從而減少我們的查詢引擎 Presto 和Apache Druid的負載 ，在高峰時段。這將快取圖表載入時間從未快取時的 30 多秒縮短到 4 秒以下。
 

域分片
在 Superset 中載入儀表板時，會同時觸發儀表板上每個可見圖表的單個請求。儘管這在請求快速且儀表板很小的情況下有效，但由於儀表板包含許多圖表，我們很快就會遇到瀏覽器設定問題。大多數現代瀏覽器將向單個域（即 Superset API）發出的併發請求數限制為 6 個，從而導致大型儀表板速度變慢的瓶頸。為了處理這個問題，我們構建了SUPERSET_WEBSERVER_DOMAINS配置選項。透過設定此選項，管理員可以允許儘可能多的併發儀表板查詢，因為他們的資料庫引擎可以支援（可能需要有效的快取來確保引擎不會過載）。我們將四個不同的子域路由到我們的 Web 伺服器，在單個儀表板上支援多達 24 個併發查詢。此功能是允許使用者構建複雜儀表板和提高效能的關鍵。
 

資料庫引擎負載管理
雖然 Superset 允許進行很多本機最佳化，但一些效能和穩定性改進只能在資料庫引擎級別完成。由於複雜的業務需求和我們資料集的大小，許多儀表板觸發的查詢平均需要 25 秒才能執行。因此，我們採取了以下步驟來確保我們的資料庫引擎叢集不會過載：

• 根據重要性路由查詢：我們將查詢路由到不同的叢集（使用DB_CONNECTION_MUTATOR配置）以避免資源爭用；最佳化的儀表板查詢被髮送到一個叢集，而臨時 SQL 實驗室和探索查詢被髮送到另一個叢集。
• 限制每個使用者的併發：我們限制每個使用者在我們的資料庫引擎上同時執行三個查詢。雖然這可能看起來很小，但考慮到前面提到的快取預熱作業，它實際上已經足夠了。在理想情況下，實際上很少有查詢進入我們的資料庫引擎，並且快取有效地返回結果而不是重新執行查詢。
• 限制大型查詢：我們將可以執行的查詢大小限制為一定的記憶體大小或分割槽數。這鼓勵使用者建立合理複雜的有效查詢。