【转载】数据杂谈

http://www.36dsj.com/archives/42783

前言

记得几年前，曾经有人预测过将来最流行的三大技术：大数据、高并发、数据挖掘。到如今来看，这三种技术的确也随着这几年互联网的发展变得愈加成熟和可靠。掌握这三种技术的人，无论是求职仍是创业，都属于香饽饽。一个很深的印象就是当年研究生毕业的时候，专业是数据挖掘、大数据的学生都比较受各类企业的青睐，无论他是否是真的掌握了这些东西。虽然我对大部分高校的相关专业持怀疑态度，可是却也不得不认可，这些专业的确改变了不少东西，也给不少学生镀上了一层金。

本身一直从事的是Java EE中间件、基础架构等方面的研发工做，对数据这一块只是略知皮毛，在前东家的时候我也没有机会接触数据平台。但因为现公司业务的缘由，却不得不去触碰这一块，到目前为止也就仅仅半年时间(其间穿插各类协调、管理的琐事)。所以，数据相关的东西对我来讲彻底是一个新的领域，算是离开了本身的温馨区。不过，逃离温馨区这个想一想也挺兴奋的。

数据

什么是数据?

最近有一本很火的书叫《精益数据分析》，其核心的一个观点就是：须要用数据驱动产品和公司的发展，而不能靠直觉或者拍脑壳。可见，数据是多么的重要。在一个产品的生命周期中，会产生不少数据：用户信息、用户行为信息、ugc数据等等。这些数据表现形式能够为文字、图片、日志、视频、音频等等。

从技术角度来说，数据通常分为结构化数据、半结构化数据和非结构化数据。

结构化数据：指的是行数据库能够存储的，数据具备相同的字段，以及相同的存储大小,能够用二维表的逻辑结构来表达实现。

半结构化数据：半结构化数据，指的总体上是结构化数据形式，但字段数目不定，数据结构和内容混杂在一块儿。

非结构化数据：不方便用二维表描述的数据，如各类文档、图片、音/视频等。

能用来干什么?-数据挖掘

说到数据的做用，不得不提数据分析师这个职位。此职位通常来讲倾向的是数学相关专业人士，使用数据来指导产品、运营、市场等工做，是公司中使用数据最多的人。在公司中，市场运营销售这几个部门也都是和数据关系很密切的。市场须要参考数据分析哪个渠道推广效果更好，运营部门须要根据数据分析什么内容更能提升产品的活跃度，销售部门则须要数据反映公司的收入状况。固然，除了这些，数据挖掘就是另外一个很重要的使用数据的方面了，可使用数据对用户进行行为分析，从而挖掘用户的兴趣，最终达到精准推荐、精准营销的目的。

归纳来看，数据的做用就是数据挖掘，就是试图从海量数据中找出有用的知识，也能够称为“知识发现”。数据挖掘的支撑技术主要包含统计学以及机器学习两方面。从这个角度来看，数据主要有如下两点做用：

数据统计：经过对数据的统计计算出一些和产品、用户相关的指标，从而指导产品、市场、运营、销售工做。

机器学习：使用相关技术让机器经过已有的数据学习到新的有用的知识。好比：从已有的用户行为数据分析获得用户的兴趣、爱好等信息，从而进一步实现用户个性化推荐。个性化推荐也是机器学习目前使用数据最为普遍的一点。

数据库&&数据仓库

有了数据，就须要有存放数据的地方。数据库和数据仓库即存放数据库的两种形式。二者在本质上没有区别，都是为了存储数据。

数据库：面向业务设计，通常针对的是在线业务，存储的是在线业务数据。如：Oracle、DB二、MySQL、Sybase、MS SQL Server等。能够分为：关系型数据库和NoSql数据库，其中后者又可分为KV数据库、文档型数据库、列数据库。

数据仓库：是数据库概念的升级，面向分析，存储的是历史数据。从数据量来讲，数据仓库要比数据库更庞大得多。主要用于数据挖掘和数据分析，表明软件为Hive。

ETL: 数据仓库不少时候是须要从其余地方传输数据到数据仓库，这个过程就是ETL：extract-抽取、transform-转换、load-加载。

数据的生命周期

不管是历史数据仍是线上数据，都是有生命周期的。好比，对于一个产品的用户活跃度统计业务，最近半年的数据是热点数据，访问较频繁;而随着时间的推移，慢慢的这些数据再也不被频繁关注，变为了通常数据;再随着时间的推移，总有一天这些数据再也不会被关注就成为了冷数据。

热点数据→通常数据→冷数据，这就是数据的一个生命周期，对于不一样的生命周期，所须要的技术选型也应该不同。

数据系统

无论是数据统计仍是数据挖掘，构建一个数据系统都是作好这些的前提。通常来讲，构建一个完备的数据系统有如下几点：

数据采集

不管是移动端仍是web上，要作好数据采集集最重要的一点就是埋点。也就是要在你须要采集数据的地方作一个标记，向服务端发起一个日志请求。固然，对于服务端可以经过业务逻辑获取的内容，原则上不要打点。好比，统计某一篇新闻的阅读数目、点赞数，这些行为其实在用户打开此新闻、点赞时已经发起了服务端请求，不须要再埋一个点;此外，统计用户数目这种，在用户数据库中就能够计算出来，也不须要埋点。埋点主要针对的是经过产品的业务逻辑没法获取到的一些数据，如一个站点中某一个模块的pv、uv等。

埋点后向服务端发起日志请求，这些请求在用户量规模并不很大的架构设计中直接实时计算数据入库便可，可是在用户请求量很大的状况下，这种设计是有问题的，会增长业务请求的压力，从而影响线上服务，所以好的设计应该是数据请求只造成一条日志(通常经过nginx日志实现)。所以，这里很关键的一点就是如何将这些日志收集起来进行处理。目前经常使用的技术有flume、Scribe、Chukwa等。其中，flume是目前比较成熟且应用比较普遍的方案。

因为从数据源到来的数据并不必定是咱们处理须要的数据或者数据格式，所以这里还有数据的清洗过程，包括分析，验证，清洗，转换，去重，

数据队列

数据采集以后须要经过数据队列传输，这里的队列主要起的是缓冲做用以及其余非采集数据源的输入(好比某一业务逻辑产生了一条统计报文，能够直接写入队列中)，能够采起本地队列或者分布式队列。目前，比较成熟的队列有kafka、rabbitMQ等。其中，在数据统计领域kafka是应用比较普遍的。

数据处理

对于采集到的数据，不少是须要计算才能获得须要的统计结果的。这时候就牵扯到了计算模型。这里分为离线计算和实时计算两种模型。离线计算针对实时来说，就是非实时的，能够定时调度进行计算的，通常来讲是耗时比较长，对结果需求没那么实时的业务场景，适合非线上业务;实时计算则是须要在数据一到达就开始进行计算、处理的，适合对实时性要求高的一些业务场景，好比广告的实时结算等。

数据存储

服务端在数据统计中一个关键的功能是对采集到的内容进行存储。对于中小规模的数据，使用mysql等传统数据库便可应对，大一点规模采用分表、分库也能应对。再大一点的那就只能祭出大数据数据库了。此外，数据的存储结构也须要慎重考虑，尤为是在应对多维度查询的时候，不合理的数据结构设计会致使低下的查询效率和冗余的存储空间。

数据可视化

数据存储的下一步是要把数据展现出来，也就是数据可视化。一般状况下，导出excel表格是一种形式，此外，web端/移动端甚至pc端也须要展现数据的话，就引出了数据可视化技术，尤为是在大数据量状况下如何更加高效快速地展现数据。

数据采集+数据队列+数据处理+数据存储+数据可视化即组成了一个完整的数据系统。而从本质上来看，数据系统=数据+查询，万变不离其宗。

对于通常规模的产品，数据其实远远没有达到须要使用大数据技术的地步。使用传统的收集数据→定时调度程序计算，存储到mysql中便可解决。若是有大的并发请求，那么使用数据队列作缓冲。当数据规模大到必定规模时，例如mysql数据库在分表分库的状况下，单表数据量仍是达到了千万的规模、单机存储依然不够或者单机计算已经慢到没法容忍。应对这种状况，就须要分布式技术出场了。

说到这里，借用《计算广告》一书中所讲，对于数据分为三种：

小规模数据：此种数据能够经过采样部分数据便可反映出数据的特征。这时候，根本无需什么大数据技术，单机规模的传统数据系统架构便可应对这种场景。

中等规模数据：小规模数据没法反应数据特征，当数据规模达到必定规模时，再增大特征趋向于平稳，那么此时也无需大数据技术的出场。

大规模数据：不能经过采样来反应数据特征，必须全量采集数据才能获取到数据特征。此时，就须要大数据技术来解决问题。

其中，大规模数据就不是通常架构能够解决的了的了。

大数据

麦肯锡的《大数据：创新、竞争和生产力的下一个前沿领域》中对大数据的定义：

大数据指的是规模超过现有数据库工具获取、存储、管理和分析能力的数据集，并同时强调并非超过某个特定数量级的数据集才是大数据。

大数据系统一般被认为具备数据的五个主要特征，一般称为数据的5Vs。分别是大规模，多样性，高效性、准确性和价值性。

相关技术

大数据是一个很宽泛的概念。当单机没法处理数据时，就有了大数据。而应对各类不一样的业务场景，诞生了不少不一样的软件。完成一个功能完备的系统须要多个软件的组合。

文件/数据存储

传统的文件存储都是单机的，不能横跨不一样的机器，通常会使用raid作安全冗余保障。可是仍是没法从根本上解决问题。HDFS(Hadoop Distributed FileSystem)则是为了应对这种业务场景产生的，其基本原理来自于google的gfs，让大量的数据能够横跨成千上百万台机器。可是对用户来讲，看到的文件和单机没任何区别，已经屏蔽掉了底层细节。

除了文件存储，还有数据的存储，即数据库。传统的mysql等数据库，在存储结构化、小规模数据的时候能够妥妥应对。但当须要存储半结构化或者非结构化数据，或者用分表、分库来解决存储性能、空间问题带来了复杂的管理、join时，就须要一种更好的数据库的出现。大数据领域的Hbase就是为了这种场景产生的，其原理是google的BigTable。固然，hbase底层仍是依赖于hdfs，是一个针对半结构化、非结构化、稀疏的数据的数据库。

此外，hbase和hdfs相比起mysql这种毫秒级数据库，其响应速度是很慢的。若是线上业务场景须要使用这些数据，那么这时候就须要更好的数据库的出现。elasticserach就是其中的佼佼者，固然，使用这种基于索引、高效的查询数据库，并不建议存储全量数据(除非你钱有的是)。通常状况下，存储热点数据便可。

离线数据处理

大数据的处理是很是关键的一个环节。当单机的处理程序没法在指望的时间内处理完数据时，就须要考虑使用分布式技术了。因而就出现了MapReduce、Tez、Spark这些技术。MapReduce是第一代计算引擎，Tez和Spark是第二代。MapReduce的设计，采用了很简化的计算模型，只有Map和Reduce两个计算过程(中间用Shuffle串联)，用这个模型，已经能够处理大数据领域很大一部分问题了。可是，MR模型很简单，但也很笨重，有很多缺点，好比：编程模型很是复杂;计算过程磁盘IO过多。因而催生出了第二代数据处理技术，Tez、Spark这些鉴于MR模型的缺点，引入了内存cache之类新的feature，让Map和Reduce之间的界限更模糊，数据交换更灵活，更少的磁盘读写，以便更方便地描述复杂算法，取得更高的吞吐量。

如上面所说，编写MR的编程复杂度很是高，因而就产生了Hive、Pig，在MR上面又抽象了一层更高级的语法出来，大大简化了MR的编程复杂度。其中以Hive为表明是Sql on xx的一个典型应用。之因此使用sql，一方面是容易编写、容易维护;另外一方面SQL可让没有编程技能的诸如数据分析师均可以不依赖工程师就可使用数据。但因为一开始的hive仍是基于MR之上的，所以，其运算速度仍是受到很多人的诟病。因而Hive on Tez / Spark和SparkSQL也出现了。它们都旨在用新一代通用计算引擎Tez或者Spark来跑SQL，这样就避免了基于MR带来的运算瓶颈。

对于程序的离线数据处理，hive通常状况下都可以知足需求。可是对于数据分析师的数据分析需求来讲，这速度就真的有点龟速了。所以为了应对数据分析的需求，Impala、Presto、Drill这些交互式sql引擎应运而生。这些系统的惟一目标就是快，可以让用户更快速地处理SQL任务，所以牺牲了通用性稳定性等特性。

一个典型的数据仓库系统能够知足中低速数据处理的需求：底层HDFS，之上是MR、Tez、Spark,再上面则是Hive、Pig;此外，直接跑在HDFS上的Presto、Impala等也是另外一种方案。

因为是离线计算，所以是须要一个任务调度工具来定时调度计算过程的。比较流行的一个任务调度工具是azkaban，是一个基于工做流的调度软件，在必定程度上可以知足目前的离线调度需求。

实时计算

上面说的都是数据仓库以及离线处理需求，也是低速数据处理需求。对于高速的数据处理，则须要引出实时计算的概念，也叫流式计算。目前，storm是比较成熟和流行的流式计算技术，spark streaming则是另一种基于批量计算的流式计算技术。所谓流式计算，就是指数据过来的时候马上进行处理，基本无延迟，可是不够灵活，计算过的数据也不能回放，所以也没法替代上面说的数据仓库和离线计算技术。

资源调度

综上的全部东西都在同一个集群上运行，须要达到一个有序工做的情况。所以，须要一个资源调度系统来调度这些工做，MR2.0带来的yarn就是负责此工做的一个框架。目前，docker on yarn，storm on yarn等on yarn技术的出现都得益于此框架，大大提升了大数据集群的资源使用率。此外，mesos也是另外一种资源调度框架。

协调服务

一个分布式系统可以有条不紊的运行离不开协调服务的功劳。无论是hadoop仍是storm、kakfa等，都是须要经过zookeeper进行协调的。zookeeper在分布式服务中扮演的角色就相似其字面意思-动物园管理员，而大数据的各个组件就相似动物园中的动物们。

集群监控

集群的稳定性对于一个数据系统是相当重要的。所以，集群监控技术也是须要重点考虑的一点。目前，ganglia是对hadoop进行监控一个较好的工具。除了hadoop以外，ganglia也能够对kafka、zookeeper、storm等集群进行监控。固然，只要支持jmx，任何集群都是能够经过ganglia进行监控的。

数据可视化

最近几年，数据可视化是一个很火的概念。尤为是大数据的可视化，考虑到高效、速度以及体验等等问题，并不是是个很简单的事情。目前，百度开源的echarts是比较好的一个可视化前端解决方案，在大数据可视化方面支持的也比较好。

《大数据：可扩展实时系统的原理和最佳实践》一书的做者将big data相关的开源项目作了如下分类：

批量计算系统：延时较高、吞吐量大，如Hadoop。

序列化框架：为对象和字段提供一种模式定义语言，实现传输通讯以及不一样语言环境之间的转化。如Thrift, Protocol Buffers, 和Avro。

支持任意存取的NoSQL数据库：牺牲了SQL强大的表现力优点，根据应用场景不一样仅支持部分操做。按照CAP理论来讲，就是牺牲C(一致性)或A(可用性)来实现AP或CP。如Cassandra, HBase, MongoDB,Voldemort, Riak, CouchDB等。

消息/排队系统：保证进程之间以容错和异步的方式传递消息，在实时处理系统中很是重要。如Kestrel。

实时计算系统：高吞吐、低延时的流处理系统。如Storm。

通常架构

下图为一个典型的大数据系统架构：

 

这里还须要提到的是Lambda架构这个概念。Lambda架构是由Storm的做者Nathan Marz提出的一个实时大数据处理框架。目标是设计出一个能知足实时大数据系统关键特性的架构，包括有：高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算，融合不可变性(Immunability)，读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各种大数据组件。

 

 

Lambda架构是由三层组成：批处理层、服务层和速度层，整体可由query = function(alldata)这个公式来表示。

 

批处理层：Hadoop是理想的批处理层工具。特色是延时较高、高吞吐量，而且是append-only(没有delete和update的概念)的。包括对所有数据集的预计算。

服务层：用于加载和显示数据库中的批处理视图，以便用户可以查询。可使用Impala做为这一层的工具(使用Hive元数据指向HDFS中的一个表)。

速度层：主要处理新数据和服务层更新形成的高延迟补偿，利用流处理系统如 (Storm, Spark)计算实时视图(HBase)。这些视图有效期一直到它们已经能经过批处理和服务层得到时为止。

为了得到一个完整结果，批处理和实时视图都必须被同时查询和融合(实时表明新数据)。

固然，架构的引入是不能照本宣科的，仍是须要根据实际状况进行调整，以更好地适应业务场景。

数据统计

数据统计是数据首当其冲的一个做用。关于数据统计，有如下几个关键点：

数据统计是业务导向的，须要和数据分析师、运营、市场等需求方作好充分的沟通，且很关键的一点要区分清楚哪些是真正的需求，哪些仅仅是临时需求，对于前者须要以对待产品的态度去对待，后者则一过性产生结果便可。

数据统计通常来讲都是pv、uv这些累加指标。使用数据库自带的累加器便可，如hbase/redis的incr。

数据统计在牵扯到用户、IP时，有些业务是须要去重的。去重的方案有bitmap、bloomfilter等，其中，redis的hyperloglog在允许必定偏差的状况下使用比较普遍。

用户统计中的用户质量模型是比较复杂的一个地方。这个地方须要必定的建模，才能作到更好的判断一个用户的质量。一般，把一个新增用户一周内以及一周后的活跃状况做为这个用户质量的判别标准。

个性化推荐

因为个性化推荐是“机器学习”的典型应用，所以这里首先要讲一下“机器学习”。

机器学习是为了让机器具备人的学习能力，目的是建模隐藏的数据结构，而后作识别、预测、分类等。大多数状况下，这至关于将一组数据传递给算法，并由算法判断出与这些数据的属性相关的信息，借助这些信息能够预测出将来有可能出现的其余数据。对于机器学习普遍的一个定义是“利用经验来改善计算机系统自身的性能”，而计算机中的经验都是以数据的形式存在的。机器学习的一个典型过程就是机器利用它所认定的出现于数据中的重要特征对数据进行“训练”，并借此获得一个模型。

此外，与机器学习相关的还有几个名词会被混淆或者概念不清。

集体智慧：简称集智，它是一种共享的或群体的智能。百度百科、维基百科、百度知道、猪八戒网等都是目前使用集体智慧的一种形式;数据挖掘、机器学习一样须要大量群体的数据才能作出计算，是使用集体智慧的另外一种形式。

数据挖掘：数据挖掘就是试图从海量数据中找出有用的信息。数据挖掘支撑技术包含了机器学习、数据库、统计学等。其中，数据库提供数据管理技术，机器学习和统计学提供了数据分析技术。可是因为机器学习并不以大数据做为处理对象，所以数据挖掘要对算法进行改造，使得算法性能和空间占用达到实用的地步。

模式识别：模式识别是一种目的。传统的模式识别的方法通常分为两种：统计方法和句法方法。句法分析通常是不可学习的，而统计分析则是发展了很多机器学习的方法。所以机器学习给模式识别提供了数据分析技术。固然，也就是由于几乎全部的非随机数据都会包含这样或者那样的“模式(pattern)”，才使得机器学习的预测是可能的。

总之，机器学习也是使用数据的一个很关键的领域，典型应用有个性化推荐、CTR预估、模式识别等。牵扯到的算法、技术很是多。如此部分开头所说，其中的个性化推荐是应用最普遍的领域，用到了不少机器学习相关技术。

从本质上看，个性化推荐和你们接触很广泛的搜索引擎是同样的，一样是为了解决信息过载的问题。搜索引擎某种意义上也是一个个性化推荐系统，其输入特征是从搜索关键字能够直接获得的。而个性化推荐中，输入特征则是须要使用机器学习相关技术才能获得。

个性化推荐系统通常由日志系统、推荐算法、内容展现UI三部分组成。

日志系统：这是推荐系统的输入源，是一个推荐系统全部信息的源头。

推荐算法：这是推荐系统的核心，根据输入数据得出最终的推荐结果的具体过程就在这里。

内容展现UI：对于推荐结果如何展现，也是一个值得权衡的地方。以更好地知足推荐系统的目标，并能更好的收集用户的行为信息等。

其中，个性化推荐中最为核心的推荐算法，目前比较流行的有如下几种：

基于内容的推荐：根据内容自己的属性(特征向量)所做的推荐。

基于关联规则的推荐：“啤酒与尿布”的方式，是一种动态的推荐，可以实时对用户的行为做出推荐。

协同过滤推荐：与基于关联规则的推荐相比是一种静态方式的推荐，是根据用户已有的历史行为做分析的基础上作的推荐。可分为物品协同过滤、用户协同过滤、基于模型的协同过滤。其中，基于模型的协同又能够分为如下几种类型：基于距离的协同过滤;基于矩阵分解的协同过滤，即Latent Factor Model(SVD);基于图模型协同，即Graph，也叫社会网络图模型。

个性化推荐系统的典型架构以下图所示：

 

在线业务系统的日志接入数据高速公路，再由数据高速公路迅速运转到离线数据处理平台和在线流计算平台;离线数据处理平台周期性地以批处理方式加工过去一段时间的数据，获得人群标签和其余模型参数，存放在高速缓存中，供在线业务系统使用，与此同时，在线流计算平台实时对线上的日志数据作处理，对离线计算出的数据进行补充、修正等;在线业务系统综合离线特征和在线特征使用必定的逻辑获得输出供业务使用，产生的日志流入数据高速公路。

 

基于此框架，个性化推荐系统的典型流程以下：

 

其余更为详细的，个性化推荐牵扯到的算法、细节还有不少，留待后续推荐系统相关文章中再谈。

 

总结

不管是互联网仍是其余领域的产品，数据的做用正变得愈来愈重要。综合来看，数据统计和机器学习/个性化推荐是目前最关键的使用数据的领域。基于具体的需求，搭建合适的数据系统是解决问题的关键。其中，大数据是在应对大规模数据的状况下合适的技术选型架构。