数据质量控制

在爬虫系统中，当前方式是：

 每天，按默认顺序爬虫，爬一定时间，然后把今天爬到的所有数据作为当前房屋租金价格，时间标注为爬虫时间

但这种做法的问题是：

 1. 可能多天爬到同一页面，但通过分析（后文）发现发布者不会通过在同一链接源上面更新价格信息而是发布新的页面来处理价格变化，因此任意天爬到的相同页面没有价值
 2. 某地区可能今天被爬到的是1000元的房间，昨天爬到的是10000元的房间，在地区分析上讲，不能认为租金的价格下降了90%

所以需要

 1. 识别不同页面表示相同信息 （这类数据保存在最低level的数据层上）
 2. 增量的爬取
      问题在于数据页面上本身没有发布时间
      解决方法：
           选择页面上所有时间中最早的一个: 
                对于homelink，选择评价中最早的一条的发布时间作为房屋信息的更新时间

以上做法的基础是：当相关人员更新房屋的价格数据时，会创建一个新的页面，而非在原页面上更新

对于1，例如：

 其实只有链接的标题变化，两个链接表示的是同一个房源

S1

另外发现homelink的一个数据特点：比如上面两个房屋，它们会有不同的房源编号，说明即使在homelink自己的系统里面它们也不会被认为是同一个房屋

但还是有相当部分html里面没有时间，这时我选择的是爬取时间作为数据的来源时间

发现更新时间根据最旧评论的方法对于某些页面是无法成功获取数据的， 比如 http://beijing.homelink.com.cn/zufang/BJCY87462939.shtml ，其中没有评论，此时如果选用页面的爬取时间同样会造成数据质量不准确 发现这些页面通常会有图片，而图片具有包含上传时间的链接，那么从最旧的时间链接中提取时间作为页面的形成时间

正则表达式提取之

的确还存在一部分页面既没有评论也没有房源图片，提取爬取时间 例如 http://beijing.homelink.com.cn/zufang/BJHD87466253.shtml 然后再根据有准确信息的页面和该页面的编号差距估算发布时间 – 粗略就比都使用爬取时间好 对于这种数据，采用临近页面的有效时间估算该页面的产生时间

根据flag=1的页面，更新之间flag=0的页面的date time 详见RevisePublishTimeInTable.py

S2

现在爬虫的最大好处是我不用担心今天爬了多少，昨天爬了多少，因为每天爬的内容不会重复，同时爬取的时间无所谓

解决了原先的两个问题： 1. 爬取重复内容 2. 数据时间维度和爬取时间完全相关

关于星型模型和雪花型模型的区分理解： 执行效率和存储效率的均衡

虽然很多情况下，我们更关心执行效率（某种程度上说是我们写SQL的难度），但在某些业务情况下，星型模型的损失是没有必要的 举例， 假如我们对租房系统的查询都是基于“苏州街”和“中关村”这个level的，那么在每条地理纬度表中都存储“北京”这个level的column，会造成一列数据多余 （假设99%的查询都是低level的，那么存储高level的数据是没有必要的），如果考虑系统每天的数据量有数百G，那么这一列的损耗要大于去在1%条件下做join带来的时间便利

多个level的fact table 对于数据系统建立更困难（因为在导入数据时需要保证数据一致性），但是在使用效率上更为高效 （计算高level的数据时没有必要从底层去获取数据）

关于ODS到WH的转换可见blog中Kettle部分。

时间维度：年，季度，月，日，星期 （实际上我当前爬取的数据没有达到一定的积累）；上个月，上年，上星期等 地理维度：城市，区，地，小区 产品维度：比如几室几厅，几楼，绿化率 销售维度：经纪人信息

首先事实表中应该只有fact信息，其次关于如何划分维度，实际上这是一个业务决定的因素：业务上相关的内容被划分为一个维度，它对应在一张宽表上，因为同一维度的东西彼此间的交互会更多，避免join操作

数据仓库的价值在于非规范化带来的灵活性，以及数据积累的多样性

我觉得对于数据仓库的建立，首先应该回答问题：你希望用它来回答什么问题

 1. 房屋类型对比：某地区中不同类型的房屋的平均租赁价 （这里的类型指的是面积）
 2. 时间对比：某地区中不同类型的房屋租赁价的时间变化
 3. 地区对比：不同地区同类型的房屋

另外建模的基本是形成报表，而另外一方面的发展就是data visualization 数据可视化 （比如dashboard，app等等）

github project