Salesforce大數據平臺產品管理產品經理Ram Sangireddy和Kartik Chandrayana撰寫，來自Salesforce同事的貢獻：Andrew Torson，William Earl，Vincent Poon和Lars Hofhansl
幾十年前，與數據和支持技術相關的業務需求已遠遠超出了世界。 那時是小數據時代，數據可以存儲在單個商店中，而基於設備的數據倉庫（DW）解決方案可以滿足大多數業務需求。 隨著大型組織中數據量迅速增長到PB規模，基於設備的DW解決方案的侷限性（例如，數據整合，存儲和計算的耦合，維護成本，數據敏捷性不足等）很快就開始出現並開始出現。 扼殺了交互式分析解決方案的有效性。
因此，行業開始建立新的模型，其中包括存儲和計算的分離-通過根據工作負載對計算和存儲進行有效的獨立擴展，以實現對大數據的更有效的臨時交互式分析。 隨著分析涉及查詢越來越多的多維大數據，以列格式存儲數據也變得越來越普遍。
這些趨勢為類似數據倉庫的功能帶來了技術創新，而沒有基於設備的傳統數據倉庫解決方案的限制，從而可以實現更廣泛的用例-例如，查詢日益分散的數據源，臨時交互分析而不是預先創建的報告和儀表板，以及對非聚合數據的處理需求，以獲取更精細，更細化的見解。 這些用例需要更多具有低成本臨時查詢處理的大規模並行處理（MPP）技術。
在Salesforce中，大規模數據被廣泛分發。 事務性存儲中有數十PB的數據，數據中心每月累積的日誌數據超過5PB，到目前為止，Hadoop存儲中累積了近200PB，每分鐘將近2億個指標存儲到時間序列數據庫中， 其他屬性中的數據。 此外，許多數據也是按地理分佈的。 在這樣的規模和複雜性下，Salesforce在B2B企業中是無與倫比的，可以與最大的B2C規模的公司媲美。 我們需要支持對這些數據集進行批處理，流處理和交互式即席查詢處理； 雖然Apache Spark是我們在各種大數據計算用例中的首選解決方案，但我們仍需要找到一種適用於臨時交互式查詢處理的合適解決方案。
考慮到上述所有因素，MPP計算引擎將非常適合其在高度分佈式的數據源上進行臨時的，交互式的，人工的時間分析的能力，同時也與託管基質無關。 該引擎應支持SQL中的分析查詢（這是分析人員進行數據探索的主要來源），還應支持新興用戶（如打算直接在大數據上發現見解的公民數據科學家）。
簡而言之，我們的評估旨在通過即席查詢找到適合我們圍繞交互式分析的需求的技術，其中包括以下幾個關鍵標準：
· 對peta字節規模數據的臨時查詢的人員時間響應延遲
· 對標準SQL查詢的成熟支持，能夠連接不同的數據集
· 連接到各種數據源，輕鬆添加新的連接器
· 計算引擎，具有查詢的分佈式處理，可獨立於存儲進行擴展
· 具有活躍社區的開源軟件
我們根據上述標準評估了多種技術，並希望與我們分享最終發現的解決方案以及我們發現的解決方案。
· Drill：Apache Drill是一個高度可擴展的開源應用程序框架，其中包括一個SQL查詢引擎。 它可以從各種主要的非關係數據存儲區（例如NoSQL數據庫）中獲取數據。 它基於用於數據的無模式JSON文檔模型，因此它比基於基於模式的列式數據格式的引擎更靈活，但速度較慢。
· Impala：Apache Impala是用於大數據的高度可擴展的開源分佈式SQL查詢引擎，主要面向Hadoop集群上的數據。 它權衡了容錯性以提高速度，將中間結果保留在內存中以提高性能，並且從某些指標來看，它是最快的交互式查詢引擎。 它使用256 MB的文件針對Parquet列式數據格式進行了優化。 對於相同數量的數據，它在處理大量小文件時可能效果不佳。
· SparkSQL：Apache SparkSQL是用於大數據的高度可擴展的開源分佈式SQL查詢引擎，具有許多數據存儲的連接器。 它可以為基於模式的列式數據格式提供非常高的吞吐量。 對於非常大的查詢（在許多處理器上運行數小時至數天），這是一個不錯的選擇，因為它可以將臨時結果捕獲到臨時文件中，並且可以以較少的時間開銷重新啟動失敗的零件。 另一方面，非常小的查詢的最短時間相對較長； 同樣，如果查詢計劃無法將中間結果保存在內存中，則保存中間結果的成本會增加中小型查詢的資源使用和服務時間。
· Presto：Presto是具有成熟SQL支持的大數據開源開源查詢引擎。 Presto繞過MapReduce並在內存中使用特定於SQL的分佈式操作。 該體系結構的設計使所有階段都流水線化，因此沒有等待時間，不需要在中間寫入磁盤，也不需要將所有數據放入內存，也沒有磁盤IO延遲。 Presto將某些操作委託給其查詢的基礎數據存儲，從而利用其固有的分析功能。 此外，Presto可以執行跨平臺聯接，從而為跨不同數據源查詢歷史數據提供集中支持。 Presto具有高級SQL支持，其功能包括動態過濾，動態解析函數，SQL定義的函數（CREATE FUNCTION）。 像Impala一樣，Presto犧牲了速度的容錯能力。
· Druid：Druid在相關技術中是獨一無二的：它既是OLAP數據庫（可以與Vertica，RedShift和Snowflake進行比較），又是分佈式查詢處理器，時間序列數據庫，具有流處理功能以及具有支持透視圖的UI可視化 。 Druid利用數字和時間序列數據提供了最佳功能，並且其連續攝取實時業務事件流的能力使其更適合實時查詢。 需要查詢大量歷史數據的長時間運行的BI查詢將必須進行冷存儲上傳，並且處理時間更長。
· Kylin：Apache Kylin構建為在HBase中管理OLAP多維數據集以支持快速SQL查詢。 OLAP多維數據集需要存儲許多二級索引（每個維度一個），然後使用快速隨機訪問來檢索記錄。 數據倉庫文件面向全表掃描（"對於乾草堆中的每個項目，如果看起來像針一樣，請添加到結果集中"）。 Kylin最適合較小的基數數據，並且對於非常大的數據集而言可能是成本更高的選擇。
總而言之，考慮到Salesforce上用於跨不同數據源的peta字節規模數據的人機交互的即席分析的用例，具有連接這些數據集的能力和成熟的SQL支持，我們確定Presto是我們需要的解決方案。 現在，Presto已成為我們大數據計算平臺不可或缺的一部分，該平臺需要支持數據分析師，數據科學家和開發人員。 藉助Presto，數據分析人員和開發人員可以同時從雲或本地的多個數據源訪問數據，並可以通過自定義的應用程序界面或所選的BI工具運行臨時查詢。 數據科學家可以將筆記本電腦連接到Presto，以對數據進行大規模的探索和ML建模，而無需處理一部分數據。
隨著我們繼續在Salesforce上構建大數據計算平臺，我們將分享更多的工程經驗和業務成果。 敬請關注！
(本文翻譯自Ram Sangireddy的文章《Big Data, Big Decisions: Finding the Right Technology for Interactive Analytics at Salesforce》，參考：https://engineering.salesforce.com/big-data-big-decisions-690a00fad88d)
閱讀更多 聞數起舞 的文章
關鍵字: 國創上頭條 Ap Salesforce
