OLTP和OLAP技术融合架构实践

OLTP和OLAP技术融合架构实践技术创新，变革未来目录•一、OLTP与OLAP技术介绍•二、融合技术选型•三、Binlog+Kudu+impala最佳实践1.1OLTP背景介绍联机事务处理OLTP（on-linetransactionprocessing）也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。[1]关键词：数据量少、面向应用、并行事务处理、分库分表、读写分离、Cache技术、B-Tree索引实时性要求高、数据库作为载体、SQL交互[1]OLTP概念引用自百度百科背景介绍联机实时分析OLAP(OnlineAnalyticalProcessing,）联机分析处理OLAP是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(FastAnalysisofSharedMultidimensionalInformation)，即共享多维信息的快速分析的特征。[2]关键词：数据海量、追加操作为主、数据分区、切片和切块、雪花模型钻取、旋转、投影、数据仓库、MDX、实时性要求低[2]OLAP概念引用自百度百科联机分析处理?fromtitle=OLAP1.3两者面向场景的分析-HTAP[3]需求：一份数据存储用于OLTP和OLAP处理。1）数据实时可见2）支持多维度低延迟查询交付3）低成本通用的解决方法：数据Sharding：实例间sharenothing，便于横向水平扩展数据分区：满足数据线性扩展，通过引擎优化命中细节分布式事务：两阶段提交[3](HTAP)ShardingHorizontalPartitionShardingNothing•水平（ScaleOut）/水平（ScaleUp）切分、综合切分，把同一表数据分散到多个数据库或者多节点，增强并发能力，同时解决扩展能力。•多个表，可以跨越DB和服务器节点。•Proxy层责任重，路由、优化、事务状态机、流式执行器。•代理：Mysql方案的：Mycat、BaiduDbproxy；引擎：OracleSharding、MongoDB；DAO层：HibernateShards、Sharding-JDBC•切分策略根据业务键、时间。•侧重单张表的水平切分，突破I/O瓶颈。•查询引擎负责任务计划、优化，不需要代理。•切分策略根据Hash、Range、List。•一般和多副本同时发挥作用•代表作：KafkaPartition、Kudutablet、Greenplumsegment。•在NewSQL、MPP模式下应用广泛，并行处理和扩展能力强。•节点独立，数据结果节点流转或者上层汇总。•底层存储多样，Kv解决方案多，类似Palo和TiKV底层存储的Rocksdb。•一般和多副本同时发挥作用、数据模型LSMTree。•代表作：HybridDBforMySQL、TiDB、Teradata、DB2DPF、GreenPlum共享存储•典型的SharedDisk架构，从底层的存储层共享解决一致性问题，简单粗暴。•理论上无限扩展，基于Raft维持一致性•弱化OLAP功能，重点解决单点容量问题。•代表作：AWSAurora、PolarDB存储模型事务特征缺点优点应用代表2PC/3PC协调者、参与者投票阶段+预提交+提交阶段保守策略、同步堵塞、单点故障、数据不一致实现简单Mysql、Greenplum、TiDB（Percolator）Paxos三角色对某个数据的值达成一致推导过程复杂保证安全和活性、允许日志空洞阿里X-Paxos、腾讯phxpaxos、ZookeeperMVCC基于快照隔离机制进行并发控制，解决读-写冲突的无锁并发控制写操作不用阻塞读操作的同时，避免了脏读和不可重复读Mysql、Oracle、BaiduTDB、HBaseOCC解决写-写冲突的无锁并发控制假设竞争几率小在资源冲突不激烈的场合，用乐观锁性能较好DBMS事务并发控制模型1.4融合技术的应用场景需求OLAPOLTPRedisMysqlHBasePrestoGreenplumPetaDataTiDBDruidApacheKuduRedshiftPaloImpala目录•一、OLTP与OLAP技术介绍•二、融合技术选型•三、Binlog+Kudu+impala最佳实践2.1SQLOnHbase：ApachePhoenix[4]•二级索引（四种）•统计信息收集•SQL编译成HbaseScans•基于Tephra支持全局事务•并行任务编排•Phoneix重点强调低延迟的OLTP，基于Hbase提供分析能力。•擅长热数据的简单聚合分析能力•百度外卖用通过MQ对接数据DML的回放和数据暂存点[4]图片来源[5]图片来源[6]来源•采用sharednothing架构（MPP）底层采用Postgresql•自有资源队列和优先级•运维管理工具丰富•索引方式丰富，命中索引场景速度较优•Gpexpand可以实现动态扩容，但周期长•侧重OLAP能力•Heap表容易实现膨胀•并发写入性能较Phoenix、TiDB差[6]2.3TiDB[7][7]TiDB架构图来自•开源分布式HTAP数据库，目标是100%的OLTP场景和80%的OLAP场景•兼容MySQL•支持无限的水平扩展•具备强一致性和高可用性•运维工具和周边工具丰富•TiKV以Region作为单元，对数据管理和复制•支持分区和索引•为云部署设计2.4HybridDBforMySQL[8]•关系型HTAP类数据库，目标实时处理分析•分布式任务可以线性增长•兼容Mysql语法和函数•对Oracle常用分析函数的支持，100%完全兼容TPC-H和TPC-DS测试标准•支持分区内事务•以阿里云方式提供服务[8]架构参照=a2c4g.11186623.3.1.qRhlHP2.5Impala+kudu[9]•Impala:基于MPP架构的即席查询引擎•内存shuffle，计算速度快•支持HDFS、KUDU、Hbase数据源•与Hive语法兼容性高•Catalog和Statestore存在单点[9]参照://kudu.apache.org/docs/•Kudu:融合OLTP型随机读写能力与OLAP型分析能力•开源的基于列式存储、与Hadoop生态结合好•强Schema，有限列数•顺序度和随机度综合性能强劲•有唯一主键约束，支持Upsert语法目录•一、OLTP与OLAP技术介绍•二、融合技术选型•三、Binlog+Kudu+impala最佳实践3.1基于binlog的回放BinarylogMysqlBinlogServerDRC（DataReplicationCenter）DRCReplicatorBootstrapServiceClientSDKDataApplayKafka多源合并和异构复制Master目标端DRC数据复制和调度中心•支持异构结构对接映射•支持基于时间点数据快速回放•支持多规则的过滤规则•整体服务高可用•不具备全局事务一致性，保证单个事务操作一致3.2融合方案的设计架构DRCKafka单一PartitionSparkStreamingKuduServerFlumeSinkFlinkwatermark方案一方案二方案三•支持轻量级ETL扇入•数据有序性•数据处理高效•精准insert、update、delete数据列•方案一：高并发支持，开发成本略低，实时性好，有乱序可能•方案二：高并发支持，在时间窗口内保证有序，实时性和有序做权衡•方案三：流程简单，处理效率低3.3关键技术点：分库分表的融合Kafka单一Partition数据交换元数据数据入库计算单元数据入库计算单元KuduAPITabletTabletImpala•Kudu随机写压力分散到Tablet•利用HashParitioning，实现随机写高性能•同一个Scan所键进行hash需要的数据放在同一个tablet中，利用业务主•大范围检索需要Range切片（日期）BootstrapService3.4关键技术点：数据冷启动SnapShotEventLogEventLogEventLogEventLogTargetData•通过Slave系统复制一份快照，并且应用后续的Eventlog•对于批量数据方便装载•痛点：•数据快照占用存储空间，需要配合清理策略+压缩•定期快照or初始快照+DataEvent阶段3.5关键技术点：数据回溯数据回溯KuduEventLogEventLogEventLogEventLogDRC回溯用于历史数据的修正•通过客户端存储数据的复位点•数据回放不清理目标端数据•回溯周期较长，采取冷启动的方式快速对接。•需要：数据的增改删带全量变更前后数据。3.6关键技术点：热数据变冷归档0感知ImpalaViewTableOnHDFSTableOnKuduHDFSKudu平滑器元数据修改迁移•基于视图对外交付•冷热交替数据通过调度定期变更•数据交替期间多存储•元数据变更与广播•迁移完Kudu清理面临问题：归档hdfs数据有变更Impala3.7踩坑集合•没有主键•类型适配映射•BinlogRow•DDL变更•保证binlog回放顺序性•数据轻度ETL扇入