写点什么

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

2021 年 2 月 21 日

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

现代技术栈通常会至少包括一个前端和一个后端,但它很快就会演变成需要包含一个数据平台。这通常是由于需要特定的分析和报表,但它也可能会演变成一个完整的“炼油厂”,包括 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

2021 年 2 月 21 日 11:381421

评论

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

区块链商品溯源系统开发,区块链底层平台搭建方案

WX13823153201

区块链商品溯源系统开发

TCP拥塞控制四种算法

赖猫

TCP 网络协议

1200道算法面试题:Github上霸榜算法宝典,狂揽8W星

互联网架构师小马

Java 数据结构 面试 算法 LeetCode

【科创人】维格表创始人陈霈霖:喜茶数字化转型的结晶是vika维格表

科创人

【315特别放送】TcaplusDB致力于给用户提供安全放心有保障的数据服务

TcaplusDB

数据库 后端 TcaplusDB Tcaplus

架构师训练营第六周作业 - 命题作业

阿德儿

本科毕业,六年Java开发经验,阿里技术三面+HR面,拿下38*16薪资P7offer

Java架构之路

Java 程序员 架构 面试 编程语言

2021社招阿里、腾讯、蚂蚁金服「4面」Java面试高频题分享

Java成神之路

Java 程序员 架构 面试 编程语言

六面天猫成功斩获offer,我的面经复盘总结,大厂真的那么难进吗?

Java成神之路

Java 程序员 架构 面试 编程语言

【死磕JVM】一道面试题引发的“栈帧”!!!

牧小农

JVM Java虚拟机 运行时数据区 Java虚拟机栈 栈帧

三步上线自己的在线监考系统

融云 RongCloud

不要去毕业就进外包!苦肝900个小时从外包到大厂,回头看这一路是真的辛酸!

程序员小毕

Java 程序员 架构 面试 分布式

五位一体全方位解析Spring Boot,阿里爆款SpringBoot实战笔记也太香了

Java王路飞

Java 程序员 面试 微服务 springboot

如何写好操作类说明文档

lenka

3月日更

《精通比特币》学习笔记(第十一章)

棉花糖

区块链 学习笔记 3月日更

恭喜自己2021金三银四收到的第五个Offer:字节跳动Java研发岗

比伯

Java 编程 架构 面试 程序人生

程序员必修课:阿里性能优化全解终开源!设计+代码+JVM三飞

程序员小毕

程序员 架构 面试 性能优化 JVM

三面拼多多归来,我总结了这些大厂面经及面试题

Java成神之路

Java 程序员 架构 面试 编程语言

架构师训练营第十周作业 - 命题作业

阿德儿

GitHub Action + ACK:云原生 DevOps 落地利器

阿里巴巴云原生

容器 运维 云原生 k8s 应用服务中间件

一分钟了解EFT公链新一代超级DeFi公链——EGG超级公链

币圈那点事

区块链 公链 挖矿

腾讯高级工程师保姆级“Java成长手册”,层层递进,全是精华

Java架构追梦

Java 腾讯 架构师 java面试 面试核心知识点总结

华为18级工程师总结的50W字算法、LeetCode、操作系统、计算机底层刷题必备笔记

Java架构之路

Java 程序员 架构 面试 编程语言

面试字节跳动定级2-2,拿32*16offer,P8大佬的算法教程给了我春天!

Java架构之路

Java 程序员 架构 面试 编程语言

使用 Arthas 排查 SpringBoot 诡异耗时的 Bug

阿里巴巴云原生

Java 开发者 云原生 中间件 Arthas

PBAC相对于传统ABAC的优势

龙归科技

IT 架构师 权限 ABAC PBAC

MySQL详解:索引的介绍和原理分析

周老师

Java 编程 程序员 架构 面试

中台还没建就开始拆中台了?医疗中台何去何从?

菜根老谭

中台 医疗中台

Python 初学者必看:Python 异常处理集合

华为云开发者社区

Python 异常 代码 程序 错误

融云聊天室属性 kv

融云 RongCloud

音视频

BOE(京东方)物联网解决方案让会议更“智慧”

爱极客侠

边缘计算隔离技术的挑战与实践

边缘计算隔离技术的挑战与实践

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