大数据面试吹牛草稿V2.0 (一)

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介: 面试吹牛之前先打个草稿!

面试吹牛之前先打个草稿!



各位面试官好!


1.我叫 xxx,毕业于 xxx,之前在 xxx 公司待了 1 年多,期间⼀直从事的是 IT 行业,刚开始的时候做的是 Java 开发后来转岗到大数据方向做大数据开发; 刚转行到大数据开发的时候开始比较困难的,大数据并不像 Java 那样⼀套框架基本可以搞定所有的问题,而是不同的业务对于同⼀个问题有多种解决方案。


2.我叫 xxx,毕业至今就职于 xx 公司,职位是数仓开发。


参加工作以来,我先后参与筹备大数据服务器购买以及从 0 到 1 的搭建,离线数仓项目组,实时数仓项目组。这三个项目都得到了老板们的一致好评,大大增加了业务方需要客户数据的效率,能更快的做出实时决策。


我对大数据各框架有浓厚的兴趣,工作之余经常钻研技术,例如 flink 的水位线,双流 join 等,对业务需求分析的比较透彻。


工作三年,我已经连续两年被评为优秀员工,我觉得这足以说明我技术扎实,对待工作严谨,好学,当然也离不开原公司帮助过我的师傅们。


3.我叫 xxx,毕业于 xxx,自己大学期间学了 C++就喜欢上了编程,然后大学期间利用业余时间学习了 JAVA。大四的时候又接触到了大数据,又对大数据产生兴趣,学校也开了大数据相关的专业,于是就在晚上找各种相关资料,在 B 站上搜一些比较好的大数据视频,把相关视频学习钻研了一遍。20 年毕业的时候,也从事的大数据行业的工作,参与了大数据架构的搭建,以及数仓的建模等相关的工作。又利用业余时间,进行补充知识,不断的提高自己。至于以后,还是会不断的学习来提高自己对大数据的开发能力,提高自己的业务水准。


4.我叫 xxx,毕业于 xxx。之前 2 年多的时间里一直从事大数据开发工作。


刚开始是在平台岗,主要负责数据平台的搭建以及维持整个框架的正常运行,从购买服务器,包括框架版本选型,以及服务器台数定制,这些都是从 0 到 1 搭建的;在平台岗工作了差不多半年时间,由于这段期间表现比较突出,公司想成立数仓组,就让我负责筹建搭建数仓的工作,我从数仓建模开始逐渐搭建元数据管理,数据质量监控,权限管理,指标分析,之后就一直数仓岗的工作;直到一年前,公司老大决定要做实时这块,要统计一个大屏的可视化展示,可能觉得我的攻坚能力比较强,第一时间又想到了我,我就把这个活接过来了,我开始组建实时团队,也比较好的完成了任务。


我离职前主要是做平台的搭建以及各种指标的分析: 实现和离线的都做;


我最近做的⼀个项目是商城平台,我们这个项目主要包含三个方⾯ :


  1. 数据仓库的搭建;
  2. 实时计算系统;
  3. 离线计算系统;


刚开始主要是负责做平台相关的工作,后来做了⼀段时间的实时指标,离职前主要负责离线 指标这块的内容以及⼀些维护优化的⼯作;


公司大数据部门这边刚开始有 5 个人,随后因为业务的增加又招了⼀些人离职前有 8 个人;


一、简要介绍项目



接下来我先介绍⼀下这个项目:


项目是⼀个高度定制化的商城平台,最近主要做的是数仓和离线指标计算这⼀块;


数仓初期


数仓搭建初期,由于公司数据量少,经验不足,数仓没有层级概念,过来的数据直接进行解析,每次计算一个指标的时候,都需要进行 ETL 操作,每次都需要进行 join,造成了大量的重复操作,效率十分低下,浪费大量人力。


数仓后期


数仓在搭建一段时间后,重复的计算操作困恼了我很久,后来我参考了阿里的离线数仓架构,我们对数仓进行了重新的架构搭建,对数仓进行了分层规划。


主要分为:


  1. ods 层 : 数据缓冲层;
  2. dwd 层 : 基础数据层;
  3. dws 层 : 数据汇总层;
  4. app 层 : 应用层;


分四层的原因主要是为了隔离数据然后还能复用上⼀层计算出来的数据,另一方面也是为了数据的备份;


二、介绍熟悉的框架



数据采集我们主要是采集业务系统的数据及日志数据两部分,业务系统数据存储在 Mysql 中,使用 Sqoop 将数据导入大数据平台。


Sqoop


Sqoop 是在 Hadoop 生态体系和 RDBMS 体系之间传送数据的一种工具。它的工作机制是将导入或导出命令翻译成 mapreduce 程序来实现。在翻译出的 mapreduce 中主要是对 inputformat 和 outputformat 进行定制。


我们在使用 Sqoop 导入导出时出现了 Null 的存储一致性问题,Hive 中的 Null 在底层是以“\N”来存储,而 MySQL 中的 Null 在底层就是 Null。为了保证数据两端的一致性,在导出数据时采用--input-null-string 和--input-null-non-string 两个参数。导入数据时采用--null-string 和--null-non-string。


Flume


对于日志采集我们当时选用的是 Flume,采集日志框架也有很多,之所以选择 Flume 主要是因为它采集数据的效果比较好,其次是对于 HDFS 和 Kafka ⽀持的也比较好;


Flume 主要包含三大组件:

Source、Channel、Sink



  1. Flume 在 1.7 以后提供了⼀个 TailDirSource 用来⽀持多目录和断点续传功能;


  • 断点续传主要保证在服务器挂掉的情况下,再次启动服务数据不会丢失的问题;其原理就是在底层维护了⼀个 offset 偏移量(也就是每次读取文件的偏移量)Flume 会通过这个偏移量来找到上次文件读取的位置从⽽实现了断点续传的功能;
  • 在 1.6 以前这个实现断点续传是需要手工维护这个偏移量的会比较麻烦;


  1. Channel 的种类比较多主要有:


  • MemoryChannel : 数据放在内存中,会在 Flume 宕机的时候丢失数据,可以用在对数据安全性要求没有那么高的场景中比如日志数据;
  • FileChannel : 不会丢失数据,因为数据是放在磁盘上边的⽽且⽀持多目录配置可以提高写入的性能,同时因为有落盘的操作所以效率比较低,适合用在对数据安全性要求比较高的场景比如⾦融类的数据;
  • KafkaChannel : 主要是为了对接 Kafka,使用这个可以节省 Sink 组件也可以提升效率的,我们项目中使用的就是这个 Channel,因为下⼀层是使用 Kafka 来传递消息的;


  1. 在 Flume 这⼀层我们还做了⼀个拦截器,主要是对收集到的日志做了⼀层过滤,因为有的日志没有 id 或一些关键字段,这些数据对我们数据分析来说是没有任何用的,所以在拦截器里边对这些数据进行了简单清洗;


  1. 还做了⼀个分类型的拦截器,在这个拦截器里边我们对数据进行类型的区分,主要是做了⼀个打标签的功能对不同的日志数据打上不同的标签,然后通过后续的选择器 Multiplexing 将不同标签的数据放到不同的 topic 里边,⽅便下游对数据进行处理;


Kafka:


下游数据传输使用的是 Kafka 作为消息队列来传输消息,使用 Kafka 的主要原因是因为 Kafka 的高吞吐量以及可以对数据进行分类也就是不同的 topic,⽅便下⼀层的使用,整体的架构是采用 Lamda 架构设计的,实时和离线都会从 Kafka 中获取数据来进行处理,⽽且还有其他的业务线也是从 Kafka 中获取数据的,这样做以后可以有效的提高数据的复用减少数据的冗余,离线这块我们是在 Kafka 之后⼜做了⼀层 Flume 来作为消费者处理 Kafka 中的数据的, 将消费到的数据直接放入 HDFS 中,实时这块使用的是 SparkStreaming 来消费 Kafka 中的数据;


为什么选择 Kafka 作为消息队列来处理数据


当时在做技术选型的时候我们也是做了大量的调研,因为消息队列的产品有很多比如 : ReactMQ Kafka 等;


我们当时调研考虑的主要指标就是吞吐量这⼀块,因为大数据流式处理对数据的吞吐量要求是⾮常高的,在这⼀块 ReactMQ 是比较厉害的,吞吐量可以达到 1 万多每秒;通过后来的调研以后发现 Kafka 的吞吐量比 ReactMQ 更高,如果使用恰当的话吞吐量甚⾄可以达到 10 万+每秒;



kafka 支持消息持久化,消费端是主动拉取数据,消费状态和订阅关系由客户端负责维护,消息消费完后,不会立即删除,会保留历史消息。因此支持多订阅时,消息只会存储一份就可以。


  1. broker:kafka 集群中包含一个或者多个服务实例(节点),这种服务实例被称为 broker(一个 broker 就是一个节点/一个服务器);
  2. topic:每条发布到 kafka 集群的消息都属于某个类别,这个类别就叫做 topic;
  3. partition:partition 是一个物理上的概念,每个 topic 包含一个或者多个 partition;
  4. producer:消息的生产者,负责发布消息到 kafka 的 broker 中;
  5. consumer:消息的消费者,向 kafka 的 broker 中读取消息的客户端;
  6. consumer group:消费者组,每一个 consumer 属于一个特定的 consumer group(可以为每个 consumer 指定 groupName);


Kafka 为什么可以这么快?


  1. 首先从生产者说起,生产者发送数据是按照批进行发送的并不是⼀条⼀条发送的,从这里就已经可以保证 Kafka ⼀个比较高的吞吐量了;


  1. 生产者来⼀条消息以后会进入⼀个拦截器,在拦截器里边可以对数据进行⼀个整体的 修改操作⼀般这里是不做特殊的处理的,数据从拦截器出来以后就会进入到序列化器, 在序列化器里边将数据转换成⼀个⼆进制流的形式放入 Broker 里边;


  1. 经过序列化器以后数据就会⾛到分区器,Kafka 使用的分区器是⼀个叫做 Hash 的分区器,Hasf 分区器我们可以对其进行重写;


  1. 生产者将消息发送到 Broker 的过程可能会出现消息的重复或者丢失的情况,这个主要是靠 ACK 的配置来决定的,ack 的响应有三个状态值 0,1,-1


  • 0:生产者只负责发送数据,不关心数据是否丢失,丢失的数据,需要再次发送
  • 1:partition 的 leader 收到数据,不管 follow 是否同步完数据,响应的状态码为 1
  • -1:所有的从节点都收到数据,响应的状态码为-1


  1. 这里还有⼀个很重要的概念就是 ISR 副本同步队列,在这个队列里边包含了 Leader 和 Follower,主要解决的问题就是 Leader 挂了以后谁来做 Leader 的问题:


  • 选举机制就是通过这个 ISR 来进行的,默认是有⼀个排序排序的⼀般都是选取第⼀ 个,因为每⼀批的数据只有最快的那个才能达到第⼀个接收消息,其中 ISR 队列以及 Leader 的选举是由 Controller 来控制的,Zookeeper 来进行存储,关于 Controller 在 Kafka 中也是⾮常重要的 Controller 也有⼀个专门的选举机制,它是相当于是用 Zookeeper 来做了⼀个分布式锁,具体原理就是利用 Zookeeper 生成的临时节点生成⼀个分布式锁,谁先抢占到谁就是 Leader;


三、介绍项目采用的架构



上面也说到,我们整体的架构是采用 Lamda 架构设计的。



数据从底层的数据源开始,经过 Kafka、Flume 等数据组件进行收集,然后分成两条线进行计算:


  • 一条线是进入流式计算平台(例如 Storm、Flink 或者 SparkStreaming),去计算实时的一些指标;
  • 另一条线进入批量数据处理离线计算平台(例如 Mapreduce、Hive,Spark SQL),去计算 T+1 的相关业务指标,这些指标需要隔日才能看见。
相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
5月前
|
SQL 大数据
常见大数据面试SQL-每年总成绩都有所提升的学生
一张学生成绩表(student_scores),有year-学年,subject-课程,student-学生,score-分数这四个字段,请完成如下问题: 问题1:每年每门学科排名第一的学生 问题2:每年总成绩都有所提升的学生
|
6月前
|
分布式计算 监控 大数据
《吊打面试官》- 大数据工程师50道中大厂面试真题保姆级详解
《吊打面试官》- 大数据工程师50道中大厂面试真题保姆级详解
111 1
《吊打面试官》- 大数据工程师50道中大厂面试真题保姆级详解
|
6月前
|
SQL 分布式计算 算法
程序员必备的面试技巧——大数据工程师面试必备技能
程序员必备的面试技巧——大数据工程师面试必备技能
118 0
|
6月前
|
缓存 运维 NoSQL
面试分享:Redis在大数据环境下的缓存策略与实践
【4月更文挑战第10天】探索Redis在大数据缓存的关键作用,本文分享面试经验及必备知识点。聚焦Redis数据结构(String、List、Set、Hash、Sorted Set)及其适用场景,缓存策略(LRU、LFU、TTL)与过期机制,集群和数据分片,以及性能优化和运维技巧。通过代码示例深入理解,助你面试成功,构建高效缓存服务。
177 4
|
6月前
|
消息中间件 分布式计算 Kafka
50道大数据精选面试题
50道大数据精选面试题
|
3月前
|
存储 Java
【IO面试题 四】、介绍一下Java的序列化与反序列化
Java的序列化与反序列化允许对象通过实现Serializable接口转换成字节序列并存储或传输,之后可以通过ObjectInputStream和ObjectOutputStream的方法将这些字节序列恢复成对象。
|
16天前
|
存储 算法 Java
大厂面试高频:什么是自旋锁?Java 实现自旋锁的原理?
本文详解自旋锁的概念、优缺点、使用场景及Java实现。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:什么是自旋锁?Java 实现自旋锁的原理?
|
17天前
|
存储 缓存 Java
大厂面试必看!Java基本数据类型和包装类的那些坑
本文介绍了Java中的基本数据类型和包装类,包括整数类型、浮点数类型、字符类型和布尔类型。详细讲解了每种类型的特性和应用场景,并探讨了包装类的引入原因、装箱与拆箱机制以及缓存机制。最后总结了面试中常见的相关考点,帮助读者更好地理解和应对面试中的问题。
41 4
|
1月前
|
算法 Java 数据中心
探讨面试常见问题雪花算法、时钟回拨问题,java中优雅的实现方式
【10月更文挑战第2天】在大数据量系统中,分布式ID生成是一个关键问题。为了保证在分布式环境下生成的ID唯一、有序且高效,业界提出了多种解决方案,其中雪花算法(Snowflake Algorithm)是一种广泛应用的分布式ID生成算法。本文将详细介绍雪花算法的原理、实现及其处理时钟回拨问题的方法,并提供Java代码示例。
74 2
|
1月前
|
JSON 安全 前端开发
第二次面试总结 - 宏汉科技 - Java后端开发
本文是作者对宏汉科技Java后端开发岗位的第二次面试总结,面试结果不理想,主要原因是Java基础知识掌握不牢固,文章详细列出了面试中被问到的技术问题及答案,包括字符串相关函数、抽象类与接口的区别、Java创建线程池的方式、回调函数、函数式接口、反射以及Java中的集合等。
31 0
下一篇
无影云桌面