小米数据流服务整体架构如下图：

数据总线：小米数据流服务使用Talos作为数据总线，使得所有数据均通过Talos进行中转；

Source支持：所有写入的模块均定义为Source，用于将数据实时的写入Talos；

Sink支持：所有从Talos写出的模块定义为Sink，用于将数据实时的从Talos导出；

流式计算：所有数据写入Talos之后，均可以通过Spark Streaming进行流式计算；

在这个架构下，小米数据流服务具备以下特点：

完全兼容Scribe数据流：小米数据流服务完全兼容Scribe数据流服务，并且支持平滑升级；

Source/Sink完全解耦：通过引入数据总线，使得Source与Sink完全解耦，不再相互影响；

Source/Sink易于扩展：支持多种Source/Sink，且定义好接口，非常易于扩展；

全方位数据中转服务：通过Source/Sink模式，系统数据中转的复杂度由（N*N-1）降低为（2N）；

完整的流式计算支持：所有数据均可以通过spark Streaming进行处理，使得流式计算成为标配；

完整的安全认证体制：整个数据流均接入了融合云账号体系，使得数据安全可靠；

完整的数据质量监控：提供整体数据流SLA，用于说明数据丢失情况与数据延迟情况；

完整的服务质量监控：提供整体数据流全链路监控，实时发现数据流异常并出发报警；

全新的用户交互设计：通过全新的中心化配置管理，使得数据流配置转化为界面的点击操作；

完善的服务运维体系：通过引入LCSAgent的自升级机制，实现了LCSAgent全公司统一维护；

交互流程主要为：

1、用户通过Web配置数据流，Web端会将配置持久化到后端存储；

2、Source会定期更新配置，当读取相关配置之后会将数据写入到Talos；

3、Job Scheduler也会定期更新配置，之后会启动spark straming作业用于将数据转储到对应的Sink；

其主要交互流程图如下：

一、流式数据处理

目前小米仍然存在大量的批处理计算，首先将数据收集到HDFS集群，然后通过MapReduce或者Hive进行批量计算，基本如下图所示：

MapReduce是批量计算很容易理解，但是这里将Hive归到批量计算，主要是因为：目前Hdfs的文件，主要是按照天切分和小时切分的方式，即Hive作业统计的最小周期也是1小时，因此将其归为批量计算；

批量计算的问题为延迟太大。对于业务而言，延迟越小越有利于进行决策等，流式计算在越来越多的场景将发挥更大的作用；目前业界流式计算框架，包括Spark Streaming，Storm，Flink，Smaza等，几乎全部依赖Kakfa，或者类Kafka系统：Amazon Kinesis，阿里云 RocketMQ，包括我们团队自研的Talos等系统，作为其输入。因此基于上述描述，期望基于小米数据流服务，让流式计算成为今后各个业务的标配。

所有数据全部转化为流

所有数据均会写到Talos，不管其原始数据为何种格式，也不管原始数据存储平台或者生成方式，全部转化为流的形式，进而可以支持Spark Streaming等流式计算框架；

多样的流式处理数据源

依托于小米数据流服务Source的理念，可以方便的将各种数据：包括业务线上日志，各种数据库更新日志，交易数据等等各种业务有分析需求的数据，全部非常方便的导入到Talos，然后通过Spark Streaming进行流式数据处理。

数据可重放

所有的数据均会在Talos里面缓存24小时（可配置，最长为7天），当业务有新的逻辑更新时，如果逻辑有问题，通过Talos的缓存机制，可以方便的进行重新计算。

二、简化数据交互流程

业务场景

随着业务的不断扩展，对于数据的各种统计需求不断增加，目前小米的业务从最开始使用Hive，到后来的Durid，ELK，Kylin，Spark SQL等，都是为了满足业务的各种增加的统计需求。对于OLAP系统，为了使查询速度得到提升，一般都会对原始数据做各种形式的转换，所以OLAP都会自带存储，或者依赖HDFS等作为其存储。因此为了接入OLAP系统，一般首先要接入其存储。

另外对于一些在线业务，例如订单系统，不仅要实时更新数据库，同时需要将一些行为数据也更新到后端系统进行存储；依赖行为数据可以进行用户行为分析，广告推送，实时推荐等。

上述只是简述了一些有代表性的业务场景，至于深入到各种真实场景，可能更复杂的多，涉及到的系统也会更多，因此数据交互的场景可能会更加复杂。

一般数据交互流程

如上一节所示，真实的的业务数据交互场景可能描述如下：

在这种交互场景下，会遇到如下问题：

系统交互复杂度过高：每两个系统之间都需要进行交互，复杂度为N*N-1；

系统复杂度过高：当涉及的系统过多时，系统架构本身就很复杂，对于开发和维护的代价都很高；

无法重用交互逻辑：各个业务按照自身的需求进行开发，尽管存在通用的部分，没有办法复用；

无法保证高可用：由于涉及的模块太多，所以数据交互质量比较难保证；

无法服务化：一般都是由业务部署交互系统，没有办法抽象并服务化；

小米数据流服务数据交互流程

如上图所示，所有系统均和Talos进行交互，其优势如下：

简化系统交互复杂度：各个系统只和Talos进行交互，因此复杂度为2*M，当接入新的系统时也非常方便；

简化系统设计：所有的数据中转均基于小米数据流服务，之前系统交互的逻辑转发为小米数据流服务的一些配置，简单方便快捷，易于维护和扩展；

服务化：小米数据流服务以服务化的形式展现给用户，实现了各个模块的一次开发，全部业务通用；

高可用性：小米数据流服务提供数据质量监控和服务质量监控等两个维度的监控，提升整理数据流的高可用性；

数据中转平台

针对业务繁多的数据中转的需求，小米数据流服务最主要的目标就是要做完整的数据中转平台，让各种数据按照业务的需求在各种系统之间流转起来，为业务提供最高的便捷性，同时保证高可用，高可靠性。依赖于小米数据流服务，业务各种复杂的需求都可以非常快捷的搭建起来，而不需要关注背后的各种细节，把业务彻底解放出来，专注于自身更核心的逻辑，提高整个公司的效率。

三、全方位Schema支持

对于各种形式的数据，如果想对其进行利用，必须要理解其数据格式。但是在Scribe数据流之中，目前只有Xlogger和Hive两个首尾的地方有schema，这就造成无法很好的理解数据并使用数据。后续我们会开发SchemeRegistry服务，为接入小米数据流服务的各个数据流提供全方位的Schema支持，并在数据流的各个环节进行数据格式校验。目前此服务准备接入中，敬请大家期待。

你更期望小米数据流服务后期解决哪些问题

欢迎留言

后期技术文章更新，长按下方二维码关注☟