作者 | Andreas Evers

编译 | 言征

长期以来，数据库一直充当着记录系统，它们以可靠且持久的方式存储和管理关键数据，也赢得了大多数公司的信赖。

但时代在变。许多新兴趋势正在影响当今数据的存储和管理方式，不得不让一些技术决策者们重新考虑数据存储究竟还有哪些创新途径。或许，关系型数据库开始变得不合时宜了。

本篇文章为诸君提供了一种“跳出框框”的记录系统的新玩法——为什么组织需要以不同的方式思考数据存储、使用 Kafka 作为记录系统的好处以及有哪些好的实现思路等，希望对诸君有所启发。

1、用Kafka替代关系数据库

KOR Financial是一家金融服务初创公司，他们为何会选择Kafka，而不是依赖关系数据库来存储数据呢？该公司的首席技术官Andreas，曾在Pivotal Software和VMware任职，主导过全球范围内的应用程序转型架构实践，他的这一决策有什么玄机？

先说结果，使用Kafka方案，能够“经济高效、安全地存储数十甚至数百PB的数据，并且保留数十年。”Andreas称，“采用这种方法不仅为数据架构提供了巨大的灵活性和可扩展性，而且还实现了精益和敏捷的运营。”

2、打破定式：数据库没有为规模设计

时代变了！身处数字化转型时代，数据驱动决策要求企业具备现代灵活的数据架构。而要实现这样的架构，成功的关键就在于，数据存储能否做到强大、可靠和灵活。

诚然，也看到了近二十年来，大数据、分布式系统、云计算和实时数据处理的兴起，但传统的数据库就成了掣肘的瓶颈，已无法跟上每秒生成数据的速度和数量。

首先，这是因为数据库并不是为规模而设计的。它们固有的僵化结构只会阻碍企业数据架构所需的灵活性。

作为服务全球企业金融贸易存储库以及互补模块化服务的运营商，数据的处理级别堪比炼狱。KOR Financial创新式地采取了数据流优先的方法，这也是它区别于竞争对手的地方。“的目标：彻底改变衍生品市场和全球监管机构对交易报告、数据管理和合规性的思考方式。”

以Kafka为架构核心，是一个思考方式上“质”的变化：因为这种架构能够捕获事件而不仅仅是状态。“将数据存储在Kafka而不是数据库中，并将其用作记录系统，就可以实现跟踪所有这些事件、处理它们并根据现在或将来的用例创建数据的物化视图。”

虽然其他贸易存储库和中介服务提供商经常使用Oracle Exadata 等数据库来满足其数据存储需求，但它可能非常昂贵并带来数据管理挑战。虽然它允许执行 SQL 查询，但挑战在于管理大型SQL数据库并确保这些系统内的数据一致性。

从事全球强制贸易报告业务，意味着要为多个管辖区提供服务，每个管辖区都有自己独特的数据模型和解释。如果将所有数据合并到单个架构或模型中，统一管理的任务就会变得越来越复杂。如果没有数据的历史概览，模式演变就具有挑战性，因为它是在特定版本的状态中具体化的，这进一步加剧了数据管理的困境。

另外，在处理大量数据时，传统数据库的可扩展性受到限制。相比之下，将Confluence Cloud用于Kafka及其无限存储，就可以允许用户在Kafka中存储任意数量的数据，只要需要，就可以存储任意长时间，而只需为所使用的存储付费。

虽然分区数量是一个考虑因素，但可以放入 Confluence Cloud 中的数据量是无限的，并且存储空间会根据需要自动增长，并且保留时间不受限制。

它使技术人员能够完全抽象出数据在底层的存储方式，并提供一种经济高效的方式来保存所有数据。更好地是，这使企业能够以一种不受限制的方式扩展自身的运维，并以想要的任何表示方式来解释事件，自由度很高。

3、会整活的Kafka：重播事件、回放数据

使用Kafka作为记录系统的显着优势之一在于它能够回放数据，这是传统数据库所缺乏的原生功能。对于金融场景来说来说，此功能与“存储事件与状态”的偏好非常契合，这对于准确计算交易状态至关重要。

“我们收到一大堆delta（增量），我们称之为提交或消息，它们在给定的时间点对贸易状态有贡献。每个传入的消息或事件都会修改交易并更改其当前状态。如果在我们的流处理逻辑过程中发生任何错误，都可能导致不正确的状态输出。”

如果该信息直接存储在固定表示或传统数据库中，则导致该状态的事件就会丢失。即使对这些事件的解释不正确，也无法重新审视导致该解释的背景。

然而，通过在不可变且仅追加的日志中保留事件的历史顺序，Kafka 提供了重播这些事件的能力。

鉴于业务的监管要求，必须以不可变的方式存储所有内容。需要捕获并保留最初收到的所有数据。虽然大多数数据库（包括SQL）都允许修改，但 Kafka 在设计上禁止对其不可变日志进行任何更改。

使用 Kafka 作为记录系统并拥有无限存储意味着可以回到过去，分析事情是如何展开的，更改的解释，管理时间点历史更正并创建替代表示，而不会影响当前的操作工作负载。

这种灵活性提供了显着的优势，尤其是在高度监管的市场中运营时，能及时有效地纠正错误，这一点至关重要。

4、灵活性征服一切

使用 Kafka 作为记录系统为的数据架构带来了显著的灵活性。可以针对每个用例建立特定的视图，并使用与这些需求精确一致的专用数据库或技术，然后读取包含这些事件来源的 Kafka 主题。

以客户数据管理为例。可以使用专门为该用例设计的图数据库，而无需围绕图数据库构建整个系统，因为它只是基于 Kafka 的视图或投影。

这种方法允许根据用例使用不同的数据库，而无需将它们指定为的记录系统。相反，它们充当数据的表示，使能够保持灵活性。否则，就将被插入数据库、数据湖或数据仓库，这些都是僵化的，不允许将数据转换为针对特定用例优化的表示形式。

从初创公司的角度来看，这种灵活性也使能够避免过早地被锁定在某个特定的技术方向。KOR成立于2021年，遵循将决策推迟到最后一个负责时刻的架构最佳实践，可以推迟对特定技术选择的承诺，直到它是必要的并且符合的要求。这种方法意味着，可以随着业务需求的发展而调整和发展的技术环境，并实现未来的可扩展性和灵活性。

除了灵活性之外，模式注册表（Schema Registry）的使用还确保了数据的一致性，因此开发者就可以知道数据的来源和与之相关的模式。Confluence Cloud 还允许通过架构注册表设置明确的演进策略。例如，如果将所有数据放入数据湖中，那么管理该数据的所有不同版本、不同模式和不同表示就会变得更加困难。

5、切换技术的背后：事件驱动思维

放弃数据库，而采用 Kafka 作为存储数据的记录系统，看起来是一件非常新鲜的做法。

并不是所有公司上来就能接受这种做法，Andreas认为，这需要公司培育“事件驱动模型”的文化，并且这种思维转变还应该扩展到通过流处理开发应用程序的方式，不然就会引起兼容性不匹配的问题。

这样做的目的，是帮助团队成员意识到：他们正在处理不可变的数据，如果他们编写了某些内容，他们就不能直接进去更改它。

Andreas还建议道，要实现以Kafka为核心的架构，可以从理解“流处理和事件作为证明系统的重要性”的团队开始。通过展示该团队内的优势，他们可以充当其他团队的大使，鼓励采用事件作为最终真相，并采用以状态作为最终表示的流处理。

6、写在最后：Kafka可以取代数据库吗？

早在2017年，Apache Kafka和Confluent的共同创始人Jay Kreps就明确表示过“ 可以在Apache Kafka中存储数据 ”。

而且，数据可以在Kafka中想保存多久就保存多久。《纽约时报》的Apache Kafka发布是用Kafka永远存储数据的著名例子。Kafka被用来存储《纽约时报》曾经发布的所有文章，并取代了他们基于API的方式。

那么Kafka可以取代数据库吗？显然并不现实，即便文中提到了许多传统数据库的“不合时宜”之处，比如，“数据库并不是为规模设计的”等观点，但也仅限于金融等强实时性场景中的方案。

不过，倡导的打破传统数据库的思维定式去重新设计底层架构的方法，值得反思和借鉴。

原文链接：https://thenewstack.io/ditching-databases-for-apache-kafka-as-system-of-record/