从实验到生产，Supercolumn 之旅

我们欢迎 NANO Corp. 作为嘉宾来到我们的博客。请继续阅读，了解他们为何使用 ClickHouse 以及他们从发现到生产的旅程。

探讨 NANO Corp. 为何切换到 ClickHouse 以支持其网络运营中心即服务 (NOCaaS) 产品，并且再也没有回头！

从表面上看，我们转向 ClickHouse 的旅程似乎并不具有突破性。但对于一家由在软件开发领域拥有丰富经验的老先生创立的公司而言，他们一直秉持着关于技术的传统观念，我们没有预料到我们的信念会以如此方式被颠覆 ????。

但在我们深入探讨这段旅程的细节之前，请允许我们先简单介绍一下我们公司、我们的业务以及我们过去、现在或将来尝试实现的目标。

NANO Corp. 是一家年轻的法国初创公司，由前国防人员于 2019 年创立。我们围绕自主研发并获得专利的内部技术创建了这家公司：对软件网络探针的应有形态进行了突破性的革新。我们使它们比以往任何时候都更加通用、轻巧，同时还能够轻松处理高达 100GBit/s 的带宽，而无需使用任何像数据包切片或采样这样令人羞愧的伎俩。请别忘了，它完全基于商用硬件（而且是非常便宜的硬件——如果您想了解一些规格，可以查看我们的博客），并且完全基于 CPU 运行（再次强调，我们不使用昂贵的 FPGA 或 ASIC）。

我们提供的服务可以用一个词概括：可观测性。但不是传统意义上的“网络监控”。我们不使用 Netflow、sflow、IPFIX 或 SNMP 等技术。这些技术运行良好，但缺乏广度和发展空间。它们都在某种程度上缺乏可见性，而且没有一种技术能够真正实现网络安全。基于绝对统一的链接：网络，我们的核心愿景是，网络性能和网络安全是同一枚硬币的两面，只关注前者而忽略后者毫无意义。

我们目前的主要目标是以线速高速分析复杂且不断变化的网络流量。并且通过异步馈送（在网络的不同层中安装不同的探针）来实现。非常有挑战性，对吧？基本上，我们需要的数据库必须是

• 能够处理快速（且持续）的插入，同时运行用于告警的定期查询以及由多个用户发起的自定义查询，
• 配备热/冷数据缓冲系统，用于将数据存储在 RAM 中以进行告警查询，
• 易于维护和部署，
• 能够在一个系统上摄取海量数据，并且仍然保持敏捷性。这意味着：在我们达到 10TB 级别之前（甚至之后），无需过快地进行多集群/分片
• 在 RAM 使用方面非常高效

正如您可能已经猜到的那样，为了充分发挥我们网络探针的潜力，并将它们捆绑到我们期望的那样普及的产品中，同时能够应对当今的许多混合挑战（M/L、网络安全等...），我们需要一个相当出色的数据库来支持我们的探针。而这正是我们最初遇到一些障碍的原因。因为当时我们并不知道，实际上我们需要的是一个像我们的探针一样具有突破性的数据库！

传统的 RDBMS 长期以来一直围绕智能事务管理系统构建。这项技术很好地服务于许多用例，并且已经做得很好很多年了。我们的主要工程师在他们之前的职业生涯中成功使用过 MySQL 或 PostgreSQL。我们知道从长远来看，它们中的大多数都无法满足我们的需求。它们的数据模式过于依赖更新速度，并且当整体性能成为问题时需要进行集群。

但我们仍然尝试了一些“老古董”数据库 ????. 主要是因为 OLTP 似乎是我们心中某些查询的先决条件。我不确定我是否可以提及它们的名字（都是很好的数据库，但它们只是不符合我们的需求）。可以这么说，当时我们并没有抱太大期望，即便如此，我们仍然感到失望。

为了给您提供更多背景信息，我们必须获得在 1Gb/s 网络上提取流元数据的成功基准测试。在极端情况下，我们必须在数据库中馈送多达 140 万个流/秒（根据情况而定，大约 30 到 250 列）。可以这样说，传统的 RDBMS 或图数据库在我们拥有的硬件上无法提供我们所需性能的 25%。

而我们的最终目标是使其在 100Gb/s 网络上流畅运行... 我猜这就是 crud 工作的成果 ;-)

但让我们稍微回到过去，让我为您提供更多背景信息。

亲爱的读者，实话告诉您，OLAP 并不是我数据库的首选。ClickHouse 也不是。考虑到它来自 Yandex（但开源），我们有一些顾虑。首先也是最重要的是，我一直在寻找 OLTP 超大规模数据库，其中分片或多集群是关键。

流行语很重要。我记得我的一个早期客户，那是疫情前，在另一家公司（那简直是黑暗时代）。那位客户执着于 Hadoop 多集群基础设施，总体拥有成本 (TCO) 高达 7 位数（欧元）。所有这些都只是为了支持非常基础的 NLP ETL，预计每月处理几百 MB 的数据……。但在当时，Hadoop 非常流行，那位政府部门的 CTO 想要玩玩这个闪亮的新玩具。却没有意识到这真正意味着什么。那是我第一次真正体会到技术领域流行语的力量。因此，当 Nano 的故事开始时，多集群已经成为据传数据存储可能遇到的每个问题的答案。

最终，我也在寻求设计和实施多集群数据库。因为它很酷，而且根据我脑海中浮现的数字，我非常确定除了 XXXXXXXX 之外，没有其他数据库能够处理预期的海量数据。如果想要快速查询，就必须有大量的集群和复制节点。不幸的是，如果不花足够的时间来设计和构建健壮的数据模式，就部署多集群数据库，就像既要拥有蛋糕又要吃掉它一样。除非您在一家利润丰厚的公司工作，并且 C 级管理人员不了解技术领域的实际价格，否则您很快就会意识到没有免费的午餐，对吧？

我们的先决条件很苛刻，而且我们追求的是一流的性能，而不是其他任何东西……。这是技术领域梦想世界的渐近线式追求。但随后我们不得不讨论一些技术人员不太喜欢考虑的事情：成本。因为在他们看来，性能是数字和理想完美世界中的纯粹抽象概念。在一个金钱是肮脏的世界里，只有那些喋喋不休、想要扼杀他们梦想的算盘珠子才会谈论金钱。请记住，我们可能会花费数周时间来为探针管理的每个网络数据包节省 3 到 4 纳秒…… 我们必须做出的思维方式转变非常巨大。

例如，早期支持数据库从多个 10Gbit/s 探针摄取数据的硬件要求…… 令人震惊。这还没有考虑到使用 OLTP 数据库意味着我们需要人员来维护如此复杂的架构。有些人可能会说，多集群总是很混乱，尤其是在正确完成的情况下。但是…… 我们当时（以及在我写这些文字时仍然是）是一家小公司。我们想要便宜、强大、可扩展，当然，我们还想要在各个阶段都“易于使用”。我可以告诉您，这绝非易事。

最终，我们对传统 OLTP 数据库的所有初始测试…… 都非常令人失望。而且它无法扩展。即使他们说可以扩展。为了提高效率，我们不得不花费大量的资金在硬件上。这与我们所有的核心信念（以及我们任何客户采购部门的信念 ;-)）背道而驰。

有一天，就在我不断掉头发、失眠的时候，我的首席数据科学家来了。他一手拿着咖啡，一手拿着手机，开玩笑地对我说：“我想试试 ClickHouse！”。

我无法形容那个家伙当时有多大的胆量！

我们有一位客户需要进行容量规划，而我一直在花费数天（甚至周末）的时间来设计巧妙的数据模式并仔细研究硬件选项……。但他却来找我，要求我们部署一个数据库社区中不被看好的新来者。

为了寻找一个能够以交互式延迟对海量数据运行分析查询的数据存储，他偶然发现了 ClickHouse，它被誉为市场上最快的数据仓库。

我确信您已经在想了。最快的数据仓库…… 我们以前都听过这种说法，对吧？剧透警告：它确实是最快的。实际上，它太快了，以至于我确信我们的第一个基准测试一定有错误，结果一定是假的。我让我的首席数据科学家查看这些基准测试。他停了下来，好奇地看着他发送一个又一个查询，结果瞬间返回，通常我的旧数据库需要几秒甚至几分钟才能完成的事情，现在只需几毫秒即可完成。哇。

当时我想：“如果 Cloudflare 这样一家专注于网络且享誉全球的公司都选择了 ClickHouse，那只能说明他们肯定发现了什么了不起的东西 ????"

在我们运行了一系列不同的测试之后，我们被征服了。但究竟是为什么呢？嗯，主要是因为 ClickHouse 的快速多重插入、快速索引、强大的物化视图、出色的 MergeTree 函数，当然还有其完善的文档，以及更棒的社区支持（当然，这只是我个人的看法）。

即使后来我们快速浏览了其他 OLAP 数据库，如 Druid 或 Pinot，我们仍然坚持使用 ClickHouse。这在很大程度上是因为 ClickHouse 中的数据摄取比其替代方案效率更高。它不需要准备包含严格落入特定时间间隔的所有数据的“段”，并且它允许更简单的数据摄取架构和更轻松的维护（请记住，我们仍然是一家小型初创公司），并且它可以节省计算能力。这非常重要，因为我们的探针不断发送数据以供 ClickHouse 摄取，同时还在热数据和冷数据上运行持续查询。ClickHouse 的批量插入理念也特别适合我们的技术，因为我们自己为所有要摄取的数据制作中间批次（有点像 Kafka 的做法，但规模要小得多）。

基本上，ClickHouse 中的数据摄取要简单得多，对资源的消耗也更少，而且它允许您执行极其快速的查找查询！两全其美。现在，如果 ClickHouse 可以原生处理 JSON 格式文件就好了…… 什么？他们现在可以了？哇……

最后，我可以这么说，我们在对所有其他替代方案感到失望之后偶然发现了 ClickHouse，并留了下来，因为它非常适合我们的需求 ;-)

下一次，我们将讨论一个具体的用例：我们如何处理用于高容量输入的多个异步数据馈送。