随着DT 时代的到来，企业占有的数据越来越多，其规模可能达到上百 TB 甚至 PB 级，如何以合理的成本管理并维护这样一个数据库也成为各个企业 IT 管理中的核心问题。 HybirdDB for MySQL 是基于 HTAP 资源的数据库，同时支持 OLTP ，在一份数据上做事务，又支持实时分析。 10 月 12 日的云栖大会· HTAP 技术专场中，阿里云产品专家陈琢分享了阿里云自研的 HTAP 数据库，并重点分享了相关技术及实现、如何借助 HTAP 技术解决业务痛点等内容。
本文分享的内容主要包括五个部分，首先是阿里云数据库产品团队的情况、用户实际的场景、线上问题不断处理过程中发现的用户需求、阿里云不断深耕数据库的原因，以及目前的产品特性和所解决的问题，包括在商业化后所积累的经验以及产品未来的发展方向。
进击的ApsaraDB
不断进击的数据库——在用户的支持下， ApsaraDB 不断砥砺前行，从 2011 年最初不断走来，承接金融云、承接双十一聚石塔、不断深入。从 2010 年开始， ApsaraDB 数据库团队跟着阿里云不断地成长，迄今为止经历了六、七年的时间，在这一过程中团队见证了中国云计算时代的风起云涌，也经历了几个重大的事件，比如接入金融云、支撑余额宝业务、以及即将到来的“双 11 ”引流项目，包括用户的订单业务都会在整个阿里云上运作起来。
在云计算的大背景下，团队也在不断地丰富产品，在产品、可靠性、场景化等各方面不断地做加法。连续五年，为了让用户把自己的业务托付给阿里云，每年都有超过1 千项以上的功能优化。在产品严谨过程当中，也不断地把主流数据库引擎以及方便用户使用的各种功能逐渐加入产品中去，对数据库的特性也不是简单用一个开源数据库产品、单一一个产品就能解决。其中随着接触用户的深入，阿里云也不断意识到自研数据库的重要性，终于在 2017 年重磅推出两款自研数据库引擎。
如今阿里云数据库已经聚木成林，如今有近20 款数据库产品在阿里云上。团队见证着一个互联网巨头迁移至云上，业务蓬勃发展，最终上市；也见证着众多初创业者借助云数据库的力量更专注于业务发展，迸发无限的创新力量，不断地发展壮大；还有细分行业中的众多优秀企业，借助云数据库的力量不断优化数据架构反哺业务改造，从而焕发更强的活力。目前在阿里云上有超过 10w 个付费实例在云上运行。
走向自研
下图是目前阿里云RDS 团队产品的情况，也是数据库团队做产品自研的背景。数据库部署在云上时，与传统安装包被部署到本地的情况较为不同，尤其是公共云上的硬件和架构情况，对于用户来说用到的只是数据库托管服务。但是对于 RDS 产品本身而言，不仅希望提供的是一个开源数据库服务，也希望在不断磨砺竞争力的同时创造更多的硬件红利。从 Gartner 的可操作型象限和数据仓库魔力象限中也可以明显看出 AWS 的强劲势头，随着云计算的逐步深入人心，云厂商必定会作为新一代数据库产品的排头兵，阿里云自然也不甘落后。自研数据库产品，在市场竞争力和用户黏性上而言具有独特的优势，这也是产品的初衷。
在通用RDS 的使用过程中可以发现其在云上受到了容量限制，在一个 RDS 池里既做业务也做分析，但用户对 MySQL 的分析性能却拥有很高的预期，这也就促使团队在架构本身之外转化出新的自研产品，增加产品性能，并且提升自身的市场竞争力。这是用户的需求，也是做自研的原因。 RDS 有性能评价等各种问题，对于数据库产品架构而言只有两条路：横向的 ScaleOut 解决方案，即 HybirdDB for MySQL 产品架构上的定位，并行处理、线性提升，用于解决 TB-PB 级的 HybirdDB 混合场景；还有一类是 ScaleUP 解决方案，有热点数据也有传统的基于 MySQL 的解决方案。但在 CPU 不能再扩的情况下还是需要考虑 ScaleOut 方案，把多年硬件能力和实践能力转化成下一代数据库产品。
关于HTAP 数据库的定义， Gtarner 提出了概念并发出了相关的 HTAP 市场指导手册：可同时支持 OLTP 和 OLAP 场景，基于创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去了费时的 ETL 过程。传统的 IP 架构有一些事务处理需要联机分析和分开处理， HTAP 数据库的出现则是希望在一份数据上同时支撑业务系统运行和做 OLAP 场景。可以想象，在一份数据库运行着账务、财务、业务等企业核心数据库的同时，也在进行报表分析，所以说可以省去很多额外的开销。不过 HTAP 只是表象，具体业务还需要看各家实现。
产品特性
HTAP 能力之源
HybirdDB for MySQL 是一个原生的云数据库产品，本身即为能力之源，不同于一些传统分布分表的方案。
首先是入口层面，分库分表对用户无感知，HybirdDB for MySQL 则是统一入口，对用户而言是一个比较透明的状态。在设计上，从链路到执行、到计算、再到存储，整个架构是比较松耦合的状态，可插拔可扩展，协调而又统一。整体而言是完全分布式的情况，可以做到分布式并行，写入、查询均可线性提升。在兼顾 MySQL 语法的情况下还自研了计算引擎，通过不断迭代使 MySQL 也具备了并行处理 MPP 的能力，这在做 OLAP 场景下还是比较有利的。
架构演进
目前来说，HTAP 的用户底层存储用的是 MySQL ，实际业务中为了计算更快也在自研 MySQL 上列存引擎，行列混合，以此达到两边能力的均衡。对于用户而言，整个 HybirdDB for MySQL 就是性能加强、功能和 MySQL 完全一样的分布式数据库，当然用户原来基于 MySQL 开发的应用、一些基于其它报表工具做的报表都可以无缝移植到 HybirdDB 产品上来。
强劲的并行处理
用户在使用HybirdDB 产品能力时具备 TB 级写入性能。写入对用户而言是实时可见的，并且具备事务特性，产品在写入里也做了相应优化，以此来达到整体的性能指标，对于传统 MySQL 而言也引入了自研的计算引擎，产品性能大幅提升。不管行存引擎还是列存引擎，降低成本、提供更高压缩比的存储一直是项目需要不断攻克的难关。目前对用户而言，部分数据落到产品里的时候，数据量也是较为可观的。目前的售卖规格里，如果用户选择了对应的规格后发现运行过程中的计算能力或容量不够时，可以自动发起扩容的动作。扩容过程中系统是可写的，处理 PB 级数据能能动态扩展，提供并行的解决方案。
沿承RDS 使用体验
除去产品本身的能力情况，HybirdDB for MySQL 还延承了 RDS 的使用体验，严格遵循 SQL 标准。另外在语法层还做了相应增强，包括 Oracle 语法、支持分析函数以及 TPC-H/TPC-DS 标准，原生 MySQL 和一些主流的开发框架都可以很方便地接入产品。此外 HybirdDB for MySQL 还延承了 MySQL 的管控，对用户而言看到的就是控制台里和类似 RDS 功能分类的内部运维体系。在日常使用管理上，还有 DMS 、 DTS 等 MySQL 生态的上下游产品，支持决策云上阿里的 QuickBI 服务。因为延承了 MySQL 生态，其它的产品都是可以支持的。
服务稳定可靠
对于一款数据库产品而言，产品本身的稳定性是非常重要的指标。HybirdDB for MySQL 的稳定性也是设计的第一要务，因为 HTAP 会有用户业务需求跑在上面，对数据库本身的稳定性要求会比较高。 HybirdDB for MySQL 提供了三方面保护：并行和恢复备份、多备份集、一键上传 OSS ，这是数据级保护；还有服务级保护，连接防闪断无感知（服务的保障是 99.95% 的状态）、存储节点多副本、自动故障切换、平滑扩容不停机；以及 IDC 级保护，目前 HybirdDB for MySQL 也在阿里云专有云输出，在专有云环境下支持两地三中心部署。
自我突破，快速演进
以上提到的都是HybirdDB 本身功能情况，因为是自研产品，所以输入的内核功能较多，需要不断做产品的迭代。项目对数据库不会锁表，会有柔性的处理，带来的开销对比传统方案也会更小。目前已经支持 RDS 了， HybirdDB 在 10 月底也会很快支持序列操作和分布式事务。在售卖上，现在已经在 Apsara StackV3 专有云新增了售卖区。在规格上，云栖大会之后马上发布一个新的规格，全面增强 OLAP （这个规格目前已经开放出来，火热邀测中）。对比 MySQL 实际上还是会有用户提出很高的要求，这也是产品不断迭代的动力。
场景和方案
在场景上，HybirdDB for MySQL 本身的定位是实时可见、混合分析并激活整个企业数据。在 2017 年 3 月份商业化后的大半年中， HybirdDB for MySQL 在大数据分析、海量历史库、物联网、性能监控等业务领域得到广泛应用，目前每天有超过 PB 的数据通过 HybridDB for MySQL 进行管理和实时分析。
这里大致罗列了几类应用场景，比如高吞吐实时DML 操作、要求事务可见性、高并发的情境下，典型的有实时指标监控类应用、实时推荐类应用；再比如有实时写入、低成本存储、响应时间块、并发不高、数据无法预建模的情境下，典型的有营业指数类应用、交易历史库类应用；还有数据集中、实时处理和分析、要求事务可见性的情境下，典型的有 HTAP 类场景、混合数仓类场景等等。
典型场景
如下图所示是一个典型的HybirdDB for MySQL 应用场景。 HybirdDB for MySQL 就是在 RDS 内部不断做演进，在 RDS 内部使用时将用户的源数据或流式数据布到 HybirdDB for MySQL 上，在内部系统实时数据写入的同时从不同维度对 RDS 健康状态实时监控分析的产品。例子中存在多个业务痛点：需要基于海量监控数据深度挖掘异常点与趋势，多维度可视化展示 RDS 的服务质量；需要满足高吞吐类的业务等等。 HybirdDB for MySQL 的应用方案价值也显而易见：结构化数据、流式数据、离线数据回流，多种数据高并发写入；并且实现了 PB 级海量数据的管理；同时还提供了实时数据仓库基座。
力助多媒体云服务的快速发展
在多媒体应用上，HybirdDB for MySQL 给整个阿里云产品提供了稳定可靠的数据库服务：智能图像解决方案 CloudPhoto+MTS+CDN ，视频类及解决方案 LiveVideo+MTS+CDN 等等。 CDN 、视频直播、视频转码，很多多媒体的产品数据都放在了 HybirdDB 上，提供了持续稳定、能力均衡的数据库服务。
目前该方案在海外还没有售卖，随着业务扩张也将在海外进行部署。
企业级解决方案之某政务物联网数据方案
这个案例比较典型，比较偏物联网的业务系统应用，同时用户在上面还会定期出一些报表。用户原来数据在OTS 上做历史文献分析，用户行为分析在离线数仓里做，这是比较典型的路径，也是阿里云专有云团队下半年比较典型的应用，税务系统主流的方向。物联网数据数据 340 亿，约 40TB ；非结构化 PDF 数据， 80TB ；需要事务保护，有标签回写等更新操作——在这些业务痛点下， HybirdDB for MySQL 提供了架构清晰、成本可控、运维方便的方案。
企业级解决方案之云上ODS 数仓融合解决方案
DBA 部门和大数据部门天生是两个部门，在大数据部门有分析需求的情况下， DBA 的通常做法是搞一些主流备库。有没有可能通过一些新的方案做 T+0 实时报表？这也是比较典型的方案。例子中的业务痛点有很难做 T+0 分析，需要数据搬运； DBA 与数据分析部分存在灰度区域；基于只读实例数据分析，导致开发复杂度大、节点数越多运维成本陡增以及额外增加的运维成本。案例实现了多方面价值： HTAP 能力快速构建 ODS+DW 层； T+0 分析支持， ODS+ 离线回流结果；降低开发和运维成本；明确部门职责，消除了灰色地带；生态成熟稳定。
发展和展望
做一款数据库，通吃所有场景是不可能的。立足HTAP 场景，找到平衡是核心场景之一，尤其是数据库本身核心能力，包括云产品核心能力，把本地位置放在第一位。稳定第一位的同时，给用户提供更多的成本、性能、效率上的提升，逐步走向自治。一般来说，数据库产品想做成通用的产品还是有难度的，所以需要将需求层及用户作为主要需求动力，同时兼顾一些竞品的操作，快速响应以释放新一代的硬件红利，给云上用户提供更好的运维体验。
最后是HybirdDB 的目标定位，希望能解决一部分业务处理的同时提供更多的分析性能。当然团队也在朝着这个目标做不断的迭代，做不断的努力，也希望能给用户提供更好的数据库服务。马老师 18 周年时曾说到家国情怀和社会责任，做好基础软件也是一件很值得骄傲的事情，对国家而言自主可控、安全可靠，为网信事业添砖加瓦；社会而言提供更更强劲的数据管理能力，普惠技术红利。
