❶ 國內做分布式資料庫開發的現狀如何
應該說，現在是國產分布式資料庫發展的利好時期。在討論發展前景前，首先要先看看分布式資料庫的發展方向。
大家把傳統關系型資料庫稱作oldsql，給人感覺要被淘汰似的。但其實數據量不是很大或者事務處理的場景夏，關系型資料庫的還是占優的。
關系型資料庫的主要問題在於：
性能瓶頸，
單一模型（關系模型），只適合OLTP
應對業務的靈活性不夠，
彈性擴充能力不夠，
兩地三中心和雙活等問題上不足。
隨著互聯網和手機的飛速發展，無論從用戶規模、使用頻率、還是場景多樣性都使得這些問題浮出水面。其實Oracle在92年就開始嘗試轉向分布式，還當時引起了業界的巨大爭論，最後失敗。更何況過去CPU、內存、存儲、帶寬的高成本導致分布式資料庫的性價比並不高，只能停留在學術階段，限制了分布式的發展。
新分布式資料庫首先是要避免和傳統關系型資料庫的競爭，這是明智的選擇，能夠輕裝上陣。因此從幾個方面入手，應對海量數據處理、分析、緩存、流式處理、開發模式等等。相對應列式，KV，Document等多種存儲數據結構。
所有這些都被稱為NoSQL資料庫，放棄ACID和事務能力還換取性能。然而，NoSQL又收到了大量的批評反對意見，主要是說把資料庫應該處理的問題交還給了開發是種發展的倒退。這些問題包括，索引、版本、SQL支持、事務支持等等。市場上超過90%的開發員都需要SQL，而且SQL也是非常有效和成熟。於是大家無論底層是什麼存儲結構又開始支持SQL，形成了NewSQL。
這里插一句題外話，在矽谷已經不再用SQL、NoSQL、NewSQL來劃分資料庫了。理由很簡單，SQL是一種語言，從來沒有SQL資料庫的說法，自然也不應該有NoSQL資料庫的說法。NewSQL資料庫就更不合理，用的SQL並非什麼「New「的新東西。所以專業上用關系型和非關系型資料庫來劃分，分布式資料庫主要都是非關系型資料庫。
回過頭來看國內分布式資料庫市場需求，中小企業不滿足Mysql的性能，分庫分表又很難搞，也不徹底；大型企業被Oracle等壟斷支付高額成本，而且又不解決實際碰到的瓶頸問題。因此，用戶都在尋找新的解決方案。小型用戶、雲計算的用
戶、大型企業都需要對應的分布式資料庫產品。
再加上國產自主和去IOE浪潮，更加推動了國產分布式資料庫的發展利好。值得注意的是，資料庫研發是個嚴肅的事情，沒法短平快。
❷ 技術選型 - OLAP大數據技術哪家強
Lambda架構的核心理念是「流批一體化」，因為隨著機器性能和數據框架的不斷完善，用戶其實不關心底層是如何運行的，批處理也好，流式處理也罷，能按照統一的模型返回結果就可以了，這就是Lambda架構誕生的原因。現在很多應用，例如Spark和Flink，都支持這種結構，也就是數據進入平台後，可以選擇批處理運行，也可以選擇流式處理運行，但不管怎樣，一致性都是相同的。
Kylin
Kylin的主要特點是預計算，提前計算好各個cube，這樣的優點是查詢快速，秒級延遲；缺點也非常明顯，靈活性不足，無法做一些 探索 式的，關聯性的數據分析。
適合的場景也是比較固定的，場景清晰的地方。
ClickHouse
Clickhouse由俄羅斯yandex公司開發。專為在線數據分析而設計。
Clickhouse最大的特點首先是快 ，為了快採用了列式儲存，列式儲存更好的支持壓縮，壓縮後的數據傳輸量變小，所以更快；同時支持分片，支持分布式執行，支持SQL。
ClickHouse很輕量級，支持數據壓縮和最終數據一致性，其數據量級在PB級別。
另外Clickhouse不是為關聯分析而生，所以多表關聯支持的不太好。
同樣Clickhouse不能修改或者刪除數據，僅能用於批量刪除或修改。沒有完整的事務支持，不支持二級索引等等，缺點也非常明顯。
與Kylin相比ClickHouse更加的靈活，sql支持的更好，但是相比Kylin，ClickHouse不支持大並發，也就是不能很多訪問同時在線。
總之ClickHouse用於在線數據分析，支持功能簡單。CPU 利用率高，速度極快。最好的場景用於行為統計分析。
Hive
Hive這個工具，大家一定很熟悉，大數據倉庫的首選工具。可以將結構化的數據文件映射為一張資料庫表，並提供完整的sql查詢功能。
主要功能是可以將sql語句轉換為相對應的MapRece任務進行運行，這樣可能處理海量的數據批量，
Hive與HDFS結合緊密，在大數據開始初期，提供一種直接使用sql就能訪問HDFS的方案，擺脫了寫MapRece任務的方式，極大的降低了大數據的門檻。
當然Hive的缺點非常明顯，定義的是分鍾級別的查詢延遲，估計都是在比較理想的情況。 但是作為數據倉庫的每日批量工具，的確是一個穩定合格的產品。
Presto
Presto極大的改進了Hive的查詢速度，而且Presto 本身並不存儲數據，但是可以接入多種數據源，並且支持跨數據源的級聯查詢，支持包括復雜查詢、聚合、連接等等。
Presto沒有使用MapRece，它是通過一個定製的查詢和執行引擎來完成的。它的所有的查詢處理是在內存中，這也是它的性能很高的一個主要原因。
Presto由於是基於內存的，缺點可能是多張大表關聯操作時易引起內存溢出錯誤。
另外Presto不支持OLTP的場景，所以不要把Presto當做資料庫來使用。
Presto相比ClickHouse優點主要是多表join效果好。相比ClickHouse的支持功能簡單，場景支持單一，Presto支持復雜的查詢，應用范圍更廣。
Impala
Impala是Cloudera 公司推出，提供對 HDFS、Hbase 數據的高性能、低延遲的互動式 SQL 查詢功能。
Impala 使用 Hive的元數據, 完全在內存中計算。是CDH 平台首選的 PB 級大數據實時查詢分析引擎。
Impala 的缺點也很明顯，首先嚴重依賴Hive，而且穩定性也稍差，元數據需要單獨的mysql/pgsql來存儲，對數據源的支持比較少，很多nosql是不支持的。但是，估計是cloudera的國內市場推廣做的不錯，Impala在國內的市場不錯。
SparkSQL
SparkSQL的前身是Shark，它將 SQL 查詢與 Spark 程序無縫集成，可以將結構化數據作為 Spark 的 RDD 進行查詢。
SparkSQL後續不再受限於Hive，只是兼容Hive。
SparkSQL提供了sql訪問和API訪問的介面。
支持訪問各式各樣的數據源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。
Drill
Drill好像國內使用的很少，根據定義，Drill是一個低延遲的分布式海量數據互動式查詢引擎，支持多種數據源，包括hadoop，NoSQL存儲等等。
除了支持多種的數據源，Drill跟BI工具集成比較好。
Druid
Druid是專為海量數據集上的做高性能 OLAP而設計的數據存儲和分析系統。
Druid 的架構是 Lambda 架構，分成實時層和批處理層。
Druid的核心設計結合了數據倉庫，時間序列資料庫和搜索系統的思想，以創建一個統一的系統，用於針對各種用例的實時分析。Druid將這三個系統中每個系統的關鍵特徵合並到其接收層，存儲格式，查詢層和核心體系結構中。
目前 Druid 的去重都是非精確的，Druid 適合處理星型模型的數據，不支持關聯操作。也不支持數據的更新。
Druid最大的優點還是支持實時與查詢功能，解約了很多開發工作。
Ku
ku是一套完全獨立的分布式存儲引擎，很多設計概念上借鑒了HBase，但是又跟HBase不同，不需要HDFS，通過raft做數據復制；分片策略支持keyrange和hash等多種。
數據格式在parquet基礎上做了些修改，支持二級索引，更像一個列式存儲，而不是HBase schema-free的kv方式。
ku也是cloudera主導的項目，跟Impala結合比較好，通過impala可以支持update操作。
ku相對於原有parquet和ORC格式主要還是做增量更新的。
Hbase
Hbase使用的很廣,更多的是作為一個KV資料庫來使用，查詢的速度很快。
Hawq
Hawq是一個Hadoop原生大規模並行SQL分析引擎，Hawq採用 MPP 架構，改進了針對 Hadoop 的基於成本的查詢優化器。
除了能高效處理本身的內部數據，還可通過 PXF 訪問 HDFS、Hive、HBase、JSON 等外部數據源。HAWQ全面兼容 SQL 標准，還可用 SQL 完成簡單的數據挖掘和機器學習。無論是功能特性，還是性能表現，HAWQ 都比較適用於構建 Hadoop 分析型數據倉庫應用。
❸ OLTP和OLAP有何區別
1、適用人員不同：OLTP主要供基層人員使用，進行一線業務操作。OLAP則是探索並挖掘數據價值，作為企業高層進行決策的參考。
2、面向內容不同：OLTP面向應用，OLAP面向主題；
4、數據特點不同：OLTP的數據特點是當前的、最新的、細節的, 二維的、分立的；而OLTP則是歷史的, 聚集的, 多維的，集成的, 統一的；
5、存取能力不同：OLTP可以讀/寫數十條記錄，而OLAP則可以讀上百萬條記錄；
6、工作事件的復雜度不同：OLTP執行的是簡單的事務，而OLAP執行的是復雜任務；
7、可承載用戶數量不同：OLTP的可承載用戶數量為上千個，而OLAP則是上百萬個；
8、DB大小不同：OLTP的DB 大小為100GB，而OLAP則可以達到100TB；
9、執行時間要求不同：OLTP具有實時性，OLAP對時間的要求不嚴格。
(3)oltp列式存儲好嗎擴展閱讀：
OLTP與OLAP的實際應用
OLAP工具是針對特定問題的聯機數據訪問與分析。它通過多維的方式對數據進行分析、查詢和報表。維是人們觀察數據的特定角度。
例如，一個企業在考慮產品的銷售情況時，通常從時間、地區和產品的不同角度來深入觀察產品的銷售情況。這里的時間、地區和產品就是維。
這些維的不同組合和所考察的度量指標構成的多維數組則是OLAP分析的基礎，可形式化表示為（維1，維2，……，維n，度量指標），如（地區、時間、產品、銷售額）。
多維分析是指對以多維形式組織起來的數據採取切片（Slice）、切塊（Dice）、鑽取（Drill-down和Roll-up）、旋轉（Pivot）等各種分析動作，以求剖析數據，使用戶能從多個角度、多側面地觀察資料庫中的數據，從而深入理解包含在數據中的信息。
應用OLTP，就必須重新定義OLTP在企業信息化體系結構中的地位。OLTP不再只是一套能處理訂單的老式應用程序。對典型的OLTP系統處理的大規模數據流更新進行同時分析，這種情況很罕見，因為一般認為這不是OLTP的目的。
數據倉庫更新固有的延遲阻礙著對最新數據的近實時分析。組織如果要對於數據的變化迅速作出反應，IT部門就必須讓OLTP產生比以往更大的作用。
參考資料來源：網路-OLTP
參考資料來源：網路-聯機分析處理
❹ Raid級別有哪些
RAID分為6個級別，不同的級別應滿足應用程序的需求。
RAID 0
特點：磁碟在兩個以上的磁碟驅動器中傳送數據，與I/O同時運行，提高I/O性能。若n代表磁碟數量，則每個磁碟驅動器中有n分之一的數據。
應用：讀寫性能較高。但是，沒有數據冗餘。RAID 0本身僅適用於對數據訪問具有容錯能力的應用程序，以及能通過其它途徑重新形成的數據。
RAID 1
特點：具有磁碟鏡像，能夠保護數據，讀性能有所提高。RAID 1將數據在兩個以上的磁碟中形成鏡像，所以磁碟之間非常相似。RAID 1利用n+n的保護模式，從而需要兩倍的驅動器數量。
應用：讀操作密集型的OLTP和其它事務數據具有較高性能和可靠性。其它應用程序也能從RAID 1中獲益，包括郵件、操作系統、應用程序文件和隨機讀取環境。
RAID 0+1
特點：對數據進行分條和鏡像，使用n+n個驅動器，性能（分條）和可靠性（鏡像）較高。一個磁碟驅動器發生故障，不會影響性能和可靠性，而在RAID 0中，驅動器故障會影響性能和可靠性。另外，磁碟分條技術可以提高性能。
應用：OLTP和I/O密集型應用程序需要很高的性能和可靠性。這些性能包括事務日誌、日誌文件、數據索引等，其成本以每個I/O的花費來計算，而不是以每個存儲單元的花費計算。
RAID 1+0 (RAID 10)
特點：與RAID 0+1相似，對數據進行分條和鏡像，使用n+n個驅動器，性能（分條）和可靠性（鏡像）較高。不同之處在於RAID 10對所有磁碟進行集體分條，然後實現鏡像功能。
應用：OLTP和I/O密集型應用程序需要很高的性能和可靠性。這些性能包括事務日誌、日誌文件、數據索引等，其成本以每個I/O的花費來計算，而不是以每個存儲單元的花費計算。
RAID 3
特點：在位元組層面進行奇偶校驗和分條，具有獨立的專用磁碟驅動器，根據所需的驅動器數量，利用n+1的方式存儲校驗信息。
應用：為視頻圖像、地球物理學、生命科學和其它順序處理的應用程序提供良好性能。但是，RAID 3不能很好地適用於那些對多用戶或I/O流進行並發操作的應用程序。
RAID 4
特點：與RAID 3相同，但是提供塊級的奇偶校驗保護模式。
應用：利用讀寫緩存，能很好地適應文件服務環境。
RAID 5
特點：利用n+1的模式提供磁碟分條和旋轉奇偶校驗保護模式，為多用戶和I/O流並發操作提供良好的可靠性，具有很好的讀操作性能。利用空閑的磁碟驅動器，重新構建（磁碟重建）數據，防止重建後數據再次遭破壞。
應用：減少所需的磁碟數量，提供良好的可靠性和讀操作性能，如果不利用寫入緩存，寫操作性能受到一定影響。RAID 5適用的應用程序包括關系型數據、讀密集型資料庫表格、文件共享和Web應用程序。
RAID 6
特點：利用雙奇偶校驗模式，對磁碟進行分條和旋轉校驗，旨在降低磁碟重建過程對數據可靠性的影響，尤其是使用大容量光纖通道和SATA磁碟驅動器時更是如此。RAID 6和其它多驅動器校驗模式的問題在於，在寫入數據或重建出現故障的磁碟驅動器時，需要校驗奇偶，這時性能會受到影響。
應用：總體來說，如果你想實現高性能的讀寫操作，就要利用小型磁碟驅動器，避免使用RAID 6。另一方面，如果你想存儲大量數據，而存儲點有可能需要重建，正確配置RAID 5和RAID 6，就能滿足應用程序的需求。
❺ 資料庫與數據倉庫的本質差別是什麼
資料庫與數據倉庫的本質差別如下：
1、邏輯層面/概念層面：資料庫和數據倉庫其實是一樣的或者及其相似的，都是通過某個資料庫軟體，基於某種數據模型來組織、管理數據。但是，資料庫通常更關注業務交易處理（OLTP），而數據倉庫更關注數據分析層面（OLAP），由此產生的資料庫模型上也會有很大的差異。
2、資料庫通常追求交易的速度，交易完整性，數據的一致性等，在資料庫模型上主要遵從範式模型（1NF，2NF，3NF等），從而盡可能減少數據冗餘，保證引用完整性；而數據倉庫強調數據分析的效率，復雜查詢的速度，數據之間的相關性分析，所以在資料庫模型上，數據倉庫喜歡使用多維模型，從而提高數據分析的效率。
3、產品實現層面：資料庫和數據倉庫軟體是有些不同的，資料庫通常使用行式存儲，如SAP ASE，Oracle, Microsoft SQL Server，而數據倉庫傾向使用列式存儲，如SAP IQ，SAP HANA。
❻ 資料庫與數據倉庫的本質區別是什麼
1、存放值區別：
資料庫只存放在當前值，數據倉庫存放歷史值；
2、數據變化區別：
資料庫內數據是動態變化的，只要有業務發生，數據就會被更新，而數據倉庫則是靜態的歷史數據，只能定期添加、刷新；
3、數據結構區別：
資料庫中的數據結構比較復雜，有各種結構以適合業務處理系統的需要，而數據倉庫中的數據結構則相對簡單；
4、訪問頻率不同：
資料庫中數據訪問頻率較高，但訪問量較少，而數據倉庫的訪問頻率低但訪問量卻很高；
5、目標人群區別：
資料庫中數據的目標是面向業務處理人員的，為業務處理人員提供信息處理的支持，而數據倉庫則是面向高層管理人員的，為其提供決策支持；