面试的问题的话，因为自己是转行自学的，所以说实话对项目了解不是特别深，但这也是面试官最常问的，这几天的是个面试，差不多一开始都是要让介绍项目，然后会问到在项目中做了什么，如果说是离线数仓的话，那一开始的搭建，模型设计，分层，建表，什么情况建宽表，能解决什么问题，缺点是什么，差不多是要达到那种知其然而后知其所以然的程度面试官才会满意，其次整个项目的数据链路也要清楚，比如数据采集用的框架是datax，那datax的优点有哪些，缺点有哪些，支不支持分布式，和sqoop比起来有什么区别，以及生产过程中可能会遇到什么问题，怎么解决，会问的很细，之前自己自学的时候仅仅是把一套项目跑下来，但是面试官并不care你能不能跑下来，他们更会关注你有没有工程化思维，就是在搭这一套系统或者平台的时候考虑到各个组件会遇到的一些问题，比如flume，kafka的宕机，数据重复，kafka的压测也会闻到，是怎么发现问题，解决问题，他们可能更看重这个过程。
系统运维重点关注：
① 如何避免出问题？测试用例维护 & 自动化测试，资源监控 & 流量监控。
② 什么时候会出问题，出了问题怎么解决？历史故障有哪些？是否存在复盘文档？
尝试给自己提出下面的问题并且找到答案：
什么时间容易出问题？比如电商双11大促，系统压力暴涨，这时候很容易出问题。
对关键链路是否已有监控？需要看系统有配置了哪些报警项，监控了哪些方面。
如果出了问题怎么解决？日志在哪？是否有全链路跟踪？是否有一些紧急修复操作，比如开关配置、降级、限流、熔断配置。
系统有哪些历史坑点？找已经熟悉系统的研发同事回顾历史问题，以免踩坑。通过同事总结的 case 以及文档，或者与负责的产品、运营、技术与了解。系统总会有一些坑，需要把这些坑填上，填坑的过程就是熟悉系统的过程。历史代码经过多次迭代总会导致复杂度高（分支、嵌套、循环很多），耦合严重，设计漏洞，性能隐患等，很难维护，这些就需要我们去重构了。
客服反馈的常见问题有哪些？处理常见客诉有哪些方案？
场景问题
实时同步常见问题
如何提高实时同步的速度和性能？
如果同步写入速度较慢，可以适当增加写入端并发数，调整JVM参数，JVM参数与同步库数量无关，和变更频率有关。在当前资源组机器允许情况下，内存给的越大，Full GC频率会越小，实时同步性能相应也会越高。
离线同步场景及解决方案
脏数据如何排查和定位？
脏数据定义：单条数据写入目标数据源过程中发生了异常，则此条数据为脏数据。 因此只要是写入失败的数据均被归类于脏数据。
脏数据影响：脏数据将不会成功写入目的端。您可以控制是否允许脏数据产生，并且支持控制脏数据条数，数据集成默认允许脏数据产生，您可以在同步任务配置时指定脏数据产生条数。详情可参考：配置通道控制。
- 任务设置允许脏数据：当脏数据产生时，任务继续执行，但脏数据将会被舍弃，不写入目的端。
- 任务控制允许产生的脏数据条数：
- 设置脏数据允许条数为0条，则当脏数据产生时，任务将失败退出。
- 设置脏数据允许条数为x条，则当脏数据产生条数超过x条时，任务将失败退出，当脏数据产生条数小于x条时，任务将继续运行，但脏数据将会被舍弃，不写入目的端。
脏数据实时场景分析：
- 报错现象：
{"message":"写入ODPS目的表时遇到了脏数据:第[3]个字段的数据出现错误，请检查该数据并作出修改或者您可以增大阈值，忽略这条记录.","record":[{"byteSize":0,"index":0,"type":"DATE"},{"byteSize":0,"index":1,"type":"DATE"},{"byteSize":1,"index":2,"rawData":0,"type":"LONG"},{"byteSize":0,"index":3,"type":"STRING"},{"byteSize":1,"index":4,"rawData":0,"type":"LONG"},{"byteSize":0,"index":5,"type":"STRING"},{"byteSize":0,"index":6,"type":"STRING"}。 - 如何处理：该日志中可以看出脏数据的字段，第三个字段异常。
- 脏数据是writer端报的，要检查下writer端的建表语句。odps端该表字段指定的字段大小小于MySQL端该字段数据大小 。
- 数据同步原则：来源端数据源的数据要能写入目的端数据源（来源端和目的端类型需要匹配，字段定义的大小需要匹配），即源端数据类型需要与写端数据类型匹配，源端是VARCHAR类型的数据不可写到INT类型的目标列中；目标端的数据类型定义的大小需要可以接收源端映射字段实际数据大小，源端是long、varchar 、double等类型的数据，目的端均可用string、text等大范围类型接纳。
- 脏数据报错不清晰时，需要复制出打印出的脏数据的一整条，观察其中的数据，和目的端数据类型比较，看哪一条或哪一些不合规范。
比如：
{"byteSize":28,"index":25,"rawData":"ohOM71vdGKqXOqtmtriUs5QqJsf4","type":"STRING"}byteSize：字节数；index:25，第26个字段；rawData：具体值（即value）；type：数据类型。
数据湖
数据湖是多结构数据系统：
结构化数据：数据库中的数据
半结构化数据：csv，xml，json等格式
非结构化数据：电子邮件，pdf等
二进制数据：图像、音频、视频等
数据仓库
1.表
1.增量表、全量表
区别：
增量表：按天分区，20220501分区下只存5.1当天产生的数据，20220502分区下只存5.2当天产生的数据，20220503分区下只存5.3当天产生的数据
全量表：按天分区，20220501分区下存截止到5.1当天所有的数据（包括5.1以及5.1以前），20220502分区下存截止到5.2当天所有的数据（包括5.2以及5.2以前），20220503分区下存截止到5.3当天所有的数据（包括5.3以及5.3以前）
使用场景：如果数据量不是很大，20W以下，可以用全量表；如果数据量比较大，一般就用增量表。因为这边数据量还是比较大的，增量表用的比较多，但是像有一个场景，需要保存月末的快照，用的是全量表。
何时用增量表：
日志表可以搞个增量中间层，用增量表，做好分区和去重
何时用全量表：
一般非得用全量表的，主要就是一定要看当时的快照这种场景，尤其结算这边要保留月末快照。
2.缓慢变化维表
什么是缓慢变化维表：
一些维度表的数据不是静态的，而是会随着时间而缓慢地变化（这里的缓慢是相对事实表而言，事实表数据变化的速度比维度表快）这种随时间发生变化的维度，一般被称为缓慢变化维；并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题（Slowly Changing Dimensions,SCD）。
怎样处理缓慢变化维：
第一种：直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息
第二种：添加属性列。用不同的字段来保存不同的值，就是在表中增加一个字段，这个字段用来保存变化后的当前值，而原来的值则被称为变化前的值。总的来说，这种方法通过添加字段来保存变化后的痕迹。
第三种：添加维度行。新增一行，将历史数据的开始时间、结束时间设为具体的某一天，将最新数据的结束时间设为9999-99-99。这种方式典型代表就是拉链表。
3.分区表和分桶表
分桶是什么：
桶是比表或分区更为细粒度的数据范围划分。针对某一列进行桶的组织，对列值哈希，然后除以桶的个数求余，决定将该条记录存放到哪个桶中。
分桶的好处：
1、获得更高的查询处理效率。桶则是按照数据内容的某个值进行分桶，把一个大文件散列称为一个个小文件。这些小文件可以单独排序。如果另外一个表也按照同样的规则分成了一个个小文件。两个表join的时候，就不必要扫描整个表，只需要匹配相同分桶的数据即可，效率当然大大提升。
2、使抽样更高效
分桶和分区的区别：
1.分桶是对应不同的文件（细粒度），分区是对应不同的文件夹（粗粒度）；
2.分区使用的是表外字段，分桶使用的是表内字段；
3.分桶是更细粒度的划分、管理数据，当数据量越来越大时，分区不能满足需求，会进一步采用分桶技术
4.分桶随机分割数据，分区是非随机
分桶表的实质和分区表的实质：
hive的桶其实就是MapReduce的分区的概念，两者完全相同。在物理上每个桶就是目录里的一个文件，Reduce的任务数量 = 分桶的数量。
而分区代表了数据的仓库，也就是文件夹目录。每个文件夹下面可以放不同的数据文件。通过文件夹可以查询里面存放的文件。但文件夹本身和数据的内容毫无关系。
分区表演示（静态分区，动静态分区，动态分区）
静态分区表和动态分区表：
-- 静态分区
insert overwrite table par_test partition (year,month)
select name,nid,phone,ntime,'2020','12' from origin_test;
-- 一个字段使用静态分区，一个字段使用动态分区
insert overwrite table par_test partition (year='2020',month)
select name,nid,phone,ntime,month from origin_test;
-- 两个字段都使用动态分区
insert overwrite table par_test partition (year,month)
select name,nid,phone,ntime,year,month from origin_test;
4.内部表和外部表
区别：
内部表：加载数据到hive所在的hdfs目录，删除时，元数据和数据文件都删除
外部表：外部表数据的存储位置由自己制定，删除时，只删除表结构。外部表数据相对来说更加安全些，因为各种前端不会直接提供hdfs的删除接口。同时外部表数据组织也更加灵活，方便共享源数据。如果数据是多个表共享的，可以使用外部表。
使用场景：
1.每天采集的ng日志和埋点日志,在存储的时候建议使用外部表，因为日志数据是采集程序实时采集进来的，一旦被误删，恢复起来非常麻烦。而且外部表方便数据的共享。
2.做etl处理时，通常会选择内部表做中间表，因为这些数据不需要共享，使用内部表更为合适，清理时，会将HDFS上的文件同时删除。
2.维度退化
什么是退化维度？
维度退化，将维度退化至事实表中，减少事实表和维表的关联。比如像订单id，这种量级很大的维度，没必要用一张维表来存储，但是进行查询的时候又非常重要，所以这种就冗余在事实表里面，这就叫退化维度。
维度退化有什么好处？
维度如果退化在事实表中，可以减少join次数，减少事实表和维表的关联，并且退化维可以用于group by操作，进行分组统计。
为什么要用clickhouse进行加速：
随着生产数据增多，Mysql 提供的可视化查询性能遇到瓶颈，且实效性要求提高，数据报表进入了第二阶段，引进 ClickHouse 进行实时报表开发。
为什么clickhouse查询快：
你对clickhouse的了解：
扫一扫
10万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
