今天和搜索部门一起做了一下MQ的迁移,顺便交流一下业务和技术。发现现在90后小伙都挺不错。我是指能力和探究心。我家男孩,不招女婿。
在前面的文章中也提到,我们有媒资库(乐视视频音频本身内容)和全网作品库(外部视频音频内容),数据量级都在千万级。我们UV,PV,CV,VV都是保密的。所以作为一个合格的员工来说………………数值我也不知道。总之,这些数据作为最终数据源,要走一个跨多个部门的工作流才最终出现在用户点击搜索按钮出现的搜索框里。大体流程图如下:
这个流程图之所以没像以往一样手绘,嗯,那是因为:钢笔放在公司了。
这里面除了两个库都在我们这边之外,其他的一个框是一个部门。我们这边给pipeline的数据交付使用的是我开发的离线服务。pipeline将各个来源的数据做重复归并处理。就是一些视频内容是一样的,但是可能来源不同或者名称有相似但可能不完全相同,而实际上是一个视频。打个比方,大学时看过一个电影叫<a Cinderella story>翻译成中文有的翻译成《灰姑娘的故事》也有翻译成《灰姑娘的玻璃手机》,但是可以根据其导演和演员表等判断其实是同一个视频。这些相同的视频要聚合成一个专辑。推举最优质的描述作为专辑的描述。展开详情有各个来源的排序后视频列表。
正常全网搜索也会将自家的视频放在前面:
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 2017-07-26
- 消息队列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 论文笔记【图片目标分割】 2017-07-26
- 词向量-LRWE模型-更好地识别反义词同义词 2017-07-26
- 从栈不平衡问题 理解 calling convention 2017-07-26
- php imagemagick 处理 图片剪切、压缩、合并、插入文本、背景色透明 2017-07-26
- Swift实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26