流数据分析技术笔记2 实时流架构设计

Posted 2021-06-28 Lora青蛙

文章目录

• • 1 实时框架的组件
  • 2 实时架构的特性
  • 3 实时编程语言
  • 4 实时架构概览

1 实时框架的组件

离线计算和实时计算的区别：
离线计算基于已经存在的数据进行计算，一般流程：Sqoop采集数据到HDFS，MapReduce处理HDFS上的数据，将结果写回HDFS
实时计算关注数据实时性，处理的是每时每刻产生的数据，一般流程：Flume采集数据，Kafka缓存，Storm进行实时计算，结果存入Redis中，通过echarts等可视化呈现

数据采集
数据采集通过建立在TCP/IP网络上的连接来进行，通常使用HTTP通用协议。网站是大规模数据采集最早用例，web服务器所使用的日志格式为日志文件格式答的主流（公共日志格式、扩展日志文件格式、javascript对象表示法格式、结构化有限格式等）
数据采集平台：Apache Flume、Fluentd、Logstash、Chukwa、Scibe、Splunk Forwarder

数据流程
第0代数据流程系统：紧耦合的专用通信系统，用来将应用分解为特定应用层。
第1代数据流程系统：解除了第0代系统的耦合，通常使用某种日志文件系统来采集特定应用的数据，将其放入文件中。
第2代数据流程系统：认识到可靠传输并不总是优先目标，因此开始为系统间的数据移动实现远程过程调用（RPC）系统。
第3代数据流程系统：兼顾了第1代日志模型的可靠性和第2代PRC模型的高速度。这类系统中，用于数据的生产者和消费者的数据层都有一个实时接口，数据以分散的消息进行交付。第3代数据流程系统的最新成员Kafka和Flume应运而生。它们在很大程度上摒弃了排序语义，同时仍然保留了分布式系统和可靠性保证的概念。

数据存储
实时流数据存储选择“NoSql”主要原因是：性能优先，而不是传统关系型数据库所要求的ACID（原子性、一致性、隔离性、持久性）优先。

数据交付
Web通信方法、Web渲染方法

2 实时架构的特性

高可用性
确保高可用性的方法：分布化（多个物理服务器将负载分散到多个端点）和复制（基本思想：系统不是将单份数据都写到单独一台机器中，而是写到多台机器中，寄希望于至少其中一条能够在故障中幸存）

低延迟
实时流应用低延迟指的不是单个请求的完成时间，而是事件在系统“边缘”某个地方发生的实践，与事件可以由处理和交付框架处理的时间，这两者的时间差。各种事件的延迟之间的差别是非常稳定的。
系统的数据采集组件大多考虑低延迟的第一个定义。一台服务器所能处理的连接越多， 需要用来处理负载的服务器就越少。
数据流程和处理组件更关注低延迟的第二个定义。减小事件到达处理组件与可以提供给消费者之间的时间差。

水平可扩展性
指的是：向处理特定问题的服务器集群加入更多的物理独立的服务器来提高性能。

3 实时编程语言

4 实时架构概览

数据采集：许多情况下，对于数据采集并没有其他选择。边缘服务器是业已存在的系统，我们的目标是对服务器进行改进，或者将其与实时框架集成起来。
数据流程：如果要集成已有系统，那就应该选择Flume，如果要对系统加以改进，或者从头开始创建新系统，那就很难找到理由不用Kafka。
数据处理：尽管Samza显示出了巨大潜力，可惜的是，对于多数首次尝试实时处理系统的人来说，它还是不够成熟，对于初次使用的用户来说，Storm是更合适的框架。
数据存储：对于相对小规模的项目，例如概念验证或只有很小流量的应用，Redis是数据存储的显而易见的最佳选择，如果需要存储的是海量的非频繁访问的数据，Cassandra是很好的选择，只有在要存储的数据有丰富的结构时（如地理数据流），MongoDB才是真正的首选。
数据交付：几乎所有应用的交付迟早都会以Web应用的形式出现，至少在第一次迭代时是这样，最好的方式是实现支持SSE的应用程序编程接口（API），由Web应用和本地应用使用。