❶ 大數據三大核心技術：拿數據、算數據、賣數據！
大數據的由來
對於「大數據」（Big data）研究機構Gartner給出了這樣的定義。「大數據」是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力來適應海量、高增長率和多樣化的信息資產。
1
麥肯錫全球研究所給出的定義是：一種規模大到在獲取、存儲、管理、分析方面大大超出了傳統資料庫軟體工具能力范圍的數據集合，具有海量的數據規模、快速的數據流轉、多樣的數據類型和價值密度低四大特徵。
大數據技術的戰略意義不在於掌握龐大的數據信息，而在於對這些含有意義的數據進行專業化處理。換而言之，如果把大數據比作一種產業，那麼這種產業實現盈利的關鍵，在於提高對數據的「加工能力」，通過「加工」實現數據的「增值」。
從技術上看，大數據與雲計算的關系就像一枚硬幣的正反面一樣密不可分。大數據必然無法用單台的計算機進行處理，必須採用分布式架構。它的特色在於對海量數據進行分布式數據挖掘。但它必須依託雲計算的分布式處理、分布式資料庫和雲存儲、虛擬化技術。
大數據需要特殊的技術，以有效地處理大量的容忍經過時間內的數據。適用於大數據的技術，包括大規模並行處理（MPP）資料庫、數據挖掘、分布式文件系統、分布式資料庫、雲計算平台、互聯網和可擴展的存儲系統。
最小的基本單位是bit，按順序給出所有單位：bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB。
大數據的應用領域
大數據無處不在，大數據應用於各個行業，包括金融、 汽車 、餐飲、電信、能源、體能和 娛樂 等在內的 社會 各行各業都已經融入了大數據的印跡。
製造業，利用工業大數據提升製造業水平，包括產品故障診斷與預測、分析工藝流程、改進生產工藝，優化生產過程能耗、工業供應鏈分析與優化、生產計劃與排程。
金融行業，大數據在高頻交易、社交情緒分析和信貸風險分析三大金融創新領域發揮重大作用。
汽車 行業，利用大數據和物聯網技術的無人駕駛 汽車 ，在不遠的未來將走入我們的日常生活。
互聯網行業，藉助於大數據技術，可以分析客戶行為，進行商品推薦和針對性廣告投放。
電信行業，利用大數據技術實現客戶離網分析，及時掌握客戶離網傾向，出台客戶挽留措施。
能源行業，隨著智能電網的發展，電力公司可以掌握海量的用戶用電信息，利用大數據技術分析用戶用電模式，可以改進電網運行，合理設計電力需求響應系統，確保電網運行安全。
物流行業，利用大數據優化物流網路，提高物流效率，降低物流成本。
城市管理，可以利用大數據實現智能交通、環保監測、城市規劃和智能安防。
體育 娛樂 ，大數據可以幫助我們訓練球隊，決定投拍哪種 題財的 影視作品，以及預測比賽結果。
安全領域，政府可以利用大數據技術構建起強大的國家安全保障體系，企業可以利用大數據抵禦網路攻擊，警察可以藉助大數據來預防犯罪。
個人生活， 大數據還可以應用於個人生活，利用與每個人相關聯的「個人大數據」，分析個人生活行為習慣，為其提供更加周到的個性化服務。
大數據的價值，遠遠不止於此，大數據對各行各業的滲透，大大推動了 社會 生產和生活，未來必將產生重大而深遠的影響。
大數據方面核心技術有哪些？
大數據技術的體系龐大且復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、Nosql資料庫、數據倉庫、機器學習、並行計算、可視化等各種技術范疇和不同的技術層面。首先給出一個通用化的大數據處理框架，主要分為下面幾個方面：數據採集與預處理、數據存儲、數據清洗、數據查詢分析和數據可視化。
數據採集與預處理
對於各種來源的數據，包括移動互聯網數據、社交網路的數據等，這些結構化和非結構化的海量數據是零散的，也就是所謂的數據孤島，此時的這些數據並沒有什麼意義，數據採集就是將這些數據寫入數據倉庫中，把零散的數據整合在一起，對這些數據綜合起來進行分析。數據採集包括文件日誌的採集、資料庫日誌的採集、關系型資料庫的接入和應用程序的接入等。在數據量比較小的時候，可以寫個定時的腳本將日誌寫入存儲系統，但隨著數據量的增長，這些方法無法提供數據安全保障，並且運維困難，需要更強壯的解決方案。
Flume NG
Flume NG作為實時日誌收集系統，支持在日誌系統中定製各類數據發送方，用於收集數據，同時，對數據進行簡單處理，並寫到各種數據接收方(比如文本，HDFS，Hbase等)。Flume NG採用的是三層架構：Agent層，Collector層和Store層，每一層均可水平拓展。其中Agent包含Source，Channel和 Sink，source用來消費(收集)數據源到channel組件中，channel作為中間臨時存儲，保存所有source的組件信息，sink從channel中讀取數據，讀取成功之後會刪除channel中的信息。
NDC
Logstash
Logstash是開源的伺服器端數據處理管道，能夠同時從多個來源採集數據、轉換數據，然後將數據發送到您最喜歡的 「存儲庫」 中。一般常用的存儲庫是Elasticsearch。Logstash 支持各種輸入選擇，可以在同一時間從眾多常用的數據來源捕捉事件，能夠以連續的流式傳輸方式，輕松地從您的日誌、指標、Web 應用、數據存儲以及各種 AWS 服務採集數據。
Sqoop
Sqoop，用來將關系型資料庫和Hadoop中的數據進行相互轉移的工具，可以將一個關系型資料庫(例如Mysql、Oracle)中的數據導入到Hadoop(例如HDFS、Hive、Hbase)中，也可以將Hadoop(例如HDFS、Hive、Hbase)中的數據導入到關系型資料庫(例如Mysql、Oracle)中。Sqoop 啟用了一個 MapRece 作業(極其容錯的分布式並行計算)來執行任務。Sqoop 的另一大優勢是其傳輸大量結構化或半結構化數據的過程是完全自動化的。
流式計算
流式計算是行業研究的一個熱點，流式計算對多個高吞吐量的數據源進行實時的清洗、聚合和分析，可以對存在於社交網站、新聞等的數據信息流進行快速的處理並反饋，目前大數據流分析工具有很多，比如開源的strom，spark streaming等。
Strom集群結構是有一個主節點(nimbus)和多個工作節點(supervisor)組成的主從結構，主節點通過配置靜態指定或者在運行時動態選舉，nimbus與supervisor都是Storm提供的後台守護進程，之間的通信是結合Zookeeper的狀態變更通知和監控通知來處理。nimbus進程的主要職責是管理、協調和監控集群上運行的topology(包括topology的發布、任務指派、事件處理時重新指派任務等)。supervisor進程等待nimbus分配任務後生成並監控worker(jvm進程)執行任務。supervisor與worker運行在不同的jvm上，如果由supervisor啟動的某個worker因為錯誤異常退出(或被kill掉)，supervisor會嘗試重新生成新的worker進程。
Zookeeper
Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，提供數據同步服務。它的作用主要有配置管理、名字服務、分布式鎖和集群管理。配置管理指的是在一個地方修改了配置，那麼對這個地方的配置感興趣的所有的都可以獲得變更，省去了手動拷貝配置的繁瑣，還很好的保證了數據的可靠和一致性，同時它可以通過名字來獲取資源或者服務的地址等信息，可以監控集群中機器的變化，實現了類似於心跳機制的功能。
數據存儲
Hadoop作為一個開源的框架，專為離線和大規模數據分析而設計，HDFS作為其核心的存儲引擎，已被廣泛用於數據存儲。
HBase
HBase，是一個分布式的、面向列的開源資料庫，可以認為是hdfs的封裝，本質是數據存儲、NoSQL資料庫。HBase是一種Key/Value系統，部署在hdfs上，克服了hdfs在隨機讀寫這個方面的缺點，與hadoop一樣，Hbase目標主要依靠橫向擴展，通過不斷增加廉價的商用伺服器，來增加計算和存儲能力。
Phoenix
Phoenix，相當於一個Java中間件，幫助開發工程師能夠像使用JDBC訪問關系型資料庫一樣訪問NoSQL資料庫HBase。
Yarn
Yarn是一種Hadoop資源管理器，可為上層應用提供統一的資源管理和調度，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。Yarn由下面的幾大組件構成：一個全局的資源管理器ResourceManager、ResourceManager的每個節點代理NodeManager、表示每個應用的Application以及每一個ApplicationMaster擁有多個Container在NodeManager上運行。
Mesos
Mesos是一款開源的集群管理軟體，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等應用架構。
Redis
Redis是一種速度非常快的非關系資料庫，可以存儲鍵與5種不同類型的值之間的映射，可以將存儲在內存的鍵值對數據持久化到硬碟中，使用復制特性來擴展性能，還可以使用客戶端分片來擴展寫性能。
Atlas
Atlas是一個位於應用程序與MySQL之間的中間件。在後端DB看來，Atlas相當於連接它的客戶端，在前端應用看來，Atlas相當於一個DB。Atlas作為服務端與應用程序通訊，它實現了MySQL的客戶端和服務端協議，同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連接池。Atlas啟動後會創建多個線程，其中一個為主線程，其餘為工作線程。主線程負責監聽所有的客戶端連接請求，工作線程只監聽主線程的命令請求。
Ku
Ku是圍繞Hadoop生態圈建立的存儲引擎，Ku擁有和Hadoop生態圈共同的設計理念，它運行在普通的伺服器上、可分布式規模化部署、並且滿足工業界的高可用要求。其設計理念為fast analytics on fast data。作為一個開源的存儲引擎，可以同時提供低延遲的隨機讀寫和高效的數據分析能力。Ku不但提供了行級的插入、更新、刪除API，同時也提供了接近Parquet性能的批量掃描操作。使用同一份存儲，既可以進行隨機讀寫，也可以滿足數據分析的要求。Ku的應用場景很廣泛，比如可以進行實時的數據分析，用於數據可能會存在變化的時序數據應用等。
在數據存儲過程中，涉及到的數據表都是成千上百列，包含各種復雜的Query，推薦使用列式存儲方法，比如parquent,ORC等對數據進行壓縮。Parquet 可以支持靈活的壓縮選項，顯著減少磁碟上的存儲。
數據清洗
MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算，」Map(映射)」和」Rece(歸約)」，是它的主要思想。它極大的方便了編程人員在不會分布式並行編程的情況下，將自己的程序運行在分布式系統中。
隨著業務數據量的增多，需要進行訓練和清洗的數據會變得越來越復雜，這個時候就需要任務調度系統，比如oozie或者azkaban，對關鍵任務進行調度和監控。
Oozie
Oozie是用於Hadoop平台的一種工作流調度引擎，提供了RESTful API介面來接受用戶的提交請求(提交工作流作業)，當提交了workflow後，由工作流引擎負責workflow的執行以及狀態的轉換。用戶在HDFS上部署好作業(MR作業)，然後向Oozie提交Workflow，Oozie以非同步方式將作業(MR作業)提交給Hadoop。這也是為什麼當調用Oozie 的RESTful介面提交作業之後能立即返回一個JobId的原因，用戶程序不必等待作業執行完成(因為有些大作業可能會執行很久(幾個小時甚至幾天))。Oozie在後台以非同步方式，再將workflow對應的Action提交給hadoop執行。
Azkaban
Azkaban也是一種工作流的控制引擎，可以用來解決有多個hadoop或者spark等離線計算任務之間的依賴關系問題。azkaban主要是由三部分構成：Relational Database，Azkaban Web Server和Azkaban Executor Server。azkaban將大多數的狀態信息都保存在MySQL中，Azkaban Web Server提供了Web UI，是azkaban主要的管理者，包括project的管理、認證、調度以及對工作流執行過程中的監控等;Azkaban Executor Server用來調度工作流和任務，記錄工作流或者任務的日誌。
流計算任務的處理平台Sloth，是網易首個自研流計算平台，旨在解決公司內各產品日益增長的流計算需求。作為一個計算服務平台，其特點是易用、實時、可靠，為用戶節省技術方面(開發、運維)的投入，幫助用戶專注於解決產品本身的流計算需求
數據查詢分析
Hive
Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張資料庫表，並提供 HQL(Hive SQL)查詢功能。Hive本身不存儲和計算數據，它完全依賴於HDFS和MapRece。可以將Hive理解為一個客戶端工具，將SQL操作轉換為相應的MapRece jobs，然後在hadoop上面運行。Hive支持標準的SQL語法，免去了用戶編寫MapRece程序的過程，它的出現可以讓那些精通SQL技能、但是不熟悉MapRece 、編程能力較弱與不擅長Java語言的用戶能夠在HDFS大規模數據集上很方便地利用SQL 語言查詢、匯總、分析數據。
Hive是為大數據批量處理而生的，Hive的出現解決了傳統的關系型資料庫(MySql、Oracle)在大數據處理上的瓶頸 。Hive 將執行計劃分成map->shuffle->rece->map->shuffle->rece…的模型。如果一個Query會被編譯成多輪MapRece，則會有更多的寫中間結果。由於MapRece執行框架本身的特點，過多的中間過程會增加整個Query的執行時間。在Hive的運行過程中，用戶只需要創建表，導入數據，編寫SQL分析語句即可。剩下的過程由Hive框架自動的完成。
Impala
Impala是對Hive的一個補充，可以實現高效的SQL查詢。使用Impala來實現SQL on Hadoop，用來進行大數據實時查詢分析。通過熟悉的傳統關系型資料庫的SQL風格來操作大數據，同時數據也是可以存儲到HDFS和HBase中的。Impala沒有再使用緩慢的Hive+MapRece批處理，而是通過使用與商用並行關系資料庫中類似的分布式查詢引擎(由Query Planner、Query Coordinator和Query Exec Engine三部分組成)，可以直接從HDFS或HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。Impala將整個查詢分成一執行計劃樹，而不是一連串的MapRece任務，相比Hive沒了MapRece啟動時間。
Hive 適合於長時間的批處理查詢分析，而Impala適合於實時互動式SQL查詢，Impala給數據人員提供了快速實驗，驗證想法的大數據分析工具，可以先使用Hive進行數據轉換處理，之後使用Impala在Hive處理好後的數據集上進行快速的數據分析。總的來說：Impala把執行計劃表現為一棵完整的執行計劃樹，可以更自然地分發執行計劃到各個Impalad執行查詢，而不用像Hive那樣把它組合成管道型的map->rece模式，以此保證Impala有更好的並發性和避免不必要的中間sort與shuffle。但是Impala不支持UDF，能處理的問題有一定的限制。
Spark
Spark擁有Hadoop MapRece所具有的特點，它將Job中間輸出結果保存在內存中，從而不需要讀取HDFS。Spark 啟用了內存分布數據集，除了能夠提供互動式查詢外，它還可以優化迭代工作負載。Spark 是在 Scala 語言中實現的，它將 Scala 用作其應用程序框架。與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數據集。
Nutch
Nutch 是一個開源Java 實現的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具，包括全文搜索和Web爬蟲。
Solr
Solr用Java編寫、運行在Servlet容器(如Apache Tomcat或Jetty)的一個獨立的企業級搜索應用的全文搜索伺服器。它對外提供類似於Web-service的API介面，用戶可以通過http請求，向搜索引擎伺服器提交一定格式的XML文件，生成索引;也可以通過Http Get操作提出查找請求，並得到XML格式的返回結果。
Elasticsearch
Elasticsearch是一個開源的全文搜索引擎，基於Lucene的搜索伺服器，可以快速的儲存、搜索和分析海量的數據。設計用於雲計算中，能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。
還涉及到一些機器學習語言，比如，Mahout主要目標是創建一些可伸縮的機器學習演算法，供開發人員在Apache的許可下免費使用;深度學習框架Caffe以及使用數據流圖進行數值計算的開源軟體庫TensorFlow等，常用的機器學習演算法比如，貝葉斯、邏輯回歸、決策樹、神經網路、協同過濾等。
數據可視化
對接一些BI平台，將分析得到的數據進行可視化，用於指導決策服務。主流的BI平台比如，國外的敏捷BI Tableau、Qlikview、PowrerBI等，國內的SmallBI和新興的網易有數等。
在上面的每一個階段，保障數據的安全是不可忽視的問題。
基於網路身份認證的協議Kerberos，用來在非安全網路中，對個人通信以安全的手段進行身份認證，它允許某實體在非安全網路環境下通信，向另一個實體以一種安全的方式證明自己的身份。
控制許可權的ranger是一個Hadoop集群許可權框架，提供操作、監控、管理復雜的數據許可權，它提供一個集中的管理機制，管理基於yarn的Hadoop生態圈的所有數據許可權。可以對Hadoop生態的組件如Hive，Hbase進行細粒度的數據訪問控制。通過操作Ranger控制台，管理員可以輕松的通過配置策略來控制用戶訪問HDFS文件夾、HDFS文件、資料庫、表、欄位許可權。這些策略可以為不同的用戶和組來設置，同時許可權可與hadoop無縫對接。
簡單說有三大核心技術：拿數據，算數據，賣數據。
❷ GBase 8a MPP資料庫如何通過JDBC實現連接級的負載均衡
在使用JDBC實現連接GBase8aMPP資料庫時，由於GBase8aMPP資料庫是分布式資料庫，那麼在通過JDBC實現連接高可用的情況下，還希望能夠實現連接級別的負載均衡，需要如何實現呢？這就需要使用到GBase8aMPP資料庫JDBC驅動自帶的負載均衡功能。
如果我們希望把資料庫連接請求平均分布到各個節點的上話，我們可以使用JDBC 高可用負載均衡功能。
假設有如下場景，部署有一個GBase 集群，三個節點IP如下：
192.168.1.1；192.168.1.2；192.168.1.3；
String dbUrl =
「jdbc:gbase://192.168.1.1:5258/test?user=gbase&password=gbase20110531&failoverEnable=true&hostList=192.168.1.2,192.168.1.3&gclusterId=gcl1」;
failoverEnable：是否開啟高可用。
hostList：集群節點的IP列表，以逗號分隔，hostList中不需要包含url中的主IP。
gclusterId：不同的gclusterId會創建不同的列表，用於區分被連接的集群，要求必須以a-z任意字元開頭的可以包含a-z、0-9所有字元長度為最大為20的字元串。
高可用負載均衡功能是將url中的IP和hostList中的IP放入一個列表中，當應用獲取連接的時候，JDBC會從列表表中順序獲取IP創建連接，每個IP獲取一個連接，從而實現連接的負載均衡，同時，當列表中的IP不可連接時，JDBC會順序獲取列表中的下一個IP，獲取連接，如果無可用連接時，將拋出異常。也就是說高可用負載均衡功能既實現了連接負載均衡功能，也實現了高可用功能。
❸ MPP DB 是 大數據實時分析系統 未來的選擇嗎
大數據領域，實時分析系統（在線查詢）是最常見的一種場景，前面寫了一個《 實時分析系統 (HIVE/HBASE/IMPALA) 淺析 》討論業界當前常見的方案。互聯網公司用得比較多是 HIVE/HBASE ，如騰訊基於 HIVE 深度定製改造，改名為 TDW ，小米等公司選用 HBASE 等。關於 HIVE/HBASE/IMPALA 介紹等可以看我前面的文章。
當前在實時分析系統中，最難的是多維度復雜查詢，目前沒有一個很好的解決方案，這兩天和人討論到 MPP DB （分布式資料庫，以 Greenplum 為最典型代表）。如果從性能來講， MPP DB 在多維復雜查詢性能確實要好於 HIVE/HBASE/IMPALA 等，因此有不少聲音認為， MPP DB 是適合這種場景的未來的解決方案。 MPP DB 看似對多維度復雜查詢性能較好，但是同時有兩個致命的缺點，大家選型的時候不得不考慮：
1、 擴展性：
MPP DB 都號稱都能擴展到 1000 個節點以上，實際在應用過程中，就我目前從公開資料看到的不超過 100 個節點，如支付寶中用 Greenplum 來做財務數據分析的最大一個集群 60 多台機器。另外和 Greenplum 公司交流，在廣東移動最大的用來做數據存儲的，也就 100 台以內。這和 hadoop 動不動 4,5 千個節點一個節點集群簡直不在一個數量級上。
為什麼 MPP DB 擴展性不好？
有很多原因，有產品成熟度，也有應用廣度的問題，但是最根本的還是架構本身的問題。講到架構這里就要先講下 CAP 原則：
Consistency( 一致性 ), 數據一致更新，所有數據變動都是同步的
Availability( 可用性 ), 好的響應性能
Partition tolerance( 分區容錯性 ) 可靠性
定理：任何 分布式 系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美 分布式 系統，而是應該進行取捨。
MPP DB 還是基於原 DB 擴展而來， DB 裡面天然追求一致性（ Consistency ），必然帶來分區容錯性較差。集群規模變得太大，業務數據太多時， MPP DB 的元數據管理就完全是一個災難。元數據巨大無比，一旦出錯很難恢復，動不動導致毀庫。
所以 MPP DB 要在擴展性上有質的提示，要對元數據，以及數據存儲有架構上的突破，降低對一致性的要求，這樣擴展性才能提升，否則的話很難相信一個 MPP DB 資料庫是可以容易擴展的。
2、 並發的支持：
一個查詢系統，設計出來就是提供人用的，所以能支持的同時並發越高越好。MPP DB 核心原理是一 個大的查詢通過分析為一一個子查詢，分布到底層的執行，最後再合並結果，說白了就是通過多線程並發來暴力 SCAN 來實現高速。 這種暴力SCAN的方法，對單個查詢來說，動用了整個系統的能力，單個查詢比較快，但同時帶來用力過猛的問題，整個系統能支持的並發必然不高，從目前實際使用的經驗來說，也就支持50～100的並發能力。
當前HBASE/IMPALA應對復雜查詢時，也是通過全盤SCAN的方法來實現的，這種場景下，硬碟數量越多越好，轉速越快越好。HBASE為什麼號稱支持上千並發，這也是在特定的場景下（查詢時帶用戶標示，即帶row key)才能實現的，復雜查詢場景下，什麼系統都歇菜。
所以MPP DB應用場景已經非常明顯了，適合小集群（100以內），低並發的（50左右）的場景。MPP DB未來是不是趨勢，我不知道，但是至少目前來看，用MPP DB來應對大數據的實時分析系統是非常吃力的。
❹ GBase 8a MPP Cluster資料庫的數據分片是什麼概念如何理解
這種概念上的含混不清之所以還在流傳，主要是因為不懂技術的人而喜歡這些概念的大有人在，所以也並不在意要去澄清概念。「既然分布式資料庫是MPP架構，那麼MPP架構就等於分布式資料庫應該也沒什麼問題吧。」於是大家就都不在意了。
比如，ShardingSphere轉向可插拔架構後，其核心流程里已經沒有分片功能了，分片會作為可插拔能力的一部分接入到服務中。對於資料庫中間件來說，幾乎屬於產品重定義。與許多人對資料庫中間件的固有認知相悖，因為在許多人的理解中，資料庫中間件不就是為了分庫分表而存在的嗎？
理解關系資料庫中的相關概念、關系模型及其三要素；理解關系的性質及類型；理解完整性規則在關系資料庫中的作用；理解關系代數運算，掌握傳統的集合運算與專門的關系運算；理解並掌握關系演算。
很多人在對比兩者時，其實並不知道MPP的含義究竟是什麼、兩者的可比性到底在哪裡。實際上，當人們在對比兩者時，與其說是對比架構，不如說是對比產品。雖然MPP的原意是「大規模並行處理」，但由於一些歷史原因，現在當人們說到MPP架構時，它們實際上指代的是「分布式資料庫」，而Hadoop架構指的則是以Hadoop項目為基礎的一系列分布式計算和存儲框架。不過由於MPP的字面意思，現實中還是經常有人糾結兩者到底有什麼聯系和區別，兩者到底是不是同一個層面的概念。
❺ mpp資料庫適合哪些應用場景
MPP資料庫主要適合查詢統計、分析研判等大數據處理場景，主要特點是整體架構呈現純扁平化，不存在單點性能瓶頸，基於開放式標准X86 PC伺服器構建，採用分布式架構設計，靈活實現按需部署，具備靈活的系統伸縮性，支持系統的縱向擴展和橫向擴展。
國內的產品主要是南大通用的GBase 8a MPP Cluster，是面向大數據、雲計算場景自主研發的大規模並行資料庫集群產品，在海量數據高速處理的場景下具有高性能、低成本、高可靠、易使用等諸多優勢，國外的如GreenPlum、Vertica等。
❻ 從站點到平台——探討服務端高並發分布式架構演進
本文以淘寶作為例子，介紹從一百個並發到千萬級並發情況下服務端的架構的演進過程，同時列舉出每個演進階段會遇到的相關技術，讓大家對架構的演進有一個整體的認知，文章最後匯總了一些架構設計的原則。
在介紹架構之前，為了避免部分讀者對架構設計中的一些概念不了解，下面對幾個最基礎的概念進行介紹：
3.1 單機架構
以淘寶作為例子。在網站最初時，應用數量與用戶數都較少，可以把Tomcat和資料庫部署在同一台伺服器上。瀏覽器往www.taobao.com發起請求時，首先經過DNS伺服器（域名系統）把域名轉換為實際IP地址10.102.4.1，瀏覽器轉而訪問該IP對應的Tomcat。
3.2 第一次演進：Tomcat與資料庫分開部署
Tomcat和資料庫分別獨占伺服器資源，顯著提高兩者各自性能。
3.3 第二次演進：引入本地緩存和分布式緩存
在Tomcat同伺服器上或同JVM中增加本地緩存，並在外部增加分布式緩存，緩存熱門商品信息或熱門商品的html頁面等。通過緩存能把絕大多數請求在讀寫資料庫前攔截掉，大大降低資料庫壓力。其中涉及的技術包括：使用memcached作為本地緩存，使用Redis作為分布式緩存，還會涉及緩存一致性、緩存穿透/擊穿、緩存雪崩、熱點數據集中失效等問題。
3.4 第三次演進：引入反向代理實現負載均衡
在多台伺服器上分別部署Tomcat，使用反向代理軟體（Nginx）把請求均勻分發到每個Tomcat中。此處假設Tomcat最多支持100個並發，Nginx最多支持50000個並發，那麼理論上Nginx把請求分發到500個Tomcat上，就能抗住50000個並發。其中涉及的技術包括：Nginx、HAProxy，兩者都是工作在網路第七層的反向代理軟體，主要支持http協議，還會涉及session共享、文件上傳下載的問題。
3.5 第四次演進：資料庫讀寫分離
把資料庫劃分為讀庫和寫庫，讀庫可以有多個，通過同步機制把寫庫的數據同步到讀庫，對於需要查詢最新寫入數據場景，可通過在緩存中多寫一份，通過緩存獲得最新數據。其中涉及的技術包括：Mycat，它是資料庫中間件，可通過它來組織資料庫的分離讀寫和分庫分表，客戶端通過它來訪問下層資料庫，還會涉及數據同步，數據一致性的問題。
3.6 第五次演進：資料庫按業務分庫
把不同業務的數據保存到不同的資料庫中，使業務之間的資源競爭降低，對於訪問量大的業務，可以部署更多的伺服器來支撐。這樣同時導致跨業務的表無法直接做關聯分析，需要通過其他途徑來解決，但這不是本文討論的重點，有興趣的可以自行搜索解決方案。
3.7 第六次演進：把大表拆分為小表
比如針對評論數據，可按照商品ID進行hash，路由到對應的表中存儲；針對支付記錄，可按照小時創建表，每個小時表繼續拆分為小表，使用用戶ID或記錄編號來路由數據。只要實時操作的表數據量足夠小，請求能夠足夠均勻的分發到多台伺服器上的小表，那資料庫就能通過水平擴展的方式來提高性能。其中前面提到的Mycat也支持在大表拆分為小表情況下的訪問控制。
這種做法顯著的增加了資料庫運維的難度，對DBA的要求較高。資料庫設計到這種結構時，已經可以稱為分布式資料庫，但是這只是一個邏輯的資料庫整體，資料庫里不同的組成部分是由不同的組件單獨來實現的，如分庫分表的管理和請求分發，由Mycat實現，SQL的解析由單機的資料庫實現，讀寫分離可能由網關和消息隊列來實現，查詢結果的匯總可能由資料庫介面層來實現等等，這種架構其實是MPP（大規模並行處理）架構的一類實現。
目前開源和商用都已經有不少MPP資料庫，開源中比較流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆 科技 的雪球DB、華為的LibrA等等，不同的MPP資料庫的側重點也不一樣，如TiDB更側重於分布式OLTP場景，Greenplum更側重於分布式OLAP場景，這些MPP資料庫基本都提供了類似Postgresql、Oracle、MySQL那樣的SQL標准支持能力，能把一個查詢解析為分布式的執行計劃分發到每台機器上並行執行，最終由資料庫本身匯總數據進行返回，也提供了諸如許可權管理、分庫分表、事務、數據副本等能力，並且大多能夠支持100個節點以上的集群，大大降低了資料庫運維的成本，並且使資料庫也能夠實現水平擴展。
3.8 第七次演進：使用LVS或F5來使多個Nginx負載均衡
由於瓶頸在Nginx，因此無法通過兩層的Nginx來實現多個Nginx的負載均衡。圖中的LVS和F5是工作在網路第四層的負載均衡解決方案，其中LVS是軟體，運行在操作系統內核態，可對TCP請求或更高層級的網路協議進行轉發，因此支持的協議更豐富，並且性能也遠高於Nginx，可假設單機的LVS可支持幾十萬個並發的請求轉發；F5是一種負載均衡硬體，與LVS提供的能力類似，性能比LVS更高，但價格昂貴。由於LVS是單機版的軟體，若LVS所在伺服器宕機則會導致整個後端系統都無法訪問，因此需要有備用節點。可使用keepalived軟體模擬出虛擬IP，然後把虛擬IP綁定到多台LVS伺服器上，瀏覽器訪問虛擬IP時，會被路由器重定向到真實的LVS伺服器，當主LVS伺服器宕機時，keepalived軟體會自動更新路由器中的路由表，把虛擬IP重定向到另外一台正常的LVS伺服器，從而達到LVS伺服器高可用的效果。
此處需要注意的是，上圖中從Nginx層到Tomcat層這樣畫並不代表全部Nginx都轉發請求到全部的Tomcat，在實際使用時，可能會是幾個Nginx下面接一部分的Tomcat，這些Nginx之間通過keepalived實現高可用，其他的Nginx接另外的Tomcat，這樣可接入的Tomcat數量就能成倍的增加。
3.9 第八次演進：通過DNS輪詢實現機房間的負載均衡
在DNS伺服器中可配置一個域名對應多個IP地址，每個IP地址對應到不同的機房裡的虛擬IP。當用戶訪問www.taobao.com時，DNS伺服器會使用輪詢策略或其他策略，來選擇某個IP供用戶訪問。此方式能實現機房間的負載均衡，至此，系統可做到機房級別的水平擴展，千萬級到億級的並發量都可通過增加機房來解決，系統入口處的請求並發量不再是問題。
3.10 第九次演進：引入NoSQL資料庫和搜索引擎等技術
當資料庫中的數據多到一定規模時，資料庫就不適用於復雜的查詢了，往往只能滿足普通查詢的場景。對於統計報表場景，在數據量大時不一定能跑出結果，而且在跑復雜查詢時會導致其他查詢變慢，對於全文檢索、可變數據結構等場景，資料庫天生不適用。因此需要針對特定的場景，引入合適的解決方案。如對於海量文件存儲，可通過分布式文件系統HDFS解決，對於key value類型的數據，可通過HBase和Redis等方案解決，對於全文檢索場景，可通過搜索引擎如ElasticSearch解決，對於多維分析場景，可通過Kylin或Druid等方案解決。
當然，引入更多組件同時會提高系統的復雜度，不同的組件保存的數據需要同步，需要考慮一致性的問題，需要有更多的運維手段來管理這些組件等。
3.11 第十次演進：大應用拆分為小應用
按照業務板塊來劃分應用代碼，使單個應用的職責更清晰，相互之間可以做到獨立升級迭代。這時候應用之間可能會涉及到一些公共配置，可以通過分布式配置中心Zookeeper來解決。
3.12 第十一次演進：復用的功能抽離成微服務
如用戶管理、訂單、支付、鑒權等功能在多個應用中都存在，那麼可以把這些功能的代碼單獨抽取出來形成一個單獨的服務來管理，這樣的服務就是所謂的微服務，應用和服務之間通過HTTP、TCP或RPC請求等多種方式來訪問公共服務，每個單獨的服務都可以由單獨的團隊來管理。此外，可以通過Dubbo、SpringCloud等框架實現服務治理、限流、熔斷、降級等功能，提高服務的穩定性和可用性。
3.13 第十二次演進：引入企業服務匯流排ESB屏蔽服務介面的訪問差異
通過ESB統一進行訪問協議轉換，應用統一通過ESB來訪問後端服務，服務與服務之間也通過ESB來相互調用，以此降低系統的耦合程度。這種單個應用拆分為多個應用，公共服務單獨抽取出來來管理，並使用企業消息匯流排來解除服務之間耦合問題的架構，就是所謂的SOA（面向服務）架構，這種架構與微服務架構容易混淆，因為表現形式十分相似。個人理解，微服務架構更多是指把系統里的公共服務抽取出來單獨運維管理的思想，而SOA架構則是指一種拆分服務並使服務介面訪問變得統一的架構思想，SOA架構中包含了微服務的思想。
3.14 第十三次演進：引入容器化技術實現運行環境隔離與動態服務管理
目前最流行的容器化技術是Docker，最流行的容器管理服務是Kubernetes(K8S)，應用/服務可以打包為Docker鏡像，通過K8S來動態分發和部署鏡像。Docker鏡像可理解為一個能運行你的應用/服務的最小的操作系統，裡面放著應用/服務的運行代碼，運行環境根據實際的需要設置好。把整個「操作系統」打包為一個鏡像後，就可以分發到需要部署相關服務的機器上，直接啟動Docker鏡像就可以把服務起起來，使服務的部署和運維變得簡單。
在大促的之前，可以在現有的機器集群上劃分出伺服器來啟動Docker鏡像，增強服務的性能，大促過後就可以關閉鏡像，對機器上的其他服務不造成影響（在3.14節之前，服務運行在新增機器上需要修改系統配置來適配服務，這會導致機器上其他服務需要的運行環境被破壞）。
3.15 第十四次演進：以雲平台承載系統
系統可部署到公有雲上，利用公有雲的海量機器資源，解決動態硬體資源的問題，在大促的時間段里，在雲平台中臨時申請更多的資源，結合Docker和K8S來快速部署服務，在大促結束後釋放資源，真正做到按需付費，資源利用率大大提高，同時大大降低了運維成本。
所謂的雲平台，就是把海量機器資源，通過統一的資源管理，抽象為一個資源整體，在之上可按需動態申請硬體資源（如CPU、內存、網路等），並且之上提供通用的操作系統，提供常用的技術組件（如Hadoop技術棧，MPP資料庫等）供用戶使用，甚至提供開發好的應用，用戶不需要關系應用內部使用了什麼技術，就能夠解決需求（如音視頻轉碼服務、郵件服務、個人博客等）。在雲平台中會涉及如下幾個概念：
❼ mpp架構資料庫有哪些
MPP的代表產品有：Vertica/Redshift(Paracel，被Amazon買買下了源碼的license後變成Redshift)/Greenplum。仔細觀察不難發現，這三者其實有非常很多相同點：
1.全部基於PostgreSQL
2.都是基於列的存儲(Columnar Storage)
3.操作都是以Scan為基礎，依賴Compression來提供性能的優化