我們正在美國處理2400萬家企業。我們現在在Hadoop上使用HDFS。我們希望加快調試的臨時查詢。例如。現在需要幾分鐘的時間來從我們的5個服務器集羣中的2400萬企業中挑出一個業務。Hadoop上的特別查詢
Hbase似乎是我發現可以完成這項工作的唯一系統。 Hive似乎沒有這樣做。
這是我們的模式,當前存儲爲HDFS中製表符分隔的文本文件。
place_id name value
1 Title Bamboo Garden
1 Title Bamboo Garden Restaurant
1 Phone 425-555-555
1 Phone 425-444-444
1 Address 123 Bellevue Way
2 Title Burger King
2 Phone 425-333-3333
我們選擇這個名稱值對來安裝附加數據和字段的靈活性。例如。如果我們想要結合兩個數據集,我們可以輕鬆地「貓」它們。另外,添加更多新字段非常簡單。這個模式很早就被設計出來了,很少有機會改變它。
我們發現很難在Hbase中對它進行建模,因爲Hbase不支持重複密鑰。正如你可以在上面的例子中看到的,每個企業可以有多個電話號碼,標題,註釋等
所以我的問題
- 什麼是加快這樣的即席查詢在 Hadoop的想法?
- 將HBase數組存儲在 HBase中的最佳做法是什麼?
- 如何使用重複鍵對此鍵值對進行建模 HBase?
編輯讀書問題在意見後: 最常見的即席查詢是返回一個企業的所有信息與給定的ID。還有其他很好的特別查詢支持,例如返回給定郵政編碼和標題的業務。
在使用RDBMS支持即席查詢的建議中是一個很好的建議。但我希望有一個系統支持流式和即席查詢。我們的臨時查詢主要用於調試。如果我們在數據中發現錯誤,我們仍然需要驗證它是否是我們的Hadoop數據中的錯誤,因此查詢RDBMS是不夠的。
最常見的流處理查詢是加入兩個大數據集並匹配兩個數據集之間的業務。與ad hoc查詢相比,流處理查詢支持需求更多,因此我們選擇Hadoop。我們的特別查詢主要用於調試。
我有點不清楚爲什麼你不只是使用普通的SQL數據庫。這些數據庫可以輕鬆處理2400萬條記錄,而且您可以使用它們進行非常複雜的搜索。我意識到NoSql是所有的範圍,但* [威爾史密斯的聲音] * daaammn。 –
你的查詢是什麼樣的?這將決定你的HBase模式/密鑰應該被組織。 – Suman
鯊魚可能對你有些興趣:http://shark.cs.berkeley.edu/ – zengr