是的, 又過了一年, 距離我開始奔四又近了, 寫寫今年的流水賬
有些事情上年紀(jì)記不清楚了, 時間可能會錯亂. 應(yīng)該搞個小本子才好...
第一季度: 搬磚
數(shù)據(jù)遷移, 整個數(shù)據(jù)倉庫從一個vendor遷移到AWS. AWS 這邊, 由于中國區(qū)業(yè)務(wù)剛剛開始, 不熟悉如何使用, 最后從在虛擬機(jī)上搭hadoop開始, 步履闌珊的遷移. 一邊遷移, 一邊學(xué)習(xí)AWS.
踩坑是難免的, S3 api 版本問題, 無奈自己根據(jù)社區(qū)版本修改了一個HDFS over S3 的library, 又遇到各種問題, 各種tricky的優(yōu)化最后終于還是穩(wěn)定的走了下來.
期間為了優(yōu)化計(jì)算, 啟動了 execution-service 項(xiàng)目, restful 提交任務(wù), 屏蔽后端計(jì)算資源, 支持hadoop, spark等. 算法組同時可以隨時一條shell命令啟動spark集群計(jì)算, 除了臨時的計(jì)算任務(wù), 還支持了推薦項(xiàng)目. 所有的報(bào)表計(jì)算也第一時間跑在了這個上面, 自己吃dogfood么, 對吧.
為了減少打點(diǎn)/數(shù)據(jù)采集, 啟動overhear-mysql項(xiàng)目, 監(jiān)聽mysql binlog 發(fā)送到kafka, 供搜索/推薦項(xiàng)目使用數(shù)據(jù), 解耦了數(shù)據(jù)系統(tǒng)與線上系統(tǒng). 感覺跟confluent公司的 kafka-connect 差不多.
任務(wù)調(diào)度, 各種etl調(diào)度, 由于數(shù)據(jù)遷移期間還有各種中間狀態(tài)的任務(wù)(比如雙寫狀態(tài)下的數(shù)據(jù)整合), 引入了azkaban, 根據(jù)需求改了一些, 支持不同project之間依賴.
第一季度只有我和另一個小伙伴@gordon 倆人撲在這里, 收獲頗豐. 贊@gordon.
總結(jié)一下:
- AWS 數(shù)據(jù)遷移
- S3 HDFS
- execution-service
- azkaban 接入
- overhear-mysql
第二季度: 數(shù)據(jù)質(zhì)量
接踵而來的, 是大家對采集的數(shù)據(jù)質(zhì)量的質(zhì)疑. 驗(yàn)證了一下, 發(fā)現(xiàn)真的嚇一跳. 開始著手想辦法提高數(shù)據(jù)質(zhì)量. 數(shù)據(jù)需求的管理也是很大的問題, 一般產(chǎn)品人員寫到google doc上,開發(fā)跟進(jìn)開發(fā). 會有遺漏, 而且沒有統(tǒng)一的管理, 時間一長, 問題來了:
- 不知道需求誰提出的
- 不知道需求定義在哪里
- 不知道為何定義該數(shù)據(jù)打點(diǎn)
- 打點(diǎn)后測試很難測試是否正確
當(dāng)初廢了九牛二虎之力做的數(shù)據(jù)打點(diǎn), 數(shù)據(jù)沒人會用, 想想就憂傷. 撓頭想了很久, 最后琢磨了一套小系統(tǒng):
- 管理需求, 每個app版本的打點(diǎn)定義, 修改記錄.
- 新app版本, 會基于最后一個版本的app而來, 初始狀態(tài)下先保留上一個版本的所有需求, 產(chǎn)品經(jīng)理基于這個再修改/新增
- 數(shù)據(jù)收集服務(wù)器攔截公司所有測試設(shè)備的數(shù)據(jù)收集, 單獨(dú)存儲, 供測試工具驗(yàn)證
- 數(shù)據(jù)驗(yàn)證系統(tǒng)從需求管理系統(tǒng)獲取打點(diǎn)定義規(guī)則, 自動驗(yàn)證, 出report
即便完成了這套系統(tǒng), 數(shù)據(jù)質(zhì)量還是下了很大功夫. 后來偶然讀到一篇神文, Everything We Wish We'd Known About Building Data Products, 看到一句話眼淚水差點(diǎn)流下來, 共勉
If you're not thinking about how to keep your data clean from the very beginning, you're fucked. I guarantee it.
除了干了上面這個事兒, 第二季度還啟動了另一個項(xiàng)目, 目的是計(jì)算所有用戶的常用metric, 簡化數(shù)據(jù)產(chǎn)品用戶使用, 用途暫且兩個:
- 給定兩個用戶集合, 自動比較兩組用戶的特征, 找出差別最大的特征
- 給定特征條件, 快速查詢出符合特征的用戶
不過由于種種原因, 這個項(xiàng)目進(jìn)行到一般就停擺了, 蠻可惜的.
除此之外, 又去了一趟硅谷參加Spark Summit, 收獲頗豐.
第三季度: 瘋狂的SOLO
第三季度我又變成了solo了.還接手了報(bào)表系統(tǒng)和搜索, 簡直是忙成狗了. 新接手的系統(tǒng)也是各種重構(gòu), 不過順便了解了一下ElasticSearch的實(shí)現(xiàn), 感覺設(shè)計(jì)挺贊的.
但從硅谷回來, 很同意Gloria Lau 在她的topic A Tale of a Data-Driven Culture里面的觀點(diǎn): 每個人都應(yīng)該是 SQL monkey , 數(shù)據(jù)部門應(yīng)該將精力花在build tools, 讓所有數(shù)據(jù)SQL connected, 每個人自己寫SQL 便可以查詢公司所有數(shù)據(jù), 自行進(jìn)行分析.
想清楚了就動手干.
考慮到Amazon的RedShift 在中國區(qū)暫且不可以用, 經(jīng)過簡單的調(diào)研, 決定使用facebook開源的Presto. 之所以選擇這個, 原因很簡單:
- Java 寫的, 出問題可以搞的定. Impala 這種, 短時間內(nèi)搞不定詭異問題就蛋碎了
- Connector 結(jié)構(gòu)設(shè)計(jì), 可以整合多個數(shù)據(jù)源join, 異構(gòu)數(shù)據(jù)整合我們非常看重. 后期可以選擇開發(fā)
- 大廠出品, 質(zhì)量保證. 有人用(facebook, netflix)
但唯一一個缺點(diǎn)是, 沒有好用的web UI. Airbnb開源的airpal 太簡陋. 決心自己寫一個. 因此啟動了 sqlbuffet 項(xiàng)目:
- master/slave 結(jié)構(gòu), sql執(zhí)行在單獨(dú)的slave中, 即便master 重啟, slave繼續(xù)執(zhí)行不受影響. slave將結(jié)果寫入S3, master/slave 通信靠mysql, 解耦的很徹底. slave 隨意擴(kuò)展
- master 負(fù)責(zé)UI, 支持SQL語法高亮, 接受查詢請求, 驗(yàn)證權(quán)限, 調(diào)度slave計(jì)算. 可隨時重啟.
- 開發(fā)了Sublime 插件, 寫SQL 后直接快捷鍵提交查詢. 借助Sublime的自動補(bǔ)全和語法高亮, 體驗(yàn)非常棒
整合了原有的數(shù)據(jù)倉庫和線上數(shù)據(jù)庫, 做到了會寫SQL + 知道數(shù)據(jù)在哪張表就可以查詢到任何數(shù)據(jù).
總結(jié):
- sqlbuffet 上線
- 遷移所有數(shù)據(jù)到s3, hdfs 僅僅最為臨時存儲
- 遷移任務(wù)調(diào)度到airflow, 簡化
第四季度
這個季度最大的事情就是做了一個presto connector, 在不引入額外存儲/索引的情況下, 可以使用presto SQL 直接查詢存儲在S3 上的小文件. 改天詳細(xì)說說, 基本原理就是使用S3 的prefix listing 特性, 構(gòu)建基于S3 key的前置索引, 適用于直接存儲在S3的小數(shù)據(jù), 例如圖片, 語音等. 上線沒多久, 查詢?nèi)魏螖?shù)據(jù)的承諾實(shí)現(xiàn)了, 很開心.
借著寫這個connector, 簡單了解了一下presto, 發(fā)現(xiàn)這貨其實(shí)是學(xué)習(xí)數(shù)據(jù)庫系統(tǒng)的一個非常好的項(xiàng)目, 已經(jīng)制定計(jì)劃, 開始系統(tǒng)的學(xué)習(xí)一下數(shù)據(jù)庫系統(tǒng). 比如基本上數(shù)據(jù)庫系統(tǒng)的主要結(jié)構(gòu)如下:
了解了數(shù)據(jù)庫系統(tǒng)的基本結(jié)構(gòu)后, 就可以有針對性的日拱一卒式的逐漸蠶食數(shù)據(jù)庫系統(tǒng)的相關(guān)知識. 推薦兩篇佳作:
- How does a database work
- 還有
James Hamilton的大作: Architecture of A Database System
非常喜歡這種邊做邊學(xué)的感覺
還有一個事情做到了一半: 基于使用歷史, 優(yōu)化AWS 的RI 購買策略. 思路就是定時dump 線上instance 的使用日志, 導(dǎo)入presto, 然后寫sql 分析使用歷史, 優(yōu)化購買策略. 由于UI還沒有做, 現(xiàn)在只有跑sql自己分析, 哪天完成了再寫寫.
剩下的工作就是日常需求+優(yōu)化現(xiàn)有系統(tǒng). 在AWS Summit做了一次演講, 自我感覺不好, 需要繼續(xù)歷練.
總結(jié)
一年過得很充實(shí), 感謝生活.
