2015年终总结与2016年度计划 - 第一部分

2015年终总结已经拖了很久了,现在准备把这个坑填上.

这一系列将会分为三篇文章,

本篇是Part I, 对2015年的工作做总结和回顾;

Part II 对2015年(包括之前)自己所收获和具备的能力, 技能等做梳理;

Part III 列出2016年的工作, 学习方向, 和成长目标.

2015流水帐

1-6月

接着2014年的主要工作, 继续负责移动端广告投放平台开发的工作, 中间相继完成了:

  • 日志和数据检查告警模块(独立于原有模块之外, 单独运行)
  • 数据分析功能告警模块(嵌入已有数据分析模块中运行)
  • 新增一些外部对接接口和后台功能(达摩盘, 网易易投等)
  • 与合作公司的项目交接
  • 新增一些数据分析功能(web与hive的交互, hive加载动态生成的udf等)
  • web端的两位同事相继离职后, 接手继续进行web功能开发(django)
  • 持续地进行维护和bug修复, 并完成临时数据报表需求

随后, 上述平台开发工作转入了暂停开发, 仅做维护和支持阶段.
具体原因和得失, 下一小节会说.

5-7月

在平台开发任务逐渐减少之后, 负责了一些小的demo项目(包括接口验证等)的开发工作, 主要是:

  • wifi sniffer工具的接口开发和数据展示
  • talking data的接口开发和数据展示
  • 对上述两者进行结合后的一个数据收集展示平台的开发(django, echarts)

8-9月

具体工作较少, 主要是:

  • bug修复
  • 遗留报表任务的执行

业余时间搭建了博客, 并买了树莓派, 温度传感器和摄像头等, 尝试进行一些简单的硬件相关开发.

10-12月

开始进行一些人群数据管理平台的开发工作, 主要是:

  • 统一人群标识数据库的建立和数据的填充
  • 开发cookie mapping功能, 并与多家媒体和Ad Exchange对接
  • 研究并实现人群Lookalike功能

2015收获与教训

移动端广告投放平台项目

从2013年10月接手该项目起, 到2015年7月项目无疾而终, 历时近两年.

项目团队也从巅峰期的10来人(产品+研发+测试), 慢慢剥离出去很多.

期间:
编写, 讨论, 修改了很多文档,
编写, 测试, review了很多代码,
修复了很多bug,
上线部署了很多版本,
还有很多的加班, 很多的讨论, 很多的会议......

这一切的一切, 随着项目生命的结束, 也都付之东流.
而项目在生命周期内, 并没有为公司带来很好的收益.

现在回想起这一切仍然有一点不真实的感觉, 不过不管怎样, 还是要回顾并总结一下.

平台功能

  • Web console, 实现广告数据CRUD, 以及数据分析任务管理, 报表数据的查看等
  • 对外接口部分, 对接移动广告投放平台, 下发广告数据并触发真实投放
  • 数据分析部分, 实现投放日志数据的回收, ETL, 分析(报表分析和人群标签分析等)

收获

在这个项目中个人的收获如下:

  • 开始作为数据分析功能模块的负责人, 进行移动端投放日志的分析, 移动用户标签体系的建立, 存储结构的设计
  • 在上述过程中, 分别应用了MRv1, Pig, Hive等开源工具, 完成数据分析功能
  • 在与合作公司进行的项目交接中, 接手了python代码为主的日志数据拉取模块, 广告投放接口模块等, 继续进行开发和维护
  • 后来作为整体研发端的负责人, 对外对接产品和业务同事的各种需求, 对内组织协调web端, 数据分析端的同事一起进行开发
  • 在web端同事相继离职之后, 接手进行广告投放平台web端的部分开发工作

对于收获技能部分, 会在系列文章的 Part II 中进行详细的梳理.

教训

现在回过头来看, 项目没有做好的原因很多, 可以说是各方面因素综合影响的结果, 下面列出一部分:

  • 项目最开始为远程合作开发(合作公司在台湾)的形式, 我们仅负责核心数据分析部分功能的设计和开发; 虽然合作公司很配合, 开发人员也靠谱, 但是避免不了远程合作的一些问题(沟通成本高等)
  • 早期我方的人员(包括我自己)缺少足够的Hadoop平台开发经验, 对于数据分析功能的一些结构设计的不够合理, 导致数据分析功能虽然可以使用, 但是开发效率和运行效率较低, 并且可维护性差
  • 由合作公司进行的技术选型(python为主, web采用django框架), 在我方缺少足够的对应技术积累, 导致人员配备, 项目交接上面都出现了一些问题
  • 项目主导思想不统一, 最早由合作公司给出设计和实现, 后来我方有逐渐接手的意愿, 开始配置产品经理岗位, 形成了产品(北京)+研发测试(西安)+合作公司(台北)的三角格局; 整个2014年就是在三方不断磨合, 进行联合设计, 再不断讨论, 修改和实现中度过, 错过了项目发展成熟的黄金时间
  • 项目本身是一个平台性质的产品, 需要外部对接多家移动端媒体(大部分是通过对接移动广告联盟的形式对接, 少部分巨无霸媒体单独对接), 而各家媒体并没有一个现成的统一接口; 平台虽然制定了统一的接口规范, 也对接了一些媒体, 但是更多的媒体并不愿意为了接入该平台(因为可以预期的流量, 或者说收益不足)而实现新的接口规范, 导致平台接入的媒体始终有限, 这又使平台的使用范围受到限制.

数据收集展示平台

这个项目本身规模很小, 功能也很简单:

前后端配合完成数据配置(CRUD), 数据展示(前端主要用ECharts对数据进行图表展示);

后端完成数据的收集(实际上就是一个HTTP Server, 接收数据源POST请求提交的数据, 进行存储), 并对原始数据进行汇总和统计;

后端还需要提供RESTful风格的API, 与前端传递数据.

之前做的大部分开发工作, 包括使用的框架(Struts, Spring MVC, Django, Flask等),

都包含了前端view(或是template)部分的工作, 因此对于这种前后端完全分离的项目还是第一次实践.

收获

  • 实践了基于RESTful架构的web应用
  • 基于Mysql, 使用SQL直接进行复杂数据汇总统计

教训

  • 基于RESTful架构的web应用, 核心文档是RESTful API接口文档, 包括每个接口的名称, 交互的数据等等, 都是需要详细考虑并设计的
  • 接口文档的更新一定要及时, 并且应立刻通知到前后端的所有开发人员

CM Server

接受并处理一些内容简单的用户浏览器HTTP request(包括cookie的处理),

主要挑战在于用户请求量较大(>500 QPS).

收获

  • 基于Flask和uwsgi开发了一个可以支撑过千QPS的web系统(双机负载均衡)
  • 用户数据与Hive client机器的交互(Hive读写)并利用Hive进行数据分析

教训

  • redis(以及其他的内存型DB)永远不要作为唯一的数据持久化destination

人群数据管理平台

除了应用一些Hadoop生态圈的工具进行数据分析和存储外,

还做了一些机器学习相关的研究和实践, 主要用于相似人群推荐.

收获

  • 基于现有机器学习工具包(python的sklearn, hadoop中的mahout等), 可以很方便地应用一些机器学习算法, 机器学习算法的实现并不是最大的难点
  • 学习并实践了有监督机器学习中的逻辑回归分类算法, 朴素贝叶斯分类算法; 无监督机器学习中的K均值聚类算法, 关联规则挖掘算法

教训

  • 在一些算法中, 选择(提供)合适的特征值给算法是一个难点

对于收获技能部分, 会在系列文章的 Part II 中进行详细的梳理.


Comments

blogroll

social