大数据分析的五个基本方面

1、可视化分析

大数据分析的使用者有大数据分析专家，同时还有普通用户，但是他们二者对于大数据分析最基本的要求就是可视化分析，因为可视化分析能够直观的呈现大数据特点，同时能够非常容易被读者所接受，就如同看图说话一样简单明了。

2、数据挖掘算法

大数据分析的理论核心就是数据挖掘算法，各种数据挖掘的算法基于不同的数据类型和格式才能更加科学的呈现出数据本身具备的特点，也正是因为这些被全世界统计学家所公认的各种统计方法（可以称之为真理）才能深入数据内部，挖掘出公认的价值。另外一个方面也是因为有这些数据挖掘的算法才能更快速的处理大数据，如果一个算法得花上好几年才能得出结论，那大数据的价值也就无从说起了。

3、预测性分析能力

大数据分析最终要的应用领域之一就是预测性分析，从大数据中挖掘出特点，通过科学的建立模型，之后便可以通过模型带入新的数据，从而预测未来的数据。

4、语义引擎

大数据分析广泛应用于网络数据挖掘，可从用户的搜索关键词、标签关键词、或其他输入语义，分析，判断用户需求，从而实现更好的用户体验和广告匹配。

5、数据质量和数据管理

大数据分析离不开数据质量和数据管理，高质量的数据和有效的数据管理，无论是在学术研究还是在商业应用领域，都能够保证分析结果的真实和有价值。大数据分析的基础就是以上五个方面，当然更加深入大数据分析的话，还有很多很多更加有特点的、更加深入的、更加专业的大数据分析方法。

如何选择适合的数据分析工具

要明白分析什么数据，大数据要分析的数据类型主要有四大类：

1、交易数据（TRANSACTION DATA）

大数据平台能够获取时间跨度更大、更海量的结构化交易数据，这样就可以对更广泛的交易数据类型进行分析，不仅仅包括POS或电子商务购物数据，还包括行为交易数据，例如Web服务器记录的互联网点击流数据日志。

2、人为数据（HUMAN-GENERATED DATA）

非结构数据广泛存在于电子邮件、文档、图片、音频、视频，以及通过博客、维基，尤其是社交媒体产生的数据流。这些数据为使用文本分析功能进行分析提供了丰富的数据源泉。

3、移动数据（MOBILE DATA）

能够上网的智能手机和平板越来越普遍。这些移动设备上的App都能够追踪和沟通无数事件，从App内的交易数据（如搜索产品的记录事件）到个人信息资料或状态报告事件（如地点变更即报告一个新的地理编码）。

4、机器和传感器数据（MACHINE AND SENSOR DATA）

这包括功能设备创建或生成的数据，例如智能电表、智能温度控制器、工厂机器和连接互联网的家用电器。这些设备可以配置为与互联网络中的其他节点通信，还可以自动向中央服务器传输数据，这样就可以对数据进行分析。机器和传感器数据是来自新兴的物联网（IoT）所产生的主要例子。来自物联网的数据可以用于构建分析模型，连续监测预测性行为（如当传感器值表示有问题时进行识别），提供规定的指令（如警示技术人员在真正出问题之前检查设备）。

数据分析工具达到哪些要求和目的？

能应用高级的分析算法和模型提供分析以大数据平台为引擎，比如Hadoop或其他高性能分析系统能够适用于多种数据源的结构化和非结构化数据随着用于分析模型的数据的增加，能够实现扩展分析模型可以，或者已经集成到数据可视化工具能够和其他技术集成

另外，工具必须包含必备的一些功能，包括集成算法和支持数据挖掘技术，包括（但不限于）：

集群和细分：把一个大的实体分割拥有共同特征的小团体。比如分析收集来的客户，确定更细分的目标市场。分类：把数据组织进预定类别。比如根据细分模型决定客户改如何进行分类。恢复：用于恢复从属变量和一个及一个以上独立变量之间的关系，帮助决定从属变量如何根据独立变量的变化而变化。比如使用地理数据、净收入、夏日平均温度和占地面积预测财产的未来走向。联合和项目集挖掘：在大数据集中寻找变量之间的相关关系。比如它可以帮助呼叫中心代表提供基于呼叫者客户细分、关系和投诉类型的更精准的信息。相似性和联系：用于非直接的集群算法。相似性积分算法可用于决定备用集群中实体的相似性。神经网络：用于机器学习的非直接分析。

人们通过数据分析工具了解什么？

数据科学家们，他们想使用更复杂的数据类型实现更复杂的分析，熟知如何设计，如何应用基础模型来评估内在倾向性或偏差。业务分析师，他们更像是随性的用户，想要用数据来实现主动数据发现，或者实现现有信息和部分预测分析的可视化。企业经理，他们想要了解模型和结论。IT开发人员，他们为以上所有类用户提供支持。

如何选择最适合的大数据分析软件？

分析师的专业知识和技能。有些工具的目标受众是新手用户，有的是专业数据分析师，有的则是针对这两种受众设计的。

分析多样性。

根据不同的用户案例和应用，企业用户可能需要支持不同类型的分析功能，使用特定类型的建模（例如回归、聚类、分割、行为建模和决策树）。这些功能已经能够广泛支持高水平、不同形式的分析建模，但是还是有一些厂商投入数十年的精力，调整不同版本的算法，增加更加高级的功能。理解哪些模型与企业面临的问题最相关，根据产品如何最好地满足用户的业务需求进行产品评估，这些都非常重要。

数据范围分析。

要分析的数据范围涉及很多方面，如结构化和非结构化信息，传统的本地数据库和数据仓库、基于云端的数据源，大数据平台（如Hadoop）上的数据管理等。但是，不同产品对非传统数据湖（在Hadoop内或其他用于提供横向扩展的NoSQL数据管理系统内）上的数据管理提供的支持程度不一。如何选择产品，企业必须考虑获取和处理数据量及数据种类的特定需求。

协作。

企业规模越大，越有可能需要跨部门、在诸多分析师之间分享分析、模型和应用。企业如果有很多分析师分布在各部门，对结果如何进行解释和分析，可能会需要增加更多的共享模型和协作的方法。

许可证书和维护预算。

几乎所有厂商的产品都分不同的版本，购买费用和整个运营成本各不相同。许可证书费用与特性、功能、对分析数据的量或者产品可使用的节点数的限制成正比。

易用性。

没有统计背景的商业分析师是否也能够轻松地开发分析和应用呢？确定产品是否提供了方便开发和分析的可视化方法。

非结构化数据使用率。

确认产品能够使用不同类型的非结构化数据（文档、电子邮件、图像、视频、演示文稿、社交媒体渠道信息等），并且能够解析和利用收到的信息。

可扩展性和可伸缩性。

随着数据量的不断增长和数据管理平台的不断扩展，要评估不同的分析产品如何跟随处理与存储容量的增长而增长。

三、如何区分三个大数据热门职业——数据科学家、数据工程师、数据分析师

随着大数据的愈演愈热，相关大数据的职业也成为热门，给人才发展带来带来了很多机会。数据科学家、数据工程师、数据分析师已经成为大数据行业最热门的职位。它们是如何定义的？具体是做什么工作的？需要哪些技能？让我们一起来看看吧。

这3个职业是如何定位的？

数据科学家是个什么样的存在数据科学家是指能采用科学方法、运用数据挖掘工具对复杂多量的数字、符号、文字、网址、音频或视频等信息进行数字化重现与认识，并能寻找新的数据洞察的工程师或专家(不同于统计学家或分析师)。数据工程师是如何定义的

数据工程师一般被定义成“深刻理解统计学科的明星软件工程师”。如果你正为一个商业问题烦恼，那么你需要一个数据工程师。他们的核心价值在 于他们借由清晰数据创建数据管道的能力。充分了解文件系统，分布式计算与数据库是成为一位优秀数据工程师的必要技能。

数据工程师对演算法有相当好的理解。因此，数据工程师理应能运行基本数据模型。商业需求的高端化催生了演算高度复杂化的需求。很多时 候，这些需求超过了数据工程师掌握知识范围，这个时候你就需要打电话寻求数据科学家的帮助。

数据分析师该如何理解数据分析师指的是不同行业中，专门从事行业数据搜集、整理、分析，并依据数据做出行业研究、评估和预测的专业人员。他们知道如何提出正确的问题，非常善于数据分析，数据可视化和数据呈现。

这3个职业具体有什么职责？

数据科学家的工作职责数据科学家倾向于用探索数据的方式来看待周围的世界。把大量散乱的数据变成结构化的可供分析的数据，还要找出丰富的数据源，整合其他可能不完整的数据源，并清理成结果数据集。新的竞争环境中，挑战不断地变化，新数据不断地流入，数据科学家需要帮助决策者穿梭于各种分析，从临时数据分析到持续的数据交互分析。当他们有所发现，便交流他们的发现，建议新的业务方向。他们很有创造力的展示视觉化的信息，也让找到的模式清晰而有说服力。把蕴含在数据中的规律建议给Boss，从而影响产品，流程和决策。数据工程师的工作职责分析历史、预测未来、优化选择，这是大数据工程师在“玩数据”时最重要的三大任务。通过这三个工作方向，他们帮助企业做出更好的商业决策。大数据工程师一个很重要的工作，就是通过分析数据来找出过去事件的特征。比如，腾讯的数据团队正在搭建一个数据仓库，把公司所有网络平台上数量庞大、不规整的数据信息进行梳理，总结出可供查询的特征，来支持公司各类业务对数据的需求，包括广告投放、游戏开发、社交网络等。找出过去事件的特征，最大的作用是可以帮助企业更好地认识消费者。通过分析用户以往的行为轨迹，就能够了解这个人，并预测他的行为。通过引入关键因素，大数据工程师可以预测未来的消费趋势。在阿里妈妈的营销平台上，工程师正试图通过引入气象数据来帮助淘宝卖家做生意。比如今年夏天不热，很可能某些产品就没有去年畅销，除了空调、电扇，背心、游泳衣等都可能会受其影响。那么我们就会建立气象数据和销售数据之间的关系，找到与之相关的品类，提前警示卖家周转库存。根据不同企业的业务性质，大数据工程师可以通过数据分析来达到不同的目的。以腾讯来说，能反映大数据工程师工作的最简单直接的例子就是选项测试（ABTest），即帮助产品经理在A、B两个备选方案中做出选择。在过去，决策者只能依据经验进行判断，但如今大数据工程师可以通过大范围地实时测试—比如，在社交网络产品的例子中，让一半用户看到A界面，另一半使用B界面，观察统计一段时间内的点击率和转化率，以此帮助市场部做出最终选择。数据分析师的工作职责互联网本身具有数字化和互动性的特征，这种属性特征给数据搜集、整理、研究带来了革命性的突破。以往“原子世界”中数据分析师要花较高的成本（资金、资源和时间）获取支撑研究、分析的数据，数据的丰富性、全面性、连续性和及时性都比互联网时代差很多。与传统的数据分析师相比，互联网时代的数据分析师面临的不是数据匮乏，而是数据过剩。因此，互联网时代的数据分析师必须学会借助技术手段进行高效的数据处理。更为重要的是，互联网时代的数据分析师要不断在数据研究的方法论方面进行创新和突破。就行业而言，数据分析师的价值与此类似。就新闻出版行业而言，无论在任何时代，媒体运营者能否准确、详细和及时地了解受众状况和变化趋势，都是媒体成败的关键。

此外，对于新闻出版等内容产业来说，更为关键的是，数据分析师可以发挥内容消费者数据分析的职能，这是支撑新闻出版机构改善客户服务的关键职能。

想要从事这3个职业需要掌握什么技能？

A. 数据科学家需要掌握的技能

1、计算机科学

一般来说，数据科学家大多要求具备编程、计算机科学相关的专业背景。简单来说，就是对处理大数据所必需的hadoop、Mahout等大规模并行处理技术与机器学习相关的技能。

2、数学、统计、数据挖掘等

除了数学、统计方面的素养之外，还需要具备使用SPSS、SAS等主流统计分析软件的技能。其中，面向统计分析的开源编程语言及其运行环境“R”最近备受瞩目。R的强项不仅在于其包含了丰富的统计分析库，而且具备将结果进行可视化的高品质图表生成功能，并可以通过简单的命令来运行。此外，它还具备称为CRAN(TheComprehensive R Archive Network)的包扩展机制，通过导入扩展包就可以使用标准状态下所不支持的函数和数据集。

3、数据可视化(Visualization)

信息的质量很大程度上依赖于其表达方式。对数字罗列所组成的数据中所包含的意义进行分析，开发Web原型，使用外部API将图表、地图、Dashboard等其他服务统一起来，从而使分析结果可视化，这是对于数据科学家来说十分重要...

大数据行业发展如火如荼，国家政策利好，互联网大佬纷纷在大数据行业布局，我们想让自己的职业生涯在一个朝阳行业发展，肯定又要学习相关技术，让自己与时俱进，但是难就难在大数据是一个新兴事物，目前我国大学的专业里面还鲜少有这个专业，国家刚批的大数据专业，全国目前35个高校，但是从17年开始招生，2021年才有第一批毕业生进入职场，在四年期间，是大数据行业发展的飞速时期，没有行业发展是等着人才进入的，而是需要要虚位以待、蓄势待发，所以在没有高等教育准备好的大数据教育，如何高效的学习大数据，如何快速的与行业发展想契合，那么需要我们成为第一个吃螃蟹的人，作为一个随着大数据行业成长的职业人，首先要知道大数据是个啥？

大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

那来帮大家分析下：如何高效的学习大数据。

经常有初学者会问，自己想往大数据方向发展，该学哪些技术，学习路线是什么样的，觉得大数据很火，就业很好，薪资很高……首先，如果你确定了想往这个方面发展，先考虑自己的过去从业经历、专业、兴趣是什么。计算机专业——操作系统、硬件、网络、服务器？软件专业——软件开发、编程、写代码？还是数学、统计学专业——对数据和数字特别感兴趣？

那么你能找师傅带吗？

但凡有这种想法的人，或多或少都会存有侥幸之心，或者叫做“天真，单纯”。希望不花一分钱，就能更快速的学到更优质，更实用的技能。

关于这一点，我只想反问一句你：“如果你是大师，你凭什么愿意带我？”

其实这就是想告诉你大数据的三个发展方向，平台搭建/优化/运维/监控、大数据开发/设计/架构、数据分析/挖掘。

先说一下大数据的4V特征：

数据量大，TB->PB

数据类型繁多，结构化、非结构化文本、日志、视频、图片、地理位置等；

商业价值高，但是这种价值需要在海量数据之上，通过数据分析与机器学习更快速的挖掘出来；

处理时效性高，海量数据的处理需求不再局限在离线计算当中。

现如今，正式为了应对大数据的这几个特点，开源的大数据框架越来越多，越来越强，先列举一些常见的：

文件存储：Hadoop HDFS、Tachyon、KFS

离线计算：Hadoop MapReduce、Spark

流式、实时计算：Storm、Spark Streaming、S4、Heron

K-V、NOSQL数据库：HBase、Redis、MongoDB

资源管理：YARN、Mesos

日志收集：Flume、Scribe、Logstash、Kibana

消息系统：Kafka、StormMQ、ZeroMQ、RabbitMQ

查询分析：Hive、Impala、Pig、Presto、Phoenix、SparkSQL、Drill、Flink、Kylin、Druid

分布式协调服务：Zookeeper

集群管理与监控：Ambari、Ganglia、Nagios、Cloudera Manager

数据挖掘、机器学习：Mahout、Spark MLLib

数据同步：Sqoop

任务调度：Oozie

······

第一步：初识Hadoop

1.1 学会百度与Google

不论遇到什么问题，先试试搜索并自己解决。

Google首选，翻不过去的，就用百度吧。

1.2 参考资料首选官方文档

特别是对于入门来说，官方文档永远是首选文档。

相信搞这块的大多是文化人，英文凑合就行，实在看不下去的，请参考第一步。

1.3 先让Hadoop跑起来

Hadoop可以算是大数据存储和计算的开山鼻祖，现在大多开源的大数据框架都依赖Hadoop或者与它能很好的兼容。

关于Hadoop,你至少需要搞清楚以下是什么：

· Hadoop 1.0、Hadoop 2.0

· MapReduce、HDFS

· NameNode、DataNode

· JobTracker、TaskTracker

· Yarn、ResourceManager、NodeManager

自己搭建Hadoop，请使用第一步和第二步，能让它跑起来就行。

建议先使用安装包命令行安装，不要使用管理工具安装。

另外：Hadoop1.0知道它就行了，现在都用Hadoop 2.0.

1.4 尝试使用Hadoop

· HDFS目录操作命令；

· 上传、下载文件命令；

· 提交运行MapReduce示例程序；

· 打开Hadoop WEB界面，查看Job运行状态，查看Job运行日志。

· 知道Hadoop的系统日志在哪里。

1.5了解它们的原理

MapReduce：如何分而治之；

HDFS：数据到底在哪里，什么是副本；

Yarn到底是什么，它能干什么；

NameNode到底在干些什么；

ResourceManager到底在干些什么；

1.6 自己写一个MapReduce程序

仿照WordCount例子，自己写一个（照抄也行）WordCount程序，

打包并提交到Hadoop运行。

不会Java的话，Shell、Python都可以，有个东西叫Hadoop Streaming。

如果能认真完成了以上几步，恭喜你，你的一只脚已经进来了。

第二步：更高效的WordCount

2.1 学点SQL吧

如果不懂数据库的童鞋先学习使用SQL句。

2.2 SQL版WordCount

在1.6中，你写（或者抄）的WordCount一共有几行代码？

如果用SQL的话：

SELECT word,COUNT(1) FROM wordcount GROUP BY word;

这便是SQL的魅力，编程需要几十行，甚至上百行代码，SQL一句就搞定；使用SQL处理分析Hadoop上的数据，方便、高效、易上手、更是趋势。不论是离线计算还是实时计算，越来越多的大数据处理框架都在积极提供SQL接口。

2.3 安装配置Hive

Hive算是数据仓库工具，安装不难，网上有很多教程，配置完成后，可以正常进入Hive命令行。

2.4 试试使用Hive

尝试在Hive中创建wordcount表，并运行2.2中的SQL语句。在Hadoop WEB界面中找到刚才运行的SQL任务。看SQL查询结果是否和1.4中MapReduce中的结果一致。

明明写的是SQL，为什么Hadoop WEB界面中看到的是MapReduce任务？

2.5 学会Hive的基本命令

创建、删除表；加载数据到表；下载Hive表的数据；并学习更多关于Hive的语法和命令。

0和Hadoop2.0的区别

MapReduce的原理（还是那个经典的题目，一个10G大小的文件，给定1G大小的内存，如何使用Java程序统计出现次数最多的10个单词及次数）；

HDFS读写数据的流程；向HDFS中PUT数据；从HDFS中下载数据；

自己会写简单的MapReduce程序，运行出现问题，知道在哪里查看日志；

会写简单的SELECT、WHERE、GROUP BY等SQL语句；

Hive SQL转换成MapReduce的大致流程；

Hive中常见的语句：创建表、删除表、往表中加载数据、分区、将表中数据下载到本地；

从上面的学习，你已经了解到，HDFS是Hadoop提供的分布式存储框架，它可以用来存储海量数据，MapReduce是Hadoop提供的分布式计算框架，它可以用来统计和分析HDFS上的海量数据，而Hive则是SQL On Hadoop，Hive提供了SQL接口，开发人员只需要编写简单易上手的SQL语句，Hive负责把SQL翻译成MapReduce，提交运行。

第三步：把别处的数据搞到Hadoop上

此处也可以叫做数据采集，把各个数据源的数据采集到Hadoop上。

3.1 HDFS PUT命令

put命令在实际环境中也比较常用，通常配合shell、python等脚本语言来使用。建议需熟练掌握。

3.2 HDFS API

HDFS提供了写数据的API，自己用编程语言将数据写入HDFS，put命令本身也是使用API。

实际环境中一般自己较少编写程序使用API来写数据到HDFS，通常都是使用其他框架封装好的方法。比如：Hive中的INSERT语句，Spark中的saveAsTextfile等。

可以尝试了解原理，试着写几个Demo。

3.3 Sqoop

Sqoop是一个主要用于Hadoop/Hive与传统关系型数据库Oracle/MySQL/SQLServer等之间进行数据交换的开源框架。

就像Hive把SQL翻译成MapReduce一样，Sqoop把你指定的参数翻译成MapReduce，提交到Hadoop运行，完成Hadoop与其他数据库之间的数据交换。

自己下载和配置Sqoop（建议先使用Sqoop1，Sqoop2比较复杂）。

了解Sqoop常用的配置参数和方法。

使用Sqoop完成从MySQL同步数据到HDFS；

使用Sqoop完成从MySQL同步数据到Hive表；

PS：如果后续选型确定使用Sqoop作为数据交换工具，那么建议熟练掌握，否则，了解和会用Demo即可。

3.4 Flume

Flume是一个分布式的海量日志采集和传输框架，因为“采集和传输框架”，所以它并不适合关系型数据库的数据采集和传输。Flume可以实时的从网络协议、消息系统、文件系统采集日志，并传输到HDFS上。因此，如果你的业务有这些数据源的数据，并且需要实时的采集，那么就应该考虑使用Flume。

下载和配置Flume。使用Flume监控一个不断追加数据的文件，并将数据传输到HDFS；

PS：Flume的配置和使用较为复杂，如果你没有足够的兴趣和耐心，可以先跳过Flume。

3.5 阿里开源的DataX

之所以介绍这个，是因为以前某公司客户目前使用的Hadoop与关系型数据库数据交换的工具，就是之前基于DataX开发的，个人感觉非常好用。现在DataX已经是3.0版本，支持很多数据源。你也可以在其之上做二次开发。

PS：有兴趣的可以研究和使用一下，对比一下它与Sqoop。

至此，你的“大数据平台”应该是这样的：

第四步：把Hadoop上的数据搞到别处去

前面介绍了如何把数据源的数据采集到Hadoop上，数据到Hadoop上之后，便可以使用Hive和MapReduce进行分析了。那么接下来的问题是，分析完的结果如何从Hadoop上同步到其他系统和应用中去呢？

其实此处的方法和第三步基本一致的。

4.1 HDFS GET命令

把HDFS上的文件GET到本地。需要熟练掌握。

4.2 HDFS API

原理同3.2。

4.3 Sqoop

原理同3.3。

使用Sqoop完成将HDFS上的文件同步到MySQL；

使用Sqoop完成将Hive表中的数据同步到MySQL；

4.4 DataX

原理同3.4

此时，“你的大数据平台”应该是这样的：

走完第三步和第四步的流程，那么你应该已经具备以下技能和知识点：

· 知道如何把已有的数据采集到HDFS上，包括离线采集和实时采集；

· 知道sqoop（或者还有DataX）是HDFS和其他数据源之间的数据交换工具；

· 知道flume可以用作实时的日志采集；

至此，对于大数据平台，应该已经掌握如何搭建Hadoop集群，把数据采集到Hadoop上，使用Hive和MapReduce来分析数据，把分析结果同步到其他数据源。

接下来的问题就是，Hive使用的越来越多，你会发现很多不愉快的地方，特别是速度慢，

大多情况下，明明我的数据量很小，它都要申请资源，启动MapReduce来执行。

第五步：快一点吧，我的SQL

其实大家都已经发现Hive后台使用MapReduce作为执行引擎，实在是有点慢。因此SQL On Hadoop的框架越来越多，按我的了解，最常用的按照流行度依次为SparkSQL、Impala和Presto.这三种框架基于半内存或者全内存，提供了SQL接口来快速查询分析Hadoop上的数据。

目前我们的方案使用的是SparkSQL，至于为什么用SparkSQL，原因大概如下：

· 使用Spark还做了其他事情，不想引入过多的框架；

· Impala对内存的需求太大，没有过多资源部署；

5.1 关于Spark和SparkSQL

什么是Spark，什么是SparkSQL。

Spark有的核心概念及名词解释。

SparkSQL和Spark是什么关系，SparkSQL和Hive是什么关系。

5.2 如何部署和运行SparkSQL

Spark有哪些部署模式？

如何在Yarn上运行SparkSQL？

使用SparkSQL查询Hive中的表。

PS:Spark不是一门短时间内就能掌握的技术，因此建议在了解了Spark之后，可以先从SparkSQL入手，循序渐进。

第六步：一夫多妻制

其实我想说的是数据的一次采集、多次消费。

在实际业务场景下，特别是对于一些监控日志，想即时的从日志中了解一些指标（关于实时计算，后面步节会有介绍），这时候，从HDFS上分析就太慢了，尽管是通过Flume采集的，但Flume也不能间隔很短就往HDFS上滚动文件，这样会导致小文件特别多。

为了满足数据的一次采集、多次消费的需求，这里要说的便是Kafka。

6.1 关于Kafka

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

6.2 如何部署和使用Kafka

使用单机部署Kafka，并成功运行自带的生产者和消费者例子。

使用Java程序自己编写并运行生产者和消费者程序。

Flume和Kafka的集成，使用Flume监控日志，并将日志数据实时发送至Kafka。

至此，“大数据平台”应该扩充成这样：

这时，使用Flume采集的数据，不是直接到HDFS上，而是先到Kafka，Kafka中的数据可以由多个消费者同时消费，其中一个消费者，就是将数据同步到HDFS。

总结：

为什么Spark比MapReduce快。

使用SparkSQL代替Hive，更快的运行SQL。

使用Kafka完成数据的一次收集，多次消费架构。

自己可以写程序完成Kafka的生产者和消费者。

前面的学习已经掌握了大数据平台中的数据采集、数据存储和计算、数据交换等大部分技能，而这其中的每一步，都需要一个任务（程序）来完成，各个任务�...

微信公众号发展至今，整体的产业已趋向成熟，市场对其运营框架也有了大致的共识，基本上可分为：内容运营、活动运营、用户运营，以及渠道运营和数据运营等几大模块。每个不同的运营模块，它们各自独立，同时又相互地影响。

本文侧重于对运营初学者来说，提供一套简易、有效的数据运营方法论。在开展数据运营工作之前，我们首先得了解数据在整个公众号运营工作中，究竟充当着什么样的角色？

我认为：“数据是运营的基础，就像一条绳索，贯穿整个运营工作。它既是运营KPI考核的直接呈现方式，同时也是运营方向的理论支撑点”

在新媒体的数据运营中，数据分析是至关重要的步骤，而数据分析有大概九类方法，你们知道吗？今天小天就来带大家了解一下这些干货吧！

数据分析的九类方法：直接评判法 — 对比分析法 — 结构分析法 — 分组分析法 — 平均分析法 — 矩阵分析法 — 漏斗图分析法 — 雷达图分析法 — 回归分析法

1.直接评判法

直接评判法即根据经验直接判断数据的好坏并给予评判，通常用于内部过往运营状况评估，如评估近期阅读量是否过低，评判近期销售量是否异常，评估当日文章推送量是否正常。

直接评判法有两个必要的条件：一是运营者有一定的新媒体运营经验，能够对跳出率，阅读量等有正确的评估；二是经过加工处理的数据足够直观，可以直接代表某项数据的优缺点。

2.对比分析法

对比分析法，是将两个或两个以上的数据进行对比，分析差异进而揭示这些数据所代表的规律。

对比分析法包括横向比较及纵向比较。横向比较即同一时间下不同总体指标的对比，如今日头条同领域作者文章阅读量对比，粉丝数对比等；纵向比较不同时间条件下同一总体指标的对比，如本月文章阅读量与上月阅读量进行对比，本月粉丝增长数与上月增长数进行对比等。

通过对比分析，可以直接观察到目前的运营水平，一方面找到当前已经处于优秀水平的方面，后续予以保持；另一方面及时发现当前的薄弱环节，重点突破。

3.分组分析法

分组分析法是指通过一定的指标，将对象统计分组并计算和分析，以便于深入了解所要分析对象的不同特征，性质及相互关系的方法。

分组分析法遵循相互独立，完全穷尽的枚举分析法原则。所谓相互独立，即分组之间不能有交叉，组别之间具有明显的差异性，每个数据只能归属于某一组；所谓完全穷尽，即分组中不要遗漏任何数据，保持完整性，各组的空间足以容纳总体的所有数据。

4.结构分析法

结构分析法是在统计分组的基础上，将组内数据与总体数据之间进行对比的分析方法。结构分析法分析各组部分占总体的比例，属于相对指标。

例如，新媒体运营团队可以统计粉丝所在的地域分布，统计出各个地方粉丝的占比情况，此情景便属于结构分析法。

5.平均分析法

例如，在分析今日头条的文章阅读量时，借助Excel导出的数据可以快速找到阅读量大于平均值的文章，接下来可以继续挖掘这些文章的标题，排版，配图等规律，便于后续内容质量的提升。

6.矩阵分析法

矩阵分析法是一种定量分析问题的方法，它是指以数据两个重要指标作为分析依据，并将这两个指标作为横，纵坐标轴，构成四个象限，从而找出解决问题的办法，为运营者提供数据参考。

例如，某餐饮企业的大众点评评价分析，可以借助四个象限“紧急且重要，重要但不紧急，紧急但不重要，不紧急也不重要”进行矩阵分析，并重点处理“紧急且重要”的事项。

7.漏斗图分析法

漏斗图分析法因展现形式如漏斗，故而得名。漏斗图可以对文章阅读量，产品购买量等情况进行逐层分析，展示整个关键路径中每步的转化情况。

重要强调的是，单一的漏斗图难以衡量各个环节的好坏，运营者可以结合本节介绍的“对比分析法”，对同一环节不同时间对比，评估运营效果。

8.雷达图分析法

雷达图常用于指数分析，即通过对新媒体账号的内容质量，领域专注等不同维度的计算而得出的客观评分结果。分数越高，代表账号的质量越好。可以利用雷达图进行分析的指数，包括今日头条指数，大鱼号星级指数，百家号指数等。

9.回归分析法

回归分析法是通过研究事物发展变化的因果关系来预测事物发展走向，它是研究变量间相互关系的一种定量预测方法，又称回归模型预测法或因果法。

例如，将今日头条粉丝数据导出到Excel表格，对累计粉丝数进行一元线性分析，就可以尝试预测某个时间的粉丝量。

如今社会，单身青年的数量越来越巨大，在某些单身人士的眼中，谈恋爱似乎是很繁琐又耗费精力的事情。很多单身人士都有这种“不是不去爱，只是怕麻烦”的想法，也有很多在恋爱中的青年说“搞不懂他/她心里到底在想些什么，稍微有点矛盾就发火，还不如自己一个人来的轻松惬意。”不少对于爱情比较迷糊的人，时不时的踩到感情的雷区，因此免不了又有一番不必要的争吵。本次生活馆将告诉你：当男生和女生进行一段感情的时候有哪些举动是极其不明智的；在彼此的恋爱期间，男生女生到底在想什么？情侣究竟怎样才能科学地相处？

一、对方给你的爱，从来都不是理所应当的

男女在交往期间，男生是十分反感一个女生对他的付出以及努力视若，在她享受男生对她的各种福利的时候，满嘴都是“男女平等”，而当她需要为男生做出一点妥协的时候，她又会搬出“女权理论”这一套。曾经有个朋友，男友对她百依百顺，她前一分钟说想吃早餐，下一分钟男友就把早餐送到楼下，当姐妹们羡慕地说她男票真好时，她得意地说：“他说过愿意为我做一切的。”好景不长，女生被分手了，男生表示和她谈恋爱太累了。其实在恋爱期间是十分忌讳一方付出大量时间精力，而另一方把却把这种付出视作她本就应得的福利，那么这段感情的“祸根”在此刻已经种下。恋爱里有种关系叫“壁垒”，指的是恋爱中两个人彼此付出，建立“爱情壁垒”，在发生矛盾时会念及对方的好，提高分手成本。建立“壁垒”需要互动式付出，恋爱中两人的关系是平等的，没有什么爱是“你本应该”。

二、双方产生矛盾，处于争执阶段时，不留情面，狠戳痛处

男性是一种极度爱惜面子的物种，女生不留情面的讽刺挖苦是他们十分难以接受和容忍的。交往期间的磕磕绊绊小小争执都没关系，但如果女生恃宠而骄、口不择言，男生是十分反感的。主持人寇乃馨曾经在节目中提到，她和老公黄国伦都是强势的人，每次吵起架来都互不相让。有次吵得很凶，她怒气冲冲说了句：“黄国伦，你哪一点比得上我寇乃馨啊，你知不知道你离过婚，你是二手货，你配不上我。”黄国伦说了句：“你知道吗？有些话是不能说出口的。”随即消失了3天毫无音讯。恋爱中最无意义的就是贬损了，有些话一旦说出就收不回来，也会拆毁彼此为恋情付出的努力。

三、意见出现分歧，女生就是不言语，让男生猜他的心思

男性和女性对同一件事情上的思考模式的差异真不是一星半点，当一个女生对男生说一些含糊不清的话时候：男生是很害怕去猜女生心思，因为不仅不容易猜到正确答案，而且如果猜错了的 话后果可是相当严重的！女人心海底针，一个糙汉子有能猜到多少，毕竟能心领神会一下子就猜到女朋友此时此刻的想法的男生是十分稀少的，对于一个男生而言，他更希望的是：你的情绪你的想法都能不兜圈子说出来，不然你的需求我怎么去满足？你的情绪我怎么去照顾呢？

财务报表是反映公司财务状况的重要数据报表。结构清晰，展示全面的财务报表能够帮助企业的管理人员深入分析报表数据，挖掘数据价值，帮助企业查找问题，以便使企业运行的更加良好。

下面列举使用葡萄城报表制作出的清晰美观的财务报表。

资产负债结构表

这张报表展示了财务三大报表之一的资产负债表，报表让企业现有资产和负债情况一目了然。

费用报表

通过费用报表，可以清晰的查看公司的费用情况趋势等，以便为节省开支计划提供数据依据。

库存分析报表

库存情况代表了企业的生产成品实际的流动情况，反映了企业的销售等情况是否正常。通过库存分析报表，企业的管理人员能实时掌握企业的运营状态。

以上报表均包含在葡萄城报表模板库中。

了解报表模板库：http://grapecity/enterprise-solutions/activereports_server/library/

转载请注明出自：葡萄城报表

关于报表模板库

报表模板库是葡萄城面向广大报表用户推出的免费报表制作、学习及参考工具。通过该工具，降低用户制作报表难度，人人都可成为报表专家，业务数据分析不再遥不可及！

仅需一步！无需配置环境及参数，即可快速浏览百余套来自真实行业的案例及典型应用模板，在了解专业报表的布局及功能的同时，掌握报表从设计到呈现的全部技术细节，还可通过自带的设计器，所见即所得的修改报表模板，并查看效果。

前言

一般而言，标题含有“秒杀”，“99%”，“史上最全/最强”等词汇的往往都脱不了哗众取宠之嫌，但进一步来讲，如果读者读罢此文，却无任何收获，那么，我也甘愿背负这样的罪名 :-)，同时，此文可以看做是对这篇文章：十道海量数据处理面试题与十个方法大总结的一般抽象性总结。

毕竟受文章和理论之限，本文将摒弃绝大部分的细节，只谈方法/模式论，且注重用最通俗最直白的语言阐述相关问题。最后，有一点必须强调的是，全文行文是基于面试题的分析基础之上的，具体实践过程中，还是得具体情况具体分析，且各个场景下需要考虑的细节也远比本文所描述的任何一种解决方法复杂得多。

OK，若有任何问题，欢迎随时不吝赐教。谢谢。

01

何谓海量数据处理？

所谓海量数据处理，无非就是基于海量数据上的存储、处理、操作。何谓海量，就是数据量太大，所以导致要么是无法在较短时间内迅速解决，要么是数据太大，导致无法一次性装入内存。

那解决办法呢?针对时间，我们可以采用巧妙的算法搭配合适的数据结构，如Bloom filter/Hash/bit-map/堆/数据库或倒排索引/trie树，针对空间，无非就一个办法：大而化小，分而治之（hash映射），你不是说规模太大嘛，那简单啊，就把规模大化为规模小的，各个击破不就完了嘛。

至于所谓的单机及集群问题，通俗点来讲，单机就是处理装载数据的机器有限(只要考虑cpu，内存，硬盘的数据交互)，而集群，机器有多辆，适合分布式处理，并行计算(更多考虑节点和节点间的数据交互)。

再者，通过本blog内的有关海量数据处理的文章：Big Data Processing，我们已经大致知道，处理海量数据问题，无非就是：

分而治之/hash映射 + hash统计 + 堆/快速/归并排序；双层桶划分Bloom filter/Bitmap；Trie树/数据库/倒排索引；外排序；分布式处理之Hadoop/Mapreduce。

下面，本文第一部分、从set/map谈到hashtable/hash_map/hash_set，简要介绍下set/map/multiset/multimap，及hash_set/hash_map/hash_multiset/hash_multimap之区别(万丈高楼平地起，基础最重要)，而本文第二部分，则针对上述那6种方法模式结合对应的海量数据处理面试题分别具体阐述。

02

第一部分、从set/map谈到hashtable/hash_map/hash_set

稍后本文第二部分中将多次提到hash_map/hash_set，下面稍稍介绍下这些容器，以作为基础准备。一般来说，STL容器分两种，

序列式容器(vector/list/deque/stack/queue/heap)，关联式容器。关联式容器又分为set(集合)和map(映射表)两大类，以及这两大类的衍生体multiset(多键集合)和multimap(多键映射表)，这些容器均以RB-tree完成。此外，还有第3类关联式容器，如hashtable(散列表)，以及以hashtable为底层机制完成的hash_set(散列集合)/hash_map(散列映射表)/hash_multiset(散列多键集合)/hash_multimap(散列多键映射表)。也就是说，set/map/multiset/multimap都内含一个RB-tree，而hash_set/hash_map/hash_multiset/hash_multimap都内含一个hashtable。

所谓关联式容器，类似关联式数据库，每笔数据或每个元素都有一个键值(key)和一个实值(value)，即所谓的Key-Value(键-值对)。当元素被插入到关联式容器中时，容器内部结构(RB-tree/hashtable)便依照其键值大小，以某种特定规则将这个元素放置于适当位置。

包括在非关联式数据库中，比如，在MongoDB内，文档(document)是最基本的数据组织形式，每个文档也是以Key-Value（键-值对）的方式组织起来。一个文档可以有多个Key-Value组合，每个Value可以是不同的类型，比如String、Integer、List等等。

{ "name" : "July",

"sex" : "male",

"age" : 23 }

set/map/multiset/multimap

set，同map一样，所有元素都会根据元素的键值自动被排序，因为set/map两者的所有各种操作，都只是转而调用RB-tree的操作行为，不过，值得注意的是，两者都不允许两个元素有相同的键值。

不同的是：set的元素不像map那样可以同时拥有实值(value)和键值(key)，set元素的键值就是实值，实值就是键值，而map的所有元素都是pair，同时拥有实值(value)和键值(key)，pair的第一个元素被视为键值，第二个元素被视为实值。

至于multiset/multimap，他们的特性及用法和set/map完全相同，唯一的差别就在于它们允许键值重复，即所有的插入操作基于RB-tree的insert_equal()而非insert_unique()。

hash_set/hash_map/hash_multiset/hash_multimap

hash_set/hash_map，两者的一切操作都是基于hashtable之上。不同的是，hash_set同set一样，同时拥有实值和键值，且实质就是键值，键值就是实值，而hash_map同map一样，每一个元素同时拥有一个实值(value)和一个键值(key)，所以其使用方式，和上面的map基本相同。但由于hash_set/hash_map都是基于hashtable之上，所以不具备自动排序功能。为什么?因为hashtable没有自动排序功能。

至于hash_multiset/hash_multimap的特性与上面的multiset/multimap完全相同，唯一的差别就是它们hash_multiset/hash_multimap的底层实现机制是hashtable（而multiset/multimap，上面说了，底层实现机制是RB-tree），所以它们的元素都不会被自动排序，不过也都允许键值重复。

所以，综上，说白了，什么样的结构决定其什么样的性质，因为set/map/multiset/multimap都是基于RB-tree之上，所以有自动排序功能，而hash_set/hash_map/hash_multiset/hash_multimap都是基于hashtable之上，所以不含有自动排序功能，至于加个前缀multi_无非就是允许键值重复而已。如下图所示：

此外，关于什么hash，请看blog内此篇文章；关于红黑树，请参看blog内系列文章，关于hash_map的具体应用：请看这里，关于hash_set：请看此文。

OK，接下来，请看本文第二部分、处理海量数据问题之六把密匙。

03

第二部分、处理海量数据问题之六把密匙

密匙一、分而治之/Hash映射 + Hash_map统计 + 堆/快速/归并排序

1、海量日志数据，提取出某日访问百度次数最多的那个IP。

既然是海量数据处理，那么可想而知，给我们的数据那就一定是海量的。针对这个数据的海量，我们如何着手呢?对的，无非就是分而治之/hash映射 + hash统计 + 堆/快速/归并排序，说白了，就是先映射，而后统计，最后排序：

1、分而治之/hash映射：针对数据太大，内存受限，只能是：把大文件化成(取模映射)小文件，即16字方针：大而化小，各个击破，缩小规模，逐个解决

2、hash_map统计：当大文件转化了小文件，那么我们便可以采用常规的hash_map(ip，value)来进行频率统计。

3、堆/快速排序：统计完了之后，便进行排序(可采取堆排序)，得到次数最多的IP。

具体而论，则是： “首先是这一天，并且是访问百度的日志中的IP取出来，逐个写入到一个大文件中。注意到IP是32位的，最多有个2^32个IP。同样可以采用映射的方法，比如%1000，把整个大文件映射为1000个小文件，再找出每个小文中出现频率最大的IP（可以采用hash_map对那1000个文件中的所有IP进行频率统计，然后依次找出各个文件中频率最大的那个IP）及相应的频率。然后再在这1000个最大的IP中，找出那个频率最大的IP，即为所求。”--十道海量数据处理面试题与十个方法大总结。

关于本题，还有几个问题，如下：

1、Hash取模是一种等价映射，不会存在同一个元素分散到不同小文件中的情况，即这里采用的是mod1000算法，那么相同的IP在hash取模后，只可能落在同一个文件中，不可能被分散的。因为如果两个IP相等，那么经过Hash(IP)之后的哈希值是相同的，将此哈希值取模（如模1000），必定仍然相等。

2、那到底什么是hash映射呢？简单来说，就是为了便于计算机在有限的内存中处理big数据，从而通过一种映射散列的方式让数据均匀分布在对应的内存位置(如大数据通过取余的方式映射成小树存放在内存中，或大文件映射成多个小文件)，而这个映射散列方式便是我们通常所说的hash函数，设计的好的hash函数能让数据均匀分布而减少冲突。尽管数据映射到了另外一些不同的位置，但数据还是原来的数据，只是代替和表示这些原始数据的形式发生了变化而已。

OK，有兴趣的，还可以再了解下一致性hash算法，见blog内此文第五部分http://blog.csdn/v_july_v/article/details/6879101。

2、寻找热门查询，300万个查询字符串中统计最热门的10个查询

原题：搜索引擎会通过日志文件把用户每次检索使用的所有检索串都记录下来，每个查询串的长度为1-255字节。假设目前有一千万个记录（这些查询串的重复度比较高，虽然总数是1千万，但如果除去重复后，不超过3百万个。一个查询串的重复度越高，说明查询它的用户越多，也就是越热门），请你统计最热门的10个查询串，要求使用的内存不能超过1G。

解答：由上面第1题，我们知道，数据大则划为小的，如如一亿个Ip求Top 10，可先%1000将ip分到1000个小文件中去，并保证一种ip只出现在一个文件中，再对每个小文件中的ip进行hashmap计数统计并按数量排序，最后归并或者最小堆依次处理每个小文件的top10以得到最后的结。

但如果数据规模比较小，能一次性装入内存呢?比如这第2题，虽然有一千万个Query，但是由于重复度比较高，因此事实上只有300万的Query，每个Query255Byte，因此我们可以考虑把他们都放进内存中去（300万个字符串假设没有重复，都是最大长度，那么最多占用内存3M*1K/4=0.75G。所以可以将所有字符串都存放在内存中进行处理），而现在只是需要一个合适的数据结构，在这里，HashTable绝对是我们优先的选择。

所以我们放弃分而治之/hash映射的步骤，直接上hash统计，然后排序。So，针对此类典型的TOP K问题，采取的对策往往是：hashmap + 堆。如下所示：

hash_map统计：先对这批海量数据预处理。具体方法是：维护一个Key为Query字串，Value为该Query出现次数的HashTable，即hash_map(Query，Value)，每次读取一个Query，如果该字串不在Table中，那么加入该字串，并且将Value值设为1；如果该字串在Table中，那么将该字串的计数加一即可。最终我们在O(N)的时间复杂度内用Hash表完成了统计；

堆排序：第二步、借助堆这个数据结构，找出Top K，时间复杂度为N‘logK。即借助堆结构，我们可以在log量级的时间内查找和调整/移动。因此，维护一个K(该题目中是10)大小的小根堆，然后遍历300万的Query，分别和根元素进行对比。所以，我们最终的时间复杂度是：O（N） + N' * O（logK），（N为1000万，N’为300万）。

别忘了这篇文章中所述的堆排序思路：“维护k个元素的最小堆，即用容量为k的最小堆存储最先遍历到的k个数，并假设它们即是最大的k个数，建堆费时O（k），并调整堆(费时O（logk）)后，有k1>k2>...kmin（kmin设为小顶堆中最小元素）。继续遍历数列，每次遍历一个元素x，与堆顶元素比较，若x>kmin，则更新堆（x入堆，用时logk），否则不更新堆。这样下来，总费时O（k*logk+（n-k）*logk）=O（n*logk）。此方法得益于在堆中，查找等各项操作时间复杂度均为logk。”--第三章续、Top K算法问题的实现。

当然，你也可以采用trie树，关键字域存该查询串出现的次数，没有出现为0。最后用10个元素的最小推来对出现频率进行排序。

3、有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16字节，内存限制大小是1M。返回频数最高的100个词。

由上面那两个例题，分而治之 + hash统计 + 堆/快速排序这个套路，我们已经开始有了屡试不爽的感觉。下面，再拿几道再多多验证下。请看此第3题：又是文件很大，又是内存受限，咋办?还能怎么办呢?无非还是：

1、分而治之/hash映射：顺序读文件中，对于每个词x，取hash(x)%5000，然后按照该值存到5000个小文件（记为x0,x1,...x4999）中。这样每个文件大概是200k左右。如果其中的有的文件超过了1M大小，还可以按照类似的方法继续往下分，直到分解得到的小文件的大小都不超过1M。

2、hash_map统计：对每个小文件，采用trie树/hash_map等统计每个文件中出现的词以及相应的频率。

3、堆/归并排序：取出出现频率最大的100个词（可以用含100个结点的最小堆）后，再把100个词及相应的频率存入文件，这样又得到了5000个文件。最后就是把这5000个文件进行归并（类似于归并排序）的过程了。

4、海量数据分布在100台电脑中，想个办法高效统计出这批数据的TOP10。

如果每个数据元素只出现一次，而且只出现在某一台机器中，那么可以采取以下步骤统计出现次数TOP10的数据元素：

1、堆排序：在每台电脑上求出TOP10，可以采用包含10个元素的堆完成（TOP10小，用最大堆，TOP10大，用最小堆，比如求TOP10大，我们首先取前10个元素调整成最小堆，如果发现，然后扫描后面的数据，并与堆顶元素比较，如果比堆顶元素大，那么用该元素替换堆顶，然后再调整为最小堆。最后堆中的元素就是TOP10大）。

2、求出每台电脑上的TOP10后，然后把这100台电脑上的TOP10组合起来，共1000个数据，再利用上面类似的方法求出TOP10就可以了。

但如果同一个元素重复出现在不同的电脑中呢，如下例子所述：

这个时候，你可以有两种方法：

遍历一遍所有数据，重新hash取摸，如此使得...

在短时间内爆发大量数据，这时数据资源的采集、存储和分析和应用等，都是大数据行业的难点。行为数据、日志数据的处理，往往成为企业数据建设首先面对的瓶颈，这些数据不易保存，实时获取分析难度较大，但是数据价值却不可估量。

在大数据中，90% 以上的数据爆发来自于行为数据，就像现在的互联网、移动互联网、甚至在产生于物联网中用来描述人和物的每一分每一秒的变化的数据状态，这些都是行为数据。

行为数据能用做什么？

行为数据能做什么？有一个简单的例子 —— 分析访客行为的路径，我们拿一个网站的数据进行分析，针对网站的访客，我们可以通过分析其访问前期、中期、后期的行为习惯去了解哪些引流的渠道需要加强投入，以及使用这些来指导内容编辑和竞品研究分析工作。

实际上在做需求时，还有更多的细节要求如：对数据的实时性的要求比较高、要求数据的热点情报的准确性、与客户数据的协同分析等。

行为数据的处理方式

用户行为数据通常具备以下特征：

用户基数大；

高基数维度比较多；

数据量大；

时序的特征。

我们用到的高基维，其中有些维度都是上千万的高基维参数。用户行为数据的处理，在支持原始数据查询的同时，也要支持原始数据的聚合能力。

原始数据的聚合分析这块又分为两种，一种是过去常用的做法，通过一个固化的业务模型或者主题，提前计算好的数据，叫做物化视图。

第二种是基于原始数据存储之后，在实时查询的过程中进行多维交叉的计算，这个称为实时聚合。

在查询过程中对实时聚合的一个分析，也是大家在进行数据挖掘分析中共同面临的一个问题，就是针对海量数据。

首先，针对这些数据，需要快速的检索出所需要的数据的行号。其次，在获取数据所在位置之后，如何快速地把数据装载到内存里，最后是装载到内存之后通过分布式计算的方式，怎么去把我们的结果计算出来。

这些就是在做数据的实时查询过程中的需要具备的基本技术条件。

挖掘数据新的价值

面对海量实时行为数据的技术思考，主要是从四个角度来进行：

第一，必须要以原始数据存储。为什么要基于原始数据存储？因为在整个的数据分析阶段，可以细分为三个阶段。第一个就是传统的是 BI 阶段。第二个是数据的挖掘，第三个是数据的预测分析。

想解决这三个阶段的过程，以传统的方法是建一个数仓，基于数仓来实施的时，只能面向比较固化的业务报表模式，产生一些数据的分析结果，得到决策结果。如果想做数据挖掘时，基于固化业务模式计算的结果的很难满足数据挖掘需求，所以必须从初始阶段基于原始数据去提取其特征。

基于固化的的业务报表模型所获取数据计算的结果，对数据挖掘分析的价值不高。存储引擎必须以原始数据进行存储，才能既满足 BI 阶段的需求，又可以解决未来数据挖掘与数据预测分析的需求。

第二，要满足实时多维的查询，是为了在数据基于原始数据存储之后，去做到聚合结果能够满足用户对海量增量数据快速查询的需求。

第三，快速响应需求，在企业内部，其实数据部门的需求量是最大的，各个业务部门的需求都往数据中心提，所以数据部门必须去解决好如何快速地响应业务需求。

第四，数据的探索分析，以往把数据，按照固化的业务报表模式所获取的结果，做二次分析的空间量比较小。所以必须要基于原始多维的数据进行数据的探索，挖掘数据新的价值，而不是按照已有的固化的业务模式，只是生产出一些固化的业务模型的数据。

平台架构

数果现在基于之前做过的一些技术的预言跟验证，自行研发了一个基于 Hadoop 加速引擎，称为 Tindex。之前我也在网络上做过万亿级日志与行为数据存储查询技术剖析http://infoq/cn/articles/trillion-log-and-data-storage-query-techniques 的文章 ，也讲解了 Tindex 是如何实现的。Tindex 的实现主要基于三点，第一点基于索引，第二点基于类似存储的方式，第三点做了分布式内存计算的框架在 Tindex 中，使之能够支持数据的实时的多维分析的能力。

基于加速引擎这块，在其上层做了一个适配层，有 SQL引擎。SQL 引擎支持 SQL 语句和表达式，还有大数据生态技术，目前已经是完全支持。基于适配层，来做不同的行业应用。这是数果整个平台技术架构的一个图。

平台特性

平台的特性方面，支持海量增量数据实时接入。在数据接入这块，现在提供可视化埋点，跟文件、MR 的一些数据的采集，就像我们目前在做的单进程的接入式，基本上在 3 万以上，从数据的产生，到数据显示、出现查询结果，在 5 秒以内即可实现。

第二个特性，基于明细数据的存储与预聚合的存储分别去搭建。为什么不仅要基于原始数据存储，还需要预聚合存储？因为其有两种不同的需求。第一个是面向固化的高频查询的数据，我们可以基于预聚合存储的方式，去查询其周期跨度比较长的需求，一年两年都可以进行查询。但是基于近半年或者一年的数据需要进行深度数据探索分析的，便可以基于原始明细数据做实时聚合分析。还有在基于原始明细数据进行分析的时候，他会更佳灵活。

第三，海量数据中怎么去实现快速检索，是基于搜索引擎的索引技术进行改造的。但是在筛选方式上，目前只能支持时间筛选、文本筛选和数值筛选，例如文本筛选中支持分词与模糊匹配，数值筛选中，数值的分组和数值的范围这些均可支持。

这个展示的是灵活多维的分析，在这个界面中，左边的这一列中是基于原始明细数据产生的所有的维度，可以根据权限去进行显示。而在指标方面通过界面拖拽进行多维实时分析，选择想要的数据分析结果，进行可视化的展示，可以自由地数据探索。因为数据是基于原始明细数据的存储，所以不需要提前预计算。可以在界面上进行任意数据交叉分析，去了解数据的分布态是非常便捷的。

通过指标的灵活定义，来实现实时响应的业务需求，这个指标定义这块有几个指标，一种叫单指标，即按照某一个维度进行一个聚合计算，通过界面可以简单、快速完成。另一种叫复合指标，需要进行一些四则运算，可以通过这个界面定义出来。

在指标这方面还有比较复杂的，需要通过多个维度进行定义的，可以通过一些表达式，进行快速的定义，定义完成后就通过界面，直接看到结果，获得图形显示，进行数据分析。

支持实时监控与跟踪告警，在多维分析界面中把分析结果定义出来后，可以直接形成一个实时监控大屏，不需要重新开放，多站完成各类需求。

最后一个也是最重要的一个特性，是支持二次的开发。数果的平台提供普通类查询，有 Timeseries、TopN、select、groupby、firstN、scanQuery。也提供像用户分组，用户漏斗查询，用户留存查询这类高级查询，还支持多种条件的过滤，像日期范围、数值范围、地理坐标范围，还有字符串的精准匹配。还支持多种聚合的方式。如统计，分组，还有聚合再聚合，这类业务场景，也是在业务需求中经常出现的。

基于平台我们做了什么？

基于这个平台实现了指标任意定制，因为数据是基于原始明细记录存储的，所以指标的定制这方面，不需要提前预计算，直接通过界面，通过一些表达式便可以轻松实现。

维度的自由的筛选，可以通过界面，自由地拖拽数据，就可以完成交叉分析。

基于平台提供用户行为分析模型，例如实时的用户分群，可以通过界面快速的完成。再例如实时的路径分析，实时的流程分析，实时的漏斗分析。提供了一个智能算法模型，相当于在这个模块实现了，将机械学习跟深度学习的算法吸收进来，跟我们的平台打通，就可以实现通过界面的简单拖拽，来完成大部分算法的模型。用户也有一些固化的模型，像用户的扩群，用户 RFM 细分的模型，用户流失预测的模型。基于这方面也提供了一个实时大屏的模块，能够由用户自由拖拽完成其实时监控的需求。

海量数据处理在面试中是经常会被问的一些问题，处理大量数据的基本功在平常工作中确实是会用到的，今天我就整理了一些这方面的问题。

所谓海量数据处理， 指的是大数据量上进行的各种数据操作，但因为数据量庞大，会出现程序的运行时间过长，单机的存储空间不够或一些程序在运行过程中内存不足的情况，因而需要一些特别的处理方法，本文就尽可能的把这些特别的处理方法汇总，同时希望各路大神帮忙补充。本文里的各种方法对应的面试题内容也会在博客中持续更新。（ 可以点击阅读原文查看博客内容）。

通过网络上各种文章的收集以及自己平时面试中的一些积累，掌握海量数据问题的处理方法首先要学会两个方法：一是用分治的方法将大数据问题变成小数据问题，其中分治的方法最常用的就是用hash，之后再对各小块问题的结果进行统计、汇总或排序；另一个方法就是用bit map。 其它网络上经常会提到的Trie树，Hadoop等当然能掌握是更好的。本文就先详细举例介绍分治法和bit map方法。其中部份举例题目来源于网络，相信有这方面准备经验的同学可能早就看过了。

分治法

大多用来hash映射来将大文件或大量数据进行分而治之的处理，分到不同的机器或节点上，再进行处理。处理的结果可能需要再用hash进行统计汇总，进行归并排序或再用堆排序找出TopK。这里值得一得的是面试过程中如果答出用hash来分治，很可能会引出新的关于hash的问题，比如怎么做hash，处理hash中冲突的方法等，最好都提前准备好。

下面是关于这方面的几个题目：（篇幅原因，只举例两题，博客上会持续大量更新）

海量日志数据，提取出某日访次数最多的那个IP

这题是典型的求TopK，TopK问题最先能想到的肯定是堆排序，但这里因为记录很多，还是可以用分治的方法先打散文件。

这里注意到IP是32位的，最多有个2^32个IP，可以采用映射的方法，比如模1000，把整个大文件映射为1000个小文件，再找出每个小文中出现频率最大的IP（可以采用hash_map进行频率统计，然后再找出频率最大的几个）及相应的频率。然后再在这1000个最大的IP中，找出那个频率最大的IP，即为所求。

因为IP地址最多有2^32=4G种取值情况，所以不能完全加载到内存中处理，我们用“分而治之”的思想，按照IP地址的Hash(IP)%1024值，把海量IP日志分别存储到1024个小文件中。这样，每个小文件最多包含4MB个IP地址。对于每一个小文件，可以构建一个IP为key，出现次数为value的Hash map，同时记录当前出现次数最多的那个IP地址。可以得到1024个小文件中的出现次数最多的IP，再依据常规的排序算法得到总体上出现次数最多的IP。如果1024个小文件中有严重的数据倾斜，则需要再进行进一步的分治打散小文件来处理。

给定a、b两个文件，各存放50亿个url，每个url各占64字节，内存限制是4G，让你找出a、b文件共同的url？

这里明确给出了每个url占用的字节数和内存限制，那么这个内存里存不下URL明显是需要计算难一下的。从条件中可以算出每个文件的大小为5G×64=320G，远远大于内存限制的4G。所以不可能将其完全加载到内存中处理。考虑采取分而治之的方法。

遍历文件a，对每个url取模 ，这里将大文件分散到小文件的方法有很多种，最直观的，按前N个字母打散也行，重点是要找到一种方法，让所有文件里的URL数量尽可能的均匀，否则出现很大的倾斜的话，还需要再次的打散。

然后根据所取得的值将url分别存储到1000个小文件中。这样每个小文件的大约为300M。遍历文件b，采取和a相同的方式将url分别存储到1000小文件中。这样处理后，所有可能相同的url都在对应的小文件中，不对应的小文件不可能有相同的url。然后我们只要求出1000对小文件中相同的url即可。如果因为hash的过程中导致小文件的大小不是均匀分布，而出现有些文件还是太大，则可进行再次的hash分治，直至单个文件可以单机处理为止。

接着用hash进行统计 ：求每对小文件中相同的url时，可以把其中一个小文件的url存储到hash_set中。然后遍历另一个小文件的每个url，看其是否在刚才构建的hash_set中，如果是，那么就是共同的url，存到文件里面就可以了。

Bit-Map

所谓的Bit-map就是用一个bit位来标记某个元素对应的Value， 而Key即是该元素。由于采用了Bit为单位来存储数据，因此在存储空间方面，可以大大节省。但在面试过程中可能会让你用自己熟悉的语言来写一个Bit-map的程序，最好也提前准备好吧。

下面是关于这方面的几个题目：（篇幅原因，只举例两题，博客上会持续大量更新）

在2.5亿个整数中找出不重复的整数，内存不足以容纳这2.5亿个整数。

方案1：采用Bit-Map（每个数分配2bit，00表示不存在，01表示出现一次，10表示多次，11无意义）进行，共需内存2^32*2bit=1GB内存，还可以接受。然后扫描这2.5亿个整数，查看Bit-map中相对应位，如果是00变01，01变10，10保持不变。所描完事后，查看Bit-map，把对应位是01的整数输出即可。

方案2：也可采用上题类似的方法，进行划分小文件的方法。然后在小文件中找出不重复的整数，并排序。然后再进行归并，注意去除重复的元素。

已知某个文件内包含一些电话号码，每个号码为8位数字，统计不同号码的个数。

8位最多99 999 999，大概需要99m个bit，大概10几m字节的内存即可。 （可以理解为从0-99 999 999的数字，每个数字对应一个Bit位，所以只需要99M个Bit==12MBytes，这样，就用了小小的12M左右的内存表示了所有的8位数的电话）

5亿个int找它们的中位数

这题也可以用Bit-Map来实现。

首先我们将int划分为2^16个区域，然后读取数据统计落到各个区域里的数的个数，之后我们根据统计结果就可以判断中位数落到那个区域，同时知道这个区域中的第几大数刚好是中位数。然后第二次扫描我们只统计落在这个区域中的那些数就可以了。

实际上，如果不是int是int64，我们可以用分治的方法，经过3次这样的划分即可降低到可以接受的程度。即可以先将int64分成2^24个区域，然后确定区域的第几大数，在将该区域分成2^20个子区域，然后确定是子区域的第几大数，然后子区域里的数的个数只有2^20，就可以直接进行统计了。

欢迎各位大神不吝贡献更多的海量数据处理相关的内容，一同分享，一同进步。

欢迎关注同名微信公共号，共同进步。

对于个人而言，数据可视化是我们在日常工作中常常能够接触到的一项重要技能，通常，我们会使用Excel进行简单的图表制作，通过这些图表，我们进而就对这些数据有了一个直观的了解和认识。

而对于企业来说，想要“读懂”存储在服务器上的大量业务数据，绝不是Excel能够完成的，这需要数据处理、分析、可视化呈现等一整套解决方案。因此，在实施大数据战略，或者说部署数据分析产品时，很多企业都会有这样的疑问：如何处理海量的业务数据？借助什么样的分析手段才能发现数据价值？如何确保数据可视化分析过程中的实时性？在第九届中国数据库技术大会（DTCC 2018）现场，DataHuner CTO马珂就针对这些问题进行了讲解。

本次分享，马珂从企业内的真实业务场景出发并结合测试实例，逐步介绍大数据时代下，数据可视化分析的技术架构与组成。同时，马柯详细介绍了探索式分析、实时数据分析的技术原理及企业应对海量数据分析的处理方法。

谈谈数据库性能优化

近些年，数据库技术不断推陈出新，从传统的关系型数据库到NoSQL，或者说从行存储发展到列存储，数据库的查询方式发生了根本性的变化。

关系型数据库，基于存储结构，其在模型定义（ORM）、数据关联（TableJoin）、聚合计算（Group）等方面具有优势，关系型数据库的特性往往也是非关系型数据库的短板；而非关系型数据库在处理海量数据（千万行以上）方面则性能突出。

谈到数据库性能，从算法层面来讲，其实无论哪种数据存储结构，基于算法的优化都已达到极限。目前提升数据库性能的途径，主要集中在IO层面，例如DFS系统、MPP的架构。内存数据库（如Redis）虽然在性能上是一种质的提升，但其持久化所引发的一系列问题，可能会使架构复杂度增加，不一定适用于所有场景。

另外，非关系型数据库向关系型数据库查询（T-SQL）的兼容，例如Hive，确实已经取得了长足的发展，但目前看还不够成熟，暂时无法做到平滑迁移。

还有一个隐含的问题，我们可以以一种娱乐的心态观察一下，即：分布式计算。对于以统计学为基础的数据分析，是一种基于全量数据的计算。所以在这种前提下，分布式计算极有可能是一个伪命题。

在MPP架构中下的RDB中，分布式计算应当是耦合在某些查询当中的，例如count(*)，这实际上是由分布式存储所带来的算法优化。是否也可以通过某种加权算法，来协调其他的聚合算法？然后用架构性能来抵消加权算法所带来的新的复杂度？我相信答案是肯定的。

可视化技术的演进

相对而言，数据分析技术有比较成熟、丰富的理论和实践支撑，而可视化技术则比较匮乏。从定义上来讲，数据可视化主要是为了增强数据的显示效果，方便用户以更加直观的方式查看数据，进而发现数据中隐藏的价值。

近几年，随着显示技术的突飞猛进，包括从显示器、投影仪，到现在的LED巨幅屏幕，VR/AR，全息技术，乃至移动设备和性能的升级，使得数据可视化领域有大量有趣的事情可以做。回到企业场景，我们可以把可视化分为两个层面的问题：即数据分析中的可视化：从报表到分析、数据展示中的可视化：从平面到多维。

大数据时代的到来，也让数据可视化技术得到了更多的关注，但面对海量数据，可视化技术目前仍然存在很多亟待解决的问题，包括海量数据的ETL处理、实时数据处理等。未来，随着人工智能和机器学习技术的快速发展，其与可视化的结合，相信也会是一个重要挑战。

探索式分析技术

数据分析当中的可视化，最直接的表现就是各类图表。其实，我们在借助Excel或其他工具生成图表时，实际上已经在可视化这条路上迈出了第一步。

在数据分析层面，传统的数据分析有明确的目的性，从数据来源、分析方式、输出结果等方面，都是有传统的业务逻辑支持的，按部就班地进行分析即可。但是进入集约化生产之后，如何调优生产、降低成本，这些事情就不是那么明确了。

与此同时，由于前期的数据积累，数据分析师所面对的数据体量也越来越大。如果我们将传统的数据分析称为粗放式分析，那么当前企业所面临的挑战，是对所拥有数据的精耕细作。这种集约化分析就是对数据金矿的深度挖掘，是企业的必经之路。其背后的分析方式，也就自然进入了探索式分析阶段。

在探索式分析中，可视化（或者说各类图表）此时是用户快速捕捉数据特点最有效的途径，在这种场景下，可视化对象是一个结果集（分析结果，小数据），虽然数据量较小，但人类依然无法直接处理。

同时，因为探索式分析需要协同决策，所以对可视化表现的合理性有较高的要求，背后应该有统一的绘图标准，来实现可视化方式的切换。狭义的数据可视化，也就是图表，我们将其抽象为以下几个部分：

坐标系

1. Rectangular Coord(Q-1, Q-All)

2. Polar Coord

3. GEO

度量(Metric)的图形表达

1. Size(Distance, Radian)

2. Direction

3. Extreme(SUM,MAX,MAXMIN)

4. 色彩饱和度

维度(Dimension)的图形表达

1. Delta(Position, Angle)

强调（基于维度）

1. Color

2. Animation

在这个体系下，可以将我们熟悉的几种图表进行建模。这里我们先不考虑“色彩饱和度”和“强调”两方面的参数。

柱图：

Rectangle: [0, 0, 400, 300]

Coordination = Rectangular:Q1

坐标系：第一象限

Metric = Size:Distance;

Direction =[Left, Up];

Extreme = MAXMIN

度量：距离的Size；左向右排列，下到上为正像；参考极值：最大最小值差。

Dimension = Delta:Position, Offset =[0, 0.8];

纬度：位置偏移，位置矫正：0，视觉矫正：0.8（该参数具体表现为柱图的宽度内缩）

饼图：

Rectangle: [0, 0, 200, 200]

Coordin+tion = Polar

坐标系：极坐标系

Metric = Size:Radian; Direction =[Clockwise]; Extreme = SUM

度量：弧度Size；顺时针排列；参考极值：总和

Dimension = Delta:Angle, Offset = [0,1];

纬度：角度偏移，位置矫正：0，视觉矫正：1

极柱图：

Rectangle: [0, 0, 300, 300]

Coordination = Polar

坐标系：极坐标

Metric = Size:Radian, Direction =[Clockwise]; Extreme = MAXMIN

度量：弧度尺寸，顺时针，差极值参考

Dimension = Delta:Position, Offset =[0, 0.8];

纬度：位置偏移，0位置矫正，0.8视觉矫正

在这种可视化体系下，我们首先可以对各类图表的适配能力进行归纳，并对图表的表现能力进行量化，从而形成基于数据集特点的图表推荐算法。前面提到，每一个图表实际是一个模型。我们在基于SaaS的数据分析产品中，会将这个模型与行业、用户使用习惯结合，借助机器学习，最后产生图表的AI算法。

实时的数据可视化分析

如果说探索式分析的可视化，是OLAP的可视化，那么实时数据可视化，可以说是OLTP的可视化。这种情况下，时间维度往往是基础维度，因为OLTP对实时性有较高的要求。所谓实时性，具体体现在时间切面的密度、采样精度等问题上，从而决定了数据窗口的大小。基于B/S的产品结构，我们对像素绘图的性能进行了测试。浏览器端的绘图分2D和3D两种，基本数据如下：

Mac Pro i7 8G Inter Graphic-card

类型|复杂度|FPS

Canvas 2D 400,000 11FPS

Canvas 3D 1,000,000 30FPS

这里面的复杂度，为一次最简绘图，即描绘一个点的动作。由于Canvas3D（WebGL）调用了显卡计算，所以点绘图方式和2D有所不同，这其中还包含了线绘图和自旋计算。WebGL接口所使用的GL是OpenES，与OpenGL同源。

当然，2D和3D绘图可比性不是很高，但通过这两组数据，我们可以基本了解在浏览器端，2D和3D绘图方面我们能够达到的性能上限。在我们实际遇到的客户场景中，有个上限8万点绘图，2FPS刷新率的案例。根据上面的测试数据，我们可以看到，2D性能完全可以满足需求，富裕的算力可以放在优化视觉效果和用户体验上。

此外，三维甚至多维空间中的可视化还处在萌芽的阶段，在这种场景下，会让数据可视化变得更加困难。未来，随着可视化技术的不断发展，我相信三维空间下的可视化理论会有大幅升级，同时由于显卡GPU的支持，其渲染能力也会大幅度提升。

今天的分享就到这里，感谢大家聆听。

一 数据分析处理需求分类

1 事务型处理

在我们实际生活中，事务型数据处理需求非常常见，例如：淘宝网站交易系统、12306网站火车票交易系统、超市POS系统等都属于事务型数据处理系统。

这类系统数据处理特点包括以下几点：

一是事务处理型操作都是细粒度操作，每次事务处理涉及数据量都很小。

二是计算相对简单，一般只有少数几步操作组成，比如修改某行的某列;

三是事务型处理操作涉及数据的增、删、改、查，对事务完整性和数据一致性要求非常高。

四是事务性操作都是实时交互式操作，至少能在几秒内执行完成;

五是基于以上特点，索引是支撑事务型处理一个非常重要的技术。

在数据量和并发交易量不大情况下，一般依托单机版关系型数据库，例如ORACLE、MYSQL、SQLSERVER，再加数据复制(DataGurad、 RMAN、MySQL数据复制等)等高可用措施即可满足业务需求。

在数据量和并发交易量增加情况下，一般可以采用ORALCE RAC集群方式或者是通过硬件升级(采用小型机、大型机等，如银行系统、运营商计费系统、证卷系统)来支撑。

事务型操作在淘宝、12306等互联网企业中，由于数据量大、访问并发量高，必然采用分布式技术来应对，这样就带来了分布式事务处理问题，而分布式事务处理很难做到高效，因此一般采用根据业务应用特点来开发专用的系统来解决本问题。

2 数据统计分析

数据统计主要是被各类企业通过分析自己的销售记录等企业日常的运营数据，以辅助企业管理层来进行运营决策。典型的使用场景有：周报表、月报表等固定时间提供给领导的各类统计报表;市场营销部门，通过各种维度组合进行统计分析，以制定相应的营销策略等。

数据统计分析特点包括以下几点：

一是数据统计一般涉及大量数据的聚合运算，每次统计涉及数据量会比较大。

二是数据统计分析计算相对复杂，例如会涉及大量goupby、 子查询、嵌套查询、窗口函数、聚合函数、排序等;有些复杂统计可能需要编写SQL脚本才能实现。

三是数据统计分析实时性相对没有事务型操作要求高。但除固定报表外，目前越来越多的用户希望能做做到交互式实时统计;

传统的数据统计分析主要采用基于MPP并行数据库的数据仓库技术。主要采用维度模型，通过预计算等方法，把数据整理成适合统计分析的结构来实现高性能的数据统计分析，以支持可以通过下钻和上卷操作，实现各种维度组合以及各种粒度的统计分析。

另外目前在数据统计分析领域，为了满足交互式统计分析需求，基于内存计算的数据库仓库系统也成为一个发展趋势，例如SAP的HANA平台。

3 数据挖掘

数据挖掘主要是根据商业目标，采用数据挖掘算法自动从海量数据中发现隐含在海量数据中的规律和知识。

数据挖掘主要过程是：根据分析挖掘目标，从数据库中把数据提取出来，然后经过ETL组织成适合分析挖掘算法使用宽表，然后利用数据挖掘软件进行挖掘。传统的数据挖掘软件，一般只能支持在单机上进行小规模数据处理,受此限制传统数据分析挖掘一般会采用抽样方式来减少数据分析规模。

数据挖掘的计算复杂度和灵活度远远超过前两类需求。一是由于数据挖掘问题开放性，导致数据挖掘会涉及大量衍生变量计算，衍生变量多变导致数据预处理计算复杂性;二是很多数据挖掘算法本身就比较复杂，计算量就很大，特别是大量机器学习算法，都是迭代计算，需要通过多次迭代来求最优解，例如K-means聚类算法、PageRank算法等。

因此总体来讲，数据分析挖掘的特点是:

1、数据挖掘的整个计算更复杂，一般是由多个步骤组成计算流，多个计算步骤之间存在数据交换，也就是会产生大量中间结果，难以用一条sql语句来表达。

2、计算应该能够非常灵活表达，很多需要利用高级语言编程实现。

二 大数据背景下事务型处理系统相关技术

在google、facebook、taobao等大互联网公司出现之后，这些公司注册和在线用户数量都非长大，因此该公司交易系统需要解决“海量数据+高并发+数据一致性+高可用性”的问题。

为了解决该问题，从目前资料来看，其实没有一个通用的解决方案，各大公司都会根据自己业务特点定制开发相应的系统,但是常用的思路主要包括以下几点：

(1)数据库分片，结合业务和数据特点将数据分布在多台机器上。

(2)利用缓存等机制，尽量利用内存，解决高并发时遇到的随机IO效率问题。

(3)结合数据复制等技术实现读写分离，以及提高系统可用性。

(4)大量采用异步处理机制，对应高并发冲击。

(5)根据实际业务需求，尽量避免分布式事务。

1相关系统介绍

1) 阿里CORBAR系统

阿里COBAR系统是一个基于MYSQL数据库的分布式数据库系统，属于基于分布式数据库中间件的分布式数据库系统。该系统是前身是陈思儒开发的“变形虫”系统(以前调研过)，由于陈思儒离开阿里去了盛大，阿里当心“变形虫”稳定性等问题，重新开发该项目。

该系统主要采用数据库分片思路，实现了：数据拆分、读写分离、复制等功能。由于此系统由于只需要满足事务型操作即可，因此相对真正并行数据库集群(例如TeraData等)，此类系统提供操作没有也不需要提供一些复杂跨库处理，因此该系统存在以下限制：

(1)不支持跨库的join、分页、排序、子查询。

(2)insert等变更语句必须包括拆分字段等。

(3)应该不支持跨机事务(以前变形虫不支持)。

说白了此类系统不具备并行计算能力,基本上相当于数据库路由器!

另外此类系统的在实际应用的关键问题是，根据什么对数据进行切分，因为切分不好会导致分布式的事务问题。

2) 阿里OceanBase系统

该系统也是淘宝为了解决高并发、大数据环境下事务型处理而定制开发的一个系统。该系统主要思路和特点如下：

(1)他们发现在实际生成环境中，每天更新的数据只占总体数据的1%不到，因此他们把数据分为：基线数据和增量更新数据。

(2)基线数据是静态数据，采用分布式存储方式进行存储。

(3)只在一台服务器上存储和处理增量更新数据，并且是在内存中存储和处理更新数据。

(4)在系统负载轻的时候，把增量更新批量合并到基线数据中。

(5)数据访问时同时访问基线数据和增量更新数据并合并。

因此这样好处是：

(1)读事务和写事务分离

(2)通过牺牲一点扩展性(写是一个单点)，来避免分布式事务处理。

说明：该系统虽然能处理高并发的事务型处理，号称很牛逼，但其实也只是根据电商的事务处理来定制开发的专用系统，个人认为其技术难度小于oracle等通用型的数据库。该系统无法应用到银行或者12306等，因为其事务处理的逻辑远远比电商商品买卖处理逻辑复杂。

在目前的大数据时代，一定是基于应用定制才能找到好的解决方案!

3) 基于Hbase的交易系统

在hadoop平台下，HBASE数据库是一个分布式KV数据库，属于实时数据库范畴。支付宝目前支付记录就是存储在HBASE数据库中。

HBASE数据库接口是非SQL接口，而是KV操作接口(基于Key的访问和基于key范围的scan操作)，因此HBASE数据库虽然可扩展性非常好，但是由于其接口限制导致该数据库能支持上层应用很窄。基于HBASE应用的设计中，关键点是key的设计，要根据需要支持的应用来设计key的组成。

可以认为HBASE数据库只支持作为KEY的这一列的索引。虽然目前HBASE有支持二级索引的方案，二级索引维护将会比较麻烦。

2并发和并行区别

并发是指同时执行通常不相关的各种任务，例如交易型系统典型属于高并发系统。

并行是通过将一个很大的计算任务，划分为多个小的计算任务，然后多个小计算任务的并行执行，来缩短该计算任务计算时间。

两者主要区别在于：

(1)通讯与协调方面：在并行计算中，由于多个小任务同属一个大的计算任务，因此小任务之间存在依赖关系，小任务之间需要大量通讯和协调;相反，并发中的多个任务之间基本相互独立，任务与任务之间相关性很小。

(2)容错处理方面：由于并发任务之间相互独立，某个任务执行失败并不会影响其它的任务。但是并行计算中的多个任务属于一个大任务，因此某个子任务的失败，如果不能恢复(粗粒度容错与细粒度容错)，则整个任务都会失败。

3本章总结

数据量大不一定需要并行计算，虽然数据量大，数据是分布存储，但是如果每次操作基本上还是针对少量数据，因此每次操作基本上都是在一台服务器上完成，不涉及并行计算。只是需要通过数据复制、数据缓存、异步处理等方式来支撑高并发访问量

三 大数据背景下数据统计分析技术介绍

随数据量变大，和事务处理不同的是，单个统计分析涉及数据量会非常大，单个统计分析任务涉及数据会分散在多台服务器上，且由于计算量大，采用单台服务器进行计算，会导致计算时间非常长，单个统计分析任务必须采用并行计算方式来加快单个统计分析任务执行速度。

1并行查询与并行计算技术介绍

在大数据背景下的数据统计分析技术门类很多，常见的有：

n MPP并行数据库 : TeraData、GreenPlum、Vertica等。

n 基于MapReduce并行计算框架的数据仓库：

HIVE(Hadoop平台) 、Tenzing(Google公司)

n 基于Hbase的Phoenix系统

n HadoopDB系统

n EMC公司的hapt系统

n MPP分布式查询引擎： Dremel、Impala、Presto、Shard query、Citusdb。

n 基于SPARK的Shark、基于Dryad的SCOPE、基于Tez的stinger。

n 基于hadoop+index的JethroData系统

n 基于内存计算的Druid系统

这些系统都解决了海量数据下的数据统计分析的问题，并且这些系统另外一个共同特点是都提供了SQL或者类SQL接口。

为了能够较好研究这些系统，我们需要对并行查询与并行计算的相关技术做一个简要的介绍。

首先所有的系统都可以分为三个层次: 语义层、并行计算引擎层、分布式存储层。语义层提供一个编程接口让用户表达所需要计算，并负责把该计算翻译成底层并行计算引擎可以执行的执行计划，并由并行计算引擎来执行，最下面一层是分布式存储层。

对于提供类SQL接口并行计算系统，语义层可以认为是SQL解析层。

1) 语义层

SQL语言是一种声名式语言，SQL只是表达了要做什么，而没有表达怎么做。为此，SQL解析层主要作用是：将用户提交的基于SQL的统计分析请求，转化为底层计算引擎层可以执行的执行计划。也就是解决“怎么做”的问题。

SQL解析层工作主要包括两个大方面:

(1) 通过语法分析技术来理解要做什么。在关系数据库中，一般会把SQL语言分析后，形成树型结构的执行计划。

(2) 在语法分析技术上，利用各种优化技术和算法，找出一种最经济物理执行计划。

优化可以分为两个方面：一是逻辑层面优化、二是物理执行层面优化。

(1) 逻辑层优化

逻辑层面个人认为主要是因为同样表达一个分析请求，有的人SQL写的好，有的人SQL写的烂，因此在逻辑层面可以通过一些等价关系代数变换，实现查询重写，将写的比较烂的sql变换为好的写法。

比较典型优化是：“把投影和过滤下沉，先执行过滤和投影操作”，减少中间结果。

(2) 物理层优化

物理层面优化是在逻辑优化后，结合实际物理执行过程，找出最优的物理执行计划。生成物理查询计划的工作包括:

ü 增加一些操作符： 包括扫描和排序等。

ü 确定各个操作符实现算法。例如扫描是全表扫描还是利用索引;Join是采用HASH连接、索引连接、合并排序等实现算法中的那一种。

ü 确定操作符之间的数据流转方法：物化还是流水线方式。

ü 采用基于代价估算方法确定最优的物理执行计划，目前代价估算主要是以估算该物理计划需要的IO量。另外对于并行数据库，则还要考虑通讯代价，即尽量减少数据在各个机器之间的传递。

在物理层优化的代价估算过程中，代价估算需要依靠很多统计信息，如表有多大，表中相关列的值分布是什么样子等。传统数据库在数据Load过程中会事先计算好这些统计信息。并行计算中还需要考虑通讯代价。

需要指出是，由于imapla、Presto、HIVE等系统只是一个查询引擎，它们可以直接查询以普通文件方式存储在HDFS系统上的文件，因此这些系统一般无法使用索引和各种统计信息来进行物理执行计划的优化，这些系统一般只能在逻辑层进行一些基于规则静态优化。根据SHARK论文，SHARK系统支持根据前面一些节点计算获得的信息，来动态优化后面执行计划。

(3) 物化与流水线执行方法

一条SQL语句对开发人员而言，感觉只是一次调用，但是实际上在数据库内部，一条SQL语句执行其实是有多个操作符组合而成的的树型结构计算流。如下图：

针对该计算流有两种执行方式：一是基于物化或者是实体化执行方式，另外一种是基于数据流的执行方式。

第一种方法的过程是： 把各个操作运算排序，并把每个操作运算的输出的中间结果存储在磁盘上，直到被另外一个操作运算所...