一、 大数据分析与处理
　　1. 文件批处理
　　以MapReduce、Hive为典型代表， 批处理模式解决了传统的数据仓库无法处理海量数据的难题。通过批处理计算引擎，使得海量数据分析成为可能。没有批处理引擎的诞生，也没有风风火火的大数据。
　　数据通常积累达到一个周期后定期运行， 也是所谓的T+1数据，即典型的T为，即数据延迟。
　　批处理的业务通常一次可以计算很大量的数据，但对计算的时效性要求不高，通常来说一个HiveSQL可以轻松处理几T的数据，运行时间从几分钟到几小时不等，如果是百亿规模的数据分析时间可能会达到数个小时。
　　2. 内存批处理
　　以Spark与Impala为典型代表，内存批处理与基于文件批处理很类似，只不过由于数据的处理过程中数据放在内存里（甚至原始数据也在内存里），由于内存的读写速度远远高于磁盘的读写速度，所以一般内存批处理系统的查询计算速度远远高于文件批处理系统的计算速度。
　　但是内存系统的缺点也是不言而喻的，内存在当今的硬件时代还是比较昂贵，而大数据领域的数据又都是比较庞大的，所以成本还是比较高昂的。
　　3. 流计算
　　全量数据处理使用的大多是鼎鼎大名的Hadoop或者Hive，作为一个批处理系统，hadoop以其吞吐量大、自动容错等优点，在海量数据处理上得到了广泛的使用。但是，Hadoop不擅长实时计算，因为它天然是为批处理而生的，这也是流计算系统（实时处理系统）诞生的意义，实时系统以Storm与 SparkStreaming为代表。Apache Storm为知名，阿里也在Storm的基础上重新用java重写了Storm，命名为Jstorm，并且又重新贡献了给Apache社区。
　　流计算系统的特点
　　低延迟。既然是是实时计算系统了，延迟是一定要低的。 时效性非常好，一般采用Kafka消息队列的方式导入，时效性可达几秒可见。
　　高性能。
　　指标预计算：预先将需要查询的数据计算好，查询的时候直接使用预计算好的结果，性能非常高。
　　分布式。系统都是为应用场景而生的，如果你的应用场景、你的数据和计算单机能搞定，那么不用考虑这些复杂的问题了。大数据所说的是单机搞不定的情况。
　　可扩展。伴随着业务的发展，我们的数据量、计算量可能会越来越大，所以希望这个系统是可扩展的。
　　容错。这是分布式系统中通用问题。一个节点挂了不能影响我的应用。
　　缺点：
　　无法查看明细数据：
　　只能看特定粒度的汇总结果，而过车记录是无法先计算出来的，即无法预知那个车有可能会犯罪，那个车会出事故，故无法预计算。
　　4. 预计算分析
　　全量数据处理系统，存在的主要问题是查询性能太差，也无并发性而言。 为了解决查询延迟问题，很多离线系统的做法是预先将每天要分析统计的指标计算好，存储在一个可以高速访问的系统里面如HBase或者传统数据里面，供报表系统进行展示，供常规多维分析使用。
　　随后发现这类需求有一共性，企业针对每种业务都单独写一遍Hive SQL ，再导入到传统数据库里面，再供报表系统查询。很麻烦，而且这类的需求很多，所以业界出现了很多预计算系统，主要目的是将业务进行预先计算，供业务进行访问，主要特点是使用非常便捷，极大的缩短的程序开发的时间，提升了开发效率，有的甚至将离线计算与流计算进行了结合，提供了更加实时的报表功能。
　　业界典型的产品代表，莫过于Apache   Kylin。Kylin是为减少在Hadoop上百亿规模数据查询延迟而设计
　　lHadoop ANSI SQL 接口:
　　Kylin为Hadoop提供标准SQL支持大部分查询功能
　　l交互式查询能力:
　　通过Kylin，用户可以与Hadoop数据进行亚秒级交互，在同样的数据集上提供比Hive更好的性能
　　l多维立方体（MOLAP Cube）:
　　用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体
　　l与BI工具无缝整合:
　　Kylin提供与BI工具，如Tableau，的整合能力，即将提供对其他工具的整合
　　5. 即席分析
　　预计算系统可以有效的解决数据查询的响应时间问题，但是现实中有很多数据是无法实现预计算的，或者预计算的代价是非常昂贵的，一个几万列的大宽表，各种维度笛卡尔组合后的结果集甚至比原生数据都多好多倍，如果用户在来个模糊检索，预计算的指标值多的简直是不可想象的。只有那些预先知道的场景可以使用预计算，有些场景是无法预先知道的，也无法进行预计算的。
　　即席（Ad Hoc）查询与分析是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。
　　在一个即席分析系统里面，用户的查询条件不再像预计算系统那样受限，检索、统计、排序等都根据用户的意愿去查询，查询的列数也不受任何限制，可以是一个维度也可以是任意维度的组合。
　　“即席分析”源于互联网公司对海量数据的即时性分析，后台系统和数据分析师通过不断地对海量数据进行探索性的查询与分析，挖掘大数据潜在价值，是互联网公司将数据变现的重要手段。
　　随着大数据在各行各业的应用，越来越多的行业客户对即席分析有着强烈的需求，要求能够对千亿甚至万亿规模数据进行高时效性地分析挖掘，这也是衡量各行业大数据应用水平的关键尺度。
　　事实上，我们已经看到，即席分析必将成为大数据生态中的为典型的需求场景之一，而延云的目标是成为大数据即席分析领域的标准。
　　一个典型的即席分析系统应该具备如下特征
　　1.数据实时导入，秒级可见
　　2.任意维度组合的多维分析，维度组合不受限。
　　3.即席查询：想查什么查什么，秒级响应，不应该受束缚。
　　4.模糊检索：可以像百度那样快速的搜索，匹配。
　　6. 探索性、验证型分析
　　当我们对大数据以及大数据分析完全没有头绪，当我们拿到数据应该怎么做呢，如果不知道怎么做，那先进行探索性分析吧。
　　探索性分析，实现我们并不知道需要查什么？那是探索性先查一下，看到数据后，有可能会激发下一步的想法，再进一步的查询，直到分析出问题所在。
　　探索性分析直观的场景的是通过日志分析BUG，一开始我们并不知道BUG在什么地方，而是先搜索下日志，了解下程序运行的一个概况，可能会意外的发现某个节点有异常，然后在深入的了解这个有异常的节点的日志，直到追查到BUG所在。
　　探索性分析在公安破案检索场景也是十分有效的，很多时候公安行业破一个案子，但是并不知道谁是嫌疑人，那么可能会先搜索出与案件相关的时间、地点、人物等进行碰撞，如果碰撞到一些有价值的线索，会在碰撞的结果上进一步追踪，根据各种线索与规律匹配到犯罪嫌疑人。
　　设想一个使用场景，我们的美女数据分析师，她有一个新的想法要验证。要验证她的想法，需要在一个上亿条数据上面，跑一个查询，看看结果和她的想法是不是一样，她可不希望等太长时间，好几秒钟结果出来。当然她的想法不一定完善，还需要不断调整条件。然后她验证了想法，发现了数据中的价值。后，她可以将这个语句完善成一个长期运行的任务。