DM针对大数据量环境下分析型应用的支持方案v2.0

–单服务器节点–操作库和分析库合并千兆交换机应用服务器千兆交换机P550数据汇总数据清洗与入文本数据源Cpu数据汇总数据清洗与入文本数据源数据库服务器文本数据源Mem数据库服务器文本数据源4GB4GB光线通道Excel数据源文本数据源CpuExcel数据源文本数据源Mem32GBRAID5典型业务流程DTCC2011案例需求DTCC2011–第一个过滤步骤–大量的多表连接查询•物理存储设计有待优化•不能充分利用多机资源提升性能于2009年开始新一代产品DM7的研制持续的技术积累持续的技术积累5.6引入物理操作符,虚拟机6.0引入高级特性和oracle兼容特性3 2实验室原型技术积累阶段实现各类标准稳定性及功能与开源系实验室原型技术积累阶段实现各类标准稳定性及功能与开源系统有差距1 5对DM4-DM6的技术总结持对于性能的理解DTCC2011数据控制权传递-批量技术DTCC2011-在数据泵一次传送一批数据-减少控制转移的CPU损耗；-有利于批量的表达式计算11111…12…N12…12…N12…N…………–将系统的初始数据入库–原有BCP接口达到5000条/s，仍无法满足要求•效率提升8倍息-Selectsum(2*c1),sum(3*(2*c1))fromt-v1=2*c1；-Selectsum(v1),sum(3*v1)fromt-一个复杂查询在一条sql语句中使用多次的情况-将复杂查询提取，并将结果缓存，多次使用{933查询优化：关系变换DTCC2011•考虑三个因素•A.确定的连接次序•B.确定的卡特兰2叉树形状•C.是否下放过滤条件•采用临时结果减少重复计算•代价模型基本覆盖所有情况•对连接表的个数非常多的情况,特殊处理查询优化：统计信息DTCC20114050400039503900405040003950390038503800500500450400350300250200500400200238432300w_id=0w_id=1w_id=2w_id=3w_id=4w_id=5w_id=63950396040023888399040323980(0,1000](1000,1500](1500,1800](0,1000](1000,1500](1500,1800](1800,2000](2000,2100](2100,3000](3000,5000]•列存储:•支持垂直分区和水平分区•支持并行插入的物理数据存储•并行备份和恢复•分区技术及相应的并行查询操作符号-某表T，31个字段，48亿条记录-随机基于某字段筛选：SELECT*FROMTWHERE-查询符合条件的结果集达到千万条记录-SQL语句非常简单，没有更优的等效语句-结果集筛选条件不确定，无法使用索引-服务器内存为32G，在扫描的过程中必然出现页面淘汰-由于基础数据量大，因此即使命中率不高（0.2%典型场景一：大结果集DTCC2011典型场景一：大结果集DTCC2011•返回结果集策略改进-优化前-优化后-效果典型场景一：大结果集DTCC2011-数据页（page）是数据读写的单位-优化前的全表扫描：按页读取，每次IO只扫描-优化后：一次扫描多个页，减少IO数量-测试：经过优化后，磁盘的吞吐量提升1倍典型场景二：大表连接DTCC2011-表T1，31个字段，5000W条记录，数据类型包括int、varchar、datetime、Dec；表T2,15个字段，500W条记录，数据类型包括varchar、datetime、Dec；-SELECTT1.NAME,T2.TITLEFROMPERSON.PERSONT1,RESOURCES.EMPLOYEET2WHERET1.PERSONID=T2.PERSONIDANDT1.SEX='M';-连接查询字段由最终用户临时指定，表上未建索引-结果集不大，但查询表数据量大，连接查询响应时间陡增典型场景二：大表连接DTCC2011…………………典型场景二：大表连接DTCC2011•优化方向：列存储…•优化方向：存储压缩-适用于列存储模式的压缩算法从17小时降至10分钟以内-表T,15个字段，500W条记录，数据类型包括int、varchar、datetime、Dec-根据T进行查询建表：CREATETABLETTasSELECT*FROM-大表进行查询建表时，需经过以下五个步骤集集-这个过程中可优化的操作有：查询与结果集的生成和大量数据的插入操作-避免结果集处理与数据插入-直接复制根节点和叶子是在-优化前耗时约35S-优化后耗时约4S，性能提升-针对500万条记录的表进行如下查询-SELECTIDnum,sub(6,8,IDnum)as生日,(now()-sub(6,8,IDnum))as年龄from…-一个表达式出现多次，只计算一次-本例中性能提升70%。其他场景性能提升程度取决于计算表达式的复杂度与数据量-同结构的表T1~T10，每张表500万条记录，需要将10-应用的并行化并没有带来较大的提升-分析-Ttmp成为瓶颈：原有的逻辑Rowid成为资源瓶颈-逻辑Rowid：不代表物理存储位置，更新、插入、重组-原有产品针对OLTP业务场景，OLTP事务以分散、短-物理RowID：代表记录的物理存储位置-多个工作线程进行插入操作，无需进入临界资源获取rowid，每个工作线程自行生成RowID-实现真正意义上的并发插入应用优化DTCC2011-应用架构设计应站在系统全局考虑性能问题-应用与数据库应该取长补短-基于分区表进行数据划分-复杂事务分解为多个可并行的简单事务应用优化-大表的全表扫描DTCC2011–优化前：数据库服务器CPU满载而应用服务器没有–在最坏情况下，将需要扫描整个表–系统设计需要站在全局角度，充分考虑应用、中间件、数据库之间的负载分配–充分利用已有的硬件应用优化-大表的全表扫描DTCC2011•应用依据分表更改查询模块，从单线程改为•在应用服务器将各分表的查询结果合并•按最坏情况测试，查询时间由原来的不可预应用优化-数据清洗与入库DTCC2011–基于JDBC驱动的数据迁移工具进行清洗和入库–批量绑定–迁移工具的资源消耗随着迁移时间的持续增加，导致迁移速度在运行3天后急剧下降–初始数据（1T）入库时间达到1个月，相当于400条/s应用优化-数据清洗与入库DTCC2011–超过100亿条记录，即使每5000条提交一次，也有2百万次的解析-计划-代价-执行流程–大量的数据库redo与undo日志操作–利用批量+BCP–利用并行化充分发挥多CPU处理能力，增加IO–JDBC方式转变为JNI+ODBC–实现动态编译型的ETL脚本引擎海量数据备份的难题DTCC2011–整库备份操作耗时太长–需要灵活的针对整库、文件组、表、分区的多种粒度备份手段–备份文件太大，消耗存储空间严重–传输大尺寸备份文件，网络传输成为瓶颈本案例中的备份需求DTCC2011根据数据量、变化频度等确定不同的备份策略•