現如今，數據分析不再是僅面向內部開發人員。當為業務方構建數據分析系統時，你需要確認哪種數據庫后端是最合適的。

程序員的本能可能是“選用自己了解的數據庫（例如 PostgreSQL 或 MySQL）”。數據倉庫也可能會擴展核心的 BI 儀表板和報告之外的功能，不過對業務方的數據分析支持仍是其重要功能之一，因此要選擇合適的工具來保證此功能的性能。

問題的關鍵點在于用戶體驗，以下是對外支持數據分析工作的一些關鍵技術討論點（以 Apache Druid 為例）。

低延遲特性

一直在隊列中等待查詢會讓人很惱火。與延遲有關的因素包括數據量、數據庫的處理能力、用戶和 API 調用的數量，以及數據庫支持查詢應用的能力。

當數據量比較大時，有一些方法可以基于任意在線分析處理（OLAP）數據庫構建交互式數據體驗，但或多或少都有一些其他方面的犧牲。預計算查詢會對性能要求較高，還會使架構變得僵化。預聚合處理會使數據粒度變大。將數據時間限制在近期的處理方式，會使得數據完整性得不到保證。

一個“不妥協”的解決方案是選擇專為大規模交互而構建的優化架構和數據格式，??Apache Druid?? 正是這樣一個旨在支持現代分析程序的實時數據庫。

• 首先，Druid 具備特有的分布式彈性架構，可將數據從共享數據層預取到近乎無限容量的數據服務器集群中。這種架構與諸如云數據倉庫這樣的解耦查詢引擎相比，具有更快的性能，因為它不需要移動數據，并且比像 PostgreSQL 和 MySQL 這樣的縱向擴展數據庫具有更高的可擴展性。
• 其次，Druid 采用內置于數據格式中的自動多級索引來驅動每個內核去支持更多查詢操作。在常規 OLAP 列格式基礎之上，還增加了全局索引、數據字典和位圖索引，這可以最大化利用 CPU 周期，加快處理速度。

高可用性

如果開發團隊為內部報告搭建了一個后端，那么中斷幾分鐘甚至更長時間真的很嚴重嗎？實際上并不是的。所以在典型 OLAP 數據庫和數據倉庫中，計劃外的停機和維護是可以允許的。

但是如果你們團隊構建了一個對外的供客戶使用的分析應用程序，如果發生數據中斷，會嚴重影響客戶滿意度、收入，當然還有你的周末休息時間。這就是為什么彈性（高可用性和數據持久性）需要成為對外分析應用程序數據庫中的首要考慮因素。

考慮彈性就需要考慮設計標準。節點或集群范圍的故障能完全避免嗎？丟失數據的后果有多嚴重？保障應用程序和數據需要涉及哪些工作？

關于服務器故障，保證彈性的常規方法是多節點服務以及 ??備份機制??。但如果你是為客戶構建應用程序，則對數據丟失的敏感性要高得多。偶爾的備份并不能完全解決這一問題。

Apache Druid 的核心架構內置了該問題的解決方案，本質是一種強大而簡單的彈性方法，旨在保證承受任何變故都不會丟失數據（即使是剛剛發生的事件）。

Druid 基于對象存儲中共享數據的自動、多級復制實現高可用性（HA）和持久性。它實現了用戶期望的 HA 特性以及持續備份機制，即使整個集群出現問題，也可以自動保護和恢復數據庫的最新狀態。

多用戶

一個好的應用應該同時兼備大用戶量和“引人入勝”的體驗，因此為高并發構建后端非常重要。你肯定不想看到因為應用掛掉而讓客戶沮喪。內部報告的架構不必考慮這點，因為并發用戶數量要小得多且有限。所以現實是，用于內部報告的數據庫可能并不適合高并發應用程序。

為高并發構建數據庫主要在于取得 CPU 使用率、可伸縮性和成本之間的平衡點。解決并發問題的通常做法是投入更多硬件成本。邏輯上說，只要增加 CPU 的數量，就能夠同時進行更多的查詢操作。雖然事實確實如此，但成本的增加是不可忽視的。

更好的方法還是使用像 Apache Druid 這樣的數據庫，它具有優化的存儲和查詢引擎，可以降低 CPU 使用率。我們強調的關鍵詞是“優化”。數據庫不應該讀取它不需要的數據。Apache Druid 可以讓基礎設施在同一時間跨度內為更多查詢操作提供服務。

節省成本是開發人員使用 Apache Druid 構建外部分析應用程序的一個重要原因。Apache Druid 具有高度優化的數據格式，結合了從搜索引擎世界借鑒來的多級索引以及數據縮減算法，可以最大限度地減少所需的處理量。

最終表現就是 Apache Druid 提供了其他數據庫不可比擬的處理效率。它可以支持每秒數十到數千跨度的 TB 甚至 PB 級別的查詢。

著眼當下，預見未來

分析應用程序對于用戶而言至關重要，所以要構建正確的數據架構。

你肯定不想一開始就選擇了一個錯誤的數據庫，然后在后續擴展時面對諸多令人頭疼的問題。幸運的是，Apache Druid 可以從小規模開始，并在之后輕松擴展以支持任何可以想象的應用程序。Apache Druid 有 ??優秀的官方文檔??，當然它是開源的，所以不妨嘗試一下并，快速上手吧。