深入相识我们数据平台的生长作为世界领先的商业新闻机构之一，《金融时报》已经存在130多年了，以其高质量的新闻业而闻名。为了恒久保持领先职位，您必须能够适应世界的变化。在已往的十年中，这意味着随着FT举行数字化转型，能够使用技术提供的时机。

本文将深入相识这一转变的幕后故事：《金融时报》数据平台的建立和生长。数据平台提供有关读者如何与FT互动的信息，从而使我们能够决议如何继续交付读者所需和需要的工具。第1代：2008–2014早期首先，数据平台专注于凭据读者已经阅读的内容为他们提供建议。

其时，我们的大多数读者仍在阅读FT印刷品，因此一个商店和24小时的延迟就足够了。该架构简练明晰，而且《金融时报》的员工能够在其之上执行查询以分析用户的兴趣。可是随后发生了许多事件。

· 互联网革命。互联网蓬勃生长，日复一日会见ft.com而不是阅读印刷报纸的读者数量有所增加。· 移动创新。

移动设备开始成为人们生活的一部门。智能手机已从奢侈移到了期望，这使《金融时报》可以为每个最受接待的操作系统公布移动应用法式。

这成为了另一类用户，他们可以在旅行途中，在家里休息或在自然界中而无法使用条记本电脑时阅读文章而受益。第2代：2014–2016年我们的提取，转换，加载（ETL）框架的到来我们平台的第二代面临两个新挑战：首先，需要让我们的利益相关者大规模分析数据，提出新的问题。其次，数据量越来越大。

为了实现这些目的，我们在2014年建设了自己的ETL框架。这使我们的团队能够以自动化和可扩展的方式设置新的事情和模型，并具有以下功效：· 排程。天天自动运行SQL查询多次，与其他团队同步输出，最后但并非最不重要的一点是，它更多地关注业务案例而不是实现细节。· Python介面。

除了提供SQL查询外，还提供了运行Python代码的功效，从而使涉众可以运行更庞大的数据模型。· 设置胜过实现。

选择引入ETL框架的原因之一是能够以XML文件花样生成作业，这在其时可以提供更多的业务功效。ETL框架的公布发生了庞大的努力影响，但无法自行解决所有数据增加和消费者数量增加带来的问题。实际上，从性能的角度来看，添加新组件实际上会带来更多问题，因为数据平台的消费者数量有所增加，现在包罗商业智能（BI）团队，数据科学团队等。

SQL Server实例开始成为数据平台的瓶颈，因此也成为所有利益相关者的瓶颈。现在是举行更改的时候了，我们正在努力寻找针对此特定问题的最佳解决方案。由于《金融时报》已经在使用Amazon Web Services（AWS）提供的某些服务，因此我们开始评估Amazon Redshift作为一种快速，简朴和经济高效的数据堆栈（用于存储越来越多的数据）的选项。Amazon Redshift专为云中的在线分析处置惩罚（OLAP）而设计，这正是我们想要的。

使用这种方法，我们无需团队为支持新的存储服务支付任何分外的努力就能大大优化查询性能。第三代：2016–2018年《金融时报》大数据的开始有了Amazon Redshift作为数据堆栈解决方案和ETL框架作为用于部署提取，转换，加载作业的工具，所有FT团队都看到了拥有数据平台的利益。

可是，当为一家领先市场的大公司（例如《金融时报》从事商业新闻公布）事情时，我们不能对我们现有的成就感应满足。这就是为什么我们开始思量如何进一步改善此架构的原因。我们的下一个目的是淘汰数据延迟。

我们天天要提取一次数据，因此延迟长达24小时。淘汰等候时间将意味着FT可以更快地响应数据趋势。为了淘汰延迟，我们于2015年开始研究一种名为下一代数据分析（NGDA）的新方法，并于2016年头被《金融时报》的所有团队接纳。

首先，我们开发了自己的跟踪库，卖力将读者的每次互动都发送到数据平台。现有的体系结构预期将由ETL Framework运行的作业天天传输一次CSV文件列表，因此，逐个发送事件意味着我们需要更改现有体系结构以支持新的事件驱动方法。然后，我们建立了一个API服务，卖力吸收读者的互动。

可是，我们仍然需要一种方法，以尽可能低的延迟将这些数据传输到数据堆栈，以及将这些数据袒露给多个消耗下游的系统。当我们将所有服务迁移到云，更详细地说是迁移到AWS时，我们研究了Amazon提供的可满足事件处置惩罚需求的托管服务。在分析了备选方案之后，我们重新设计了系统，以将所有原始事件从ft.com发送到简朴通知服务（SNS）。

使用这种方法，组织中的许多团队就有可能订阅SNS主题并依靠实时数据来解锁新的业务案例。可是，仅在SNS中拥有这些原始数据还不够-我们还需要将数据放入数据堆栈中以支持所有现有的事情流程。我们决议使用简朴行列服务（SQS）行列，因为它允许我们在事件到达系统后立刻将所有事件持久生存在行列中。

可是在将数据移至数据堆栈之前，我们的业务又有一个要求-使用内部服务，外部服务或简朴的内存转换提供的附加数据来富厚原始事件。为了以最小的延迟满足这些需求，我们建立了一个NodeJS服务，该服务卖力异步处置惩罚循环中的所有事件，从而使扩展步骤可以大规模举行。

一旦事件被完全充实，数据将立刻发送到AWS其时提供的唯一托管事件存储-Kinesis。使用这种体系结构，我们能够以毫秒级的延迟将富厚的事件连续存在，这对于我们的利益相关者来说是一个了不起的消息。一旦将数据存储在Kinesis Stream中，我们就使用另一个AWS托管服务Kinesis Firehose消耗富厚的事件流，并凭据以下两个主要条件之一（经由了预定时间段）将它们作为CSV文件输出到S3存储桶中（这种情况很少发生）或文件巨细到达100mb。这种新的事件驱动方法凭据一天中的时间在几分钟之内生成了带有富厚事件的CSV文件，因此，我们在数据湖中的延迟淘汰到了1-5分钟。

可是业务团队另有一个更重要的要求。他们要求在数据堆栈中提供洁净的数据。使用Kinesis Firehose方法，我们不能保证只有一个事件实例，因为：· 我们可以从客户端应用法式吸收重复事件。· 当Firehose作业因失败而重试时，Kinesis Firehose自己可能会重复数据。

为了对所有事件举行重复数据删除，我们建立了另一个Amazon Redshift集群，卖力对每个新CSV文件举行摄取和重复数据删除。这涉及一个权衡：实施一个历程以确保唯一性将数据进入数据堆栈的延迟增加到约莫4小时，但使我们的业务团队能够更轻松地生偏见解。第4代：2019年重建平台，使我们的团队能够专注于增加业务价值该平台的第3代运行起来很庞大。我们的团队全天大部门时间都在为大量独立服务提供支持，工程成本不停增加，而举行有趣，有影响力的事情的时间却少得多。

我们希望使用新技术来降低这种庞大性，同时也为利益相关者提供更多令人兴奋的功效：我们希望将数据平台转变为PaaS（平台即服务）。我们最初的尺度是平台应提供：· 自助服务-使利益相关者能够独立开发和公布新功效。· 支持多个内部消费者-差别的团队具有差别的会见级别。

· 宁静隔离-团队只能会见自己的数据和作业。· 代码重用-制止通用功效重复。建设多租户自助服务平台很是具有挑战性，因为它需要每项服务来支持这两个方面。只管如此，为实施此方法而支付的努力对于未来将是极为有益的，其主要利益是：· 利益相关者团队可以交付价值，而不必等候与平台团队举行协调-这样可以降低成本，提高速度并让他们掌控自己的运气· 平台团队可以专注于为平台构建新功效-而不是花费时间来疏散利益相关者团队我们选择实现这种脱钩的方式是通过着眼于设置而不是实施，利益相关者团队能够使用治理Web界面凭据其内部团队结构，角色和权限来建设自己的治理规则。

Kubernetes软件系统就像屋子。您需要从基础而不是从屋顶构建它。在工程中，基础是基础架构。

没有稳定的基础架构，就不行能拥有生产停当的稳定系统。这就是为什么我们从基金会开始，讨论什么是短期和恒久未来的最佳方法。

我们现有的数据平台已部署到AWS ECS。只管AWS ECS是一个很是精彩的容器协调器，但我们决议切换到Kubernetes，因为在EKS上，我们获得支持来支持许多支持多个租户的事情，例如租户之间的宁静隔离，每个租户的硬件限制等。除此之外，另有许多Kubernetes运算符对我们来说是开箱即用的，例如spark-k8s-operator，prometheus-operator等。

AWS一直在提供托管Kubernetes集群（EKS）一段时间，对于短期和恒久的未来，它显然是数据平台基础的选择。为了拥有一个自助式多租户数据平台，我们必须在每个服务和Kubernetes集群自己之上应用几个要求。· 系统名称空间-在隔离的Kubernetes名称空间中分开所有系统组件，这些名称空间卖力治理所有服务。

· 每个团队的命名空间—将所有团队资源分组在Kubernetes命名空间中，以便为每个团队资源自动应用基于团队的设置和约束。· 每个名称空间的宁静隔离-限制Kubernetes集群中的跨名称空间会见，以防止差别团队资源之间发生意外交互。

· 每个命名空间的资源配额-当其中一个团队到达硬件极限时，防止影响所有团队，同时通过盘算每个团队的花费和交付的业务价值之间的比率来权衡效率。批量处置惩罚ETL框架相当稳定，已经运行了许多年，可是要完全受益于我们接纳云原生技术，我们需要一个新的框架来支持：· 云部署。

· 水平缩放。随着事情流程数量和数据量的增加，我们需要能够以最小的努力举行扩展。· 多租户。

因为整个平台都需要支持这一点。· 部署到Kubernetes同样，为了确保整个平台的一致性。自从我们建设ETL框架以来，ETL的期望一直在继续。

我们希望能够支持：· 与语言无关的事情。为了充实使用使用数据平台的所有团队的种种技术。· 事情流程的观点。界说事情流中相互依赖的事情序列的需求是天天做出以数据为依据的决议的另一个关键业务需求。

· 代码可重用性。由于事情流中某些步骤背后的功效是重复的，因此它们是代码重用的理想选择。· ETL作业的自动漫衍式回填。由于此历程在我们的新用例中经常发生，因此自动化将提高业务速度。

· 监控。我们需要良好的监控，以防止基于低质量，高延迟甚至丢失数据做出数据驱动的决议。· 可扩展性。

基于利益相关者提供的反馈和要求以新功效扩展批处置惩罚服务的能力将使该服务在可预见的未来足够灵活。另一个重大变化是，现在已经存在功效齐全的ETL框架，而不必重新开始构建。

思量到所有这些要求之后，我们评估了市场上的差别选项，例如Luigi，Oozie，Azkaban，AWS Steps，Cadence和Apache Airflow。最切合我们要求的是Apache Airflow。只管它很棒，但仍然有一些限制-例如单个调理法式和缺乏本机多租户支持。

只管现在基于基准测试，我们的预计负载以及Apache Airflow 2.0中该功效的预期公布，第一个对我们来说并不是一个大问题，可是第二个将影响我们的整个体系结构，因此我们决议构建自界说Apache Airflow之上的多租户支持。我们思量使用Apache Airflow托管服务-有多个提供法式-但最终决议凭据一些要求（包罗多租户，与语言无关的作业和监视）继续接纳自我治理的解决方案。使用托管解决方案无法实现所有这些要求，从而导致了可扩展性要求及其对我们的重要性。

将Apache Airflow集成到我们的平台后，我们首先在平台之上公布新的事情流程以确保其功效。当我们知道它满足所有条件时，下一步就显而易见了，当前我们正在将所有现有的ETL作业迁移到Apache Airflow。除此之外，我们已将其作为自助服务产物公布给公司中的所有利益相关者，而且我们已经拥有诸如BI团队，数据科学团队等客户。

第5代：2020年是时候获取实时数据了第四代是向前迈出的一大步。可是，仍有一些革新目的。实时数据对于我们数据的重要部门，我们的延迟仍然约为4小时。

这4个小时的延迟中的大多数是由于重复数据删除历程而发生的，这对于我们的涉众及其需求而言很是重要。例如，金融时报无法基于低质量数据做出任何业务生长决议。因此，我们必须确保我们的数据堆栈在这些用例中保留洁净的数据。可是，随着产物，业务和技术的生长，泛起了新的用例。

纵然使用一小部门低质量数据，它们也可以通过使用实时数据来提供影响。一个很好的例子是凭据读者的兴趣在ft.com和移动应用法式中订购用户的供稿。

对于这个用例来说，有几个重复的事件并不是至关重要的，因为用户体验总是比向所有用户显示相同内容而不体贴他们的兴趣要好得多。我们已经有了一个稳定的流处置惩罚架构，可是它很是庞大。

我们开始研究通过使用Apache Kafka作为事件存储从SNS，SQS和Kinesis迁移到新架构来优化它。为事件存储提供托管服务将是我们的偏爱，我们决议实验一下Amazon MSK，因为它似乎已经稳定了一段时间。在Apache Kafka主题中提取数据是向企业提供实时数据的一个很好的起点。

可是，利益相关者仍然无法会见Apache Kafka集群中的数据。因此，我们的下一个目的是建立一个流处置惩罚平台，使他们可以在实时数据之上部署模型。我们需要与我们架构的其余部门相匹配的工具-支持多租户，自助服务，多种语言而且可部署到Kubernetes。思量到这些需求，Apache Spark似乎是最适合我们的应用法式，它是最常用的分析引擎，而且是全球最大的开源社区之一。

为了将Apache Spark流作业部署到Kubernetes，我们决议使用spark-on-k8s-operator。此外，我们在数据用户界面中构建了一个部门，该部门允许我们的涉众通过填写一个简朴的表格来将其Apache Spark流处置惩罚作业部署到生产情况，该表格包罗该作业的信息，例如Docker映像和标签，CPU和内存限制，作业中使用的数据源等数据合约我们需要举行优化的另一个领域是将数据验证移至开发流程中最早的步骤。

我们有服务来验证进入数据平台的数据，可是这些验证是在管道的差别步骤中执行的。由于管道有时由于传入的不正确数据而中断，因此导致泛起问题。

因此，我们希望通过提供以下功效来改善这一领域：· 管道中事件流的数据条约· 将验证步骤移至最早的阶段· 添加压缩以减小事件巨细思量到所有这些需求，我们找到了使用Apache Avro到达这些要求的好方法。它允许在Apache Kafka中为每个主题界说一个数据协定，从而确保集群中的数据质量。

这种方法还解决了另一个问题-可以将验证步骤移到管道中的第一步。将Apache Spark流作业与Apache Avro模式联合使用，可以将所有不正确的事件移至用作"死信行列"的其他Kafka主题，从而防止我们在管道中破坏数据。Apache Avro附带的另一个重要功效是序列化和反序列化，这使得可以对Apache Kafka事件存储区中持久存储的数据举行压缩。数据湖从CSV迁移到我们的数据湖存储中的镶木文件是满足我们大多数需求的绝佳初始选择。

可是，我们仍然缺少一些可以使我们的生活变得更轻松的功效，包罗ACID事务，架构实施和更新镶木地板文件中的事件。在分析了市场上所有现有的替代产物（包罗Hudi，Iceberg和Delta Lake）之后，我们决议基于对Apache Spark 3.x的支持开始使用Delta Lake。它提供了所有主要要求，很是适合我们的体系结构。· 效率。

我们将盘算历程与存储解耦，从而使我们的架构可以更高效地扩展。· 低延迟，高质量数据。使用Delta Lake提供的upsert和模式执行功效，我们可以一连地向《金融时报》的所有利益相关方提供低延迟和高质量的数据。· 多个接入点。

将所有传入数据持久存储在Delta Lake中，使涉众可以通过包罗Apache Spark和Presto在内的多个系统查询低延迟数据。· 时间旅行。Delta Lake允许重新处置惩罚已往特定时间的数据，从而自动回填数据，此外还可以针对特定用例（例如陈诉或培训机械学习模型）在特定日期距离之间举行分析。

虚拟化层在《金融时报》中，公司团队使用的存储类型有所差别，包罗Amazon Redshift，Google BigQuery，Amazon S3，Apache Kafka，VoltDB等。可是，利益相关者经常需要分析疏散在多个数据存储中的数据。为了做出数据驱动的决议。为了满足此需求，他们使用Apache Airflow在差别的数据存储之间移动数据。

可是，这种方法远非最佳。使用批处置惩罚方法会给数据增加分外的延迟，而且在某些情况下，使用低延迟数据举行决议对于业务用例至关重要。此外，部署批处置惩罚作业需要更多的技术配景，这可能会限制一些利益相关者。思量到这些细节之后，我们对利益相关者的期望提出了一些明确的要求，以便为读者带来更多价值—支持：· 任何存储的暂时查询· ANSI SQL-他们经常熟知的语法· 能够在差别数据存储之间联接数据我们希望能够部署到Kubernetes，以适应我们的平台架构。

在分析了市场上的差别选择之后，我们决议从Presto开始，因为它允许公司大规模分析PB级数据，同时能够合并来自许多数据源的数据，包罗《金融时报》使用的所有数据源。计划未来在《金融时报》上，我们从未对我们的成就感应满足，这就是该公司在业务领域保持领先130多年的原因之一。

因此，我们已经制定了如何进一步生长该架构的计划。· 摄取平台。我们使用三个组件来摄取数据-由Apache Airflow治理的批处置惩罚作业，消耗来自Apache Kafka流的数据的REST服务和希望将数据输入到数据平台的REST服务的Apache Spark流作业。我们的目的是用Change Data Capture（CDC）替换现有的高延迟摄取服务，该服务可在数据到达任何数据源时立刻摄取新数据，因此该业务将能够为我们的读者提供更好的体验。

· 所有人的实时数据。我们想到的主要功效之一是使《金融时报》的所有人都可以会见数据，而无需具备特定的技术技术。

为此，我们计划增强Data UI和流处置惩罚平台，以允许拖放操作来构建流作业。这将是一项庞大的革新，因为它将使没有技术配景的员工能够使用，转换，生成和分析数据。

如果您对完成具有挑战性的大数据任务感兴趣，请思量在保加利亚索非亚的办公室申请加入我们的数据团队。我们正在等你！(本文由闻数起舞翻译自Mihail Petkov的文章《Financial Times Data Platform: From zero to hero》，转载请注明出处，原文链接：https://medium.com/ft-product-technology/financial-times-data-platform-from-zero-to-hero-143156bffb1d)。

本文来源：betway必威-www.rcgdgc.com