大数据实战【千亿级数仓】项目总结

        前段时间作过一个大数据离线数仓的项目，先后花了有好几周的时间。一共是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、HL七、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数据表的查询效率。

---

结语

        关于大数据离线数仓项目的总结，暂时就先更到这里…后期博主可能会对此进行更详细的补充，敬请期待????

        若是以上过程当中出现了任何的纰漏错误，烦请大佬们指正????

        受益的朋友或对大数据技术感兴趣的伙伴记得点赞关注支持一波????