rdbms迁移到impala.pptVIP

rdbms迁移到Impala2.0 崔雪征 cuixuezheng@ Impala特点 定位于OLAP分析 和hadoop集成，可与hadoop同样方式扩展 多种数据文件格式存储 Parquet、text可读写；Avro、RCFILE、SequenceFile可读；都支持gzip、Snappy压缩 支持HBase存储 与Hive共享元数据 MPP引擎 迁移－数据类型 数据类型 VARCHAR,?VARCHAR2, CHAR, NCHAR,?NVARCHAR, CLOB, NCLOB?对应STRING，无长度，2.0开始支持VARCHAR DATE,?DATETIME, TIME对应TIMESTAMP SELECT NOW() + INTERVAL time_period DAYS from deadlines; DECIMAL, NUMBER对应FLOAT， DOUBLE?，不能指定固定精度 整型都是有符号类型 不支持复合或嵌入类型，像maps、Structs、 Arrays 不支持PRIMARY KEY,?FOREIGN KEY,?UNIQUE,?NOT NULL,?UNSIGNED, CHECK?constraints, DEFAULT 不支持索引 使用函数时，类型不对或者超出范围返回NULL 支持JAVA，C++自定义函数、聚合函数；当catalogd重启后，函数须重新load 迁移－SQL SQL 不支持DELETE?，可用INSERT OVERWRITE代替 不支持UPDATE 没有事务，也就没有COMMIT、ROLLBACK 数据库、表、字段等都不能与impala保留字冲突 仅支持FROM后面的子查询，不支持IN,NOT IN, EXISTS, NOT EXISTS的子查询 每个子查询必须有别名 分区字段必须是特定的值，不能是范围 top-N 用limit SQL通用优化方法 过滤数据 Where过滤数据条数 只取必要字段 减少数据量 汇总 子查询 少用关联 可用union all替换部分 少用外关联 冗余 列上少用函数 在参数上用函数 批处理 一起做，而不是分开做 预处理 能提前处理的提前处理 物尽其用 性能最佳实践 合适的数据文件格式 大数据量下snappy压缩的parquet性能表现最好 避免产生大量小文件 INSERT ... SELECT，而不是INSERT ... VALUE 合适的分区粒度 分区数最好在3万以下 合适的分区类型 Integer类型代替string类型 Tinyint代表smallint 合适的parquet块大小 收集表信息 在load或者insert后 最小化传输给客户端的数据量 汇总 过滤 Limit 合适的输出格式 确认执行计划符合预期 确认性能瓶颈 优化-关联 Broadcast joins 默认方式，把关联右边的表传输到其他所有参与计算节点 Example: BIG,?MEDIUM,?SMALL, and?TINY, the logical join order to try would be?BIG,?TINY,?SMALL,?MEDIUM. 表及列信息可用时，系统可以根据表大小做优化，如果不可用，则是Broadcast joins partitioned join 把需要的数据并行分发到不同的的节点计算 STRAIGHT_JOIN 手工指定关联表分发顺序: select straight_join x from medium join small join (select * from big where c1 10) as big where medium.id = small.id and small.id = big.id; 优化-HDFS caching 特点 类似于MySQL中的内存表 hdfs cacheadmin -addPool four_gig_pool -owner impala -limit 00 表和分区都可以pinned内存中，语法：cached in pool_name 缓存满时报错 建议 缓存维表、参数表 缓存临时表，用完后清空 优化-分区 何时需要分区 表非常大 根据某列特定值查询 某列只有特定几个值 通过ETL处理的数据 因为SQL不支持delete而加的分区 使用 insert into t1 partition(x, y=b) select c1, c2 from some_other_table; insert into weather partition (year, month, day) select cloudy,2014,4,21; insert into weather partition (ye