現(xiàn)如今，數(shù)據(jù)分析不再是僅面向內(nèi)部開發(fā)人員。當(dāng)為業(yè)務(wù)方構(gòu)建數(shù)據(jù)分析系統(tǒng)時，你需要確認(rèn)哪種數(shù)據(jù)庫后端是最合適的。

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

問題的關(guān)鍵點在于用戶體驗，以下是對外支持?jǐn)?shù)據(jù)分析工作的一些關(guān)鍵技術(shù)討論點（以 Apache Druid 為例）。

低延遲特性

一直在隊列中等待查詢會讓人很惱火。與延遲有關(guān)的因素包括數(shù)據(jù)量、數(shù)據(jù)庫的處理能力、用戶和 API 調(diào)用的數(shù)量，以及數(shù)據(jù)庫支持查詢應(yīng)用的能力。

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

一個“不妥協(xié)”的解決方案是選擇專為大規(guī)模交互而構(gòu)建的優(yōu)化架構(gòu)和數(shù)據(jù)格式，??Apache Druid?? 正是這樣一個旨在支持現(xiàn)代分析程序的實時數(shù)據(jù)庫。

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

高可用性

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

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

考慮彈性就需要考慮設(shè)計標(biāo)準(zhǔn)。節(jié)點或集群范圍的故障能完全避免嗎？丟失數(shù)據(jù)的后果有多嚴(yán)重？保障應(yīng)用程序和數(shù)據(jù)需要涉及哪些工作？

關(guān)于服務(wù)器故障，保證彈性的常規(guī)方法是多節(jié)點服務(wù)以及 ??備份機制??。但如果你是為客戶構(gòu)建應(yīng)用程序，則對數(shù)據(jù)丟失的敏感性要高得多。偶爾的備份并不能完全解決這一問題。

Apache Druid 的核心架構(gòu)內(nèi)置了該問題的解決方案，本質(zhì)是一種強大而簡單的彈性方法，旨在保證承受任何變故都不會丟失數(shù)據(jù)（即使是剛剛發(fā)生的事件）。

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

多用戶

一個好的應(yīng)用應(yīng)該同時兼?zhèn)浯笥脩袅亢汀耙巳雱佟钡捏w驗，因此為高并發(fā)構(gòu)建后端非常重要。你肯定不想看到因為應(yīng)用掛掉而讓客戶沮喪。內(nèi)部報告的架構(gòu)不必考慮這點，因為并發(fā)用戶數(shù)量要小得多且有限。所以現(xiàn)實是，用于內(nèi)部報告的數(shù)據(jù)庫可能并不適合高并發(fā)應(yīng)用程序。

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

更好的方法還是使用像 Apache Druid 這樣的數(shù)據(jù)庫，它具有優(yōu)化的存儲和查詢引擎，可以降低 CPU 使用率。我們強調(diào)的關(guān)鍵詞是“優(yōu)化”。數(shù)據(jù)庫不應(yīng)該讀取它不需要的數(shù)據(jù)。Apache Druid 可以讓基礎(chǔ)設(shè)施在同一時間跨度內(nèi)為更多查詢操作提供服務(wù)。

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

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

著眼當(dāng)下，預(yù)見未來

分析應(yīng)用程序?qū)τ谟脩舳灾陵P(guān)重要，所以要構(gòu)建正確的數(shù)據(jù)架構(gòu)。

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