为什么要重新设计架构

• 部分节点存在隐患，
  比如数据传输节点 Dumper，
  已属于无法维护的状态

• 部分节点冗余，存在资源浪费。

• 集群机器不够统一，容易出现一些不可预料的问题

• 集群环境太过老旧，享受不到技术进步带来的优势

• 一些业务分析已经达到瓶颈，无法进一步扩展

  • 数据太多，磁盘容量不够
  • 维度分析太多，计算量无法支持
  • 计算资源紧张等

架构分层

数据收集

不丢数据
高可用
方便接入

数据清洗

实时
高效

数据建仓

数据分析

数据展示

• flume为什么要对接kafka？
  另外一种方式就是 flume直接对接HDFS。
  主要是为了实时数据考虑
  flume是一个消息管道，
  其数据流入之后，
  一旦被消费，这个数据就会被删除，
  也就是说他只能有一个消费者，
  而kafka不一样，可以支持多个消费者，
  比如实时数据可以拿一批，离线数据还可以拿一批

为什么要flume

• 简单易用
  通过简单的配置就能完成数据的收集，
• 适用广
  其本身已经提供了对目前大多数的场景的数据收集配置
  即使没有，也可以通过简单的接口完成自定义收集和落地
• 高可用
  提供HA架构，对于宕机具有比较好的容错能力
• 高可靠
  能保证数据的完整性，不会造成数据丢失
• 可扩展性
  收集的数据源可以自由增加和删减
  高度解耦。
• 功能也比较丰富
  消息头的设计
  拦截器

为什么用Kafka

主要作用当然是削峰填谷，做一个缓冲作用
解耦

• 高吞吐量、低延迟：
  kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；

• 可扩展性：
  kafka集群支持热扩展；

• 持久性、可靠性：
  消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；

• 容错性：
  允许集群中节点故障（若副本数量为n,则允许n-1个节点故障）；

• 高并发：
  支持数千个客户端同时读写。

• 多个消费者

Spark 和 Flink的对比

• Flink比起Spark性能略好
• flink是真的流式计算，而Spark只能做微批处理
• 对于Hadoop生态圈都有比较好的支持
• Spark对于SQL支持更友好，
• Spark针对SQL有更好的优化
• Spark社区更活跃，但是国内Flink有ali的大力支持

根据目前的情况看起来，国内普遍对于flink比较看好，
从实际情况来看，flink也是以后的发展方向，
但是目前Spark的活跃程度远高于Flink，
很难说Spark以后的底层不会也才有flink这种方式，

目前建议 离线用Spark，
实时的话可以 尝试flink

目前熟悉Spark，对Flink不太熟悉

为什么要用Kylin

• Kylin产生的背景
  eBay公司为了实现Bi平台和Hadoop平台的无缝整合，并能在大规模数据集上实现秒级的查询而提出的最终解决方案，即 OLAP on Hadoop.从而诞生了kylin这个框架

• Kylin解决的问题
  在大数据领域，自Hadoop诞生以来，存储和计算都得到了妥善的解决，
  其用到的主要技术主要是 并行计算 和 列式存储。
  这些技术虽然大大提高了计算速度，但是查询时间还是会和数据的增加成线性增长
  这离实时分析的要求还相差甚远
  而kylin就是用来解决这一问题，
  其通过预计算的方式来使得我们平时查询的数据可以达到秒级响应

• kylin的特点

  • 标准的SQL接口
  • 支持超大规模的数据集
  • 亚秒级的响应
  • Bi平台以及可视化工具的集成

• 我们为什么要用

  • 一些业务多维度分析确实遇到了瓶颈
  • 可以弥补公司确实OLAP的空白
  • 可以作为一个数据自助查询的平台

Spark1.6 和 2.x的不同

• 性能方面
  相比于Spark 1.0，Spark 2.0在引擎性能方面有重大优化，
  其优化主要体现在Spark Core和Spark SQL两个系统上，
  其优化主要得益于Tungsten计划(“钨丝计划”)，
  其主要动机是优化Spark内存和CPU的使用，
  使其能够逼近物理机器的性能极限。
  利用“整阶段代码生成”(“whole stage code generation”)，
  使得SQL和DataFrame中算子性能优化2-10倍
  通过“向量化计算”提升Parquet格式文件的扫描吞吐率
  提升ORC格式文件的读写性能
  提升Catalyst查询优化器性能

• 统一DataFrame与Dataset
  API众所周知，在Spark 1.x中，DataFrame API存在很多问题，
  包括 不是类型安全的(not type-safe)，
  缺乏函数式编程能力(not object-oriented)等，
  为了克服这些问题，社区引入了Dataset，
  相比于DataFrame，它具有以下几个特点：
  类型安全，面向对象编程方式;支持非结构化数据(json);
  java与scala统一接口和性能极好的序列化框架等，
  她将成为Spark未来主流的编程接口(RDD API是low-level API，
  而Dataset则是high-level API)。

• SQL支持进一步完善

• 引入了Struct streaming

过程

• 架构分享

1. 为什么要升级
2. 新的架构设计概览
3. 各个框架概览

• 架构技术细化
  针对架构确定的技术框架进行科普，
  以及测试资源的确定。
  最后确定并开始部署测试环境

• 各个框架的评估
  最终方案的确定

大数据架构设计.png