大约18个月前我加入CloudFlare时，我们刚刚开始构建新的数据平台。那时，公司早期建立的日志处理和分析管道已经达到了极限。这是因为我们的Edge平台的日志量快速增长，我们不得不应对每年超过400%的流量增长。我们的日志处理流水线开始像大多数其他人一样：压缩日志文件被运送到一个中心位置，用于聚集一个由Perl脚本和C++程序组成的杂凑集合，用一个PostgreSQL实例来存储聚合数据。从那时起，CloudFlare已经发展到每秒为数百万个站点提供数百万个请求。除了每天必须聚合成百上千兆字节的日志数据外，在为CloudFlare上数百万个站点提供详细分析方面，我们还面临着一些独特的挑战。对于我们的客户分析应用程序的下一次迭代，我们想让一些东西快速启动并运行，尝试Kafka，在Go中编写聚合应用程序，然后看看如何扩展我们可靠的Go-to数据库PostgreSQL，从一台机器到一个服务器集群，而不需要我们在应用程序中处理分片。在分析PostgreSQL的扩展需求时，我们遇到了Citus Data，它是2011年夏天推出Y Combinator的公司之一。Citus Data构建了一个名为CitusDB的数据库，该数据库扩展PostgreSQL以用于实时工作负载。由于citusb支持跨数十亿行的实时数据摄取和次秒级查询，因此它已成为我们分析基础设施的关键部分。用于分析的日志处理管道在进入数据库后端的详细信息之前，让我们回顾一下将日志事件从CloudFlare的Edge传输到我们的分析数据库的管道。HTTP访问日志事件通过CloudFlare数据管道进行，如下所示：web浏览器发出请求（例如，HTTP GET请求）。运行Lua代码的nginxweb服务器处理请求并生成Cap'n Proto格式的二进制日志事件。一个类似Heka的Go程序通过UNIX套接字从Nginx接收日志事件，与其他事件一起批处理，使用Snappy或LZ4之类的快速算法压缩批处理，并通过TLS加密的TCP连接将其发送到我们的数据中心。另一个Go程序（Kafka-shim）接收日志事件流，对其进行解密，解压缩批处理，并将事件生成Kafka主题，在许多服务器上复制分区。Go聚合器（每个分区一个进程）使用主题分区，并以1分钟的粒度将聚合（而不是单个事件）插入citudb数据库。稍后将进一步汇总到1小时和1天的粒度，以减少要查询的数据量，并加快跨越多个小时或数天的时间间隔的查询。为什么要去？以前的博客文章和讨论都涉及到使用Go构建的各种CloudFlare项目。我们发现Go是团队在构建CloudFlare所需的各种分布式系统时使用的一种很好的语言，无论工程师对Go的经验水平如何，这都是事实。我们的客户分析团队由从1.0发布前就开始使用Go的工程师以及完整的Go新手组成。新加入的团队成员能够快速启动，代码库保持可维护性，即使我们继续构建更多的数据处理和聚合应用程序，例如新版本的第7层DDoS攻击缓解系统。另一个使Go变得伟大的因素是第三方图书馆不断扩大的生态系统。我们使用GO CAPNPROTO生成GO代码来处理CAN原始格式中的二进制日志事件，这是GO、C++和Lua项目之间共享的一个共同模式。ZooKeeper/Go对sarakeeper/Go数据库的支持非常好。为什么是卡夫卡？随着我们开始在Go中构建新的数据处理应用程序，我们对管道有一些额外的要求：使用具有持久性的队列，以允许下游服务器和/或使用者服务在短时间内停机。通过现场可靠性工程团队成员编写的脚本，使数据可用于实时处理。允许将来的聚合器以其他语言构建，如java、C++或C++。经过大量的测试，我们选择Kafka作为日志处理管道的第一阶段。为什么是博士后？正如我们在postgresql9.3发布时提到的，PostgreSQL长期以来一直是我们堆栈的重要组成部分，这是有原因的。国外的数据包装器和其他扩展机制使得PostgreSQL成为一个存储大量数据的优秀平台，或者作为其他NoSQL数据存储的网关，而不必放弃SQL的强大功能。PostgreSQL还有很好的性能和文档。最后，PostgreSQL有一个庞大而活跃的社区，我们有幸在CloudFlare办公室和其他地方举行的由旧金山湾区PostgreSQL会议组组织的会议上会见了许多PostgreSQL贡献者。为什么选择citudb？CloudFlare从第一天就开始使用PostgreSQL。我们相信它，我们想继续使用它。然而，CloudFlare的数据增长很快，我们遇到了单个PostgreSQL实例的局限性。我们的团队的任务是在短时间内扩展我们的分析数据库，因此我们从定义对我们很重要的标准开始：性能：我们的系统支持客户分析仪表板，因此典型的查询需要在不到一秒钟的时间内返回，即使是在处理来自许多客户站点的长时间数据时。PostgreSQL：我们在生产中运行PostgreSQL有丰富的经验。我们还发现了一些有用的扩展，例如Hstore使我们能够存储半结构化的数据，HyperLogLog（HLL）使唯一计数近似查询快速。扩展：我们需要动态扩展集群以获得性能和巨大的数据存储。也就是说，如果我们意识到我们的集群正变得过度利用，我们希望通过添加新的机器来解决这个问题。高可用性：这个集群需要高可用性。因此，集群需要从诸如磁盘死机或服务器停机之类的故障中自动恢复。商业智能查询：除了对客户查询的秒级响应外，我们还需要能够执行可能需要分析数十亿行分析数据的商业智能查询。首先，我们评估了在PostgreSQL上构建一个处理分片的应用程序需要什么。我们研究了使用postgres_fdw扩展来在多个独立的PostgreSQL服务器上提供统一的视图，但是这个解决方案不能很好地处理服务器宕机的问题。对PostgreSQL领域主要参与者的研究表明，CitusDB有潜力成为我们的最佳人选。在性能方面，他们已经让客户运行实时分析，查询在一个大型集群中并行运行，只需几十毫秒。citudb还保持了与PostgreSQL的兼容性，不是像其他供应商那样分叉代码库，而是将其扩展到计划和执行分布式查询。此外，citusb使用了许多逻辑碎片的概念，因此，如果我们要向集群中添加新的机器，我们可以通过调用一个简单的PostgreSQL用户定义函数轻松地重新平衡集群中的碎片。使用citudb，我们可以将逻辑碎片复制到集群中的独立机器上，甚至在查询期间也可以在副本之间自动进行故障转移。如果出现硬件故障，我们还可以使用重新平衡功能在集群中重新复制碎片。CITUDB建筑citudb采用类似于Hadoop的架构来扩展Postgres：一个主节点保存关于集群中碎片的权威元数据，并并行化传入的查询。然后，工作节点执行运行查询的所有实际工作。在CloudFlare的例子中，集群拥有大约100万个碎片，每个碎片被复制到多台机器上。当应用程序向集群发送一个查询时，主节点首先修剪掉不相关的碎片，并找到与查询相关的特定碎片。然后，主节点将查询转换为许多较小的查询以进行并行执行，并将这些较小的查询发送给工作节点。最后，主节点从worker接收中间结果，合并它们，并将最终结果返回给应用程序。对于CloudFlare analytics群集中的查询，这需要25毫秒到2秒的时间，具体取决于页面缓存中是否有部分或全部数据可用。从高可用性的角度来看，当工作节点发生故障时，主节点会自动故障切换到副本，即使在查询期间也是如此。主节点保存缓慢变化的元数据，非常适合连续备份或PostgreSQL的流式复制功能。citusdata目前正在进行进一步的改进，以便于将主元数据复制到所有其他节点。在CloudFlare，我们喜欢citudb架构，因为它使我们能够继续使用PostgreSQL。我们的分析仪表板和BI工具使用标准的PostgreSQL连接器连接到Citus，而像pg嫒dump和pg_upgrade这样的工具就可以工作了。两个突出的特性是citudb的PostgreSQL扩展，它支持我们的分析仪表板，以及citudb能够将这些扩展中的逻辑进行开箱即用的并行化。CitusDB的Postgres扩展PostgreSQL扩展是为核心数据库本身添加功能的软件。一些示例包括数据类型、用户定义函数、运算符、聚合和自定义索引类型。PostgreSQL有150多个公开可用的官方扩展。我们想重点介绍其中两个可能会引起普遍关注的扩展。值得注意的是，使用citudb，所有这些扩展都是自动进行的