写在前面： 博主是一名软件工程系大数据应用开发专业大二的学生，昵称来源于《爱丽丝梦游仙境》中的Alice和自己的昵称。作为一名互联网小白，
写博客一方面是为了记录自己的学习历程，一方面是希望能够帮助到很多和自己一样处于起步阶段的萌新。由于水平有限，博客中难免会有一些错误，有纰漏之处恳请各位大佬不吝赐教！个人小站:http://alices.ibilibili.xyz/ , 博客主页:https://alice.blog.csdn.net/ 尽管当前水平可能不及各位大佬，但我还是希望自己能够做得更好，因为一天的生活就是一生的缩影。我希望在最美的年华，做最好的自己！
前段时间做过一个大数据离线数仓的项目，前后花了有好几周的时间。一共是6个阶段，想关注阶段细节的朋友可以查看?大数据实战项目这个专栏。
现在项目结束了，理应对此进行一个总结，好好回顾一下这个项目中遗漏的细节…
项目架构
① 原始数据在mysql中存储
② 使用kettle将数据从mysql同步到数据仓库(hive)
同步分为全量同步 增量同步 增量同步需要使用到拉链表(目标：既能够保存历史数据，又不会有数据冗余)
③ 数据储存到hive
hive数仓内结构: ODS : 存储着数据源同步过来的数据 DW : 对ODS层数据机型预处理（数据过滤，数据填充），以及数据的拉宽，将业务中需要的字段，但是字段不在一个表里。使用拉宽（join）将这些字段拉到一个表中。 ADS：存储最终结果
④ 使用kylin对hive内的数据进行预计算，提高查询效率
⑤ 部分数据同步至mysql,使用sqoop/kettle同步
技术选型
★ 数据来源： MySQL
★ 数据存储： Hive
★ 数据同步： Kettle
★ 计算模型（数仓）： ODS，DW，ADS三层
★ 结果存储： Hive的ads和Mysql
★ 加速查询的组件： Kylin
…
以为就这样技术选型就讲完了？不不不，既然在开头咱都谈到了需要深挖细节，那么接下来我们就要从结论反推，思考某个方面的技术为什么需要用到这个技术/组件，而不是其他类似的技术/组件。
数据来源
我们的数据来源为什么选择的是关系型数据库MySQL，而不是其他的非关系型数据库？
最主要的原因是因为 MySQL
■ 体积小，速度快，总体拥有成本低，开源；
■ 支持多种操作系统；
■ 是开源数据库，提供的接口支持多种语言连接操作；
而以MongoDB为例的非关系型数据库
□ 使用键值对存储数据；
□ 无需经过sql层的解析，读写性能很高；
□ 不提供SQL支持，学习使用成本较高；
□ 无事务处理，附加功能bi和报表等支持也不好；
综上所述，在该项目中，关系数据库MySQL更适合。
数据存储
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供类SQL查询功能（HQL）。其本质是将SQL转换为MapReduce的任务进行运算，底层由HDFS来提供数据的存储，hive可以理解为一个将SQL转换为MapReduce的任务的工具。
使用Hive的好处:
√ 操作接口采用类SQL语法，提供快速开发的能力。 √ 避免了去写MapReduce，减少开发人员的学习成本。 √ 功能扩展很方便。
通过Hive与传统RDBMS的对比
Hive | RDBMS | |
|---|---|---|
查询语言 | HQL | SQL |
数据存储 | HDFS | Raw Device or Local FS |
执行 | MapReduce | Excutor |
执行延迟 | 高 | 低 |
处理数据规模 | 大 | 小 |
索引 | 0.8版本后加入位图索引 | 有复杂的索引 |
总结：
hive具有sql数据库的外表，但应用场景完全不同 hive只适合用来做批量数据统计分析
数据同步
谈到关于数据同步的问题，相信很多好学的朋友有疑问了?
为啥这个项目不用Sqoop来进行数据的同步？
相信看完下面Kettle与Sqoop差异对比的表格就清楚了。
功能 | Kettle | Sqoop |
|---|---|---|
领域 | 数据抽取、转换、加载 | 关系型与非关系型数据库数据迁移 |
输入 | 关系型数据库、HDFS、Hbase、Excel、HL7、JSON、RSS、文本文件、等等 | 关系型数据库、非关系型数据库 |
输出 | 关系型数据库、Hbase、HDFS、Excel、CSV、等等 | 关系型数据库、非关系型数据库 |
Hadoop集成度 | 外部工具，需要安装对应版本的插件，仅支持流行的Hadoop发行版 | 属于Hadoop生态圈，启动即用 |
适用数据量 | 十万、百万、千万级 | 亿级 |
支持系统 | Linux、Windows、Unix | Linux |
交互 | 有图形界面 | 没有图形界面 |
底层 | 多线程提高效率 | MapReduce |
在这个项目阶段一开始的时候，就介绍了，咋们这个项目的每日订单量为10W，按照上图表格所述，确实不太适合 支持系统单一，交互无图形化界面，底层计算效率低的 Sqoop。
当然也并不是说Sqoop没用，当数据量真的达到亿级别之后，Kettle就无法发挥它的优势，这个时候我们就只能借助于Sqoop了。
计算模型
每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层，数据运营层、数据仓库层和数据服务层。基于这个基础分层之上添加新的层次，来满足不同的业务需求。
数仓分层通过数据分层管控数据质量，需要对数据清洗等操作，不必改一次业务就需要重新接入数据，每一层数据都是单独的作用，同时规范数据分层，减少业务开发、直接抽取数据。
其中
数据运营层ODS存储着数据源同步过来的数据
数据仓库层DW需要对ODS层数据进行预处理（数据过滤，数据填充）
数据服务层存储最终结果
结果存储
通过上面的分析，在Hive中ADS层负责存储着结果数据，可以根据用户需求，利用简易sql而查询出最终结果。而数据源来自MySQL，我们自然也可以选择将结果存储至MySQL当中。数据同步组件根据实际情况选择Kettle或者Sqoop。
加速查询
Kylin 是一个 Hadoop 生态圈下的 MOLAP 系统，是 ebay 大数据部门从2014 年开始研发的支持 TB 到 PB 级别数据量的分布式 Olap 分析引擎。其特点包括:
✔ 可扩展的超快的 OLAP 引擎
✔ 提供 ANSI-SQL 接口
✔ 交互式查询能力
✔ MOLAP Cube 的概念
✔ 与 BI 工具可无缝整合
Kylin 的核心思想是利用空间换时间，在数据 ETL 导入 OLAP 引擎时提前计算各维度的聚合结果并持久化保存。
在离线数仓项目中，我们使用Kylin对Hive的ADS层的数据进行预处理，并将结果写入到HBase，提高了实际应用场景对于Hive数据表的查询效率。
结语
关于大数据离线数仓项目的总结，暂时就先更到这里…后期博主可能会对此进行更详细的补充，敬请期待?
如果以上过程中出现了任何的纰漏错误，烦请大佬们指正?
受益的朋友或对大数据技术感兴趣的伙伴记得点赞关注支持一波?
