精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

當前位置:CIO技術探討 → 正文

為什么Google的BigQuery在大數據并發處理中脫穎而出?

責任編輯:cres 作者:D1net |來源:企業網D1Net  2017-04-14 10:35:16 原創文章 企業網D1Net

D1net觀察:現在是數據時代,企業都想通過數據獲取價值,工欲善其事,必先利其器,企業應該選擇什么工具呢?接下來看看幫助機構在大數據中實現商業智能的初創公司AtSacle的一些實踐。
 
您應該使用Hadoop來滿足您的商業智能需求嗎?抑或是BigQuery?自建Hadoop,云端Hadoop與Google的無服務器模型BigQuery之間有什么區別呢?來自Atscale的基準有助于您應付這些問題。
 
在大數據中實現商業智能并且處理大量并發查詢的能力對您來說如果是很重要的,根據專門幫助機構在大數據中實現商業智能的初創公司AtSacle公布的一項商業智能基準,Google的BigQuery是不二之選。
 
“并發處理一直是個硬傷,給SQL-on-Hadoop帶來巨大的挑戰”,AtScale產品管理部的副總裁Josh Klahr如是說。
 
然而AtScale的基準發現并發處理一直是BigQuery的強項。因為它的無服務器模型意味著小數據集的并發查詢性能不會表現出任何查詢性能的下降,甚至在查詢量超過25個商業智能用戶時。
 
Klahr說:“并發處理是至關重要的”。“但是BigQuery的用戶體驗也是不錯的,也許這并不奇怪,因為Google多年來一直關注消費產品:關于產品使用一直都是不錯的,最耗費時間的是把我們的本地網絡加載到云端,一旦在云端有了數據,創建表格將變得非常容易。“
 
關于基準,AtScale使用了和去年部署的測試商業智能工作量的SQL-on-Hadoop引擎基準測試同樣的模型,測試的理念在于幫助技術評估者為他們的商業智能用例選擇最好的SQL-on-Hadoop技術。Google的BigQuery基準的目的也如出一轍。
 
Constellation Research的副總裁兼首席分析師Doug Henschen在周四的聲明里說:“Atscale基準提供了企業領袖所需的使商業智能運行在大數據里提供了有價值的對比”。“當數據變得越來越復雜,越來越多樣時,這些基準統計能幫助企業理解領先的大數據查詢選擇,并做出對商業數據基礎設施至關重要的決定。”
 
AtScale的測試團隊使用Star Schema Benchmark (SSB)數據集,該數據集基于廣泛使用的TPCH數據,做了一定修改以便更準確地表示以一個典型的商業智能為導向的數據布局。該數據集允許測試團隊測試一系列大表格中的查詢:Lineorder表格包含了將近60億行,并且大客戶表格可包含超過10億行。
 
對于Google的BigQuery基準,AtScale查看了3個和去年一樣的用來評估SQL-on-Hadoop引擎及其是否滿足商業智能工作量的三個關鍵要求。
 
能在大數據上工作。SQL-on-Hadoop引擎必須能夠持續分析幾十億或上萬億的數據行而不出錯,并且響應時間大約在10秒或100秒。
 
處理小數據也很快。該引擎需要在已知的查詢模式中實現交互性能,很重要的一點是SQL-on-Hadoop引擎能在幾秒內返回小數據集的查詢結果(大約幾千或幾百萬行)。
 
多用戶狀態下依然穩定。企業商業智能用戶基礎由數百甚至幾千的數據工人組成。底層的SQL-on-Hadoop引擎必須在高度并發的分析工作量下可靠運行。
 
去年,AtScale發現Apache Impala,2.3, Apache Spark 1.6 和Apache Hive 1.2,它做了基準測試的3大SQL-on-Hadoop引擎,都有獨一無二的優缺點,而這些優缺點使得它們更適合一些使用情況而不太適合另一些用例。例如Hive是諸引擎中最慢的,致使其不適合交互查詢,然而它卻是3個引擎中最穩定的,在多種查詢類型中都具有最好的一致性。Impala和Spark則更適合較小的數據集。
 
正如Klahr指出,BigQuery提供了最佳的并發處理支持。并且使用它不需要過多的調整或系統配置。
 
Klahr說:“BigQuery不需要您做過多的調整,也不允許您做過多的加工。”“我們使用Hive和Impala的體驗就是各個引擎可能都要花費幾天到數周的時間調整參數。”
 
AtScale發現BigQuery管理控制臺,查詢工具和文檔編制使其簡單易用并支持快速適職。另外,把數據移動到Google云和加載到BigQuery的過程很簡單并且有豐富的參考文獻,盡管Klahr指出這個過程在云原生數據中比在自建數據中更快。
 
高效性能,BigQuery的速度沒有像Impala和Spark SQL那樣吹的天花亂墜,但也不相伯仲了。Klahr說。
 
“值得考慮的是:獲得性能所要付出的努力以及獲得合意的性能所要付出的代價的較量。”Klahr如是說。
 
如果說BigQuery有什么地方嚴重落后其它選擇的話,那就是在轉(join)語句上了。
 
“它對于大量的轉語句處理的不是很好”,Klahr說。“您的數據全部都在一個表格里,而Google致力于推廣嵌套的數據結構”。
 
AtScale的技術總監兼共同創始人Matt Baird認為最近的基準測試表明了大數據市場的成熟程度,像Google這樣的平臺供應商為企業結構提供了切實可行的方案。
 
“該基準的測試結果表明大數據市場的快速演變”,Matt Baird在周四的聲明中說:“這樣的步伐是令人望而生畏的,因為企業已經要處理相當程度的復雜性了,您應該使用Hadoop還是BigQuery呢?自建Hadoop,云端Hadoop和Google這樣的無服務器模型有什么區別?這就是我們創辦AtScale的原因”。

關鍵字:大數據

原創文章 企業網D1Net

x 為什么Google的BigQuery在大數據并發處理中脫穎而出? 掃一掃
分享本文到朋友圈
當前位置:CIO技術探討 → 正文

為什么Google的BigQuery在大數據并發處理中脫穎而出?

責任編輯:cres 作者:D1net |來源:企業網D1Net  2017-04-14 10:35:16 原創文章 企業網D1Net

D1net觀察:現在是數據時代,企業都想通過數據獲取價值,工欲善其事,必先利其器,企業應該選擇什么工具呢?接下來看看幫助機構在大數據中實現商業智能的初創公司AtSacle的一些實踐。
 
您應該使用Hadoop來滿足您的商業智能需求嗎?抑或是BigQuery?自建Hadoop,云端Hadoop與Google的無服務器模型BigQuery之間有什么區別呢?來自Atscale的基準有助于您應付這些問題。
 
在大數據中實現商業智能并且處理大量并發查詢的能力對您來說如果是很重要的,根據專門幫助機構在大數據中實現商業智能的初創公司AtSacle公布的一項商業智能基準,Google的BigQuery是不二之選。
 
“并發處理一直是個硬傷,給SQL-on-Hadoop帶來巨大的挑戰”,AtScale產品管理部的副總裁Josh Klahr如是說。
 
然而AtScale的基準發現并發處理一直是BigQuery的強項。因為它的無服務器模型意味著小數據集的并發查詢性能不會表現出任何查詢性能的下降,甚至在查詢量超過25個商業智能用戶時。
 
Klahr說:“并發處理是至關重要的”。“但是BigQuery的用戶體驗也是不錯的,也許這并不奇怪,因為Google多年來一直關注消費產品:關于產品使用一直都是不錯的,最耗費時間的是把我們的本地網絡加載到云端,一旦在云端有了數據,創建表格將變得非常容易。“
 
關于基準,AtScale使用了和去年部署的測試商業智能工作量的SQL-on-Hadoop引擎基準測試同樣的模型,測試的理念在于幫助技術評估者為他們的商業智能用例選擇最好的SQL-on-Hadoop技術。Google的BigQuery基準的目的也如出一轍。
 
Constellation Research的副總裁兼首席分析師Doug Henschen在周四的聲明里說:“Atscale基準提供了企業領袖所需的使商業智能運行在大數據里提供了有價值的對比”。“當數據變得越來越復雜,越來越多樣時,這些基準統計能幫助企業理解領先的大數據查詢選擇,并做出對商業數據基礎設施至關重要的決定。”
 
AtScale的測試團隊使用Star Schema Benchmark (SSB)數據集,該數據集基于廣泛使用的TPCH數據,做了一定修改以便更準確地表示以一個典型的商業智能為導向的數據布局。該數據集允許測試團隊測試一系列大表格中的查詢:Lineorder表格包含了將近60億行,并且大客戶表格可包含超過10億行。
 
對于Google的BigQuery基準,AtScale查看了3個和去年一樣的用來評估SQL-on-Hadoop引擎及其是否滿足商業智能工作量的三個關鍵要求。
 
能在大數據上工作。SQL-on-Hadoop引擎必須能夠持續分析幾十億或上萬億的數據行而不出錯,并且響應時間大約在10秒或100秒。
 
處理小數據也很快。該引擎需要在已知的查詢模式中實現交互性能,很重要的一點是SQL-on-Hadoop引擎能在幾秒內返回小數據集的查詢結果(大約幾千或幾百萬行)。
 
多用戶狀態下依然穩定。企業商業智能用戶基礎由數百甚至幾千的數據工人組成。底層的SQL-on-Hadoop引擎必須在高度并發的分析工作量下可靠運行。
 
去年,AtScale發現Apache Impala,2.3, Apache Spark 1.6 和Apache Hive 1.2,它做了基準測試的3大SQL-on-Hadoop引擎,都有獨一無二的優缺點,而這些優缺點使得它們更適合一些使用情況而不太適合另一些用例。例如Hive是諸引擎中最慢的,致使其不適合交互查詢,然而它卻是3個引擎中最穩定的,在多種查詢類型中都具有最好的一致性。Impala和Spark則更適合較小的數據集。
 
正如Klahr指出,BigQuery提供了最佳的并發處理支持。并且使用它不需要過多的調整或系統配置。
 
Klahr說:“BigQuery不需要您做過多的調整,也不允許您做過多的加工。”“我們使用Hive和Impala的體驗就是各個引擎可能都要花費幾天到數周的時間調整參數。”
 
AtScale發現BigQuery管理控制臺,查詢工具和文檔編制使其簡單易用并支持快速適職。另外,把數據移動到Google云和加載到BigQuery的過程很簡單并且有豐富的參考文獻,盡管Klahr指出這個過程在云原生數據中比在自建數據中更快。
 
高效性能,BigQuery的速度沒有像Impala和Spark SQL那樣吹的天花亂墜,但也不相伯仲了。Klahr說。
 
“值得考慮的是:獲得性能所要付出的努力以及獲得合意的性能所要付出的代價的較量。”Klahr如是說。
 
如果說BigQuery有什么地方嚴重落后其它選擇的話,那就是在轉(join)語句上了。
 
“它對于大量的轉語句處理的不是很好”,Klahr說。“您的數據全部都在一個表格里,而Google致力于推廣嵌套的數據結構”。
 
AtScale的技術總監兼共同創始人Matt Baird認為最近的基準測試表明了大數據市場的成熟程度,像Google這樣的平臺供應商為企業結構提供了切實可行的方案。
 
“該基準的測試結果表明大數據市場的快速演變”,Matt Baird在周四的聲明中說:“這樣的步伐是令人望而生畏的,因為企業已經要處理相當程度的復雜性了,您應該使用Hadoop還是BigQuery呢?自建Hadoop,云端Hadoop和Google這樣的無服務器模型有什么區別?這就是我們創辦AtScale的原因”。

關鍵字:大數據

原創文章 企業網D1Net

電子周刊
回到頂部

關于我們聯系我們版權聲明隱私條款廣告服務友情鏈接投稿中心招賢納士

企業網版權所有 ©2010-2024 京ICP備09108050號-6 京公網安備 11010502049343號

^
  • <menuitem id="jw4sk"></menuitem>

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 乌海市| 平阳县| 始兴县| 汪清县| 澄城县| 博乐市| 扬州市| 秭归县| 桂平市| 大渡口区| 青海省| 景洪市| 象山县| 固镇县| 久治县| 云安县| 陆丰市| 杨浦区| 从化市| 淳化县| 西城区| 巩义市| 宣威市| 崇信县| 沙田区| 黔西| 汽车| 额敏县| 清镇市| 红原县| 南华县| 安龙县| 绥芬河市| 丰宁| 邵阳市| 乌鲁木齐市| 右玉县| 六安市| 六安市| 浦城县| 勃利县|