Longda's Interesting World

Longda's Interesting World

Redshift 产品分析 《Amazon Redshift and the Case for Simpler Data Warehouses》

论文解读 -- Redshift

Redshift 随谈

无意中看到《Amazon Redshift and the Case for Simpler Data Warehouses》这篇论文的读书笔记(应该是2018年写的)， 于是将论文笔记梳理一下，分享给大家。
这是2015年sigmod的一篇论文，这篇论文介绍了redshift 很多产品化的细节， 技术性探讨并不多(有一点aws 软文的感觉)，强烈建议云数据库类的产品经理好好阅读一下， 里面很多理念和产品化的做法aws 2015年就实现了，这在当时是非常超前的，而且有些东西至今国内很多云厂商都还没有实现。

总结

先来看一下2017年 Redshift 战绩： 2017财年， 整个aws 数据库部门营收是36 billion $, 而不同于其他数据库云厂商的是， Redshift 占比达到惊人的25%， 也就是9 billion $, 这个数字远远超过国内所有olap 数据库的总和， 简直就是一个天文数字。

整片论文，换个角度去看，我们带这问题 《How Redshift is success?》去看论文，会带来很多意想不到的思路：

  • Redshift 目标客户是谁？
  • 这个市场前景是多少？
  • 目标客户的需求是什么？
  • 怎么赢得客户
  • 架构和技术分析

Redshift 基本介绍

Redshift 是2013年推出来， 2014/2015年数据库部门增长率最高的olap数据库(Aurora 出来后，号称Aurora 是增长最快的)。

技术是基于ParAccel 系统演化而来， 这里一个小插曲，ParAccel 大概是硅谷一群做数据库的人，基于postgres 7.x 做出来一款mpp 数据库，这款数据库吸收了之前开源界很多数据库的设计，比如列存借鉴了c-store/monetdb/x100, 压缩技术类似vertica， 2008年左右，这帮数据库的人自己出来创业， aws 2009 年找到他们，购买了他们的源码授权， 结果2年后，ParAccel自己倒闭了，而aws的Redshift 越活越好（估计aws 没有少挖 ParAccel的人， ParAccel 肯定最后抗不住）。

今天看Redshift, 有一点点类似postgres-xl的架构，技术上，采用列存，并且支持列存压缩， 计算存储一体化， 支持本地join， code gen， 并且非常容易即可进行scale out。

数据同时存在s3 和db本地盘中， 每个数据同步写到第一个slice和至少另外一个node的slice中。当磁盘或节点出现故障时， 队列用于限制受影响的slice数， redshift 尝试平衡，重新replication的资源影响和当disk或node增长时，带来相应的失败。 数据异步同步到s3. primary和secondary /s3 上数据皆可以读取， s3 上的备份还可以放到其他region。
执行器， query plan会被编译成机器码， 多了一些overhead

和aws 很多service 紧密合作， 利用ec2 作为instance， s3 做备份， simple workflow（swf） 管控action， cloudwatch 作为用户实例的metrics， simple notification service（sns）作审计日志， key management service/cloudhsm 作为key management ， vpc 做security, 还利用了很多内部能力来做部署， 短期credential， 日志收集， metering。 可以利用s3 的高可用和便利的api， 允许我们自动备份， 持续，自动解决用户的需求， s3 还可解决本地存储的页错误， 实现流式恢复能力， 元数据和catalog 恢复后，即可sql 查询。

有一个manager 帮助部署引擎， 收集events和metrics， 生成实例事件， 归档/rotating 日志， 监控节点/db/日志错误， 还有少量功能执行受限操作， 管控平台是额外集群， 负责集群间的监控和报警， 初始的运维task， 终端用户的请求， 比如节点替换， 集群伸缩容， 备份， 恢复，部署，打patch。

目标客户是谁？

大部分的db vendor 目标都是大客户， 但Redshift 目标是olap的所有客户， 当DLA 和snowflake 在市场上获得成功后， redshift 立马推出与之对标的产品， 其目的就是解决所有olap需求。
在论文里，其实很清楚的写着他们的宗旨

1
宗旨： 如何更便捷的让用户消费redshift, 让用户非常方便，并且极高的性价比获得分析能力, $1000 /TB/Year

市场前景

论文对这的论断是： 分析市场占关系数据库(1/3, $14B VS $45B), GARTNER预估 每年8 ～ 11% 的增长， 过去10年， 分析的数据量是每年30～ 40% 增长， 过去的12个月，增速已经达到50 ～ 60%。
这个论断和国内的市场结果完全不一样， 国内olap市场大概只有1/10 的水准， 这个结果可能第一和国内olap数据库水平比较差； 第二，大家上云的需求量有区别，国内oltp比较重要，会对云厂商依赖重一些，而olap 系统挂了也没有关系，因此上云需求也就少了

客户需求是什么？

使用数据仓库的企业

传统的企业数据仓库， 收集各种数据源的数据， 通过bi 访问， 他们需要无缝从现有bi或etl 工具迁移过来， redshift 解放他们运维这些系统的压力并让用很轻松的scale-out/scale-in， 当迁移系统时， 他们更偏爱现有的db系统，而不care 系统是哪家厂商。 当硬件升级或license 到期，或到了规模上限或同厂商提供第二套系统但第二套系统和早期sql 不兼容时，他们会来尝试redshift， 针对这些客户， redshift 不断强化线性增长， 无限扩容， postgres 兼容， 并不断完善工具系统。

  • 释放DBA – 释放运维压力，附加工具不断完善
  • 让系统轻松scale-out/scale-in， 按需扩容
  • 良好的兼容性 –
    • 无缝兼容现有的BI/ETL 工具
    • 提供现有系统血缘相近的db
    • 保持协议兼容，现有系统可以继续使用

大数据客户

去年有一篇文章《大数据已死》介绍了大数据的3驾马车 cloudera/hontorworks/mapr 3家公司奄奄一息， 直到去年才暴露出大数据的问题。 其实早在redshift 一出来， redshift 就准备干死大数据这一套的开源系统。

论文这样描述：
半结构化的大数据分析， 常常对日志或事务数据集成分析， 一些客户从hive 迁移过来， 获得更好的成本和性能， 他们边用sql或bi工具来使用系统，简便是他们最care的特性之一， 他们没有dba团队， 数据存在大量无效数据， 并且他们需要更简便。 redshift 支持透明数仓， 在数据湖上或自动半结构化数据。

大部分的数据是dark 数据， 收集了但不分析， 没有什么用， 因此常常把数据存储到hadoop 或nosql（带冷热分离能力）只是解决了一部分的需求。成本， 大部分的商业数据库价格昂贵， 因此很难评估大数据清晰的价值

总结下来就是：

  1. 超强的性价比： 大数据常常是无效数据多， 因此需要极低的价格，
  2. 释放运维压力，使用大数据的企业没有dba，因此需要解决运维压力
  3. 兼容现有的bi/sql 即可

加速在线业务的客户

这种客户的特点是业务驱动， 消费大量原始数据， 跑大型sql 产生在线业务需要的结果， 比如广告技术，数据转化/数据消费， 客户用sql直接或申明式展示内容并在hadoop 生态也是一样， sql 越来越替代mr的使用。

samll data 客户

有一些用户并没有使用过传统数仓，他们直接运行分析任务在他们的事务系统中， redshift 帮助他们搭建数仓， 并获得性能提升， oltp系统offline并保留历史， 这些用户会有一个短的滞后， 自动数据变更和schema 自动创建和维护很重要。

价值点：

  1. 冷热分离， 将冷数据offline到redshift， 实际上对oltp系统有一定的加速
  2. 更强的分析能力，并且不影响在线业务
  3. 让用户快速搭建olap系统，并降低用户迁移成本， 自动数据变更， schema变更

怎样将用户吸引进来

Redshift 将如何将用户吸引进来，做的十分极致， 用了大量的手段：

  1. 简化购买流程

减少用户实验成本， 提供60天免费使用， 压缩ssd 到160g， 随后， 每个节点打包价$0.25/hour/node, 含软件和硬件维护费用

  1. 创建集群快， 即使是PB 级的cluster， 创建不超过15分钟。
    1.1 “time to first report”, 从一开始浏览网页， 评估redshift 服务， 发送第一个query， 获得第一个结果， 用零售的习惯去理解用户的行为， 对产品决策很有帮助。
    1.1.1 保持postgres odbc/jdbc 完全的兼容， 客户现有的系统无需修改即可使用
    1.1.2 价格体系是和容量相关
    1.1.3 减少前端步骤 如创建和配置， 能减少流失率
    1.2 打包交付， 提供给用户的信息只包含节点的数量和类型， 基本网络类型， 管理账号信息， 未来这些信息也尽可能少。
    1.2.1 早期创建集群耗时15minute， 后来通过预配置只需3分钟搞定
    1.2.2 减少错误成本， 用户可以自由实验， 让用户db 很方便收回和exchange， 头2个月免费使用160g 压缩ssd， 并且基于小时的计费方式，减少用户的负担
    1.2.3 用户可以任意伸缩容或部署一个新的集群，做并行迁移， 让老的集群只读

  2. 数据快速加载

10 minute load 5B rows, 9.75 hours load 150 B rows, backup 30min, restore 用了4.8 hour， join 2 万亿 和60亿 只花了14 minute
数据加载是一个特殊的query 过程， 使用修改过的postgressql copy 命令， 可以直接从s3， dynamoDB, emr, SSH 上获取数据， 多个slice 可以同时并行拉取数据， copy还可以直接支持json和压缩， 加密数据。

怎样将用户留下来

  • 性价比
  • 简单易用，释放运维压力
  • 稳定性第一
  • 后台推荐系统

性价比

redshift 目前基本超过现在能看到的开源olap 数据库或大数据系统， 并且提供极低的价格， $1000 /TB/Year， 这个价格下，很少有系统能提供如此高的性价比。

释放运维压力

  • 减少运维管理
    复杂性， 云上数据库需要解决数据库的复杂性， 比如部署， 运维， 备份， 调优. 减少管理， 减少迁移， 备份， 自动备份， 恢复， 部署，打patch， 错误探测和恢复， 高级功能如加密，伸缩容， 灾难恢复也只要点几下。

    1. 不需要dba， 不需要db 日常管理， 如安装，打patch， 监控， 修复备份和恢复。
    2. db的运维应该是申明式的
    3. 集群备份会均分到每个节点， 集群备份会自动执行和过期。
    4. 当需要备份到其他region， 用户只用点击click box 和选择region， 它会备份到本地或远程region， 恢复也是流式， 几分钟就能在其他region 进行恢复。
    5. 加密是很直接
    6. 未来， 用户不用初始的table 管理操作， 让他们接近备份操作， db能自我决定， 当load 过载或访问性能下降。
    7. 减少扩容担心， 价格仅和数据量相关， 管控操作也是并行的
    8. 部署和打patch是自动， 用户无感知， 一个星期一个feature， 快速迭代来寻找用户最关心的feature

  • 减少性能调优
    自动tuning， 默认设置是足够的， 高级用户可以做一些调优的操作， 比如自动挑选压缩类型， 通过多维-curve 来避免indexing 和projecting

    1. 很少工具来进行性能调优， 我们来承担这份工作， 用户只需关注db类型和节点数， 个别表的sort 方式和分布模型。
    2. 用户有时想设置一些参数， 比如列压缩类型， redshift 减少这种设置， 或者让这些设置更精准， db 提供足够信息如查询pattern， 数据分布，压缩成本
    3. 减少设置， sort column和key平衡分布， 我们的一个技术是减少后续优化操作
    4. 系统可以grow 或收缩 随load 变化， 减轻数据和查询的连接

一个功能就是， 在周5释放集群，在周日晚上恢复。

稳定性第一

对用户非常尊重， 每个节点增加1分钟的开销都需要很多天的调研， 一个缺陷的bug fix， 即使是1000多天才回让集群重启一下都要调研一下， 持续提高可靠性，可用性，自驱。
列了一些教训

  1. 2013年开始，几千套集群， 更偏重迭代而不是重构， 失败是很常见的， 当出现故障时， 降级比丢失可用性更关键， aws 有5千万的code， 经常会出现少量的regression， 当某个service 失去服务时， 让自己弹性很有必要。 我们每个data center 有预配置节点， 可以持续部署或替换节点，当ec2部署中断， 可以增加本地备份，防止s3 或网络故障。
  2. 不间断服务， 用户期望小的patch而不是大的， 打patch 是繁重过程， 因此自动打patch， 限制在用户允许的30分钟窗口内每周， patch 可回滚， 当出现错误或延迟时，可以自动回滚。 任何时刻用户只在一个patch verison， 这样可以很便捷的确认issue， 每两周推动新的engine， 以前是4周， 现在降低失败的概率

客户推荐系统

用pareto 分析调度任务， severity level 2 的报警才让engineer 参与， 否则研发会被日常维护给淹没， 系统自动收集日志，分析前10 的错误。 pareto 可以帮助了解用户需求， 每年会直接1v1 对话客户。