OLTP和OLAP技術融合架構實踐課件

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

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

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

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

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

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

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

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

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

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

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

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

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