其次，执行引擎的设计要求与TP天然不同，AP系统要访问大量的数据，迭代数据的效率极为关键。这个领域也是近十年来数据库研究的重点，从“火山”模型到“数据流”模型、从“拉”数据到“推”数据、cache-aware、即时编译（Just-in-time compilation），各种技术令人眼花缭乱。
OceanBase的最新3.0版本引擎与之前的最大不同在于引入了新的cache-aware向量化处理，在大数据量场景下有数倍的性能提升。当然，我们还要清醒的看到，OceanBase的引擎性能距离很多优秀产品还有明显的差距，这个方向的工作才刚起步。
第三个挑战，在于HTAP里面的H，Hybrid，混合。AP和TP是技术要求上天然不同的两类请求，典型的TP的场景是简单请求、小数据量、高并发，关注重点在系统的吞吐量。
而AP场景则是复杂查询居多，运行时间长，更多关注响应延迟。这就像是田径项目中的短跑和长跑，对运动员肌肉类型、反应速度、耐力都有不一样的要求。一个好的HTAP系统，能在一个系统里把很多TP、AP的请求同时解决掉，就相当于在培养一个运动员，既能跑一百米的短跑，又能跑一万米或者是马拉松。好比博尔特，100米短跑的王者，但今天还要博尔特跑进一万米的世界决赛，难度可想而知。
因此，考验一个HTAP系统，往往不是一个单一的维度，而是看如何在去做技术的妥协，这个是考验我们整个技术的能力。OceanBase今天已经应用在很多TP为主的核心场景，我希望做到的是AP能力的尽量能的延伸，我们今天在TPC-H测试中做了很多优化，但我们在TP场景的性能并没有出现回退。
另外，一旦将TP和AP的请求放在了同一个系统，意味着系统对于不同请求的资源使用要非常“合理”并且尽量互不影响。困扰数据库开发人员的一个难题是，当TP和AP请求混布时，两者之间的互相影响很难被“隔离”，今天“隔离”问题仍然是影响用户选择HTAP系统的一个重要挑战，我们将不同的资源在内部进行了虚拟化，并通过资源组的概念将TP、AP请求进行隔离，一定程度上解决了这个问题，但HTAP如何彻底的解决这些问题，还有很多有待探索的空间。
类似的问题还有很多，限于篇幅，只能先说这么多。但我认为任何一个真正的HTAP数据库，至少要能够比较好的解决上面提到的三个方面的挑战。
四 HTAP的边界在哪里？未来OceanBase的方向在哪里？过去大家提到OceanBase，第一反应就是一个典型的TP处理系统，具有很强的高可用和线性扩展的能力。TPC-H成绩出来以后，身边的很多朋友都想了解未来OceanBase会成为一款什么样的数据库产品？对这个问题，我有几点想法想和同行、客户分享。
首先，一个既能处理TP又能处理AP的数据库系统，可以大大简化系统的复杂性，是有不可否认的客户价值的，这点是HTAP产品的立足之本，也是我们做产品的初心。
因此，一个HTAP系统如果本身的处理能力不足或者使用起来很复杂，也是不能满足用户期待的，OB过去两年一直在尝试降低用户的使用成本，就是希望不管是大型客户还是中小型客户，是金融客户还是非金融客户，都能用的起，用的简单，甚至用的爽，这个方向很关键，未来也会继续坚持下去。
其次，每款HTAP产品都有自己的定位。OceanBase起步于企业核心场景的分布式数据库，TP场景的处理能力将永远是OceanBase坚持的底线和优化方向。换句话说，我们不会以牺牲TP场景的能力为手段，提升AP场景的处理能力，这和很多以AP为核心场景的产品定位会有所不同。最后，HTAP是一种技术架构选择。
就像Gartner提到的：
Hybrid Transaction/Analytical Processing (HTAP) is an emerging application architecture that breaks the wall between transaction processing and analytics. It enables more informed and in business real time decision making.
说到底，HTAP架构是希望通过打破TP和AP的边界，最终带给客户实实在在的商业价值。对于OceanBase这样一款数据库产品，选择HTAP这样的技术方向意味着要克服更多困难。路还很长，好在11岁的OceanBase还很年轻，还有很多机会，很多希望。