Abstract：pm需要了解的产品研发过程中设计到的数据处理的基础知识。

数据处理

关系型数据库：mySQL，Oracle，RDBMS；问题：1.数据高负荷运转时出现性能瓶颈，数据库操作会更慢；2.扩展性：要给数据增加一个字需要更改大量表结构；3.恢复数据的速度慢；
非关系型数据库：NOSQL（Rediscovered，MongoDB，HBase）
NOSQL：1.多台机器分担单一机器的高负荷，解决性能瓶颈；2.数据之间无依赖关系，可随时增删字段；3.结构简单，反应快；（高扩展性，分布式计算，低成本，架构灵活，半结构化数据）；

数据恢复原理

文件系统的设计——索引区+数据区；
存入数据的流程——在索引区添加索引+在数据区写入文件的完整内容；
删除文件的流程——索引信息被删且数据区里标记为无人使用+新文件存入时可能覆盖数据区的被删文件的位置；

非关系型数据库

关系型：=excel；字段指表头；
非关系型：key-value形式（数据库不关心value到底是什么，每个key对应的value项可不一致），查询无需SQL语句，查询：输入key，返回json字符串；优点：不束缚在字段的设计；

eg.1334389483{“name”:”zhang”,”male”:”female”,”age”:”13”}
key:手机号；value：一个个json字符串；

分布式计算基础：Mapreduce

mapreduce：Google提出的分布式计算模型；即总分单，单归总；（把大量数据分解成独立单单元执行map，然后将结果归并在一起reduce）

eg.分析2.6TB数据找出最热单10个人名；
分布式方法：90台机器map（分别分析一个个单个文件得出key-value，key-人名，value-出现次数）+10台机器reduce（分析完的同key的结果丢到同一台机器里，什么key到什么机器要提前设好，最后获得最终的完全key-value，列出次数最多单前10个）

写SQL语句

SQL语句：创建数据库，删除数据库，删除表，修改表，查询表（核心）；
查询：select,根据条件筛选数据；

表名：staff
select from staff: 从staff表中选择
select from staff Where sex=’female’:从staff整张表中选出sex为female的数据；
select from staff Where name like ‘%江’ : 从表中选出名字中含有江的数据；
select from staff ORDER BY cup DESC :将整张表降序排列；
select *from staff ORDER BY cup ASC: 将整张表按升序排列；
select name, age from staff ORDER BY cup DESC:选出名字和年龄并按年龄降序排列；

数据库

索引：
事务：提供一种机制，即一件事必须做完，如果中间出了差错就会清除所有痕迹初始化，可保持数据单完整性；
联合查询：几张表一起查；
对数据库database的理解：table-表，record-每一行的记录，feature-特点，每条记录的N列；一个大文件里有许多excel表格，每张表格里存储了许多条记录；
操作：增，删，改，查；
why 数据库（比excel）：存取效率高，很多系统无用户界面用不了excel，SQL语句操作，事务系统，命令操作失误少；
什么样的数据适合数据库存储：结构化的数据，即数据有方便查询的feature；
设计数据库：excel思维+拆表；

eg.user表和message表需拆开，否则会出现数据冗余／重复插入的结果，即低频与高频分开；
create_table user(姓名 varchar（20），昵称 varchar（20）)
create_table message(姓名 varchar（20，时间datetime，message text)
insert into message values（‘李晓华’，now（），‘xxxxx！’）：把用户发的新消息插入表中；
select *from message where 姓名=‘李晓华’ ：查询李晓华单所有消息；
select max（time）from user_table :找出使用时长最长的用户；

select是精髓，其执行速度直接关系到用户体验；

数据库索引

数据库索引：排序（对数据库里的某个属性的所有值排序以加快查询速度）+二分法（取大取小再取中点，重复）

1.聚簇索引

按数据的物理存储顺序建立索引；
缺点：会改变表的存储结构和数据排序；每张表只能建一个聚簇索引；

2.非聚簇索引

开辟一块存储区域保存索引，不改变表的存储结构和顺序；每张表可建多个聚簇索引；
缺点：索引消耗硬盘存储空间；

ORM（一种轮子）

能帮你把对象直接存入数据库，也能直接从数据库读取对象的工具；（对象-SQL语句-对象）
调API

数据的来源

上报数据的流程：埋点——上报——后台记录日志——计算／入库——展示
埋点：在正常功能逻辑里加统计逻辑；上报数据可采用key-value或数据组合的形式；key-value：key-区分不同事件，value-事件发生的次数／状态值；数据组合：描述一个事件或状态需要多种属性描述的场景；

eg.数据组合：描述【下载成功】这个事件的数据组合包括：对应的下载地址，下载渠道／来源，耗时等。

上报：不是每统计一次事件或状态就上报，客户端统计到的数据会暂时保存在内存或磁盘上，当用户启动／退出应用时或其他合适时机，将当前周期统计到的事件批量上报到服务器（减少性能损耗和流量损耗）
后台记录日志：数据上报到服务器后，服务器将原始数据存到服务器磁盘里；非强实时性的数据不会立即参与计算，而是等服务器负载较低的时间段利用预先配置的计划任务进行离线处理（节约服务器资源／钱／不影响实时业务的处理效率）；
计算／入库：对海量数据的计算需用到数据仓库（eg.hive处理工具），当数据仓库工具计算出最终结果后，计划任务会将最终结果保存到数据库里（入库）；
展示：数据入库后报表系统通过前段页面用户的输入获取查询条件——通过后台数据查询获取结果——在前端展示；

数据统计

统计数据出问的原因和方案？

1.报表数据为0

在验证客户端埋点功能正常后，可能计算&入库和展示环节（与埋点功能相关，需根据不同的统计需求修改）出问题
solution：确认功能正常——联系后台负责数据统计的人员跟进，恢复异常数据；发现功能不正常导致数据没有上报——等下个版本修复或热补丁；

2.报表数据大面积突降

可能是日志分析系统有策略调整或日志迁移导致只收录了部分数据
solution：找运维确认

3.报表数据突增

可能是恶意刷量
solution：找数据组查原始日志，看是否有个别IP或用户ID对应的PV数量明显异常；

4.报表数据明显低于预期

埋点功能出问题，漏报数据
solution：找负责埋点的同学

5.业务流复杂的漏斗系统统计数据异常

solution：逐级找相关人员确认数据

@pm要谨记

及时关注重要数据，有问题及时发现反馈；
影响埋点的因素考虑清楚，如果数据异常是否原因可追溯，若有需要可多设置几个辅助埋点；
除自己熟悉的业务，也要了解外围业务；

渠道号是怎么统计的

需要针对不同的渠道包在同一个逻辑里上报不同的数据
如何实现：在apk里添加配置文件，注明当前apk对应的渠道号；当客户端启动时，首先从配置文件中读取渠道号信息，然后进行上报操作，即可实现用相同的代码来上报不同渠道号信息；
针对每个需要统计的分发渠道，要提供单独的渠道包，且配置文件不同；
可自动化生成；

无埋点统计系统（eg Growing10）

下载sdk并植入，超方便！