Airbnb的架构

• https://quastor.substack.com/p/airbnbs-architecture
• https://www.youtube.com/watch?v=yGOtTd-l_3E
• 我们将介绍每个体系结构，并讨论其优缺点以及迁移Airbnb原因。我们将介绍每个体系结构，并讨论其优缺点以及迁移Airbnb原因。我们将介绍每个体系结构，并讨论其优缺点以及迁移Airbnb原因。
• Airbnb最初是Ruby on Rails单体（2008 - 2017），然后过渡到微服务架构（2017 - 2020），现在已经迁移到微服务和宏服务之间的混合（宏服务聚合多个微服务）。Airbnb最初是Ruby on Rails单体，然后过渡到微服务架构，现在已经迁移到微服务和宏服务之间的混合（宏服务聚合多个微服务）。Airbnb最初是Ruby on Rails单体，然后过渡到微服务架构，现在已经迁移到微服务和宏服务之间的混合（宏服务聚合多个微服务）。

可汗学院 Khan Academy

• https://quastor.substack.com/p/how-khan-academy-rewrote-their-backend
• https://blog.khanacademy.org/go-services-one-goliath-project/
• https://blog.khanacademy.org/technical-choices-behind-a-successful-rewrite-project/
• https://blog.khanacademy.org/incremental-rewrites-with-graphql/

        在2019年底，可汗学院正在寻求升级他们的后端。该网站建立在Python 2单体之上，运行良好超过10年。

        然而，Python 2 即将在2020 年1 月 1日正式结束生命周期，因此可汗学院的工程师决定他们必须更新。

        KA（可汗学院）有几种选择

• 从 Python 2 迁移到 Python 3 - 这将使 KA 在后端服务器代码性能和 Python 10 的语言功能方面提高 15-3%。

• 从 Python 2 迁移到 Kotlin 从 Python 2 迁移到 Kotlin - KA 开始使用 Kotlin 执行计算密集型后端任务，因为它比 Python 2 性能更高。从 Python 切换到 Kotlin 可能意味着 Khan Academy 的响应速度更快，服务器成本也会下降。

• 从Python 2迁移到Go - Go是一种简单简洁的语言，编译时间非常快，对Google App Engine有一流的支持，并且比Kotlin（基于KA的测试）更少的内存使用量。

        在这些选项中，可汗学院决定采用第三种选择，并用Go重写他们的Python 2单体。他们进行了性能测试，发现 Go 和 Kotlin（在 JVM 上）的表现相似，Kotlin 领先百分之几。但是，Go 使用的内存要少得多。Go 和 Python 之间的巨大性能差异使得转换所涉及的努力是值得的。

Stack Overflow

• https://quastor.substack.com/p/-the-architecture-behind-the-worlds

Tinder的视频交付

• https://quastor.substack.com/p/how-tinder-streams-video-to-70-million

• Tinder工程师使用FFMPEG将MP4文件转码为HLS流。他们开发了一个工作流程，将 MP4 文件和配置（分辨率、比特率、帧速率等）作为输入，并将包含 HLS 流的目录作为输出。

• 他们为所需的所有不同视频版本提供了多个配置，并将所有这些视频版本存储在 AWS S3 存储桶中。
  

Netflix 如何同步数亿台设备

• https://quastor.substack.com/p/how-netflix-syncs-hundreds-of-millions

Quora如何分片他们的MySQL数据库

• https://quastor.substack.com/p/how-quora-shards-their-mysql-database
• 随着读/写查询负载的增长，工程师不得不水平扩展数据库 水平 （添加更多计算机）。他们通过将数据库表拆分为不同的分区来实现这一点。如果某个表变得非常大或具有大量流量，则会为该表创建一个新分区。每个分区由一个主节点和副本节点组成。从分区到该分区中的表列表的映射存储在 ZooKeeper 中。
• 将大型/高流量表拆分到新分区上效果很好，但是在变得非常大的表周围仍然存在问题（即使它们位于自己的分区上）。对于大型表，架构更改变得非常困难，因为它们需要大量空间并且需要几个小时（由于负载峰值，它们也必须经常中止）。涉及未知的风险，因为很少有公司拥有像Quora运营的桌子一样大的单个表格。MySQL有时会在读取或写入时选择错误的索引。在 1 TB 表上选择错误的索引比在 100 GB 表上选择错误的索引要昂贵得多。因此，Quora的工程师研究了分片策略，其中可以将大表拆分为较小的表，然后放在新的分区上。

Facebook的News Feed

• https://quastor.substack.com/p/-the-engineering-behind-facebook
• https://engineering.fb.com/2021/01/26/ml-applications/news-feed-ranking/
• 每当您刷新Facebook新闻源时，Facebook的Web / PHP层都会向Feed聚合器查询它应该显示的帖子。源聚合器在源叶数据库中查询所有帖子和相关指标。然后，提要聚合器处理数字并返回帖子的排名列表，供前端呈现。
  

Lyft 如何存储为其 ML 模型提供支持的数据

• 来福车 美国交通网络公司
• https://quastor.substack.com/p/how-lyft-stores-the-data-powering
• https://eng.lyft.com/ml-feature-serving-infrastructure-at-lyft-d30bf2d3c32a
  

功能定义

这些功能在 SQL 中定义。定义的复杂性可以从单个查询到包含复杂联接和转换的数千行 SQL。

这些定义还包含 JSON 中的元数据，用于描述功能版本、所有者、验证信息等。

要素数据摄取

对于在批处理数据上定义的特征，Lyft 使用 Flyte 运行定期计划的特征提取作业。该作业针对 Lyft 的数据仓库执行 SQL，然后写入要素服务。

对于实时特征数据，Lyft使用Apache Flink。它们针对流窗口执行 SQL ，然后写入要素服务。

特征处理和检索

功能服务是用 Golang 编写的，具有用于写入和读取功能数据的 gRPC 和 REST 端点。

将要素数据添加到服务时，会同时写入 DynamoDB 和 Redis 中（Redis 用作直写缓存以减少 DynamoDB 上的读取负载）。

Lyft使用Dynamo流将特征数据复制到Apache Hive（他们的数据仓库工具）和Elasticsearch。

然后，功能服务将利用 Redis 缓存、DynamoDB、Hive 和 Elasticsearch 来处理特征数据请求。

对于需要快速返回要素数据的实时 ML 模型，要素服务将尝试从 Redis 缓存中检索要素数据。如果缓存未命中，它将从 DynamoDB 检索数据。

CG

• Kubernetes - The Documentary 【Kubernetes 纪录片 】https://www.youtube.com/watch?v=BE77h7dmoQU

• B站搬运版https://www.bilibili.com/video/BV1jL4y157Mq/?
  

• https://quastor.substack.com/p/dynamic-programming-in-the-real-world

• 大型科技公司远程工作的未来