典型案例：一个数据平台的十二年架构演变历程.pdfVIP

典型案例：⼀个数据平台的⼗⼆年架构演变历程 作者 | Mihail Petkov 策划 | Tina 英国⾦融时报是世界上最⼤的商业新闻机构之⼀，已有 130 多年历史，以其⾼质量的新闻报道⽽闻名。 要想长时间保持领先地位，就必须能够适应世界的变化。过去 10 年，为了利⽤技术提供的机遇，⾦融 时报经历了⼀次数字化转型。 本⽂将深⼊介绍这⼀转型的幕后故事：⾦融时报数据平台的创建和演化。该数据平台提供读者与 FT 互 动的信息，让我们能够决定如何继续为读者提供他们想要和需要的东西。 1第⼀代：2008–2014 早期 起初，数据平台专注于根据读者已经阅读的内容做推荐。 当时，我们的⼤多数读者仍在阅读纸质版《⾦融时报》，因此，⼀个存储和 24 ⼩时的延迟就⾜够了。 该架构⼲净、简单，⾦融时报的员⼯能够在上⾯执⾏查询，分析⽤户兴趣。 但随后发⽣了⼀些事情。 1.互联⽹⾰命。互联⽹蓬勃发展，访问 ⽽⾮阅读纸质报纸的读者数量每天都在增加。 2.移动创新。移动设备开始成为⼈们⽇常⽣活的⼀部分。智能⼿机从⼀种奢侈品变成了⼀种预期，⾦融 时报就针对每 种最流⾏的操作系统发布了移动应⽤程序。这成了另⼀个⽤户流，让他们不管是在上班的路上，还是在 家⾥休息，亦或是在户外享受⼤⾃然时，都可以从阅读⽂章中获益，⽽不必借助笔记本电脑。 2第⼆代：2014–2016 提取、转换、加载（ETL）框架的到来 我们的第⼆代平台⾯临两个新的挑战：⾸先，需要使我们的涉众能够⼤规模地分析数据，提出新的问 题；其次是数据量的增加。 为了实现这些⽬标，我们在 2014 年构建了⾃⼰的 ETL 框架。这使得我们的团队能够以⾃动化和可扩展 的⽅式创建新的作业和模型，并包含如下特性： 1.调度。每天⾃动运⾏多次 SQL 查询，与其他团队同步输出结果，最后但同样重要的是，更多地关注业 务⽤例⽽不是 实现细节。 2.Python 接⼝。除了 SQL 查询之外，还提供了运⾏ Python 代码的能⼒，允许涉众运⾏更复杂的数据模 型。 3.重配置轻实现。选择引⼊ ETL 框架的其中⼀个原因是能够⽣成 XML ⽂件格式的作业，这在当时催⽣ 了更多的业务 功能。 ETL 框架的发布产⽣了巨⼤的积极影响，但它本⾝并不能解决因为数据量和⽤户数增加⽽带来的所有问 题。 实际上，从性能的⾓度来看，添加这个新组件实际上会带来更多的问题，因为数据平台的消费者数量增 加了，现在包括商业智能（BI）团队、数据科学团队和其他团队。SQL Server 实例开始成为数据平台的 瓶颈，也成为所有涉众的瓶颈。现在是做出改变的时候了，我们设法为这个特定的问题找到了最好的解 决办法。 考虑到⾦融时报已经在使⽤ Amazon Web Services （AWS）提供的⼀些服务，我们开始评估 Amazon Redshift ，将其作为⼀种快速、简单、划算的数据仓库，⽤于存储越来越多的数据。Amazon Redshift 是 为云端在线分析处理（OLAP）⽽设计的，这正是我们⼀直在找的东西。使⽤这种⽅法，我们能够⼤幅 优化查询性能，⽽不需要团队付出任何额外的努⼒来⽀持新的存储服务。 3第三代：2016–2018 ⾦融时报⼤数据时代来临 将 Amazon Redshift 作为数据仓库解决⽅案，将 ETL 框架作为部署提取、转换、加载作业的⼯具，所有 FT 团队都看到了拥有⼀个数据平台的好处。然⽽，当我们在⼀家引领市场的⼤公司⼯作时，⽐如在⾦融 时报从事商业新闻发⾏时，我们不能满⾜于现有的成就。这就是为什么我们开始思考如何进⼀步改进这 个架构。 我们的下⼀个⽬标是减少数据延迟。我们每天摄⼊⼀次数据，因此延迟时间长达 24 ⼩时。减少延迟意 味着 FT 可以更快地对数据趋势做出反应。 为了减少延迟，我们在 2015 年开始研究⼀种名为下⼀代数据分析（NGDA ）的新⽅法，并在 2016 年初 被⾦融时报的所有团队采⽤。 ⾸先，我们开发了⾃⼰的跟踪库，负责将读者的每⼀次互动发送到数据平台。现有的架构需要⼀个 CSV ⽂件列表作为输⼊，这些⽂件由 ETL 框架运⾏的作业每天传输⼀次，因此，逐个发送事件意味着我们需 要更改现有的架构以⽀持新的事件驱动⽅法。 然后，我们创建了⼀个 API 服务，负责接收读者的交互。但是，我们仍然需要⼀种⽅法，以尽可能低的 延迟将这些数据传输到数据仓库，并将这些数据公开给多个下游消费系统。在我们将所有服务迁移到云 （更具体地说是迁移到 AWS）上时，我们了解了 Amazon 提供的能够满⾜我们事件处理需求的托管服 务。 尽管如此，仅仅是在 SNS 中有这些原始数据还不够——我