《被忽視的位圖數據庫:Pilosa查詢十億級出租車搭乘數據案例》要點:
本文介紹了被忽視的位圖數據庫:Pilosa查詢十億級出租車搭乘數據案例,希望對您有用。如果有疑問,可以聯系我們。
Pilosa 是一個開源的分布式內存位圖索引,可以針對海量數據集對查詢進行加速,適合在用戶數據查詢以及用戶畫像等場景使用,但在另外一方面,非稀疏的關系型數據是否也可以使用 Pilosa 來查詢?
Pilosa 最初是為分析用戶屬性數據(稀疏并且高基數)而準備的.所以當我們準備圍繞 Pilosa 創建一家公司時,第一步就是評估在其他類型數據上的效果.
雖然用戶細分的屬性數量非常多,但數據卻非常稀疏,這是因為很多屬性只與少數人相關聯,大部分人只有幾百個或幾千個屬性. Pilosa 可以非常優雅地處理這種場景,它能夠在幾毫秒內篩選數百萬個屬性的任意組合,從而找到滿足該條件的用戶.
圖片由 Umbel 提供
對于用戶細分數據,我們可以使用 Pilosa 處理這類問題.然而,如果我們希望 Pilosa 成為通用索引,那么它將不僅能支持分段查詢而且不僅再稀疏而高基數的數據上工作.
為了測試 Pilosa,我們需要一個具有密集的,較低基數的數據集,并最好是能通過其他解決方案進行探討,以便評估我們如何處理該問題.
紐約市政府開放的十億出租車搭乘數據集(下載請參閱文末鏈接 4)完美符合以上條件,有很多分析該數據的文章,下面列出的僅僅是少數幾個鏈接:
(譯者注:數據集中包含上下車時間、地點、距離、車費、支付方式、乘客人數等字段)
對我們特別有用的是 Mark Litwintschik 和他編制的性能比較表的系列文章,這是結果表格供參考,其中分別使用了 Spark, PostgreSQL, Elasticsearch 等數據庫來查詢.
我們對 Pilosa 執行了相同的四個查詢,以便我們可以同其他解決方案的性能進行比較.
以下是每個查詢的描述:
現在我們有一個數據集和一組查詢,都遠遠超出了 Pilosa 的最適合做的領域,以及對不同硬件/軟件組合的長期性能對比.
如果您想了解如何在 Pilosa 中建模數據集并構建查詢,請參閱我們的運輸用例文章 [6].
現在我們并非只有數千萬的 boolean 屬性,其中一些屬性具有更復雜的類型:整數,浮點,時間戳等等.總而言之,相比之下這個數據集更適合用關系型數據庫.
我們在 AWS c4.8xlarge 實例上架起了一個 3 節點的 Pilosa 集群,并附加了一個 c4.8xlarge 實例來加載數據.我們使用 pdk 工具將數據加載到 Pilosa 中,使用以下命令行參數:
pdk taxi -b 2000000 -c 50 -p:10101 -f /usecase/taxi/greenAndYellowUrls.txt
這個過程需要大約 2 小時 50 分鐘,其中包括從 S3 下載所有的 csv 文件,解析它們,并將數據加載到 Pilosa 中.
如果我們將結果添加到 Mark 表中,它將如下所示:
請注意,每個組合的軟硬件都不同,所以直接比較是很困難的.
我們應該注意到,Pilosa 在“查詢1”上有一些“作弊”(由于其存儲數據的方式,Pilosa 已經預先計算了此結果),因此查詢時間大部分是網絡延遲.
然而,對于其余的查詢,Pilosa 表現非常出色 – 在某些情況下,可以勝過異構硬件,如多 GPU 配置.查詢3 的 0.177s 時間特別令人吃驚,與 Nvidia Pascal Titan Xs 的表現相似.看起來 kdb+/q 也很好,但是請記住,Xeon Phi 7210 每個芯片有 256 個硬件線程,以及 16GB 的內存.這使它們的性能和內存帶寬更接近于 GPU.當然價格也很貴,約 2400 美元.
對于我們來說,這些結果足以讓我們花費更多的時間優化 Pilosa 用于其他方面.由于 Pilosa 的內部位圖壓縮格式沒有針對密集數據進行優化,我們在這方面進行了更多的研究,并獲得了令人振奮的結果,所以我們有理由認為這些數字還有很大的改進空間.
更多了解 Pilosa 源代碼:https://github.com/pilosa/pilosa
相關鏈接:
本文作者 Matt Jaffee 及 Alan Bernstein,由 Jesse 翻譯,來自微信公眾號:高可用架構
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/2744.html