发布在即!企业 AIGC 应用程度测评,3 步定制专属评估报告。抢首批测评权益>>> 了解详情
写点什么

现代技术栈中,你到底需要的是一个后端架构还是数据架构?

  • 2021-02-21
  • 本文字数:3104 字

    阅读完需:约 10 分钟

现代技术栈中,你到底需要的是一个后端架构还是数据架构?

现代技术栈通常会至少包括一个前端和一个后端,但它很快就会演变成需要包含一个数据平台。这通常是由于需要特定的分析和报表,但它也可能会演变成一个完整的“炼油厂”,包括 cron 作业、仪表盘、批量数据复制等等。一般来说,需要推到数据平台的功能通常是:

 

  • 延迟不是很关键,因此可以更晚地运行,延时可能长达 24 小时(与处于请求-响应周期中的响应式同步作业相反)

  • 更容易表达成在大型数据集上操作的批处理作业,而不是对每个请求所进行的操作

 

报表就是一个很好的例子。假设你需要将所有交易导入到你的核算系统。比起直接在后端执行,编写一个每隔 24 小时执行一次的脚本可能更容易一些。

 

另一个例子是训练机器学习模型。假设你正在构建一个欺诈检测系统,并且有一个机器学习模型来检测某些用户行为是否具有欺诈性。训练模型可能需要一个小时,但预测却很快。每隔 24 小时甚至每周或每月对模型进行一次重新训练要容易得多。然后,你可以序列化模型,并在后端系统中使用它进行预测。

 

在 Spotify,数据平台是从版税报表开始的,但很快就用它将排行榜重构成每晚的数据作业了。数据平台不断发展壮大,尤其是音乐推荐系统中,它已经成为一条庞大的数据管道了。我们每隔几周就对核心模型进行一次重新训练,但通常每晚都会重新生成个性化推荐。对于人们需要的推荐来说,这种频率已经足够了。

 

为什么要这么麻烦呢?

 

为什么要这么麻烦地使用数据平台呢?因为通常情况下,能使产品的构建和交付容易 10 倍。将工作从后端推送到单独的数据平台有助于实现以下几点:

 

  • 你不必担心延迟。

  • 你可以自己控制流(而不是听命于等待响应的用户请求)

  • 一般来说,你可以用一种更能容错的方式来编码(批处理通常更容易编写成一组幂等的运算)

  • 批处理的效率更高(为 1,000,000 个用户生成音乐推荐可能只比为 1 个用户生成音乐推荐多 1000 倍的工作量)

  • 如果失败了,这也不是世界末日,因为你通常可以在第二天修复 bug 后重新运行作业。

 

例如,假设要构建一个能够实时更新的全球头条的基本功能,比如在新闻网站上显示头条新闻。我敢打赌,与在数据平台中构建一个每小时或每天更新一次并将结果推回到后端的 cron 作业相比,纯粹地在后端完成这项工作要困难得多。

 

那么,你是否做到了(以最少的技巧)?

 

当然,后端架构更成熟一些,大约有 1000 篇关于其最佳实践的博客文章。比如,我首先想到的就是Martin Fowler。当我们构建后端系统时,我们会被教导要注意以下内容:

 

  • 避免集成数据库(每个系统都应该有自己的数据库,两个系统永远不能共用同一个数据库)

  • 数据库查询应该尽可能地简单(通常引用一个确切的键,并且连接尽可能少的表,理想情况下应该为零)

  • 使用事务(以及约束、键、etc)确保数据的完整性

  • 大量的单元测试

  • 大量的集成测试

  • 将较大的服务(也称为“单体”)拆解为较小的服务(也称为“微服务”)

 

无论如何,当你进入数据平台时,你可以把这些中的全部或大部分都扔出去了!

 


油画描绘的是 1618 年的布拉格扔出窗外事件(defenestration of Prague)

数据端:“狂野的西部”

 

我所看到的基础设施通常以如下的某一点来作为起点:

 

  • 后端日志被发送到某些数据存储中

  • 后端的生产数据库被转储到某些数据存储中

 

在过去,这个数据存储通常是 Hadoop(HDFS),但如今它通常是一些可扩展的数据库,比如 Redshift。有很多不同的解决方案,在这里我就不展开介绍了。

 


数据延迟的注意事项

 

数据平台中的任何内容通常都会延迟(在 Spotify 上,通常会延迟 24 小时甚至更长)。如果它没有延迟,也应该认为它是延迟的,这意味着对数据的任何操作,延迟都不应该是至关重要的。

 

你能拥有一个操作实时数据库数据而不是操作有延迟的数据转储的数据平台吗?在理论上是可以的。但我认为这会助长不良的行为。例如,如果在生产数据库上运行 cron 作业,很容易做一些诸如将数据写回数据库的事情,这样就创建了一个集成数据库,该数据库的同一个表有多个写入者和读取者。这可真是一团糟!因此,正确的分离应该是(a)cron 作业操作延迟的数据(b)任何返回后端系统的通信都通过内部端点进行。

 

还有一点要注意:不要让业务人员访问实时数据!否则他们提的任何需求都会要求基于此,而你将不得不永远支持它。

 

不管怎样,数据端会发生什么?根据我的经验,我认为,任何事情都会发生。下面我们来讨论其中的一些:

集成数据库

 

例如,传统的约束是服务不应该接触到彼此的数据库,并且这些层应该备受推崇。这就避免了所谓的“集成数据库”反模式,即同一数据有多个写入者和读取者。在数据世界里,这条规则已经过时了。在数据端,我发现完全可以加入来自不同服务的 3 个不同数据集。为什么这是可以接受的呢?我认为可以归结为以下三点:

 

  1. 破坏任何下游使用者的模式更改并不是世界末日,只需更新一些查询即可,仅此而已。

  2. 如果出现问题,则通常可以修复后并重新运行作业。如果在 UTC 午夜没有生成某些报表,你也可以在接下来的几个小时内修复该作业,也几乎没有人会抱怨。

  3. 所有查询都是只读的,这意味着你永远不必担心事务的完整性或读取不一致的数据。

 

我的结论是,集成数据库对于后端系统来说是很糟糕的,但是对数据层来说却非常棒。

大型查询

 

后端系统必须处理低延迟、低吞吐量的查询,通常一次只涉及一个用户。由于该用户发出请求并等待响应,因此查询需要很快。那么如何使查询更快呢?

 

  1. 尽量避免连接,如果需要,坚持使用非常简单的索引连接(通常是 left join from table A to B

  2. 每个查询都应引用一个特定的项 ID,例如 ... where user_id = 234 或类似的

 

每当我在后端系统中看到任何比关联几个表并带一两个 where 条件更复杂的查询时,我都会产生难以置信的怀疑。

 

在数据世界里,这些都不重要。几乎所有的查询都将“跨越”所有/大部分数据,事实上,大多数查询都将归结为“全表扫描”。难道跨越页的查询看起来不像是 20 世纪早期的德国哲学家写的吗?魅力四射!

 

这基本上就是 OLTP(on-line transaction processing,联机事务处理)和 OLAP(On-Line Analytical Processing,联机分析处理)之间的区别,它们是不同类型的查询模式。如果你愿意深入研究的话,也有很多的文章可以参考!

测试

 

写到这里我有些抱歉,也许是带着一种负罪感,因为我承认了一些黑暗的秘密。我非常支持非常全面的测试,但是在数据端要达到合理的测试覆盖率是很难的。

 

对于后端系统,你可以实现类似于 y=f(x) 这样的函数,其中 x 是一个输入(比如来自第三方 API 的响应), y 是结果(例如,将 API 响应转换为内部表示)。这真的很容易测试!有时你的函数是类似 Sn+1=f(Sn,A) 这样的,其中 Si 是“状态”, A 某些动作,但是状态和动作都非常小,可以在单元测试中很好地表示出来。

 

在数据端,xSi 都是很庞大的。这意味着只要设置所有的输入数据,任何单元测试基本上都会达到 99%。但是由于输入数据是超高维的,因此这也意味着边界情况的建模变得更加困难。更麻烦的是,数据管道通常是不确定的(机器学习模型),或者具有非常主观的输出,以至于你不能简单地编写一堆断言。由于所有这些原因,我发现数据管道的测试保真度很低(它们捕获到的 bug 很少),而且维护成本很高。伤心!我喜欢做一些基本的测试来确保其运行正常,但是验证正确性可能并不总是值得的。

结论

 

我发现,将尽可能多的功能从后端推到数据平台是非常有用的。这些功能包括:

 

  • 向用户发送(非事务性)电子邮件(如个性化营销电子邮件)

  • 生成搜索索引

  • 生成推荐

  • 报表

  • 生成业务人员需要的数据

  • 训练机器学习模型

 

所有这些都可以构建到后端系统中,但应该作为 cron 作业在数据平台中运行。这能使代码的复杂度降低(大致)一个数量级。

 

原文链接:

https://erikbern.com/2019/01/10/data-architecture-vs-backend-architecture.html

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2021-02-21 11:381972

评论

发布
暂无评论
发现更多内容

Java中的抽象类详解

共饮一杯无

Java 抽象类 10月月更

Rocksdb dynamic-level-bytes测试简单记录

TiDB 社区干货传送门

实践案例 管理与运维

华为云灾备解决方案,助力企业高效构建安全合规云灾备系统

科技之光

打造全栈安全防护体系,华为云等保合规解决方案帮企业30天过等保

科技之光

企业架构-了解分布式

Marvin Ma

企业架构 分布式系统 凤凰架构 书籍拆解

Nodejs:ESModule和commonjs,傻傻分不清

coder2028

node.js

Kyligence 当选 Gartner 2022 中国数据管理 Cool Vendor

Kyligence

Gartner 数据管理

数据中台的前世今生(一):数据仓库——数据应用需求的涌现

雨果

数据中台 数据仓库

OpenHarmony轻量系统中内核资源主要管理方式

OpenHarmony开发者

OpenHarmony

“程”风破浪的开发者|THREE.JS实现看房自由(VR看房)

知心宝贝

前端 three.js 元宇宙 VR看房 “程”风破浪的开发者

TiCDC 实践:TiDB 到 TiDB 增量数据迁移

TiDB 社区干货传送门

迁移

TiDB v6.1.0 及 TiUniManager 在 openEuler 22.03 中的部署踩坑实践

TiDB 社区干货传送门

实践案例 管理与运维 安装 & 部署 应用适配 6.x 实践

如何定义LED显示屏与OLED显示屏

Dylan

LED LED显示屏 OLED

钛媒体 | 发布PaaS平台2.0,元年科技通过自主技术撬起更大市场

元年技术洞察

媒体 PaaS

koa实战

coder2028

node.js

多版本并行,测试如何做好质量保障?

老张

质量保障 版本迭代

Docker | 部署nginx服务

甜点cc

nginx Docker 10月月更

华为云CDN使能千行百业,业务价值不断凸显!

科技之光

“程”风破浪的开发者|什么是web3.0,一文带你搞懂它

共饮一杯无

前沿技术 Web3.0 10月月更 “程”风破浪的开发者

零信任时代安全沙箱成为企业应用必需品

FinClip

Docker | 镜像浅析,以及制作自己的镜像

甜点cc

Docker tomcat 10月月更

华为云,中小型企业的等保安全专家

科技之光

华为云,助力企业快速省心过等保

科技之光

华为云,高品质保障企业的等保安全

科技之光

git-secret:在 Git 存储库中加密和存储密钥(下)

SEAL安全

git 加密 makefile 密钥管理 10月月更

建木v2.5.7发布

Jianmu

DevOps 持续集成 CI/CD 自动化运维

为了讲明白继承和super、this关键字,群主发了20块钱群红包

华为云开发者联盟

开发 华为云 企业号十月 PK 榜 发红包

千万级高并发秒杀系统设计套路!超详细解读~~

博文视点Broadview

【文本检测与识别白皮书】第三章-第三节:算法模型

合合技术团队

人工智能 深度学习 文字识别 文本

新来个技术总监,仅花2小时,撸出一个多线程永动任务,看完直接跪了,真牛逼!

小小怪下士

Java 程序员 多线程

华为云灾备服务,如何守护云上数据

科技之光

现代技术栈中,你到底需要的是一个后端架构还是数据架构?_大数据_Erik Bernhardsson_InfoQ精选文章