4 qq_36039236

尚未进行身份认证

我要认证

暂无相关简介

等级
TA的排名 18w+

一套 SQL 搞定数据仓库?Flink 有了新尝试

导读:数据仓库是公司数据发展到一定规模后必然需要提供的一种基础服务,也是“数据智能”建设的基础环节。迅速获取数据反馈不仅有利于改善产品及用户体验,更有利于公司的科学决策,因此获取数据的实时性尤为重要。目前企业的数仓建设大多是离线一套,实时一套。业务要求低延时的使用实时数仓;业务复杂的使用离线数仓。架构十分复杂,需要使用很多系统和计算框架,这就要求企业储备多方面的人才,导致人才成本较高,且出了问题难以排查,终端用户也需要熟悉多种语法。本文分析目前的数仓架构,探索离线和实时数仓是否能放在一起考虑,探索 Fli

2020-09-18 15:01:21

一文搞懂 Flink (内部) 的 Exactly Once 和 At Least Once

看完本文,你能 get 到以下知识介绍 CheckPoint 如何保障 Flink 任务的高可用CheckPoint 中的状态简介如何实现全域一致的分布式快照?什么是 barrier?什么是 barrier 对齐?证明了:为什么 barrier 对齐就是 Exactly Once?为什么 barrier 不对齐就是 At Least Once?Flink简介有状态函数和运算符在各个元素/事件的处理中存储数据(状态数据可以修改和查询,可以自己维护,根据自己的业务场景,保存历史数据或者中间结

2020-09-17 18:45:56

Spark Streaming保证Exactly-Once语义

在流计算引擎如Apache Storm、Apache Kafka(Kafka Streams)、Apache Spark(Spark Streaming、Spark Structured Streaming)、Apache Flink中,经常提到Exactly-Once语义,那Exactly-Once究竟是啥意思?当流计算引擎声称Exactly-Once时,究竟意味着啥?Spark Streaming如何保证Exactly-Once?关于此,自己有时也百思不得其解,查阅了众多资料,咨询了众多大佬,将自己理

2020-09-17 14:27:26

深入理解Flink --- End-to-End(端到端) Exactly-Once语义(两阶段提交)

Flink内部的Exactly-Once语义是基于Asynchronous Barrier Snapshotting(ABS)实现的.那么Flink和外部系统(如Kafka)之间的消息传递如何做到exactly once呢?问题所在:如上图,当sink A已经往Kafka写入了数据,而sink B fail。根据Flink的exactly once保证,系统会回滚到最近的checkpoint,但是sink A已经把数据写入到kafka了。Flink无法回滚kafka的state,因此,kafka

2020-09-17 11:47:07

flink维表关联系列之自定义异步查询

在异步IO查询外部存储时,对于提供异步查询的客户端来说可以直接使用,但是对于没有提供异步查询的客户端应该怎么做呢?我们可以将查询请求丢到一个线程池中,将这个线程池看做是一个异步的客户端来帮助我们完成查询请求。通过线程池方式来帮助我们完成异步请求关键在于线程池的core大小如何设置,如果设置过大,会导致创建很多个线程,势必会造成CPU的压力比较大,由于大多数情况下集群是没有做CPU隔离策略的,就会影响到其他任务;如果设置过小,在处理的速度跟不上就会导致任务阻塞。可以做一个粗略的估算:假如任务中单个Task需

2020-09-16 16:32:36

flink维表关联系列之kafka维表关联:广播方式

Flink中广播状态假设存在这样一种场景,一个是用户行为数据,一个是规则数据,要求通过规则去匹配用户行为找到符合规则的用户,并且规则是可以实时变更的,在用户行为匹配中也能根据规则的实时变更作出相应的调整。这个时候就可以使用广播状态,将用户行为数据看做是一个流userActionStream,规则数据也看做是一个流ruleStream,将ruleStream流中数据下发到userActionStream流中,使得在userActionStream流中每一个Task都能获取到ruleStream流中所有数据,

2020-09-16 16:27:05

flink维表关联系列之Redis维表关联:实时查询

在做维表关联如果要求低延时,即维表数据的变更能够被立刻感知到,所以就要求在查询时没有缓存策略,直接查询数据库维表信息。本篇以实时查询redis为例,要求redis 客户端支持异步查询,可以使用io.lettuce包,支持redis不同模式:单点模式、sentinel模式、集群模式,需要在pom中引入:<dependency> <groupId>io.lettuce</groupId> <artifactId>lettuce-core</artif

2020-09-16 15:43:57

flink维表关联系列之Hbase维表关联:LRU策略

LRULRU(Least Recently Used),最近最少使用缓存淘汰算法,认为最近访问过的数据在将来被访问的概率也比较大,当内存达到上限去淘汰那些最近访问较少的数据。在Flink中做维表关联时,如果维表的数据比较大,无法一次性全部加载到内存中,而在业务上也允许一定数据的延时,那么就可以使用LRU策略加载维表数据。但是如果一条维表数据一直都被缓存命中,这条数据永远都不会被淘汰,这时维表的数据已经发生改变,那么将会在很长时间或者永远都无法更新这条改变,所以需要设置缓存超时时间TTL,当缓存时间超过t

2020-09-16 15:35:51

flink维表关联系列之Mysql维表关联:全量加载

在维表关联中定时全量加载是针对维表数据量较少并且业务对维表数据变化的敏感程度较低的情况下可采取的一种策略,对于这种方案使用有几点需要注意:全量加载有可能会比较耗时,所以必须是一个异步加载过程内存维表数据需要被流表数据关联读取、也需要被定时重新加载,这两个过程是不同线程执行,为了尽可能保证数据一致性,可使用原子引用变量包装内存维表数据对象,即AtomicReference查内存维表数据非异步io过程具体实例:广告流量统计,广告流量数据包含:广告位id,用户设备id,事件类型(点击、浏览),发生时间

2020-09-16 15:18:55

flink维表关联系列之维表服务与Flink异步IO

一、维表服务维度或者是维表概念熟知应该是从数据仓库维度建模开始了解的,区别于事实表业务真实发生的数据,通常用来表示业务属性,比如订单业务中,商品属性、商家属性都可以称之为维度表。在flink 流处理实时分析中或者实时数仓中,同样需要使用维表来完成一些数据过滤或者字段补齐操作,但是我们所需要的维度数据通常存储在Mysql/Redis/Hbase/Es这样的外部数据库中,并且可能是会随时变动的,根据业务要求数据的时效性,需要不同程度的感知维表数据的变化,在实际使用中常常会有以下几种方案可供选择:在维度数据

2020-09-16 14:37:55

Flink task之间的数据交换

Flink中的数据交换是围绕着下面的原则设计的:数据交换的控制流(即,为了启动交换而传递的消息)是由接收者发起的,就像原始的MapReduce一样。用于数据交换的数据流,即通过电缆的实际数据传输,被抽象为了IntermediateResult,并且是可插拔的。 这意味着系统可以使用同一实现同时支持流数据传输和批处理数据传输。数据交换也涉及到了一些角色,包括:JobManager,master节点,负责任务调度,异常恢复,任务协调,并且通过ExecutionGraph这样的数据结构来保存一个作业

2020-09-16 10:46:38

Spark Streaming VS Flink

本文从编程模型、任务调度、时间机制、Kafka 动态分区的感知、容错及处理语义、背压等几个方面对比 Spark Stream 与 Flink,希望对有实时处理需求业务的企业端用户在框架选型有所启发。本文篇幅较长,建议先收藏~目录```/ 运行模型对比 / ``````生态``````运行模型``````/ 编程模型对比 / ``````Spark Streaming``````Flink``````/ 任务调度原理 / ``````Spark 任务调度``````Flink 任务调度``````/ 时间

2020-09-15 16:50:18

Hive脚本: Unable to close file because the last block does not have enough number of replicas 报错分析

一、问题跑spark或hive脚本报错如下:[INFO] 2020-03-31 11:06:03 -> java.io.IOException: Unable to close file because the last block does not have enough number of replicas. at org.apache.hadoop.hdfs.DFSOutputStream.completeFile(DFSOutputStream.java:2266) at org

2020-09-14 16:45:05

spark算子reducebykey和groupbykey的对比

目录一、场景二、源码解读结论一、场景reducebykey和groupbykey作为经常使用的算子,都会触发shuffle操作。reducebykey返回的 k-v 的tuple的rddgroupbykey返回的 k-iterable 的tuple的rdd二、源码解读这两个方法的底层都调用了combineByKeyWithClassTag这个方法groupbykey 调用:/** * Group the values for each key in the RDD into a s

2020-09-14 15:41:05

count(distinct) 与 group by 再 count 的区别

在传统关系型数据库中,group by与count(distinct)都是很常见的操作。count(distinct colA)就是将colA中所有出现过的不同值取出来,相信只要接触过数据库的同学都能明白什么意思。count(distinct colA)的操作也可以用group by的方式完成,具体代码如下:select count(distinct colA) from table1;select count(1) from (select colA from table1 group by col

2020-09-14 11:05:43

Flink 故障恢复机制

目录故障恢复自动故障恢复是 Flink 提供的一个强大的功能,在实际运行环境中,我们会遇到各种各样的问题从而导致应用挂掉,比如我们经常遇到的非法数据、网络抖动等。Flink 提供了强大的可配置故障恢复和重启策略来进行自动恢复。故障恢复在flink的配置文件flink-conf.yml 中,其中有一个参数 jobmanager.execution.failover-strategy: region。Flink 支持了不同级别的故障恢复策略,jobmanager.execution.failover-

2020-09-11 11:03:33

Flink SQL 数据sink到mysql时,非空列存在null值问题

flink sql 数据sink到mysql时,非空存在null值,插入mysql报错,配置下面的参数进行解决:table.exec.sink.not-null-enforcer对表的NOT NULL列约束强制执行不能将空值插入到表中。Flink支持“错误”(默认)和“删除”强制行为默认情况下,当将空值写入NOT NULL列时,Flink将检查值并引发运行时异常。用户可以将行为更改为“删除”,以在不引发异常的情况下静默删除此类记录。...

2020-09-10 14:48:52

Flink重启策略

目录Flink重启策略1. 固定延迟重启策略2. 故障率重启策略3. 无重启策略4. 后备重启策略Flink重启策略Flink支持不同的重启策略,可以控制在发生故障时如何重启新启动作业。默认重启策略是通过Flink的配置文件设置的flink-conf.yaml。配置参数restart-strategy定义采用的策略。如果未启用检查点,则使用“无重启”策略。如果激活了检查点并且尚未配置重启策略,则固定延迟策略将用于 Integer.MAX_VALUE重启尝试。重启策略分为:固定延迟重启策略、故障率重

2020-09-10 14:31:25

Mysql权限问题: Access denied; you need (at least one of) the RELOAD privilege(s) for this operation

场景是使用某个mysql用户访问mysql的binlog, 出现这个问题的原因是当前用户没有reload权限导致的。1、reload 是 administrative 级的权限,即 server administration;这类权限包括: CREATE USER, PROCESS, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHUTDOWN, SUPER2、这类权限的授权不是针对某个数据库的,因此须使用o

2020-09-10 14:19:19

Hive 内置集合函数

目录size(Map[K,V])size(Array[V])map_keys(Map[K.V])map_values(Map[K.V])array_contains(Array[T], value)sort_array(Array[T])小结size(Map[K,V])解释返回 Map 类型中的元素数。使用案例select size(map类型参数); -- 返回map中的元素个数size(Array[V])解释返回 Array 类型中的元素数。使用案例selec

2020-09-09 10:49:42

查看更多

勋章 我的勋章
  • 持之以恒
    持之以恒
    授予每个自然月内发布4篇或4篇以上原创或翻译IT博文的用户。不积跬步无以至千里,不积小流无以成江海,程序人生的精彩需要坚持不懈地积累!
  • 勤写标兵Lv4
    勤写标兵Lv4
    授予每个自然周发布9篇以上(包括9篇)原创IT博文的用户。本勋章将于次周周三上午根据用户上周的博文发布情况由系统自动颁发。