【活动】杭州GDG 开源搜索和海量数据处理沙龙活动总结

zooboa

活动主题：搜索和海量数据处理沙龙
活动时间：2014年8月23日 14:00-17:00
活动地点：西湖区通普路 贝塔咖啡活动人数：40余人
活动照片链接：https://plus.google.com/events/gallery/cpslheteuhe93fd5fpjiahbvp3s

活动概述
此次沙龙是针对开源的大数据搜索引擎elasticsearch如何来构建每日处理TB级以上的海量数据处理平台技术交流，话题涉及到分布式搜索的技术架构，同等量级的MQ选型、优化经验交流，现场参加人员根据现实案例中每日数TB级的实时日志处理所遇到的性能瓶颈展开激烈的分析和问题探讨，大胆设想各抒己见，现场氛围异常活跃。

参加活动的嘉宾主要有：
来自阿里的ODPS数据平台运维组、CDN平台运维组 以及SLS日志平台组核心开发人员和BIGLog创业团队、杭州GDG该领域兴趣成员，浙大研究数据挖掘领域的学生等40余人

活动流程和总结
1、Zooboa为此次活动做开场白，详细介绍了杭州GDG的背景、现状以及往届活动的主题范围，让大家了解到GDG组织能给到大家带来的学习交流机会的多样性，并邀请大家加入和继续关注杭州GDG。

2、随后zooboa对elasticsearch、logstash、kibana架构和应用的场景做了介绍，并引出现实案例中所碰到的问题，从架构的合理性、性能的监测、MQ选型等方面分析，让大家参与讨论：

David Pan、HongHui Ding等热心成员总结了很多经验，在他们的生产场景下，大量日志数据通过UDP传输始终会保持1%的数据丢失率，但是如果采用TCP传输，虽然能够保证完整性，但又会增大网络延迟和资源的消耗，应该根据用户对数据的重要性而选择可接受的数据传输方式。

另外Redis在遇到数据输入大于输出的情况下，很快就导致内存耗光而崩溃，正常的应用环境下，应该让Redis保持0缓冲，只有当后端出现问题时，才让Redis发挥缓冲池的作用。而在固定单一来源和单一消费者的场景下，不建议使用Redis等MQ，这样反而增加了故障点。

在处理海量日志数据时，网络传输的延迟，传输的数据未进行压缩，以及使用短连接极易导致数据丢失，应该在集群的每个节点内，部署性能监测探针，监控出瓶颈产生的根源，这样才能对症下药。评估资源消耗后，尽可能让集群中每一个机器都充分发挥计算资源，这需要在架构上做出适当的调整。

3、活动结束时，大家互留联系方式方便以后继续就相关问题交流学习。