是的, 又过了一年, 距离我开始奔四又近了, 写写今年的流水账

有些事情上年纪记不清楚了, 时间可能会错乱. 应该搞个小本子才好...

第一季度: 搬砖

数据迁移, 整个数据仓库从一个vendor迁移到AWS. AWS 这边, 由于中国区业务刚刚开始, 不熟悉如何使用, 最后从在虚拟机上搭hadoop开始, 步履阑珊的迁移. 一边迁移, 一边学习AWS.

踩坑是难免的, S3 api 版本问题, 无奈自己根据社区版本修改了一个HDFS over S3 的library, 又遇到各种问题, 各种tricky的优化最后终于还是稳定的走了下来.

期间为了优化计算, 启动了 execution-service 项目, restful 提交任务, 屏蔽后端计算资源, 支持hadoop, spark等. 算法组同时可以随时一条shell命令启动spark集群计算, 除了临时的计算任务, 还支持了推荐项目. 所有的报表计算也第一时间跑在了这个上面, 自己吃dogfood么, 对吧.

为了减少打点/数据采集, 启动overhear-mysql项目, 监听mysql binlog 发送到kafka, 供搜索/推荐项目使用数据, 解耦了数据系统与线上系统. 感觉跟confluent公司的 kafka-connect 差不多.

overhear_arch.png

任务调度, 各种etl调度, 由于数据迁移期间还有各种中间状态的任务(比如双写状态下的数据整合), 引入了azkaban, 根据需求改了一些, 支持不同project之间依赖.

第一季度只有我和另一个小伙伴@gordon 俩人扑在这里, 收获颇丰. 赞@gordon.

总结一下:

• AWS 数据迁移
• S3 HDFS
• execution-service
• azkaban 接入
• overhear-mysql

第二季度: 数据质量

接踵而来的, 是大家对采集的数据质量的质疑. 验证了一下, 发现真的吓一跳. 开始着手想办法提高数据质量. 数据需求的管理也是很大的问题, 一般产品人员写到google doc上,开发跟进开发. 会有遗漏, 而且没有统一的管理, 时间一长, 问题来了:

• 不知道需求谁提出的
• 不知道需求定义在哪里
• 不知道为何定义该数据打点
• 打点后测试很难测试是否正确

当初废了九牛二虎之力做的数据打点, 数据没人会用, 想想就忧伤. 挠头想了很久, 最后琢磨了一套小系统:

• 管理需求, 每个app版本的打点定义, 修改记录.
• 新app版本, 会基于最后一个版本的app而来, 初始状态下先保留上一个版本的所有需求, 产品经理基于这个再修改/新增
• 数据收集服务器拦截公司所有测试设备的数据收集, 单独存储, 供测试工具验证
• 数据验证系统从需求管理系统获取打点定义规则, 自动验证, 出report

data_collect_system.png

即便完成了这套系统, 数据质量还是下了很大功夫. 后来偶然读到一篇神文, Everything We Wish We'd Known About Building Data Products, 看到一句话眼泪水差点流下来, 共勉

If you're not thinking about how to keep your data clean from the very beginning, you're fucked. I guarantee it.

除了干了上面这个事儿, 第二季度还启动了另一个项目, 目的是计算所有用户的常用metric, 简化数据产品用户使用, 用途暂且两个:

• 给定两个用户集合, 自动比较两组用户的特征, 找出差别最大的特征
• 给定特征条件, 快速查询出符合特征的用户

不过由于种种原因, 这个项目进行到一般就停摆了, 蛮可惜的.

除此之外, 又去了一趟硅谷参加Spark Summit, 收获颇丰.

第三季度: 疯狂的SOLO

第三季度我又变成了solo了.还接手了报表系统和搜索, 简直是忙成狗了. 新接手的系统也是各种重构, 不过顺便了解了一下ElasticSearch的实现, 感觉设计挺赞的.

但从硅谷回来, 很同意Gloria Lau 在她的topic A Tale of a Data-Driven Culture里面的观点: 每个人都应该是 SQL monkey , 数据部门应该将精力花在build tools, 让所有数据SQL connected, 每个人自己写SQL 便可以查询公司所有数据, 自行进行分析.

想清楚了就动手干.

考虑到Amazon的RedShift 在中国区暂且不可以用, 经过简单的调研, 决定使用facebook开源的Presto. 之所以选择这个, 原因很简单:

• Java 写的, 出问题可以搞的定. Impala 这种, 短时间内搞不定诡异问题就蛋碎了
• Connector 结构设计, 可以整合多个数据源join, 异构数据整合我们非常看重. 后期可以选择开发
• 大厂出品, 质量保证. 有人用(facebook, netflix)

但唯一一个缺点是, 没有好用的web UI. Airbnb开源的airpal 太简陋. 决心自己写一个. 因此启动了 sqlbuffet 项目:

• master/slave 结构, sql执行在单独的slave中, 即便master 重启, slave继续执行不受影响. slave将结果写入S3, master/slave 通信靠mysql, 解耦的很彻底. slave 随意扩展
• master 负责UI, 支持SQL语法高亮, 接受查询请求, 验证权限, 调度slave计算. 可随时重启.
• 开发了Sublime 插件, 写SQL 后直接快捷键提交查询. 借助Sublime的自动补全和语法高亮, 体验非常棒

sqlbuffet.png

整合了原有的数据仓库和线上数据库, 做到了会写SQL + 知道数据在哪张表就可以查询到任何数据.

总结:

• sqlbuffet 上线
• 迁移所有数据到s3, hdfs 仅仅最为临时存储
• 迁移任务调度到airflow, 简化

第四季度

这个季度最大的事情就是做了一个presto connector, 在不引入额外存储/索引的情况下, 可以使用presto SQL 直接查询存储在S3 上的小文件. 改天详细说说, 基本原理就是使用S3 的prefix listing 特性, 构建基于S3 key的前置索引, 适用于直接存储在S3的小数据, 例如图片, 语音等. 上线没多久, 查询任何数据的承诺实现了, 很开心.

借着写这个connector, 简单了解了一下presto, 发现这货其实是学习数据库系统的一个非常好的项目, 已经制定计划, 开始系统的学习一下数据库系统. 比如基本上数据库系统的主要结构如下:

database_components.png

了解了数据库系统的基本结构后, 就可以有针对性的日拱一卒式的逐渐蚕食数据库系统的相关知识. 推荐两篇佳作:

• How does a database work
• 还有 James Hamilton 的大作: Architecture of A Database System

非常喜欢这种边做边学的感觉

还有一个事情做到了一半: 基于使用历史, 优化AWS 的RI 购买策略. 思路就是定时dump 线上instance 的使用日志, 导入presto, 然后写sql 分析使用历史, 优化购买策略. 由于UI还没有做, 现在只有跑sql自己分析, 哪天完成了再写写.

剩下的工作就是日常需求+优化现有系统. 在AWS Summit做了一次演讲, 自我感觉不好, 需要继续历练.

总结

一年过得很充实, 感谢生活.