生而为人

程序员的自我修养

0%

Posted on In

consumer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
21/09/08 02:39:19 INFO ConsumerConfig [Executor task launch worker for task 2322]: ConsumerConfig values: 
	auto.commit.interval.ms = 5000
	auto.offset.reset = none
	bootstrap.servers = [msnsam-prod.servicebus.windows.net:9093]
	check.crcs = true
	client.dns.lookup = default
	client.id = 
	connections.max.idle.ms = 540000
	default.api.timeout.ms = 60000
	enable.auto.commit = false
	exclude.internal.topics = true
	fetch.max.bytes = 52428800
	fetch.max.wait.ms = 500
	fetch.min.bytes = 1
	group.id = spark-kafka-source-babd462a-415a-413a-aeea-e55435fff762-448121830-executor
	heartbeat.interval.ms = 3000
	interceptor.classes = []
	internal.leave.group.on.close = true
	isolation.level = read_uncommitted
	key.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer
	max.partition.fetch.bytes = 1048576
	max.poll.interval.ms = 300000
	max.poll.records = 500
	metadata.max.age.ms = 300000
	metric.reporters = []
	metrics.num.samples = 2
	metrics.recording.level = INFO
	metrics.sample.window.ms = 30000
	partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor]
	receive.buffer.bytes = 65536
	reconnect.backoff.max.ms = 1000
	reconnect.backoff.ms = 50
	request.timeout.ms = 30000
	retry.backoff.ms = 100
	sasl.client.callback.handler.class = null
	sasl.jaas.config = [hidden]
	sasl.kerberos.kinit.cmd = /usr/bin/kinit
	sasl.kerberos.min.time.before.relogin = 60000
	sasl.kerberos.service.name = null
	sasl.kerberos.ticket.renew.jitter = 0.05
	sasl.kerberos.ticket.renew.window.factor = 0.8
	sasl.login.callback.handler.class = null
	sasl.login.class = null
	sasl.login.refresh.buffer.seconds = 300
	sasl.login.refresh.min.period.seconds = 60
	sasl.login.refresh.window.factor = 0.8
	sasl.login.refresh.window.jitter = 0.05
	sasl.mechanism = PLAIN
	security.protocol = SASL_SSL
	send.buffer.bytes = 131072
	session.timeout.ms = 10000
	ssl.cipher.suites = null
	ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
	ssl.endpoint.identification.algorithm = https
	ssl.key.password = null
	ssl.keymanager.algorithm = SunX509
	ssl.keystore.location = null
	ssl.keystore.password = null
	ssl.keystore.type = JKS
	ssl.protocol = TLS
	ssl.provider = null
	ssl.secure.random.implementation = null
	ssl.trustmanager.algorithm = PKIX
	ssl.truststore.location = null
	ssl.truststore.password = null
	ssl.truststore.type = JKS
	value.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer

Posted on

deepseek or 豆包 模拟面试

  1. 给它一个项目描述，询问面试官可能问哪些问题，尝试作答
  2. 让它根据不同的jd出架构题，设计题等

准备的知识点

  1. 多线程
    1. 不同线程池的用法
    2. 如何处理异常情况
  2. 数据倾斜
    1. 如何解决数据倾斜

Posted on In

迟来的干货 | Kafka权限管理实战

kafka Authentication with SASL using JAAS

kafka Documentation

干货|kafka最佳实践

kafka offset 设置

  1. 如何查看当前offset
  2. 如何指定offset

Kafka手动设置offset

Kafka手动设置offset

kafka消费者offset相关设置

Kafka offset管理

Kafka文件存储机制及offset存取

Kafka的CommitFailedException异常

使用Kafka时一定要注意防止消费速度过慢触发rebalance而导致的重复消费

Kafka又出问题了！

配置项

https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html

问题：

  1. This means the time between subsequent calls to poll() was longer than the

Posted on

[toc]

简历描述

数据仓库搭建

\1. 服务平台及用户产品部门数据仓库的设计、搭建及相关一系列的数据处理

\2. 包括对业务数据、日志数据的抽取、清洗、管理工作，并依据这些数据构建数据仓库，抽取dw层明细表，设计dm层宽表，统计ads层报表等；以及对历史任务及设计的优化

\3. 通过任务的监控、依赖、数据量监控等保证数据的准确性

\4. 主要技术：mysql、hive、datax、sqoop、flink

Posted on

[toc]

对比Flink CDC、Flume、DataX 优势，适用场景及项目上常遇到的问题有哪些

这是一份关于 Flink CDC、Flume 和 DataX 这三个数据同步工具的对比分析，我会从核心定位、优势、适用场景以及项目实战中的常见问题这几个方面展开。

📊 核心定位速览

工具 核心定位 处理模式 典型场景
Flink CDC 实时数据捕获与同步 流处理 (Streaming) 实时数据集成、构建实时数仓、数据库变更订阅-6
Flume 海量日志采集与传输 流式传输 (Streaming) 日志收集、监控数据聚合、系统间事件中转-
DataX 离线/批量数据同步 批处理 (Batch) 异构数据源离线迁移、数据备份、T+1数据仓库构建–

💎 各工具优势与适用场景详解

Flink CDC（Change Data Capture）的优势在于其全增量一体化的流处理架构。它基于Flink引擎，不仅能实时捕获数据库的增量变更日志（如MySQL的binlog），还能一次性完成历史数据的全量快照读取，并在全量同步完成后无缝切换到增量模式，整个过程无需中断，保证数据一致性-。这使其成为构建实时数据湖、实时数仓和需要低延迟响应的数据管道的理想选择-1。

Flume

Flume 的核心优势在于其专为日志而生的轻量级、高可靠架构。它采用简单的管道（Source-Channel-Sink）模型，稳定且易于部署，是处理非结构化或半结构化日志数据的利器-10。因此，它广泛用于将分散在大量服务器上的应用日志、系统日志、访问日志等汇聚到HDFS、Kafka等中央存储系统中，为后续的离线或实时分析提供原始数据–。

DataX

DataX 的优势在于其高度的可扩展性和对离线批量同步场景的专注。它采用插件化架构，官方支持大量异构数据源（关系型数据库、NoSQL、大数据存储等），通过配置JSON文件即可完成开发，简单稳定-6-20。因此，当需要进行大规模、周期性、对实时性无要求的离线数据迁移、数据备份或T+1数据仓库ETL时，DataX是一个非常成熟可靠的选择--20。

⚠️ 项目实战中的常见问题

这三个工具在落地时也会遇到一些典型问题，以下是常见问题速查表，方便你快速定位和排查。

问题维度 Flink CDC Flume DataX
数据重复/丢失 高频问题。主要发生在全增量切换时，因位点（offset）管理或chunk边界重叠导致数据重复-47；或因Checkpoint未成功、重启时位点提交不及时导致-47。 可能因Source或Sink的事务配置不当导致数据重复或丢失，但日志场景通常对数据质量要求相对宽松。 任务中断后重启可能重跑部分数据，导致重复。不支持断点续传。
性能瓶颈 数据库连接压力：全量读取和实时CDC会与数据库建立长连接，增加源库负载-。 状态管理：处理大规模数据时对Flink状态后端（如RocksDB）要求高-。 通道吞吐量：单个Source-Sink对的处理能力有限，处理海量数据时容易成为瓶颈。 缓存开销：Channel的内存或文件缓冲可能带来额外延迟-11。 单机模式瓶颈：受限于单节点资源，处理TB级以上数据时性能可能不稳定-27。 资源竞争：并发任务多时，对CPU和内存的争用明显。
部署与运维 技术栈复杂：依赖Flink集群，需熟悉Flink作业的提交、调优和监控-6。 Schema变更：需处理源表结构变化，配置较繁琐。 配置繁琐：每个数据流都需独立配置，维护大量Flume Agent较复杂-11。 故障转移：Agent故障时的自动恢复和负载均衡需精心设计。 JSON配置复杂：复杂的同步任务需要编写冗长的JSON文件，易出错，缺乏可视化界面-20-27。 依赖外部调度：本身无调度能力，需集成DolphinScheduler等工具。
数据一致性 Exactly-Once保证：依赖Flink的Checkpoint机制，理论上可保证端到端的一致性，但在实际复杂环境中达成代价较高-。 At-least-Once保证：默认设计倾向于至少一次，确保数据不丢失，但可能重复。 批量一致：以批为单位，一批数据要么全成功要么全失败，无事务性支持，易出现数据不一致。
环境依赖 强依赖Flink：必须有一套稳定、资源充足的Flink集群，且对Flink版本有要求。 依赖Hadoop生态：常用于与HDFS、HBase等集成，对Java环境有要求。 轻量级：只需Java环境，单机即可运行，对集群依赖小。

💎 总结

  • 需要实时同步数据库变更，延迟要求在秒级甚至毫秒级。
  • 数据源为关系型数据库，需要同时处理历史全量数据和实时增量数据。
  • 希望利用Flink的流处理能力进行实时计算和清洗。

什么时候选 Flume？

  • 数据源是大量的日志文件、网络数据包、系统事件等。
  • 目标系统是 HDFS、Kafka、HBase 等大数据生态组件。
  • 对数据的实时性有一定要求，但对数据质量（如少量重复、丢失）的容忍度较高。

什么时候选 DataX？

  • 任务是离线的、批量的数据迁移，对实时性没有要求。
  • 需要在多种异构数据源之间进行数据交换（如MySQL → Hive, Oracle → HBase）。
  • 追求工具的稳定性和易用性，希望用简单的配置快速完成数据同步任务。