OLTP和OLAP技術(shù)融合架構(gòu)實(shí)踐課件

1、OLTP和OLAP技術(shù)融合架構(gòu)實(shí)踐技術(shù)創(chuàng)新，變革未來(lái)第1頁(yè)，共23頁(yè)。目錄一、OLTP與OLAP 技術(shù)介紹二、融合技術(shù)選型三、Binlog+Kudu+impala最佳實(shí)踐第2頁(yè)，共23頁(yè)。1.1 OLTP 背景介紹聯(lián)機(jī)事務(wù)處理OLTP（on-line transaction processing）也稱(chēng)為面向交易的處理過(guò)程，其基本特征是前臺(tái)接收的用戶(hù)數(shù)據(jù)可以立即傳送到計(jì)算中心進(jìn)行處理，并在很短的時(shí)間內(nèi)給出處理結(jié)果，是對(duì)用戶(hù)操作快速響 應(yīng)的方式之一。1關(guān)鍵詞：數(shù)據(jù)量少、面向應(yīng)用、并行事務(wù)處理、分庫(kù)分表、讀寫(xiě)分離、Cache技術(shù)、B-Tree索引實(shí)時(shí)性要求高、數(shù)據(jù)庫(kù)作為載體、SQL交互1 OLTP概

2、念引用自百度百科 /item/OLTP/5019563第3頁(yè)，共23頁(yè)。1.2 OLAP 背景介紹聯(lián)機(jī)實(shí)時(shí)分析OLAP (OnlineAnalytical Processing,）聯(lián)機(jī)分析處理OLAP是一種軟件技術(shù)，它使分析人員能夠迅速、一致、交互 地從各個(gè)方面觀察信息，以達(dá)到深入理解數(shù)據(jù)的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多維信息的快速分 析的特征。2關(guān)鍵詞：數(shù)據(jù)海量、追加操作為主、數(shù)據(jù)分區(qū)、切片和切塊、雪花模型鉆取、旋轉(zhuǎn)、投影、數(shù)據(jù)倉(cāng)庫(kù)、MDX、實(shí)時(shí)性要求低2 OLAP概念引用自百度百科

3、 /item/聯(lián)機(jī)分析處理?fromtitle=OLAP第4頁(yè)，共23頁(yè)。1.3 兩者面向場(chǎng)景的分析-HTAP3需求：一份數(shù)據(jù)存儲(chǔ)用于OLTP和OLAP處理。1）數(shù)據(jù)實(shí)時(shí)可見(jiàn) 2）支持多維度低延遲查詢(xún)交付 3）低成本通用的解決方法：數(shù)據(jù)Sharding：實(shí)例間share nothing，便于橫向水平擴(kuò)展 數(shù)據(jù)分區(qū)：滿(mǎn)足數(shù)據(jù)線性擴(kuò)展，通過(guò)引擎優(yōu)化命中細(xì)節(jié)分布式事務(wù)：兩階段提交3 /wiki/Hybrid_transactional/analytical_processing_(HTAP)第5頁(yè)，共23頁(yè)。ShardingHorizontal PartitionSharding Nothing水平

4、（Scale Out）/水平（Scale Up）切分、綜合切分，把同一表數(shù)據(jù)分散到多個(gè)數(shù)據(jù)庫(kù)或者多節(jié)點(diǎn)，增強(qiáng)并發(fā)能力，同時(shí)解決擴(kuò)展能力。多個(gè)表，可以跨越DB和服務(wù)器節(jié)點(diǎn)。Proxy層責(zé)任重，路由、優(yōu)化、事務(wù)狀態(tài)機(jī)、流式執(zhí)行器。代理：Mysql方案的：Mycat、Baidu Dbproxy；引擎：Oracle Sharding、MongoDB；DAO層：Hibernate Shards、 Sharding-JDBC切分策略根據(jù)業(yè)務(wù)鍵、時(shí)間。側(cè)重單張表的水平切分，突破I/O瓶頸。查詢(xún)引擎負(fù)責(zé)任務(wù)計(jì)劃、優(yōu)化，不需要代理。切分策略根據(jù)Hash、Range、List。一般和多副本同時(shí)發(fā)揮作用代表作：Ka

5、fka Partition、Kudu tablet、Greenplum segment。在NewSQL、MPP模式下應(yīng)用廣泛，并行處理和擴(kuò)展能力強(qiáng)。節(jié)點(diǎn)獨(dú)立，數(shù)據(jù)結(jié)果節(jié)點(diǎn)流轉(zhuǎn)或者上層匯總。底層存儲(chǔ)多樣，Kv解決方案多，類(lèi)似Palo和TiKV底層存儲(chǔ)的Rocksdb。一般和多副本同時(shí)發(fā)揮作用、數(shù)據(jù)模型LSM Tree。代表作：HybridDB for MySQL、TiDB、Teradata、DB2 DPF、GreenPlum共享存儲(chǔ)典型的Shared Disk架構(gòu)，從底層的存儲(chǔ)層共享解決一致性問(wèn)題，簡(jiǎn)單粗暴。理論上無(wú)限擴(kuò)展，基于Raft維持一致性弱化OLAP功能，重點(diǎn)解決單點(diǎn)容量問(wèn)題。代表作：A

6、WS Aurora、PolarDB存儲(chǔ)模型第6頁(yè)，共23頁(yè)。事務(wù)特征缺點(diǎn)優(yōu)點(diǎn)應(yīng)用代表2PC/3PC協(xié)調(diào)者、參與者投票階段+預(yù)提交+提交階 段保守策略、同步堵塞、單點(diǎn)故障、數(shù)據(jù)不一致實(shí)現(xiàn)簡(jiǎn)單Mysql、Greenplum、 TiDB（Percolator）Paxos三角色對(duì)某個(gè)數(shù)據(jù)的值達(dá) 成一致推導(dǎo)過(guò)程復(fù)雜保證安全和活性、允 許日志空洞阿里X-Paxos、 騰訊phxpaxos、 ZookeeperMVCC基于快照隔離機(jī)制進(jìn)行并 發(fā)控制，解決讀-寫(xiě)沖突的 無(wú)鎖并發(fā)控制寫(xiě)操作不用阻塞讀操 作的同時(shí)，避免了臟 讀和不可重復(fù)讀Mysql、Oracle、 Baidu TDB、 HBaseOCC解決寫(xiě)-寫(xiě)

7、沖突的無(wú)鎖并發(fā)控制假設(shè)競(jìng)爭(zhēng)幾率小在資源沖突不激烈的 場(chǎng)合，用樂(lè)觀鎖性能 較好DBMS事務(wù)并發(fā)控制模型第7頁(yè)，共23頁(yè)。1.4 融合技術(shù)的應(yīng)用場(chǎng)景需求OLAPOLTPRedisMysqlHBasePrestoGreenplumPetaData TiDBDruidApache KuduRedshift PaloImpala第8頁(yè)，共23頁(yè)。目錄一、OLTP與OLAP 技術(shù)介紹二、融合技術(shù)選型三、Binlog+Kudu+impala最佳實(shí)踐第9頁(yè)，共23頁(yè)。2.1 SQL On Hbase：Apache Phoenix4二級(jí)索引（四種）統(tǒng)計(jì)信息收集SQL編譯成Hbase Scans基于Tephra支

8、持全局事務(wù)并行任務(wù)編排Phoneix重點(diǎn)強(qiáng)調(diào)低延遲的OLTP，基于Hbase提供分析能力。擅長(zhǎng)熱數(shù)據(jù)的簡(jiǎn)單聚合分析能力百度外賣(mài)用通過(guò)MQ對(duì)接數(shù)據(jù)DML的回放和數(shù)據(jù)暫存點(diǎn)4圖片來(lái)源https:/linbingdong/p/5832112.html第10頁(yè)，共23頁(yè)。2.2 Greenplum5圖片來(lái)源/yunqi/articles/511766來(lái)源https:/2018/02/22/hybrid-database-capturing-perishable-insights-yiguo/采用shared nothing架構(gòu)（MPP）底 層采用Postgresql自有資源隊(duì)列和優(yōu)先級(jí)運(yùn)維管理工具豐富

9、索引方式豐富，命中索引場(chǎng)景速度較優(yōu)Gpexpand可以實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)容，但周 期長(zhǎng)側(cè)重OLAP能力Heap表容易實(shí)現(xiàn)膨脹并發(fā)寫(xiě)入性能較Phoenix、TiDB差6第11頁(yè)，共23頁(yè)。2.3 TiDB77TiDB架構(gòu)圖來(lái)自/docs-cn/開(kāi)源分布式HTAP數(shù)據(jù)庫(kù)，目標(biāo)是100% 的 OLTP 場(chǎng)景和 80% 的 OLAP場(chǎng)景兼容 MySQL支持無(wú)限的水平擴(kuò)展具備強(qiáng)一致性和高可用性運(yùn)維工具和周邊工具豐富TiKV以Region作為單元，對(duì)數(shù)據(jù)管 理和復(fù)制支持分區(qū)和索引為云部署設(shè)計(jì)第12頁(yè)，共23頁(yè)。2.4 HybridDB for MySQL8關(guān)系型 HTAP 類(lèi)數(shù)據(jù)庫(kù)，目標(biāo)實(shí)時(shí) 處理分析分布式任務(wù)可

10、以線性增長(zhǎng)兼容Mysql語(yǔ)法和函數(shù)對(duì)Oracle常用分析函數(shù)的支持，100%完全兼容TPC-H和TPC-DS測(cè)試標(biāo)準(zhǔn)支持分區(qū)內(nèi)事務(wù)以阿里云方式提供服務(wù)8架構(gòu)參照/product/26320.html?spm=a2c4g.11186623.3.1.qRhlHP第13頁(yè)，共23頁(yè)。2.5 Impala+kudu9Impala:基于MPP架構(gòu)的即席查詢(xún)引擎內(nèi)存shuffle，計(jì)算速度快支持HDFS、KUDU、Hbase數(shù)據(jù)源與Hive語(yǔ)法兼容性高Catalog和Statestore存在單點(diǎn)9參照/kudu.pdf /docs/Kudu:融合OLTP型隨機(jī)讀寫(xiě)能力與OLAP型分析能力開(kāi)源的基于列式存儲(chǔ)

11、、與Hadoop生態(tài)結(jié)合好強(qiáng)Schema，有限列數(shù)順序度和隨機(jī)度綜合性能強(qiáng)勁有唯一主鍵約束，支持Upsert語(yǔ)法第14頁(yè)，共23頁(yè)。目錄一、OLTP與OLAP 技術(shù)介紹二、融合技術(shù)選型三、Binlog+Kudu+impala最佳實(shí)踐第15頁(yè)，共23頁(yè)。3.1 基于binlog的回放Binary logMysqlBinlogServerDRC（Data Replication Center）DRCReplicatorBootstrap ServiceClient SDKDataApplayKafka多源合并和異構(gòu)復(fù)制Master目標(biāo)端DRC數(shù)據(jù)復(fù)制和調(diào)度中心支持異構(gòu)結(jié)構(gòu)對(duì)接映 射支持基于時(shí)間點(diǎn)數(shù)

12、據(jù) 快速回放支持多規(guī)則的過(guò)濾規(guī) 則整體服務(wù)高可用不具備全局事務(wù)一致 性，保證單個(gè)事務(wù)操 作一致第16頁(yè)，共23頁(yè)。3.2 融合方案的設(shè)計(jì)架構(gòu)DRCKafka單一PartitionSpark StreamingKuduServerFlumeSinkFlink watermark方案一方案二方案三支持輕量級(jí)ETL扇入數(shù)據(jù)有序性數(shù)據(jù)處理高效精準(zhǔn)insert、update、delete數(shù)據(jù)列方案一：高并發(fā)支持，開(kāi)發(fā)成本略低，實(shí)時(shí)性好，有亂序可能方案二：高并發(fā)支持，在時(shí)間窗口內(nèi)保證有序，實(shí)時(shí)性和有序 做權(quán)衡方案三：流程簡(jiǎn)單，處理效率低第17頁(yè)，共23頁(yè)。3.3 關(guān)鍵技術(shù)點(diǎn)：分庫(kù)分表的融合Kafka單一P

13、artition數(shù)據(jù)交換元數(shù)據(jù)數(shù)據(jù)入庫(kù)計(jì)算單元數(shù)據(jù)入庫(kù) 計(jì)算單元Kudu APITabletTabletImpalaKudu隨機(jī)寫(xiě)壓力分散到Tablet利用Hash Paritioning，實(shí)現(xiàn)隨機(jī)寫(xiě)高性能同一個(gè)Scan所 鍵進(jìn)行hash需要的數(shù)據(jù)放在同一個(gè)tablet中，利用業(yè)務(wù)主大范圍檢索需要Range切片（日期）第18頁(yè)，共23頁(yè)。Bootstrap Service3.4 關(guān)鍵技術(shù)點(diǎn)：數(shù)據(jù)冷啟動(dòng)SnapShotEventLogEventLogEventLogEventLogTarget Data通過(guò)Slave系統(tǒng)復(fù)制一份快照，并且 應(yīng)用后續(xù)的Eventlog對(duì)于批量數(shù)據(jù)方便裝載痛點(diǎn)：數(shù)據(jù)快照占用存儲(chǔ)空間，需要配合 清理策略+壓縮定期快照 or 初始快照+DataEvent階段第19頁(yè)，共23頁(yè)。3.5 關(guān)鍵技術(shù)點(diǎn)：數(shù)據(jù)回溯數(shù)據(jù)回溯KuduEventLogEventLogEventLogEventLogDRC回溯用于歷史數(shù)據(jù)的修正通過(guò)客戶(hù)端存儲(chǔ)數(shù)據(jù)的復(fù)位點(diǎn)數(shù)據(jù)回放不清理目標(biāo)端數(shù)據(jù)回溯周期較長(zhǎng)，采取冷啟動(dòng)的方式 快速對(duì)接。需要：數(shù)據(jù)的增改刪帶全量變更前后數(shù)據(jù)。第20頁(yè)，共23頁(yè)。3.6 關(guān)鍵技術(shù)點(diǎn)：熱數(shù)