共计 4960 个字符，预计需要花费 13 分钟才能阅读完成。
简介：Gartner 2016 年首次提出 HTAP（Hybrid Transaction / Analytical Processing，混合事务剖析解决）并给出明确的定义：即同时反对 OLTP 和 OLAP 场景，须要翻新的计算存储框架，在一份数据上保障事务的同时反对实时剖析，省去费时的 ETL 过程。在我看来，HTAP 代表了一种技术现实，然而落地的时候难免会遇到各种问题，包含：
数据库的全称是 DBMS（Database Management System），晚期是不辨别 OLTP 与 OLAP 的，E.F.Codd 在 1970 年就提出了关系模型，Jim Gray 在 1976 年提出了事务模型。随着数据库的利用场景越来越丰盛，繁多数据库的解决能力瓶颈越来越显著，于是有人把简单剖析从数据库中独自拆分进去，Berry Devlin 和 Paul Murphy 在 1988 年提出了数据仓库，1993 年 E.F.Codd 提出 OLAP，明确把 OLAP 与 OLTP 辨别开来，并附带 OLAP 的 12 条准则。OLAP 倒退到明天有各种做法，包含咱们经常听到的 ROLAP（基于 MPP 架构的关系数据库之上的 OLAP）、MOLAP（基于 Data Cube 的计划）、大数据（基于 Hadoop/Spark 的大规模剖析计划）等等。经典数据库把业务分成 OLTP 和 OLAP，并通过 ETL 定期将数据从 OLTP 数据库抽取到 OLAP 数据库，这也是数据仓库 T+1，T+n 的由来。这种形式带来了两个问题：一个是提早、一个是复杂度，在理论生产零碎中经常出现数据同步提早或者同步出错导致的线上故障。那么，一种很天然的想法就是基于同一份数据同时做好事务处理和实时剖析，从而让利用变得简略。一种形式是在 OLTP 数据库的根底上扩大 OLAP 的能力，典型的代表是 Oracle 和 SQL Server。相比 MySQL 这种纯正用于 KV 类简略查问的 OLTP 零碎，Oracle 和 SQL Server 一方面可能解决简单查问，另外，通过 Oracle IMC（In-memory column store）和 SQL Server 列存 / 列索引等技术可能很好地解决 OLAP。这种类型的混合负载叫做 ”real-time operational analytics”，先有 OLTP，再有 OLAP，且 OLTP 性能做到极致，这也是我认为的真正的 HTAP。OceanBase 采纳的也是这种做法，不同点在于 OceanBase 的底层是原生分布式架构，相比 Oracle/SQL Server，可能解决更大的数据量。另外一种形式是在 OLAP 数据库的根底上引入实时写入能力，典型的代表是一些专门用于实时 OLAP 的 MPP 数据库。国内很多守业公司走的是这条路，这种类型的混合负载实质上是 ”real-time analytics”，往往是在数据仓库的根底上引入实时写入，成为一个实时数据仓库，但因为 OLTP 波及外围业务门槛太高，不反对残缺的事务处理能力，例如不反对跨服务器强一致性，不反对大事务 / 长事务，不反对触发器 / 外键 / 束缚，等等。真正的 HTAP（real-time operational analytics）要求先有高性能的 OLTP，且可能很好地反对实时剖析。这种类型的 HTAP 零碎人造具备实时数仓（real-time analytics）的能力，这也是为什么 Oracle Exadata、SQL Server MPP 架构被宽泛用于实时数仓场景的起因。须要留神的是，尽管真正的 HTAP 零碎可能同时做 OLTP 和 OLAP，但因为工程复杂度和产品成熟度的起因，真正的 HTAP 零碎也不可能在所有场景都具备劣势。例如，纯正的离线数据仓库，专门的 OLAP 零碎会比 HTAP 零碎做得更好。HTAP 的典型劣势场景包含：1) 企业级混合负载。MySQL 这样的开源数据库只能解决简略查问，如果波及到简单查问，往往是通过用户批改业务的形式来绕过。经典的企业级工作负载个别都是混合负载，既有简略的 Key-Value 查问，也有更加简单的跑批作业，甚至是实时剖析出报表，须要用到大事务 / 长事务，以及触发器、外键、束缚等严格数据校验性能，例如企业 ERP 零碎。2) 实时数据中台。很多场景会应用 MySQL 分库分表，并将所有 MySQL 分库的数据同步到一个专门的汇聚库做实时剖析。具备分布式能力的 HTAP 零碎可能同时接管 MySQL 交易库和汇聚库的工作负载。3) 在线历史数据对立解决。DBA 做数据库布局的时候往往会辨别在线库和历史库，通过在线库做交易，定期将在线库的冷数据迁徙到历史库。HTAP 零碎可能将在线数据和历史数据对立成一份数据，反对更加灵便的查问形式，升高业务复杂度。4) 面向用户的实时剖析。传统的数据仓库往往是面向企业内部人员的，实时性不强，随着数据变得越来越重要，很少数仓场景须要间接面对最终用户，须要晋升零碎的实时性和并发解决能力，例如淘宝实时剖析每个广告主 / 代理商的广告推广打算 / 关键词，支付宝对每一笔交易做实时风控，支付宝双十一当天实时剖析每个商家的销售状况并依据剖析后果疾速调整营销策略，等等。
真正的 HTAP 零碎有一个要求是基于”一份数据”同时做好交易和剖析。那么，什么叫做“一份数据”？想要答复这个问题，外围是要答复哪一种做法是对用户最敌对且性价比更高。我认为，数据的多个正本或者多种状态（列索引 / BTree 索引 / Bitmap 索引等）都能够被认为是”一份数据”，前提是可能在满足 HTAP 解决需要的前提下最大水平升高数据冗余。例如，OceanBase 往往存储多个正本（3 个正本 / 5 个正本），能够抉择让其中一个备正本专门做 OLAP 查问；Oracle IMC 反对对表格在内存中建设列索引，SQL Server 反对对表格在磁盘 / 内存中建设列索引，从用户的角度依然是“一个零碎，一份数据”。很多用户都问我：OceanBase”一份数据”是否反对资源隔离？了解了”一份数据“这个概念之后，这个问题就很容易答复。对于 HTAP 混合负载，如果是 OLTP 负载为主，OLAP 负载占比很少，那么，能够在主正本同时反对 OLTP 和 OLAP 混合负载并在数据库外部实现资源逻辑隔离；如果 OLAP 负载占比很高，那么，能够在主正本上做 OLTP，在专门的备正本或者只读正本上做 OLAP 查问，实现资源物理隔离。业界还有一些两套零碎的计划，例如 OLTP 零碎采纳 RocksDB/MySQL，OLAP 零碎采纳 Spark 或者 ClickHouse，并在零碎外部实现不同类型 SQL 的路由散发。这种计划并不合乎“一份数据“的要求，不是真正的 HTAP。为什么？因为采纳两个零碎之后必然导致老本大幅回升，为了零碎的高可用，OLTP 零碎和 OLAP 零碎须要有各自独立的多正本容灾架构，且两个零碎在实践上无奈保证数据的一致性。HTAP 是否意味着全公司一套零碎？HTAP 的确可能很好地兼顾 OLTP 和 OLAP，但这并不代表 HTAP 是万能的，也不代表全公司只有一套 HTAP 数据库。这外面既有技术因素，也有非技术因素。一个公司往往会有多个业务部门，利用也会做拆分，这就导致 OLTP 数据库和 OLAP 数据库的决策部门不同，即便是 OLTP 数据库也会依照业务做拆分。全公司一套零碎在大多数公司根本是不事实的，比拟事实的做法是每个业务一套 HTAP 数据库。例如交易业务一套 HTAP 数据库，同时反对在线交易实时处理和历史订单的实时剖析。相比基于 MySQL/ClickHouse/Elastic Search/Presto/Kylin 等多个零碎搭积木的做法，HTAP 的确可能大大简化利用。另外，即便 HTAP 零碎足够弱小，数据仓库往往也会独自部署。一方面，实时业务和数据仓库的决策部门不同，另一方面，实时业务往往是繁多数据源，而数据仓库解决多个业务的多种数据源。HTAP 零碎也不等于原生分布式架构。后面提到，Oracle / SQL Server 尽管采纳集中式架构，然而具备 HTAP 能力，可能同时解决 OLTP 和 OLAP 混合负载，Oracle Exadata 一体机也是经典的 HTAP 计划之一。当然，通过原生分布式架构，以 OceanBase 为代表的分布式 HTAP 数据库具备解决大数据量的能力，大大拓宽了 HTAP 数据库的利用场景。HTAP 技术上就义事务还是剖析？真正的 HTAP 要求先有高性能的 OLTP，而后在 OLTP 的根底上反对实时剖析。无论是 Oracle/SQL Server 这样的集中式 HTAP 数据库，还是 OceanBase 这样的分布式 HTAP 数据库，都有十分好的事务处理性能。业界有一些“HTAP 产品”的事务处理性能比拟差，这并不是 HTAP 的问题，而是这类产品的设计实现问题。HTAP 的“一份数据”能够是数据的多个正本或者多种状态，例如主正本采纳行存，备正本采纳列存，因而，实践上也能做到不就义剖析能力。然而，真正的 HTAP 数据库都是在 OLTP 的根底上倒退起来的，因为工程复杂度的问题，OLAP 的能力个别会弱于专门的 OLAP 零碎。HTAP 适宜 OLTP 或者 OLTP 与实时 OLAP 混合负载解决这两类场景，不适宜离线数仓或者大数据无结构化数据处理场景。
真正的 HTAP 是在 OLTP 数据库的根底上扩大 OLAP 的能力。经典的 OLTP 数据库，无论是开源的 MySQL，还是商业数据库 Oracle/SQL Server，都采纳集中式架构，底层存储引擎是面向磁盘设计的 B+ 树。这种计划是为小数据量的实时事务处理量身定制的，读写性能很好但相比 LSM Tree 等新型数据结构存储老本更高。以 OceanBase 为例，底层采纳优化过的 LSM Tree 存储引擎，在支付宝所有业务齐全替换 Oracle/MySQL，存储老本只有原来 B+ 树计划的 1/3 左右。为了让 OLTP 数据库具备 OLAP 的能力，尤其是大数据量 OLAP 的能力，思考如下：首先，须要引入原生分布式架构和低成本存储引擎，晋升零碎的大数据处理能力，从而使得零碎不仅可能解决最新数据的实时交易，也能解决更大规模历史数据的全量分析。OceanBase 的底层采纳了一个基于 LSM-Tree 的行列混合式存储计划，大幅升高存储老本，并在 OLTP 和 OLAP 二者性能获得很好的均衡。其次，须要反对 OLTP 与 OLAP 之间的资源隔离。这外面既有多个正本之间的物理隔离，也有一个正本外部的 CPU/ 网络 / 磁盘 / 内存的逻辑隔离，将 cgroup 集成到数据库引擎外部做逻辑资源隔离是一个不错的计划。再次，须要很好地反对简单查问和大数据量查问，波及到优化器、并行执行、向量执行等核心技术。对于分布式数据库，优化器不仅仅要思考单机上的代价，还须要思考多机上的代价，优化器的搜寻空间大幅减少；另外，如何解决并行执行和服务器故障容错的问题，如何实现高效的向量引擎，如何设计内存中的数据格式，等等。最初，须要更好地反对 OLAP 的数据开发和建模能力。数据仓库往往会将数据分成多个档次，包含：数据明细层，数据服务层，利用数据层。为了反对实时剖析能力，HTAP 须要反对高效易用的物化视图，内部表，疾速数据导入，并与各种数据开发工具和 BI 工具实现适配对接。
自己从事数据库内核研发十几年，最大的感触是经典数据库博大精深浩如烟海，尽管咱们明天摸索的 HTAP 计划是一种翻新，然而，其中大部分优良的设计都能够从 Oracle/SQL Server 这样的经典数据库中借鉴，它们代表的是集中式架构的 HTAP，咱们要做的是分布式架构的 HTAP，从而进一步拓展 HTAP 的利用场景。HTAP 不是万能的，比拟适宜单个业务部门的 OLTP 和实时 OLAP 的混合负载解决。我认为终态 HTAP 计划肯定是基于“一个零碎，一份数据”同时解决交易和实时剖析的高性价比计划，“一份数据”的多个正本能够存储成多种状态（行存 / 列存），用于不同的工作负载。OceanBase 从 2010 年开始始终保持做分布式 HTAP，尽管曾经做了 12 年，但离产品齐全成熟还须要很多年，接下来咱们会有 HTAP 技术系列文章，把咱们目前曾经实现的 HTAP 技术计划和场景价值分享进去。尽管这些计划不肯定很欠缺，然而能够作为和咱们的开发者进一步探讨的根底。原文链接：http://click.aliyun.com/m/100… 本文为阿里云原创内容，未经容许不得转载。
