路卫杰的专栏

我们目前的数据流程是：数据源数据 经过挖掘处理转换等操作生成中间数据，入宽表 ，然后 提取宽表数据 入PDC，数据停留的地方有 数据源–>中间数据–>宽表–>PDC。目前我们的监控措施如下: （1） 数据源 –>中间数据–>宽表 每个数据流有监控，监控的是每个数据的总量 （2） 每天运行监控 监控 宽表每个数据的变化 （3） 宽表–>PDC有对最终每种数据总量的监控 和 对 数据的简单校验（

MapReduce 处理两个或多个数据源是经常的事，此时就要根据某个key将两个数据源进行Join操作，Join操作的原则是： 1) 如果两个数据源大小差不多，则直接使用DataJoin类进行Join操作 2) 如果两个数据源大小相差很大，则使用Distributed Cache机制将较小的数据源复制到所有节点并缓存起来，然后过滤大的数据源。如果缓存不小较小的数据源，可以先用Distribute

因为历史原因，目前我们的机器学习所需要的各种特征数据是通过一个MR程序来进行数据抽取，特征转换，数据存储，数据监控等，一个MR任务承担了太多了功能，导致程序的可读性，扩展性非常差，每次增加一个数据的抽取，转换都需要修改很多代码，而且极易出错，当要适应一个新的模型所需要的新型特征转换的时候，目前的特征工程更是不能胜任。基于此，痛中思痛，下定决心重构特征工程。 首先这个特征工程的架构不是一蹴而就的，

文章出处: http://data.qq.com/article?id=2784         1. 背景         先来看两个例子，下面两幅图展示了百度在趋势预测方面的应用案例，一个是世界杯期间的比赛输赢预测，另一个是北京各旅游景区的游客人数预测。         这两幅图代表了大数据环境下趋势预测的典型场景，即事件预测和时序预测，本文重点关注第二幅图中的场景，即与