为什么腾讯QQ的大数据平台选择了InfluxDB数据库？

导读：本文带你了解一个开源的、高性能的时序型数据库——InfluxDB 。
作者：韩健
来源：华章科技

本文插图

00 为什么QQ要选择InfluxDB？
从2016年起，笔者在腾讯公司负责QQ后台的海量服务分布式组件的架构设计和研发工作，如微服务开发框架、名字路由、名字服务、配置中心等，做了大量分布式架构、高性能架构、海量服务、过载保护、柔性可用、负载均衡、容灾、水平扩展等方面的工作，以公共组件的形式支撑来自QQ后台和其他BG海量服务的海量流量。
2018年年底，笔者负责监控大数据平台的研发工作，致力于减少现有监控后台成本，以及支撑内部和外部海量监控数据的需求，打造千亿级监控大数据平台。
笔者发现，当前监控技术领域缺乏优秀的监控系统，尤其是在海量监控数据场景中，很多团队常用的做法是堆服务器和堆开源软件，比如大量采用高配置的服务器，单机近百CPU核数、TB内存、数十TB的SSD存储，安装了大量开源软件，如Elasticsearch、Druid、Storm、Kafka、Hbase、Flink、OpenTSDB、Atlas、MongoDB等，但实际效果并不理想。
众多开源软件的组合是在增加了系统的运营成本和数据的处理延迟的情况下解决接入计算，在海量标签和时间序列线情况下，常出现查询超时、数据拉不出来等问题，且成本高昂。
笔者认为，海量或千亿级是整体的量，是个笼统的概念，可以分而治之，通过分集群的方法来解决，海量监控数据的真正挑战在于以下几点：

能否做到实时。实时是种质变的能力，可将一个离线监控平台提升为一个实时决策系统。难点在于能否设计实现高性能的架构，以及能否实现水平扩展等。
分集群后，单个业务的流量大小、标签集多少是关键。流量大，相对容易解决，主要涉及系统性能和水平扩展等。标签集多，海量标签，海量时间序列线，如何做查询优化是挑战，如笔者遇到的一些业务上报的监控数据，有几十个维度的标签，并将QQ号和URL作为标签值，有非常海量的时间序列线。
针对监控数据多写少读、成本敏感的特点，如何设计高效的存储引擎？既能充分发挥硬件性能，又能在高效压缩存储的同时保障查询效率。

为了更好地打造有竞争力的监控系统，我们将技术理念定位为“技术降成本，坚决反对开源软件堆砌” 。

首先，我们认为云计算是基建，决定它能否成功的关键在于能否在基础技术上突破，打造出相比开源软件更有成本优势的云原生软件；
其次，虽然现在开源软件非常繁荣，基于开源软件，我们很容易搭建一个基础系统，将功能跑起来，但绝大部分开源软件侧重的是功能，而不是针对海量监控数据的场景进行设计，或多或少都有其局限性，且成本也非常高昂。

因此我们要做的是借助强大的技术和工程能力，直面问题，在架构和源码层面解决它，而不是引入和堆砌更多的开源软件。
出于工程效率的考虑，我们选择基于开源软件进行二次开发，使用开源软件的部分代码，按照我们的想法进行架构设计和功能开发。在对众多的开源软件进行调研分析后，我们最终选择了以InfluxDB源码为基础进行二次开发。
之所以选择InfluxDB源码，主要是因为我们对InfluxDB源码背后的技术和工程实力比较认可。 InfluxDB研发团队能真正解决海量监控数据场景的问题，也是在认真地打造一款优秀的监控产品（出于读写性能和可用性的考虑， InfluxDB研发团队曾2次重构存储引擎）。
在笔者着手以InfluxDB源码为基础开发集群等功能时，业界还没有团队实现了真正可用的InfluxDB集群能力。一些团队只是通过Proxy实现了负载均衡，却无法突破单机接入计算和存储的限制，缺乏一致性能力。