字节大数据开发实习面经

怎样设计数据分层?

  1. 原始数据层 ODS:此层包含从各种数据源获取的未处理的原始数据。这些数据可能来自于业务系统、日志文件、外部数据提供商等。数据在这一层通常以最原始的形式存储,没有进行任何加工处理。
  2. 数据处理层 DWD:在此层,原始数据经过清洗、验证、转换等处理,以适应后续的数据分析需求。处理过程可能包括数据的格式化、空值处理、错误数据剔除、数据类型转换、数据编码等。
  3. 数据聚合层 ADS:在此层,处理后的数据根据业务需求进行聚合。这可能包括事实表的创建、维度的建立、计算指标的生成等。数据在这一层通常以数据仓库模型(如星型模型或雪花模型)的形式组织。
  4. 数据服务层 :此层为最终用户提供数据访问服务。这可能包括创建数据视图、数据集市、数据立方体等,以满足不同的数据分析和报表需求。数据在这一层通常以对用户友好的形式提供,如图表、仪表盘、报表等。

了解的大数据组件有哪些?

  1. Hadoop:Apache Hadoop 是一个开源的分布式计算框架,主要包括 HDFS(Hadoop Distributed File System)和 MapReduce 两个组件。HDFS 用于在大规模集群上存储大数据,而 MapReduce 提供了一种编程模型,用于在 HDFS 上进行分布式数据处理。
  2. Spark:Apache Spark 是一个快速的、通用的、大规模数据处理引擎,它提供了一个高级 API,支持 Java, Scala, Python 和 R,以及一个优化的运行时引擎,可以在大规模集群上进行高性能的数据处理。
  3. Hive:Apache Hive 是一种建立在 Hadoop 上的数据仓库工具,它提供了一种类 SQL 的查询语言(HiveQL),用于查询、汇总和分析存储在 Hadoop 文件系统中的大规模数据。
  4. HBase:Apache HBase 是一个建立在 Hadoop 上的分布式、列式数据库,它用于存储非结构化和半结构化的大规模数据,并提供了实时的数据访问能力。
  5. Flink:Apache Flink 是一个针对批处理和流处理的大规模数据处理框架,它提供了一种高效的、分布式的、通用的流处理引擎。
  6. Kafka:Apache Kafka 是一个分布式的流处理平台,主要用于构建实时的数据管道和流应用。
  7. ZooKeeper:Apache ZooKeeper 是一个分布式的服务协调系统,提供了一种为分布式应用提供一致性服务的机制。

spark底层计算原理?

  1. RDD:RDD 是 Spark 中的基本数据结构,它是一个分布式的元素集合。每个 RDD 都被分割成多个分区,每个分区都会在集群中的不同节点上进行处理。
  2. 懒加载:Spark 使用懒加载(lazy evaluation)的方式进行计算。这意味着,当用户对 RDD 执行转换操作(如 map、filter 等)时,这些操作并不会立即执行,而是记录下来,形成一个 "操作图"(或称为 "血缘图")。只有当需要返回结果给驱动程序或将数据写出到文件系统时,这些操作才会真正执行。这种方式可以让 Spark 更有效地优化计算过程。
  3. 转换和动作:RDD 支持两种类型的操作:转换(transformation)和动作(action)。转换操作会生成一个新的 RDD,如 map、filter 等。动作操作会触发计算并返回结果给驱动程序,如 count、collect 等。
  4. 持久化:用户可以通过持久化(persist)或缓存(cache)操作来将 RDD 保存在内存中,以便于多次访问。这对于迭代算法或共享数据集等场景非常有用。
  5. 容错:RDD 通过记录转换操作的 "血缘关系"(lineage)来实现容错。如果某个分区的数据丢失,Spark 可以通过血缘关系重新计算丢失的数据,而不需要进行复杂的数据恢复。
  6. 调度:Spark 使用一个 DAG(Directed Acyclic Graph)调度器来管理计算任务。Spark 会将操作图划分为多个阶段(stage),每个阶段包含多个任务(task),每个任务对应 RDD 的一个分区的计算。Spark 调度器会尽可能地将需要进行 shuffle 操作的任务放在同一阶段,以减少数据传输的开销。
  7. Spark SQL, DataFrame and Dataset:除了基本的 RDD API,Spark 还提供了 Spark SQL 和 DataFrame/Dataset API,这些 API 提供了更高级的数据操作方式,如 SQL 查询和列式操作等。同时,它们还能享受到 Catalyst 优化器的优化,提高计算效率。

join底层逻辑

  1. 嵌套循环连接(Nested Loop Join):这是最基本的 JOIN 实现方式。对于每一行 R 在表 A 中,扫描整个表 B 查找匹配的行。这种方法简单直观,但如果两个表的大小都很大,那么这种方法的效率会非常低。
  2. 排序合并连接(Sort Merge Join):在这种方法中,数据库首先将两个表按照连接键进行排序,然后同时扫描两个表进行连接。这种方法的优点是不需要索引,并且在两个表的大小差不多时效率很高。但如果两个表的大小差别很大,那么这种方法的效率就不是很高。
  3. 散列连接(Hash Join):散列连接是一种在内存中通过散列技术处理连接操作的方法。这种方法中,数据库首先选取两个表中的一个(通常是较小的那个),然后根据连接键创建一个散列表。然后,数据库扫描另一个表,并使用相同的散列函数处理连接键,找到在散列表中的匹配行。散列连接在处理大规模数据时效率很高,但它要求至少有一个表(或两个表的一部分)能够放进内存。

举例A(3) join B (5) 有几条数据

在 SQL 中,JOIN 操作是根据给定的连接条件,将两个表中的行组合在一起。如果你没有给出具体的连接条件,我将假设你是在问一个简单的交叉连接(CROSS JOIN),也称为笛卡尔积。

对于表 A 有 3 条记录,表 B 有 5 条记录,做 CROSS JOIN,结果将会有 3 * 5 = 15 条记录。这是因为每一条来自 A 的记录都会与 B 中的每一条记录配对,所以总的配对数就是 A 和 B 中记录数的乘积。

然而,如果你是在问其他类型的 JOIN(例如 INNER JOINLEFT JOINRIGHT JOIN 或 FULL JOIN),那么结果将取决于给定的连接条件以及满足这些条件的行的数量。

解决职场真实面试问题,分享同学真实成功案例,欢迎订阅关注!

全部评论

相关推荐

让ai总结了一下问题和回答,心累了,面试官一直问优化相关的问题,多少也回答了一些出来,最后反问的时候,问有什么能加强的,说是觉得项目没什么亮点,一、代码问题的主动发现与预防主动发现方式静态代码分析:使用 ESLint、TSLint 等工具在编码阶段检测语法错误、代码规范问题、潜在逻辑漏洞(如未处理的空值、死循环)。自动化测试:通过单元测试(Jest)、集成测试(Cypress)覆盖核心逻辑,结合 CI/CD 流程在提交 / 部署前触发测试,提前暴露问题。代码审查:制定 Code Review 规范,重点检查边界条件、性能风险、安全性(如 XSS、CSRF)。监控告警:线上通过 Sentry 等工具捕获运行时错误(如 TypeError、Promise 未捕获异常),结合日志分析高频异常点。预防措施制定开发规范:明确命名规则、代码结构、错误处理方式(如统一使用 try/catch 或全局异常捕获)。技术选型管控:避免引入低维护性依赖,优先选择成熟库并控制版本。定期重构:针对耦合度高、可维护性差的代码进行重构,降低后续迭代风险。二、To C 项目的监控设计To C 项目需重点关注用户体验与稳定性,监控设计可从以下层面展开:前端性能监控核心指标:首屏加载时间(FCP)、交互响应时间(TTI)、白屏时间,通过 Performance API 或第三方工具(如 Lighthouse、阿里云 ARMS)采集。资源加载:监控 JS/CSS 加载耗时、图片加载失败率,设置阈值告警(如某资源加载超时 >3s)。用户行为与异常监控错误监控:捕获 JS 运行时错误、接口错误(4xx/5xx)、资源加载失败,关联用户 ID、设备信息便于定位。行为轨迹:记录用户点击、滑动等操作,分析卡顿、崩溃场景的触发路径(如某按钮点击后高频报错)。业务指标监控核心流程转化:如注册、支付步骤的成功率,异常中断时触发告警。设备兼容性:统计不同浏览器 / 机型的报错率,优先修复高占比问题。实现方式埋点系统:通过 SDK 主动上报监控数据,后端存储后用 Grafana 等工具可视化。实时告警:配置短信 / 钉钉通知,针对严重错误(如大面积白屏、支付失败)即时响应。三、虚拟列表优化实现虚拟列表核心是只渲染可视区域内的 DOM 元素,减少渲染压力,实现思路:核心原理计算可视区域高度、单个 item 高度,确定可见项数量(如可视区高度 500px,item 高 50px → 可见 10 项)。监听滚动事件,动态计算滚动偏移量,确定当前需渲染的 item 起始索引。通过容器内的 “占位元素” 撑起列表总高度,避免滚动条异常,可视区项通过绝对定位展示。关键优化缓存已渲染项:避免滚动时频繁销毁 / 创建 DOM,仅更新位置和内容。预渲染缓冲区:在可视区上下额外渲染 1-2 项,减少快速滚动时的空白闪烁。动态高度支持:若 item 高度不固定,可通过预估高度 + 滚动时修正位置解决。库选型:优先使用成熟库(如 react-virtualized、vue-virtual-scroller),减少自研成本。四、列表滑动卡顿的排查与优化排查方向性能分析:用 Chrome DevTools 的 Performance 面板录制滑动过程,查看是否有长任务(>50ms)、频繁重排(Layout)/ 重绘(Paint)。DOM 数量:检查列表是否渲染了过多 DOM(如未做虚拟列表),导致渲染线程阻塞。事件处理:滑动时是否绑定了高频事件(如 scroll、touchmove)且未做节流 / 防抖,导致 JS 线程繁忙。样式问题:是否使用复杂样式(如阴影、渐变)或强制同步布局(如频繁读取 offsetHeight 后修改样式)。优化措施实现虚拟列表:减少 DOM 数量(见上文)。优化事件:对 scroll/touchmove 事件节流(如 100ms 触发一次),避免高频执行。减少重排 / 重绘:将固定样式抽离为 CSS 类,避免 inline 样式;使用 will-change: transform 让浏览器单独分层渲染。数据处理:若滑动时需加载数据,提前预加载并缓存,避免同步阻塞。五、白屏的检测与解决检测方式前端埋点:在页面关键节点(如 DOMContentLoaded、首屏元素渲染完成)设置时间戳,若超过阈值(如 5s 未渲染)则上报白屏事件。图片监控:在页面顶部放一个 1x1 像素的 “探针图片”,若加载成功则证明页面正常,否则判定为白屏。错误关联:结合 JS 错误日志(如关键脚本加载失败、语法错误)定位白屏原因。解决思路加载问题:优化资源加载(如 CDN 加速、代码分割、懒加载),处理脚本加载失败(如重试机制、备用 CDN)。渲染阻塞:避免 JS 阻塞 HTML 解析(如用 defer/async),减少首屏不必要的 CSS/JS。数据依赖:若白屏因接口延迟,增加骨架屏、加载动画,避免用户感知空白;接口失败时显示错误提示并提供重试。兼容性:修复特定浏览器的渲染 bug(如 CSS 前缀缺失、ES6+ 语法未转译)。六、ECharts 性能问题及优化常见性能问题大数据量渲染卡顿(如万级以上数据点)。频繁更新(如实时数据)导致内存泄漏或 CPU 占用过高。图表容器大小频繁变化时重绘异常。折线图(多日期筛选)的优化与后端方案前端优化:数据采样:根据日期范围动态调整精度(如日级展示 24 点,周级展示 24*7 点,月级按天采样而非小时,避免数据量过大)。节流重绘:筛选日期时,通过防抖(如 300ms 延迟)避免频繁调用 setOption。销毁旧实例:切换筛选条件前,调用 dispose () 销毁旧图表,释放内存。懒加载:非首屏图表延迟初始化,避免阻塞首屏渲染。与后端沟通方案:动态返回精度:后端根据筛选的时间范围(天 / 周 / 月)返回对应粒度的数据(如周级返回按小时聚合的平均值,而非每小时原始数据)。分页 / 分段加载:若需保留细粒度,后端支持按时间段分段返回,前端滚动时再加载后续数据。数据压缩:后端用二进制或精简格式(如仅返回 [x,y] 数组而非完整对象)减少传输量。ECharts 适配方案响应式容器:监听窗口 resize 事件,调用 resize () 方法调整图表大小,结合 CSS 媒体查询适配不同屏幕。移动端优化:简化图表样式(如隐藏次要网格线、缩小字体),触摸交互适配(如支持双击放大、手势缩放)。七、图片优化方向资源优化格式选择:优先使用 WebP/AVIF(比 JPEG 小 30%+),降级兼容旧浏览器;简单图形用 SVG 替代位图。压缩处理:通过工具(如 TinyPNG)或后端服务(如七牛云)压缩图片,平衡质量与体积。合理尺寸:根据展示容器大小提供多分辨率图片(如 srcset 属性),避免大图小用。加载优化懒加载:使用 IntersectionObserver 监听图片进入视口后再加载,减少首屏请求。预加载:对首屏或即将展示的图片(如轮播图下一张)用 link [rel="preload"] 预加载。缓存策略:设置合理的 Cache-Control 头,复用缓存减少重复请求。体验优化占位符:加载前显示低分辨率缩略图或纯色占位,减少布局偏移(CLS)。错误处理:图片加载失败时显示默认图,避免破图影响体验。八、图片加载时间的检测前端检测监听事件:通过 img.onload 记录加载完成时间,减去 img.src 赋值时间,得到加载耗时。Performance API:使用 performance.getEntriesByType ('resource') 获取图片资源的加载详情(如 startTime、responseEnd),计算耗时 = responseEnd - startTime。埋点上报:将检测到的耗时结合图片 URL、用户设备信息上报,分析慢加载图片。工具辅助浏览器 DevTools:Network 面板筛选 img 类型资源,查看各阶段耗时(如 DNS、TCP、下载)。第三方监控:通过 Lighthouse 或监控平台(如 Datadog)批量分析页面图片加载性能。
查看8道真题和解析
点赞 评论 收藏
分享
先说说目前面试进度,我是在BOSS直聘投的简历,然后京东安排面试,一面面试完成过一天安排2面2面面试完过一天安排3面,3面去线下面,面完你会遇到你今后的直属领导,下面来说说面经一面,是个女面试官1 先自我介绍2说说项目以及你目前技术栈3 说说你实时都做了哪些,说说维度建模和范式建模都有啥区别4 平时有遇到数据倾斜吗,怎么处理的5 看你有做财务数据,你认为财务数据和流量数据有啥区别,需要注意什么地方,财务数据你感觉最难的地方是哪里,怎么解决的6 来个场景题,对于一个字段找到其中出现a字母的所有次数7 模型建设规范都有哪些二面 似乎就是大部门leader和hr一起来的1 先进行自我介绍2 说一下做的项目,你扮演了什么角色3 看你实时经验比较丰富,下面来做2个场景题,对于一些交易订单来说,会出现订单出现退款,你如何可以做到订单实时的成交金额目前交易链路存在一个这个问题,交易的订单的渠道信息的某些字段可能会更新,你如何可以实现字段可以实时更新为最新得数据,保证数据不丢4 你平时看实时任务都是怎么看的,实时任务有哪些指标可以衡量,你平时遇到哪些问题,怎么解决的,你认为实时资源该怎么分配,时效性怎么确定5看你经验目前做过流量数据和财务数据,你感觉财务数据和流量数据最大的区别是啥,两者时效性和准确性都有啥区分6 你这边有啥问我的3面 线下面,京东似乎最后一面必须线下面,我去了一趟总部,感觉很大和面试官面对面聊,似乎还是交叉面,应该是别的部门领导,主要是聊了和一面2面差不多问题,不一样的地方是聊了一下数据湖,为啥现在企业都在追求数据湖,数据入湖和出湖都有哪些好处后面进展,似乎面试都通过了开始收集流水,还不知道涨幅怎么样,之前都说京东似乎不能太频繁跳,我这似乎跳的还比较频繁也给过了,可能跳槽不是卡的这么严同步一下后续到了谈薪阶段,目前base不变,加了4个月年终,总包涨30%多点
查看14道真题和解析
点赞 评论 收藏
分享
评论
13
158
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务