使用阿里云ODPS之点滴

    趁着这次做网聚宝搜索服务化这个项目，体验了一下阿里云的重量级云产品ODPS，也就是传说中的云梯2。项目几近结束，现在回过头来看当初选择使用OPDS的决定还是相当正确的，ODPS在网聚宝搜索上云这个项目中起到了非常至关重要的作用，一句话总结：ODPS是非常靠谱的。从刚开始里了解ODPS开始，到引入项目中使用，进而通过优化加速在项目中使用得游刃有余，经历了一个过程，中间也走了不少弯路。在此将之前碰到问题点做一下总结，希望对有和我们一样需求的团队或者个人有所帮助。

 

终搜为什么选择ODPS

    搜索引擎都是为了解决业务方数据多维度随意组合的条件搜索的需求，终搜的产品也不例外，在构建索引的过程中有非常重要的一个步骤就是将业务数据库中的数据导入搜索引擎中。搜索引擎中保存的数据结构是单维度的记录，而网聚宝搜索上云项目中所用到的数据源是来自多个数据库的多张数据库表。对象实体是由一对多，多对多的表组成的。所以在数据导入到搜索引擎之前对数据进行扁平化处理成为一个必不可少的环节。

 

    实现这个操作在java社区有非常成熟的hadoop可以使用，基于hadoop之上的hive通过执行命令SQL化可以很好地屏蔽底层技术细节。这个是一个不错的选择，同时我们在方案选型的过程中了解到阿里集团在公有云中正在推广ODPS，并且已经开始在公有云中售卖。抱着试试看的想法，开启了ODPS之旅。

 

   其实现在总结起来，使用ODPS还有一个非常重要的原因，就是阿里云在云基础设施配套这块做得比较到位，比如，针对ODPS数据导入有CDP（Cloud Data pipeling）这个产品来负责数据导入工作。通过CDP，只需要简地将单数据的reader和writer通过XML描述发送给CDP中间件，就可以轻松将几个G甚至几个T的数据从RDS在短短几十分钟之内DUMP到ODPS中。有了CDP可以免去我们很多额外工作。

 

   在ODPS上执行多表数据扁平化工作，通俗地讲就是“打宽表”，举个最简单的例子，例如有一张会员表，一张交易表，两表的关系是一对多，那我们可以按照会员维度将两张表打成一张宽表。最终打好的宽表结构就变成，user.id,user.name,”trade.id,trade.id  …….” As tradeids。这对于ODPS来说小菜一碟，有现成的聚合函数可以使用，如wm_concat。终搜将宽表构建成索引，用户可以很方便地通过trade.id来反查user.id。这是一个最简单的例子，或许你会问处理这种问题数据库也是可以的。那我要提醒你，数据库处理的数量级和ODPS处理的数据级完全不在一个等级上。但凡数据上G上T之后，数据库只能干瞪眼了，而像ODPS这样的<