数据分析.docx

数据分析.docx

《数据分析.docx》由会员分享，可在线阅读，更多相关《数据分析.docx（13页珍藏版）》请在冰点文库上搜索。

数据分析

数据分析必须想清楚的两个概念：

指标和维度（转）

指标与维度是数据分析中最常用到的术语，它们是非常基础的，但是又很重要，经常有朋友没有搞清楚它们之间的关系，只有掌握理解了，我们的数据分析工作开展就就容易多了。

现在就来说说指标与维度的那些事。

1、指标

指标，用于衡量事物发展程度的单位或方法，它还有个IT上常用的名字，也就是度量。

例如：

人口数、GDP、收入、用户数、利润率、留存率、覆盖率等。

很多公司都有自己的KPI指标体系，就是通过几个关键指标来衡量公司业务运营情况的好坏。

指标需要经过加和、平均等汇总计算方式得到，并且是需要在一定的前提条件进行汇总计算，如时间、地点、范围，也就是我们常说的统计口径与范围。

指标可以分为绝对数指标和相对数指标，绝对数指标反映的是规模大小的指标，如人口数、GDP、收入、用户数，而相对数指标主要用来反映质量好坏的指标，如利润率、留存率、覆盖率等。

我们分析一个事物发展程度就可以从数量跟质量两个角度入手分析，以全面衡量事物发展程度。

刚才说过，指标用于衡量事物发展程度，那这个程度是好还是坏，这就需要通过不同维度来对比，才能知道是好还是坏。

2、维度

维度：

是事物或现象的某种特征，如性别、地区、时间等都是维度。

其中时间是一种常用、特殊的维度，通过时间前后的对比，就可以知道事物的发展是好了还是坏了，如用户数环比上月增长10%、同比去年同期增长20%，这就是时间上的对比，也称为纵比;

另一个比较就是横比，如不同国家人口数、GDP的比较，不同省份收入、用户数的比较、不同公司、不同部门之间的比较，这些都是同级单位之间的比较，简称横比;

维度可以分为定性维度跟定量维度，也就是根据数据类型来划分，数据类型为字符型（文本型）数据，就是定性维度，如地区、性别都是定性维度;数据类型为数值型数据的，就为定量维度，如收入、年龄、消费等，一般我们对定量维度需要做数值分组处理，也就是数值型数据离散化，这样做的目的是为了使规律更加明显，因为分组越细，规律就越不明显，最后细到成最原始的流水数据，那就无规律可循。

最后强调一点，只有通过事物发展的数量、质量两大方面，从横比、纵比角度进行全方位的比较，我们才能够全面的了解事物发展的好坏。

进一步拓展思考，我理解为指标拆分和维度对比。

其实在实际产品数据分析的过程中也可参照以上思想。

通过大量的数据分析软件工具应用可以发现，主要包括以下内容：

∙整体情况的分析和汇总：

全局数据的概况、变化趋势、占比等

∙多个维度的分析：

如果是日志数据，已经存在多个数据项，以某一个数据项作为主关键词汇总分析，同比、环比变化，占总数的变化。

如果没有日志数据，则需要想清楚解决这个问题原因是什么?

需要采集哪些数据项?

∙重要场景问题的分析:

根据分析的重要问题、用户关心的问题进行分析

∙软硬件性能管理、告警管理、报表管理、基础参数配置和用户管理等等

在多维度分析、告警、报表，数据图表可视化设计呈现方面也存在许多共性，总结如下:

1.数据的呈现方式是表格还是图表?

若是时间范围，时间统计粒度是多少?

2.表格需要呈现哪些数据?

数据的单位?

保留几位小数?

数据计算的方法?

排序依据?

3.图表采用哪一种?

呈现的范围是多少?

4.常见的数据项操作：

新增、删除、修改、查询

∙新增哪些是必填数据项?

校验重复性和有效性?

∙删除是否需要提醒?

是否具有权限删除?

∙修改可修改的数据项有哪些?

修改后是否要进行校验有效性和重复项?

是否有修改的权限?

∙查询是精准查询还是模糊查询?

是单一查询还是支持批量查询?

批量查询输入方式的讲究?

查询的内容输入什么是否支持大小写空格等?

数据区间的查询是自定义还是给出范围划分?

人们总认为与大数据分析沾点边的技术都要花大价钱才能得到。

但事实上，大数据分析的思想才是最贵的，技术可以实现数据批量清洗，处理，呈现地更快、更美。

但却不知道要哪些数据算有效，哪些数据才是重点需要分析得出有价值的信息。

从零开始了解数据分析——系列讲座

（一）

NGA玩家社区10-02

从零开始了解数据分析——系列讲座

（一）

前言——什么是数据分析

数据分析可以算得上近年来最时髦、最炙手可热的概念之一，无论论坛帖子、广告宣传还是汇报总结，似乎一旦和数据分析拉上关系，立时就变得高端大气上档次。

但就像文案中铺天盖地般的"互联网+"一样，最热门的概念往往也是人们认知最为模糊的概念。

到底什么是数据分析？

是一出场就能抓住人们眼球的华丽图表？

还是密布数据的庞大表格？

然而事实上，抛开那些浮华、吸引眼球的噱头，冷静客观地分析才是我们应该牢牢抓住的核心。

作为在数据行业浸淫多年的业内人士，我打算从数据分析的不同层级谈起：

（1）最初级也最原始的数据分析是建立固定报表，例如工作中常见的财务报表，它们是定期生成的，有着固定的格式和内容。

（2）在这之上为即席查询和多维分析，也就是随时就用户想看的数据开展查询，具有一定的快速响应和灵活性。

（3）第三层级则有风险预警，在问题出现的早期及时向用户发出提醒。

（4）下一级是统计学分析，运用数学工具进行深入发掘。

（5）之后则是预测和评估，以揭示未来一个时段内某属性的发展趋势或某事件发生的几率。

（6）更高阶的应用则是建立模型优化策略，乃至于对非结构化数据（例如文本数据）的分析，机器学习、人工智能等等，都是建立在数据分析基础上的深层次应用。

不过无论你根据实际需要选用何种分析形式，算法简易或是繁杂，切入点粗浅还是深入，数据分析的实质都不会发生改变——始终都是一种从实际出发，为揭示事物发展规律、做出决策而服务的方法论。

概括起来讲，一次完整的数据分析，一定具备以下几个要素：

其一是明确的业务目标与方向；其二是拥有大量可靠的有效数据作为分析基础；其三是获得完善的工具与方法论支持；其四则是通过探索和建立模型，找出更优的策略。

这就意味着，数据分析所涉及的知识相当宽泛，而一位合格的数据分析者，必然是在多个领域有所建树的复合型人才，我将其归纳总结为：

看得懂业务，理得清需求，讲得清思路，列得明算法，写得出代码，做得好说明

以上述六点为指导思想，我将这系列讲座规划为四部分：

数据库与SQL语言基础；数据的获取与处理；统计学与应用数学基础知识；数学模型的建立与数据分析实践。

如果将数据分析比作烹饪美食，那么数据库与SQL语言基础便是厨具；数据的获取与处理是备料；统计学与应用数学基础知识为菜谱；数学模型的建立与数据分析实践则是动手下厨，四部分缺一不可。

讲座将搭配多个游戏、电竞主题案例，案例并非单独列示，而是将整个完成过程贯穿于讲座当中，尽可能全方位地展示数据分析的每一面；同时，本着从实际应用出发的精神，本文舍弃了部分深入内容，对部分知识点仅进行简述，有兴趣的朋友可以在专业书籍中进一步寻求详实讲解。

为表示诚意，本文中选材、案例、设计、作图、代码均为本人独立完成。

对于Java、Python、VBA、C++、SAS、SPSS、R、Tableau等工具，只要能找到完整版本，我也会尽量在案例中加以展示。

由于本人姿势水平有限，也并非程序员，在文中难免出现谬误和不专业之处，还请大家多多包涵并加以指正。

第一讲：

数据库与SQL语言基础

为什么首先要学习数据库和SQL语言——什么是数据库，数据库的基本结构——目标：

符文模拟器——数据流——缓存——表结构设计——主键——INI配置文件——连接数据库——SQL语言基础——SQL语言进阶

为什么首先要学习数据库和SQL语言

在动笔前，我曾经这样问自己。

为什么要从数据库开始讲起？

要知道，在本主题下，我们所面对的，往往不是企业级别的海量数据。

即使需要用到大量对局信息，也有各类辅助工具和网站替我们做好了收集整理工作，在这样优越的条件下，我们还有必要耗费精力来学习数据库和SQL语言此类"专业"工具么？

仔细考量之后，出于以下两点，我得出了肯定的答案。

第一，数据分析是门揭示事物内在联系的学问，而通过建立数据库，有助于我们明晰数据间的关联关系，可以说，学习数据库、使用数据库的目标和开展数据分析的目标在某种程度上是趋向一致的。

第二，在某些场景下，数据分析不是一门精准的学问，而是偏向实验性、以量取胜的学问，有时我们开展数据分析，是由理论推导结果，有时我们又是从结果反推理论。

在这一过程中，将不可避免地面临多次实验和反复验证的环节，其计算量和工作量是人力难以企及的。

因此，以数据库为基础的自动化程序是开展数据分析工作的必备条件。

什么是数据库，数据库的基本结构（本文中数据库均指关系型数据库）

数据库是结构性存储和管理数据的仓库，但其所存放的不仅是数据。

我们知道，一个运营良好的仓库，其存放的物品必然不能散乱无序地摆放，而是分类、分区域有序地存放，并有详细的目录和存取记录，以便于开展统计盘点。

数据库也是一样。

数据和信息往往不是独立存在，而是存在着普遍联系，人们也习惯于将它们关联到一起，例如看到对局的结果，就会联想到每名玩家的KDA；看到ADC选择了EZ，就会联想到辅助选择了哪位英雄；看到一方拿了大龙，就会联想到其利用大龙buff拉开了多少经济差距。

这就决定了我们不会单独查看某个数据，而是需要数据整体地展示出来；同样的，我们不会单独存放数据，而是将其按照关联性和逻辑关系，有秩序地储存起来，从而形成一个数据库。

其基本组成是二维表（同我们日常所接触的Excel表结构相同，也被称为"关系"）。

对于表中的每一行，我们可以称之为一个记录；每一列，可以称之为一个变量（字段）。

表中不得存在重复行、重复列，不难看出，在一张表中，任一记录的任一变量，都对应着一个数据。

表是数据库的基础组成部分，但表在数据库结构中并不处于最底层。

在表的下层为保存数据的数据文件，它们是数据库的底层基础，表的上层可能存在视图（VIEW），最上方则是用户层面。

数据库层级模型

目标：

诺森德符文模拟器

在本讲中，笔者将通过一个完整的应用案例——英雄联盟符文模拟器制作，来逐步讲解数据库的设计及SQL语言的实际应用。

应用数据库思路制作符文模拟器并不复杂，只能算作一个小小的工程。

但是在模拟器制作过程中，我们能够接触到建立、应用数据库的全部流程，因此十分适合作为入门讲解案例。

在本案例中，经过权衡，我决定以Excel的VBA制作界面（简便易用，无需安装），Access为数据库管理系统（简便易用，无需安装，适合作为本地数据库）进行开发。

经过初步规划分析，符文模拟器的大体界面及其应该具备的基本功能如下：

1.能够为每个符文槽自由配置符文，以实现模拟功能

2.能够计算各符文配置的加成效果

3.能够添加、删除、编辑符文及其性能，以应对版本变更

4.能够导入、导出符文配置文件，以实现配置存档

数据流

在明确了功能需求后，我们就可以开展需求分析工作，首先让我们看下符文模拟器运行时，数据的传输流动情况：

第一项要确认的是存储数据的对象，根据需求我们能够判定，在符文模拟器工程中，数据表和存档文件分别将保存符文信息和符文配置信息。

然后是展示数据的对象，也就是数据最终的接收方，既符文模拟器的使用者。

使用者要通过交互界面来使用符文模拟器，所有数据信息都将经过界面，同时界面还将查询和编辑请求传递给数据库。

除了数据表、界面窗体、用户，我们还需要其他对象参与到数据的流动当中么？

还是有的。

缓存

我们设计、规划一个项目，往往会依照一定的准则规范行事，数据库的设计也不例外

存储空间是有限的，新时代下的数据洪流则是无穷无尽，如何提高存储空间的利用率，则是每个数据的设计规划者必须面对的课题。

为了尽可能优化结构、提高性能，我们一般会遵循以下的原则：

减少冗余、主题明确、注重效率、逻辑清楚

在本案例中，通过分析我们可以得出，既然要制作一个符文模拟器，使用者免不了为每个符文槽反复更换符文，如果每更换一次符文，就访问一次数据库取出相应的符文信息，那就显得太不效率了，为了提高运行速度，降低数据库访问量，可以设置一个缓存区，在程序初始化时，将数据库数据读入到缓存中，之后用户直接通过访问缓存获取数据。

由于本例是以Excel为平台制作符文模拟器，直接选取一张工作表（Sheet）作为缓存区再合适不过。

由此我们便得出符文模拟器顶层数据流动情况，如下图：

数据库顶层数据流示意图

顶层数据流图不能详细表明符文模拟器运行过程中，对于数据的加工情况，由于先前确立了符文模拟器的各项功能，在制作工程中，必然要为每项功能构筑相应的模块。

因此我们还要将各模块对数据的需求和处理纳入考虑，并设计出符文模拟器底层数据流动图。

让我们从符文模拟器运行各环节出发，来分析这一问题，当用户打开符文模拟器后，他首先看到的是符文模拟器的主界面。

符文模拟器主界面

通过主界面，用户可以配置符文、导入导出符文配置文件，计算符文属性加成，或进入编辑符文界面。

为了让用户能够在主界面选取各符文，我们需要在载入主界面时，一并读取符文数据，也就是初始化。

符文编辑界面

在编辑符文界面，我们可以进行符文的添加、删除、编辑工作，而编辑一个符文首先要从数据库中读取该符文的信息，而添加、删除、编辑，也是对数据库中的数据开展操作。

由此我们便得出涉及符文模拟器各模块的底层数据流动情况，如下图：

数据库底层数据流示意图

表结构设计

完成数据流图后，我们就可以开始设计每张数据表。

首先让我们分析下符文模拟器在运行过程中，需要用到哪些数据（字段）：

首先我们必然会用到符文名称；其次为了筛选符文，需要用到符文类型字段（精华、印记、符印、雕纹）；为了计算符文属性加成，我们需要每个符文增加的属性值（由于存在该死的混合穿透符文，我们需要两个属性字段）；为了将结果展现出来，我们需要每个符文属性的描述；同时我们还要区分出成长符文，因为计算成长符文的属性时需要乘以人物等级。

还有么？

还有！

主键PRIMARYKEY

在我们储存数据时，常常会关注一条记录是否被重复保存或遗漏。

出于这一考虑，数据库管理者在创建表，通常选择一个或多个能够唯一标识出每条记录的字段，是为主键（PRIMARYKEY）。

不难看出，为了达到唯一识别的目的，主键列不会出现重复值，这也为我们查询、增添、修改、删除表中的记录提供了便利。

满足上述条件的字段有很多，但不是每个字段都适合被设为主键，因为为了保持数据库的稳定、降低代码的修改频率，主键的职责一般由没有太多实际意义、很少会被修改、最好是自动创建的字段承担，在本例中，虽然我们能够通过符文名称来唯一识别每一种符文，但是符文名称本身带有大量含义，又有可能随着游戏版本更替而发生变动，所以我们选择新创建一个符文编码字段作为主键，符文编码由首字母和数字两部分组成，首字母代表符文类型，数字则是按顺序排列生成，可以说，符文编码字段除了能够用于判别符文类型外，没有其他含义。

这样一来，符文数据表的所有字段都可以确定下来，为了方便程序使用，我们将字段名设置为英文和下划线的组合。

至于符文配置存档文件，其结构就十分简单了，只需要两个字段，其一是符文槽编号，其二则是符文槽镶嵌的符文的符文编码。

符文数据表

导入导出存档

完成了表结构设计，我们可以正式进入代码环节了。