HadoopSpark在七牛数据平台的实战20150730.docVIP

昨日，七牛数据平台工程师就七牛内部使用的数据平台，深入分享了该团队在Flume、Kafka、Spark以及Streaming上的实践经验，并讲解了各个工具使用的注意点。 分享人介绍：王团结， 七牛数据平台工程师，主要负责数据平台的设计研发工作。关注大数据处理，高性能系统服务，关注Hadoop、Flume、Kafka、Spark等离线、分布式计算技术。 下为讨论实录 数据平台在大部分公司属于支撑性平台，做的不好立刻会被吐槽，这点和运维部门很像。所以在技术选型上优先考虑现成的工具，快速出成果，没必要去担心有技术负担。早期，我们走过弯路，认为没多少工作量，收集存储和计算都自己研发，发现是吃力不讨好。去年上半年开始，我们全面拥抱开源工具，搭建自己的数据平台。 数据平台设计架构 公司的主要数据来源是散落在各个业务服务器上的半结构化的日志(系统日志、程序日志、访问日志、审计日志等)。大家有没考虑过为什么需要日志？日志是最原始的数据记录，如果不是日志，肯定会有信息上的丢失。说个简单的例子，需求是统计nginx上每个域名的的流量，这个完全可以通过一个简单的nginx模块去完成，但是当我们需要统计不同来源的流量时就法做了。所以需要原始的完整的日志。 有种手法是业务程序把日志通过网络直接发送出去，这并不可取，因为网络和接收端并不完全可靠，当出问题时会对业务造成影响或者日志丢失。对业务侵入最小最自然的方式是把日志落到本地硬盘上。 Agent设计需求 每台机器上会有一个agent去同步这些日志，这是个典型的队列模型，业务进程在不断的push，agent在不停的pop。agent需要有记忆功能，用来保存同步的位置(offset)，这样才尽可能保证数据准确性，但不可能做到完全准确。由于发送数据和保存offset是两个动作，不具有事务性，不可避免的会出现数据不一致性情况，通常是发送成功后保存offset，那么在agent异常退出或机器断电时可能会造成多余的数据。 agent需要足够轻，这主要体现在运维和逻辑两个方面。agent在每台 机器上都会部署，运维成本、接入成本是需要考虑的。agent不应该有解析日 志、过滤、统计等动作，这些逻辑应该给数据消费者。倘若agent有较多的逻 辑，那它是不可完成的，不可避免的经常会有升级变更动作。 数据收集流程 数据收集这块的技术选择，agent 是用go自己研发的，消息中间件kafka，数据传输工具flume。说到数据收集经常有人拿flume和kafka做比较，我看来这两者定位是不同的，flume更倾向于数据传输本身，kakfa是典型的消息中间件用于解耦生产者消费者。 具体架构上，agent并没把数据直接发送到kafka，在kafka前面有层由flume构成的forward。这样做有两个原因 1. kafka的api对非jvm系的语言支持很不友好，forward对外提供更加通用的http接口 2. forward层可以做路由、kafka topic和kafka partition key等逻辑，进一步减少agent端的逻辑 forward层不含状态，完全可以做到水平扩展，不用担心成为瓶颈。 出于高可用考虑，forward通常不止一个实例，这会带来日志顺序问题，agent 按一定规则(round-robin、failover等)来选择forward实例，即使kafka partition key一样，由于forward层的存在，最终落入kafka的数据顺序和 agent发送的顺序可能会不一样。我们对乱序是容忍的，因为产生日志的业务 基本是分布式的，保证单台机器的日志顺序意义不大。如果业务对顺序性有要 求，那得把数据直接发到kafka，并选择好partition key，kafka只能保证 partition级的顺序性。 跨机房收集要点 多机房的情形，通过上述流程，先把数据汇到本地机房kafka 集群，然后汇聚到核心机房的kafka，最终供消费者使用。由于kafka的mirror对网络不友好，这里我们选择更加的简单的flume去完成跨机房的数据传送。 flume在不同的数据源传输数据还是比较灵活的，但有几个点需要注意 1. memory-channel效率高但可能有丢数据的风险，file-channel安全性高但性能不高。我们是用memory-channel，但把capacity设置的足够小，使内存中的数据尽可能少，在意外重启和断电时丢的数据很少。个人比较排斥file-channel，效率是一方面，另一个是对flume的期望是数据传输，引入file-channel时，它的角色会向存储转变，这在整个流程中是不合适的。通常flume的sink端是kafka和hdfs这种可用性和扩张性比较好的系统，不用担心数据拥堵问题。