Webank（微众银行）实习总结

随着深圳实习在8月底告一段落，我搭乘9月1号的飞机回到上海，虽然外面的秋招氛围如火如荼，但是中科院这个圈子里总是风平浪静，这是我喜欢他也讨厌他的一点。
言归正传，这次的失利可能在于我最后的总结汇报有所疏忽。从6月20号至8月31日，我所做的工作以及技术栈整理如下：
1、kylin+Mondrian+saiku/kylin+tableau 性能对比
Kylin介绍：
Kylin是为减少在Hadoop/Spark上百亿规模数据查询延迟而设计，主要用于OLAP平台，为Hadoop提供标准SQL支持大部分查询功能并通过事先预计算的方式生成CUBE。
Mondrian介绍：
是一个OLAP分析的引擎，主要工作是根据事先配置好的schema，将输入的多维分析语句MDX(Multidimensional Expressions )翻译成目标数据库／数据引擎的执行语言（比如SQL）。
Saiku介绍：
提供了一个多维分析的用户操作界面，可以通过简单拖拉拽的方式迅速生成报表。Saiku的主要工作是根据事先配置好的schema，将用户的操作转化成MDX语句（多维分析语句）提供给Mondrian引擎执行。

由于saiku对新版的Java10还存在不兼容现象，经过对比发现saiku的组合还是相较于收费50美金一年的tableau慢，原因是开源的Mondrian并未对需要的SQL语句进行优化，且Schema的书写尤为麻烦，二度开发的成本较高，由于业务部门使用tableau并不多，遂决定继续采用kylin+tableau的方式，但是kylin预先生成好的CUBE由于受到网络带宽传输的影响，需要先配置tableau推送到本地方才能达到毫秒级的实时查询速度。
2、OLAP和OLTP
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统，强调高可用性，用于传统数据库。OLAP主要考验的磁盘吞吐量，用于数据仓库。
3、关于异常值检测
在实际我们处理业务的过程中，应该和业务多多商量，一起来定义什么是异常值。而在实际工作中异常值往往是一个十分模糊的概念，业务也无法确定究竟什么是异常值。这个时候往往采用一些平均值、众数等统计数据进行规约。实际上，下一时刻的数据只和上几个时刻的数据相关，可以采用相关模型进行最近一期的时域分析。
4、业务部门报表的开发
在Webank做数仓，是一个和业务结合的十分紧密的岗位，隶属于消费者金融-数据管理科室。其实在哪里做数仓，都应该是和业务结合紧密的，从数据的事实表、维度表设计、再到日常MIS报表（风险日报）的开发、最后到标准指标库的建设。这一系列的工作都由数据仓库岗位承担。在实际操作中，做数据仓库并不关心数据的稀疏以及冗余。至少在webank开发的指标库中就由于各个指标的维度数目不同而需要强行放在一张表里便于操作时直接Group by而导致稀疏。所以数仓并不像传统数据库那样关注数据库的范式设计，为业务而转，而非为实时性的增删改查而转，这是数仓的岗位职责。事实上也并不存在删以及改，由于数据量十分庞大，删除数据往往是打一个标签而不会真的删除，真的删除会导致内存不连续从而造成大量的系统开销。
数据仓库的物理模型分为星型和雪花型两种。所谓星型，就是将模型中只有一个主题，其他的表中存储的都是主题的一些特征。比如货物销量的主题仓库中，每次出售记录是事实表，而时间，售货员，商品是维度，都和事实表有联系，组织起来就是星型。而如果更细化来看，商品是有种类，产地，价格等特征的，从这个角度来看，有两个主题，一个是商品出售，一个是商品本身。组织起来就是雪花型。实际项目中，由于操作型系统业务的复杂性导致本身产生了大量的数据，所以，组织起来也以雪花型居多。
常见的数仓表有如下几类：
全量表：每天的所有的最新状态的数据，
增量表：每天的新增数据，增量数据是上次导出之后的新数据。
TIPS：增量表和全量表的区别可以用select count(*) from tablename group by partition_name 来做区别如果是一张全量表的话，那么可以看到数据量始终是在递增的，如果只是增量表的话，统计的结果会有起伏。
拉链表：维护历史状态，以及最新状态数据的一种表，拉链表根据拉链粒度的不同，实际上相当于快照，只不过做了优化，去除了一部分不变的记录而已,通过拉链表可以很方便的还原出拉链时点的客户记录。
流水表： 对于表的每一个修改都会记录，可以用于反映实际记录的变更。
在webank由于腾讯云做后台支撑，几乎可以看作空间无限，所以在很多表的使用上都是全量表，只需简单依照DS字段来区分即可，但在实际空间有限的折中方案下，我们最好选择拉链表来作为数仓建设的基础表。
同时在HIVE之中也有四种表：内部表、外部表、分区表和桶表。一般而言，都是创建的内部表，外部表的创建需要显式申明external，此外，分区表也是很常用的表结构，几乎webank所有的全量表都是以DS作为字段进行分区的。桶表用于抽样，利用hash算法让数据分布均匀，在实际工作中并未用到。
5、spark组件问题，
这个问题在滴滴的笔试题中有所出现，知识点比较零散，遂总结如下：
Spark SQL 通常用于交互式查询，但这一领域同类产品太多，更多作为MapReduce的替代者，用于批量作业。
Spark Streaming 流式batch处理。主要同类产品为storm。除了storm延迟低以外，想不出不使用spark streaming的理由。（spark streaming 2.2以后延迟将降低到1ms以内;除了spark不稳定和不兼容的理由以外）
MLlib 机器学习
GraphX 图计算
Spark core spark的核心框架，以上四大组件都依赖于core。
6、LSM树
以上知识点也是来自于滴滴的笔试，对于存储引擎而言，有以下三种基本存储引擎算法：
• 哈希存储引擎 是哈希表的持久化实现，支持增、删、改以及随机读取操作，但不支持顺序扫描，对应的存储系统为key-value存储系统。对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操作O(n)快,如果不需要有序的遍历数据，哈希表就是your Mr.Right
• B树存储引擎 是B树（关于B树的由来，数据结构以及应用场景可以看之前一篇博文）的持久化实现，不仅支持单条记录的增、删、读、改操作，还支持顺序扫描（B+树的叶子节点之间的指针），对应的存储系统就是关系数据库（Mysql等）。
• LSM树（Log-Structured Merge Tree）存储引擎和B树存储引擎一样，同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提高写性能。
LSM树原理把一棵大树拆分成N棵小树，它首先写入内存中，随着小树越来越大，内存中的小树会flush到磁盘中，磁盘中的树定期可以做merge操作，合并成一棵大树，以优化读性能。（读数据需要等待内存和磁盘同步）
7、mysql索引失效问题
• 1.如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因) 要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引
• 2.对于多列索引，需要满足最左匹配原则。
• 3.like查询以%开头
• 4.如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引
8、azkaban 调度
Crontab命令与azkaban调度。
Crontab大概是滴滴用来考验应届生的吧。实际上azkaban调度才是在工作中实际使用的，主要shell来设置固定的变量，dependency设置任务流，而python跑批，整体打包成JOBS放在后台跑批，具备方便、可视化、直观的特点。
9、数据仓库的分层
ods层：称为接口层或近源数据层，表结构与源系统表结构高度相似，通常在ods层主要会做字段的筛选，枚举值转换，编码统一，异常&缺失数据处理等操作。
dw层：称为中间层，按主题建模（域->主题）的明细数据层，数据粒度与ods层一致。
dm层：称为数据集市层，集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合。
维度建模源于Kimball提出的总线式的自下而上（DM-DW）的数据仓库架构。
特点：
1.模型结构简单，星型模型为主；
2.开发周期短，能够快速迭代；
3.维护成本较高；
范式建模源于Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构。特点：
1.同一份数据只存放在一个地方，因此只能从一个地方获取，没有数据冗余，保证了数据一致性；（主要是消除冗余）
2.解耦（系统级与业务级），方便维护；
3.开发周期较长，开发成本较高；
当下的数据仓库模型架构设计中，dw层通常会采用范式建模，并且可以根据实际情况允许存在一些冗余。dm层通常会采用维度建模，因为采用维度建模构建出来的数据模型更加符合普通人的认知、易于被普通人所理解，从而有利于数据的推广使用。在webank的实习期间接触得最多得就是ODS表以及DW表，指标库得建设则主要为DM表。
10、Hive和mysql的使用区别
语法层面：
1、Hive的表操作都需要有别名，而Mysql的表操作可以直接使用表名。
2、hive不支持等值连接，必须使用on关键字作为接连条件。
3、对于分号字符的识别并不智能。
4、hive的empty和null需要做区分，empty仅仅只是长度为0的字符串。
5、hive不支持将数据插入到分区表中，仅支持覆盖重写整个表。
此外hive作为非关系型数据库是数仓的得力帮手，因为基于列存储，很方便进行维度的添加以及修改。数据在HDFS的warehouse目录下，一个表对应一个子目录。本地的/tmp目录存放日志和执行计划。
此外1、hive由于使用于数据仓库，并不存在索引。2、在数据库的CAP理论之中HIVE更强调的CP而Mysql更强调的CA。
11、数据偏移问题

map()：相当于分解任务的集合吧
reduce(): 相当于对分解任务运算结果的汇总
以上的两种函数的形参都是K/V结构
键为该行起始位置相对于文件其实位置的偏移量
12、对于粒度的理解
粒度，可以理解为某件事件发生的频率。也可以看作事看待事物的高度，其中，事实表的设计主要就是确定粒度的过程。