数据杂谈

数据

什么是数据？

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

从技术角度来讲，数据一般分为结构化数据、半结构化数据和非结构化数据。

• 结构化数据：指的是行数据库可以存储的，数据具有相同的字段，以及相同的存储大小,可以用二维表的逻辑结构来表达实现。
• 半结构化数据：半结构化数据，指的整体上是结构化数据形式，但字段数目不定，数据结构和内容混杂在一起。
• 非结构化数据：不方便用二维表描述的数据，如各种文档、图片、音/视频等。

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

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

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

• 数据统计：通过对数据的统计计算出一些和产品、用户相关的指标，从而指导产品、市场、运营、销售工作。
• 机器学习：使用相关技术让机器通过已有的数据学习到新的有用的知识。比如：从已有的用户行为数据分析得到用户的兴趣、爱好等信息，从而进一步实现用户个性化推荐。个性化推荐也是机器学习目前使用数据最为广泛的一点。

数据库&&数据仓库

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

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

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

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

数据的生命周期

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

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

数据系统

不管是数据统计还是数据挖掘，构建一个数据系统都是做好这些的前提。一般来说，构建一个完备的数据系统有以下几点：

1. 数据采集

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

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

   由于从数据源到来的数据并不一定是我们处理需要的数据或者数据格式，因此这里还有数据的清洗过程，包括分析，验证，清洗，转换，去重，

2. 数据队列

   数据采集之后需要通过数据队列传输，这里的队列主要起的是缓冲作用以及其他非采集数据源的输入(比如某一业务逻辑产生了一条统计报文，可以直接写入队列中)，可以采取本地队列或者分布式队列。目前，比较成熟的队列有kafka、rabbitMQ等。其中，在数据统计领域kafka是应用比较广泛的。

3. 数据处理

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

4. 数据存储

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

5. 数据可视化

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

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

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

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

• 小规模数据：此种数据可以通过采样部分数据即可反映出数据的特征。这时候，根本无需什么大数据技术，单机规模的传统数据系统架构即可应对这种场景。
• 中等规模数据：小规模数据无法反应数据特征，当数据规模达到一定规模时，再增大特征趋向于平稳，那么此时也无需大数据技术的出场。
• 大规模数据：不能通过采样来反应数据特征，必须全量采集数据才能获取到数据特征。此时，就需要大数据技术来解决问题。

其中，大规模数据就不是一般架构可以解决的了的了。

大数据

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

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

 

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

相关技术

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

1. 文件/数据存储

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

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

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

2. 离线数据处理

   大数据的处理是非常关键的一个环节。当单机的处理程序无法在期望的时间内处理完数据时，就需要考虑使用分布式技术了。于是就出现了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，是一个基于工作流的调度软件，在一定程度上能够满足目前的离线调度需求。

3. 实时计算

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

4. 资源调度

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

5. 协调服务

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

6. 集群监控

   集群的稳定性对于一个数据系统是至关重要的。因此，集群监控技术也是需要重点考虑的一点。目前，ganglia是对hadoop进行监控一个较好的工具。除了hadoop之外，ganglia也可以对kafka、zookeeper、storm等集群进行监控。当然，只要支持jmx，任何集群都是可以通过ganglia进行监控的。

7. 数据可视化

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

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

1. 批量计算系统：延时较高、吞吐量大，如Hadoop。
2. 序列化框架：为对象和字段提供一种模式定义语言，实现传输通信以及不同语言环境之间的转化。如Thrift, Protocol Buffers, 和Avro。
3. 支持任意存取的NoSQL数据库：牺牲了SQL强大的表现力优势，根据应用场景不同仅支持部分操作。按照CAP理论来说，就是牺牲C（一致性）或A（可用性）来实现AP或CP。如Cassandra, HBase, MongoDB,Voldemort, Riak, CouchDB等。
4. 消息/排队系统：保证进程之间以容错和异步的方式传递消息，在实时处理系统中非常重要。如Kestrel。
5. 实时计算系统：高吞吐、低延时的流处理系统。如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)。这些视图有效期一直到它们已经能通过批处理和服务层获得时为止。

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

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

数据统计

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

1. 数据统计是业务导向的，需要和数据分析师、运营、市场等需求方做好充分的沟通，且很关键的一点要区分清楚哪些是真正的需求，哪些仅仅是临时需求，对于前者需要以对待产品的态度去对待，后者则一过性产生结果即可。
2. 数据统计一般来说都是pv、uv这些累加指标。使用数据库自带的累加器即可，如hbase/redis的incr。
3. 数据统计在牵扯到用户、IP时，有些业务是需要去重的。去重的方案有bitmap、bloomfilter等，其中，redis的hyperloglog在容许一定误差的情况下使用比较广泛。
4. 用户统计中的用户质量模型是比较复杂的一个地方。这个地方需要一定的建模，才能做到更好的判断一个用户的质量。通常，把一个新增用户一周内以及一周后的活跃情况作为这个用户质量的判别标准。

个性化推荐

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

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

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

• 集体智慧：简称集智，它是一种共享的或群体的智能。百度百科、维基百科、百度知道、猪八戒网等都是目前使用集体智慧的一种形式；数据挖掘、机器学习同样需要大量群体的数据才能做出计算，是使用集体智慧的另一种形式。
• 数据挖掘：数据挖掘就是试图从海量数据中找出有用的信息。数据挖掘支撑技术包含了机器学习、数据库、统计学等。其中，数据库提供数据管理技术，机器学习和统计学提供了数据分析技术。但是由于机器学习并不以大数据作为处理对象，因此数据挖掘要对算法进行改造，使得算法性能和空间占用达到实用的地步。
• 模式识别：模式识别是一种目的。传统的模式识别的方法一般分为两种：统计方法和句法方法。句法分析一般是不可学习的，而统计分析则是发展了不少机器学习的方法。因此机器学习给模式识别提供了数据分析技术。当然，也就是因为几乎所有的非随机数据都会包含这样或者那样的“模式(pattern)”，才使得机器学习的预测是可能的。

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

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

个性化推荐系统一般由日志系统、推荐算法、内容展示UI三部分组成。

• 日志系统：这是推荐系统的输入源，是一个推荐系统所有信息的源头。
• 推荐算法：这是推荐系统的核心，根据输入数据得出最终的推荐结果的具体过程就在这里。
• 内容展示UI：对于推荐结果如何展示，也是一个值得权衡的地方。以更好地满足推荐系统的目标，并能更好的收集用户的行为信息等。

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

• 基于内容的推荐：根据内容本身的属性(特征向量)所作的推荐。
• 基于关联规则的推荐：“啤酒与尿布”的方式，是一种动态的推荐，能够实时对用户的行为作出推荐。
• 协同过滤推荐：与基于关联规则的推荐相比是一种静态方式的推荐，是根据用户已有的历史行为作分析的基础上做的推荐。可分为物品协同过滤、用户协同过滤、基于模型的协同过滤。其中，基于模型的协同又可以分为以下几种类型：基于距离的协同过滤；基于矩阵分解的协同过滤，即Latent Factor Model(SVD)；基于图模型协同，即Graph，也叫社会网络图模型。

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

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

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

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

总结

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

参考资料

• 《计算广告》
• 《推荐系统实践》
• 知乎@Xiaoyu Ma的有关回答

 

转：http://www.rowkey.me/blog/2016/02/23/data-talk/