微店索引数据dump架构演进
前言
微店技术团队在过去的一年时间里，发生了天翻地覆的变化，一个个项目从无到有，一套套技术方案从构思到落地再到升级完善，目睹这一切的发生，有一种万丈高楼迅速拔地而起的既视感；而建造这座大楼的主要材料，无疑就是微店积累的6千万用户、13亿商品的海量数据。那么如何为这些数据提供有效的索引及检索方案就变得很关键。今天和大家分享一下微店索引数据dump架构的演进，顺带提一下：我们不生产数据，我们只是数据的搬运工。
一、为什么需要dump索引数据
在很多应用场景下都需要配合一些较为复杂的筛选条件从海量数据中迅速过滤出符合条件的数据按一定规则排序展示，微店目前使用mysql存储原始数据，对一些大表采用分库分表的方式来缓解检索压力；然而直接检索mysql有以下短板：
需要的关联数据分布在很多个库的很多张表上，需要查询多次
复杂mysql查询的查询性能难以满足需要
无法提供上下文模糊匹配查询
支持个性化排序相对较难
为了规避以上短板，很多产品在确定技术方案的时候往往会倾向于使用搜索引擎来支持数据检索功能；而搜索引擎检索的索引数据就是从mysql dump数据来构建的。
二、dump需要做哪些事
dump不仅仅是同步数据那么简单，它需要处理很多问题，例如：关联数据、数据转化、数据过滤、版本控制、数据对账、数据补偿......
关联数据：
dump最终输出的数据是一张包含某个维度或者业务所需的全部数据的索引表，比如商品维度需要包含商品基础数据、商品扩展信息、商品类目等数据，根据业务需要，可能还要包括商品所属店铺的一些信息，比如是否频闭店铺等；而这些数据在mysql中实际上是分布在各个库的各个表上的，我们需要做的是把这些数据用关联键join到一起，这是整个dump流程里最核心的功能之一。
数据转化&过滤：
数据在dump过程中经常需要做一些转化和过滤，比如把商品价格从元换算成分，又比如需要对一些违禁商品做过滤。
版本控制：
为了保证索引数据和原始数据的最终一致性，通过设置版本号来控制数据修改是否生效；比如有相同记录的两条mysql的增量消息，较早产生（版本号较小）的消息在较晚产生（版本号较大）的消息后面到达，此时因为版本控制，覆盖不生效，使得最终索引数据和数据库一致。
数据对账&补偿：
所有健壮的系统都有一套容灾措施，dump必然也需要一套常态化的监控措施，即按照一定规则将索引数据和原始数据进行对账，若发现数据不一致，则采取相应的数据补偿，并发出报警。
下面是初始阶段的dump架构示意图：
三、平台化、规范化
在完成了最初的功能需求之后，通过一段时间的使用，我们发现了若干问题：
每次一有新的dump需求，都要申请新的dump机器，浪费公司资源，增加了维护成本；
dump开发流程繁琐且容易出错；
全量索引和增量索引两个流程没有统一，导致代码不能复用，提高了代码维护难度；
因为只能以记录维度设置版本号，版本控制问题贯穿整个开发流程；
为了解决以上问题，dump中心平台应运而生，代号Ergate(工蚁)，我们希望它可以像工蚁一样规范、准确、高效地完成数据搬运工作。
Ergate架构示意图：
Ergate有以下新特性：
开发快：通过提交表单的方式完成dump开发，几分钟便可完成
资源省：新增dump业务只需提交新的MR-job，无需申请新机器，原来申请的机器可以逐步回收
数据准：整个开发流程实现了标准化、规范化，只要配置正确，结果就正确
扩展易：整体流程按照模块化设计，输入的数据源模块可以支持mysql、HDFS、VSS、HBASE等多种数据源，输出暂时只支持vsearch索引文件、紧接着将扩展支持ES索引文件
除了以上特性，Ergate（dump中心）完美解决了版本控制的问题，开发甚至不需要关注版本的问题；这是因为用来存储宽表的HBase天然支持给相同记录的不同字段设置独立的版本号（时间戳），这样就不会出现同一秒产生的两条增量消息互斥的问题；
四、未来展望
Ergate的定位是一个dump通用解决方案服务平台，目前一期版本已上线，未来的发展方向如下：
业务方面：作为一个兼容块状数据(全量离线数据)和流式数据(增量日志流)的dump通用解决方案，逐步推广服务于微店各团队。
技术方面：全量索引考虑使用spark提升整体计算速度；增量索引考虑使用jstorm优化提高增量索引的实时性和吞吐量。