前言
数据流（
Data Stream）是ElasticSearch7.9之后提出来的一个新概念，可以用于帮助我们更好的管理日志类的索引。不过个人在使用后觉得体验感还有待提升，所以就写篇文章总结一下可能会遇到的问题。
正如前文所说，ElasticSearch在7.9版本之后引入了数据流这个概念：数据流让你在多个索引中存储仅有附加的时间序列数据，同时给你一个单一的命名资源来进行请求。数据流非常适用于日志、事件、指标和其他连续产生的数据。你可以直接向数据流提交索引和搜索请求。数据流会自动将请求路由到存储数据流的备份索引。你可以使用索引生命周期管理（ILM）来自动管理这些支持索引。
从功能特性中我们可以得知，数据流天然适合于日志类型的索引，但是！！！如果本身索引就已经实现indexName-yyyy-mm-dd的日期格式的话，就没有必要再改为数据流这种格式了。甚至可能会适得其反，没有利用上数据流的特性。因为数据流的存在本身就是为了方便整合不同日期下的所有日志，帮助我们手动实现索引的管理，现在由于索引名本身会发生变化，就导致这个特性“失效”了。
比较好的实践就是，我们直接指定某个日志文件作为数据源文件，那么创建索引模板和数据流之后，会自动根据日志的打印日期进行索引的滚动切分，这一步不需要人为参与！ES底层就会实现好日期的划分
我们在创建索引模板的时候会发现有个选项是是否创建数据流，默认是不勾选的。不过笔者发现如果在创建索引模板之前就通过filebeat创建了索引模板，那么此时就会自动生成对应的索引模板以及数据流，而一旦匹配到数据流，且本身索引命名有日期的话就会造成数据流重复命名。所以这里
同时，数据流本身适用于不断累加的日志索引，但我们知道索引的大小是会不断变大的，无论怎么切分，最后还是会占用磁盘资源，在没有索引全量备份需要的前提下，一般来说我们都是需要手动删除某个时间点之前的所有日志索引，但问题在于ES官方推出这个特性就不太希望我们对数据流以及里面的数据进行修改和删除（虽然提供了相关的api），这就对我们ES索引运维造成了一定的难度。
所以感觉对于日志类的索引，如果非必要，目前还是在创建索引时使用日期进行分隔会好一些。如果确实要用数据流的话，可以看kibana上面的索引生命周期是否支持配置删除策略，有个比较坑的地方是部分版本的kibana只支持配置热阶段、温阶段和冷阶段的配置，里面没有删除阶段的配置，如果kibana支持的话，我们倒是可以利用这个特性来满足索引的自动删除，方便我们及时清理磁盘空间
参考文章
Elastic：深入了解数据流Data Stream https://juejin.cn/post/7089411359741313031
