大模型大数据攻城狮的专栏

判断两个链表是否相交可以采用多种方法。一种方法是使用双指针。首先分别遍历两个链表，得到两个链表的长度。然后让长链表的指针先走两个链表长度差的步数。之后，同时移动两个链表的指针，每次比较两个指针是否指向相同的节点。如果指向相同节点，那么这两个链表相交；如果直到指针都走到链表末尾还没有相同节点，那么这两个链表不相交。例如，有链表 A 长度为 m，链表 B 长度为 n（假设 m > n）。先让链表 A 的指针先走 m - n 步，然后同时移动 A 和 B 的指针。

查询每个用户最大连续登录天数的问题与上一个问题类似，关键在于如何计算并判断用户连续登录的天数。最大连续登录天数可以通过类似的方式实现，但查询的重点是要返回每个用户的最长连续登录天数。event_date是事件的发生时间，continue_time是持续秒数，有的事件发生了，还没结束又发生别的事件，要求计算时间时去除重叠的时间。：首先，我们同样需要计算每个用户的登录日期，并标记每个登录记录是否是连续的。：通过计算连续的登录天数，标记出每个用户的连续登录天数。的表，包含用户的登录记录。

反射的概念Java 反射是指在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性。这种动态获取信息以及动态调用对象方法的功能称为 Java 语言的反射机制。反射的主要组成部分Class 类：是 Java 反射机制的核心类，每个类在运行时都会有一个对应的Class对象。Class类提供了获取类的各种信息的方法，如获取类的名称、获取类的构造方法、获取类的成员变量和获取类的方法等。可以通过以下三种方式获取Class对象：通过类的class。

信创旨在实现信息技术产业的自主可控，减少对外部技术的依赖，从而提升国家信息安全和经济发展的自主性。在此背景下，中国对信创提出了更高的要求，以期在激烈的市场竞争中占据有利地位。信创不仅关乎技术层面的创新，更涉及到产业链条的整合与优化。它要求从基础硬件、操作系统、数据库、中间件等各个层面实现国产替代，构建完整的信息技术生态体系。尤其是在做国企项目时，就有硬性要求使用符合信创（国产代替）。在信创背景下，符合要求的产品必须具备自主可控、安全可靠以及性能卓越等核心特点。

做好这些不用担心试用期不通过：程序员入职新公司如何快速上手项目本人遇到大数据面试题和参考答案（超过1万字精华版）大数据面试英文自我介绍参考（万字长文）大数据运维应用场景面试题汇总及参考答案（持续更新）万字数据仓库面试题及参考答案数据仓库数据质量监控和处理方法最佳实践数据仓库建模方法万字详解Doris的3种数据模型详解和数据仓库每一层的模型选用大数据面试临阵磨枪不知看什么？看这份心理就有底了-大数据常用技术栈常见面试100道题最全Hive面试题2024年（2万字详解）Elasticsearch 面试题及参考答

一周之内，他们主动找过来，把 3 年前的数据全删了，最近 2 年的数据转了归档存储。等你发现 CPU 跑到 90% 再去申请节点，节点启动要 3-5 分钟，等新节点加入集群，黄花菜都凉了，任务可能已经阻塞或者跑完了。批处理任务通常不是关键路径的在线服务，延迟几个小时是可以接受的，没必要为了那几个 9 的可用性，去交昂贵的“跨区过路费”。我看过很多团队的配置，那是真的“头铁”。如果你缩容的时候，正好把一个跑了 4 小时的 Task 所在的节点给干掉了，那这个 Task 就得重跑，这 4 小时的电费就白交了。

如果你的下游Sink也是一个分布式系统（比如写入HDFS的不同Bucket，或者写入Kafka的不同Partition）。而30分钟那一波数据，业务逻辑上决定了它们都要去往同一个下游分区。比如，按照时间切分Bucket写入HDFS。30分钟整，所有数据都要写入这个文件夹。不管你在Flink里怎么并行，到了Sink端，本质上是对同一个文件系统的目录在进行高并发写入（或者Rename操作）。文件系统的NameNode锁竞争，或者单目录下的文件数限制，会反向卡住Flink的Sink。不要直接用KeyBy。使用。

下次老板问你：“怎么保证 Flink 作业即使在 DB 爆炸的时候也不挂？你可以自信地回答： “老板，我们实现了一套基于异步 I/O 的自适应流控系统。它能在 DB 抖动时自动重试，在 DB 宕机时毫秒级熔断并降级到备用方案，同时将失败数据完整记录到死信队列，保证数据一条不丢，服务永不宕机。听听，这专业度，年终奖稳了。面试的时候，大家最喜欢聊“两阶段提交”（2PC）和“精准一次”。但在高并发且不稳定的 DB 面前，2PC 往往是稳定性毒药。

尝试推行一种规范，核心指标的计算逻辑必须封装成 UDF 或者一段标准的 SQL 片段（Snippet）。比如 "活跃用户" 的定义。不要让每个人都在 SQL 里写。

当你的订单表数据量达到 10 亿级别，且 ID 是随机生成的（比如 UUID），Bloom Filter 的误判率（False Positive）会让你痛不欲生。如果你的数据湖架构只能做 T+1 的全量覆盖，那你很幸福，洗洗睡吧，这文章你不用看了。对于要求 SLA（服务等级协议）的实时流任务，这是不可接受的。读取时，Query Engine 读到 Base File 里的数据，再读到 Log 里的 Delete Block，两者一碰，发现：“哦，这行 ID 即使在 Base 里有，也得当做不存在。

继承 Thread 类：Thread 类本身实现了 Runnable 接口，通过继承 Thread 并重写run()方法定义线程任务。run()方法是线程的核心执行逻辑，线程启动后会自动调用该方法。代码示例：@OverrideSystem.out.println("继承Thread类实现多线程");特点：优点是实现简单，直接调用start()即可启动；缺点是 Java 单继承机制限制，继承 Thread 后无法再继承其他类，灵活性较低，且任务与线程耦合度高，不利于任务复用。

从My或配置中心（如Nacos）读取规则变化，通过CDC推送到Kafka的一个专用Topic。

别小看数据结构，省内存全靠它。千万别把整个 JSON 字符串存到 State 里！我见过有人把上千字节的原始报文存 State，结果 RocksDB 膨胀得把磁盘撑爆了。我们只需要存核心字段。// 经度// 纬度// 数据产生时间（Event Time）// 最后一次处理的系统时间（用于辅助调试或延迟计算）// 千万别存 String 类型的 address，那个费空间，展示的时候再反查在open方法里初始化。这里有个细节，设置还是手动管理 Timer？很多人偷懒直接用 Flink 原生的。

很多开发同学在写代码时，习惯性地忽略，觉得这就几条数据，丢了就丢了。大错特错。在金融结算、广告计费这种对数据精度要求极高的场景下，万分之一的丢数率都可能导致对账对不上，最后是你背锅扣绩效。Side Output 的价值不在于“实时计算”，而在于“证据保留”。它的工作机制非常直白：凡是错过了 Allowed Lateness 宽限期的数据，都会被 Flink 打上一个特殊的标签（Tag），扔进一条独立的流里。主流（Main Stream）里你看不到它们，窗口计算逻辑也不理它们。但你需要把它们“捞”出来。

逻辑隔离（队列）在CPU和内存上通常有效，但在网络I/O和磁盘I/O上往往会失效。举个例子：算法团队跑了一个深度学习任务，虽然你限制了它的CPU核数，但它把机器的网卡流量打满了，或者把磁盘IOPS跑崩了。同一个节点上的数仓ETL任务，虽然有CPU配额，但因为读不出数据，照样超时。这时候，YARN的Node Labels（节点标签）功能就必须登场了。这是YARN体系下唯一能做到物理级隔离的手段。怎么搞？将集群节点划分为（高IO机型）和label_gpu（GPU机型）以及。在中，将算法队列绑定到。

假如软件层面的招数你都用了，水位还在 92%，而新的硬盘还要三天才能寄到。这时候，你需要深入 DataNode 的物理层面搞点事情。RAM_DISK：内存，极快，易失。SSD：固态，贵。DISK：普通硬盘（默认）。ARCHIVE：高密度存储（通常指计算能力弱但容量大的节点，或者同节点上的冷数据盘）。但在实际物理部署中，我们很少真的去买专门的“归档机器”。我们可以“欺骗”HDFS。如果软的不行，就来硬的。HDFS 原生支持目录级别的配额管理。

在Compaction过程中，HBase会发现f:basic这个Cell在所有HFile中都是“旧”的、“不变”的，可能会（取决于Compaction策略）跳过重写这个大的JSON块。有些数据，如用户的实时行为标签，价值会随时间迅速衰减。Region分裂本身是一个高I/O消耗的过程，涉及HFile的重新切分与元数据变更，会严重挤占正常的读写资源，导致集群性能剧烈抖动。这个过程，我们称之为。试想，十亿用户，即便每日仅有1%（千万量级）的用户画像发生变动，每个快照占用50KB，每日新增存储便高达500GB。

让我们回到最初的场景。你已经用上了Airflow的SqlSensor，它轮询上游的表。凌晨2:30，上游的存储过程终于跑完了，它COMMIT了一条的记录。你的Sensor绿了。你的主ETL任务启动了。你安全了吗？不一定。一个事故。上游的存储过程因为一个bug，在处理1000万行数据时，在第500万行抛了个异常。但该死的，它了那个异常。在CATCH块里，它没有ROLLBACK，而是简单地记录了一下日志，然后...它继续执行，并成功地在控制表里插入了'COMPLETED'状态。

必须做到万无一失。

调整为 session.timeout.ms=30000，heartbeat.interval.ms=10000，并启用 group.instance.id，rebalance 频率降低，lag 稳定。：调整 session.timeout.ms=30000，heartbeat.interval.ms=10000，并启用 group.instance.id，rebalance 频率降至每日 1 次。，一旦网络抖动或瓶颈，消息传递就像堵车的高速公路，消费者拉取消息的速度直接受影响，lag 蹭蹭往上涨。

反射是Java中一种可以在运行时动态访问类信息（包括私有成员）和调用方法的机制，常用于框架开发、动态代理等场景。下面分别实现通过反射获取类的私有变量和调用类的泛型方法，并说明关键步骤。首先，定义一个测试类，包含私有变量和泛型方法，作为反射操作的目标：获取私有变量的实现步骤：代码实现：调用泛型方法的实现步骤：代码实现（接上面的ReflectDemo类）：关键点与面试加分点：记忆法：可通过“获取-授权-操作”三步记忆反射流程：先获取Class对象和目标成员，再通过setAccessible授权

记录每个字段的来源表、转换逻辑、目标表。

编写脚本定期检查 Region 分布和热点。

接手旧项目时，最怕之一是看复杂SQL，没有用CTE表达式，各种嵌套，各种操作都在一个SQL中，就像看天书一样，更不用提去修改优化。有了大模型，这个问题可以得到好转。下面分享自己如何利用大模型来读懂复杂SQL和修改优化的。 SQL，作为数据世界的通用语言，简单查询谁都会写，但一旦涉及复杂业务逻辑、嵌套子查询、跨表关联，甚至是海量数据的性能瓶颈，优化就成了一门艺术。而大模型（LLM）的出现，像是给这门艺术装上了“智能引擎”。它们不仅能读懂SQL，还能分析语义、提出优化建议，甚至直接重写代码，省时省力。大模型的核

除了 B + 树，常见的数据结构树还包括红黑树、B 树和 AVL 树，其中红黑树和 B 树在计算机领域应用尤为广泛，其结构特点和适用场景各有侧重。红黑树是一种自平衡的二叉查找树，它通过一组规则保证树的平衡，避免出现极端倾斜的情况。其核心特点包括：节点分为红色或黑色；根节点必为黑色；叶子节点（NIL 节点）为黑色；红色节点的子节点必为黑色（即不存在连续的红色节点）；从任意节点到其所有叶子节点的路径中，黑色节点的数量相同（黑高相等）。

明确测试目标，比如点击率（CTR）、转化率（CVR）、客单价（GMV）。

模型再训练好了，怎么安全、快速地上线？数据湖的生态为模型上线提供了强大的支持，但“最后一公里”往往隐藏着不少坑。以下是上线流的核心要点。

销售数据（结构化）用Athena分析，司机日志（半结构化）用Spark处理，监控视频（非结构化）用Rekognition提取元数据。某电商平台用CSV存储销售数据，每天生成10GB文件，查询时经常卡壳。：用Kafka或AWS Kinesis摄入实时数据，存到数据湖的“热分区”（如S3 Standard），用Flink处理后写入Delta Lake或Iceberg表。：用Spark提取结构化数据特征（如销售趋势），用AI模型（如Hugging Face的BERT）处理文本或图像，生成特征向量，存回数据湖。

IAM限制访问，理赔团队只能看脱敏数据。他们的治理策略用Azure Purview管理元数据，自动爬取Raw层的HL7格式数据，记录Curated层的标准化表，标注Consumer层的报表主题。引入分层后，Raw层存原始日志，Curated层把销售数据按时间、地域标准化，Consumer层直接生成“上海门店日销售额”表，分析师两秒钟就能拿到结果。这里的数据已经过精心打磨，专为业务场景量身定制，无论是BI报表的炫酷图表、机器学习模型的训练集，还是实时仪表盘的动态数据，Consumer层都得让用户用得。

以 Java 语言为例，自定义 User 类的序列化器需实现接口，重写configure（初始化配置）、serialize（核心序列化逻辑）、close// 初始化配置（如无特殊需求可空实现）@Override// 核心序列化逻辑：将 User 对象转为 JSON 字节数组@Override// 处理空对象，避免空指针// 使用 FastJSON 实现对象转字节// 关闭资源（如无流资源可空实现）@Override// 指定自定义序列化器。

我在找flink相关的大数据开发的面试，这个问题被问不少于5次。Spark Checkpoint和Flink Checkpoint有什么不同？Flink Checkpoint设置是考虑什么因素。Flink Checkpoint设置过小会有什么问题。只有深入了解Flink Checkpoint 原理才不怕各种变种问题及追问。

HR每天收到海量简历，十几秒决定是否继续看一下，如果简历写的是MapReduce、只是很传统的hive离线数仓，就不会引起用人单位的兴趣。现在IT面试是买方市场，大数据相关岗位更是不多，如果简历没有足够亮点，没有好的学历或去过有名的公司，得到的面试机会就不会太多。下面的简历案例是从不同热门方向的模板，可以进行参考优化。

如果业务逻辑复杂，SQL 不够灵活，可以用 UDF（用户定义函数）。

Flink 的状态后端是负责管理应用程序状态存储、持久化和访问的组件，它决定了状态数据在内存和磁盘中的存储方式、Checkpoint 时的持久化路径以及状态的序列化方式。状态是 Flink 中算子在处理数据过程中积累的中间结果（如窗口聚合的计数、连接操作的缓存等），状态后端通过高效的存储和访问机制保证这些数据的可靠性和处理性能。通常使用的状态后端有三种：MemoryStateBackend、FsStateBackend（文件系统状态后端）和 RocksDBStateBackend。

选定了数据库，性能调优就是让它跑得更快、更稳的“秘密武器”。Doris和ClickHouse就像两匹赛马，调优得当，能让它们在赛道上飞驰！下面我们分享两者的实用调优技巧，结合真实案例，帮你把性能发挥到极致。

Hadoop是开源的分布式计算与存储框架，旨在处理海量数据，其主要组成部分包括HDFS、MapReduce、YARN和Common，各部分协同工作，构成完整的大数据处理体系。HDFS（Hadoop Distributed File System，分布式文件系统）是Hadoop的存储基础，采用主从（Master-Slave）架构。

用户日活跃量（DAU，Daily Active Users）是互联网产品的命脉指标，简单说，就是一天内有多少用户真正“动”了你的产品。但“动”是个模糊词，具体指什么？是打开App就算？还是得完成一次核心操作，比如发条微博、刷个短视频、点个外卖？定义日活的第一步，就是把这个“动”掰扯清楚。见过一个创业团队，把“打开App”就算日活，结果数据好看得很，但用户打开后秒退，压根没用核心功能。后来他们改成“完成一次搜索或购买”，日活数据腰斩，但真实反映了用户粘性。定义日活得贴合产品目标，不然就是自欺欺人。

默认情况下，Shuffle 文件由 Executor 提供，Reduce 任务通过 Executor 的 BlockManager 拉取数据。但如果 Executor 因为 OOM 或 GC 被杀死，Shuffle 文件也会丢失，导致整个 Stage 重跑。外部 Shuffle 服务将 Shuffle 文件的管理交给一个独立的进程，Executor 挂了也不影响数据可用性。

一家流媒体公司（如某“网飞”）用AWS S3搭建了数据湖，存储用户观看记录（JSON格式）、视频元数据（CSV）和用户上传的评论（文本）。：数据仓库要求数据在进入之前就得“洗白白”，通过ETL（Extract, Transform, Load）流程，把原始数据整理成统一的格式，存入关系型数据库（如Oracle、Snowflake）。如果说数据仓库是整齐的图书馆，数据湖（Data Lake）就是一片未经开发的原始丛林，数据以原始形态存储，自由度极高，适合各种“野蛮生长”的数据处理需求。

"start": {"times": {"min": 1,"max": 10},},"message": "用户 {event.userId} 触发高额交易报警，累计金额: {aggregate.amount}"解析事件类型：只匹配 TRANSACTION 事件。条件：单笔交易金额 ≥ 1 万元。聚合逻辑：5 分钟内累计金额超 10 万元。动作：触发报警，推送消息到 Kafka。