文件接口抽象能很好的处理流式的连续数据么？

首先，假设我们用文件和文件系统来做一个流存储。把传感器、用户日志、用户输入这些数据注入一个文件中，貌似并没有什么问题。但是被写入文件的数据必须被持续不断的读取出来。也就是说，持续不断被写入文件的数据，必须不停的被读取出来用以处理，这是文件接口和针对连续数据流处理最根本的区别。

其次，当数据量变大的时候，并发是必须的。我们当然可以利用多个文件实现并发写，但这也意味着读端的应用程序必须追踪多文件读。为增加并发而带来的多文件读取的协调和追踪并没有包含在文件接口的抽象里，所以这对读应用程序来说，并不是透明的。

第三，如果进一步考虑动态扩展呢？动态扩展意味着在程序读取的过程中再动态生成新的文件或者合并已有文件以适应新的并发度。在这种情况下，读端应用程序需要自己监测在读文件的新增和减少，这是除应用程序本身业务逻辑之外额外的工作。

第四，数据是连续无边界的，需要一种标记来记录当前数据的读取位置。横跨多个文件去设计逻辑上全局一致的位置点，进一步增加了应用程序的复杂性。

第五，IOT 场景往往需要维护针对同一设备号的数据序列。如果把设备数据当作文件，把设备号当作 key，那么注入端需要 key 到文件的映射处理并维护在同一 key 命名空间下的per-key order 。同时，读取端还得做到多文件读取的负载均衡。这些都是文件和文件系统抽象不能完成，所有的工作都推向了上层应用程序。

第六，对于流处理来说，数据的清除往往是从流数据的头开始删除，先写入的先删。文件接口抽象并不能很好的处理这点。

近些年来，业界其实是广泛应用了一个中间解决方案，通过 messaging 系统（比如ka）+文件系统的混合抽象方案注入。这解决了部分问题，比如说动态扩展、注入端的并行问题。但是这不是一个完整的端到端解决方案。实时流计算是走了 messaging 接口规避了文件接口的一些问题，但是针对历史数据的批处理还是需要文件接口，这实际上是针对同一数据的两种系统。

所以，对于连续的流式数据的存储层抽象，我们需要的既不是原来的基于传统数据库的实现，也不是基于 messaging 系统的转化，而是从头设计一个完整的流存储系统。

以上内容摘自《开源大数据前瞻与应用实战》电子书，点击https://developer.aliyun.com/topic/download?id=1153可下载完成版