一、大数据是什么？

大数据是通过传统数据库技术和数据处理工具不能处理的庞大而复杂的数据集合。
大数据不等于数据大
一般人认为的数据量大，并不是大数据中的数据量大，例如100万行以内的数据，用EXCEL处理就很好。**注意：EXCEL的处理能力大约为100万行。**最近英国就曾出现用EXCEL处理远大于100万的新冠病例而造成数据丢失的情况。

（一）大数据的特征——4V：

（1）规模大（VOLUME）。
（2）速度快(VELOCITY)——能快速处理的能力，例如：微博每秒3万条、淘宝每分钟5万订单。
（3）类型多（VARIETY）——传统数据库一般处理结构化数据，例如：身份证号、手机号、姓名…大家的身份证号都一样长；而大数据只要处理非机构化的数据，例如：视频、音频、爬取的网页…
（4）价值密度低（VALUE）——少量的数据的价值不是很大，大量的数据的价值才比较高。例如：一个人购买了一台笔记本电脑后又买了一套鼠标和键盘，这件事是对于商业来说是没多少价值的，因为另外一个人买了一台笔记本电脑后可能又买了一件衣服，我们不能通过少量的数据得出一个人买了电脑后继续购物的规律。当然，某个单独的数据，对于某些人来说也是有用的，例如，A知道B买了一台适合打游戏的笔记本电脑之后又买了适合打游戏的键盘、鼠标、耳机、座椅，A可以推测B买电脑主要是为了玩游戏，甚至可以大胆猜测B今后可能会花大量时间呆在宿舍玩游戏、B今后可能很少去网吧。

（二）大数据与传统数据库的区别

传统的数据库数据量变大了，并不是大数据。例如：一个小商店用Oracle数据库存了10万条数据，若干年后这个小商店发展成一家大型连锁超市了，它还是用Oracle数据库，但是数据量达到10亿级别了，这个不叫大数据，因为它还是使用传统的Oracle数据库

（1）传统数据库的特点（以交易、银行转账为例）：

（1）随机：今天哪一个用户、什么时间、会来办什么业务不确定。
（2）高并发：同一时间好多人都在办业务。
（3）小规模：单次处理的数据比较少。例如：A给B转账100元，数据库执行A账户余额减100、B账户余额加100、提交事务（类似于保存）共三步，涉及的数据规模很小。
（4）面向事务：一系列的操作要么都成功，要么都不成功。例如：A向B转账，只能出现要么A的账户余额减少且B的账户余额增加相同数值，要么A和B的余额都不变，不能出现A账户的余额减少了，而B账户余额没增加或者A的账户余额没变而B的账户余额增加的情况。
（5）读：有大量、频繁的读操作。
（6）写：有大量、频繁的增、删、改操作。
（7）更多是一行一行的操作。
（8）对时效性要求较高：例如：在超市购物用手机支付，应当在1秒内完成，若是需要1小时，还不如用现金呢。

事务

事务是一系列操作的集合，要么这些操作全都执行成功，要么全都不执行。例如：A给B转账100元，数据库执行A账户余额减100、B账户余额加100，如果A账户余额减100执行成功后，突然停电或者数据库崩溃了，B账户余额加100的操作未执行，则要么将A账户余额减100的操作回滚使A账户的余额不变，要么将当前状态记录下来，等数据库恢复后继续执行B账户余额加100的操作。反正不能出现A账户余额减少了，B账户余额没增加的情况。
事务的特征：
A（原子性）：一系列操作，要么都成功，要么都不成功。
C（一致性）：数据保持一致。
I（隔离性）：事物的中间状态对外界不可见。以转账为例，客户查询余额，要么只能看到A与B账户余额变化前的状态，要么只能看到A与B的账户余额都发生变化后的状态，不能看到A的余额发生变化但B的余额还没变化的状态。
D（之久性）：事务执行完会对数据库中的数据产生永久性的影响，除非用户对事务涉及的数据执行对数据的修改和回滚操作，否则数据是不能更改的。

（2）大数据的特点——以数据分析/挖掘为主

（1）数据规模相对较大。
（2）实时性要求不是特别高。
（3）更多是一列与其他列之间的关联。

处理数据思想的改变

以前是以小规模数据，通过复杂的算法获得规律或结论。大数据以大规模（甚至是全量的）数据，通过简单的算法获得规律或结论。
我们可以只关心“是什么”，而不关心“为什么”。有时通过大量数据分析得到的结论只是表象或者是间接原因，而不是直接原因。例如，以前有人进行过大量统计，发现经常喝红酒的人寿命比较长，于是得出结论“喝红酒有益健康”，但事实是在那个年代能经常喝红酒的人都是有钱人，他们能享受到更好的医疗条件。

二、大数据实施

大数据的实施步骤

步骤	参与人员	主要内容
业务理解	业务人员、技术人员	指定业务需求、业务目标、大数据挖掘目标。
数据理解	技术人员	基于业务理解，利用各种分析方法、工具，对数据仓库中的数据进行理解。
数据准备	技术人员	基于前面步骤，从数据仓库中抽取建模所需的数据 ，并转化为模型所需要的格式。
建立模型	技术人员	基于前面步骤，选择数据挖掘方法进行建模。
模型评估	业务人员、技术人员	技术人员根据模型的关键指标统计数据确认模型是否可行，业务人员从业务角度出发判断模型是否可用于营销。
模型发布	技术人员、业务人员、营销人员	业务人员确定可以用于营销的模型结果，业务人员、营销人员确认营销脚本，技术人员推送派单数据，统计结构、进行评、调整模型，最终形成闭环。

大数据实施过程中可能最麻烦、花费时间最多、并有可能影响分析结果准确度的步骤是数据准备。数据准备时要确定不同系统中名字不同的对象是否是同一个，例如：在对《三国演义》中人物名字出现的次数进行统计时，要把“关羽”、“关公”、“云长”视为同一个人。
你眼中的大数据——数据提取–>建立模型–>深度学习、人工智能——一周可以完成
实际上的大数据——需求讨论–>数据提取–>数据清洗–>数据整合–>缺失值处理–>特征工程–>模型评估–>返回某个环节再来一遍–>分析结果

三、大数据与传统业务的区别与分工

传统数据库

优点：安全、稳定、强一致性，对事务的支持
缺点：性能欠佳
应用场景：核心的业务、交易类的业务

大数据

牺牲了：一定的安全稳定强一致性、对事务的支持
换取了：高性能、分布式、弹性（可扩展性）
应用场景：大数据分析、数据挖掘

四、大数据用到的技术

（一）Hadoop的三个组件

HDFS——存数据

HDFS把数据存到多台计算机上，

MapReduce——算数据

MapReduce把一个大的任务交给多台机器做离线计算、批处理（数据放在硬盘中，一批一起处理）。
还有像Storm、Spark、Flink等是实时计算、流处理（数据放在内存中，随着数据的产生，产生一个就计算一个）

Yarn——任务调度、资源分配

（二）Hadoop的设计思路

（1）把多台机器当作一台来用，自动把数据/任务分配到多台机器，用户不需要关系分布式问题，只需要关系业务逻辑怎么实现。
（2）认为硬件是不可靠的、单一硬件的性能不够；多台机器高度冗余。即同一份3数据存在至少3台机器上、多台机器同时算一个任务

（三）Hadoop的大致架构

1、HDFS——分布式文件系统。解决存的问题

Hadoop不是一台服务器而是一堆服务器，大致分为2类：NameNode和DataNode。
HDFS适合大量数据大文件，不适合小文件，文件小了反而体现不出优势，文件越大优势越明显。Linux中一般4K/块、Oracle一般8K/块、MySQL一般16K/块，HDFS一般128M/块。

NameNode——存放的是元数据，即文件的属性（文件名、位置、权限等）

整个集群的出入口，客户端访问都找NameNode。
SecondaryNameNode：**不是NameNode的备份，而是帮NameNode加速。**假设客户端A要将“1.txt”存入HDFS，NameNode中存放的是“1.txt”的元数据（可以想象为书的目录），这个存储过程又分为2部分：fsimage和editlog。其中fsimage存的是元数据，editlog存的是记录操作。当客户端B要将“2.txt”存入HDFS时，不是直接修改fsimage，而是把操作记录在editlog。 SecondaryNameNode会定期从NameNode拿到fsimage和editlog，然后合并起来、返回给NameNode。可以想象一下，有一个1000人的工厂，某天张三迟到了，老板有两种方法记这事：第一种，在考勤表上依次查看每个员工的名字，找到张三后再后面标记上迟到；第二种，在本子上记上张三迟到这件事，先去忙别的事，等闲的时候再在考勤表上找到张三在后面标记上迟到。如果一天有好几个员工迟到，用第一种方法记录会造成排队。
如果怕NameNode坏了，可以再搭一个NameNode，然后用HA连接2个NameNode。

DataNode——存放数据（切块3副本）

将一个大文件切成很多小块，每一个小块在至少3台服务器上存一样的内容（即每台机器互为另外两台的备份）。
每一台DataNode服务器的配置不需要很高，甚至可以用旧电脑。因为数据太大了，单台服务器的性能就算再好也处理不了，任务是分给很多服务器一起来做，每台服务器的任务量很小，对服务器的性能要求不高。NameNode的配置还是要高一点，因为NameNode是整个集群的出口和入口。
NameNode和DataNode没必要每个单独占一台服务器，甚至可以都放到一台机器上。

2、MapReduce——大任务拆分成多个小任务，分派给多个机器进行运算

Map——大任务拆分成多个小任务，分派给多个服务器分别进行运算

Reduce——统一汇总，返回计算的结果

3、Yarn——多个任务怎么分配资源

标签：华润集团,账户,数据库,笔记,余额,NameNode,100,数据
来源： https://blog.csdn.net/agepower1989/article/details/123450469