建立大数据技术体系学习的新思维

本文主要是介绍建立大数据技术体系学习的新思维，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一. 开篇

随着大数据时代的到来，各类数据都在惊人的增长，形成了WEB与社交媒体数据、机器对机器数据、大体量交易数据、生物计量数据和人工生成数据的五大类型。数据越来越不满足于处于静止状态，数据越来越处于流动中，时时刻刻都在反映着事件的发生，新的数据又在原始的数据之上生产。因此我们在学习大数据技术的开始，就需要用新思维去应对大数据技术带来的变化，迎接大数据时代的到来。

自从Hadoop成为大数据热的起点，到现在各种大数据技术框架如雨后春笋般不断兴起，Spark、HBase、Hive、Kafka、Elasticsearch.......，我们仿佛进入到了一个新的技术天地，感觉不会点这类技术，都不好意思说自己是搞科技研发的，但是又感觉这些技术与我们若即若离。因为这些框架工具本身是没有生命力的，而我们真正需要的是一种有生命力的思维逻辑，形成对大数据理念的理解、领会和贯通，需要在这种思维的引导下，就像手指捏住细线一样，小心翼翼将其中的道理串在一起。

大数据的继承关系图

看到上面的一张来自谷歌体系的大数据存储的基因继承关系图。我相信大家要想全部掌握对应的开源技术，估计得花上几年。因此我们对大数据的掌握，一定是根据现阶段的需求，选择最需要掌握的部分。但如果我们对其本质思想的理解，那么无论是那种技术的掌握，都是顺其自然的事情。

二. 大数据模型的本质

第一条数据尽量是原始的

数据库里的数据尽量是原始数据。这个问题乍一听，有些不可思议的。我们做了那么多年的关系型数据结构，不都是先定义好表模式（schema），然后再定义好数据类型字段，通过我们的程序服务，接收各种应用界面的数据输入，提交，转换（convert）并储存成最终想要的结果吗？

怎么到了大数据模型的时候，就需要我们存储的是原始数据了呢？看看下面的关键回答：

我们很少能在设计之初就想好所有的答案。当对原始数据进行汇聚、过滤、修改和删除的时候，我们也就在缩小数据能提供的答案范围
往往我们要存储PB和EB的数据，被称之为海量数据，我们无法短时间内为这么海量的数据充分建立解答思路
只有通过保存好原始数据，才能为我们留够充足的时间去施展我们的能力，找出数据中的更多答案

上面的三句话其实就是大数据模型本质的初衷。

简单点理解，就是在告诉大家，现代数据的产生可能是每秒、每小时、每天都成奔涌之势向海量存储的终点汇聚，例如：手机APP在应用里的各种操作，一个点击，一个滑动的日志事件都会被采集到服务端，大家可以想想如果只有十几万的移动在线用户数，这种操作一天下来要存储不少的日志事件数据，更何况热门级APP，上亿用户的存在，数据流是个怎么样的天文数字！

短时间内，APP产品分析和设计人员也不知道这么大量的操作日志在到底能干什么用，至少数据利用的考虑不会充分，而且随着变化，数据价值的利用也在变化，但谁也不敢说这些数据现在没用了，也许过一段时间，作为广告分析的一个新模型也许就又起作用了。但短期内怎么办呢？最好的办法就是没有捋清楚拿这些数据干什么的情况下，先都存起来，日后慢慢挖掘出来做商业价值。这还只是当前和大家联系比较紧密的一个案例。再比如像机器设备发出的数据，例如各类传感器数据，那就更海的去了。

以前总是说ETL（抽取、转换、加载），在我们分析的时候，数据抽取到仓库的过程中就做转换，因为我们面向的是结构化过的数据，所以我们的转换都是预先设定好的逻辑，大量的信息在转换后就没有了，只是保留想要的那部分结构数据加载到数据仓库中。但是大数据模式下就变成了ELT，我们将数据抽取后先加载到大数据平台，日后慢慢转换成需要的二次加工数据。这在传统的数据仓库是难以想象的，因为大量原始数据存储到关系型数据库中，几乎无法让数据仓库有能力再执行批量的转换了，性能瓶颈无法避免，非结构化数据无法在关系表中有效表达。

第二条数据是不可修改的；第三条数据是真实的

数据不可修改，估计经常CRUD的程序员们，就会默默一问，大数据难道没有update记录的概念了吗？大数据的模式中，的确没有update记录这个概念，因为所有的数据作为事件一旦发出，就是事实，这也就提出了大数据模型本质另外的两个观点：不可修改，数据是真实情况的反映。

这有什么好处呢？

容忍犯错，传统可变数据模式，会导致发生错误的操作覆盖数据时，可能无法挽回。但是不可变数据模式，只是对增加新的数据单元进行修复，任何时刻的历史信息都是可获取的，最大限度的容忍人为错误。
简单化，传统可变数据模式，因为更新或删除操的需要，必须为数据进行必要的索引，便于获取数据，但是不可变数据模式，只需按照顺序增加数据，不用顾虑索引问题，不仅使得写入效率极大提升，也简化了存储的文件模型结构

大家可以试想一下，对于传统关系型数据库也好，键值数据库或有些文档数据库也好，都可以根据索引，进行记录的更新操作。其实不能称之为符合大数据模式的系统，因此不适合成为主数据集，而应是主数据集之上针对业务需要的部分数据集。在这种思路的引导下，简单化的优势显而易见，无索引，就无随机，批次顺序的读写。这种数据结构简单、牢靠、高性能且省资源。

Hadoop HDFS对大数据模型本质的极强表现力

大家看到这块，再想想Hadoop分布式文件系统HDFS的设计模式，顺序的写入文件块，顺序的读取文件块，没有索引，没有记录级更新，通过块的概念统一了所有结构与非结构化的文件数据类型。这不就是为了满足大数据模式的三个本质吗。

HDFS文件分块操作示意图

HDFS的设计思路：

超大文件存储-——储具有几百MB，几百GB甚至是TB大小的文件，避免大量小文件导致的读取效率和元信息的内存占用
高效数据访问——一次写入，多次读取的访问模式，长时间、多种类型的数据分析任务可以在整个数据集上查询进行，形成写入与读取之间的分离，提升读取效率
提高延迟为代价的吞吐优化——通过写入和读取分离，提升一次写入的数量，提升整体的吞吐量，低延迟考虑HBase的结合
集群容错——庞大的集群，节点故障的几率会变高，HDFS被设计成容错性，也就是继续运行不去中断

对于HDFS的结构和优势不是本文重点去说的事情，在此带出来它的特征，就是让我们能更清晰地认识到大数据其内在特质。理解HDFS的特点，就能引导我们去了解大数据体系的本质设计思路。

三．大数据存储到底有多少种模式

上面对分布式文件系统（HDFS）介绍，大家一定记住它的价值和作用，就是最基础的主数据集。另外我们还必须提出大数据平台关键的NoSQL生态体系，再列出一个表，看看还有哪些分类模式的NoSQL数据库。

存储模式	模式描述	模式应用
键值存储	一个简单的字符串和任意大小的blob文件关联的方式	字典、图像存储、文档/文件存储、查询缓存…
图存储	存储顶点和边的图关系	社交网络、朋友圈、知识库、推理、规则系统、模式匹配…
列族存储	通过行和列共同组成主键，才存储稀疏矩阵数据	网页爬虫数据、大型稀疏表、高度变化系统、高适应性系统
文档存储	对一组信息单元以树形结构分层存储	健康档案、销售订单、发票、产品描述、出版物、文档搜索…

通过这张表，我们可以看到除了作为主数据集担当的分布式文件系统（HDFS）之外，还包括了键值存储模式、图存储模式、列族存储模式、文档存储模式（还包括时序模式）。它们都是针对一种或者多种业务场景而存在，有的是基于HDFS，例如：列族的HBase，但大多数都是自成体系。

优势

键值模式：

精确的监控和通知，有了精确的服务级别，监控工具的使用变的方便
可扩展性和可靠性，键值存储非常易于建立，接口简单，更容易满足不同的可靠性和扩展性方案
可移植性和低操作性

图存储：

图存储的结构，连接操作是轻量和快速的
图存储的节点天然就很小，非常适合加载到内存中操作
基于BSP模型使得图处理具备了水平可伸缩的分布式能力

列族存储

更好的可扩展性，列族存储的设计是为了突破单个处理器的限制，列族不依赖连接操作，可以轻易地在分布式系统上进行扩展
高可用性，能在一个网络中多个节点复制数据的能力
易于添加数据，列族系统的一个关键特性是在插入数据之前不完全定义好数据模型，行ID和列名随时可以创建

文档存储

树形结构更适合表现出文档型数据的嵌套层次
在主索引和文档二级索引的组合，更容易构建丰富的查询和搜索功能
文档分片机制可以轻松实现分布式水平扩展，多个分片又能快速聚合查询结果

它们都有几个明显的相同点：对分布式水平伸缩性的天然支持，渴求对海量数据的承载，对非结构化数据以及对象数据的理想存储。

但是相对于关系型数据库，几乎也有共同的劣势，那就是支持事务强一致性支持的弱点（MongoDB是个例外），对记录间关系处理是个薄弱环节（图模式除外）。因此我们理解清楚大数据平台的这些NoSQL分类模式，就不惧那么多的框架技术，我们更重要的是去选择什么类型的数据平台方案去解决什么样的业务。

引用一段对NoSQL的重要描述：NoSQL的驱动力

容量：RDBMS在查询海量数据的瓶颈，迫使存储架构设计从规模向上扩展（更快的处理器）转变成规模向外扩展（分区分块），从串行执行转变为并行执行

速度：RDBMS频繁对新写入行进行新建索引操作，会影响系统性能，单处理器系统的快速读写在面向海量数据吞吐，成为了瓶颈。数据分区分块，多处理器并行处理，提升速度成为关键

四. 选择实时流计算还是批处理计算

举个简单的例子吧：互联网实名认证，早些年我们要做实名认证，就是在web页面填写一个表格，你的姓名、身份证，上传你的照片。设计者都是预先进行了关系数据表的设计，包括了姓名、身份证、图片blob等字段的设计，我们把这一个提交过程，成为联机事务（OLTP）。最终还是需要人工审核，用户得耐心等待。

过了一段时间，我们采用了比较先进的图像模式识别技术，我们不用再填表了，直接上传身份证，等待结果。那么在后端可能1小时，1天先存储个几个G的图像，然后几千张一批次的通过自动识别，将数据自动填入结构化表中，识别不了的，打入审核不通过数据表。这就是一种最简单的批处理计算了！

再过了一段时间，我们的设计者为了不让用户等待太长时间，增强用户体验和粘性，那么在用户提交图片的时刻，就开始做识别和分析了。后台经历了数据的排队，十几台流计算工具消费这些队列，并行识别图片，几秒中完成结果，通过消息推送系统返回用户应用端。这个过程就是最基本的一种实时流计算了。

又过了一段时间，根据需求增加了人脸识别功能，证明身份证上的你是真实的，当用户开始识别过程，系统就从主数据集获取到原始的身份证信息，针对手机拍摄人脸和身份证图像进行比对，达到最精确比对。

我们可以看到系统升级的历程，从关系型（OLTP）转变到批处理，再进化到实时流计算，用户等待时间越来越短，用户做的事情越来越少，系统表现越来越智能。这个例子想表达的意思就是告诉大家，大数据平台的价值一定是升级、优化、改进现有的业务模式，复用原始的数据集，解决新的问题。

对于什么时效算是实时流计算或是批处理计算，一样通过张表来做一个界定：

处理模式	时效性	适应系统
大型批处理	15分钟～数小时	Hadoop/Spark
小型批处理	2分钟～15分钟	Hadoop/Spark
近实时决策支持	2秒～2分钟	Spark/HBase/Elasticsearch/solr
近实时事件处理	100毫秒～2秒	Storm/Spark streaming/Flink
实时处理	100毫秒以内	Storm（存疑）

从上表可以看出，1个小时的处理，肯定是大型批处理任务了。尽量使用Hadoop来实现数据块的切分，Spark并行任务处理。

微批处理，主要还是在近实时事件处理中起作用，它们的模式和实时流处理的区别，就在于不是来一个数据处理一个，像Spark streaming那么就有个间隔，例如等500毫秒，对积攒的数据处理一次。

流式处理，很难达到实时——即100毫秒以内，几乎不可能，需要从硬件资源下手了，存储基本不能考虑磁盘来做。一般所说的大数据实时处理，其实都是准实时，也就是能在2-3秒处理一批次（微批次），2分钟内能见到最终统计决策结果，就能满足需要了。Storm可以做到来一个处理一个的效果，但是Storm仅仅作为计算，还要考虑流数据临时计算结果存储带来的延时问题。因此Storm最好的方案还是Apache Trident，其实还是微批处理，但保证了数据处理的可靠性以及计算的可回溯。

我们再从采集数据的批处理管道过程、实时流处理管道过程看看：

sqoop管道批量采集的两种模式

Kafka管道构建流式计算模式

从上面两张图中，我们能看到数据源可以定时的、按批次的进入大数据平台进行批量处理。数据源也可以实时推送的过程中，进行流式过滤、清洗和加工，再进入大数据平台或关系型业务系统。因此选择那种计算架构和方案，关键是看业务的需要，很大程度上，都是混合使用，传统关系型与大数据平台的混合，实时流架构和批处理架构混合使用。

五．数据驱动决策（DDD）

经过上面的种种描述，我们至少大体清楚了大数据平台的特征和价值。但是最终量变为质变的价值一定是数据驱动决策（DDD）

数据驱动决策（DDD）

通过数据驱动决策（DDD），大数据就成为了数据资产，且看对数据资产的关键性三段表述：

企业往往认为数据分析主要就是从现存的数据中发现价值，而往往忽视了企业自身是否有足够的分析能力
企业经常或缺乏合适的数据做最优的决策，或缺乏运用数据进行最优决策的能力，或两者并存
若将分析能力和数据视为战略性投资，就能清醒认识到该投入多少，往往能带来高回报

六. 结束语

通过我们对大数据模型本质的呈现，关系型模式与大数据模式的区别，大数据存储模式优势展现，批处理与实时流计算的能力界定以及数据驱动决策（DDD）对企业未来关键性作用描述。我希望能在读者心中建立一个全新的思维模式——大数据技术思维。我们只有在新思维新思想的有力助推下，才能以不变应万变的去适应当下各种大数据技术的发展。完成企业大数据的架构升级，完成企业数据资产化的新使命。