u采 采集(数据分析数据属性备注直接数据日志数据某人的某个属性(组图))

　　u采 采集(数据分析数据属性备注直接数据日志数据某人的某个属性(组图))

　　在进行数据分析之前，首先要有数据，这就需要考虑数据的来源。数据来源基本上有两种：直接来源和间接来源。通俗的讲，直接数据就是经过我们采集的数据，间接数据就是我们引用别人的数据。你自己的采集数据可靠灵活，但是采集比较麻烦；引用他人数据的方式虽然简单，但是数据的可靠性大大降低。

　　数据源

　　数据属性

　　评论

　　直接数据

　　日志数据

　　某人在特定的时间以特定的方式做了某事并达到了特定的结果

　　状态数据

　　某人在某个时间点的属性状态

　　间接数据

　　主题相关数据

　　虽然不是你的采集，但它是反映你研究主题的数据

　　参考数据

　　用其他类似事物的数据替换您的主题数据

　　直接数据可以进一步分为日志数据和状态数据。日志数据反映事物变化的痕迹，状态数据反映事物在某个时间点的状态。比如你浏览某个网站的痕迹可以看成是日志数据，在某个时间点网站每个页面的访问量就是状态数据。日志数据通常可以推导出一些状态数据，但是考虑到日志数据量比较大，处理起来比较麻烦，所以我们直接采集状态数据，比如给每个网页加一个计数器。

　　采集日志数据确实是一个很复杂的问题，主要体现在：

　　1）事物的复杂性使得采集点的放置和采集内容的选择尤其困难。采集的内容虽然可以用“某人在某个时间、某个地点以某种方式做了某事，得到了一定的结果”的方式来阐明，但这里往往涉及的主题太多，而且很多也有互动关系（怎么做要看行业和需求，当然在游戏行业我总结了一套可行的方法）；

　　2）数据量非常大（比如我们公司一个小游戏的日志量达到每天20到3000万条日志），导致了一系列问题，比如：业务服务器本身，日志传输服务器的压力，数据库的压力等等，还好这些都可以用钱解决。

　　3）数据处理过程复杂（复杂程度因行业而异）。有了这些数据之后，我们需要将这些日志处理成各种便于分析的表，俗称ETL。从我现在的情况来看，每天要处理采集的日志成100多张表。

　　相比之下，状态数据更容易处理。我们只需要选择需要的属性，然后按照一定的时间段对数据进行快照，就可以形成一个动态的数据表（但是数量还是很大的）。

　　至此，直接数据就形成了。看看是不是很复杂，我花了将近半年的时间整理游戏的直通资料采集，多次转载重复（我以后会用这个方案作为专题分享方式）和你）。

　　在间接数据方面，主要有以下几个问题：1）能不能有你想要的数据，主要看命运；2）数据质量不可靠。这种不可靠性不仅是数据质量的问题，也是数据质量的问题。是数据定义不一致（或者说是口径不一致）。针对第一个问题，我们有间接数据中的“参考数据”。例如，如果想知道北京的人口，但找不到，可以参考与北京规模相近的城市（如上海）的人口数据。

　　间接数据的来源很多，比如：财报、统计年鉴、一些信息网站（比如：艾瑞）和百度指数。特别要提一下百度指数。以前我在分析某款游戏的异常（尤其是新用户的异常）时，用内部直接数据无法解决的时候，经常可以通过百度指数找到异常的原因。（主要是插件的问题），简直就是神器。但无论如何，我们都无奈求助于间接数据，“是”总比“否”好。

　　以上就是我对数据采集的一些认识和心得，后面会结合游戏行业做更深入的分享。如果您想了解更多关于数据分析的知识，请订阅我的微信和微博：