1. 究竟是什麼讓Redshift比Hive快10倍
究竟是什麼原因產生了如此懸殊的速度，有網友在Quora上提出了這個問題，並得到了Reynold Xin的解答：
Redshift採用了專有的叫做ParAccel的並行資料庫實現機制。我想在很多工作情境中，你會發現大多數並行資料庫引擎要比Hive快。接下來，我將給出答案，並解釋其中的某些原因。請注意的是，雖然該答案針對的是ParAccel，其中的大部分因素也適用於Vertica、Greenplum、OracleRAC等並行資料庫。
在答案中呢，我將使用三個可互換的術語「並行資料庫」、「關系型資料庫」和「分析型資料庫」。
比起並行資料庫，Hive在可擴展性、靈活度方面遙遙領先。例如，Facebook使用Hive數據倉庫跨越成千上萬個節點。說起靈活度，Hive設計的初衷是與一些系列存儲系統（HDFS、HBase、S3）配合使用，並能夠支持多種輸入格式（壓縮、未壓縮、Avro、純文本、JSON）。
易擴展和高靈活度在給你帶來便利的同時，卻也阻礙了你構建性能更好的查詢引擎。接下來，我將列舉哪些特徵會影響查詢性能：
數據格式：數據以類似純文本文件，相對未優化的形式存儲在HDFS中。Hive 作業在處理數據之前，需要先花大量時間從硬碟中讀取數據，再反序列化這些數據。
發起任務的系統開銷：Hadoop MapRece 使用心跳機制（heartbeats）制定作業計劃，每項任務作為一獨立的JVM過程發起。在Hadoop MapRece 中，僅僅是發起一項作業就需要幾十秒鍾，在秒級時間單位內，是無法運行任何進程的。相反，並行資料庫擁有持續進程或線程池，它們能夠大大減少任務安排及發起所需要的系統開銷。
中間數據物化 vs數據傳輸：Hive 使用擁有二階模型(Map和Rece)的MapRece來執行。通常一個復雜的SQL查詢被映射為MapRece的多個階段，不同階段的中間數據在硬碟上物化。並行資料庫內置有用於執行SQL查詢的引擎，執行查詢時，該引擎在查詢操作符和數據流（steram data）之間跨節點傳遞數據。
列數據格式：列資料庫將數據按照列式的格式進行存儲。在典型的數據倉庫中，每張數據表能夠存儲成百上千列，而大多數查詢僅查找少數列。讓我們來考慮一下如下查詢，要查找的是沃爾瑪每家店的營業額。它僅需要查找兩三列（商店的編號、每件商品的零售價，或者還有銷售日期）。以列式存儲數據，執行查詢時，引擎可以跳過不相關的列。這樣可以減少上百次的硬碟I/O。此外，按列存儲數據能夠大大增加壓縮比率。
列查詢引擎：除了上面提到的按列式存儲的數據格式，還可以按列構建查詢執行引擎，該引擎在分析型工作負載方面得到了較好的優化。其中的技巧包括：晚期物化（late materialization）、直接操作壓縮過的數據、利用現代CPU提供的向量化操作（SIMD）。
更快的S3連接：在這里我將給出一個大膽的猜測：AWS可能已經為他們的Redshift實例實現了一個比普通S3能夠提供的更高帶寬的S3整體負載。
我需要申明，我們剛剛討論的這些因素是基於Hive當前版本（2013年2月）。毫無置疑，Hive社區將會推進開發工作，並解決其中的一些難題。
2. vertica資料庫中怎麼實現動態參數
MAX_UTILIZATION代表資料庫自上次啟動以來達到的最大值，LIMIT_VALUE代表設置的最大值
select resource_name,MAX_UTILIZATION,LIMIT_VALUE from v$resource_limit where resource_name in ('processes','sessions')！
3. 設計一個大數據實時分析平台要怎麼做呢
PetaBase-V作為Vertica基於億信分析產品的定製版，提供面向大數據的實時分析服務，採用無共享大規模並行架構（MPP），可線性擴展集群的計算能力和數據處理容量，基於列式資料庫技術，使 PetaBase-V 擁有高性能、高擴展性、高壓縮率、高健壯性等特點，可完美解決報表計算慢和明細數據查詢等性能問題。
大數據實時分析平台（以下簡稱PB-S），旨在提供數據端到端實時處理能力（毫秒級／秒級／分鍾級延遲），可以對接多數據源進行實時數據抽取，可以為多數據應用場景提供實時數據消費。作為現代數倉的一部分，PB-S可以支持實時化、虛擬化、平民化、協作化等能力，讓實時數據應用開發門檻更低、迭代更快、質量更好、運行更穩、運維更簡、能力更強。
整體設計思想
我們針對用戶需求的四個層面進行了統一化抽象：
統一數據採集平台
統一流式處理平台
統一計算服務平台
統一數據可視化平台
同時，也對存儲層保持了開放的原則，意味著用戶可以選擇不同的存儲層以滿足具體項目的需要，而又不破壞整體架構設計，用戶甚至可以在Pipeline中同時選擇多個異構存儲提供支持。下面分別對四個抽象層進行解讀。
1)統一數據採集平台
統一數據採集平台，既可以支持不同數據源的全量抽取，也可以支持增強抽取。其中對於業務資料庫的增量抽取會選擇讀取資料庫日誌，以減少對業務庫的讀取壓力。平台還可以對抽取的數據進行統一處理，然後以統一格式發布到數據匯流排上。這里我們選擇一種自定義的標准化統一消息格式UMS（Unified Message Schema）做為 統一數據採集平台和統一流式處理平台之間的數據層面協議。
UMS自帶Namespace信息和Schema信息，這是一種自定位自解釋消息協議格式，這樣做的好處是：
整個架構無需依賴外部元數據管理平台；
消息和物理媒介解耦（這里物理媒介指如Kafka的Topic, Spark Streaming的Stream等），因此可以通過物理媒介支持多消息流並行，和消息流的自由漂移。
平台也支持多租戶體系，和配置化簡單處理清洗能力。
2)統一流式處理平台
統一流式處理平台，會消費來自數據匯流排上的消息，可以支持UMS協議消息，也可以支持普通JSON格式消息。同時，平台還支持以下能力：
支持可視化／配置化／SQL化方式降低流式邏輯開發／部署／管理門檻
支持配置化方式冪等落入多個異構目標庫以確保數據的最終一致性
支持多租戶體系，做到項目級的計算資源／表資源／用戶資源等隔離
3)統一計算服務平台
統一計算服務平台，是一種數據虛擬化／數據聯邦的實現。平台對內支持多異構數據源的下推計算和拉取混算，也支持對外的統一服務介面（JDBC／REST）和統一查詢語言（SQL）。由於平台可以統一收口服務，因此可以基於平台打造統一元數據管理／數據質量管理／數據安全審計／數據安全策略等模塊。平台也支持多租戶體系。
4)統一數據可視化平台
統一數據可視化平台，加上多租戶和完善的用戶體系／許可權體系，可以支持跨部門數據從業人員的分工協作能力，讓用戶在可視化環境下，通過緊密合作的方式，更能發揮各自所長來完成數據平台最後十公里的應用。
以上是基於整體模塊架構之上，進行了統一抽象設計，並開放存儲選項以提高靈活性和需求適配性。這樣的RTDP平台設計，體現了現代數倉的實時化／虛擬化／平民化／協作化等能力，並且覆蓋了端到端的OLPP數據流轉鏈路。
具體問題和解決思路
下面我們會基於PB-S的整體架構設計，分別從不同維度討論這個設計需要面對的問題考量和解決思路。
功能考量主要討論這樣一個問題：實時Pipeline能否處理所有ETL復雜邏輯？
我們知道，對於Storm／Flink這樣的流式計算引擎，是按每條處理的；對於Spark Streaming流式計算引擎，按每個mini-batch處理；而對於離線跑批任務來說，是按每天數據進行處理的。因此處理范圍是數據的一個維度（范圍維度）。
另外，流式處理面向的是增量數據，如果數據源來自關系型資料庫，那麼增量數據往往指的是增量變更數據（增刪改，revision）；相對的批量處理面向的則是快照數據（snapshot）。因此展現形式是數據的另一個維度（變更維度）。
單條數據的變更維度，是可以投射收斂成單條快照的，因此變更維度可以收斂成范圍維度。所以流式處理和批量處理的本質區別在於，面對的數據范圍維度的不同，流式處理單位為「有限范圍」，批量處理單位為「全表范圍」。「全表范圍」數據是可以支持各種SQL運算元的，而「有限范圍」數據只能支持部分SQL運算元。
復雜的ETL並不是單一運算元，經常會是由多個運算元組合而成，由上可以看出單純的流式處理並不能很好的支持所有ETL復雜邏輯。那麼如何在實時Pipeline中支持更多復雜的ETL運算元，並且保持時效性？這就需要「有限范圍」和「全表范圍」處理的相互轉換能力。
設想一下：流式處理平台可以支持流上適合的處理，然後實時落不同的異構庫，計算服務平台可以定時批量混算多源異構庫（時間設定可以是每隔幾分鍾或更短），並將每批計算結果發送到數據匯流排上繼續流轉，這樣流式處理平台和計算服務平台就形成了計算閉環，各自做擅長的運算元處理，數據在不同頻率觸發流轉過程中進行各種運算元轉換，這樣的架構模式理論上即可支持所有ETL復雜邏輯。
2)質量考量
上面的介紹也引出了兩個主流實時數據處理架構：Lambda架構和Kappa架構，具體兩個架構的介紹網上有很多資料，這里不再贅述。Lambda架構和Kappa架構各有其優劣勢，但都支持數據的最終一致性，從某種程度上確保了數據質量，如何在Lambda架構和Kappa架構中取長補短，形成某種融合架構，這個話題會在其他文章中詳細探討。
當然數據質量也是個非常大的話題，只支持重跑和回灌並不能完全解決所有數據質量問題，只是從技術架構層面給出了補數據的工程方案。關於大數據數據質量問題，我們也會起一個新的話題討論。
3)穩定考量
這個話題涉及但不限於以下幾點，這里簡單給出應對的思路：
高可用HA
整個實時Pipeline鏈路都應該選取高可用組件，確保理論上整體高可用；在數據關鍵鏈路上支持數據備份和重演機制；在業務關鍵鏈路上支持雙跑融合機制
SLA保障
在確保集群和實時Pipeline高可用的前提下，支持動態擴容和數據處理流程自動漂移
彈性反脆弱
? 基於規則和演算法的資源彈性伸縮
? 支持事件觸發動作引擎的失效處理
監控預警
集群設施層面，物理管道層面，數據邏輯層面的多方面監控預警能力
自動運維
能夠捕捉並存檔缺失數據和處理異常，並具備定期自動重試機制修復問題數據
上游元數據變更抗性
?上游業務庫要求兼容性元數據變更
? 實時Pipeline處理顯式欄位
4)成本考量
這個話題涉及但不限於以下幾點，這里簡單給出應對的思路：
人力成本
通過支持數據應用平民化降低人才人力成本
資源成本
通過支持動態資源利用降低靜態資源佔用造成的資源浪費
運維成本
通過支持自動運維／高可用／彈性反脆弱等機制降低運維成本
試錯成本
通過支持敏捷開發／快速迭代降低試錯成本
5)敏捷考量
敏捷大數據是一整套理論體系和方法學，在前文已有所描述，從數據使用角度來看，敏捷考量意味著：配置化，SQL化，平民化。
6)管理考量
數據管理也是一個非常大的話題，這里我們會重點關注兩個方面：元數據管理和數據安全管理。如果在現代數倉多數據存儲選型的環境下統一管理元數據和數據安全，是一個非常有挑戰的話題，我們會在實時Pipeline上各個環節平台分別考慮這兩個方面問題並給出內置支持，同時也可以支持對接外部統一的元數據管理平台和統一數據安全策略。
以上是我們探討的大數據實時分析平台PB-S的設計方案。