0.自我介绍
答：1）.简单的自我介绍，突出自己优势
2）.项目介绍
3）.项目中承担的工作和模块。
4）.长的帅或漂亮，前四条都可以忽略
1. 什么是数据仓库？如何构建数据仓库？
可参考：漫谈 | 大牛带你从0到1构建数据仓库实战
（如果这个问题回答的好，后面很多问题都不需要再问）
答：数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，它用于支持企业或组织的决策分析处理。
数仓构建：
1). 前期业务调研需求调研 数据调研 技术选型
2). 提炼业务模型，总线矩阵，划分主题域；
3). 定制规范命名规范、开发规范、流程规范
4). 数仓架构分层：一般分为
操作数据层（ODS）、公共维度模型层（CDM）和应用数据层（ADS）,其中公共维度模型层包括明细数据层（DWD和汇总数据层（DWS）
公共维度模型层（CDM）：存放明细事实数据、维表数据及公共指标汇总数据,其中明细事实数据、维表数据一般根据ODS层数据加工生成：公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
CDM层又细分为DWD层和DWS层,分别是明细数据层和汇总数据层,采用维度模型方法作为理论基础,更多地采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联,提高明细数据表的易用性：同时在汇总数据层,加强指标的维度退化,采取更多的宽表化手段构建公共指标数据层,提升公共指标的复用性,减少重复加工。
应用数据层（ADS）：存放数据产品个性化的统计指标数据,根据CDM层与ODS层加工生成。
5）.选择合适的数据模型，不同的行业涉选取的模型近不相同，合适的模型，更利于在数据存储，计算，开发，安全，以及数据查询的效率，更能体现数仓的价值。
综上所述：数仓建设这个问题的范围过于大，它包含了一个0-1的过程，此处只做大方面的回答，具体的细节问题还需另外讨论。
2.如何建设数据中台？可简单说下对中台理解与思路
答：省略
可参考：
蚂蚁金服技术中台架构实践
漫画：什么是中台？
阿里架构总监一次讲透中台架构，13页PPT精华详解，建议收藏！
3.数据仓库、数据中台、数据湖的理解
答：数据仓库 分而治之 对象BI
数据湖 无为而治 对象AI
数据中台 一统天下 对象DataAPI（组织架构）
可参考：
辨析数据仓库、数据湖和数据中台内涵及差异点(建议收藏)
数据中台VS数据仓库、数据中台VS业务中台，到底有什么区别？
Delta Lake | Apache大神带你了解数据湖，这一篇文章就够了
4.传统数仓的程度（建模工具、ETL工具、BI报表工具、调度系统）
答：
建模工具：powerDesiger、Erwin、Visio
ETL工具: kettle/informatic（主流的两款） 等等
BI报表工具:superset、cboard、redash、帆软BI/QuickBI/PowerBI 等等
调度系统：airflow、azkaban、ooize、xxl-job、dolphinscheduler、Zeus、hera、TASKCTL/自研平台 等等
参考：大数据可视化BI工具，通幽洞微
系列 | 漫谈数仓第三篇NO.3 『数据处理』ETL
系列 | 漫谈数仓第四篇NO.4 『数据应用』（BI&OLAP）
5.传统数仓和大数据数仓的异同？有哪些大的变化？
答：其区别主要数数仓数据存储的地方不同，传统数仓数据存储在mysql/oracle等关系型数据库上，大数据数仓存储在hadoop平台的hive中（实际上是HDFS中），当然也有其他的数仓产品比如TD、greenplum等。
我接触过的传统数仓技术架构是使用kettle做ETL工具，数据保存在mysql中，使用MSTR+java开发的数据平台做可视化，随着数据量逐渐增大，事实表条数达到千万级，kettle逐渐变得不稳定，
单表做拉链的任务的执行时间也指数级增加，从1/2h到了6/7h。
公司考虑使用hadoop平台的hive做数据仓库，报表层数据保存在mysql中，使用tableau做报表系统，这样不用担心存储问题、计算速度也大大加快了。
在此基础上，公司开放了hue给各个部门使用，这样简单的提数工作可以由运营自己来操作。
使用presto可以做mysql、hive的跨库查询，使用时要注意presto的数据类型非常严格。
6.印象最深刻的项目？为什么？亮点与优势？
答：回答的方向两方面
1.好的项目，从中学到了什么
2.差的项目，你是如何改造的
7.数仓最重要的是什么？
答：数据的准确性，鄙人记得在一个统计网站上看过，好多数仓因为数据不准确被终止。
数据的真正价值在于数据驱动决策，通过数据指导运营,在一个不准确的数据驱动下，结果可想而知。
如何保证数据的准确性？
元数据的建设与管理是其中重要的一个环节
元数据建设的目标是打通数据接入到加工 ，再到数据消费整个链路，规范元数据体系与模型，提供统一的元数据服务出口，保障元数据产出的稳定性和质量。
首先梳理清楚元仓底层数据，对元数据做分类，如计算元数据、存储元数据、质量元数据等，减少数据重复建设，保障数据的唯一性。
另外， 要丰富表和字段使用说明，方便使用和理解。根据元仓底层数据构建元仓中间层，建设元数据基础宽表，也就是元数据中间层，打通从数据产生到消费整个链路。
也可在粒度、规范等方面展开，见仁见智。
可参考：美团 数据质量平台 设计与实践
8.实时数仓做过吗？采用什么架构？lambda有哪些优缺点？
答：省略（目前我只接触到离线数仓）
参考：如果你也想做实时数仓…
基于Lambda架构，MES实时计算平台演进之路
9.如何看待kappa架构？iota架构呢？
答：省略（目前还没接触到）
参考：Lambda架构已死，去ETL化的IOTA才是未来
10.责任心？沟通能力？团队协作？数据思维？
答：鄙人开发出身，后转数仓；深有体会搞TP系统和搞AP系统的考虑问题有出入，也许更多的是对数仓的机制不了解，
项目需要不同的开发人员来协作完成某项工作，因此大家在交流沟通上需要找到一个共同的点，协作合力完成。
11.用户画像（静态、动态标签，统计、规则、预测标签，衰退系数、标签权重）
参考：用户画像
58用户画像实践
答：
静态数据-评估价值:用户相对稳定的信息，例如，主要包括人口属性、商业属性等方面数据；这类信息，自成标签，如果企业有真实信息则无需过多建模预测，更多的是数据清洗工作，如果某些静态信息不准或缺失则需要建模预测。
动态数据-循迹: 用户不断变化的行为信息，例如：浏览凡客首页、浏览休闲鞋单品页、搜索帆布鞋、发表关于鞋品质的微博、赞“双十一大促”的微博消息。等等均可看作互联网用户行为。
形态:标签与权重: 用户画像的最终形态是通过分析用户行为，最终为每个用户打上标签，以及该标签的权重
标签：表征了内容，用户对该内容有兴趣、偏好、需求等等
权重：表征了指数，用户的兴趣、偏好指数，也可能表征用户的需求度，可以简单的理解为可信度，概率
数据建模方法: 标签=用户标识 + 时间 + 行为类型 + 接触点（网址+内容）的聚合，某用户因为在什么时间、地点、做了什么事，所以会打上**标签
12.推荐系统（协同过滤，基于用户、商品，SVD，各种距离算法等）
答：省略（只知神策有相关的产品）
13.数仓基础理念理解
可参考：数据仓库建模
（主题域 血缘关系 拉链表 代理键 维度退化 缓慢变化维SCD 事实表类型 增量dwd处理 星型/雪花/星座模型 事实 维度 粒度 原子/派生指标 OLAP）
答：省略（概念性的问题可以自行查找）
14.数仓如何确定主题域？CDM？
参考：系列 | 漫谈数仓第二篇NO.2 数据模型（维度建模）
答：主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。
15.数仓如何分层的？及每一层的作用？思考：为什么要这么分层？
参考：系列 | 漫谈数仓第一篇NO.1 『数仓架构』
数仓蓝图：如何优雅地规划数仓体系
答：如何架构分层？
结合Inmon和Kimball的集线器式和总线式的数据仓库的优点，分层可为ODS【-MID】-DW-DM-OLAP/OLAM/app（不同企业略有差异）
ODS层是将OLTP数据通过ETL同步到数据仓库来作为数据仓库最基础的数据来源。在这个过程中，数据经过了一定的清洗，比如字段的统一，脏数据的去除等，但是数据的粒度是不会变化的。ODS层的数据可以只保留一定的时间。
MID中间层是采用Inmon集线器架构的方式，使用范式建模（贴源）的方法。这一层主要是做规范化的事情，比如应用库表非规范化，字段格式复杂（json格式）需做一些处理。这一层不是必须有的。也不会对外开放使用。范式建模保证了数据一致性、唯一性、正确性。
DW-DM层是采用Kimball的总线式的数据仓库架构，针对部门（比如财务部门）或者某一主题（比如商户、用户），通过维度建模（推荐星型模型），构建一致性维度，原子粒度的数据是DW层，按照实体或者主题经过一定的汇总，建设数据集市模型。数据集市可以为OLAP提供服务。
为什么要分层的思考？
空间换时间。通过建设多层次的数据模型供用户使用，避免用户直接使用操作型数据，可以更高效的访问数据。 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。 便于处理业务的变化。随着业务的变化，只需要调整底层的数据，对应用层对业务的调整零感知.
分层的价值
01.高效的数据组织形式【易维护】
面向主题的特性决定了数据仓库拥有业务数据库所无法拥有的高效的数据组织形式，更加完整的数据体系，清晰的数据分类和分层机制。因为所有数据在进入数据仓库之前都经过清洗和过滤，使原始数据不再杂乱无章，基于优化查询的组织形式，有效提高数据获取、统计和分析的效率。
02.时间价值【高性能】
数据仓库的构建将大大缩短获取信息的时间，数据仓库作为数据的集合，所有的信息都可以从数据仓库直接获取，数据仓库的最大优势在于一旦底层从各类数据源到数据仓库的ETL流程构建成型，那么每天就会有来自各方面的信息通过自动任务调度的形式流入数据仓库，从而使一切基于这些底层信息的数据获取的效率达到迅速提升。
从应用来看，使用数据仓库可以大大提高数据的查询效率，尤其对于海量数据的关联查询和复杂查询，所以数据仓库有利于实现复杂的统计需求，提高数据统计的效率。
03.集成价值【简单化】
数据仓库是所有数据的集合，包括日志信息、数据库数据、文本数据、外部数据等都集成在数据仓库中，对于应用来说，实现各种不同数据的关联并使多维分析更加方便，为从多角度多层次地数据分析和决策制定提供的可能。
04.历史数据【历史性】
记录历史是数据仓库的特性之一，数据仓库能够还原历史时间点上的产品状态、用户状态、用户行为等，以便于能更好的回溯历史，分析历史，跟踪用户的历史行为，更好地比较历史和总结历史，同时根据历史预测未来。
16.数仓有哪几种建模思想？维度建模、范式建模、datavault？.. 有什么优劣，如何选择？
答：ER模型，维度建模，datavault模型，Anchor 模型。
参考：系列 | 漫谈数仓第二篇NO.2 数据模型（维度建模）
数据仓库建模
ER模型：
数据仓库之父 Bill lnmon 提出的建模方法是从全企业的高度设计一 个3NF 模型，用实体关系（ Entity Relationship, ER）模型描述企业业 务，在范式理论上符合 3NF。数据仓库中的 3NF 与 OLTP 系统中的 3NF 的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体 业务流程的实体对象关系的抽象。其具有以下几个特点：· 需要全面了解企业业务和数据。· 实施周期非常长。． 对建模人员的能力要求非常高。采用 ER 模型建设数据仓库模型的出发点是整合数据，将各个系统
中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性 处理，为数据分析决策服务，但是并不能直接用于分析决策。其建模步骤分为三个阶段。·高层模型：一个高度抽象的模型，描述主要的主题以及主题间的 关系，用于描述企业的业务总体概况。· 中层模型：在高层模型的基础上，细化主题的数据项。． 物理模型（也叫底层模型）：在中层模型的基础上，考虑物理存 储，同时基于性能和平台特点进行物理属性的设计，也可能做一 些表的合并、分区的设计等。
维度建模：
维度建模从分析决策的需求出发构建模型，为分析需求服务，因此 它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复 杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下 使用的雪花模型。其设计分为以下几个步骤。· 选择需要进行分析决策的业务过程。业务过程可以是单个业务事 件，比如交易的支付、退款等；也可以是某个事件的状态，比如 当前的账户余额等；还可以是一系列相关业务事件组成的业务流 程，具体需要看我们分析的是某些事件发生情况，还是当前状态， 或是事件流转效率。· 选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，
从而决定选择的粒度。粒度是维度的一个组合。· 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括 维度属性，用于分析时进行分组和筛选。·选择事实。确定分析需要衡量的指标。
Data Vault 模型：
Data Vault 是 Dan Linstedt 发起创建的一种模型，它是 ER 模型的衍 生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分 析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史 性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合g 同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的 范式处理来优化模型，以应对游、系统变更的扩展性。
Data Vault 模型组成部分：
• Hub：是企业的核心业务实体，由实体 key、数据仓库序列代理 键、装载时间、数据来源组成。• Link：代表 Hub 之间的关系。这里与 ER 模型最大的区别是将关 系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直 接描述 1 : 1 、 l :n 和 n:n 的关系，而不需要做任何变更。它由 Hub 的代理键、装载时间、数据来源组成。• Satellite：是 Hub 的详细描述内容， 一个 Hub 可以有多个 Satellite。它由 Hub 的代理键、装载时间、来源类型、详细的 Hub 描述信 息组成。
Anchor 模型：
Anchor 对 Data Vault 模型做了进一步规范化处理， Lars. Ri:innback 的初衷是设计一个高度可扩展的模型，其核心思想是所有的扩展只是添 加而不是修改，因此将模型规范到 6NF，基本变成了 k-v 结构化模型。我们看一下 Anchor 模型的组成。• Anchors：类似于 Data Vault 的 Hub ，代表业务实体，且只有主键。• Attributes：功能类似于 Data Vault 的 Satellite ，但是它更加规范 化，将其全部 k-v 结构化， 一个表只有一个 Anchors 的属性描述。• Ties：就是 Anchors 之间的关系，单独用表来描述，类似于 Data Vault 的 Link，可以提升整体模型关系的扩展能力。• Knots：代表那些可能会在多个 Anchors 中公用的属性的提炼， 比如性别、状态等这种枚举类型且被公用的属性。
以上四种模型总结：
综上所述：数据模型的选择应该根据所述的行业以及现有的业务综合考虑，选择合适的模型或者混合性模型，但要遵循模型的设计的原则；
1.高内聚低耦合
2. 核心模型与扩展模型分离
3.公共处理逻辑下沉及单一
4.成本与性能平衡
5.数据可回滚
6.一致性
7.命名清晰、可理解。
17.SCD的常用处理方式？优劣？与SCD2与拉链表有什么异同？
答：拉链表面向事实
SCD2面向维度
缓慢变化维（SCD）：
SCD1: 覆盖重新
SCD2：增加属性列
SCD3：增加维度行
拉链表：
参考：系列 | 数仓实践第三篇NO.3『拉链表』
历史拉链表，既能满足对历史数据的需求，又能很大程度的节省存储资源；
1. dw_begin_date表示该条记录的生命周期开始时间，dw_end_date表示该条记录的生命周期结束时间；
2. dw_end_date = '9999-12-31'表示该条记录目前处于有效状态；
3. 如果查询当前所有有效的记录，则select * from order_his where dw_end_date = '9999-12-31'
4. 如果查询2012-06-21的历史快照，则select * from order_his where dw_begin_date <= '2012-06-21' and end_date >= '2012-06-21'。
18.元数据的理解？元数据管理系统？
答：元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监 控数据仓库的数据状态及 ETL 的任务运行状态。
元数据有重要的应用价值，是数据管理、数据内容、数据应用的基础，在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持。
元数据管理系统： 首先梳理清楚元仓底层数据，对元数据做分类，如计算元数据、存储元数据、质量元数据等，减少数据重复建设，保障数据的唯一性。
另外， 要丰富表和字段使用说明，方便使用和理解。根据元仓底层数据构建元仓中间层，建设元数据基础宽表，也就是元数据中间层，打通从数据产生到消费整个链路。
19.如何控制数据质量？
可参考：美团 数据质量平台 设计与实践
答：
1.数据质量保证原则：完整性，准确性，数据质量，及时性，一致性
2.数据质量方法：数据资产等级的划定
3.数据加工过程卡点校验
4.风险点监控：针对在线或者离线数据的监控
5.质量衡量：故障等级的划定以及数据质量的事件的记录
20.如何做数据治理？数据资产管理呢？
参考：美团起源 数据治理平台 的架构与实践（建议收藏）
数据治理平台工具前世今生
浅谈数据治理、数据管理、数据资源与数据资产管理内涵及差异点(建议收藏)
答：
在明确数据治理是数据管理的一部分之后，下一个问题就是定义数据管理。
治理相对容易界定，它是用来明确相关角色、工作责任和工作流程的，确保数据资产能长期有序地、可持续地得到管理。
而数据管理则是一个更为广泛的定义，它与任何时间采集和应用数据的可重复流程的方方面面都紧密相关。
其实在数仓的整个链路中数据治理的理念是渗入其中的，在ETL过程中开发人员会对数据清洗这其实就是治理的一部分，再加上后期数据资产的管理和落定都有数据治理的渗入。
21.Hive优化？SQL优化，参数优化
参考：干货：Hive调优及优化的12种方式（推荐收藏）
（mapjoin、列裁剪、分区、分桶、Map数、Reduce数、常用参数等）
答：
针对于Hive内部调优的一些方式（原因和解决方案可查看上面参考文章）
01.请慎重使用COUNT(DISTINCT col)
02.小文件会造成资源的过度占用以及影响查询效率
03.请慎重使用SELECT *
04.不要在表关联后面加WHERE条件
05.处理掉字段中带有空值的数据
06.设置并行执行任务数
07.设置合理的Reducer个数
08.JVM重用
09.为什么任务执行的时候只有一个reduce？
10.选择使用Tez引擎
11.选择使用本地模式
12.选择使用严格模式
22.数据倾斜
参考：直击面试 | 一文搞懂大数据、数仓面试必问之『数据倾斜』（建议收藏）
答：
1）map倾斜
Map 端长尾的根本原因是由于读人的文件块的数据分布不均匀，再 加上 UDF 函数性能、 Join 、聚合操作等，导致读人数据量大的 Map lnstance 耗时较长。在开发过程中如果遇到 Map 端长尾的情况，首先考 虑如何让 Map Instance 读取的数据量足够均匀，然后判断是哪些操作导 致 Map Instance 比较慢 ，最后考虑这些操作是否必须在 Map 端完成 ， 在其他阶段是否会做得更好。
2）join倾斜
当大表和大表 Join 因为热点值发生倾斜时，虽然可以通过修改代 码来解决，但是修改起来很麻烦，代码改动也很大，且影响阅读。而 Max Compute 现有的参数设置使用不够灵活，倾斜值多的时候不可能将 所有值都列在参数中，且倾斜值可能经常变动。因此，我们还一直在探 索和思考，期望有更好的、更智能的解决方案，如生成统计信息， Max Compute 内部根据统计信息来自动生成解决倾斜的代码，避免投入 过多的人力。
3）reduce倾斜
目前 Reduce 端数据倾斜很多是由 Count Distinct 问题引起的，因此 在 ETL 开发工作中应该予以重视 Count Distinct 问题，避免数据膨胀。对于一些表的 Join 阶段的 Null 值问题，应该对表的数据分布要有清楚 的认识，在开发时解决这个问题。
23.小文件问题
答：原因：
① 众所周知，小文件在HDFS中存储本身就会占用过多的内存空间，那么对于MR查询过程中过多的小文件又会造成启动过多的Mapper Task, 每个Mapper都是一个后台线程，会占用JVM的空间。
② 在Hive中，动态分区会造成在插入数据过程中，生成过多零碎的小文件。
③ 不合理的Reducer Task数量的设置也会造成小文件的生成，因为最终。Reducer是将数据落地到HDFS中的。
④ Hive中分桶表的设置。
解决方案：
① 在数据源头HDFS中控制小文件产生的个数，比如采用Sequencefile作为表存储格式，不要用textfile，在一定程度上可以减少小文件（常见于在流计算的时候采用Sequencefile格式进行存储）。
② 减少reduce的数量(可以使用参数进行控制)。
③ 慎重使用动态分区，最好在分区中指定分区字段的val值。
④ 最好数据的校验工作，比如通过脚本方式检测hive表的文件数量，并进行文件合并。
⑤ 合并多个文件数据到一个文件中，重新构建表。
24.order by、sort by、distribute by、cluster by
答：order by 全局排序
sort by 局部排序(reduce)
通过修改 distribute by和sort by 字段的方法进行数据重分布。
25.udf、udtf？处理的问题？
答：省略。按实际开发陈述即可。
26.shuffer优化
答：理解hive中一个sql的执行的内在情况，是如何转换为mr的；
压缩：对数据进行压缩，减少写读数据量；
减少不必要的排序：并不是所有类型的Reduce需要的数据都是需要排序的，排序这个过程如果不需要最好还是不要的好；
27.MySQL如何改写row_number
SELECT t.*, @RowNum := @RowNum + 1 AS RowNum
FROM t, (SELECT @RowNum := 0) AS myRows;
28.连续n天登录用户
参考：大数据SQL经典面试题系列(1) - 连续3天登录用户
oracle ：
select distinct user_id
from
(
select b.user_id, b.d_temp, count(*)
from
( select a.user_id, a.login_time - rownum d_temp
from
( select t.*
from user_data t
order by t.user_id, t.login_time
)a
)b
group by b.user_id, b.d_temp
having count(*) >= 3
);
29.用户留存、用户活跃、沉默用户、回流用户
答：曾在神策的《数据驱动》一书中看到过相关的介绍，此问题数据数据运营范围，在数据的支撑下得出一段时间或者某个特定时间端内用户的情况。
30.lag/lead()over()函数、ntile() 等分析函数
参考：SQL分析函数，看这一篇就够了（最全总结）
答：lead函数：用于提取当前行前某行的数据
lag函数：用于提取当前行后某行的数据
ntile：用于将分组数据按照顺序切分成n片，返回当前记录所在的切片值。
31.rollup、cube、grouping sets grouping_id
答：
rollup(N+1个分组方案)
cube (2^N个分组方案)
grouping sets (自定义罗列出分组方案)
cube函数：
SELECT col1,col2,col3,col4 --维度字段 ,COUNT(user_id) --聚合字段 ,GROUPING__ID --聚合选取的组号(二进制表示,但是这里打印出来的是十进制) ,rpad(reverse(bin(CAST(GROUPING__ID AS BIGINT))),4,'0') --对其二进制化就能明白了,注意中间是两个下划线,因为在反转的时候会把末尾的0去掉,需要用rpad补充至维度个数 FROM TABLEGROUP BY col1,col2,col3,col4 WITH cube --维度字段都要出现在group by中,这里不能使用1,2,3,4代替 ;
grouping sets：
rollup函数：
32.partition和分桶
答：
分区：优势在于利用维度分割数据。在使用分区维度查询时，Hive只需要加载数据，极大缩短数据加载时间
分区提供了一种整理数据和优化查询的便利方式。不过，并非所有数据集都可形成合理的分区，特别是在需要合理划分数据、防止倾斜时。分桶是将数据分解管理的另一技术
分桶：解决的是数据倾斜的问题。因为桶的数量固定，所以没有数据波动。桶对于数据抽样再适合不过，同时也有利于高效的map-side Join。