# 分析数十亿笔信用卡交易并在云中提供低延迟的见解
> 原文: [http://highscalability.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html](http://highscalability.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html)
![](https://img.kancloud.cn/a6/1b/a61b4960b414a442866eef3ca65f5dff_150x150.png)
*这是 [Ivan de Prado](http://www.linkedin.com/in/ivanprado) 和 [Pere Ferrera](http://www.linkedin.com/in/pedroferrera) 的来宾帖子, [Datasalt](http://www.datasalt.com) 的创始人, [Pangool](http://pangool.net) 和 [Splout SQL](http://sploutsql.com) 大数据开源项目。*
使用信用卡支付的金额巨大。 显然,可以通过分析所有交易得出数据中的内在价值。 客户忠诚度,人口统计,活动热点图,商店推荐以及许多其他统计数据对于改善客户与商店之间的关系都非常有用。 在 [Datasalt](http://www.datasalt.com) ,我们与 [BBVA 库](http://www.bbva.com)合作开发了一个系统,该系统能够分析多年的数据并为不同的低延迟 Web 和移动应用程序提供见解和统计信息。
除了处理大数据输入外,我们面临的主要挑战是**的输出也是大数据,甚至比输入**还大。 并且此输出需要在高负载下快速提供服务。
由于使用了[云(AWS)](http://aws.amazon.com), [Hadoop](http://hadoop.apache.org/) 和 [Voldemort](http://www.project-voldemort.com/voldemort/) ,我们开发的解决方案每月的基础设施成本仅为数千美元。 在下面的几行中,我们将解释所提出的体系结构的主要特征。
## 数据,目标和首要决策
该系统使用 BBVA 在世界各地的商店中进行的信用卡交易作为分析的输入源。 显然,数据是匿名的,非个人的,并且可以进行隔离以防止任何隐私问题。 信用卡号被散列。 任何产生的见解始终是汇总,因此无法从中获得任何个人信息。
我们为每个商店和不同时间段计算许多统计数据和数据。 这些是其中一些:
* 每个商店的付款金额直方图
* 客户保真
* 客户人口统计
* 店铺推荐(在这里购买的客户也可以在...购买)。 按位置,商店类别等过滤。
该项目的主要目标是通过低延迟的 Web 和移动应用程序向所有代理(商店,客户)提供所有这些信息。 因此,一项苛刻的要求是能够在高负载下以亚秒级的延迟提供结果。 由于这是一个研究项目,因此需要处理代码和要求方面的高度灵活性。
因为一天仅更新数据不是问题,所以我们选择了面向批处理的架构(Hadoop)。 我们选择 Voldemort 作为只读存储来提供 Hadoop 生成的见解,这是一个简单但超快速的键/值存储,可以与 Hadoop 很好地集成。
## 该平台
该系统基于 [Amazon Web Services](http://aws.amazon.com/) 构建。 具体来说,我们使用 S3 存储原始输入数据,使用 Elastic Map Reduce(亚马逊提供的 Hadoop)进行分析,并使用 EC2 提供结果。 使用云技术使我们能够快速迭代并快速交付功能原型,这正是我们这类项目所需的。
## 架构
![](https://img.kancloud.cn/c7/32/c7320717aee55649679eb7c07e989a53_800x397.png)
该体系结构包含三个主要部分:
* **数据存储**:用于维护原始数据(信用卡交易)和生成的 Voldemort 存储。
* **数据处理**:在 EMR 上运行的 Hadoop 工作流,执行所有计算并创建 Voldemort 所需的数据存储。
* **数据服务**:Voldemort 群集,用于服务来自数据处理层的预先计算的数据。
银行每天都将当天发生的所有交易上载到 S3 中的文件夹中。 这使我们能够保留所有历史数据-每天执行的所有信用卡交易。 所有这些数据都是处理层的输入,因此我们**每天都重新计算所有内容**。 重新处理所有数据可以使我们变得非常敏捷。 如果需求发生变化或发现一个愚蠢的错误,我们只需更新项目代码,并在下一批之后修复所有数据。 这是一项发展决定,为我们带来了:
* 简化的代码库&架构,
* 灵活性&适应变化,
* 轻松处理人为错误(只需修复错误并重新启动过程)。
每天一次,控制器在 EMR 上启动新的 Hadoop 集群并启动处理流程。 此流程由大约 16 个[元组 MapReduce 作业](http://www.datasalt.com/2012/02/tuple-mapreduce-beyond-the-classic-mapreduce/)组成,这些作业计算各种洞察力。 流的最后一部分(Voldemort 索引器)负责构建数据存储文件,该文件随后将部署到 Voldemort。 流程完成后,结果数据存储文件将上传到 S3。 控制器关闭 Hadoop 集群,然后将部署请求发送到 Voldemort。 然后,Voldemort 从 S3 下载新的数据存储并执行热交换,完全替换旧的数据。
## 技术
### Hadoop 和 Pangool
整个分析和处理流程是使用 Hadoop 之上的 [Pangool Jobs](http://pangool.net) 实现的。 这使我们在性能,灵活性和敏捷性之间取得了良好的平衡。 元组的使用使我们能够使用简单的数据类型(int,字符串)在流之间传递信息,同时我们还可以将其他复杂的对象(如直方图)包含在其自己的自定义序列化中。
另外,由于 Pangool 仍然是低级 API,因此我们可以在需要时对每个 Job 进行很多微调。
### 伏地魔
![](https://img.kancloud.cn/ee/e2/eee230274dd5fdc1bffcca6ab26bbc48_640x357.png) [Voldemort](http://www.project-voldemort.com/voldemort/) 是 LinkedIn 基于 [Amazon Dynamo](http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html) 概念开发的键/值 NoSql 数据库。
Voldemort 背后的主要思想是将数据分成多个块。 每个块都被复制并在 Voldemort 群集的节点中提供服务。 每个 Voldemort 守护程序都可以将查询路由到保留特定键值的节点。 Voldemort 支持快速读取和随机写入,但是对于此项目,我们将 Voldemort 用作只读数据存储区,在每次批处理之后替换所有数据块。 因为数据存储是由 Hadoop 预先生成的,所以查询服务不受部署过程的影响。 这是使用这种只读批处理方法的优点之一。 我们还具有灵活性,可以在需要时更改集群拓扑并重新平衡数据。
Voldemort 提供了一个 Hadoop MapReduce 作业,该作业在分布式集群中创建数据存储。 每个数据块只是一个 [Berkeley DB](http://www.oracle.com/technetwork/products/berkeleydb/overview/index-093405.html) [B 树](http://en.wikipedia.org/wiki/B-tree)。
Voldemort 的接口是 TCP,但我们想使用 HTTP 服务数据。 VServ 是一个简单的 HTTP 服务器,它将传入的 HTTP 请求转换为 Voldemort TCP 请求。 负载平衡器负责在所有 VServ 之间共享查询。
## 计算数据
### 统计
分析的一部分在于计算简单的统计信息:平均值,最大值,最小值,标准偏差,唯一计数等。它们是使用众所周知的 MapReduce 方法实现的。 但是我们也计算一些直方图。 为了在 Hadoop 中有效地实现它们,我们创建了一个自定义直方图,该直方图只能通过一次计算。 而且,我们可以在一个 MapReduce 步骤中,在任意数量的时间段内,为每个商务计算所有简单的统计数据以及相关的直方图。
为了减少直方图使用的存储量并改善其可视化效果,将由许多分箱组成的原始计算出的直方图转换为可变宽度的分箱直方图。 下图显示了特定直方图的 3 槽最佳直方图:
![](https://img.kancloud.cn/f7/70/f7700ca6ee9de2971ea011f87541a174_639x307.png)
使用[随机重启爬山](http://en.wikipedia.org/wiki/Hill_climbing)近似算法计算出最佳直方图。 下图显示了每次爬山迭代中可能的移动:
![](https://img.kancloud.cn/5e/7b/5e7be34fd8be975a697f861331134683_640x555.png)
该算法已被证明非常快速和准确:与精确的动态算法(由[本文](http://cosco.hiit.fi/Articles/aistat07.pdf)实现)相比,我们达到了 99%的精度,速度提高了一个因子。
### 商业建议
推荐使用共现进行计算。 也就是说,**如果有人在商店 A 和 B 中都购买了商品,则存在 A 和 B 之间的同现**。 即使购买者在 A 和 B 都购买了几次,也仅考虑一次共现。给定商店的顶级共同商店是该商店的推荐。
但是需要对共现这一简单概念进行一些改进。 首先,因为几乎每个人都在其中购物,所以通过简单的降频来过滤掉最受欢迎的商店。 因此,推荐它们没有任何价值。 按位置(商店彼此靠近),商店类别或两者过滤推荐也可以改善推荐。 与“总是真实的”建议相比,基于时间的同现产生了更热烈的建议。 限制共现的时间会导致人们建议在第一次购买后立即购买的商店。
Hadoop 和 Pangool 是计算共现并生成建议的理想工具,尽管有些挑战并不容易克服。 特别是,如果一个买家在许多商店付款,则此信用通知的同现次数将显示二次增长,从而使分析不能线性扩展。 因为这种情况很少见,所以我们只考虑每张卡的并发数量,只考虑购买者购买最多的那些卡。
## 成本&一些数字
BBVA 在西班牙进行的一年信用卡交易在 Voldemort 上提供的信息量为 270 GB。 整个处理流程将在 24 个“ m1.large”实例的群集上运行 11 小时。 整个基础设施,包括为生成的数据提供服务所需的 EC2 实例,每月费用约为 3500 美元。
仍有优化的空间。 但是考虑到该解决方案敏捷,灵活且可在云中运行,价格相当合理。 在内部基础架构中运行的系统的成本将便宜得多。
## 结论&的未来
由于使用了 Hadoop,Amazon Web Services 和 NoSQL 数据库等技术,因此可以快速开发可扩展,灵活的解决方案,并准备以合理的成本承受人为的失败。
未来的工作将涉及用 [Splout SQL](http://sploutsql.com) 代替 Voldemort,它允许部署 Hadoop 生成的数据集,并将低延迟键/值扩展到低延迟 SQL。 由于可以“即时”执行许多聚合,因此可以减少分析时间并减少数据量。 例如,它将允许在任意时间段内汇总统计信息,而这是无法预先计算的。
在“ LinkedIn 开发的键/值 NoSql 数据库”之后,我停止阅读
对那些什至不知道如何添加用户密码哈希的白痴都不感兴趣。
这是一个令人困惑的描述,并且体系结构似乎布局/解释不当。 另外,如何处理节点故障?
回答“ dev”的评论:EMR 下的节点故障由 Amazon 透明处理,而 Voldemort 群集中的节点故障由 Voldemort 的故障转移功能处理。 我们只需要指定所需的复制因子,就可以相应地部署数据块。
随意问您可能感兴趣的其他问题,并且您认为这些解释不够充分。
感谢 Ivan 和 Pere,这非常有趣! 我有一个快速的问题。 270 GB 的数据集并不是很大,并且由于您最终要使用 HTTP,所以我想知道是什么导致您选择 Voldermort 而不是像 Sofadb 这样的东西? 我也对 Splout(您似乎是内部开发的)感到好奇。 在给定数据量的情况下,这似乎代表了相当大的工程努力-您能解释一下 Splout 在此特定用例与(敢于说)分片 RDBMS 的优势吗? 非常感谢!
嗨斯蒂芬,谢谢你的评论和问题。 我们选择 Voldemort 的原因有三个:速度,简单性以及与 Hadoop 的良好集成。 我们认为很少有数据库可以有效地从 Hadoop 提取数据。 我们对那些其数据结构可以由 Hadoop 预先生成并且可以以全有或全无的方式部署 Hadoop 文件且不影响查询服务的数据库感兴趣。 这为系统增加了安全层,并使后端与前端完全脱开。 反过来,这使体系结构更简单,从而消除了在处理和服务之间逐渐增加流状态的需要。
ElephantDB 是另一个可以满足这些要求并且可以选择的数据库,但是我们以前在 Voldemort 方面已有过积极的经验。
我不确定您的问题是否更像我们是否可以使用以 CouchDB 为中心的系统来替代 Hadoop + Voldemort。 如果真是这样,我们目前没有足够的 CouchDB 经验来判断这是否是一个有趣的选择。
关于 Splout SQL,实际上您实际上可以将其视为分片的 RDBMS,但它是只读的,并且与 Hadoop 紧密集成,这正是我们所需要的。 通过成为只读文件,它实际上比传统的 RDBMS 变得更易于管理,并且通过将其与 Hadoop 集成,我们使应用程序能够轻松,安全地将数据从处理过程转移到服务过程中,而这正是我上面提到的所有好处。
关于数据大小,请考虑到 270 GB 仅是西班牙的一年数据,但是该应用程序可能会服务数年和多个国家/地区的数据。 此外,由于需求变化很快,因此输出幅度仍然未知,因为每次添加新功能时输出幅度可能都会增加。
希望这能回答您的问题,否则请随时提出。
谢谢 Pere,这很有道理-我现在意识到 Splout 或 ElephantDB 的优点是不必通过 MR 对初始数据存储进行处理,然后再将 ETL 转换为需要自己维护和明显的性能优势的单独存储 是只读+(我想)要维护的代码库较小(显然 Elephant 是 2k LoC!)。 干杯!
这是一个有趣的问题,但我只是希望对它进行更多的解释。
使用这种类型的数据时(除规模之外),您遇到的最困难的事情是什么?
我自己花了 10 多年的时间分析信贷/借记数据,我很好奇:)
谢谢
Jon Wren
- LiveJournal 体系结构
- mixi.jp 体系结构
- 友谊建筑
- FeedBurner 体系结构
- GoogleTalk 架构
- ThemBid 架构
- 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构
- TypePad 建筑
- 维基媒体架构
- Joost 网络架构
- 亚马逊建筑
- Fotolog 扩展成功的秘诀
- 普恩斯的教训-早期
- 论文:Wikipedia 的站点内部,配置,代码示例和管理问题
- 扩大早期创业规模
- Feedblendr 架构-使用 EC2 进行扩展
- Slashdot Architecture-互联网的老人如何学会扩展
- Flickr 架构
- Tailrank 架构-了解如何在整个徽标范围内跟踪模因
- Ruby on Rails 如何在 550k 网页浏览中幸存
- Mailinator 架构
- Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据
- Yandex 架构
- YouTube 架构
- Skype 计划 PostgreSQL 扩展到 10 亿用户
- 易趣建筑
- FaceStat 的祸根与智慧赢得了胜利
- Flickr 的联合会:每天进行数十亿次查询
- EVE 在线架构
- Notify.me 体系结构-同步性
- Google 架构
- 第二人生架构-网格
- MySpace 体系结构
- 扩展 Digg 和其他 Web 应用程序
- Digg 建筑
- 在 Amazon EC2 中部署大规模基础架构的六个经验教训
- Wolfram | Alpha 建筑
- 为什么 Facebook,Digg 和 Twitter 很难扩展?
- 全球范围扩展的 10 个 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展
- 《 FarmVille》如何扩展以每月收获 7500 万玩家
- Twitter 计划分析 1000 亿条推文
- MySpace 如何与 100 万个并发用户一起测试其实时站点
- FarmVille 如何扩展-后续
- Justin.tv 的实时视频广播架构
- 策略:缓存 404 在服务器时间上节省了洋葱 66%
- Poppen.de 建筑
- MocoSpace Architecture-一个月有 30 亿个移动页面浏览量
- Sify.com 体系结构-每秒 3900 个请求的门户
- 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训
- Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长
- 扩展 BBC iPlayer 的 6 种策略
- Facebook 的新实时消息系统:HBase 每月可存储 135 亿条消息
- Pinboard.in Architecture-付费玩以保持系统小巧
- BankSimple 迷你架构-使用下一代工具链
- Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表
- Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件
- Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求
- Node.js 成为堆栈的一部分了吗? SimpleGeo 说是的。
- 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量
- Medialets 体系结构-击败艰巨的移动设备数据
- Facebook 的新实时分析系统:HBase 每天处理 200 亿个事件
- Microsoft Stack 是否杀死了 MySpace?
- Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰
- Facebook:用于扩展数十亿条消息的示例规范架构
- Evernote Architecture-每天有 900 万用户和 1.5 亿个请求
- TripAdvisor 的短
- TripAdvisor 架构-4,000 万访客,200M 动态页面浏览,30TB 数据
- ATMCash 利用虚拟化实现安全性-不变性和还原
- Google+是使用您也可以使用的工具构建的:闭包,Java Servlet,JavaScript,BigTable,Colossus,快速周转
- 新的文物建筑-每天收集 20 亿多个指标
- Peecho Architecture-鞋带上的可扩展性
- 标记式架构-扩展到 1 亿用户,1000 台服务器和 50 亿个页面视图
- 论文:Akamai 网络-70 个国家/地区的 61,000 台服务器,1,000 个网络
- 策略:在 S3 或 GitHub 上运行可扩展,可用且廉价的静态站点
- Pud 是反堆栈-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术
- StackExchange 体系结构更新-平稳运行,Amazon 4x 更昂贵
- DataSift 体系结构:每秒进行 120,000 条推文的实时数据挖掘
- Instagram 架构:1400 万用户,1 TB 的照片,数百个实例,数十种技术
- PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片
- Etsy Saga:从筒仓到开心到一个月的浏览量达到数十亿
- 数据范围项目-6PB 存储,500GBytes / sec 顺序 IO,20M IOPS,130TFlops
- 99designs 的设计-数以千万计的综合浏览量
- Tumblr Architecture-150 亿页面浏览量一个月,比 Twitter 更难扩展
- Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天对 2000 万张照片进行爬网,分析和排名
- LinkedIn:使用 Databus 创建低延迟更改数据捕获系统
- 在 30 分钟内进行 7 年的 YouTube 可扩展性课程
- YouPorn-每天定位 2 亿次观看
- Instagram 架构更新:Instagram 有何新功能?
- 搜索技术剖析:blekko 的 NoSQL 数据库
- Pinterest 体系结构更新-1800 万访问者,增长 10 倍,拥有 12 名员工,410 TB 数据
- 搜索技术剖析:使用组合器爬行
- iDoneThis-从头开始扩展基于电子邮件的应用程序
- StubHub 体系结构:全球最大的票务市场背后的惊人复杂性
- FictionPress:在网络上发布 600 万本小说
- Cinchcast 体系结构-每天产生 1,500 小时的音频
- 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容
- 棱镜更新:基于文档和用户的机器学习
- Zoosk-实时通信背后的工程
- WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量
- 史诗般的 TripAdvisor 更新:为什么不在云上运行? 盛大的实验
- UltraDNS 如何处理数十万个区域和数千万条记录
- 更简单,更便宜,更快:Playtomic 从.NET 迁移到 Node 和 Heroku
- Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序
- BigData 使用 Erlang,C 和 Lisp 对抗移动数据海啸
- 分析数十亿笔信用卡交易并在云中提供低延迟的见解
- MongoDB 和 GridFS 用于内部和内部数据中心数据复制
- 每天处理 1 亿个像素-少量竞争会导致大规模问题
- DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长
- SongPop 在 GAE 上可扩展至 100 万活跃用户,表明 PaaS 未通过
- Iron.io 从 Ruby 迁移到 Go:减少了 28 台服务器并避免了巨大的 Clusterf ** ks
- 可汗学院支票簿每月在 GAE 上扩展至 600 万用户
- 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段
- 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量
- Facebook 的网络秘密
- 神话:埃里克·布鲁尔(Eric Brewer)谈银行为什么不是碱-可用性就是收入
- 一千万个并发连接的秘密-内核是问题,而不是解决方案
- GOV.UK-不是你父亲的书库
- 缩放邮箱-在 6 周内从 0 到 100 万用户,每天 1 亿条消息
- 在 Yelp 上利用云计算-每月访问量为 1.02 亿,评论量为 3900 万
- 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips
- Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户,300K QPS,22 MB / S Firehose 以及发送推文
- Salesforce Architecture-他们每天如何处理 13 亿笔交易
- 扩大流量的设计决策
- ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行
- 如何制作无限可扩展的关系数据库管理系统(RDBMS)
- Bazaarvoice 的架构每月发展到 500M 唯一用户
- HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息
- NYTimes 架构:无头,无主控,无单点故障
- 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放,喜欢和更多内容
- Google 如何备份 Internet 和数十亿字节的其他数据
- 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧
- AOL.com 体系结构如何发展到 99.999%的可用性,每天 800 万的访问者和每秒 200,000 个请求
- Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 构建社交音乐服务
- 大,小,热还是冷-条带,Tapad,Etsy 和 Square 的健壮数据管道示例
- WhatsApp 如何每秒吸引近 5 亿用户,11,000 内核和 7,000 万条消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理
- 关于 Disqus 的更新:它仍然是实时的,但是 Go 摧毁了 Python
- 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明
- 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集
- 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序
- 一点点:建立一个可处理每月 60 亿次点击的分布式系统的经验教训
- StackOverflow 更新:一个月有 5.6 亿次网页浏览,25 台服务器,而这一切都与性能有关
- Tumblr:哈希处理每秒 23,000 个博客请求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构
- MixRadio 体系结构-兼顾各种服务
- Twitter 如何使用 Redis 进行扩展-105TB RAM,39MM QPS,10,000 多个实例
- 正确处理事情:通过即时重放查看集中式系统与分散式系统
- Instagram 提高了其应用程序的性能。 这是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架构
- 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大规模构建发布平台
- Aeron:我们真的需要另一个消息传递系统吗?
- 机器:惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化
- AWS 的惊人规模及其对云的未来意味着什么
- Vinted 体系结构:每天部署数百次,以保持繁忙的门户稳定
- 将 Kim Kardashian 扩展到 1 亿个页面
- HappyPancake:建立简单可扩展基金会的回顾
- 阿尔及利亚分布式搜索网络的体系结构
- AppLovin:通过每天处理 300 亿个请求向全球移动消费者进行营销
- Swiftype 如何以及为何从 EC2 迁移到真实硬件
- 我们如何扩展 VividCortex 的后端系统
- Appknox 架构-从 AWS 切换到 Google Cloud
- 阿尔及利亚通往全球 API 的愤怒之路
- 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分
- 为社交产品设计后端
- 阿尔及利亚通往全球 API 第 3 部分的愤怒之路
- Google 如何创造只有他们才能创造的惊人的数据中心网络
- Autodesk 如何在 Mesos 上实施可扩展事件
- 构建全球分布式,关键任务应用程序:Trenches 部分的经验教训 1
- 构建全球分布式,关键任务应用程序:Trenches 第 2 部分的经验教训
- 需要物联网吗? 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式
- Uber 如何扩展其实时市场平台
- 优步变得非常规:使用司机电话作为备份数据中心
- 在不到五分钟的时间里,Facebook 如何告诉您的朋友您在灾难中很安全
- Zappos 的网站与 Amazon 集成后冻结了两年
- 为在现代时代构建可扩展的有状态服务提供依据
- 细分:使用 Docker,ECS 和 Terraform 重建基础架构
- 十年 IT 失败的五个教训
- Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售
- 整个 Netflix 堆栈的 360 度视图
- Wistia 如何每小时处理数百万个请求并处理丰富的视频分析
- Google 和 eBay 关于构建微服务生态系统的深刻教训
- 无服务器启动-服务器崩溃!
- 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南
- 为 David Guetta 建立无限可扩展的在线录制活动
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿个通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训
- 缩放原理
- TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿条通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训