Tableau + Spark + Cassandra的性能極差

目前我正在研究將Cassandra與Spark和Tableau結合使用進行數據分析的可能性。但是，我目前在這種設置下的表現非常糟糕，我無法想象將它用於生產目的。當我讀到Cassandra + Spark組合的表現應該是多麼出色的時候，我顯然做錯了什麼，但我找不到什麼。Tableau + Spark + Cassandra的性能極差

我的測試數據：

所有數據都存儲
查詢與50MB在單個表進行的單個節點上在選擇條件時（間隔數據）
列有一個索引上它

我的測試設置：

的MacBook 2015年，1.1千兆赫，8GB內存，SSD，OS X埃爾卡皮坦
虛擬盒，4GB內存，Ubuntu的14.04
單節點機智Datastax企業4.8.4：
- 的Apache Cassandra的2.1.12.1046
- 阿帕奇星火1.4.2.2
- 星火連接器1.4.1
- 阿帕奇節儉0.9.3
- 蜂巢連接器0.2.11
的Tableau（通過ODBC連接）

發現：

當的Tableau的變化從數據庫中需要加載的數據，它需要40秒和1.4分鐘之間的任何地方。檢索數據（這基本上是行不通的）
當我結合使用的Tableau與Oracle而不是卡桑德拉+星火，但在相同的虛擬框，我得到的結果幾乎在瞬間

下面是表用於查詢定義：

CREATE TABLE key.activity (
    interval timestamp, 
    id bigint, 
    activity_name text, 
    begin_ts timestamp, 
    busy_ms bigint, 
    container_code text, 
    duration_ms bigint, 
    end_location_code text, 
    end_ts timestamp, 
    pallet_code text, 
    src_location_code text, 
    start_location_code text, 
    success boolean, 
    tgt_location_code text, 
    transporter_name text, 
    PRIMARY KEY (interval, id) 
) WITH CLUSTERING ORDER BY (id ASC) 
    AND bloom_filter_fp_chance = 0.01 
    AND caching = '{"keys":"ALL", "rows_per_partition":"ALL"}' 
    AND comment = '' 
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'} 
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'} 
    AND dclocal_read_repair_chance = 0.1 
    AND default_time_to_live = 0 
    AND gc_grace_seconds = 864000 
    AND max_index_interval = 2048 
    AND memtable_flush_period_in_ms = 0 
    AND min_index_interval = 128 
    AND read_repair_chance = 0.0 
    AND speculative_retry = '99.0PERCENTILE'; 
CREATE INDEX activity_activity_name_idx ON key.activity (activity_name); 
CREATE INDEX activity_success_idx ON key.activity (success); 
CREATE INDEX activity_transporter_name_idx ON key.activity (transporter_name);

這裏是通過的Tableau產生的查詢的示例：

INFO 2016-02-10 20:22:21 org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation: Running query 'SELECT CASE WHEN 4 >= 0 THEN SUBSTRING(`activity`.`transporter_name`,1,CAST(4 AS INT)) ELSE NULL END AS `calculation_185421691185008640`, 
    AVG(CAST(`activity`.`busy_ms` AS DOUBLE)) AS `avg_busy_ms_ok`, 
    CAST((MONTH(`activity`.`interval`) - 1)/3 + 1 AS BIGINT) AS `qr_interval_ok`, 
    `activity`.`transporter_name` AS `transporter_name`, 
    YEAR(`activity`.`interval`) AS `yr_interval_ok` 
FROM `key`.`activity` `activity` 
GROUP BY CASE WHEN 4 >= 0 THEN SUBSTRING(`activity`.`transporter_name`,1,CAST(4 AS INT)) ELSE NULL END, 
    CAST((MONTH(`activity`.`interval`) - 1)/3 + 1 AS BIGINT), 
    `activity`.`transporter_name`, 
    YEAR(`activity`.`interval`)'

這裏是在52S查詢的統計數據爲例：

Spark statistics on query taken 52 secs. to complete

我試着在其他帖子中提到的分區鍵打轉轉，卻沒有看到一個顯著差異。我也嘗試啓用行緩存（Cassandra config + table屬性），但這也沒有任何效果（儘管也許我忽略了某些內容）。

即使沒有擺弄所有這些參數，我也會期望獲得至少10倍到20倍的開箱即用性能，並且我已經沒有想法做什麼了。

我在做什麼錯？我應該期待什麼樣的表現？

來源

2016-02-10 thedutchy

你能描述查詢嗎？例如，是否有加入？ –

@ChrisGerken謝謝你看我的問題。我剛剛添加了一個查詢的例子。所有查詢都在單個表上執行（因此沒有聯接）。 – thedutchy

由於您未在帖子中定義的變量，回答您的問題並不容易。你提到存儲在一個節點上的數據，這很好，但你沒有描述你是如何構建你的表/列系列的。您也沒有提及cassandra緩存命中率。您還必須考慮Cassandra Compaction，如果在繁重的讀/寫操作過程中正在運行壓縮，它會減慢速度。

您似乎也有一個SSD，在這種情況下，您將在同一個物理驅動器上擁有Data目錄和commitlogs和cache目錄。即使它不是旋轉磁盤，除非從commitlogs/cache目錄拆分數據目錄，否則將會看到性能下降。通過將Data dir分割到自己的物理SSD上，我看到性能提高了50％。

另外，最後你在Vbox的筆記本電腦主機上的虛擬機上運行。這裏最大的瓶頸是1.1 GHz CPU。在運行中型作業時，在VMWare的cassandra環境中，我看到16GB內存上4個2核心的使用率接近99％。我的數據目錄位於SSD上，而我的提交日誌和緩存目錄位於磁性HDD上。我獲得了良好的性能，但我調整了我的環境以達到此目的，並接受了非生產環境提供的延遲。

看一看HERE並試圖更好地理解Cassandra應該如何使用以及如何實現更好的開箱即用性能。分佈式系統就是這樣..分佈式和有原因的。您在單臺計算機上無法使用的共享資源。

希望這可以解釋更多關於你前進的方向。

編輯

你的表定義看起來不錯。您是否使用Tableau Spark連接器？你的性能問題可能在cassandra/Spark方面。

看看這個article，它描述了從緩存讀取時壓縮相關的問題。基本上，在2.1.2壓縮之前的cassandra發行版中，現在已經失去了緩存，因爲壓縮完成後，Cassandra將文件（和緩存）扔掉。一旦你開始閱讀你立即得到一個錯過的緩存命中和cassandra然後回到光盤。這在2.1.2以後的版本中得到修復。對於運行Spark/Cassandra來說，其他一切看起來都很正常。

來源

2016-02-10 16:42:19 apesa

謝謝！我只是添加了一個SQL查詢和表定義到我的問題。我在執行查詢之前手動運行壓縮，之後沒有添加/更改/刪除任何數據。一切都從同一個SSD運行，不幸的是，我沒有簡單的方法來改變它，但感謝提示。是的，我意識到我的硬件遠非最佳，但我只是試圖確定解決方案是否可行。縱觀你的鏈接，我仍然感到奇怪的是，甲骨文立即在相同的設置中返回，而Spark似乎永遠消失。將研究你的鏈接更多... – thedutchy

我編輯了我的答案，看看。特別是在你的cassandra版本的鏈接文章中 – apesa

儘管查詢時間似乎有點高，但我發現有幾件事情可能會導致問題。

我注意到你正在使用MacBook。美麗的電腦，但不理想的火花。我相信那些正在使用雙核英特爾M處理器。如果你去你的Spark Master用戶界面，它會顯示你可用的核心。它可能顯示4（包含vCPU）。您運行此查詢的性質不允許大量的並行（如果有的話）。在這種情況下，你基本上沒有得到Spark的優勢，因爲你運行在一個非常小的虛擬機中，並且運行在單個節點上（CPU有限）。可視化工具還沒有真正趕上Spark。

還有一點需要記住的是，Spark並不是被設計成'adhoc query'工具。您可以將SparkSQL視爲Spark Spark的一個抽象概念。與Oracle相比，在這個規模下，不會產生您期望的結果。您會注意到Spark的「最低」性能閾值。一旦您將數據和節點擴展到足夠的距離，您就會開始看到完成時間和數據大小不是線性的，並且當您添加更多數據時，處理時間仍然相對平緩。

我建議在SparkSQL REPL dse spark-sql中嘗試查詢，看看你是否得到相似的時間。如果你這樣做，那麼你知道這是你用當前設置獲得的最好結果。如果Tableau比REPL慢很多，那麼我猜測這是他們在這一點上的結果。

來源

2016-02-11 16:00:27 MarcintheCloud

Tableau + Spark + Cassandra的性能極差

回答

相關問題