浅谈大数据业务处理流程

大数据业务处理根据数据形式可分为“离线数据”与“实时数据”。
“实时数据”也就是要即时反馈的数据，如购物平台的推荐系统：猜你喜欢，买了又买、客户评价、物流信息等，这些数据是根据用户当前的行为做出的及时反馈及展示，因此叫“实时数据”。
相对应的，“离线数据”的实时性要求没那么高，一般存在隔天更新的：如酷狗音乐的“每日推荐”，是在每天的24：00更新的；或是按业务需求更新：如“喜马拉雅FM”上的书单信息、购物平台上的商品信息等。

离线数据处理流程

离线数据处理一般经过：数据采集 ，数据处理，数据存储。
其实不管是离线还是实时，数据存储完成之后，为了数据的分析、可是化查看，还要进行二次转存。

总结
一般情况下，采集来的离线数据，是不会直接被处理掉，而是形成日志、行为数据等分析好的包，也就是数据要经过处理，才能上传到互联网数据中心IDC（也就是机房）。

1、数据采集

数据一般可通过日志、埋点、第三方、外部数据等方式获取。而埋点一般是指Web/App端想通过日志获取的数据技术上存在一定的难度。这里所谓的难度，需要根据开发同事反馈确定：如想要获取用户订单数、或是歌曲播放量等信息，通过日志就能很容易获取，这时候就不必埋点，但是要获取视频的播放时长、页面点击等操作信息，日志获取就有一定的技术难度，如果业务分析中需要展示这部分数据，那么就需要设置埋点来获取。

数据在上传IDC（机房）过程中，会存在一些异常情况，如：
1）没有正确写入
2）网断、系统崩溃
3）重读读
4）机器重启
… …
这时候就需要日志回滚，对于还没标记(.bak：日志读完的标记)、也就是还没读取完的日志，会被删掉，然后重新读取，这也是比较原始，甚至可以说是比较笨的一种处理方法。

2、数据处理

数据采集完之后，就到数据处理，这里就会涉及到Hadoop(Hadoop是一个由Apache基金会所开发的分布式系统基础架构)。
数据的处理主要涉及到Hadoop的三驾马车：HDFS、Mapreduce和YARN。

2.1、HDFS

Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统（Distributed File System），为Hadoop海量的数据提供了存储依据。

2.2、Mapreduce

Mapreduce为Haddop海量的数据提供了计算的依据。
最简单的 MapReduce应用程序至少包含 3 个部分：一个 Map 函数、一个 Reduce 函数和一个 main 函数。
如果把数据处理比喻成做配料，那么一开始传来的源数据就是原料：洋葱、辣椒、姜等；而Map函数就是映射，把配料准备好：把洋葱、蒜头等区分开来并剁碎；而Reduce 函数就是按业务需求重新合成：按照需求把洋葱、蒜头等按一定比例搭配在一起；main 函数将作业控制和文件输入/输出结合起来。

2.3、YARN

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

实际处理业务时，同时会有多个业务线、也就是多个Mapreduce在处理事情。

3、数据存储

说到数据存储，就涉及到Hive与Zookeeper，后面还有一点关于数据仓库与数据库的知识，有兴趣的伙伴可以继续往下看。

3.1、Hive

3.1.1、Hive的定义与操作原理

Hive 是基于Hadoop 的一个数据仓库工具。

1）可以将结构化的数据映射为一张数据库表
2）并提供HQL(Hive SQL)查询功能
3）底层数据是存储在HDFS 上
4）Hive的本质是将SQL 语句转换为MapReduce 任务运行
5）使不熟悉MapReduce 的用户很方便地利用HQL 处理和计算HDFS 上的结构化的数据，适用于离线的批量数据计算。

上面提到Hive的本质是将SQL语句转换成MapReduce任务运行，为啥不直接使用MapRedue呢？

直接使用MapReduce 所面临的问题：

1）人员学习成本太高
2）项目周期要求太短
3）MapReduce实现复杂查询逻辑开发难度太大

为什么要使用Hive：

1）更友好的接口：操作接口采用类SQL 的语法，提供快速开发的能力
2）更低的学习成本：避免了写MapReduce，减少开发人员的学习成本
3）更好的扩展性：可自由扩展集群规模而无需重启服务，还支持用户自定义函数

3.1.2、Hive在架构中的位置

在大数据架构中，数据流一般如下图：
1.通过ETL工具将数据源抽取到HDFS存储；
2.通过Hive清洗、处理和计算原始数据
3.Hive清洗处理后的结果，如果是面向海量数据随机查询场景的可存入Hbase4.数据应用从HBase查询数据；

3.1.3、使用Hive处理数据的优缺点

优点：提供SQL查询、SQL语句到下面转换成一个Mapreduce的任务运行，包括对数据进行提取、转换、加载，也就是ETL。
缺点：只适合用来做海量离线数据统计分析（所有Hadoop都是离线操作），也就是数据仓库。如音乐推荐，隔天（T+1）才出音乐推荐榜单。

3.2、Zookeeper

数据处理完后，需要存储到IDC(机房)的时候，所谓的机房，不可能只有一台机器，而是多台机器的相互配合工作，这时候就需要zookeeper来做配置管理。

ZooKeeper是Hadoop的正式子项目，它是一个针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
简单粗暴一点理解就是：把机房里面的东西做一个统一集群，然后给用户提供分布式应用程序。

到这里，离线的数据处理存储就算完事了。下面补充介绍下数据仓库与数据库，数据的存储是放在数据库和数据仓库的，前面提到的Hive就是一个数据仓库。但数据仓库到底是什么，数据仓库与数据库又有什么区别？有兴趣的伙伴可以继续往下瞅瞅。

3.3、数据仓库

3.3.1、数据仓库定义

数据仓库（Data Warehouse）简称DW或DWH，是数据库的一种概念上的升级，可以说是为满足新需求设计的一种新数据库，而这个数据库是需容纳更多的数据，更加庞大的数据集，从逻辑上讲数据仓库和数据库是没有什么区别的。

3.3.2、数据仓库的特点

1）数据仓库是面向主题的

操作型数据库的数据组织是面向独立事务的处理任务，各个业务系统之间是分隔独立的。而数据仓库的数据是面向主题的，通过一个个主题域将多个业务系统的数据加载到一起。

2）数据仓库是集成的

数据仓库系统需要将多处的数据源通过一定的规则进行抽取和清洗，并最终加载到数据仓库中过程中必须消除数据的不一致性。

3）数据仓库的数据是相对稳定的

操作型数据库事实上并不过于注重历史数据，但数据仓库的数据是为企业数据分析而建立，所以数据被加载后一般情况下将被长期保留。

4）数据仓库更注重读

数据仓库中的数据一般仅执行查询操作，很少会有删除和更新。需定期加载和刷新数据。

5）持续的项目

数据仓库并不会像一个独立项目一样的由始至终完结，它从开始建立起就需要不断的维护。很多企业会选择先面向某个主题建立数据集市，在通过一个个数据集市组成完整的数据仓库。

3.3.3“数据仓库”与“数据库”的区别

对于初学者，在这里我们需要注意把“数据仓库”和“数据库”区分开来。

1）数据库（DB）的操作

一般称为联机事务处理OLTP（On-Line Transaction Processing），是针对具体的业务在数据库中的联机操作，具有数据量较少的特点，通常对少量的数据记录进行查询、修改。

2）数据仓库（DW或DWH）的操作

一般称为联机分析处理OLAP（On-Line Analytical Processing），是针对某些主题（综合数据）的历史数据进行分析，支持管理决策。

3）从物理概念上理解

数据库是实实在在的、存储在内存或磁盘上的表。而数据仓库是从数据库中抽取要分析的表，打散、关联、重新组合成虚拟逻辑上的表，它没有一个实际存放的东西。

4）从逻辑概念上理解

数据库就是存储数据的仓库，是面向事务的，主要有关系型数据库和非关系型数据库。里面的数据有结构化数据、半结构化数据、和非结构化数据。
从逻辑上来理解，和数据库的概念一致，都是存储数据的仓库，只是数据仓库的数据量更大。
但数据仓库是面向主题的。啥是面向主题呢？比如说现在要查看、分析过去2年、某个年龄段、某个区域的用户购买某些商品信息。那么这就是一个主题，是针对某些方面来分析问题。这会它就需要建立维表和事实表从数据库中抽取数据，如地区维表、年龄维表、商品维表等。事实表：某某用户在什么时候购买了什么商品等。

4、二次转存

数据存储完之后，还不算完事，为了数据的可视化展示，需要对数据做二次转存。
常见的关系型数据库有：orcle、mysql等，上面提到的那些处理完的离线数据，能不能直接放在在mysql、orcle中呢？理论上是可以的，但是不推荐这么做，原因如下：
1）压力大：如果真的存进去，orcle、mysql等关系型数据库的压力会很大，处理完的数据不能保证为完全的关系型数据，如车联网中的记录的车辆轨迹，这就是非关系型数据。这里我们需要明白一点，离线数据并不等于结构化数据，它同样包含半结构化与非结构化数据。
2）数聚量庞大：每天会有5T、10T的数据吃进来，mysql估计一下子就爆掉了，计算能吃得下，频繁的操作（读取），mysql也是hold不住的。
因此，数据的二次转存只能往Nosql里面存放。Nosql有以下特点：
1）支持海量数据
2）存进来的数据不会丢
3）支持计算

4.1、 Hbase

HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”
HBase Hadoop是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。【百度百科】

4.1.1、Hbase运行逻辑：

对于数据的二次转存，Hbase其实是扮演着一个存储空间的管理。
1）Hbase其内部用的还是HDFS作为其文件存储形式。换言之，HDFS为HBase提供可靠的、底层的文件存储模式；
2）HBase同样使用MapRedue处理数据，也就是MapRedue为HBase提供计算能力；
3）Hive为HBase提供高层语言支持；
4）zookeeper为HBase提供分布式稳定服务。

实际运行中，Mapreduce处理好的数据可以直接往HBase存放，或是通过Hive、mysql再传往Hbas。
当数据超大时，Hbase也会吃不消，有些公司会在HBase外面加一层ES（Elasticsearsh），提供二次索引。搜索速度将提高十多倍，额外提示下，ES可视化工具很好用，有兴趣的小伙伴可以去了解下。

实时数据处理流程

1、在线数据的采集跟离线差不多，但实时数据没有落地与存储的操作，它的计算引擎前几年使用Spark，最近流行使用flink。

2、实时数据多时，需要考虑建池来缓冲，这就用到kafka，也就是消息队列。大量数据存储到kafka，从后面进、从前面出。

3、不管是离线数据还是实时数据，处理、存储完了还不算完事，还需要做二次展示、可视化查看。

4、实时数据库有两种：MongDB、Redis。

5、实时数据为啥不用HBase呢？原因如下：
1）spark、flink本身不是一个数据存储的东西、它不是读写HDFS，对HBase支持性不好；
2）Redis专门做一些实时化数据库，速度很快，每一秒能执行十几万条数据，MongDB 、Redis对数据的实时性支持很好。他们的数据是存储在内存而不是磁盘，内存的数据读取要比磁盘快很多。