Will Xu

重构推送服务

重构推送服务

最近对业务里发送 apple APNS, google FCM 部分的代码进行了重构, 抽出了一个单独的 service, 本文记录下过程. 存在的问题 我们有好几个 mobile app, 每个 app 会有一套对应的 server 端 service 做业务逻辑, 因为历史原因, 每个 service 里面其实有很多重复代码, 大多只是一些配置和错误处理上有差异. 给 app 发推送是个典型, 原来的做法是当要发推送的时候, 往 python 的 celery 队列里扔一个 task, 由 celery 异步得去发. 有如下问题: * celery 性能不佳, worker class 用的是 gevent, 但在高峰时候任务队列里还是有大量 pending, 代码上之前做过多次优化, 但收效甚微. * 当
  • Will Xu

从 python2.7 迁移到 python3.6

python2.7 会在 2020 年停止维护, 很多第三方包也在去掉对 python2.7 的支持, 最近终于完成了内部代码向 python3 的迁移, 整个过程挺繁琐的, 记录一下. 总共需要迁移的代码大概有 50w 行(cloc 计算, 去注释空行), 包括业务代码 + ETL + data analysis... 前后花了3个月. 做之前确保已读过官方的 migration guide: https://docs.python.org/3/howto/pyporting.html 我的大致步骤: 1. 清查依赖包, 不支持 python3 的 lib 寻找替代品(常用 lib 基本都没问题). 2. 将现有代码转写成 py2/
  • Will Xu

Glow data infrastructure 的演化

Glow 一向是一个 data driven 做决策的公司,稳定高效的平台是必不可少的支撑, 本文总结几年里公司 data infrastructure 的演进过程. 结合业务特点做技术选型和实现时候的几个原则: 1. real time 分析的需求不高,时间 delta 控制在1 小时以内可接受 . 2. 支持快速的交互式查询. 3. 底层平台尽量选择 AWS 托管服务, 减少维护成本. 4. 遇到故障, 数据可以 delay 但不能丢. 5. 可回溯历史数据. 6. 成本可控. 用到的 AWS 服务: * 数据存储和查询: S3, Redshift (spectrum), Athena * ETL: DMS, EMR, Kinesis, Firehose, Lambda 开源软件:
  • Will Xu

DynamoDB

DynamoDB 是 AWS 的托管 NoSQL 数据库,可以当作简单的 KV 数据库使用,也可以作为文档数据库使用. Data model 组织数据的单位是 table, 每张 table 必须设置 primary key, 可以设置可选的 sort key 来做索引. 每条数据记作一个 item, 每个 item 含有一个或多个 attribute, 其中必须包括 primary key. attribute 对应的 value 支持以下几种类型: * Number, 由于 DynamoDB 的传输协议是 http + json, 为了跨语言的兼容性, number 一律会被转成 string 传输. * Binary, 用来表示任意的二进制数据,会用
  • Will Xu

使用 Redshift Spectrum 查询 S3 数据

通常使用 redshift 做数据仓库的时候要做大量的 ETL 工作,一般流程是把各种来源的数据捣鼓捣鼓丢到 S3 上去,再从 S3 倒腾进 redshift. 如果你有大量的历史数据要导进 redshift,这个过程就会很痛苦,redshift 对一次倒入大量数据并不友好,你要分批来做。 今年4月的时候, redshift 发布了一个新功能 spectrum, 可以从 redshift 里直接查询 s3 上的结构化数据。最近把部分数据仓库直接迁移到了 spectrum, 正好来讲讲。 动机 Glow 的数据仓库建在 redshift 上, 又分成了两个集群,一个 ssd 的集群存放最近 4 个月的数据,供产品分析,metrics report, debug 等等 adhoc 的查询。4个月之前的数据存放在一个 hdd
  • Will Xu
python

Python web 应用性能调优

为了快速上线,早期很多代码基本是怎么方便怎么来,这样就留下了很多隐患,性能也不是很理想,python 因为 GIL 的原因,在性能上有天然劣势,即使用了 gevent/eventlet 这种协程方案,也很容易因为耗时的 CPU 操作阻塞住整个进程。前阵子对基础代码做了些重构,效果显著,记录一些。 设定目标: * 性能提高了,最直接的效果当然是能用更少的机器处理相同流量,目标是关闭 20% 的 stateless webserver. * 尽量在框架代码上做改动,不动业务逻辑代码。 * 低风险 (历史经验告诉我们,动态一时爽,重构火葬场....) 治标 常见场景是大家开开心心做完一个 feature, sandbox 测试也没啥问题,上线了,结果 server load 飙升,各种 timeout 都来了,要么 rollback 代码,要么加机器。
  • Will Xu

Redshift as data warehouse

Glow 的 server infrastructure 全部搭建在 AWS 上,一般要选择一些基础服务的时候,总是先看 AWS, 只要功能和成本符合要求,不会特意选择开源方案。 数据仓库我们选择了 AWS 的 Redshift. 在一年多的使用过程中 Redshift 的性能和稳定性都不错, 当然也有一些坑, 这里整理下在使用 redshift 的过程中的一些经验和遇到的问题. Columnar storage 就是常说的列式存储, 这里只谈应用场景, 理论详情可以看: http://docs.aws.amazon.com/redshift/latest/dg/c\_columnar\_storage\_disk\_mem\_mgmnt.html 常用的开源数据库 MySQL 和 PostgreSQL 都是传统的行式数据库, 和 columnar
  • Will Xu