一直以來，BI平臺的數據如何保證及時有效地更新，是很多用戶關心的問題。通常情況下，對於T+1或其他定期性的數據分析，大多數BI平臺，包括觀遠數據，都會採用定時任務的方式來觸發數據更新。這邊以觀遠數據爲例，簡單進行說明。
場景一：
某電商ERP平臺需要從業務系統直接抽取數據至BI平臺。
由於電商ERP平臺白天業務交易繁忙，我們一般會採取凌晨一兩點定時 進行前一天增量數據的抽取。
場景二：
某便利店客戶自建了數倉，需要在每天數據處理完導入數倉後發起BI平臺的數據更新。
由於BI平臺的數據更新必須等數倉中數據更新完成了以後才能發起，所以必須要選擇一個比較合適的數據更新時間點。比如數倉數據更新完成時間是每天7點，那麼我們可以把BI平臺的數據更新時間選在每天7點10分。
數據倉庫（DataWarehouse），一般縮寫成DW、DWH。數據倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策。
——來自智庫百科
定時的數據更新存在弊端
有時候數倉的數據更新並不是每天都能準時完成的。比如，在品牌週年慶、雙十一等大型營銷活動舉辦的時候，數據量有可能會暴增，那麼原本每天7點就能完成的數據導入工作，可能就需要多延長半個小時甚至更長。
而BI平臺的數據更新如果還是在7點10分準時發起，那很有可能拿到的數據是不完整的。更有甚者，如果客戶的ETL系統出現了問題，導致數倉數據根本就沒有更新，或者數倉數據導入本身就需要人工完成的，完成時間上將存在很大不確定性。一旦這類情況發生，必須要用戶去手動點擊觸發各個數據集的數據更新，非常麻煩且容易遺漏。
全新數據更新方式——“URL外部觸發更新”
爲了解決這個問題，觀遠平臺首先提供了多時間點的自動數據更新（一天四次），儘可能保證用戶在數倉數據更新後，能儘快同步到BI平臺。
在此基礎上，觀遠平臺又開創性地提供了“URL外部觸發更新”的全新數據更新方式，可允許用戶調用指定接口，將BI平臺數據更新完美融合到企業自身的數據處理流程中去，進一步滿足用戶對於數據及時性的渴求。
我們知道，爲了保證用戶體驗和不給服務器、數倉造成太大的計算壓力，不管是抽取數據還是直連數據庫，BI系統基本都會有一定的緩存機制。緩存的存在，不但可以有效降低數據庫查詢的次數，減少服務器冗餘計算，也同時給終端用戶帶來快速的數據獲取體驗。
但由於BI系統總是主動地進行數據更新，而無法從外界獲知當前緩存是否該失效了，因此在數據的及時有效性方面總是存在缺憾。特別是在數據時效性較強的使用場景下，這常常是以往的數據更新方式一直被客戶詬病的地方。
如今有了觀遠數據這個外部觸發數據更新的功能，用戶就可以在數據集詳情頁“數據更新”一欄中，獲取一個用來更新當前數據集的一個URL，並把該URL的調用集成到現有的數據處理流程中去。
這樣一來，數據倉庫的數據導入流程就變成：在相關數據導入完成後，調用該URL、觸發BI平臺的更新。這樣做的好處是，當且僅當數倉數據完成了正常更新後，就能及時觸發BI平臺的數據更新，既保證了數據更新的及時性，也保證了數據的有效性。
調用Web端的數據更新 VS 調用URL的數據更新
有些高級玩家可能要問，我也可以通過調用Web端的數據更新接口來觸發數據集更新啊，這兩者有什麼區別？
當然有區別！如果通過Web端的數據更新接口來觸發數據集更新，勢必是需要先進行用戶登錄獲取有效token的，那麼如果把這整個流程都整合在數據處理流程裏面，一來步驟比較繁瑣，調用也比較麻煩，二來賬戶的安全性得不到保障（因爲賬戶可能會明文顯示在腳本里）。
而在URL觸發更新裏面，細心的用戶可以發現，URL裏面其實已經帶了一個token，而這個token僅對當前數據集更新操作有效，再加之這個URL只有數據集所有者和管理員才能獲取到，且可隨時關閉或重置，極大程度上保障了用戶的賬戶及數據安全。
觀遠數據URL觸發更新的內容我們就介紹到這裏，作爲一種更敏捷的數據觸發更新機制，它將爲企業構建更及時、更安全的數據自動化更新全流程，幫助企業快速獲取最新數據變化，爲運營決策提供前提支持。
同時，除了URL觸發更新之外，觀遠產品與傳統BI相比，另有許多創新之處。也正是憑藉這一系列的新一代BI產品特性，觀遠才越來越多地吸引到一批又一批的重量級客戶與觀遠一起踏上合作之路。未來，觀遠數據也將以持續深化用戶體驗爲己任，保持互聯網產品式的迭代速度，爲大家帶來更好的智能BI產品。
觀遠數據｜ 觀點精選