- 企业服务
- 数据库
- 大数据
- 基础平台
即使将范围从大数据缩小到数据库这个细分领域，PingCAP依然是家非常特殊的公司，其产品TiDB是市面上为数不多面向HTAP场景的数据库。
传统意义上，数据库分成事务性数据库（TP）和分析性数据库（AP）。
近几年兴起的NoSQL数据库、如MongoDB、基于Hadoop的Hbase，更多都是分析性数据库，通过分布式架构解决大规模的数据查询、分析问题。
然而，承载生产系统的事务性数据库却始终被传统数据库厂商所把持，Oracle、IBM等占据传统大型企业市场，中小企业及互联网公司则大多数采用开源技术MySQL，鲜有新技术、新公司能够进入这个市场。
2012年，Google的Spanner横空出世，这是一款基于分布式架构的事务性数据库。受到Google的启发，国外出现了CockroachDB（蟑螂数据库）等一系列解决TP问题的新兴数据库厂商，但国内市场几乎还是空白，找不到研发这类数据库的创业公司。
2015年，PingCAP成立，填补了国内的空白。
互联网背景的团队，用开源模式做数据库
与市面上其他数据库厂商不同的是，PingCAP创始团队大多数来自大型互联网公司，如豌豆荚、京东等，几乎没有来自传统IT或者数据库厂商。
互联网的背景，创始团队每名成员都经历过数据指数级增长的时期，具备处理海量数据的经验，做数据库产品会优先考虑扩展性。
同时，因为互联网公司大多会采取MySQL技术，因此TiDB最先兼容的是MySQL协议，这使得PingCAP更容易获取客户。
互联网还有个特点是开源为先，PingCAP从第一天就确立了用开源方式做数据库的打法。但与其他团队不同的是，PingCAP的创始人刘奇等人，曾经是分布式缓存项目Codis的作者，具备开源社区运营的能力，懂得如何借助社区力量发展产品。
开源社区一方面会扩大PingCAP产品的覆盖面，带来潜在的客户；另一方面，通过开源社区的运营，PingCAP将更多精力放在核心产品TiDB的研发，其他功能可以一部分由开源社区用户来实现。
此外，通过用户反馈，PingCAP可以了解用户的潜在需求，作为TiDB研发的一个参考。
产品同时支持TP和AP，强一致性和扩展性是主要特点
最初，TiDB只是解决TP问题，但在实际应用过程中，直接让客户用新数据库替代原先的MySQL数据库难度很大，尤其当数据库厂商是一家名不见经传的初创公司。
多数企业客户的做法是前端仍然保留传统MySQL数据库，将TiDB数据库作为背后的数据集市，与前端数据库相连，但这个数据集市的实时性要远好于Hadoop架构的数据集市，可以运行在实际生产系统。
当按照这种方式运行一段时间，客户认可PingCAP的产品后，会逐步替换掉MySQL数据库，将TiDB作为前端数据库。
当客户将TiDB数据库作为数据集市来使用时，因为前端数据库要从这个数据集市中查询数据，因此，对TiDB数据库的查询功能提出更高要求。TiDB调整了自己的数据库执行器，进行AP功能的拓展。
这样一来，TiDB同时支持TP和AP功能，成为分布式HTAP（Hybrid Transaction Analytical Processing）数据库产品。
TP场景下，TiDB具备强一致性的特点，可以承载金融等对数据一致性敏感度很高的行业。与传统数据库相比，TiDB可扩展性是最大优势。TiDB可以通过不断增加机器来提升性能。
AP场景下，与Hbase等相比，PingCAP的实时性更好，处理数据的速度更快。
现阶段主要覆盖互联网金融、游戏等互联网领域，销售线索主要来自开源社区
与传统企业相比，互联网公司更加容易尝试新技术，互联网背景出身的团队也更加能够清楚互联网公司的业务特点。
同时，互联网公司的发展速度大多远超传统企业，数据量增长速度极快，对改善底层技术架构、提升数据库性能的需求更加强烈，特别是在游戏行业、互联网金融行业。
这些因素促使PingCAP早期客户大多数来自互联网企业，同程旅游、360金融、摩拜单车等都陆续成为PingCAP的客户。
截至2017年底，PingCAP整体团队规模达到100人左右，其中超过80%是研发，只有一名全职销售。
一名销售的获客能力非常有限，PingCAP主要还是通过开源社区的方式获客，销售人员只负责跟进有意向的企业。2017年，应用在实际生产环境的用户达到200家，最终产生十几家付费客户。
现阶段，PingCAP重点仍然放在产品打磨和社区运营上，尚未进入到产品大范围推广阶段，因此，2018年PingCAP会考虑进入金融、医疗、物流等传统行业，但不会大范围增加销售团队，仍然会采取较为谨慎的市场策略。
近期，爱分析对PingCAP创始人刘奇进行访谈，他对PingCAP的业务模式、未来战略，以及数据库行业未来发展趋势等方面，进行阐述，现将部分访谈内容分享。
基于解决数据库扩展性问题的初衷，产品可同时满足TP和AP业务需求
爱分析：您创立PingCAP的初衷是什么？
刘奇：我在京东工作的时候就已经有这个想法，当时没有一个可以很好实现扩展的数据库，最普遍的做法是分库分表。但这种方式存在缺点，第一它的弹性扩展能力比较差，第二是易用性比较差，第三是编程的心智负担比较大，第四是表达力比较弱。
当时我在做一个项目，也需要分布式数据库，但是市面上没有令人满意的产品。
所以，最开始的定位是想解决自己的问题，中间我们还开发了一个分布式缓存，之后我们开始着手解决数据库扩展性的问题，就出来创业了。
爱分析：数据库作为底层技术，客户选择供应商会非常谨慎，最初是如何获取客户的？
刘奇：2016年，我们拿到了云启资本的A轮融资之后，开始考虑怎么去获取第一批用户。的确，用户将一个新的数据库应用到线上是存在风险的，谁愿意拿自己线上的业务去冒险尝试一个全新的数据库？
盖娅互娱是我们第一个用户。那个时候，他们的MySQL数据库出现了问题，线上查询速度特别慢，整个系统已经卡顿到无法使用，不尝试使用新的技术已经很难开展业务。我们当时的产品还在测试阶段，他们就开始推动这个数据库上线。
因为采用新的数据库到线上确实是存在风险的，因此很多用户采用另一个方式来做。线上有一堆MySQL在运行，他们在后面搭建一个大的数据集群，把所有的数据全部汇到这里，看起来有点像数仓。因为我们本身是兼容协议的，我们可以把数据复制过来，他们来进行实时查询。
在游戏行业或者是实时性要求比较高的风控管理，他们就急需要这种技术来解决问题。
我们目前披露了很多金融案例，有相当一部分都是用在实时风控这个场景。好处是不直接针对线上业务，风险相比线上MySQL要小，而又刚好解决了他们的痛点。
这个阶段之后，客户如果觉得技术足够稳定，他会把线上撤下来，再把我们的产品推到最前面去，来支撑所有业务。
当客户把我们的数据库当作数仓的时候，其实查询的复杂程度很高，我们的数据库能帮助客户做一些以前不敢做的事情，一个SQL查询语句甚至好几页纸那么长。
那么问题来了，我们的设计本身并不是为了AP业务，而查询这个功能是侧重AP的，因此我们在优化执行器的时候，也做了相应的调整，做了AP功能的拓展。
这样一来，我们的产品能同时支持线上TP和AP业务，我们的产品就变成HTAP。
当把这个产品做好之后，我们发现产品的特点十分明显，在这个领域没有一个强有力的竞争对手，而且这个产品是满足用户需求的。很多时候用户的需求并不能简单的分为TP还是AP，实际上是没有明确定义的，甚至客户并不关心这些，只希望能够解决自身的问题。
爱分析：从数据写入和查询上看，存在行与列的差别，TiDB如何在一个表里实现的？
刘奇：行列只是一个存储的形式，从技术角度来讲还是可以做行列变化的。
比如说把冷数据慢慢的后台转成列存，然后最新写入的数据仍然使用行存。前台还是一个标准的行存，根据数据的冷热，转换成行存还是列存。
其实，最新的论文已经提出了新的观点，数据的存储并不纯粹的是行存或者列存，而是根据访问频率，经常访问的数据使用行存，并不需要扫整个表，实现的方式还是很多样的。
爱分析：谷歌在做Spanner的时候强调其扩展性，在算力上要求是不是比较低？
刘奇：这是以前谷歌的一个理念，但这样的话，如果去做一些相对比较复杂的运算的时候，数据库的反应时间会比较长，这是存储格式决定的。
不过，谷歌2017年的论文当中，已经把存储格式改成了偏混存的形式。我们跟谷歌的迭代路线是一样的，而且我们的存储格式改的更早，因为我们更早的遇到了用户的实际需求。
爱分析：算法和扩展性是否存在一定的矛盾，复杂的算法会不会影响其扩展性能？
刘奇：算法和扩展性没有什么关系，算法主要影响执行的效率。
比如，如果是列存的话，执行效率更高，比如说银行对所有账户的金额进行求和，如果是列存的话会很简单，但是行存的话要扫描每一行中的金额数据，执行效率很低，但在下层的计算层面并不会有太大的差别。
爱分析：在推到前台的时候，数据库要做哪方面的调整？
刘奇：要根据整个系统的负载，来决定使用多少并发度，会做一些优化。
假设有100台机器，有这样一个数据集群，均匀地推到每一台机器上计算，并发度很高的情况下，每台机器人可能都很忙，这个时候再给它增加任务是没有用的，机器会崩溃的。
但如果有一个“聪明”的调度器，对指令进行控制，在保持高并发的状态下，调度不同的机器进行不同运算，这样机器不至于很忙，不过带来的问题是，会带来比较长的延迟。
当然，同样的数据可能不一定要运用CPU来运算，可以用GPU或者FPGA，这对调度器的要求就更高了，按照发展趋势来看，调度器的能力是衡量一个数据库性能的重要指标。
爱分析：TiDB是如何实现实时性的？
刘奇：因为他本身就是一个分布式的结构，性能是可以继续扩展的，前面有多少数据的输入都无所谓。如果现在觉得算的不够快，通过加机器就可以实现计算。
速度的快慢还跟计算有关系，有的计算是推不到所有的节点上去的。比如，我要把所有的数据拿回来做排序，这就没有办法让所有节点来做。
这种情况，优化器的作用比较重要，它会识别哪些计算需要推到下面做并行运算，哪些只要做出决定就可以。
爱分析：MySQL构架，数据迁移到TiDB能否做到无感迁移？
刘奇：我们从一开始设计的时候就考虑到了这个问题，针对MySQL可以做到无感迁移，如果是Oracle或者DB2的其它协议的话，可能涉及到改代码的问题。
爱分析：面向其它协议，迁移的周期有多长？
刘奇：这个还要考虑业务的复杂度，比如，原来的业务有10万条SQL，只要都要验证一遍，如果本身业务比较复杂，那就会比较快。MySQL协议这边，我们很快就可以做POC。
爱分析：下一步有没有考虑去支持Oracle或DB2的快速迁移？
刘奇：我们没有这方面的打算，因为新的业务已经不用这些技术了。如果考虑这些的话，目的就是切入老项目。在切入老项目时兼容性存在一个问题，用户需要知道新技术的兼容性到底是多少？我能不能放心的使用新技术替换？
兼容性不仅是功能的兼容，Bug也要兼容，真正做到100%兼容是很难的，企业原来的程序员可能也离职了，如果去替换老的业务，工作量、风险都会很大。
现阶段互联网金融、游戏等偏互联网行业是重点行业，适用于数据量大、业务复杂性高的场景
爱分析：产品主要针对哪些行业的客户？
刘奇：我们在商业化的过程中，最重要的是把产品做出来，然后根据客户的需求去完善它的功能。
另外，我们的产品是开源的。开源的好处是当用户在使用过程中会及时反馈他们的使用体验和遇到的问题，在这个过程中会发现我们的潜在用户是谁。
我们的第一个用户是游戏公司，这其实是超出了我们的预计的，我们认为可能是互联网优先，因为互联网对新技术比较激进。
游戏行业也有其特点，游戏公司最赚钱的肯定是爆款游戏的运营，一天的流水可能就有几千万。他们希望自己的基础设施是足够稳定、强大的，一旦遇到瓶颈再去停机改造，那造成的损失就会很大，因此，他们也希望通过新的技术来解决问题。
再一个就是互联网以及传统行业，互联网企业在使用我们的新产品的时候，表现得还是很保守的 ，因为前面已经有那么多的MySQL在使用，突然换新的技术他们会觉得风险很高。
不过，像互联网金融这类企业对实时性要求还是很高的，要通过实时的信息进行风控管理，以前的方案是无法满足的，所以会选择使用我们的产品。
爱分析：TiDB的应用场景有哪些？
刘奇：我们的数据库通用性比较强，一般是面向新的业务需求，我们自身并没有将数据库设计成面向某一行业的产品。
说到我们产品的优势，客户的数据量必须达到亿级别以上，如果数据量比较小，就没有必要上分布式数据库；另外，就是业务的复杂性要比较高，这样我们的优势更加明显。
爱分析：下一步会重点侧重哪几个行业？
刘奇：从营收的角度来讲，金融应该会是我们重点布局的一个行业，像物流、医疗等其他领域数据增速也比较快。
团队主要来自互联网公司，销售人员极少
爱分析：2017年PingCAP的用户推广进展？
刘奇：我们在2017年运行在生产环境的用户达到200个，产品客单价比较高，付费用户要少一些。
爱分析：TiDB是一个开源技术，在提供企业级产品时会做哪些强化？
刘奇：虽然我们提供一个开源技术，但还是有部分是闭源的，比如监控运维组件，备份工具，安全性工具等。
对于企业应用来说，它必须具备很漂亮的用户界面、很方面的操作工具，这是我们企业版提供的方式。
还有一部分，我们叫做Database & Service，我们提供的不仅是一个数据库，而是一个数据库平台，企业用户可以申请TiDB数据集群。如果没有这个东西，可能就需要管理员手动处理，使用体验差别是很大的。
爱分析：TiDB是如何收费的？
刘奇：我们现在有两方面考虑：一方面可以利用云部署，我们可以看到腾讯云的数据库入口，这个商业模式比较简单，与云上的其它产品一样，按照租赁的方式进行收费。
另一方面，可以买我们的subscription，也可以买我们的license，按照节点数来计算。
爱分析：公司的团队规模？
刘奇：现在公司大概100个人，研发占比比较高，有82个。销售人员只有1个，销售比较少是因为用户都是自己找过来的，我们在这方面没有太大的投入。
我们对研发的要求还是很高的，包括研发人员对外面的支持、响应的速度等。虽然看上去不会像Oracle那么夸张，但有很多外部公司在给我们做贡献。
比如，调度器方面的代码很多是摩拜贡献的，很多场景下的优化是今日头条贡献的，包括韩国三星研究院等，还有很多人在帮我们做测试，这也体现了开源技术的一个好处。
爱分析：研发人员会承担一部分售前的工作吗？
刘奇：在17年的时候还存在一些研发人员做售前工作的情况，但18年我们会做出一些调整，这也是我们一个很重要的任务。
人员结构的建设要形成一个完整的体系，售前、实施、研发各司其职，根据不同阶段的问题安排不同的人去解决。
爱分析：销售人员比较少的情况下，是不是对社区的运营提出更高的要求？
刘奇：我认为研发人员比较多，跟社区的交流就会比较快。社区中最主要的用户是开发者，与开发者的交流肯定是研发人员更加顺畅，销售人员没法替代这个角色。比如，用户提出有部分代码存在问题，研发的响应速度会很快。
像今日头条、摩拜、同程这些规模比较大的用户，都是因为存在痛点主动联系到我们，不需要销售去做额外的工作。
当然，社区中还存在许多规模比较小的用户，小的用户虽然没有那么大的付费能力，但对社区来说也是有直接作用的。
他们会用自己的场景进行测试，发现很多我们从来没有遇见过的问题，他们所提供的这些信息对我们来说也是十分重要的，因此我们会花费比较大的力气来运营社区。
爱分析：PingCAP的团队背景以互联网居多？
刘奇：对，互联网出身的多一些，都是规模比较大的互联网公司，都体会过数据量大了之后带来的痛苦。
另外，还有来自传统行业的，售前有来自金融行业的，他对金融行业的使用场景更加清楚一些。
爱分析：切入传统行业的话，是不是对人员结构的要求有变化？
刘奇：目前我们还不是这么想的，我们希望通过产品就能够直接拿下客户，能够体现我们产品的优势。如果是用谁的数据库都一样的客户，我们是不会去争取的，这也不是我们的强项。
爱分析：产品的研发和社区的维护，精力如何平衡？
刘奇：我们肯定会先做好一个基础版，才会在社区中推广，当遇到Bug的时候一定要去修复，不然会影响到很多人的使用，两者共同推进，并不冲突。
内部研发方面，我们会快速的开发很多新的功能，这些不会马上就应用到稳定版本，而是先在社区发布一个Beta版本，通过用户测试发现Bug，我们来进行修复，在不断的沟通之后，我们才会发布稳定版。
在这个过程当中，我们需要通过社区让用户不断的进行测试来跟我们反馈。因为产品行不行并不是我们自己说了算的，而是用户来判断的。
TP和AP融合是未来趋势，数据库市场未来会更加多样化
爱分析：CAP原理中的一致性和可用性存在一定的矛盾，怎么进行优化？
刘奇：我们在未来会提供一个选项，用户可以根据自己的需求自己选择，高一致性或者高可用性。比如银行的数据就要求高一致性，而互联网应用就更侧重高可用性，我们会都提供给用户，让用户来选。
爱分析：NewSQL技术与之前的技术有什么不同？
刘奇：历史上最开始应用的是SQL，后来为什么会出现NoSQL，是因为SQL不能扩展，虽然NoSQL具备了扩展的能力，但表达力比较差，可能还不支持事务处理，不具备SQL的传统优势。
NewSQL就相当于同时具备了两个优势，既能很好的扩展，又能具备SQL的事务处理能力和表达力。
爱分析：下一步TP和AP是有融合的趋势吗？
刘奇：我们认为是这样的，用户是不关心是TP还是AP的，解决问题就是硬道理，也不管是线上还是线下，能实时实现我肯定不愿意等一天。
TP和AP分开这是历史原因造成的，在数据库刚诞生的时候并没有去区分。现在技术能做得到，肯定还是希望融合在一块。数据分析比较复杂的情况可能还会存在单独的AP，但我们的产品还在快速的迭代，最后还是要看谁的性能更胜一筹。
爱分析：分布式数据库平台领域将来会不会产生另一个Oracle？
刘奇：因为历史原因，短时间内Oracle的地位是不可替代的，但新的数据库构架兴起的也很快，现在Oracle遇到了前所未有的挑战，我认为在未来两年，将会有20%的传统数据库被新的数据库取代。
看现在我们的用户增速，这个趋势还是相当明显的。
爱分析：未来市场的格局会发生哪些变化？
刘奇：我觉得市场会变得更加多样化。
首先，现在的需求非常碎片化，传统数据库不能很好的表达，例如对Streaming要求越来越高。
关系型数据库的优势是通用性比较强，也比较均衡。但有些场景用现在的数据库框架是很难适应的，肯定不会比专门的设计的数据库用起来顺畅，如图数据库等。
从发展趋势来看，当NoSQL出来的时候，大家会考虑它能替代什么样的场景，后来发现NoSQL还是存在很多约束的。NewSQL的出现确实会改变市场格局，应该以后会有两三家比较大体量的公司吃掉大部分市场，但小公司依然存在。
爱分析：开源技术的发展会不会影响到数据库公司的业务？
刘奇：其实开源技术已经存在很长时间了，像MySQL已经有二十几年的历史，但企业级应用毕竟不是那么简单，还存在很多问题需要团队去解决。
未来不会有完全免费的数据库，就算是开源的也是要收费的。
爱分析：互联网公司一般会自己开发基础设施，会不会对PingCAP造成影响？
刘奇：这个事情要分国内和国外来看，国内的公司喜欢建设私有云，国外差别就比较大，很多国外公司都把自己的私有云给拆掉了，原因也很简单，自己部署私有云的效率并不如直接使用成熟的公有云。
现在很多互联网公司不想再像过去那样被Oracle这样的公司Lock in，我既要用你的数据库，又必须具备一定的掌控力。因为互联网公司成长是很快的，需求的变化也更加明显，他们希望对数据库具有一定的理解力和掌控力，以方便互联网企业修改数据代码，满足自身定制化的需求。
爱分析：云厂商最后会不会成为数据库企业的竞争对手？
刘奇：数据库跟云的关系，有点像APP和APP Store的关系。云厂商可能也会做数据库，但更多的应该是一种合作关系。