为什么要重新设计架构

  • 部分节点存在隐患,
    比如数据传输节点 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

相关文章:

  • 2022-12-23
  • 2021-07-17
  • 2021-09-17
  • 2022-01-06
  • 2021-05-18
  • 2021-12-25
  • 2021-08-27
  • 2022-12-23
猜你喜欢
  • 2021-09-07
  • 2021-06-21
  • 2022-01-05
  • 2021-07-12
  • 2022-01-10
  • 2021-08-21
  • 2022-12-23
相关资源
相似解决方案