我的博客

前言前几天写了面试的上，主要是6个问题，这次把剩下的面试题再复盘一下。 Q7：你有遇到过反压么？怎么解决的？这个问题是做实时流处理经常会遇到的问题，反压是指Flink的某个算子数据处理有瓶颈。从而导致数据消费的速度跟不上生产，最后导致数据积压。 举例说明项目中棘手的反压问题 比如接口调用（网络IO） 然后说一下怎么解决的（async) Q8: count distinct 执行原理？ 比如我有一个登录表， 我要算uv嘛， 底层是怎么执行的？ mapper reduce?这里主要是想考察SQL的执行原理，对于count distinct这个语句，是对某个字段进行去重统计，如果直接写的话，就是一个MR任务，且只有一个reduce任务，很可能出现性能问题，如果数据量比较大的情况下，会导致失败，集群会直接kill掉container，因为是全内存的去重操作，从而引发了OOM问题。 优化方式就是使用group by，再进行count，这样多进行了一次job但是可以避免数据倾斜，不依赖域内存，效率会提升。 即 1select count(*) from (select id from tb whe ...

前言今天大环境不好，再加上一些不可言说的原因，所以萌生了想出去面试瞧瞧的想法，主要也是想看看行情，毕竟目前高不成低不就的阶段。投了很多家公司，面试机会确实不多……多说无益，直接开整。 这是一家杭州的大数据公司，面试官上来详细介绍了自己，具体说明了面试的流程和期望候选人回答的问题，算是在我面试中比较专业的面试官了，后面提问的问题就可以看的出，有点东西。 Q1：简单介绍一下你的工作经历，项目经历，以及具体的项目成果？这个问题其实就是想更一步了解一下你，看看你自己对自己的工作和做的项目有没有自己的想法，还是一个只会听从leader，埋头coding的开发。没什么好说的，这个问题应该是老早准备充分的，也应该是最熟悉的，注意不要给自己挖坑，如果可以，也可站在更高的视角进行回答，例如从项目的必要性，成果的效益等回答自己的经验和经历。对于提到的项目和技术栈，一定要了然于胸，否则就讲不通了。 Q2：你刚说了XXX项目，这个项目的数据流向和技术架构是怎样的？一般大数据的项目，如果是业务较多的非数仓项目，大概率会问数据流向，就是数据采集，数据加工，数据分析的相关问题，结合项目使用的技术栈，阐述清楚即可。 ...

前言在数据开发中，经常会收到来自业务部门指标需求。需要我们实时的对上游产生的行为数据或者日志进行分析聚合，根据预先定义好的时间段进行统计。最后输出到数据库中，供展示使用。即我们常说的实时TopN。 定义实时TopN是指在一个数据流中，实时地计算并返回当前时间窗口内某个指标的前N个最大值或最小值。在实现过程中，需要考虑数据的去重、排序、分组等问题，同时还需要考虑如何优化计算性能，以提高实时性和可伸缩性。 模拟数据首先写一段代码来模拟用户不同时间段的行为数据。通过新建一个线程来生成随机的用户数据，然后每隔固定的时间段发送到Kafka。其中KafkaUtil是用于发送的数据封装的工具类。 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596package com.hc;import ...

前言目前笔者所在的公司有相当一部分数据来源是从网络上爬取的，也有专门的爬虫团队进行数据的抓取和数据源的整理和收集。后续的流程再进行进一步的清洗、关联、分析。最终形成有价值的数据。在这一流程中， 尽管数据的分析技术比较重要， 但是了解上游数据的来源和数据抓取的机制，将利于对业务的理解，写出更加健壮高效的实时、离线处理程序。 Python入门python的基础知识这里就不详述了，基本上一两天就可以入门，最好的学习还是放在实践中去驱动，比如写第一个爬虫。首先要了解的是基本语法结构，比如常用的数据结果，字符串、列表、字典等。然后就是for循环、函数的定义和调用、类的创建与初始化等… 基本语法 变量赋值：使用等号（=）将值赋给变量，例如：x = 10 数据类型：Python支持多种数据类型，包括整数、浮点数、字符串、列表、元组、字典等。 条件语句：使用if、elif和else关键字进行条件判断，例如： 123456if x > 10: print("x is greater than 10")elif x == 10: print(&q ...

前言最近一段时间，技术圈里要说最火的是什么，肯定非ChatGPT莫属了。公众号和博客涌现出大量的GPT相关话题，让人眼花缭乱。今天刚好有点时间， 来了解一波。 概念ChatGPT是一种语言模型。主要应用于聊天机器人的技术。 GPT 英文翻译过来就是Generative Pre-training Transformer。是一种基于Transformer的自然语言处理模型，由OpenAI团队于2019年发布。 当前使用的模型是GPT-3.5-turbo 是OpenAI最新的发布的升级版，它使用了更大的模型和更多的数据进行训练，具有更强的自然语言生成和语义理解能力。 ChatGPT可以应用于多种场景，例如在线客服、智能客户端、虚拟个人助理等。在实际应用中需要根据具体需求对模型进行调整和优化，以获得更好的适用性和鲁棒性。 注册由于一些不可抗力，国内无法直接使用ChatGPT。这里有两种方法可供选择。 借助国外的代理，注册OpenAI的账号，注意最好是欧美的节点否则会有拒绝访问的错误。还需要一个能接到短信的国外手机号。可以使用一些接码平台来做。eg: sms-activate. 注册完成后就可 ...

前言目前，数据处理的链路很长，由于业务的不断迭代，导致了数据的分层。例如ODS->DWD->DWS->ADS。每个层都有不同的数据处理逻辑。 而层与层之间目前是通过Kafka队列实现解耦的。在某些场景下，上下层需要通过查询数据库来实现某种数据的更新交互。由于网络延迟和一些不可预知的原因，导致下游查询不到最新的数据，从而无法得到正确的更新。 解决方案既然是因为时间差导致的不一致问题，那直接可以使用延迟队列。虽然kafka也支持延迟队列，但是使用上限制较多，且需要配置，维护比较麻烦。在环境允许的情况下，可以优先选用RabbitMQ进行解决。网上示例很多，可以进行参考。 由于笔者是Flink流处理任务，DataSteam的底层API天然就支持对时间的精确控制。时间语义和窗口是让无界流可以聚合精准处理的两大核心要素。 大致思路如下： 首先把上游推送的标识ID进行逻辑分区 开窗口进行ID去重，保证一段时间内数据的唯一性，避免下游重复查询 定义一个状态，缓存延迟的ID 注册定时器，触发ID的推送逻辑 实现代码：12345678910111213141516171819 ...

auto offset reset 参数配置定义了消费者在没有初始偏移量的情况下从topic分区消费的具体方法。 当消费者组新加入一个消费者时，并且当前消费者是首次监听此topic体已经被定义并且是第一次收听一个主题时， 这个配置会告诉组内的消费者是从分区的开头还是结尾读取数据。 消息消费每个 Kafka 消费者都属于一个消费者组，由消费者的 group.id 配置分组。 一个消费者组将包含一个或多个消费者。 消费者组中的消费者将被分配到主题分区以消费他们的消息。 每个分区将只有一个消费者分配给它，尽管一个消费者可以分配给任何一个主题中的多个分区，并且类似地分配给它订阅的所有主题中的分区。 首次创建新的消费者组并将其消费者分配给主题分区时，必须决定从哪个点开始轮询消息。 除非消费者被告知从特定偏移量进行轮询（非典型情况），否则有两个主要选项。 首先，消费者可能会从分区的开头读取消息，处理分区日志中存在的每条消息。 第二种选择是仅在消费者开始监听后才消费写入该主题的新消息。 配置当消费者组没有设置初始偏移量时，是从topic的分区的开头消费还是消费新消息是由 Kafka 消费者的 au ...

数据流API设计 原文：https://jenkov.com/tutorials/data-streaming/stream-processing-api-designs.html 数据流处理作为一种接收实时产生的事件（记录）并立即处理的技术已经变得非常流行。使用流处理（Aka数据流）有很多好处和用例。因此设计者开发了多种流处理 的API 来帮助开发人员更加轻松地处理流程序。 从表面上看，这些流处理 API 较为相似。不过一旦你尝试使用这些 API 来实现复杂的流处理逻辑，你就会意识到这些 API 的设计大大简化了使用它们处理流的复杂性。即使是设计上的细微差别也会对实现的内容产生影响，尤其是实现起来的难易程度。 在接触过各种流处理 API 之后，我决定写这篇流处理 API 接口设计的方案分析。帮助即将涉足流处理的或者希望在流处理 API 时寻求一些指导的人。 流处理API设计概念在开始设计分析之前，我想列出我已经意识到的流处理 API 设计的重要方面。这些设计方面是： 拓扑 信息流 转向 触发器 状态 反馈 并发模型 我将在以下部分探讨不同的设计选项及其结果。 拓扑 ...

前言公司早期开发的项目，接手后需要根据不同的data source 进行迭代优化。data source数据源非常多，不同的数据源需要根据不用的产品规则进行处理。因此，老代码的里大量的if else判断非常多······。说实话刚开始不太敢动手改，非常头疼。但是经过一番思考过后，毅然决定进行重构。所谓长痛不如短痛······ 而消除if else 有很多方法，网上目前很多类似的例子。大多都比较抽象，实际的应用过程中，就需要自己独立思考，实现适合当前项目的最佳方式。笔者一开始也遇到了不少麻烦。下面本文通过结合Flink中常用的map算子，实现策略模式+工厂模式的应用。 定义 首先说明下该设计模式的定义，策略模式是指有一组算法，它将每个算法都封装起来，并且可使它们之间可以相互替换，在客户端调用它们时可以互不影响。 这里需要理解三个角色 抽象策略 具体策略 上下文环境 抽象策略是接口或者抽象类的封装，一般来定义一个方法，可以写成函数式接口，满足单一职责的原则。 具体策略是用于实现抽象策略的子类或实现类。是消除复杂if判断的关键，不同的策略实现类承接不同的业务方法和逻辑。 上下文环境 ...

前言目前公司已经有一套功能完善的大数据管理平台。业务上很多实时处理Job的技术栈是 Flink+Kafka+TiDB以前一直没有接触过TiDB 不过听旁边的技术大佬说，和MySQL一样…… 官方注释如下: TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。适合高可用、强一致要求较高、数据规模较大等各种应用场景。 问题提出总之，TiDB用下来感觉…不怎么好。接触下来问题倒挺多。除了经常发生的DDL异常，最先遇到的就是数据库锁冲突问题。 Lock wait timeout exceeded; try restarting transaction… 造成锁冲突的原因很多，主要有以下几点： 执行了锁表DML没commit，或进行了删除操作等。 同一事务内多个线程对同一条数据进行插入或者更新操作。 索引设计不当，出现死锁。 长事务，阻塞DDL，最终阻塞该表的所有 ...