【技术er圣诞创意大赏】基于Flink的实时数据平台

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
实时计算 Flink 版,1000CU*H 3个月
云数据库 RDS PostgreSQL,高可用系列 2核4GB
简介: 【技术er圣诞创意大赏】基于Flink的实时数据平台

一、前言

迪拜是否过圣诞节日,迪拜信基督教的人过圣诞,其他一般不过。

圣诞节(Christmas)又称耶诞节、耶稣诞辰,译名为“基督弥撒”,是西方传统节日,起源于基督教,在每年公历12月25日。弥撒是教会的一种礼拜仪式。圣诞节是一个宗教节,因为把它当作耶稣的诞辰来庆祝,故名“耶诞节”。

大部分的天主教教堂都会先在12月24日的平安夜,亦即12月25日凌晨举行子夜弥撒,而一些基督教会则会举行报佳音,然后在12月25日庆祝圣诞节;基督教的另一大分支——东正教的圣诞节庆则在每年的1月7日。

圣诞节也是西方世界以及其他很多地区的公共假日,例如:在亚洲的中国香港和澳门地区、马来西亚、新加坡。古罗马教会在君士坦丁时代(公元年),就逐渐习惯在十二月二十五日庆祝主的诞生。

二、创意名

基于Flink的数据实时展示平台

三、效果展示

四、实现步骤

Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据集RDD进行批量处理,是一种伪实时。

而Flink是基于事件驱动的,它是一个面向流的处理框架,Flink基于每个事件一行一行地流式处理,是真正的流式计算.另外他也可以基于流来模拟批进行计算实现批处理,所以他在技术上具有更好的扩展性,未来可能会成为一个统一的大数据处理引擎。

因为他们技术理念的不同,也就导致了性能相关的指标的差别,spark是基于微批的,而且流水线优化做的很好,所以说他的吞入量是最大的,但是付出了延迟的代价,它的延迟是秒级;而Flink是基于事件的,消息逐条处理,而且他的容错机制很轻量级,所以他能在兼顾高吞吐量的同时又有很低的延迟,它的延迟能够达到毫秒级;

SparkStreaming只支持处理时间,折中地使用processingtime来近似地实现eventtime相关的业务。显然,使用processingtime模拟eventtime必然会产生一些误差,特别是在产生数据堆积的时候,误差则更明显,甚至导致计算结果不可用。

Structuredstreaming支持处理时间和事件时间,同时支持watermark机制处理滞后数据

Flink支持三种时间机制:事件时间,注入时间,处理时间,同时支持watermark机制处理迟到的数据,说明Flink在处理乱序大实时数据的时候,优势比较大。

其实和Kafka结合的区别还是跟他们的设计理念有关,SparkStreaming是基于微批处理的,所以他采用DirectDstream的方式根据计算出的每个partition要取数据的Offset范围,拉取一批数据形成Rdd进行批量处理,而且该Rdd和kafka的分区是一一对应的;

Flink是真正的流处理,他是基于事件触发机制进行处理,在KafkaConsumer拉取一批数据以后,Flink将其经过处理之后变成,逐个Record发送的事件触发式的流处理。另外,Flink支持动态发现新增topic或者新增partition,而SparkStreaming和0.8版本的kafka结合是不支持的,后来跟0.10版本的kafka结合的时候,支持了,看了源码;

五、编码实现

server:
  port: 8080
#  port: ${server.port}
spring:
  #数据源
  datasource:
    username: root
    password: 123456
    url: jdbc:mysql://192.168.1.100:3306/datax_web?serverTimezone=Asia/Shanghai&useLegacyDatetimeCode=false&useSSL=false&nullNamePatternMatchesAll=true&useUnicode=true&characterEncoding=UTF-8
#    password: ${DB_PASSWORD:password}
#    username: ${DB_USERNAME:username}
#    url: jdbc:mysql://${DB_HOST:127.0.0.1}:${DB_PORT:3306}/${DB_DATABASE:dataxweb}?serverTimezone=Asia/Shanghai&useLegacyDatetimeCode=false&useSSL=false&nullNamePatternMatchesAll=true&useUnicode=true&characterEncoding=UTF-8
    driver-class-name: com.mysql.jdbc.Driver
    hikari:
      ## 最小空闲连接数量
      minimum-idle: 5
      ## 空闲连接存活最大时间,默认600000(10分钟)
      idle-timeout: 180000
      ## 连接池最大连接数,默认是10
      maximum-pool-size: 10
      ## 数据库连接超时时间,默认30秒,即30000
      connection-timeout: 30000
      connection-test-query: SELECT 1
      ##此属性控制池中连接的最长生命周期,值0表示无限生命周期,默认1800000即30分钟
      max-lifetime: 1800000
  # datax-web email
  mail:
    host: smtp.qq.com
    port: 25
    username: gree2@qq.com
    password: xxxxxxxx
#    username: ${mail.username}
#    password: ${mail.password}
    properties:
      mail:
        smtp:
          auth: true
          starttls:
            enable: true
            required: true
        socketFactory:
          class: javax.net.ssl.SSLSocketFactory
management:
  health:
    mail:
      enabled: false
  server:
    servlet:
      context-path: /actuator
mybatis-plus:
  # mapper.xml文件扫描
  mapper-locations: classpath*:/mybatis-mapper/*Mapper.xml
  # 实体扫描,多个package用逗号或者分号分隔
  #typeAliasesPackage: com.yibo.essyncclient.*.entity
  global-config:
    # 数据库相关配置
    db-config:
      # 主键类型  AUTO:"数据库ID自增", INPUT:"用户输入ID", ID_WORKER:"全局唯一ID (数字类型唯一ID)", UUID:"全局唯一ID UUID";
      id-type: AUTO
      # 字段策略 IGNORED:"忽略判断",NOT_NULL:"非 NULL 判断"),NOT_EMPTY:"非空判断"
      field-strategy: NOT_NULL
      # 驼峰下划线转换
      column-underline: true
      # 逻辑删除
      logic-delete-value: 0
      logic-not-delete-value: 1
      # 数据库类型
      db-type: mysql
    banner: false
  # mybatis原生配置
  configuration:
    map-underscore-to-camel-case: true
    cache-enabled: false
    call-setters-on-nulls: true
    jdbc-type-for-null: 'null'
    type-handlers-package: com.wugui.datax.admin.core.handler
# 配置mybatis-plus打印sql日志
logging:
  level:
    com.wugui.datax.admin.mapper: info
    path: ./data/applogs/admin
#  level:
#    com.wugui.datax.admin.mapper: error
#    path: ${data.path}/applogs/admin
#datax-job, access token
datax:
  job:
    accessToken:
    #i18n (default empty as chinese, "en" as english)
    i18n:
    ## triggerpool max size
    triggerpool:
      fast:
        max: 200
      slow:
        max: 100
      ### log retention days
    logretentiondays: 30
datasource:
  aes:
    key: AD42F6697B035B75


目录
相关文章
|
5月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
在数字化转型中,企业亟需从海量数据中快速提取价值并转化为业务增长动力。5月15日19:00-21:00,阿里云三位技术专家将讲解Kafka与Flink的强强联合方案,帮助企业零门槛构建分布式实时分析平台。此组合广泛应用于实时风控、用户行为追踪等场景,具备高吞吐、弹性扩缩容及亚秒级响应优势。直播适合初学者、开发者和数据工程师,参与还有机会领取定制好礼!扫描海报二维码或点击链接预约直播:[https://developer.aliyun.com/live/255088](https://developer.aliyun.com/live/255088)
348 35
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
|
5月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
173 11
|
6月前
|
存储 分布式计算 调度
Flink Shuffle 技术演进之路
本文由阿里云智能Flink团队郭伟杰与哔哩哔哩蒋晓峰在Flink Forward Asia 2024上的分享整理而成,聚焦Flink Shuffle技术的演进与未来规划。内容涵盖低延迟的Pipelined Shuffle、高吞吐的Blocking Shuffle、流批一体的Hybrid Shuffle三大模式及其应用场景,并探讨了Flink与Apache Celeborn的整合、性能优化及长期发展路线图。通过Hybrid Shuffle等创新技术,Flink实现了资源调度灵活性与高性能的平衡,为流批一体化计算提供了强大支持。未来,社区将进一步优化Shuffle机制,提升系统智能化与易用性。
330 14
Flink Shuffle 技术演进之路
|
8月前
|
SQL 消息中间件 Kafka
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
本文介绍了阿里云实时数仓Hologres负责人姜伟华在Flink Forward Asia 2024上的分享,涵盖实时数仓的发展历程、从实时数仓到实时湖仓的演进,以及总结。文章通过三代实时数仓架构的演变,详细解析了Lambda架构、Kafka实时数仓分层+OLAP、Hologres实时数仓分层复用等方案,并探讨了未来从实时数仓到实时湖仓的演进方向。最后,结合实际案例和Demo展示了Hologres + Flink + Paimon在实时湖仓中的应用,帮助用户根据业务需求选择合适的方案。
1202 20
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
|
8月前
|
SQL 存储 HIVE
鹰角基于 Flink + Paimon + Trino 构建湖仓一体化平台实践项目
本文整理自鹰角网络大数据开发工程师朱正军在Flink Forward Asia 2024上的分享,主要涵盖四个方面:鹰角数据平台架构、数据湖选型、湖仓一体建设及未来展望。文章详细介绍了鹰角如何构建基于Paimon的数据湖,解决了Hudi入湖的痛点,并通过Trino引擎和Ranger权限管理实现高效的数据查询与管控。此外,还探讨了湖仓一体平台的落地效果及未来技术发展方向,包括Trino与Paimon的集成增强、StarRocks的应用以及Paimon全面替换Hive的计划。
714 1
鹰角基于 Flink + Paimon + Trino 构建湖仓一体化平台实践项目
|
7月前
|
SQL 消息中间件 Serverless
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
180 4
|
7月前
|
SQL 存储 HIVE
鹰角基于 Flink + Paimon + Trino 构建湖仓一体化平台实践项目
鹰角基于 Flink + Paimon + Trino 构建湖仓一体化平台实践项目
402 2
|
消息中间件 资源调度 API
Apache Flink 流批融合技术介绍
本文源自阿里云高级研发工程师周云峰在Apache Asia Community OverCode 2024的分享,内容涵盖从“流批一体”到“流批融合”的演进、技术解决方案及社区进展。流批一体已在API、算子和引擎层面实现统一,但用户仍需手动配置作业模式。流批融合旨在通过动态调整优化策略,自动适应不同场景需求。文章详细介绍了如何通过量化指标(如isProcessingBacklog和isInsertOnly)实现这一目标,并展示了针对不同场景的具体优化措施。此外,还概述了社区当前进展及未来规划,包括将优化方案推向Flink社区、动态调整算子流程结构等。
744 31
Apache Flink 流批融合技术介绍
|
12月前
|
消息中间件 分布式计算 Kafka
大数据平台的毕业设计02:Spark与实时计算
大数据平台的毕业设计02:Spark与实时计算
241 0
|
Cloud Native 安全 调度
Flink 新一代流计算和容错问题之Flink 通过云原生技术改进容错设计要如何操作
Flink 新一代流计算和容错问题之Flink 通过云原生技术改进容错设计要如何操作
107 2

热门文章

最新文章