如果您喜欢视频,请在数据委员会2023 "When to Move from Batch to Streaming and how to do it without hiring an entirely new team"
上查看Zander的演讲。数据处理的世界正在发生重大转变,朝着实时处理方向发展。尽管了解将工作负载转移到实时可以提高投资回报率并降低成本,但业界尚未达成共识,围绕如何最好地过渡工作量到实时,以及对于不同类型的实时实时的最佳工具是什么工作负载。尽管传统的分析工具(例如数据仓库,商业智能层和指标)被广泛接受和理解,但实时数据处理的概念以及使其能够得到广泛认可或商定的技术。
在这篇文章中,我们旨在揭开实时数据处理,讨论其在组织中的相关性,不同类型的实时工作负载以及我在Github期间的一些现实示例。但是首先,让我们澄清一些定义。
了解实时和流处理
什么是实时? “实时”是指人类实时发生的任何事物 - 肯定是模糊的定义。定量地,这通常是指在次秒领域中发生的过程。有趣的是,基于此定义,批处理和流处理技术实际上可以实时数据处理,具体取决于端到端的潜伏期。
流处理是指一次处理一个基准,在连续流中流动,而批处理处理是当您收集一批数据并一次处理时。通过逐渐减小批次的大小,我们可以更接近实时处理。这正是像Spark的结构化流有关微批量的技术。
现在我们有了一些定义,让我们深入实时处理和不同类型的实时工作负载。
实时数据处理的相关性
在我们的日常生活中,我们不断实时接收和处理信息。考虑驾驶汽车 - 一项需要处理多个输入并实时做出决策的活动。如果我们要以批处理处理方式进行驾驶,等待收集信息持续一段时间,然后试图预测接下来的15秒,那么这可能会在灾难中结束。作为另一个例子,您可以想象一项像篮球这样的运动。在每一刻,玩家都会收到数十个或数百个输入,他们会实时对它们做出反应。如果我们还想象一下这是一个非真实的时间版本,那么观看或播放时,每个玩家在接收输入时等待一定数秒的时间并不是那么令人兴奋,然后尝试对这些输入做出反应。
这些示例有助于突出显示为什么我们可以选择实时处理事物。在驾驶的背景下,我们正在做出可能是生死攸关的问题。在我们的篮球示例中,实时处理可以提高用户体验。但是,尽管这些示例提供了一些理解,但它们并不一定有助于我们推广该概念。
实时工作量的类型
我们可以将实时处理分为两种类型的工作负载:分析和操作。
分析工作负载
分析工作负载需要低潜伏期,新鲜度和大规模检索能力。实时分析工作负载必须是可查询的。一个很好的例子是LinkedIn的个人资料视图通知。当您单击“配置文件”视图通知时,您将被带到显示您的个人资料视图历史记录的页面,一直到最新数据。这证明了数据的新鲜感和查询能力,因为您可以过滤和与数据进行交互,查询最新鲜的数据。
实时分析工作负载的另一个示例是Instacart订单。当您在Instacart上下订单时,您可以进入订单,并查看更新的估计到达时间(ETA)。这是用户实时与分析数据进行交互的分析实时工作负载的另一个实例。
操作工作负载
另一方面,操作工作负载需要低潜伏期和新鲜度,但它们也需要反应性。这意味着某些决策或业务逻辑被嵌入到系统中。例如,在流式用例中,这将在流处理器内部。收到,转换数据,然后以在线方式做出决定。 bytewax是一个框架的一个很好的例子,该框架可用于为操作工作负载做出实时决策。
操作处理的一个很好的例子是欺诈检测。欺诈检测系统实时采用所有投入,并在没有人类的情况下就它们做出决定。然后,它决定该做什么并与用户进行通信以确认其怀疑欺诈是否正确。
金融市场中的另一个例子是高频交易。该软件系统会从各种不同的数据源中消耗输入,实时处理它们,然后决定是否购买或出售。做出决定的速度是在这种情况下的关键因素。
分析与操作
我想在这里介绍的另一个方面是,在循环中让人类与循环中有一台机器之间的区别。如果我们查看分析和运营工作负载的不同示例,就会有一个概念,即人更多地参与分析性,而不是参与运营的概念。
总结一下,如果您认为您认为有价值可以得出并且循环中有一个人,那么实时空间内可能有一部分工具,而这些工具属于分析工作负载之下。如果您正在构建类似算法交易系统之类的东西,那么您认为在循环中没有人需要的人,您更有可能属于运营类别,并且您应该查看工具,例如Bytewax,以支持支持操作处理。
实例探究。 GitHub的实时数据处理决策
让我们通过讨论一些涉及我们在GitHub关于实时数据处理的决策的案例研究来使事情变得更具体。
趋势存储库和开发人员:批处理处理方法
我是Github的团队,负责GitHub.com上出现的几种数据产品,包括趋势存储库和趋势开发人员。这些功能位于GitHub探索页面上,旨在根据各种指标(例如星星,叉子和视图)来识别趋势存储库和开发人员。我们可以通过另一个团队管理的流媒体平台(KAFKA)实时访问此数据。
尽管我们有能力将它们作为实时功能实施,但我们决定反对它。我们的团队主要由以前从未使用过流平台或流处理器工作的数据科学家和机器学习工程师组成。此外,这些功能是新产品,我们不知道它们会有多影响,或者用户是否会发现它们有价值并反复与它们互动。
我们决定以批处理格式处理这些数据,而不是实现这些功能来使用实时数据。我们将对Presto进行每晚的查询,Presto的数据从Kafka降落,然后将处理的数据存储在MySQL数据库中,以从Github.com检索。这些功能不是实时工作量,但可能是。如果确定它们将作为实时数据产品有用,它们将作为分析用例的绝佳例子。
Star垃圾邮件检测:实时处理解决方案
我们执行的另一个任务是Star垃圾邮件检测。 GitHub存储库中“星星”的概念被用作衡量项目健康和实用性的代理。如果我们无法检测到星级垃圾邮件发送者,它将降低平台对用户的价值,有可能导致平台的整体价值下降。
我们决定实时解决这个问题,以限制用户的曝光率,并从Star Spam中限制平台的潜在退化。该数据可在Kafka获得,因此可以在可用的情况下消耗。根据某些标准,可以将用户标记为垃圾邮件发送者,然后采取行动。一旦标记用户,他们就会提交人类审查,以决定下一步应该是什么。这是操作处理的一个很好的例子。
实时处理决策的影响
关键是实施实时处理的决定可能会对项目的投资回报率产生重大影响,应仔细考虑这种相关性。如果我们决定实时进行趋势功能,那么通过尽可能接近实时的星级垃圾邮件来维护平台的价值更加必要。
数据的价值通常会随着时间的流逝而降低,虽然通常被描述为急剧下降(请参见左图),但大多数项目或数据倾向于遵循更多的S曲线(右图)。一定点之后,数据的返回或值相对于延迟而言。在这些案例研究中,随着潜伏期的降低,投资回报率呈指数增长,我们能够在一个小时的时间范围内而不是毫秒。这表明,并非所有数据项目都需要向零潜伏期发展以提供重要的价值。
如果您有兴趣将某些工作负载移至实时,并且不确定从哪里开始。请在our slack channel与我们联系,我们很乐意帮助您弄清楚该价值是否在那里以及从哪里开始。