OPPO互联网业务每天产生海量的数据，如调用链跟踪系统ESA Trace，每日采样的请求数据超过千亿级别，我们需要对这些数据进行归类，聚合、过滤和存储，同时我们需要对采集到的数据进行多通道并行处理，比如并行进行关键指标告警和写入存储集群。

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

ESA DataFlow是由OPPO互联网自研的一款高性能的数据流采集、聚合和传输框架，单节点的日均处理数据量超过百亿条。相较Flume在运维可视化、路由、并行处理能力等方面有较大的提升。

其内部结构如下：

DataEvent是DataFlow端到端传输的基本单元，它由body和headers信息构成，由K-V构成的Map信息，主要用于数据信息的传递。

它是数据源，从特定通道（如Http）接受数据，把消息路由分发到Channel中。开发者通过继承SourceBase实现Source的功能。

它缓存接收到的DataEvent直到它们被所有Sink节点消费完成，Channel传输时需要序列化及反序列化，默认采用的是Kryo，开发者可以根据实际情况使用其它序列化方式，如protobuf。开发者通过继承ChannelBase实现Channel的功能以及序列化和反序列化。

它主要从Channel中获取数据，将数据传输到下一个目的地，如Elasticsearch、RocksDB。一个Sink有且只有一个Channel。开发者通过继承SinkBase实现Sink的功能。

我们最初的需求是能够接收大流量和高并发的数据采集框架，并且具有良好的扩展性。于是我们有了最初版本：

DataFlow框架分三层，类似Flume的Source、Channel和Sink概念。

我们开发了最初的扩展：HttpSource、MemoryChannel，Sink的扩展则由开发者根据业务需求定制。

1）Http Source

DataFlow内置HttpSource实现，它是基于Netty实现的高性能HttpServer。在500线程下（4c8g，cpuload 99%），请求数据大小为1kb，平均TPS达到13w/s。

2）Memory Channel

内存队列，基于Java内置的BlockingQueue实现。使用时需控制队列数量及对象大小，数据量过大时容易造成进程OOM，重启时则数据丢失。

HttpSource采用Netty实现的Http服务以及Memory Channel使用内存队列实现的Channel满足了高性能和高并发的要求，但是Memory Channel在进程重启时，如果数据没有被消费完，则Channel中的数据丢失，这又使得可靠性得不到很好的保证。于是我们有了FileQueue Channel：

3）FileQueue Channel

文件队列，采用基于mmap实现的文件队列的方式 ，保证了数据的本地持久化，进程crash及重启时数据不丢失。但如所在服务器异常关机时，则可能丢失page-cache里面缓存的数据。相比传统的I/O读写，mmap大大提高了读写效率，从而保证了Channel数据传输极高的吞吐量。

特别是在日志采集和调用链采集业务的应用上，FileQueue的Channel扩展，在线上可靠性和吞吐量之间取得了平衡，业务的特殊性可以容忍在极端异常情况下，少量数据的丢失（服务器掉电、异常重启等）。当然mmap也支持强制刷盘的方式，但是读写效率也会因此大打折扣，没有充分利用mmap带来的好处。

随着业务的深入迭代，FileQueueChannel 在大规模使用的同时，Channel与Sink一一对应的模式使得业务不能有更加灵活的扩展。比如日志告警和日志存储，如果都放到一个Sink中处理，使得业务逻辑变得耦合。

实际情况可能更加糟糕：在日志的后端存储异常时，日志告警的数据获取和发送告警依赖与整个Sink的消费，如果后端存储恢复时间在半小时后，那么日志告警发送时间也是半小时后，这对线上依赖日志告警的业务是不可接受的。

针对上述问题，我们针对FileQueueChannel 做了扩展，使得同一份数据，支持多个Sink并行消费，相互拥有独立线程池，互不干扰：

多个Sink维护自己的消费位点，彼此互不干扰。比如ES入库失败或延迟，并不会影响AlarmSink的执行。

比如调用链系统，SDK每次上报的数据量条数不一，数据类型不同，通过数据分类并整形，从Channel消费的数据条数是固定的，大幅提升了数据写入的性能。

SDK上报的消息类型有多种，我们需要对不同的消息分发到不同的通道去处理，比如将DataEvent对象logType Header值等于jvm的消息，路由到xxxChannel。

ESA DataFlow内置SQLite数据库，按分钟维度实时采集7天内的数据，并提供内置简单UI界面，当然DataFlow也提供Prometheus监控接口，方便集成到内部监控系统：

测试数据

ESA DataFlow已广泛应用在调用链采集，日志采集等业务。

典型的采集服务的部署图如下：

以日志采集为例，基于DataFlow实现的类图如下：

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

由上图可知，ESA DataFlow大大降低了开发者开发一个采集系统的难度。

日志采集架构

客户端分LogAppender及agent采集2种方式。客户端采用权重轮询的调度算法，作为负载均策略。如果其中一个节点crash，客户端可以failover到其他节点，以此来保证数据可靠性。

开发者可以通过每个节点的内置控制台来查看统计数据，并以此调整权重策略。

基于ESA DataFlow，开发者能很容易开发出高性能的数据采集服务：它内置的HttpSource、FileQueueChannel等组件，保证其高性能和高吞吐量。而轻量级和简单易学的架构能保证针对业务不同的数据处理需求，可以很容易扩展出不同的插件来满足。而通过内置的WEB界面，可以直观分析和跟踪一周内的数据流量情况。是一个面向开发者而生的轻量级、高性能的数据采集、传输和处理框架。

目前使用ESA DataFlow开发的调用链采集服务日均处理大约千亿以上级别的数据量，集群规模大约在10个节点左右。服务上线后，在稳定性、性能、吞吐等方面均达到了预期的效果。