如何解决银行日志分析系统中实时性的问题？

实时性高？

1. 存储硬件资源跟上
2. 带宽够
3. Agent发送给力
4. 数据入库迅速
5. 搜索能力强劲

硬件资源不用说了，io肯定不能差，至于要不要求虚拟另说。
很多人忘记Agent收集日志也是需要消耗时间的，尤其是生成的小文件很多、目录很多（银行很常见），agent 采集往往就是实时性的一大杀手。

另外在数据入库层，不管是ES，solr还是其他企业版，这个必须要快。如果说用ES来搞，那么我可以保证说他不是实时性的。ES 是 NRT, 而不是RT。

如何解决实时性，说白了还是要舍得花钱。舍得买硬件资源，舍得买软件。（开发能力强悍的银行可以忽略）

在日志分析系统中实时性是一个难点问题，比如实时任务1分钟只能处理30秒采集的数据，那么产出的数据的延时会越来越长，不能代表当前时刻的业务状态，有可能导致业务方做出错误的运营决策。在互联网行业中，需要处理的数据是海量的，如何在数据量快速膨胀的情况下也能保持高吞吐量和低延时，是当前面临的重要挑战。因此， 实时处理的性能优化占了任务开发的很大一部分工作。

我们所有的日志分析策略都是常驻任务，区别于离线任务的周期调度，流式任务属于常驻进程任务， 一旦启动后就会一直运行，直到人为地终止，因此计算成本会相对比较高。这一特点也预示着流式任务的数据源是无界的，而离线任务的数据源是有界的。这也是实时处理和离线处理最主要的差别，这个特性会导致实时任务在数据处理上有一定的局限性。如何来解决实时性的问题呢？ 我们采取了两个策略，一是进行了索引区分和消费优先级的区分，将重要日志数据的优先级提高，这样这部分重要的数据会较不重要的数据先进入数据存储模块，这样这部分数据的实时性就有了保障其次在存储时也将重要数据进行单独命名和创建索引，这样在计算时就会减少大范围的搜索和计算；二是进行冷热数据分别存储，重要数据所存放的位置为闪存盘，不重要的数据存放在SATA盘上，这样在不耗费大量金钱的同时保证了磁盘的读写，保障了实时性。