1. 程式人生 > >資料分析用它就夠了 | 37 個場景你要用集算器

資料分析用它就夠了 | 37 個場景你要用集算器

【報表查詢效能】

1. 資料量大或併發多導致的查詢效能低下,BI 介面拖拽響應很慢

  • 通過集算器編寫更為簡單高效的演算法加速計算程序,提升查詢效能
  • 採用集算器可控儲存和索引機制,為 BI(CUBE)提供高速的資料儲存

2.T+0 實時全量查詢報表涉及資料量大,影響生產系統執行,而分庫後又難以實施跨庫混合運算

  • 將冷熱資料分離,僅將當期熱資料存放在資料庫中,冷資料儲存在檔案系統或資料庫中,通過集算器完成跨源(庫)計算,完成多源資料彙總、複雜計算,實現 T+0 全量資料實時查詢
  • 集算器提供不同資料庫的基本 SQL 翻譯功能,資料分庫(同構異構均可)後,仍然可以使用通用 SQL 進行跨庫查詢

survey2png

3. 資料關聯運算太多,十幾甚至幾十個表 JOIN,效能惡劣

  • 集算器重新定義關聯運算,可以根據計算特徵選用不同且高效的關聯演算法提升多表關聯效能
  • 一對多的主外來鍵表可採用指標式連線提高效能
  • 一對一的同維表和多對一的主子表可採用有序歸併提升效能

4. 資料來源 SQL 複雜,巢狀層次多,資料庫優化路徑不可控,運算效能低

  • 集算器採用過程計算,分步實施計算簡化實現程式碼,無需巢狀
  • 過程中可以複用中間結果,效能更高

5. 報表從資料庫中取數量大,JDBC 傳輸效能低

  • 集算器通過(多執行緒)平行計算與資料庫建立多個連線並行取數提升取數效能
  • 可將量大的冷資料事先儲存在庫外檔案系統中,集算器基於檔案直接查詢計算,避免通過 JDBC 取數

survey3png

6. 清單式大報表難以及時呈現,採用資料庫分頁方式翻頁效率很差

  • 集算器將計算和呈現做成兩個非同步執行緒,取數執行緒發出 SQL 將資料快取到本地交給呈現執行緒快速展現報表,此外取數執行緒只涉及一個事務不會出現資料不一致,保證資料準確性

【報表查詢開發】

7. 報表開發沒完沒了,佔用程式設計師的過多工作量,找不到低成本高效率的應對手段

  • 集算器幫助報表開發徹底工具化,不僅報表呈現層工具化,報表資料計算層也工具化,從而降低報表開發難度,報表實現更快更簡單
  • 對人員要求更低,無需專業程式設計師
  • 報表業務不穩定導致報表沒完沒了不可能消滅,集算器提供了最低成本的應對

8. 業務人員取數需求多,敏捷 BI 並不管用,技術部門應對這些需求費時費力

  • 集算器作為完備計算引擎,支援過程計算開發快捷
  • 演算法實現簡單,適合一般技術人員使用
  • 提供視覺化程式設計環境,即裝即用使用簡單
  • 通過多源支援,基於 Excel/TxT/DB 直接計算無需入庫

9. 資料來源 SQL 或儲存過程過於複雜,巢狀或步驟多,除錯開發都很困難

  • 集算器通過過程計算,分步程式設計簡化演算法開發難度,演算法短小、分步同時降低了維護難度,極大改善上千行 SQL 編寫除錯和維護困難的情況

10.SQL(儲存過程)語法涉及資料庫方言,難以移植

  • 集算器作為庫外通用計算引擎,可以編寫不依賴資料庫的通用演算法,資料庫發生變化時無需更改核心演算法,易於移植

11. 複雜過程運算用 SQL 很難寫,需要大量外部 Java 計算,開發效率低

  • 集算器提供了完備的結構化資料計算能力,解決了 JAVA 集合運算困難的問題,無需再用 JAVA 編寫
  • 集算器還很方便整合到現有應用中,與應用完美結合

12.Java 和 SQL 編寫的資料來源與報表模板分開儲存,程式耦合性太強,還難以做到熱切換

  • 集算器可作為報表獨立的計算層,資料準備演算法和報表模板一起儲存,共同管理,可與應用分開部署,降低應用的耦合度
  • 解釋執行的集算器指令碼可實現熱切換

13. 涉及 MySQL 等開源資料庫,視窗函式等許多高階語法不支援,開發困難

  • 集算器作為完備計算引擎,提供了豐富的結構化資料運算函式,改善 MySQL 無法使用視窗函式導致的編碼困難

14. 某些資料庫(如 Vertica)對儲存過程支援不好,難以實現複雜過程

  • 集算器作為完備結構化資料計算引擎,可以充當通用庫外儲存過程,提供不依賴於資料庫的強計算能力和易移植特性

15. 涉及 NoSQL 資料、文字、Excel 等,無法使用 SQL 運算

  • 集算器提供直接針對檔案使用 SQL 查詢的功能
  • 還可以編寫指令碼讀取 NoSQL、文字、Excel 資料,實施計算,實現複雜度與 SQL 相當或更低

16. 涉及 Web 或 IOT 等實時資料,有 json/xml 格式需要處理,事先匯入資料庫不僅效率低又影響實時性

  • 集算器提供了對 JSON/XML 這類分層資料的支援,基於這類資料計算不僅編碼簡單,而且效能高實時性好

【ETL 開發與效能】

17.ETL 工具不能直接解決複雜業務邏輯,還要大量編寫指令碼,而 ETL 工具的指令碼功能常常弱於 SQL,開發困難

  • 集算器具備強計算能力,非常擅長複雜計算,可以輔助或替代現有 ETL 工具實現複雜業務邏輯,實現複雜度遠遠低於硬編碼 ETL 計算指令碼

18.SQL(儲存過程)缺乏除錯機制,開發效率低

  • 集算器支援過程計算,提供視覺化程式設計環境,每步的計算結果所見即所得,還提供設定斷點、單步執行、執行到游標等編輯除錯功能,開發效率極高

19. 儲存過程步驟多,程式碼長,幾百甚至上千行,大量使用臨時表,效能低下而且難以維護

  • 相對儲存過程需要反覆讀寫磁碟使用中間結果,集算器提供豐富的運算,大量減少中間結果落地,效能更高
  • 集算器採用過程計算,提供豐富函式類庫,實現演算法短小精悍易於維護
  • 集算器指令碼可以脫離資料庫編寫和執行,減少資料庫安全隱患

20. 涉及 NoSQL、文字、Excel 等資料庫外資料,無法使用 SQL,只能硬編碼,開發效率太低且難以維護

  • 集算器提供通過 SQL 針對檔案的查詢功能
  • 還可以針對 NoSQL、文字和 Excel 直接進行多源混合計算,編碼效率遠高於硬編碼

21. 涉及多資料庫和非資料庫的整合,SQL 無法跨資料來源計算,需要事先彙總到單庫,ETL 做成 ELT 和 LET,資料庫臃腫且效能差

  • 集算器作為完備計算引擎可以實現真正的 ETL,基於多源混合計算能力先將多源資料進行清洗(E)傳輸(T),將整理好資料載入(L)到目標資料庫,避免彙總到單庫帶來的時間、空間和管理上的過多開銷

22. 複雜運算要用庫外的 Java 開發或編寫 UDF 才能完成,人工成本高昂

  • 集算器採用過程計算,分步編寫程式碼,提供豐富的類庫和方法,開發簡單易維護,大大降低編碼難度,提升實施效率

【資料倉庫與部署】

23. 生產庫和分析庫在一起,大資料運算可能影響生產系統執行,分庫又難以做到實時全量計算

  • 集算器可基於生產庫和分析庫進行混合計算,量小的實時熱資料從生產庫查,將對生產系統的影響降到最低,量大的歷史冷資料從分析庫查,兩部分資料混合計算實現全量資料實時計算

24. 資料量變大,資料倉庫效能變低,總要擴容,成本高昂

  • 集算器允許將量大且不再變化的歷史資料從資料庫匯出到檔案系統儲存,藉助集算器完備的資料計算能力,直接基於檔案系統計算,同時支援與資料庫混合計算,從而降低資料庫擴容壓力,實施成本低

25. 中央資料倉庫支撐了過多應用,併發過多導致效能不可控,前端使用者體驗差

  • 集算器易於應用整合,可將資料倉庫中的部分計算和資料移植到應用層藉助集算器計算能力實施資料儲存和計算,分擔資料倉庫壓力

26. 資料倉庫中有大量非原始資料的中間表,冗餘嚴重,而且年代久遠非常難管理

  • 集算器支援將資料庫的中間表移植到 I/O 效能更高的檔案系統,降低資料庫冗餘,集算器直接基於檔案計算,效能更高,還方便實施平行計算,進一步提升效率
  • 中間表在庫外採用檔案系統的樹狀結構進行分類管理,優於資料庫的線性結構,管理方便

27. 很多業務應用中都要部署單獨的資料集市或前置資料庫,成本高昂

  • 集算器的強計算能力 + 資料快取 + 資料閘道器 + 多源混算可以替代單獨資料集市或前置資料庫,成本低廉

【Hadoop 大資料平臺】

28.Hadoop 叢集規模不大,只有幾個或十幾個節點,管理的資料並不多,難以發揮其優勢,但維護卻很複雜

  • 集算器作為輕量級大資料解決非常適合幾個到幾十個節點的叢集規模,相對 hadoop 集算器資源利用率更高,節約資源,同樣的計算指標需要硬體更少,同樣的硬體計算效率更高

29.Hadoop 難以完成需要的計算,結果又在旁邊部署傳統資料庫來實施計算,結構累贅且效率低

  • 集算器可將 hadoop 作為資料來源,實現 hadoop 難以完成的計算
  • 同時支援實時查詢,避免部署 RDB 帶來的 ETL 時間成本高,資料實時性差,商用 RDB 價格成本高等問題

30.Hadoop/Spark 提供的計算介面不夠用,複雜運算還要寫 UDF,開發效率低

  • 集算器計算引擎具備複雜計算實現簡單、效率高的特點,適合使用 hadoop 或 spark 卻還經常需要編寫 UDF 的場景,極大提升開發效率

31.Hadoop/Spark 儲存和排程過於自動化,難以控制資料分佈和任務安排以獲得最優效能

  • 集算器提供靈活的資料分佈和計算分佈,可以根據資料特徵、計算特徵和硬體特徵實施個性化大資料計算從而獲得最高效能,解決了 hadoop/spark 過於透明導致無法實施高效能運算的難題

32.Spark 記憶體耗用太大,硬體成本太高,很多運算超過記憶體範圍還無法實施

  • 集算器提供記憶體和外存兩種計算方式,由於採用高效計算模型,記憶體計算時效率更高、記憶體利用率更低,從而降低成本
  • 當記憶體容量不夠或無需全記憶體計算時,集算器採用外存計算從而減輕對記憶體容量的依賴,硬體成本更低

33. 試圖用 HBase 解決大資料查詢問題,但效果很差

  • 集算器藉助高效能運算和高效能資料儲存特徵,優化所以體系,很好解決了 Hbase 等 KV 資料庫批量查詢效率低下的難題

【Python 等桌面資料開發】

34.Python 並非專門為結構化資料計算設計,開源包貢獻者不同,風格不統一,複雜過程編寫並不簡單

  • 集算器專為結構化資料計算設計,支援過程化計算,提供了豐富的結構化資料集算函式,提供即裝即用的視覺化編輯除錯環境,非常適合進行桌面資料分析,隨裝隨用,隨用隨走

35. 涉及 Excel/json 等非庫資料,Python 等開源技術雖然介面豐富,但版本混亂,難以駕馭

  • 集算器具備完備的資料計算能力,作為商業軟體,提供了豐富的介面處理 Excel/JSON 等非庫資料,即裝即用,避免了 Python 等開源技術版本混亂、使用困難

36.Python 缺乏自有大資料,幾乎不能寫並行程式,無法充分利用多 CPU 能力

  • 集算器提供了多執行緒平行計算和分散式計算能力,通過簡單的指令碼即可實現平行計算,可充分利用多 CPU 核能力實施高效能運算

37.Python 程式碼難以和 Java 整合,演算法需要嵌入到生產系統時常常還要重寫

  • 集算器可作為計算中介軟體無縫嵌入應用系統,桌面資料分析編寫的指令碼可直接移植到生產系統中,無需重寫