十问 PingCAP CTO 黄东旭：Oracle 为 MySql 加上的这个新功能，让 HTAP 企业们更兴奋还是更忐忑了?

12 月初，Oracle 在其官网正式推出 “MySQLDatabase Service with Analytics Engine（简称 MAE）”。作为 MySQL 产品的一个重大增强，这一特性颇为引人注目。

作为 Oracle 旗下最为流行的一款开源数据库，MySQL 已经得到非常广泛地使用，在最新的 db-engines 指数中，MySQL 排名第二，在数据库领域占据着重要的位置。但作为一款如此流行的数据库产品，其存在一个明显的短板就是数据分析。

由于 MySQL 原生便是为 OLTP 场景设计的，并没有考虑 OLAP 场景。所以即使有部分厂商也基于开源 MySQL 拓展了一些数据分析的能力，但是总体而言不尽如人意。伴随着此次 Oracle 原厂正式推出了 MySQLAnalytics Engine ，在一定层面上表示了 MySQL 对于 OLAP 场景的重视。

而在这背后，迫使 Oracle 主动做出调整变化与产品更新的更深层次原因是什么呢？哪些最新的技术趋势正在成为这一事件发生背后的核心推动力量？带着这些疑问，InfoQ 记者通过书面形式特别采访了 PingCAP 联合创始人兼 CTO 黄东旭，并第一时间得到了以下回复。

数据库技术架构演进：HTAP 正在成为新趋势

1、 Oracle 推出 MAC 这件事情反映了其对于 OLAP 技术的高度重视，这背后反映的是数据库发展领域的哪些新兴技术趋势呢？

在互联网浪潮出现之前，企业的数据量普遍不大，特别是核心的业务数据，通常一个单机的数据库就可以保存。那时候的存储并不需要复杂的架构，所有的线上请求 (OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online AnalyticalProcessing) 都跑在同一个数据库实例上。

随着互联网的发展，企业的业务数据量不断增多，单机数据库的容量制约了其在海量数据场景下的使用。因此在实际应用中，为了面对各种需求，OLTP、OLAP 在技术上分道扬镳，在很多企业架构中，这两类任务处理由不同团队完成。当物联网大数据应用不断深入，具有海量的传感器数据要求实时更新和查询，对数据库的性能要求也越来越高，此时，新的问题随之出现：

OLAP 和 OLTP 系统间通常会有几分钟甚至几小时的时延，OLAP 数据库和 OLTP 数据库之间的一致性无法保证，难以满足对分析的实时性要求很高的业务场景。企业需要维护不同的数据库以便支持两类不同的任务，管理和维护成本高。因此，能够统一支持事务处理和工作负载分析的数据库成为众多企业的需求。

在此背景下，由 Gartner 提出的 HTAP（混合事务 / 分析处理，Hybrid Transactional/Analytical Processing）成为希望。基于创新的计算存储框架，HTAP 数据库能够在一份数据上同时支撑业务系统运行和 OLAP 场景，避免在传统架构中，在线与离线数据库之间大量的数据交互。此外，HTAP 基于分布式架构，支持弹性扩容，可按需扩展吞吐或存储，轻松应对高并发、海量数据场景。

新技术的发展和业务场景的需求，共同推动了 HTAP 数据库这一趋势的到来。

在互联网浪潮出现之前，数据量比较少，OLTP 和 OLAP 确实是可以跑在一个数据库单机实例上的。只有在业务量上升到一定量级，架构师们才需要考虑将这两种业务拆开，分别用针对性优化的数据库来支撑。但是随着技术的发展，最优解永远在变化。

分布式架构在数据库领域的落地，让计算和存储能力得以横向扩展；分布式一致性同步算法，让数据得以在各个节点间保持一致；强大的优化器，可以从异构的数据形态选出最佳数据源；存储技术的发展，让列存实时更新成为可能……等等这些技术的发展都让 HTAP 数据库的出现成为可能。

业务侧，核心的需求是降本增效。但是使用异构的系统往往带来巨大的研发、运维成本，并制约业务的开展。一方面，把数据在两个异构系统之间同步，并且要互相配合支持业务，是一件非常困难的事情。比如依赖传统的手段，OLTP 和 OLAP 系统之间的数据流转依赖于 ETL。ETL 过程会带来较大的同步延迟，无法满足实时分析的要求。而在另一方面，异构的 OLTP 和 OLAP 系统之间的数据一致性无法保证，在需要实时、准确数据的处理场景往往无能为力，比如风控、物流等场景。

而 HTAP 就是解决以上业务侧痛点的一个完美方案，值得一提的是，优秀的 HTAP 方案并没有牺牲 TP 或者 AP 的能力——这既是一个技术升级，也是对数据库使用方式的回归。类似于智能手机能解决打电话、拍照、娱乐社交等需求，而且还比传统拍照手段解决的更好。

2、在技术实现层面，传统的 OLTP 与 OLAP 在技术实现上是如何区分的呢？二者又会如何配合工作？主流的 HTAP 技术是如何将两者结合起来的？

OLTP 数据库通常有较为完整的事务支持，并且提供完整增删改查能力，追求高 TPS 和低延迟。OLAP 数据库则注重解决在线分析的需求，更短时间内呈现更多的分析结果。OLAP 需求更为多变，业务复杂程度高，业界有不同的解决方案和侧重点。比如有些产品通过预计算提高并发能力，然而灵活度受限；有些产品为了性能，牺牲了更新能力，只能对静态数据进行分析；有些则为了极致的性能为某些场景做了特化。几乎所有的 OLTP 数据库存储引擎使用行存，绝大部分的 OLAP 数据库使用列存。

传统的使用方式，需要在 OLTP 和 OLAP 数据库之间架设数据同步通道，业界称之为 ETL(Extract, Transform and Load)。它定期的，把 OLTP 的数据全量或者增量的方式同步到 OLAP 数据库。这两个体系之间配合工作是比较困难的事情。比如他们使用不同的 SQL 方言；另外他们的数据一致性难以保证，需要在业务侧做大量的工作；使用者还需要解决多个数据库，不同的数据模型，以及数据同步工具等带来的运维挑战。

目前 HTAP 方案主流大体有两个方向，根据 OLTP 和 OLAP 负载是否使用相同的节点或者引擎，分为统一架构和分离架构。

统一架构的代表是 SAP Hana、OracleIn-Memory Column Store、SingleStore、Kudu 等，它们的特点是一个节点同时提供 TP 和 AP 能力，存储结构上通常使用行列混合的架构。如 SingleStore (原名 MemSQL) ，最新的数据是内存中的行存形态，而落盘的数据则使用列存。通常这个架构由于要兼顾 TP 和 AP 的能力，所以任何一方面都难以得到充分的优化，性能往往不如分离的架构。

分离架构的代表有 TiDB，Google F1Lightning, 以及 MySQL DatabaseService with Analytics Engine 等。他们分别用不同的子系统实现 OLTP 和 OLAP 的功能，中间使用高效的同步协议把 OLTP 子系统的数据更新实时同步到 OLAP 子系统，然后提供的用户层（SQL）可以自动选择最优的数据源。这种新兴的架构有巨大的架构优势，可以充分发挥不同子系统的能力，而且对用户非常友好。由于物理上对不同的 workload 进行隔离，TP 和 AP 的业务可以互不影响。而不同子系统可以根据业务压力单独扩展，非常适合云环境部署。

Oracle 推出 Analytics Engine 对行业的影响

3、HTAP 数据处理技术正在成为趋势，Oracle 推出 MySQL 的 MAE 功能，这是否也意味着 Oracle 开始准备研发集合了 OLTP 与 OLAP 于一体的 HTAP 数据库产品呢？

其实 Oracle 很早就已经为 HTAP 而优化，例如 Oracle 数据库从 12.1 就开始支持 In-Memory Column Store，它是一个为 AP 而优化的纯内存的列存数据副本。用户可以为需要 AP 加速的列打开 In-Memory Column Store，行存的修改会自动同步给列存。但是如上所述，这个架构存在天然的问题，主要是隔离性和扩展性。MAE 的出现，也可能预示着 Oracle 这个目前的商业数据库老大接下来会有新的动作。

4、你们是否从技术层面研究过 Orace 此次推出的 MAE 数据分析型引擎，在技术实现层面，MAE 是如何实现与之前的技术相结合的？是什么样的组合接入方式？

我们一直跟进业界的最新产品和技术，MAE 也不例外。目前从公开的资料，MAE 的功能属于闭源产品，Oracle 对于实现细节也还没有过多的介绍。整体架构上，Oracle 为 MySQL 增加了独立的 Analytics Cluster，它使用 shared nothing 架构，以列存形态存储数据，并且数据是纯内存的。并使用一个嵌入 MySQL 实例的 Analytics Plugin 把 InnoDB 的数据更新实时同步到 Analytics Cluster。用户的查询仍然放送到 MySQL 实例，它会智能的决定哪些查询发往 AnalyticsCluster，并提供 Read Committed 的事务隔离级别。

5、从技术维度来看，基于 MySQL 的 MAE 功能推出，为开发人员或者说企业数据管理带来了些什么样改变，有哪些有益的提升？同时还存在哪些待改进之处？

 MAE 极大的提升了 Oracle Cloud 上的 MySQL DatabaseService 的分析能力，注意这个能力只有在 Oracle Cloud 上提供，并没有放在 MySQL 社区版内。对于 on-premise 用户想使用这项功能，Oracle 提供了贴心的建议：通过 MySQL 从库的方式，把本地 MySQL 实例同步到 Oracle Cloud。

从功能上看，目前 MAE 的完成度还有一定提升空间，比如任何 DDL 操作都需要 reload 列存副本的数据；另外 Read Committed 的隔离级别还是差点意思；以及纯内存的工作方式，对于高可用和成本方面是不小的挑战。

6、对于 PingCAP 这一类集成了 MySQL 、同时瞄准 HTAP 数据库技术发展的厂商带来了哪些影响？

更多的是积极的影响，类似于传统汽车厂商开始造新能源汽车了。可以带动企业新技术选型，对整个行业释放更多积极的信号。

推动 HTAP 向前发展的技术实践主体、团队及企业们

7、目前在市面上在积极布局 HTAP 的主流玩家都有哪些？各自有什么特色？

现在不少数据库开始给自己打上 HTAP 的标签。在关系型数据库领域，个人认为较为正式且有影响力的有 SAP HANA ATR, Google F1 Lightning，SingleStore 以及 TiDB。其中 Google F1 Lightning 和 TiDB 都在今年的 VLDB 上有 HTAP 主题论文发表，在工业界和学术界引起广泛讨论。

SAP HANA ATR 的架构其实和 MAE 比较相识，它通过引入额外的列存副本，把主节点的数据实时同步到副本节点。主节点使用行存，副本节点使用列存，且副节点可以有多个。HANA 是 in-memory 数据库，所以主、副节点的数据都使用内存，使用 Recovery log 和 Check point 保证数据持久性和快速恢复。由于节点间的数据存在一定的延迟，为了保证数据库的事务可见性，HANA 的做法是在事务中记录一个 changed table list，对这些表的读直接去主节点读数据。个人理解这种做法不能完全保证 Read Committed。这里主要参考 HANA 2017 年的论文，可能存在信息滞后的情况。

SingleStore 也是内存数据库出身，它使用的 HTAP 方案相对异类，即上面提到到统一存储引擎的方案。它希望用一套存储引擎同时解决 OLTP 和 OLAP 的需求。最新的数据以行式的形态放在内存，数据落盘后使用则转化为列存。SingleStore 只支持 Read Committed 隔离级别。

Google F1 Lightning 是 Google 为自家的 F1 DB 提供的 HTAP 方案，目标是做成 HTAP-as-a-service 的形式，并且使用松耦合的方式来整合 OLTP 和 OLAP 系统。它把 OLTP 系统的更新通过 CDC 的方式实时同步到 OLAP 系统，即 Lightning Server。Lightning Sever 的存储结构使用行式+列式的结构。内存中最新的更新是使用行式结构的 B-Tree，当数据写到磁盘则转化为列存格式。用户的所有查询，全部发送到 F1 Query 层，然后它会决定这条查询发往原来的 F1 DB（OLTP）还是 Lightning Server（OLAP）。他们通过这种无侵入的方式，提升系统的 OLAP 能力，从用户角度，甚至不会意识到 Lightning Server 的存在。Google F1 Lightning 支持 SI 隔离级别。

TiDB 作为较新的分布式关系型数据库，它的设计从一开始就考虑到为 HTAP 而优化。TiDB 有两种存储节点，他们是 TiKV 和 TiFlash，分别适合支撑 OLTP 和 OLAP 业务。TiKV 存放行存副本，而 TiFlash 存放列存副本，行存副本和列存副本都支持在线 DDL。TiKV 和 TiFlash 之间使用 Raft 分布式一致性协议来进行数据同步，这种内部的数据同步协议相比于 CDC 或者 binlog 的方案，可以更好的保证数据同步延迟。在上层，统一使用无状态的 TiDB 节点或者 TiSpark 来查询。优化器可以智能选择最优的数据源，并尽可能的把查询下推到存储节点，以获得最好的查询性能。用户可以根据用况选择单独扩展 TiKV 或者 TiFlash 节点。这种架构为 on-premise 和 on-cloud 部署都带来了很多优势。TiDB 的事务支持 SI 隔离级别，并提供悲观（兼容 MySQL）和乐观两种事务模型。

8、目前 HTAP 领域内各利益相关主体之间的竞合关系是怎样的？哪些比较强势？未来行业发展会呈现出什么样的趋势？

HTAP 从历史上看并不算是一个完全新的事物，因为它就是数据库最原本的样子。业务的需求导致之前很长一段时间内，我们不得不把 TP 和 AP 拆开来实现。目前市场已经慢慢的认识到，随着技术的发展，HTAP 其实是完全可行的方案。另外 HTAP 还是要落地到具体的功能，即要看系统的具体的 OLTP 和 OLAP 能力，以及他们互相结合产生的产品优势。

9、PingCAP 是非常典型的新一代 HTAP 数据库企业，优势在于解决了之前 MySQL 等数据库无法解决的分析型数据处理问题，伴随着着如今 MySQL 推出分析型数据引擎，公司是更加兴奋了还是更加的忐忑了？

有一点儿兴奋，PingCAP 有自己独特的优势，MAE 的出现只会让我们更加坚定 HTAP 是一条正确的路径。TiDB 几乎 100% 兼容 MySQL 生态。我们相信 TiDB 的分布式架构，在目前以及未来的业务形态中有很大的优势。TiDB 有遍布全球的活跃开源社区，有在本地以及云上的任意 Scale 的能力。

TiDB 现已被近 1500 家不同行业的领先企业应用在实际生产环境。它已经进入了很多国内外头部企业的核心生产系统，包括银行、金融、物流、制造、互联网等行业，成为默默支撑大家日常生产、生活的基础架构。我们在今年正式推出了 DBaaS 服务，让在云上使用 TiDB 的成本降到最低。

正在成为数据库技术发展热门的技术方向

10、未来，哪些数据库技术领域的前沿热门方向正在受到越来越多的企业、用户关注，公司下一步在技术方向上的投资布局将会聚焦在哪些领域？

让我们看看未来哪些事情是大概率发生的，然后我们再看未来的技术方向：

1.    云变成新的基础设施，开发者几乎不会触碰到云服务下层的基础设施；

2.    企业数字化转型越来越深入，意味着数据量将越来越大，Workload 越来越复杂；

3.    Kubernetes 在云之上变成新的"操作系统"。

如果认同上面几个趋势，那么对于数据库的技术方向就比较清晰了，例如，多模数据库，如何利用云的服务作为底座来构建数据库，使用 AI 来对数据库进行优化，数据库更好的辅助 AI 场景等等都是很明确的技术方向。