百度MPP数据仓库Palo开源架构解读与应用 牟宇航 百度

2020-03-01 347浏览

  • 1.百度在线数据仓库Palo ——开源架构解读及应用 百度大数据部 牟宇航 2017.12
  • 2.
  • 3.
  • 4.
  • 5.Palo • • • • • • 名字由来：PALO <->OLAP A MPP-based Interactive Data Analysis SQL DB 百TB ~ PB级别，结构化数据，毫秒/秒级分析 百度大数据部研发，第三代 OLAP 产品 – Doris -> OlapEngine -> Palo 百度内部署1000+台，单一业务最大500TB 17年8月开源，10月通过“大数据产品能力评测”
  • 6.场景一 • 某在线报表业务 • • • • • • 为网站站长提供流量分析，网站分析，受众分析等多种分析服务 300+表，数据清洗结构化后百TB+，单日增量1TB+ 查询峰值QPS 2000+，日查询量千万级 一致性（会话内单调一致性、更新一致性） 导入5分钟一次 查询平均延时30+ms
  • 7.场景二 • 某业务数据集市 • 集运营、业务分析、订单管理、会员管理、客户关系管理等数十个管理分析平台 一体的综合数据平台 • • 100+主题视图、10-100TB 标准SQL，Ad-Hoc（即席查询），秒级分析
  • 8.场景三 • 某在线多维分析平台 • • 100+表，最大单表50+维度列、10+指标列，任意组合，秒级分析 10-100TB
  • 9.场景 • 以前 • • • 报表：Hadoop + MySQL 分析：Hadoop + Hive 现在 在线报表 在线多维分析 即席查询 在线数据仓库 Palo
  • 10.Palo在百度大数据技术栈的位置
  • 11.Palo在友商技术栈的应用
  • 12.在线数据仓库——OLAP • Online Analytical Processing • Online vs. Offline (Interactive vs. Batch) • Analytical Processing vs. Transactional Processing OLTP OLAP 面向应用 日常交易处理 明细查询，分析决策 访问模式 简单小事务，操作少量数据 复杂聚合查询，查询大量数据 数据 当前最新数据 历史数据 数据规模 GB TB ~ PB 数据更新 实时更新 批量更新 数据组织 满足3NF 反范式，星型模型
  • 13.OLAP-商业产品 产品 简介 技术特点 收购情况 Netezza 2000年在美国成立 Netezza TwinFin 软硬一体机 采用FPGA数据过滤代替索引 2010年9月20日，IBM出资17.8亿美 元收购 Greenplum 2003年在美国成立 Greenplum Database 行存 + 列存 Shared-Nothing集群 2010年7月6日，EMC出资3亿美元收 购 Vertica 2005年在美国成立 Vertica Analytic Database 列存 Shared-Nothing集群 2011年2月，HP出资3.5亿美元收购 Aster Data 2005年在美国成立 nCluster SQL-MapReduce Shared-Nothing集群 2011年7月6日，Teradata出资2.63亿 美元收购 ParAccel 2005年在美国成立 PADB 列存 + 自适应压缩 Shared-Nothing集群 2013年Actian出资1.5亿美元收购， Redshift宣称使用ParAccel
  • 14.OLAP-开源社区
  • 15.百度OLAP功能需求 • • 基本需求 – – – high availability Scalability High Performance 特化需求 – – – – Consistent View Monotonic Consistency Heterogeneous Storage ……
  • 16.Palo定位 低成本 线性扩展 1/10 ~1/100 Cost 100~200节点 / 1000 TB 高可用 高查询性能 99.9999 % Uptime 10W QPS/ 100GB/s 支持云化部署 高加载性能 10 TB / Hour
  • 17.Palo整体架构 • MPP通用构件
  • 18.中心架构（Centric Architecture） Master may be bottleneck
  • 19.对称架构（Symmetric Architecture） 1. 违背会话单调一致性 2. 元数据冗余 3. Planner和executor争内存 4. 广播元数据，可能有网络瓶颈
  • 20.混合架构（Hybrid Architecture）
  • 21.Palo整体架构 • Hybrid Architecture – Leader * 1 + Follower * 2 + Observer * n – 高可靠；高QPS；可动态扩缩容；支持频繁的元数据更改 MySQL Tools (MySQL Networking) Palo-FE (Leader, Java) Palo-BE (C++) Palo-FE (Follower, Java) Palo-BE (C++) Palo-FE (Follower, Java) Palo-BE (C++) Palo-FE (Observer, Java) Palo-BE (C++)
  • 22.集成式系统 • Integrated system VS layered method – – – 多表原子导入 进程内通信 VS 进程间通信 易于开发和调试 MySQL Tools (MySQL Networking) Palo-FE (Leader, Java) Palo-BE (C++) Palo-FE (Follower, Java) Palo-BE (C++) Palo-FE (Follower, Java) Palo-BE (C++) Palo-FE (Observer, Java) Palo-BE (C++)
  • 23.Palo使用 MySQL Client MySQL Proxy MySQL Protocol Layer Frontend • 轻量级客户端 • 与上层应用兼容容易 • 学习曲线平缓，方便用户上手使用 • 利用MySQL相关工具，比如MySQL Proxy
  • 24.Palo使用
  • 25.Palo使用
  • 26.Palo使用
  • 27.Palo使用
  • 28.元数据高可用 • • Memory + Checkpoint + Journal 采用 Berkeley DB Java Edition，类Paxos协议实现， Log Replicating Followers Leader Metadata In MEM Checkpoint.10 LOG.11 Observer Metadata In MEM Checkpoint.10 LOG.11 Checkpoint.10 LOG.12 LOG.12 Checkpoint.13 Checkpoint.13 Metadata In MEM LOG.11 LOG.12 Checkpoint.13 LOG.13 LOG.13 LOG.13 LOG.14 LOG.14 LOG.14
  • 29.元数据一致性保证 • 会话内单调一致性 – – • Master Follower和Observer 多个会话间（尤其在失败重试时） – 提供sync命令来手动同步
  • 30.数据高可靠 • • • 默认三副本 自动均衡 自动补充
  • 31.MPP执行
  • 32.向量化执行&LLVM • 向量化 – 行式执行引擎问题 • 每行一次函数调用，打断CPU流水，不利于分支预测 • 指令和数据cache miss • 编译器不友好，不利于循环展开，SIMD – 设计思想 • 单条处理到批量处理 • 行式处理转化为列式处理 – 效果：star-schema测试整体提升3~4倍 • LLVM – 运行时代码生成 – 大型ad-hoc查询可提升5倍以上
  • 33.存储格式-列存 数据按列存储，每一列单独存放 只访问查询涉及的列，大量降低I/O 数据类型一致，方便压缩 数据包建索引，数据即索引 w w w .gbase.cn GBase 8a 技术白皮书 Palo存储引擎利用原始过滤条件以及min、max和sum智能索引技术 GBase 8a 核心功能 4.3.2. 智能索引使用原理 将数据集查询范围尽可能地缩小，可以大大减少I/O，提升查询性能 c d e 100101 a (date) 8, 10 b (int) ... ... ... True = 完全确定 100101, 100102 5, 25 ... ... ... Possible = 有可能 可以进一步优化结合其它条件过滤后确定 100102 30, 50 ... ... ... 100103 1, 5 ... ... ... False = 完全排除 不需要读取列数据 {min, max, sum, ...} 100101, 100101 8, 10, 600000 100101, 100102 5, 25, 1155261 600000 + 24351 select 必须读取列数据 结果集 from a sum(b) as b mytab where a<='100101' 过滤条件 I/O group by order by a b desc 基本算子 b列一个需要打开的数据包 假设一个表 mytab，按列存储了 a、b、c、d、e 五列，GBase 8a 存储引擎将每
  • 34.数据模型-Schema • Google Mesa模型 • • Key列有序存储 • • 维度（Key列），指标（Value列） 查询快速定位 全Key全局唯一 • 相同Key的行，其Value列自动合并(SUM,MIN,MAX,REPLACE) Time Id Country Clicks Cost 2016/12/31 1 US 10 32 2017/01/01 2 UK 40 20 2017/01/01 2 US 150 80
  • 35.数据模型-预聚合 Base Time Id Country Clicks Cost 2016/12/31 1 US 10 32 2017/01/01 2 UK 40 20 2017/01/01 2 US 150 80 + Delta New Base Time Id Country Clicks Cost 2017/01/01 1 US 5 3 2017/01/01 2 UK 60 30 2017/01/01 2 US 50 20 Time Id Country Clicks Cost 2016/12/31 1 US 10 32 2017/01/01 1 US +5 +3 2017/01/01 2 UK 40+60 20+30 2017/01/01 2 US 150+50 80+20
  • 36.数据模型-多版本
  • 37.数据模型-更多存储模型 • 聚合模型的缺点 – – 不易理解，某些Olap场景没有聚合需求 读放大 value列的过滤条件无法下推 count一个列会造成读取所有列 • – 较多key列时，排序本身可能成为瓶颈 更丰富的存储模型选择 – – – DUPLICATED KEY UNIQUE KEY AGGREGATE KEY
  • 38.物化视图(rollup) • • • 以空间换时间 – – Base表中列的子集 按指定列排序 key列重新排序 查询时自动选择 导入原子生效 时间 Id 省份 pv 2017.01.01 1 北京 10 2017.01.01 2 天津 30 2017.01.02 1 北京 20 2017.01.02 2 北京 40 Base表 Id 时间 省份 pv 1 2017.01.01 北京 10 1 2017.01.02 北京 20 2 2017.01.01 天津 30 2 2017.01.02 北京 40 聚合表 Id pv 1 30 2 70
  • 39.两层分区 & 分级存储 • 两层分区 • • • • 方便新旧数据分离，使用不同的存储介质（新数据SSD，历史数据SATA） 减少了大量历史数据不必要的重复合并，节省了大量的IO和CPU开销 简化了表的扩容，shard调整 分级存储 • 用户可以指定数据放到SSD上或者SATA盘上，也支持根据TTL将冷数据从SSD迁 移到SATA上，高效利用SSD提高查询性能
  • 40.Online Schema Change • • • 变更期间不停服，用户业务上层不需感知 加列、减列，修改列类型等 详见 help alter table
  • 41.数据导入 • • • 按批导入 异步 – Show load查看状态 Label机制 – 防止数据被重复导入
  • 42.数据导入 • Broker – – – 支持直接从HDFS、Baidu BOS上进行数据读取。 每个物理机部署broker进程，提供并发读取能力。 可以访问外部表。
  • 43.数据导入 • MINI BATCH – – 使用http即可导入，减少客户端对其它组件的依赖 实现了多表导入的事务提交
  • 44.资源隔离 • 问题 • 解决 – 多用户影响 – 线程级cgroup – 单用户多任务影响 – 两级资源组织
  • 45.部分SQL增强 • 支持窗口函数 • • 计算排名、同环比问题变得简单高效 同一部门内，薪水最高的三位？ rank() over (partition by dept order by salary) • 类Proc机制 • • Show proc ”/XX” HELP • • • 在线查看帮助文档 Web help Help xxx
  • 46.联系方式 • GitHub：https://github.com/baidu/palo• 百度云：https://cloud.baidu.com/product/palo.html• 邮件： palo-rd@baidu.com • Palo开源讨论群： 加我的微信，备注“加入Palo技术讨论群” myh13161636186
  • 47.谢谢