pb 窗口数据修改sql_大数据hadoop,数据中台选型你应该看到这些分布式数据库
? ? 長期以來,由于以hadoop為核心的生態系統霸占了大數據的各個角度,以至于我們以為大數據就是hadoop。誠然,自hadoop誕生以來,hive+hbase掀起第一個高潮,而后Spark和Flink更是火爆到不行,聲浪一陣蓋過一陣。盡管hadoop在高并發、海量數據處理等方面有著無可比擬的優勢,但是在OLAP場景下的數據分析方面始終不如人意。
? ? ?在hadoop生態體系中,可以用作OLAP分析的引擎主要有以下幾個:
1)Hive
? ? ?Hive 最早由 Facebook 開源貢獻也是早年應用最廣泛的大數據 SQL 引擎,和 MapReduce 一樣,Hive 在業界的標簽就是慢而穩定。其無私地提供了很多公共組件為其他引擎所使用,堪稱業界良心,比如元數據服務 Hive Metastore、查詢優化器 Calcite、列式存儲 ORC 等。
? ? 近年來,Hive 發展很快,例如查詢優化方面采用了 CBO,在執行引擎方面用 Tez 來替換 MapReduce,通過 LLAP 來 cache 查詢結果做優化,以及 ORC 存儲不斷演進。不過相比較而言,這些新技術從市場應用來說還不算成熟穩定,Hive 仍然被大量用戶定義為可靠的 ETL 工具而非即時查詢產品。
? ? ?Hive的優勢是完善的SQL支持,極低的學習成本,自定義數據格式,極高的擴展性可輕松擴展到幾千個節點等等。但是Hive 在加載數據的過程中不會對數據進行任何處理,甚至不會對數據進行掃描,因此也沒有對數據中的某些 Key 建立索引。Hive 要訪問數據中滿足條件的特定值時,需要暴力掃描整個數據庫,因此訪問延遲較高。
2)HAWQ
? ? ? Hawq是一個Hadoop原生大規模并行SQL分析引擎,Hawq采用 MPP 架構,改進了針對 Hadoop 的基于成本的查詢優化器。除了能高效處理本身的內部數據,還可通過 PXF 訪問 HDFS、Hive、HBase、JSON 等外部數據源。HAWQ全面兼容 SQL 標準,能編寫 SQL UDF,還可用 SQL 完成簡單的數據挖掘和機器學習。無論是功能特性,還是性能表現,HAWQ 都比較適用于構建 Hadoop 分析型數據倉庫應用。
? ? 網絡上有人對Hawq與Hive查詢性能進行了對比測試,總體來看,使用Hawq內部表比Hive快的多(4-50倍)。Hawq是基于GreenPlum實現,缺點是安裝配置復雜,技術實現也比較復雜,因此社區活躍度不高。
3)Presto
? ? ?Presto是Facebook推出的基于內存的并行計算的分布式SQL交互式查詢引擎 多個節點管道式執行。支持任意數據源 數據規模GB~PB 是一種Massively parallel processing(mpp)(大規模并行處理)模型
數據規模PB 不是把PB數據放到內存,只是在計算中拿出一部分放在內存、計算、拋出、再拿。Presto不僅支持hive,還支持各種jdbc數據源,可以作為一個跨平臺的查詢計算引擎。
? ? ? Presto 在前幾年應用比較廣泛,在Airbnb和JD等企業有過應用,京東還專門為此寫了一本書。但是近幾年逐步淡出了。這款內存型 MPP 引擎的特點就是處理小規模數據會非常快,數據量大的時候會比較吃力。
? ? ?由于Presto是基于內存的,而hive是在磁盤上讀寫的,因此presto比hive快很多,但是由于是基于內存的計算當多張大表關聯操作時易引起內存溢出錯誤。不適合多個大表的join操作。
4)Spark SQL
? ??SparkSQL 這兩年發展迅猛,尤其在 Spark 進入 2.x 時代,發展更是突飛猛進。其優秀的 SQL 兼容性(唯一全部 pass TPC-DS 全部 99 個 query 的開源大數據 SQL),卓越的性能、龐大且活躍的社區、完善的生態(機器學習、圖計算、流處理等)都讓 SparkSQL 從這幾個開源產品中脫穎而出,在國內外市場得到了非常廣泛的應用。
? ??Spark SQL對熟悉Spark的同學來說,很容易理解并上手使用:
相比于Spark RDD API,Spark SQL包含了對結構化數據和在其上運算的更多信息,Spark SQL使用這些信息進行了額外的優化,使對結構化數據的操作更加高效和方便;
SQL提供了一個通用的方式來訪問各式各樣的數據源,包括Hive, Avro, Parquet, ORC, JSON, and JDBC;
Hive兼容性極好。
5)Kylin
? ?? Apache Kylin?是一個開源的分布式分析引擎,提供Hadoop/Spark之上的SQL查詢接口及多維分析(OLAP)能力以支持超大規模數據,最初由eBay Inc. 開發并貢獻至開源社區。
? ? ? Kylin自身就是一個MOLAP系統,多維立方體(MOLAP Cube)的設計使得用戶能夠在Kylin里為百億以上數據集定義數據模型并構建立方體進行數據的預聚合。 簡單來說,Kylin中數據立方的思想就是以空間換時間,通過定義一系列的緯度,對每個緯度的組合進行預先計算并存儲。有N個緯度,就會有2的N次種組合。所以最好控制好緯度的數量,因為存儲量會隨著緯度的增加爆炸式的增長,產生災難性后果。原來的kylin是把數據存儲在Hbase里面,近些年做了一些改進,嘗試用文件存儲。
6)Impala
? ? ?Impala也是一個SQL on Hadoop的查詢工具,底層采用MPP技術,支持快速交互式SQL查詢。與Hive共享元數據存儲。Impalad是核心進程,負責接收查詢請求并向多個數據節點分發任務。statestored進程負責監控所有Impalad進程,并向集群中的節點報告各個Impalad進程的狀態。catalogd進程負責廣播通知元數據的最新信息。
? ? ?Impala 的性能也非常優異,不過其發展路線相對封閉,社區生態進展比較緩慢,SQL 兼容性也比較差,用戶群體相對較小。
Impala的劣勢也同樣明顯:
Impala不提供任何對序列化和反序列化的支持;
Impala只能讀取文本文件,而不能讀取自定義二進制文件;
每當新的記錄/文件被添加到HDFS中的數據目錄時,該表需要被刷新。這個缺點會導致正在執行的查詢sql遇到刷新會掛起,查詢不動。
? ? ?以上開源組件,雖然在某些方面的性能比較卓越,但是總體上欠缺穩定性,使用也不夠靈活,優點明細,確定也很明顯。在這里我針對OLAP的一些數據庫選型要求簡單明了的總結一下各組件的評分情況。如有不妥,還請大神指正。
| 查詢速度 | SQL支持 | BI集成支持 | 市場活躍度 | |
| Hive | ★ | ★★★★ | ★★★★ | ★★★★★ |
| Presto | ★★★ | ★★★ | ★★ | ★★★ |
| HAWQ | ★★★ | ★★★ | ★ | ★ |
| Spark SQL | ★★★ | ★★★★ | ★★ | ★★★★ |
| Kylin | ★★★★ | ★★★ | ★★★ | ★★★ |
| Impala | ★★★★ | ★★★ | ★★★ | ★★★ |
? ? ? ?注:以最高五顆星作為滿分要求。
? ? ? 由于以上插件的種種優劣勢,我特此推薦以下三個數據庫作為大家作為數據中臺的一個可選項。其中任何一款都比hadoop平臺好用。
1)Greenplum數據庫
? ? ? 在此,我向大家非常隆重的推薦Greenplum數據庫。Greenplum數據庫是基于PostgreSQL開源并行數據庫,基于MPP架構的最成熟的應用產品。
? ? ?Greenplum完全支持ANSI SQL 2008標準和SQL OLAP 2003 擴展;從應用編程接口上講,它支持ODBC和JDBC。完善的標準支持使得系統開發、維護和管理都非常方便。Greenplum支持分布式事務,支持ACID。保證數據的強一致性。作為分布式數據庫,擁有良好的線性擴展能力。Greenplum有完善的生態系統,可以與很多企業級產品集成,譬如SAS,Cognos,Informatic,Tableau等;也可以很多種開源軟件集成,譬如Pentaho,Kettle等。
?? ?? ?除此以外,Greenplum還有非常豐富的ETL插件功能,例如GPLoad高速并行加載機制、PXF外表,支持Python、C等各種編程語言擴展功能,支持存儲過程加工數據(Greenplum里面統稱函數),支持MADLIB機器學習插件庫。由于Greenplum功能特別強大,所以做OLAP開發也特別簡單。另一方面Greenplum的OLTP性能也還可以,支持通過JDBC鏈接實時更新數據。
? ? ? ?同時Greenplum在存儲和處理大數據量查詢是也毫不遜色。在合理的集群配置和恰當的性能優化場景下,可以實現復雜應用場景5s以下的查詢響應。
2)Clickhouse
? ? ?Clickhouse 由俄羅斯 yandex 公司開發。專為在線數據分析而設計。Yandex是俄羅斯搜索引擎公司。官方提供的文檔表名,ClickHouse 日處理記錄數"十億級",在騰訊還有千億級數據量的應用。
? ? ??Clickhouse 是OLAP界的一匹黑馬,最近幾年上升勢頭特別猛。這個開源的列式存儲數據庫的跑分要超過很多流行的商業MPP數據庫軟件,例如Vertica。因此Clickhouse 特別適合超大數量的實時快速查詢,在各互聯網公司的使用場景下,可以優化到億級數據5s以內的響應速度,堪稱是性能怪獸。
? ?ClickHouse集成了各自優秀的數據庫引擎,支持分布式并行計算,把單機性能壓榨到極限;支持列式存儲數據庫和數據壓縮;支持關系型SQL語句;支持高可用和PB級數據查詢。
? ? ?當然,ClickHouse也有一些劣勢,例如缺少高頻率,低延遲的修改或刪除已存在數據的能力;僅能用于批量刪除或修改數據;沒有完整的事務支持;不支持二級索引;有限的SQL支持,join實現與眾不同。
? ? ?所以ClickHouse適合配合hive使用,用作hive批處理結果的查詢引擎。在“快”的巨大優勢勉強,ClickHouse是超大數量實時查詢的首選。
3)?HANA
? ? ? HANA是SAP公司發布的一款內存數據庫。根據SAP公司的定義,HANA是一個軟硬件結合體,提供高性能的數據查詢功能,用戶可以直接對大量實時業務數據進行查詢和分析。用戶拿到的是一個裝有預配置軟件的設備。至于HANA的云服務,只是對用戶而言可以在不購買相關硬件的情況下享受HANA的高性能,而HANA云服務的背后還是需要更高性能的硬件支撐的。
? ? ? ?HANA的優勢在于快,億級數據關聯都是毫秒級響應結果。HANA也是一款關系型數據庫,支持單機部署,也支持多節點部署。HANA也支持云平臺部署。
? ? ? ? HANA缺點是貴,并且不開源。但是憑良心說,HANA確實是一款非常優秀的數據庫,在當前數據比硬件更值錢的趨勢下,有些不差錢的企業可以考慮這個方案。
? ? ? 最后,針對以上三款關系型數據庫,我也在這里打一下分,用以對比。
| 查詢速度 | SQL支持 | BI集成支持度 | 市場活躍度 | |
| Greenplum | ★★★★ | ★★★★★ | ★★★★★ | ★★★★ |
| ClickHouse | ★★★★★ | ★★★★ | ★★ | ★★★★ |
| HANA | ★★★★★ | ★★★★★ | ★★★★★ | ★★★ |
??? ? ?最后統計一下得分,hadoop生態圈,Hive得分14分,Presto11分,HAWQ 8分,Spark SQL 13分,Kylin13分,Impala 13分。非Hadoop生態圈,Greenplum得分18分,ClickHouse15分,HANA18分。
? ?總結一下,除了上述三款關系型數據庫以外,大數據平臺里面Impala+Kudu的方案在小米有過應用,應該也是可以在一定業務場景慢滿足查詢和插入數據的均衡;另外,在關系型數據庫領域,PingCAP 公司的TiDB、騰訊開源的TBase、阿里巴巴的OceanDB、華為的GaussDB、中興的GoldenDB都可以引入到OLAP場景中,實現數據插入更新和批量數據分析的均衡,從而更好的滿足數據中臺的快速查詢和實時數據更新需求。
? ? ? ??數據中臺的目的是讓數據持續產生價值,因此,技術不是重點,簡單好用才是我們應該把握的關鍵。不忘初心,才能走得更遠。最后再次推薦中小企業搭建數據中臺采用Greenplum,Hadoop水太深慎入。
《數據中臺研習社》微信群,請添加微信:laowang5244,備注【進群】
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??分享、點贊、在看,給個三連擊唄!?
與50位技術專家面對面20年技術見證,附贈技術全景圖總結
以上是生活随笔為你收集整理的pb 窗口数据修改sql_大数据hadoop,数据中台选型你应该看到这些分布式数据库的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 编程用的记事本软件_数控常用编程软件那么
- 下一篇: ps cs6 磨皮插件_PS后期磨皮插件