聊聊PingCAP和HTAP

前几天高达2.7亿美金的融资突破了数据库领域融资额记录，刷遍朋友圈，让数据库界创业的朋友们又激动又眼馋。刘奇和东旭都是我前同事（虽然在同事期间压根没见过，都是后来再聊的），我又是从2003年开始做数据库的，的成功真是给我们立了一个好榜样，值得好好学习。

我的理解，的成功主要是因为几件事。一是作为开源的，有的理论实践基础，足够创新，起点就比较高；二是团队能力强，这么复杂的系统还真就做出来了，当然把 这样的复杂玩意砍掉了；三是因为开源，国内一大批互联网头部企业都用了，虽然这些企业估计都是白嫖的，应用规模可能也不大，另外硅谷都有用户，这样用户基数和国际化视野就出来了；四是成功开拓海外云上市场，在AWS、GCP上搞下来一批大客户，这气象就跟如日中天的和 Atlas一个level了。以上路径，简直可以作为所有开源基础软件类创业的模版。

当然以上纯粹我的个人马后炮，我也没跟刘奇或东旭深入沟通过这个话题。

我和东旭沟通比较多，有很多共同理念。比如我们都看好云上市场，都希望国内的公有云能够更快，能力更开放。都很喜欢，都认同存算分离的架构。不过存算分离上，似乎我更激进，东旭更注重本地存储。其实没本质区别，至少还是本地存储做为缓存的。

我想重点聊聊的是对HTAP的看法。

HTAP是近两年一直提倡的概念，意思是用一个系统既支持OLTP，又支持OLAP。HTAP的概念感觉开始有些影响力了，今年VLDB上，和曾经的老师还不约而同的都发表了论文讲HTAP。HTAP概念往前可以追溯到图灵奖得主在2005年发表的C-Store论文。你看讲这个概念的都是牛皮哄哄的名字啊。在C-Store里提出了糅合行存和列存两套存储引擎的HTAP路线， TiDB也就是这么做的，更关键的一点是TiDB是在分布式架构下这么做，C-Store还是单机架构。（顺便说句题外话，C-Store后来没有取得特别大的成功，我觉得是没有抓住分布式这个大趋势）

个人观点，HTAP应该有比较大的市场，因为对数据库数据做分析查询的需求普遍存在。回想起2005年底，还没有正式入职网易，就被将来的丁老板喊去优化网易点卡数据库的统计查询，因为晚上跑不出来了。这就是一个数据库既做交易又做分析的案例，但是因为点卡用的数据库不是HTAP设计，虽然OLTP天下无敌，但跑分析查询就不够快。点卡的统计查询还是晚上跑的，如果需要在交易期间跑分析查询，还会影响到交易的性能。所以这一直是一个普遍的痛点问题。

在HTAP概念之前，一般有两种手段。一是读写分离，主库做OLTP，备库做OLAP；另一种是拉到专用于分析的、Spark之类的大数据系统跑OLAP。这两种手段操作运维比较复杂，硬件成本也比较高，第二种方案还存在数据不实时的问题，因为大数据技术体系一直支持不了实时更新，也就最近才发展了一点这方面的技术。HTAP能够比较好的解决这些问题，所以应该是比较有价值的。

不过，当前的HTAP也存在两个局限。

一，是要分析的数据现在大量的并不是来自于交易数据库，比如日志数据的量通常比数据库数据量大得多，这个时候HTAP就没意义。

二，是面向分析的数据仓库维度模型和面向交易的范式模式是完全不同的两种模型。两种模型的不同是逻辑上的，行列存混合的HTAP技术是物理层面的，无法解决模型层面的问题。从我们的业务实践看，数据仓库的数据量和分析负载远大于对数据库的分析。

我的观点是，HTAP是一个好的概念，但还需要不同的技术手段，解决不同类型的HTAP场景。我们正在开发一个方案：

1. 基于支持大数据的实时更新和事务性，且支持所有主流的分析引擎，解决面向分析的存储问题；

2. 基于网易NDC实现数据库到大数据体系的全自动秒级同步，解决OLTP和OLAP数据同步问题；

3. 基于网易易数，增强可视化建模等技术，降低数据仓库建设的技术门槛的复杂度，弱化范式模式和维度模型不匹配问题；

4. 通过缓存、预计算等技术，提升分析查询性能，降低对数据仓库维度建模的需求。

这样的方案也是一种实现HTAP的思路，虽然远比TiDB这样一套系统就全自动实现HTAP复杂，解决的也没那么漂亮，但是应用范围可能更广。

如果要分析的数据来自交易数据库，并且也没有强的维度建模分析需求，那就用行列存混合一体化的HTAP数据库；如果要分析的数据不仅来自数据库，或维度建模分析需求强，那就可以参考我们的思路。