2018Elastic Meetup南京交流会，由华泰证券李文强带来以“华泰证券Elasticsearch应用实践”为题的演讲。本文首先介绍了华泰证券具有系统运维繁琐、日志不能长期保存、日志数据价值没有挖掘、大数据领的一角的特点。接着介绍了它在日志搜索、日志分析和链路管理系统方面的应用实践。最后介绍了华泰证券Elasticsearch在使用中应注意的事项。
阿里云Elasticsearch 1核2G首月免费试用，开始云上实践吧
直播视频回顾
以下内容根据现场分享整理而成。
建设背景及现状
背景
在过去，华泰证券具有系统运维繁琐、日志不能长期保存、日志数据价值没有挖掘、大数据领的一角的四个特点。所谓的系统运维繁琐是指系统多、独立建设、服务产生大量日志、运维时需要登陆服务器才能查看日志等，遇到复杂问题时需要一台台地登陆服务器搜索相关日志文件才能定位问题。日志没有长期保存是指根据证券行业相关的法律法规，日志数需要保存一定年限并支持随时调取。日志数据价值没有挖掘是指日志中包含非常有价值的信息，但并没有深入挖掘。大数据领域的一角是指Hadoop主要面向的是结构化数据的存储和分析，而不是非结构化数据的存储和分析。
现状
- 2016年6月，华泰证券开始建设Elasticsearch集群，由于机房通过专线进行联网，当数据量太大时机房会被占用，所以机房不一样会导致需要许多个集群，因此集群需要单独建设。
- Elasticsearch建设容量为120T，每天数据量会占用 600G甚至800G的空间，由于Elasticsearch容量比较小，所以日志保存时间非常短，有些只能保存两个月甚至几个星期，只有非常重要的信息才能保存三个月。在未来计划将Elasticsearch容量进行扩展，预期日志保存时间能够达到一年甚至两年以上。
- 华泰证券支持的应用包括支撑涨乐、理财平台、监控数据分析、日志分析等。例如理财平台，Elasticsearch能够发现用户的行为，并给出用户建议方案。
展望未来，中国证券市场已发生根本性转变，现在正面临着历史性的发展机遇。面对新的形势，华泰证券将继续坚持规范化、集团化、国际化发展战略，进一步加快公司做大做强步伐，力争尽快使公司成为具有核心竞争力的、业务规模和综合实力进入行业前列的证券控股集团。
应用实践
日志搜索
在日志搜索中，日志源是整个ES上的第一部分，跟ELK的采集与展示基本一致，它主要分为日志采集模块、采集代理、日志存储模块、日志检索模型、前台展示模块、采集管理模块。
其中，日志采集模块又分为采集代理和日志处理两部分。采集处理主要用来做数据的缓存，日志处理是把日志消费成两份，一份消费进入到ES，另一份消费日志进行实时报警。日志检索模块是对日志进行展示，它主要有三个功能，即统一的日志检索、实时监控报警、统一权限管理功能。
日志分析
数据源不仅包括日志，还包括网页和数据库。数据源通过morphling将数据采集放置三个库中，三个库包含ES、HDFS和Hbase。ES最终进行日志检索，HDFS和Hbase最终通过Hve和Kylin进行展现。
链路管理系统
在链路管理系统中，由数据质量分析、统一采集框架、自动化部署、应用监控构成一个内循环系统。
- 对于数据质量的分析而言，用户要求数据一条不能多一条不能少，但在实际上对于分支系统来讲，由于链路比较长，所以几乎是不可能实现数据不多不失的。但是链路管理系统可以做到的是去辅助链路发现是否有质量问题，并在这个系统里及时对数据质量进行分析。
例如，一个节点发送1000万条数据，通过链路管理最终进入到ES。在这个过程中可能会出现数据延迟的现象，若发送的曲线和对应发送的最终曲线一致，那么就说明数据质量是完好的，即最终数据是一致的。若两条曲线不能拟合，那就说明有数据已丢失。 - 对于统一采集框架而言，即在采集的日志文件中对日志进行标准化，比如，日志应该包含什么等等。
- 自动化部署即对部署过程的每一个步骤自动化，目前部署过程涉及到应用、环境和部署流程等。要实现自动化首先要做的是将需要部署的应用、环境和流程进行建模，并需要一个自动化部署系统来支撑。
- 应用监控，即每天巡检只需要通过应用监控系统就能够知道每个链路上的节点是否正常，如果异常则会报警。
使用经验
华泰证券Elasticsearch的使用有六点注意事项。第一，磁盘目录不易过多，建议做Raid5，便于管理；第二，索引分片根据实际需求分配；第三，冷热分离策略；第四，根据业务特点进行集群部署，通过TrieNode连接；第五，元数据不易过多，过多会导致集群性能降低，触发BUG；第六，设置节点离开时的分片延迟分配策略。
其中，对于磁盘目录不易过多问题而言，需采取官网建议，即采取裸盘。由于单台机器有24块盘，长期运行当某些分片都落在某个磁盘上时，会造成单盘的读写热点问题，且这些分片的数据量较大时，这个磁盘的空间很容易爆满，ES也不会进行数据均衡，一旦磁盘超过阈值，整个节点都不会再分配分片，造成空间利用率不足的情况。可以通过新购机器的磁盘做Raid5和统一管理来解决这个问题，这样既不会出现某一块盘爆满，还能提升整体I/O吞吐，将老机器逐渐替换。
Jstat发现Master持续GC时，CPU使用率会非常高。可能存在有内存泄露问题，这就需要把Jmap内存dump出来分析，接着进一步分析漏点，最后修改源码并验证。
对于使用经验中的第六点， 集群运行很久后，集群分片就会越来越多，元数据就会多，当集群分片个数超过1.5万时，性能将出现问题，运行一段时间后集群运行不正常，节点就会无法连接Master。
在集群实际运转过程中，往往会出现节点由于网络或GC等原因从集群中离开、日常运维时节点下线的情况。集群为避免数据丢失，必须保证每个分片都有足够的副本，所以会产生大量的网络I/O，而这时如果节点重新加入集群，Elasticsearch会为该节点再次分配数据分片，这将再次导致大量的网络I/O操作。在这种情况下，集群长期处于Yellow状态，恢复非常缓慢，通过监控可看到分片处于迁移状态。这就需要通过设置参数index.unassigned.nod_left.delayed_timeout来延迟分片平衡的时间，为运维和节点异常恢复提供缓冲时间。
