作者：SJZ97
主要是看了一下技术问题，其他一些因人而异的问题删掉了。
1.选择业务板块-电商 物流。
2.规范定义-规范的命名体系、数据域。
业务板块-基于业务的命名空间 数据域-当前业务板块下一组业务活动的集合，项目属于具体的业务板块，数据域面向业务分析，对业务过程或维度进行抽象 修饰类型-从属于某个业务域，比如日志域中访问终端包括无线、PC 维度-从属于一个数据域，表示度量的环境，是描述信息，如地理，时间维度等，原子指标如下单金额，派生指标=原子+修饰词+时间，比如1天海外买家支付金额 3.模型设计
选择业务过程-比如下单 声明粒度-一行表示什么，确定维度，确定事实 层次
数据操作层 ODS：把操作系统数据几乎无处理地存放在数据仓 库系统中。 公共维度模型层 CDM：存放明细事实数据、维表数据及公共指标汇总数据 ， 其中明细事实数据、维表数据一般根据 ODS 层数据加工生成，CDM 层又细分为明细数据层 DWD 和汇总数据层 DWS ，采用维度模型方法作为理论基础，更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性：同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性。 应用数据层 APP：存放数据产品个性化的统计指标数据，根据 CDM 层与 ODS 层加工生成 。（个性化指标：排名型、比值型等）) 4.维度设计
维度的定义-度量称为“事实” ，将环境描述为“维度”。 维度设计步骤-选择或新建维度-唯一，确定主维表-ODS表 直接与业务系统同步，确定相关维度-确定哪些表与主维表的关联关系 如商品与类目、spu、卖家、店铺等存在维度关系，确定维度属性-从主维表、相关维表中选择维度属性或新的维度属性。 一致性-保证交叉探查不会出现问题，例如计算转化率。具体方法：共享维表-只有一个，一致性上卷-子集，交叉属性-两个维度部分属性相同。 维度整合(垂直-不同来源但有相同的数据集，如淘宝 天猫。水平-不同来源相同数据集，如蚂蚁金服的数仓来自淘宝、支付宝、1688。 维度拆分-水平-机票酒店和普通商品拆开，它们有特殊维度属性。垂直-有的热度低，或者属性经常变化，或者产出时间晚。 缓慢变化维-快照维表，历史拉链表，极限存储-底层是历史拉链，上层多了视图，对下游用户透明，微型维度-垂直拆分，经常变化的拆分出去，比如注册时间不变，但等级经常改变。 5.事实表设计
事务型事实表-任何类型的事件都可以被理解为一种事务。比如创建订单、付款。 周期快照事实表：当需要一些状态度量时，比如账户余额、买卖家星级 、 商品库存、卖家累积交易额等，则需要聚集与之相关的事务才能进行识别计算，于是便有了周期快照事实表。快照事实表在确定的问隔内对实体的度量进行抽样，这样可以很容易地研究实体的度量值，而不需要聚集长期的事务历史。 累计快照事实表：事务型事实表能够很好的记录单一事务的发生，但对于统计不同的事务时间的关系逻辑较为复杂。比如统计买家下单到支付的时长、买家支付到卖家发货的时长、买家从下单到确认收货的时长等。如果使用事务事实表进行统计，则逻辑复杂且性能很差。对于类似于研究事件之间时间间隔的需求，采用累积快照事实表可以很好地解决。 set hive.map.aggr=true，即开启 map 端的 combiner，减少传到 reducer 的数据量，同时需设置参数hive.groupby.mapaggr.checkinterval 规定在 map 端进行聚合操作的条目数目。 设置 mapred.reduce.tasks 为较大数量，降低每个 reducer 处理的数据量。 set hive.groupby.skewindata=true，该参数可自动进行负载均衡。生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce中），最后完成最终的聚合操作。 CPT cost per time
CPC cost per click
CPM cost per mile 千次广告收入。
CPA cost per action 按转化次数计费，无转化不计费。
CPS cost per sale 按订单计费
CPV cost per view 有效播放计费，例如：播放时间 >= 10s
CPD cost per download
CPI cost per install
OCPC optimized cost per click 本质是 CPC ，采用更科学的转化率预估机制。
OCPM 本质还是 CPM
OCPA optimized cost per action，根据转化去优化出价。
ECPM 每次曝光价格
Cost 广告成本 + 货品成本。
我回答的 “1、业务（商业） 2、技术 3、耐心细心沉得住气”面试官很满意，还给我补充了一点就是“数据分析和算法能力”
业务方就是用数据的人。
ER模型严格遵守第三范式，适合对性能要求较高的场景。注重的是精简高效，更多是面向数据的整合和一致性治理，期望达到“single version of the truth”。
维度建模更多面向业务，可以通过指标来定义的场景。
ODS，DWD，DWS，APP。
复杂问题简单化。 结构清晰方便管理。 减少重复开发。 隔离原始数据。 一个程序执行单元，例如：在关系数据库中，一个事务可以是一条 SQL 语句，一组 SQL 语句或整个程序。事务应该具有4个属性：原子性、一致性、隔离性、持久性。
原子性-做完或不做 一致性-完整性不破坏 隔离性-数据只能被一个事务请求 持久性-完成后不回滚，故障时不受影响 业务理解 上下游业务方沟通 经验和制定复杂技术方案的能力 主要是 MapReduce vs Spark。
Spark 和 Hadoop 的根本差异是多个作业之间的数据通信问题 : Spark 多个作业之间数据通信是基于内存，而 MR 是基于磁盘。 Spark 只有在 shuffle 的时候将数据写入磁盘，而 MR 中多个 MR 作业之间的数据交互都要依赖于磁盘交互。 Spark 更擅长函数处理和迭代，模型更加丰富。 三面 35 mins 部门交叉面。
交叉面一般不会问技术。因为是不同岗位的人来面试。
数据研发和算法，职业规划
讲了一些重构和优化工作，然后被追问 “既然都已经优化了，那么你觉得还有哪里不够好呢？”
随机森林用过吧，讲一讲集成学习中 boosting 和 bagging 的区别
说实话当时都没有把这当成一场面试，而是不断和阿里的前辈交流数据对于业务的价值，可以做哪些事情。后来也从大老板（没错，就是我实习组的大老板）那里了解到因为已经通过了手淘数据团队的面试，所以他面我的时候也是比较宽松的，基本是让我问他问题…
笔试没有发挥太好，所以加一轮技术笔试。
一共10道题，5道简答题，5道 SQL，给了2个小时，不太难。
45 mins 天猫精灵技术团队大老板
产生-加工-消费的整个数据生命周期的质量管控 准确性、完整性、一致性、及时性、有效性 表字段是否一致，数据条目数量、空值比例、电话告警数、最晚产出时间、不同表相同维度聚合结果是否一致。
Hive：Hive 提供了 Hook 机制，在 Hive 编译、执行的各个阶段，可以调用参数配置的各种 Hook。我们利用 hive.exec.post.hooks 这个钩子，在每条语句执行结束后自动调用该钩子。 MapReduce：由于输入输出均是由各种 InputFormat/OutFormat 执行，因此可以在 Job 提交时获取。在 org.apache.hadoop.mapreduce.JobSubmitter#submitJobInternal 方法中添加一些逻辑，如在 submitJob 之后。 Spark：可以通过自定义 org.apache.spark.scheduler.SparkListener。然后在 spark/conf 中指定 spark.sql.queryExecutionListeners 和 spark.extraListeners 订阅事件总线上的事件。 终面总结：
（面试结束后分析和自我安慰）