「观察」云原生数仓,破茧而出( 二 )


我们再从数据的常见载体—数据库做下分析 。 根据我们常见的两类数据应用操作型、分析型及数据结构特征关系型和非关系型 , 我们将数据库产品可按照这两个因素做个分类 。 下面我们重点讨论的是关系型的面对分析场景的产品 , 也就是图中的右上角象限 。 在这一象限内的产品 , 根据其发展特点可以简单分为两类:传统数据仓库和云(原生)数据仓库 。

  • 在传统数据仓库领域 , 从右上角图中可见 , 主要是以国外大厂为主 。 这里面包括了IBM、Oracle、HP、SAP、EMC、TeraData等 。 在技术特点上 , 普遍采用了MPP、列存技术;输出形态上有纯软和一体机的方案 。 发展时间上主要集中在2005~2010年前后 。
  • 在云(原生)数据仓库领域 , 从右下角可见 , 主要是以新兴云厂商为主 。 这里包括了AWS、Google、Microsoft等公司产品 。 其技术特点上 , 普遍在原有数仓的技术积累之上 , 与云端基础环境结合 , 输出形态为云端产品 。 发展时间上主要集中在2015~年后 。

「观察」云原生数仓,破茧而出文章插图
针对上述两类产品 , 我们做个发展对比 。 下图是根据db-engines网站数据所得 。 这一网站的数据库排名 , 是按照搜索引擎搜索量+主流论坛访问量+相关职位招聘量维度 , 反映数据库的受关注程度 。 下图中列出了常见的数据分析产品 , 包括了传统数仓产品Teradata、Vertica(HP)、Netezza(IBM)为代表 , 云数仓产品Redshift(AWS)、BigQuery(Google)、ADW(Microsoft)为代表 。 这两类产品的发展趋势有明显的差异 。 前者的发展比较平稳 , 后者发展更为迅速 。 两者在2020年左右 , 在局部产品上已经出现的交叉 。 也就是说 , 在这一年上 , 对新兴数仓产品的关注程度 , 已高于某些传统数仓产品 。
03 用户场景及需求变化
「观察」云原生数仓,破茧而出文章插图
【「观察」云原生数仓,破茧而出】从客户的使用场景来看 , 也如上图经过了阶段 。
  • “报表”阶段
从早期的以批处理和预定义查询为主 , 以报表为主要展现形式 , 辅助以少量的数据分析 。 此时的数据规模不大 , 并发量不高 , 以简单的数据库功能为主 。 其重点解决的是“发生了什么情况?” , 主要是企业事后了解业务情况为主 。
  • “分析”阶段
到了这个阶段 , 固定的批处理与预定义报表依然占据主要部分 , 但动态的交互式分析占比增大 。 此时的数据规模有所增大 , 并发量因需满足即席查询需求而增大不少 。 这个阶段重点解决了“为何发生这种情况?” 。 这个“为何”也导致需查询明细类数据造成的数据规模的增大 , 导致探索类的查询造成不确定的(非预定义)的查询增加 。
  • “预测”阶段
到了第三个阶段 , 固定的部分大幅减少 , 即席查询类、分析类的部分大幅增大 。 这个阶段重点强调的是建模能力 。 有了模型之后 , 才会为预测提供可能性 。 此阶段应用的复杂度大幅增大 , 特别是灵活多变的模型对应用提出了更高的要求 。 此外 , 这个阶段还出现了少量数据更新及对变化部分的查询 。 这是与之前阶段比较大的差异 。 这个阶段重点解决了“将要发生什么?” 。 这个“将要” , 正是模型带来的价值 。
  • “运营支撑”阶段
这个阶段没有太本质的差异 , 主要是对数据在变化情况下的实时性提出了更高的要求 。 数据的变化的实时捕捉、实时计算、实时反馈 , 成为运营支撑的基础 。 从技术上讲 , 对工作负载管理成为重点 , 如何避免不同工作负载的影响很关键 。 这个阶段重点解决了“正在发生什么情况?” 。 这个“正在” , 正是体现了对实时性的要求 。


推荐阅读