Flume也扛不住的千亿级数据,OPPO如何靠自研提升

      最后更新:2020-03-25 13:33:16 手机定位技术交流文章

      1。后台


      OPPO互联网服务每天都会生成大量数据。例如,欧洲航天局跟踪系统,一个链跟踪系统,被称为。每日采样请求数据超过1000亿个级别。我们需要对这些数据进行分类、汇总、过滤和存储。同时,需要对采集的数据进行多通道并行处理,如关键指标的并行报警和写入存储集群。


      以及数据采集系统的性能、通道隔离、吞吐量等因素对我们来说是一个挑战在我们的应用场景中,开源水槽不能满足我们在可视化、监控、性能和通道隔离等方面的需求。


      esa数据流是由OPPO internet开发的高性能数据流收集、聚合和传输框架。单个节点的日平均处理数据量超过100亿条。与Flume相比,它在操作和维护可视化、路由、并行处理能力等方面有较大的提高。


      2,基本概念


      esa数据流是一个高性能数据流处理框架,具有


      消息路由:灵活的路由规则,可将消息分发到不同的通道进行处理高性能:单个节点每天能够处理超过100亿条数据易于扩展:内置通用的源和汇。通道开发人员可以灵活地定制源、通道和接收器的扩展,以及序列化方法。监控操作和维护:内置管理控制台,可实时查看数据输入、缓冲、消耗率等各种数据统计


      的内部结构如下:



      1,data event


      data event是数据流端到端传输的基本单元。它由正文和标题信息组成,由K-V组成的地图信息主要用于数据信息传输


      私人地图& lt字符串,字符串>。headers =新的哈希映射& lt>。();私人列表T>。正文=新数组列表& lt>。();Source


      是一个数据源,它接受来自特定通道(如Http)的数据,并将消息路由和分发到该通道开发人员通过继承SourceBase来实现sourcebase的功能。


      2,通道


      it缓冲收到的数据事件,直到它们被所有接收器节点使用。通道传输需要序列化和反序列化。默认情况下采用Kryo。开发人员可以根据实际情况使用其他序列化方法,如protobuf。开发人员通过继承通道库来实现通道、序列化和反序列化的功能。


      3,Sink


      它主要从Channel获取数据,并将数据传输到下一个目的地,如Elasticsearch、RocksDB水槽有且只有一个通道开发人员通过继承SinkBase来实现Sink函数。


      3。框架


      的发展我们最初的要求是能够接收大流量和高度并发的数据采集框架,并具有良好的可扩展性。所以我们有原始版本:



      数据流框架分为三层,类似于水槽的源、通道和汇的概念


      我们开发了初始扩展:HttpSource、MemoryChannel和Sink扩展由开发人员根据业务需求定制


      1)httpSource


      数据流内置的Http源实现,这是一个基于Netty实现的高性能Http服务器在500个线程(4c8g,cpuload 99%)下,请求的数据大小为1kb,平均TPS达到13w/s


      2)内存通道


      内存队列,基于Java内置阻塞队列实现使用时,需要控制队列的数量和对象的大小;如果数据量太大,很容易造成流程的OOM如果重新启动,数据将会丢失。


      HttpSource使用Netty实现Http服务,内存通道使用内存队列实现通道,以满足高性能和高并发性的要求。但是,当内存通道重新启动该过程时,如果数据没有被完全消耗,通道中的数据就会丢失,这使得可靠性得不到很好的保证。因此,我们有一个文件队列通道:



      3)文件队列通道


      文件队列。采用基于mmap的文件队列来保证数据的本地持久性,并且数据不会在进程崩溃和重启时丢失。但是,如果服务器异常关闭,页面缓存中的缓存数据可能会丢失。与传统的输入输出读写相比,mmap大大提高了读写效率,从而保证了极高的通道数据传输吞吐量。


      ,特别是在日志收集和呼叫链收集服务的应用中,文件队列的通道扩展实现了在线可靠性和吞吐量之间的平衡。服务的特殊性可以容忍少量数据的丢失(服务器电源故障、异常重启等)。)在极端异常的条件下。当然,mmap也支持强制刷盘的方法,但是读写效率会大大降低,mmap带来的好处也不会得到充分利用。


      1,并行处理


      随着业务的深入迭代,FileQueueChannel被大规模使用,而Channel和Sink之间的一一对应使得业务无法进行更灵活的扩展。例如日志警报和日志存储,如果它们都在一个接收器中处理,那么业务逻辑就会耦合起来


      的实际情况可能更糟:当日志的后端存储异常时,日志警报的数据采集和发送取决于整个接收器的消耗。如果后端存储的恢复时间是半小时后,日志警报的发送时间也是半小时后,这对于依赖于日志警报的在线服务是不可接受的。



      为了解决上述问题,我们扩展了文件队列通道,使相同的数据支持多个接收器并行使用,并且拥有独立的线程池而不会相互干扰:



      多个接收器维护自己的消费站点而不会相互干扰例如,专家系统仓储的故障或延迟不会影响报警链接的执行。


      我们最早的服务成功率和耗时的警报是在存储后实时计算的。该实时计算系统的延迟将影响报警的及时性。因此,代替相关性计算的指标,警报直接在接收器处执行,从而大大提高了警报的及时性和可靠性。


      2,数据整形


      如呼叫链系统,SDK每次报告不同的数据量和数据类型。通过数据分类和整形,通道消耗的数据量是固定的,大大提高了数据写入的性能。



      3,消息路由


      SDK报告各种消息类型。我们需要将不同的消息分发到不同的通道进行处理。例如,我们需要将数据事件对象日志类型头值等于jvm的消息路由到xxxChannel


      & lt;路线-规则>& lt规则>。& lt表达式>。header . LogType =“JVM”& lt;/expression>。& lt目标频道>。xxxChannel<。/targetChannel>。& lt/rule>。& lt/route-rules>。


      4,可视化


      eSa数据流内置SQLite数据库,根据分钟维度实时收集7天内的数据,并提供内置的简单用户界面。当然数据流也提供普罗米修斯监控界面。方便地集成到内部监控系统中:


      测试数据





      4,OPPO

      |中的ESA数据流应用


      集合服务的典型部署图如下:



      。以日志收集为例,基于数据流的类图如下:



      紫色部分为用户自定义扩展


      从上图可以看出,ESA数据流大大降低了开发人员开发采集系统的难度。


      日志采集架构


      客户端分为日志采集和代理采集两种方式客户端采用加权轮询调度算法作为负载均衡策略。如果其中一个节点崩溃,客户端可以故障转移到其他节点,以确保数据的可靠性


      开发人员可以通过每个节点的内置控制台查看统计数据,并相应地调整权重策略



      五、结论


      基于ESA数据流,开发人员可以轻松开发高性能数据收集服务:它内置了HttpSource、FileQueueChannel和其他组件,以确保其高性能和高吞吐量。轻量级且易于学习的体系结构可以确保业务的不同数据处理需求,并且可以轻松扩展不同的插件来满足它们。但是通过内置的网络界面,我们可以直观地分析和跟踪一周内的数据流。这是一个面向开发人员的轻量级高性能数据采集、传输和处理框架。


      目前使用ESA数据流开发的呼叫链收集服务,每天处理超过1000亿级的数据,集群大小约为10个节点服务上线后,在稳定性、性能、吞吐量等方面达到了预期的结果。


      作者,OPPO互联网技术基础技术

      源代码,OPPO互联网技术(id: OPPO _ tech)

      DBA plus社区欢迎各种技术人员的贡献。投稿电子邮件:editor@dbaplus.cn

      近年来,大数据技术发展迅速,并不断更新以满足新时代的海量数据处理需求。然而,随着技术的变化,每一次进化都需要很多人的精力和时间,而以前的数据治理模型已经摇摇欲坠。这时,数据操作应运而生。让我们一起来看看中国联通大数据背后的数据运营系统建设与Gdevops全球敏捷运营峰会北京站:


      “数据智能时代:构建开放运营商的大数据数据运营系统”中国联通大数据基础设施平台负责人/高级架构师尹郑钧

      本次研究的目的是让大家了解联通大数据背后的数据运营平台整体框架的演变,包括数据采集、交换和处理流程等核心实际内容然后在2020年9月11日,我们将在北京


      本文由 在线网速测试 整理编辑,转载请注明出处,原文链接:https://www.wangsu123.cn/news/2816.html

          热门文章

          文章分类