Go在大数据开发中的经验总结

1 .Go在⼤大数据开发中的实战经验 七⽜牛云 — 孙健波 

2 .简单 · 可信赖 ⾃自我介绍 Pandora • 孙健波 • 七⽜牛云 • ⼤大数据开发⾼高级⼯工程师 • 《Docker容器器与容器器云》主要作者 

3 .简单 · 可信赖 七⽜牛在⼤大数据⽅方⾯面做了了 什什么？ ⼀一站式⼤大数据服务平台 ——Pandora 

4 .简单 · 可信赖 成熟⽽而复杂的⼤大数据⽣生态 හഝ‫ݢ‬ᥤ۸ .LEDQD හഝ༄ᔱ‫ړ‬ຉ ଘ‫ݣ‬ ᵞᗭ᧣ଶ <DUQ =RR ṛ NHH ‫ݢ‬ ਂ‫ؙ‬ၾ௳ᴚ‫ڜ‬ .DIND +')6 SHU አ හഝතᵞᓕ᭲ /RJVWDVK 7HOHJUDI )OXPH ፊഴ 

5 .简单 · 可信赖 Pandora是什什么？ 

6 .简单 · 可信赖 pandora的理理念 1.收集 6.冷冻 2.加⼯工 • 将多样的⼤大数据⼯工具整合 • 将复杂的⼤大数据管理理简化 数据的⽣生命周期 • 构建完整的⼤大数据⽣生命周期闭环 5.消费 3.分析 4.管理理 

7 . 本地⽇日志/kafka/HDFS/mysql... WEB loT 简单 · 可信赖 云存储 LogKit SDK 开放API 消息队列列 导出 Mongo 任务 清洗 计算任务 消息队列列 HTTP 计算任务 聚合 计算任务 筛选 Pandora产品架构 导出任务 ··· 消息队列列 消息队列列 json gzip Parquet 导出任务 导出任务 ORC Mysql Report Studio 时序数据库 ⽇日志检索服务 对象存储服务 HDFS Grafna/开放API Kibana/开放API ··· XSpark 

8 .简单 · 可信赖 Pandora的系统架构 /RJ Transf *UDIDQD Export 76'% orm ୏න$3, 6'. Transf .LEDQD Export /RJ'% orm ୏න$3, ԯਂ‫ؙ‬ Transf :(% Pipeline Export Parquet ;VSDUN orm ORC Transf Text gzip Xspark ,R7 Export orm Transf Export ԯਂ‫ؙ‬ orm 

9 .简单 · 可信赖 Pandora的组件结构 ORJNDINDKGIVP\VTOŏ :(%$33,R7 ԯਂ‫ؙ‬ /RJNLW 6'. ୏න$3, Points Gate .DIND &OXVWHUV Kafka Kafka Kafka Spark Streaming Spark Streaming Spark Streaming Mongodb ([SRUW &OXVWHUV Export Export Export Http TSDB LOGDB KODO … Grafana / ୏නAPI Kibana / ୏නAPI ԯਂ‫ ؙ‬/ හഝՙପ XSPARK ᐶᕚ‫ړ‬ຉ Report Studio 

10 .简单 · 可信赖 Pandora的数据量量级 每天上百TB、2000+亿条 实时数据增量量 TSDB LogDB KODO HTTP… 

11 . 海海量量数据的实时导出会 简单 · 可信赖 有哪些问题？ ⽤用户数据 pipeline Lag(延迟)！ export export export TSDB LOGDB KODO HTTP… 本质：数据流动的效率问题 

12 .简单 · 可信赖 数据传输模型 PULL ：数据已经在数据源(kafka/hdfs)之上，去拉取即可 优点：吞吐量量由服务端控制，游刃有余 缺点：需要⽤用户有数据源 =>为⽤用户再准备⼀一个数据源Kafka/HDFS PUSH：作为⼀一个server端接受打过来的数据 优点：⽤用户打过来数据即可 作为⼀一个rest服务 我们别⽆无选择 缺点：吞吐量量受⽤用户打数据的姿势影响 

13 .简单 · 可信赖 数据传输的常⻅见神话 1. 导出的上游数据产量量是稳定不不变(变化缓慢)的 2. 导出的下游服务永远是稳定可⽤用 链路路损耗严重！ 3. 导出的速度仅受限于上下游中的⼀一⽅方影响 • 单向吞吐量量 = 请求⼤大⼩小*并发数 • 整体吞吐量量 = f(拉取吞吐量量,链路路承载能⼒力力,推送吞吐量量) • 举例例：流量量20k/s = 上游10k/s*2+下游5k/s*2 ? ⽹网络抽⻛风？下游响应慢？⽹网卡打满？内存超限？ 

14 .简单 · 可信赖 可以想到的思路路… ✤ 上下游解耦：拉取与推送解耦，数据预取、队列列暂存、拉取与发送并⾏行行 ✤ 任务分割：⼤大任务分解成⼩小任务，⼩小任务⽔水平扩展 ✤ 任务标准化：每个任务承载固定的流量量，流量量增加则增加任务数量量 ✤ 提升资源利利⽤用率：调度、平衡，压榨机器器性能 ✤ 提供任务管理理能⼒力力：运维、运营、监控 ✤ 更更懂下游 ⽬目标：降lag！ 

15 . 简单 · 可信赖 数据导出、格式转换、过滤 精细化调度管理理 轻量量级分布式goroutine ⾼高可⽤用保证 pipeline … export export 构建加速系统 加速！ 加速！ 加速！ TSDB LOGDB KODO HTTP 

16 .简单 · 可信赖 选型 ✤ 上下游解耦？ ✤ 任务分割？ ✤ ⽔水平扩展？ • logstash？ ✤ 任务标准化？ ✤ 提升资源利利⽤用率？ ✤ 提供任务管理理能⼒力力？ • beat？ ✤ 更更懂下游？！ • flume？ • ⾃自研？ 

17 .简单 · 可信赖 flume 

18 .简单 · 可信赖 ⾃自研 ✤ 上下游解耦？ + buffer? channel? ✤ 任务分割？ + process? ✤ ⽔水平扩展？ +分布式 + thread? ✤ 任务标准化？ + goroutine? ✤ 提升资源利利⽤用率？ + 调度 +admin ✤ 提供任务管理理能⼒力力？ ✤ 更更懂下游？！ + 让下游⾃自⼰己写 😜 + 易易学易易⽤用 + 社区活跃(⼩小轮⼦子多) + 部署迭代简便便 + ⾼高效 + 稳定 + ⾼高性能 + 并发编程 + 七⽜牛技术栈 = 选择golang！ 

19 .简单 · 可信赖 核⼼心模型 

20 .简单 · 可信赖 sink 以及⾃自定义sink 插件形式的下游适配器器 没有⼈人⽐比下游⾃自⼰己更更懂下游 

21 .简单 · 可信赖 快速响应与反压 • 只要放到channel⾥里里就返回200 ok，否则就返回503失败 

22 .简单 · 可信赖 磁盘队列列 

23 .简单 · 可信赖 借助export数据重播 重播 重播 [offset, export export 加速！ 故障！ 加速！ [offset,check] [offset, [offset,check] [offset,check] [offset, [offset,check] [offset,check] [offset, [offset,check] 

24 .简单 · 可信赖 transaction资源池 init/ new task • 进：数据进channel前，通过transaction(事务) 保证资 stopped 源，若有空间则进,否则返回503。 restore启动 正常启动 restore • 出：数据出channel后，通过transaction(事务) 保证数 据完整，若sink不不成功，则将数据回滚回channel。 restore完毕 running 本地保存 关闭信号 • 关停：停⽌止下游sink，启动磁盘sink，下游sink数据回 滚⾄至channel，再通过磁盘sink流⼊入本地磁盘保存。 interrupt 关闭信号 • 启动：先从本地磁盘流⼊入数据⾄至channel 回到主线 stopping • 制定task状态机完成整个过程 task状态机 

25 .简单 · 可信赖 架构图 • agent可以理理解为 scheduler，负责任务的 创建分配 get/create task rest-api restart workflow transaction transaction • 本地磁盘队列列解决重启 put queue put queue task agent appid 的容错问题 transaction reponame put queue local memory queue file • 主程序就是⼀一个内存队 queue 列列，⼊入队出队都通过 transaction transaction transaction transaction sink send queue send queue send queue send queue transaction解决 checkpoint • transaction是⼀一个共享 logdb tsdb kodo sink 的事务池，包含锁和 channel 

26 .简单 · 可信赖 单机模型核⼼心总结 • ⼀一个repo⼀一个单独的task，不不同repo间task不不共享。 • ⼀一个task包含⼀一个MQ，多个sink、⼀一个磁盘队列列。 • 根据mongo的配置决定sink的数量量(与capacity相同) • MQ中包含transaction池，每次sink，通过事务控制数据 进出MQ保证原⼦子性。 • 重启的过程也以sink的形式，只不不过发送端变为磁盘，保 证了了服务升级时内存数据不不丢失。 

27 .简单 · 可信赖 分布式 还有什什么困难？ 维护困难，如果我的集群要添加或者减少⼀一个producer节点，该怎么办？ 数据分散，所有的数据都有可能经过任意producer节点，对应每个producer发往下 游的数据分散，导致每个请求的可能聚集的数据量量⼩小，batchsize⼩小。 资源浪费，每个producer都要维护⼤大量量的task，对应⼤大量量的goroutine，浪费CPU和 内存。 负载不不均，若是纯粹的随机，或者轮询，⼀一旦遇到机器器配置不不同或者服务混部等情 况，负载⽆无法均衡。 不不易易管理理，新的业务需要启动对应的producer task，需要改变配置等，都⽆无法操 作。 

28 . 简单 · 可信赖 分布式—⼀一致性问题 如何保证数据的⼀一致性，让协作数据传递到⼀一致地传递到每⼀一个producer？ • zookeeper/etcd • ⾃自研分布式算法 • 最终⼀一致性 => pull系统+版本戳 

29 .简单 · 可信赖 七⽜牛⼆二级缓存系统—qconf qconf master qconf master memcached memcached local cache mongo producer producer producer apiserver apiserver 基于键值对⼆二级缓存的框架，保证最终⼀一致性