基于Spark SQL构建即席查询平台 讲话.ppt

基于Spark构建即席查询平台 自我介绍 基础架构部 分布式计算团队 孙垚光 09年-11年：Linux内核 网络协议栈优化 11年-今：分布式计算 批处理/内存计算/流式等 目录 即席查询 为什么是Spark 基于Spark，我们做了什么 应用案例 后续规划 即席查询 面向“人”的查询 即席（Ad-Hoc）： 查询模式相对不固定 数据没有（时间/成本）做过多预处理 数据暂时不知如何处理 交互式（Interactive） 查询具有较高时效性 为什么是Spark MPP vs Hadoop MPP(Impala) Hadoop(Hive/SparkSQL) 扩展性 1000台以内/PB以下 千台以上/PB以上 查询延迟 毫秒~秒 秒~分钟 架构复杂性 中等 复杂 容错 无 有 调度策略 Gang/Transaction 分批调度 与存储结合程度 紧密 一般 基于Spark我们做了什么 更易用 更稳定 安全/资源隔离 性能/时效性 整体架构 基于Spark我们做了什么 更易用 Platform as a Service 用户不再关心部署/升级/调参/监控 各种形式的API Web/CLI/JDBC/SDK/Tools等 合理/简洁的概念抽象 Resource/Project/Dataset/Table/Partition 账单 Query粒度的资源消耗 基于Spark我们做了什么 更稳定 接入层无单点 Query持久化 支持Query返回大量数据 各用户保证Quota 多种维度的监控 安全/资源隔离 基于Cgroup/Namespace的Container隔离 CPU/Memory/FS Container本身的加固 网络的互通与隔离 基于JVM沙箱层的多种安全策略 计算/存储框架层的安全认证和加密传输 基于Spark我们做了什么 Web界面 基于Spark我们做了什么 基于Spark我们做了什么 性能/时效性 查询引擎与存储引擎紧密配合，解决IO瓶颈 翻译优化 规避慢节点 构建索引 充分利用内存 列式存储 减少框架开销 优化器 Limit 下推 create table as select a from table limit 10; Filter 下推：配合索引使用 select a from table where id=1; 列裁剪：支持嵌套结构 select from table; 隐含等值条件 select a from t1 join t2 on t1.id=t2.id where t1.id0; 基于Spark我们做了什么 规避慢节点 更合理的预测执行 长尾自动忽略 本机短路读 支持分发写 类似back-up request 读/写慢节点检测与切换 控制集群压力 基于Spark我们做了什么 有选择的构建索引（与Intel合作） 随机扫描 和 范围扫描（Random Scan Range Scan） 基于Spark我们做了什么 Name Age Department Salary JiangTao 26 INF 3000 Yuanjian 18 INF 1000 FangJun 34 INF 4000 ... 36 ... 2000 ... 21 ... 8000 ... 19 ... 7000 18 2 19 6 21 5 26 1 34 3 36 4 Index of Age 1000 2 2000 4 3000 1 4000 3 7000 6 8000 5 Index of Salary 有选择的Cache数据（与Intel合作） 基于Spark我们做了什么 Name Age Department Salary JiangTao 26 INF 3000 Yuanjian 18 INF 1000 FangJun 34 INF 4000 ... 36 ... 2000 ... 21 ... 8000 ... 19 ... 7000 Column Trunk In Memory Column Trunk In Memory Column Trunk In Memory 原Shuffle：基于磁盘的Pull 基于Spark我们做了什么 DCE-Shuffle：基于内存的Push 基于Spark我们做了什么 DCE-Shuffle：对接Spark ShuffleManager ShuffleWirter ShuffleReader DCE-Shuffle：性能 平均+30% 基于Spark我们做了什么 减少框架开销 Map Partition 数量 Reduce Partition 数量 根据复杂度评估数据量 调度开销 根据Query大小，自动复用AppMaster或者启用新的AppMaster 基于Spark