我看到有些人，到现在其实对大数据到底是什么？要做什么？怎么做？（其实这是哲学的经典的三个问题，遇到问题，都从这些问题出发，对自己还是有好处的）其实都还不是特别清晰。所以我想说说我的理解，也许不是很准确，但是希望对大家有用。
一、为什么要用大数据？
首先，大数据的出现与普及，并不是因为概念啊，噱头之类，而是因为实际生产中，遇到了大量数据无法处理的问题。这些问题才是让大数据技术蓬勃发展的土壤。
其次，我们是不是一定要用大数据生态圈的东西？现在很多人的误区是，为了大数据而大数据（包括一些公司，可能就是为了蹭点热点）。我们要用什么怎么用，其实都是根据业务来的，根据需求来的。对于同一个问题，我们可能会用到hdfs、spark、flume这些通用性轮子等等，但是有些牛逼的架构师，会根据业务需求，可能会自己造些更适合的针对性更强的轮子来解决。其实当你每次都从需求角度出发，从业务角度出发考虑问题的时候。你对大数据生态圈里的数十种组件也就不会那么迷茫了。
总之，大数据就是解决数据量大的问题，只要你明白数据流转的整个过程，然后针对这个过程，去选择相应的组件就够了。也许是和网上流传的通用架构一样，也许根本没有用到几个大数据生态中的组件，但是这都没有关系，只要能解决问题，有一定的拓展性，就够了。
二、大数据是做什么的？
简单来说，大数据就是为了处理数据的。我认为主要是四个步骤，这些名称都是自己想的，可能和一些主流的说法不太一样，但是我会在说明中，尽量解释清楚。
源数据存储——数据处理——目标数据存储——结果展示
（一）源数据存储：主要分为数据采集——数据清洗——数据存储三个步骤。
我个人认为数据采集是非常麻烦，而且不可预测因素最多的一个环节。在这里就不展开说了，简单的就是把我们需要的数据拿过来。
我在这里主要说几个概念，这些概念都不是大数据的专属，很多公司都在做，只不过手段不同而已：
（1）数据仓库、数据集市、用户画像、数据分层等虽然他们概念有很多的区别，但是他们都做了一件事情，就是把数据整合成我们想要数据，只不过程度不同而已
（2）ETL只是完成上述功能的过程的说法而已。具体如何etl 我不太清楚，但是我知道用hive、sqoop等都可以完成简单的etl。
（二）数据处理：我这里的数据处理，主要是指计算。
这里也说两个概念：
（1）离线计算：具体概念不解释了，主要讲一下工具：最传统的是MR，hive,spark等，除了计算以外，如何去做任务调度，也很重要
（2）实时计算：现在主流的storm，sparkstreaming，flink。storm的出现比较早，在传统架构中也应用比较多，但是拓展性稍差。sparkstreaming，微批处理。flink，实时处理，完成某些功能比sparksteaming更加便捷。后两种计算框架现在都比较流行。重点就是解决三类问题：1.如何保证消息不重、不漏。2、消息堆积了怎么处理？3、出现OOM如何处理（即实时流程中的某一个组件挂了，如何处理）？
（3）如何使用？
举个简单的例子。pv ，uv 的计算，你既可以用离线，也可以用实时，也可以结合起来。
那么为什么会将同一个计算，划分出实时和离线呢？都用实时、或者都用离线的不就好了？主要的原因有以下几点：
一是在实时这个概念上要区分和实时响应（对用户）和实时计算（对数据）的区别：如果在用户发起请求的时候，把所有的数据都计算一遍，那返回的一定是最准确的数据。但是计算需要时间，就做不到实时响应了。
二是离线数据有时间差，对于某些业务，过长的时间差是很致命的。
三是实时计算因为追求速度，所以在稳定性和准确度都没有离线计算高
四是实时计算对于处理复杂计算效果不够理想
所以最好的方式就是将实时计算和离线计算同时使用，这样会降低资源使用、人力成本和获得不错的稳定性和准确性
（三）目标数据存储
到了这一步，我们的数据已经可以用了。这个时候要考虑的就是存到哪里，怎么存？这个时候要根据业务数据量来决定，可以存到mysql 等RDBMS中，也可以存到HBASE、REDIS、MONGODB等nodql中。当然根据业务需要采取混合存储，也是现在非常常用的。
（四）结果展示
终于到了最后一步，我们的工作是不是就做完了？我现在已推荐系统为例，简单说一下整个的数据流程。
千言万语画成一张图。这就是一个简单系统逻辑（而不是架构），我为什么选择思维导图而不是流程图来展示这些。主要的一个原因是我想表达一个意思：最终的系统会根据业务和数据的形式，将上述数据流转的过程循环嵌套。就比如推荐系统的源数据是数仓。但是数仓本身的建立，也要经过数据流转的全过程。
以上就是我对大数据的一点看法。其中有些是为了表述简单，偷换了一些概念，有些是因为自身的原因，理解的不够准确（特别是数仓和数据集市的方面），如果有问题的，欢迎大家批评指正。
最后再补充一张通用架构图
