*100万条数据取topN,手写代码(手写快速排序)
*如何一个很大的文件把你的linux磁盘整崩溃了,怎么去查找这个文件?(这里的崩溃是指占用磁盘过多,什么命令找出这个文件;注意面试官提问问题前的提示)
df -h 通过文件系统来获取空间大小的信息
du -h 通过搜索文件来计算每个文件的大小然后累加得到的值(能在文件系统里面看到的文件才会被du统计)
思路,先df -h,找到是那个磁盘崩溃了,然后cd 切换到该磁盘下,du -sh * 查看各个目录文件所占用大小,即找到该大文件
-h, --human-readable 以可读性较好的方式显示尺寸(例如:1K 234M 2G)
-s, --summarize 只分别计算命令列中每个参数所占的总用量
*kafka中producer、consumer,哪段是线程安全的,哪段是线程不安全的
生产者KafkaProducer是线程安全对象,所以建议KafkaProducer采用单例模式,多个线程共享一个实例
消费者KafkaConsumer是线程不安全,
为什么是KafkaConsumer是线程不安全?
线程与KafkaConsumer对象的对应关系是1:1,一个KafkaConsumer对象始终是由同一个线程来操作的;不然也不会存在消费者组的概念,topic下的每个分区只从属于消费组中的一个消费者,其它消费者是不能再去消费这个分区了。
不能使用ScheduledExecutorService这个线程池来操作KafkaConsumer。因为线程池本来是为了共享而存在的,他在执行任务时,线程与任务的关系是不固定的,而KafkaConsumer要求的是固定的线程
*ES、Hbase数据更新有什么区别
都是存在更新,把旧数据标记为删除,不存在插入,如果一定要说有什么区别,那就是更新的命令不同,原理都很相似。
Hbase更新数据 (Put,Delete,Put,Scan/Get)
put 'ns1:t_userinfo','rk0001','base_info:name','zhaomin'
使用put命令更新现有的单元格值,新给定值替换现有的值,并更新该行。
标记删除,不是真正的删除。
major compact
默认7天执行一次,将多个storefile合并,会将过期的,超出版本数量的、标记为删除的数据都
进行删除(一般要在系统空闲的时候去做,因为需要大量的磁盘IO),一般会设置手动执行
ES更新数据
restful
window(http方式)
linux(curl方式),以此为例; -XPut、-XDelete、-XPut/-Post、-XGet
curl -XPUT 11.11.11.11:30000/test_index/product/1 -d '{"brand_name" : "华为","product_name" : "P9"}'
ES可以使用PUT或者POST对文档进行更新(全部更新),如果指定ID的文档不存在,则执行插入操作,如果已经存在,则执行更新操作。
PUT操作是幂等的,即连续多次执行同一个PUT命令,与只执行一次命令,对数据库的影响是相同的。不带id的时候不能用PUT了,因为每次执行都会新插入一条,违背了幂等原则。POST则不一定。
只要指定了id,则不管是插入还是更新,PUT和POST都是等效的(这里的更新说的是全部更新,如果只是更新文档的某个字段,则只能用POST, _update)
但是如果不指定id,则只能是插入操作,且只能用POST,且此时ES会自动生成一个id。
curl -XGET 11.11.11.11:30000/test_index/product/1
curl -XGET 11.11.11.11:30000/test_index/product/_search
curl -XDELETE 11.11.11.11:30000/test_index/product/1
ES执行更新操作的时候,ES首先将旧的文档标记为删除状态,然后添加新的文档,旧的文档不会立即消失,但是你也无法访问,ES会在你继续添加更多数据的时候在后台清理已经标记为删除状态的文档。
*container的生命周期是啥,是在整个job的完成后,还是container上的任务完成后
一个应用程序所需的Container分为两大类,如下:
(1) 运行ApplicationMaster的Container:这是由ResourceManager(向内部的资源调度器)申请和启动的,用户提交应用程序时,可指定唯一的ApplicationMaster所需的资源; (2) 运行各类任务的Container:这是由ApplicationMaster向ResourceManager申请的,并由ApplicationMaster与NodeManager通信以启动之。 |
container的生命周期:从ResourceManager为ApplicationMaster指定资源容器container,到运行在container上各个task执行,再到ApplicationMaster向ResourceManager注销自己,ResourceManager回收资源 这个过程去说行了。
*hive的UDF,项目哪个地方用到UDF函数,举例两三个
UDF
一.通过出生日期计算玩家的年龄
游戏需要实名认证,玩家有输入身份证信息,获取到玩家的出生日期调用自定义的UDF得到玩家的年龄
// 计算年龄
int age = nowYear - birthYear;
//判断月份
if (nowMonth < birthMonth){
age -=1;
} else if (nowMonth == birthMonth && nowDay < birthDay){
age -=1;
}
return age;
1.继承UDF,重写evaluate()方法,该方法可以重载(根据需求)
--- 需要导包(hive.exec.udf...)
2.打包上传服务器,添加到class中(服务器中输入)
add jar /xxx.jar
3. 创建一个函数指向编写的类(hive中输入)
create temporary function myUpper as '包名+类名'
二.对后台收集到的json格式的日志信息(主要包含服务器时间、公共字段、事件信息)调用自定义的UDF\UDTF进行解析,
UDF,根据传入的公共字段数组进行解析,返回各公共字段key对应的值 + 事件json格式 + 服务时间
extends UDF,利用fastJson解析json格式的数据,得到公共字段key对应的值
UDTF,针对之前UDF解析的字段 事件json格式数据,调用自定义的UDTF,返回event_name,event_json
extends GenericUDTF,重写initialize:将指定输出参数的名称和参数类型
重写process:编写处理逻辑,输入1条记录,输出若干条结果, // 将结果返回,forward(result);
重写close:当没有记录处理的时候该方法会被调用,用来清理代码或者产生额外的输出
为了DWD层的基础明细表包含:公共字段、事件名称、事件json、服务器时间
UDTF
一.上述解析日志的
二.对于这样的数据样式解析:21::Ge(1995)::Action|Comedy|Drama,编写UDTF; 类似一行转换成多行 lateral view explode(数组)功能,
extends GenericUDTF,重写initialize:将指定输出参数的名称和参数类型
重写process:编写处理逻辑,输入1条记录,输出若干条结果, // 将结果返回,forward(result);
重写close:当没有记录处理的时候该方法会被调用,用来清理代码或者产生额外的输出
UDAF
玩家登录的区域拼接,就是玩家登录游戏的地址区域是会变的,根据玩家分组,然后对登录的区域字段调用自定义的UDAF函数进行聚合拼接并按排名输出
extends GenericUDAFEvaluator,重写init()、merge()等方法
*数仓的建模过程,项目中包含哪些事实表维度表十几张,怎么建星型模型、雪花模型等过程,出指标
数仓构建过程:
数仓构建:首先肯定就是业务建模、概念建模,明确需求分析,这个数仓是要做什么的嘛,确认主题; 逻辑建模,业务概念实体化,确认粒度,确认事实表有哪些,维度表又有哪些,明确表与表之间的关系模型,是星型,还是雪花,星座等
建模工具:PowerDesigner
主题有十几,事实表也是十几个,维度表有几十张
主题有哪些(玩家、会员主题、充值、消费、商店、活动、广告、任务、推广主题)
事实表有哪些(准备好几张表,重要表重要字段) 用户表(id、name、sex、地区、年龄)、 登陆表、订单表、订单详情表(成功、失败)、商品表(道具、技能、皮肤) 、支付流水表、交易流水表(支付、消费、兑换)、充值信息表、启动日志表、事件日志表(点击、商品详情、商品列表、消息通知、广告等)
用户登录表:id,time登录时间,server游戏服务器,country,region省,city市,isp网络线路
游戏日志表:id,model游戏模式,playTime比赛耗时单位秒,Time开始时间,Money
维度表有哪些(准备好几张表,重要表重要字段)
时间:日/周/月/季度/年
区域维度表含有字段有 cityid、cityname、provinceid、provincename, 国家、省份、城市
国家维、省份维、城市维
用户拓展维度表一般含有userid、account、nickname、spreader_channel、reigster_ip、register_area、是否付费用户、是否一次性用户;用户维度应该是一个渐变维度,因为像是否付费用户、新老用户等是会随时间改变的属性。另外它有一些属性是激烈变化的,如用户游戏等级
道具维度表一般含有的字段有 itemId、itemname、itemtypeid、itemtypename、price、属性,由于要经常性的上架和下架商城物品,因而这也是一个渐变维度,
技能维度表
皮肤维度表
角色维度表
服务器:server、时间
设备终端(Android):
职业:上班族、医生、护士、老师、创业者
教育:学历、毕业院校、证书
充值支付维度一般含有充值渠道和支付平台,充值渠道指付款来源,如直接支付宝付款、工商银行……支付平台指支付宝、财付通、神州付、骏网等支付平台
小游戏维度表,含有的字段一般为 extragameid、extragamename,小游戏是指在一款游戏产品内增设的额外游戏功能,如“幸运转盘”,此举在增添游戏玩法的同时也增加了吸金点
活动维度表一般含有的字段有 activitiesid、activitiesname、gameroomid、datekey……节日一过,活动也会随着停止,因而这个活动维度也是渐变维度,
语言:
合作方
虚拟货币维度
游戏模式维度
推广渠道维度表一般有字段spreaderchannelid、spreaderchannelname、spreadertypeid、spreadertypename;一般有seo竞价(搜索引擎推广)、网页广告位(下载页面链接)、网页下载 链接、第三方平台桌面推广(比如360桌面)、网吧桌面推广、论坛……,推广方式有CPA、CPS、seo、个人兼职等等。
用到了什么模型
主要是星型模型,一张事实表被多张维度表环绕, 登录事实下时间、区域、服务器、设备终端; 订单事实下时间、区域、道具; 充值信息表下时间、区域
还有雪花模型,一张事实表被多张维度表环绕的同时,维度表又嵌套一层或多层的维度表,
如用户事实表下又区域,区域维度下,又有国家维、省份维、城市维更细的维度划分
商品表下有道具、技能、皮肤、角色维度下,会有属性维,更细的粒度去描述这个维度
------------------------------------------------------