《{环境管理}针对大数据量环境下分析型应用的支持方案》由会员分享，可在线阅读，更多相关《{环境管理}针对大数据量环境下分析型应用的支持方案（94页珍藏版）》请在金锄头文库上搜索。
1、DTCC2011 DM 针对大数据量环境下分析型 应用的支持方案 大纲 一个实际案例 挑战和解决方案 下一步工作规划 DTCC2011 DTCC2011 一个实际案例 案例简介 DTCC2011 海量数据 基于已有硬件投资 单服务器节点 操作库和分析库合并 以查询分析为主，兼顾少量数据维护 文本 硬件与拓扑 千兆交换机 DTCC2011 应用服务 器 数据汇总 文本 数据 源 文本 Excel 数据 数据清洗与入 库 数据库 服务器 P550 Cpux4 Mem32GB P550 Cpux4 Mem32GB 源源 16X1TBSAS RAID5 案例简介-数据 DTCC2011 以常规数据为主
2、，主要为数值、字符串、 时间类型 日增长数据量为约 56G，3 亿条元组 当前数据量 3TB 最大单表为计费表，目前约 150 亿条记录 数据保存 20 年后归档为历史数据 在线数据规模将超过 400TB 典型业务流程 DTCC2011 源数据清洗入库 分析统计型查询 第一步过滤的筛选条件不确定 试错式的查询分析过程，成功后固化，一般包含 20 多个步骤 大规模的连接查询、子查询、联合查询、数据分组与排序、临 时结果集与临时表等 复杂 SQL 不多，但 IO 非常大 日常数据维护 手工修改记录内容 批量删除 定期维护 案例需求 DTCC2011 关键在查询性能 第一个过滤步骤 筛选字段由用户随
3、机定义，因此无法使用索引 一般会得到千万级别的结果集 大量的多表连接查询 数据装载性能 初始入库 48 亿条，近 1T：限 48 小时，相当于 3 万条/s 后续每 3 天入库一次，9 亿条，168G，限 10 小时内完成 DTCC2011 挑战-核心是性能 原有产品难以支持分析型应用DTCC2011 只 支 持 行 式 存 储 查 询 优化器比较简陋 虚拟机实现不尽合理 物理存储设计有待优化 日志系统过于复杂 不能充分利用多机资源提升性能 数据分片技术不完善 于 2009 年开始新一代产品 DM7 的研制 DTCC2011 实验室原型 技术积累阶段 实现各类标准 持续的技术积累 5.65.6
4、 引入物理操作符, ,虚拟机 6.06.0 引入高级特性和 oracleoracle 兼容特性 5 5 DM7DM7 2011 稳定性及功能 与开源系 统有差距 3 3 DM5.6DM5.6 4 4 DM6DM6 2009 对 DM4-DM6 的技 术总结 融合列存储与行 存储 基于向量数据的 1 1 DM1-DM3DM1-DM3 2 2 DM4DM4 20042007 执行内核原 生的 MVCCOLAP 应用的支持 1988- 2003 对于性能的理解 DTCC2011 应用系统的 设计 表达式计算 优化器 综合性能 数据/ /控制权 传递 I/OI/O 效率 并发/ /并行 数据控制权传递
5、-批量技术DTCC2011 向量数据处理 在数据泵一次传送一批数据 减少控制转移的 CPU 损耗； 有利于批量的表达式计算 传统的数据传递 PROJECTPROJECT FILTERFILTER 一次只传递一条记录 每个操作符一次只处理一 行记录 1 11 11 1 控制权需要反复传递 SCANSCAN 向量式的数据传递 PROJECTPROJECT 减少控制权限的反复传递 提升 CPU 的有效利用率 FILTERFILTER 便于表达式批量计算 SCANSCAN 批量技术-数据入库 DTCC2011 将系统的初始数据入库 原有 BCP 接口达到 5000 条/s，仍无法满足要求 改进： 在服
6、务器端实现批量，减少执行流程中的控制跳转 效率提升倍 批量技术-全表更新 DTCC2011 普通 批量 普通批量 绑定 针对大表更 新的特定的 批量绑定消 息 计划生成 生成特定计 划，减少执 行流程 单趟扫描一个 ID 进行 更新，执行 20 万次 ID 进行排序，单趟扫描 20 万个 ID 并进行更新 性能提升 100 倍以上，控制在 2 秒以内 批量技术-LIKE 谓词 selectcount(*)fromorderswhere o_mentnotlike %special%requests% DTCC2011 DBMSO11g:3.3 DBMSS2005:10 DM7: 0.4 ord
7、ers:1,500,000 记录 cpu2.2G,多次执行 DTCC2011 一个表达式出现多次 Selectsum(2*c1),sum(3*(2*c1)fromt 只计算一次，结果缓存 v1=2*c1； Selectsum(v1),sum(3*v1)fromt 类似思路：中间结果重用 一个复杂查询在一条 sql 语句中使用多次的情况 将复杂查询提取，并将结果缓存，多次使用 批量表达式计算 for(i=0;in;i+)for(i=0;in;i+) r=(int64)opr1i+opr2;r=(int64)opr1i+opr2; if(r!=(int)r)if(r!=(int)r) return
8、EC_DATA_OVERFLOW;returnEC_DATA_OVERFLOW; resiresi=(int)r;=(int)r; 一次 计 算 一 批数据 利用 CPU的 CACHE 利 用 CPU的 SIMD特性 避免传统 DBMS 的函数反复调用代价 接近于 C 的效率 比一次一行模式快 10-100 倍以上 批量尺寸对性能的影响 SF=1,TPCHQ1 BDTA_SIZE:可配 置的批量大小参数 增大 BDTA_SIZE 可以有效的提高执 行效率 TPCHDM7 DBMS O11 PGSQL8.3 DBMS S20 05 Q11.3149.0916.0112.87 Q20.160.04
9、60.190.14 Q30.8621.619.302.78 Q40.989.030.800.68 Q51.49.054.611.58 Q60.7892.720.96 Q71.6111.7319.542.35 Q82.30.282.972.01 Q931.6118.015.45 Q101.369.165.832.23 Q110.1944.670.550.46 DTCC2011 优化器-分析器流程 DTCC2011 SQLSQL 脚本 语法分析 语法树 语义分析 SFWSFW 结构 关系代数变换 关系树 代价优化 优化了的关系树 物理计划生成 执行计划 智能优化器 基于多趟分析的代价优化器 语义分
10、析、代价优化过程分离 灵活的计划变换控制 基于时间单位(ms)的代价计算 解决统计信息的使用性问题 增加频率直方图 增加高度直方 图的桶数 DTCC2011 查询优化：关系变换 DTCC2011 SFW 结构转换为关系树 Select:ID,nameSelect:ID,name From:TFrom:T SFW 结构 投影(PROJECT) 连接(JOIN) 半连接(SEMIJOIN) 选择(SELECT) 基本表(BASETABLE) Where:ID=10Where:ID=10 PROJECTPROJECT (ID,name)(ID,name) SELECTSELECT (ID=10)(I
11、D=10) BASE_BASE_ TABLE(T)TABLE(T) 关系树 查询优化：关系变换的关键DTCC2011 消除子查询，“平坦”的关系树 子查询一律转化为半连接（SEMIJOIN） 例：selectfromT1wheret1.idin(selectIDfromT2) PROJECTPROJECT SEMISEMI JOINJOIN T1T1T2T2 查询优化：待选关系树的生成DTCC2011 考虑三个因素 A.确定的连接次序 B.确定的卡特兰 2 叉树形状 C.是否下放过滤条件 采用临时结果减少重复计算 代价模型基本覆盖所有情况 对连接表的个数非常多的情况,特殊处理 查询优化：统计信
12、息 DTCC2011 记录数据分布情况，用于精确行数估计， 特别是数据分布不规则的情况，对基数及 代价计算有重大影响 频率直方图：不同值较少 500 450 400 350 300 250 400200238432300 200 150 100 50 0 124167 w_id=0w_id=1w_id=2w_id=3w_id=4w_id=5w_id=6 等高直方图：不同值较多 4050 4000 4002399040323980 3950 3900 3850 3800 39503960 3888 DTCC2011 列存储: 数据按列存储 结合自适应压缩技术 与批量计算技术紧密结合 列存储优缺点
13、 大幅提升扫描性能 适合批量装载与删除 不适合频繁的插入、删除和更新 融合列存储和行存储 提供按列存储选项 结合分区技术 同时适应 OLAP 和 OLTP 应用需求 I/O 效率 行存储优化 简化物理记录格式 字段物理次序与逻辑次序分离 多 buffer 类型 常驻内存和常规方式淘汰 用户可以指定 批量读：预处理 支持垂直分 区和水平分区 DTCC2011 提高并发度 支持并行插入的物理数据存储 并行备份和恢复 分区技术及相应的并行查询操作符号 DTCC2011 典型场景一：大结果集 DTCC2011 场景描述 某表 T，31 个字段，48 亿条记录 随机基于某字段筛选：SELECT*FROM
14、TWHERE FLD1=753 查询符合条件的结果集达到千万条记录 分析 SQL 语句非常简单，没有更优的等效语句 结果集筛选条件不确定，无法使用索引 服务器内存为 32G，在扫描的过程中必然出现页面淘汰 由于基础数据量大，因此即使命中率不高（0.2%）， 也会生成 960 万条记录的结果集 典型场景一：大结果集 DTCC2011 从 3 个方向入手，提升全表扫描的 IO 效率 批量技术 降低结果集处理的时间消耗 调整数据页读取策略 典型场景一：大结果集 DTCC2011 返回结果集策略改进 优化前 根据通信块大小决定结果集分批次返回的数量 第一批结果集返回后，自动完成后续结果集获取和返回 优
15、化后 由应用设定第一批结果集的大小和返回的时机 当返回第一批结果集后，工作线程暂停 SQL 查询请求，直到下 一批结果集请求到来或开始新事务 效果 快速返回部分结果集，提高用户体验 避免自动返回所有结果集，降低服务器资源消耗 典型场景一：大结果集 DTCC2011 调整数据读取策略 数据页（page）是数据读写的单位 优化前的全表扫描：按页读取，每次 IO 只扫描 一个页 优化后：一次扫描多个页，减少 IO 数量 测试：经过优化后，磁盘的吞吐量提升 1 倍 典型场景二：大表连接 DTCC2011 场景描述 表 T1，31 个字段，5000W 条记录，数据类型包括 int、 varchar、da
16、tetime、Dec；表 T2,15 个字段，500W 条记录， 数据类型包括 varchar、datetime、Dec； SELECTT1.NAME,T2.TITLEFROM T1,T2WHERE T1.PERSONID=T2.PERSONIDANDT1.SEX=M; 连接查询字段由最终用户临时指定，表上未建索引 结果集不大，但查询表数据量大，连接查询响应时间陡增 典型场景二：大表连接 DTCC2011 分析 行存储特性：连接查询所连接的字段在数据页中的 存储非连续，进行连接查询，需将所有数据页读到 内存，IO 消耗巨大； 连接匹配时，要对读入缓存中的所有页进行扫描。 行存储： C1 C2 Cn C1 Cm 连接列分散在每个数据页中 Cn+1Cn+1页 1Cn+1Cn+1页 N 典型场景二：大表连接 DTCC2011 优化方向：列存储 按字段存储 连接列被集中存储 Cn+1Cn+1Cn+1Cn+1 页 1 Cn+1Cn+1
