【硬刚大数据】Flink在实时在实时计算平台和实时数仓中的企业级应用小结

本文主要是介绍【硬刚大数据】Flink在实时在实时计算平台和实时数仓中的企业级应用小结,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

  欢迎关注博客主页:https://blog.csdn.net/u013411339
欢迎点赞、收藏、留言 ,欢迎留言交流!
本文由【王知无】原创,首发于 CSDN博客!
本文首发CSDN论坛,未经过官方和本人允许,严禁转载!

本文是对《【硬刚大数据之学习路线篇】从零到大数据专家的学习指南(全面升级版)》的面试部分补充。

大数据领域自 2010 年开始,以 Hadoop、Hive 为代表的离线计算开始进入各大公司的视野。大数据领域开始了如火如荼的发展。我个人在学校期间就开始关注大数据领域的技术迭代和更新,并且有幸在毕业后成为大数据领域的开发者。

在过去的这几年时间里,以 Storm、Spark、Flink 为代表的实时计算技术接踵而至。2019 年阿里巴巴内部 Flink 正式开源。整个实时计算领域风起云涌,一些普通的开发者因为业务需要或者个人兴趣开始接触Flink。

Apache Flink(以下简称 Flink)一改过去实时计算领域为人诟病的缺陷,以其强大的计算能力和先进的设计理念,迅速成为实时计算领域先进生产力的代表。各大小公司纷纷开始在 Flink 的应用上进行探索,其中最引人瞩目的两个方向便是:实时计算平台和实时数据仓库。

Flink 实时计算

如果你是一位大数据领域的开发人员或者你是一名后端的开发者,那么你对下面这些需求场景应该不会陌生:

我是抖音主播,我想看带货销售情况的排行?我是运营,我想看到我们公司销售商品的 TOP10?我是开发,我想看到我们公司所有生产环境中服务器的运行情况?...... 

在 Hadoop 时代,我们通常的做法是将数据批量存储到 HDFS 中,在用 Hive 产出离线的报表。或者我们使用类似 ClickHouse 或者 PostgreSQL 这样的数据库存储生产数据,用 SQL 直接进行汇总查看。

那么这样的方式有什么问题呢?

第一种,基于 Hive 的离线报表形式。大部分公司随着业务场景的不断丰富,同时在业界经过多年的实践检验,基于 Hadoop 的离线存储体系已经足够成熟。但是离线计算天然时效性不强,一般都是隔天级别的滞后,业务数据随着实践的推移,本身的价值就会逐渐减少。越来越多的场景需要使用实时计算,在这种背景下实时计算平台的需求应运而生。

第二种,基于 ClickHouse 或者 PostgreSQL 直接进行汇总查询。这种情况在一些小规模的公司使用非常常见,原因只有一个就是数据量不够大。在我们常用的具有 OLAP 特性的数据库的使用过程中,如果在一定的数据量下直接用复杂的 SQL 查询,一条复杂的 SQL 足以引起数据库的剧烈抖动,甚至直接宕机,对生产环境产生毁灭性的影响。这种查询在大公司是坚决不能进行的操作。

因此基于 Flink 强大实时计算能力消费实时数据的需求便应运而生。在实时数据平台中,Flink 会承担实时数据的采集、计算和发送到下游。

Flink 实时数据仓库

数据仓库最初是指的我们存储的 Hive 中的表的集合。按照业务需求一般会分为原始层、明细层、汇总层、业务层。各个公司根据实际业务需要会有更为细致的划分。

传统的离线数据仓库的做法一般是将数据按天离线集中存储后,按照固定的计算逻辑进行数据的清洗、转换和加载。最终在根据业务需求进行报表产出或者提供给其他的应用使用。我们很明显的可以看到,数据在这中间有了至少 T+1 天的延迟,数据的时效性大打折扣。

这时,实时数据仓库应运而生。一个典型的实时数据仓库架构图如下:

图片

技术选型

这一部分作者结合自身在阿里巴巴这样的公司生产环境中的技术选择和实际应用的中一些经验,来讲解实时计算平台和实时数据仓库的各个部分是如何进行技术选型的。

实时计算引擎

我们在上面提到,实时计算解决的最重要的问题就是实时性和稳定性。

实时计算对数据有非常高的稳定性和精确性要求,特别是面向公众第三方的数据大屏,同时要求高吞吐、低延迟、极高的稳定性和绝对零误差。随时电商大促的成交记录一次次被刷新,背后是下单、支付、发货高达几万甚至十几万的峰值 QPS。

你可以想象这样的场景吗?天猫双十一,万众瞩目下的实时成交金额大屏突然卡住没有反应。我估计所有开发人员都要被开除了…

我们以一个最常见和经典的实时计算大屏幕来举例。

在面向实际运营的数据大屏中,需要提供高达几十种维度的数据,每秒的数据量高达千万甚至亿级别,这对于我们的实时计算架构提出了相当高的要求。那么我们的大屏背后的实时处理在这种数据量规模如何才能达到高吞吐、低延迟、极高的稳定性和绝对零误差的呢?

图片

在上图的架构图中,涉及几个关键的技术选型,我们下面一一进行讲解。

业务库 Binlog 同步利器 - Canal

我们的实时计算架构一般是基于业务数据进行的,但无论是实时计算大屏还是常规的数据分析报表,都不能影响业务的正常进行,所以这里需要引入消息中间件或增量同步框架 Canal。

我们生产环境中的业务数据绝大多数都是基于 MySQL 的,所以需要一个能够实时监控 MySQL 业务数据变化的工具。Canal 是阿里巴巴开源的数据库 Binlog 日志解析框架,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费。

图片

Canal 的原理也非常简单,它会伪装成一个数据库的从库,来读取 Binlog 并进行解析。Canal 在阿里巴巴内部有大规模的应用,因为阿里有众多的业务是跨机房部署,大量业务需要进行业务同步,Canal 功能强大,性能也很稳定。

解耦和海量数据支持 - Kafka

在实时大屏的技术架构下,我们的数据源绝大多数情况下都是消息。我们需要一个强大的消息中间件来支撑高达几十万 QPS,同时支持海量数据存储。

首先,我们为什么需要引入消息中间件?主要是下面三个目的:

  • 同步变异步

  • 应用解耦

  • 流量削峰

在我们的架构中,为了和业务数据互相隔离,需要使用消息中间件进行解耦从而互不影响。另外在双十一等大促场景下,交易峰值通常出现在某一个时间段,这个时间段系统压力陡增,数据量暴涨,消息中间件还起到了削峰的作用。

为什么选择 Kafka?

Kafka 是最初由 Linkedin 公司开发,是一个分布式、高吞吐、多分区的消息中间件。Kafka 经过长时间的迭代和实践检验,因为其独特的优点已经成为目前主流的分布式消息引擎,经常被用作企业的消息总线、实时数据存储等。

Kafka 从众多的消息中间件中脱颖而出,主要是因为高吞吐、低延迟的特点;另外基于 Kafka 的生态越来越完善,各个实时处理框架包括 Flink 在消息处理上都会优先进行支持。并且 Flink 和 Kafka 结合可以实现端到端精确一次语义的原理。

Kafka 作为大数据生态系统中已经必不可少的一员,主要的特性如下所示。

  • 高吞吐:

    可以满足每秒百万级别消息的生产和消费,并且可以通过横向扩展,保证数据处理能力可以得到线性扩展。

  • 低延迟:

    以时间复杂度为 O(1) 的方式提供消息持久化能力,即使对 TB 级以上数据也能保证常数时间复杂度的访问性能。

  • 高容错:

    Kafka 允许集群的节点出现失败。

  • 可靠性:

    消息可以根据策略进行磁盘的持久化,并且读写效率都很高。

  • 生态丰富:

    Kafka 周边生态极其丰富,与各个实时处理框架结合紧密。

实时计算服务 - Flink

Flink 在当前的架构中主要承担了消息消费、维表关联、消息发送等。在实时计算领域,Flink 的优势主要包括:

  • 强大的状态管理

    Flink 使用 State 存储中间状态和结果,并且有强大的容错能力;

  • 非常丰富的 API

    Flink 提供了包含 DataSet API、DataStream API、Flink SQL 等等强大的API&

这篇关于【硬刚大数据】Flink在实时在实时计算平台和实时数仓中的企业级应用小结的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1142805

相关文章

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因?

视频智能分析/视频监控/安防监控综合管理系统EasyCVR视频汇聚融合平台,是TSINGSEE青犀视频垂直深耕音视频流媒体技术、AI智能技术领域的杰出成果。该平台以其强大的视频处理、汇聚与融合能力,在构建全栈视频监控系统中展现出了独特的优势。视频监控管理系统EasyCVR平台内置了强大的视频解码、转码、压缩等技术,能够处理多种视频流格式,并以多种格式(RTMP、RTSP、HTTP-FLV、WebS

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

中文分词jieba库的使用与实景应用(一)

知识星球:https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义: 精确模式(默认模式): 全模式: 搜索引擎模式: paddle 模式(基于深度学习的分词模式): 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

csu 1446 Problem J Modified LCS (扩展欧几里得算法的简单应用)

这是一道扩展欧几里得算法的简单应用题,这题是在湖南多校训练赛中队友ac的一道题,在比赛之后请教了队友,然后自己把它a掉 这也是自己独自做扩展欧几里得算法的题目 题意:把题意转变下就变成了:求d1*x - d2*y = f2 - f1的解,很明显用exgcd来解 下面介绍一下exgcd的一些知识点:求ax + by = c的解 一、首先求ax + by = gcd(a,b)的解 这个