剑客
关注科技互联网

WOT2016欧阳辰:小米程序化广告交易平台(MAX)的架构实践

【51CTO.com原创稿件】WOT2016大数据峰会将于2016年11月25-26日在北京粤财JW万豪酒店召开,届时,数十位大数据领域一线专家、数据技术先行者将齐聚现场,在围绕机器学习、实时计算、系统架构、NoSQL技术实践等前沿技术话题展开深度交流和沟通探讨的同时,分享大数据领域最新实践和最热门的行业应用。

51CTO记者在会前采访了小米公司研发总监欧阳辰,他是小米公司MIUI商业产品部的架构师和研发主管,是此次WOT2016大数据峰会重要演讲嘉宾之一。他的演讲主题是小米程序化广告交易平台(MAX)的架构实践。

【受访人简介】

WOT2016欧阳辰:小米程序化广告交易平台(MAX)的架构实践

欧阳辰·小米公司研发总监

欧阳辰,目前就职小米公司MIUI商业产品部,担任架构师和研发主管,主要负责广告平台系统架构,广告交易系统研发和数据平台。之前在微软工作工作10年,带领团队从事互联网广告和搜索引擎的研发工作,包括负责微软移动上下文广告系统和数据算法,必应搜索引擎的Index Serve的性能提升,最早在甲骨文公司从事数据库的研发工作。

当问及所处团队当前的规模和业务划分情况,欧阳老师这样说:“小米商业产品部目前是百余人的规模,其中大部分为技术人员,整体团队还在不断增长,不断有广告行业技术专家加入我们。研发部门按业务目标划分,可分为媒体方、系统架构、策略算法、广告主服务和数据平台。媒体方组负责媒体变现对接和用户体验,系统组负责架构演化和可靠性,策略算法组负责点击率预估、相关性等,广告主服务负责提升广告主满意度和ROI,数据平台提供数据洞察和营销数据平台DMP”。

小米程序化广告交易平台(MAX)的架构设计思路

关于架构设计思路,欧阳老师谈到架构设计本身就是一种学习和演化,踩坑踩多了,知道哪些地方不能走,也便成了思路。广告平台的设计思路是从几个方面出发:

首先是对于目前业务和未来业务的深刻理解,一直坚信架构是为现在和未来的业务服务的,减少业务变化而引入的成本,在设计理念上更愿意按照业务分解系统,特别是将需求多变的业务模块隔离出来,减少耦合。

其次,架构设计需要和团队的组织方式是一致的,遵守康威法则,例如在平台建设初期,各个业务小组都飞速发展,放马狂飙,那么架构需要提供足够的灵活性。

另外,广告系统对于可靠性要求非常高,不仅仅涉及到用户体验,也涉及到业务收入,因此系统的预警,报警和错误排除都需要大力投入。广告系统也有业务驱动的特点,不同的广告业务可能需要不同的系统架构来支持,因此架构的扩展性和可演化性也是非常重要的,需要支持业务的小步快跑,敏捷式迭代。

小米程序化广告交易平台(MAX)的演化过程以及对应业

欧阳老师表示平台架构的过程实际上是一个演化的过程,每一步演化都是为业务服务的。其可以分为四个阶段,分别是”加、减、乘、除”。

第一个阶段是加法,不断的上线新业务,整个系统不断复杂化,结果造成各个业务之间耦合很厉害,在后期,每一次设计涉及的影响都很大。

第二个阶段是减法,为了解决第一阶段的问题,系统的解耦成是一项最重要的工作,将各个模块独立出来,服务化,减少各个模块之间的不必要的联系。

第三个阶段是“乘法”,这一阶段的业务发展脉路较为稳定,各个模块分解的比较合适,各个模块(服务)都可以利用各种技术,高速提高服务质量,例如数据处理方面,通过流式处理,大大提高及时性;算法模块在解耦后,也大大提高了算法上线的速度和种类;架构服务化后,系统的容量和可靠性也大大提高。

最后一个阶段是“除法”,整个系统变得非常大且复杂,开发人员也有近5倍的增长,部署的机器也有近10倍的增长,服务模块数量也超过20个,这时候架构的调整涉及到一些抽象,按照业务分为服务群,对于离线的数据流也进行了大规模的优化,整合了一些分散的小模块,使得整个系统更加简单。

值得分享的经验是,架构师的工作不是创建一个静态的,美丽的架构蓝图,更多的工作是在成本、质量、收益和速度中找到长期技术投入的平衡,其目标是支持业务的快速发展。

研发过程中遇到的问题及经验教训

谈到经验教训,欧阳老实说开发过程中踩坑是不可避免的,关键是能从踩坑中吸取教训,不要第二次踩到同一个坑。架构设计上,其个人收获到很重要一点就是:架构及演化一定要坚持为业务服务。这部分,他举了两个例子:

其一:一年前刚刚接触这个平台时,当时感觉平台的层次不清楚,各业务之间的重复性很高,很多代码不忍直视,我的第一个直觉就是需要一个周全的架构,统一化的广告检索,可扩展的广告检索元语言等,基于这些想法和过去多个广告平台的经验,设计了一个广告演化的目标架构(所谓蓝图),有些模块沿着这个思路开始了重构工作,有些模块并没有重构,沿着老路发展,半年以后,我们再回首当时的决定。当时重构的模块是业务相对稳定的模块,后期的业务并没有从其中得到太多直接好处,虽然代码很整齐,设计很规范,但是投入和产出比很低; 对于没有重构的一些模块,在各个新业务的冲击,打磨和碰撞下,不断的进行自然演化,反而成为最适宜业务变化的模块,回想过来,其中的很多设计都不是当初能够规划出来的,因为很多新业务都未到位。

其二:关于MySQL的,在项目初期使用MySQL一直很顺利,读访问量大了,就采用、读写分离;写访问量大了,就进行垂直拆库(分表);数据量继续增长,然后进行水平拆库、水平扩展、引入代理层;然后数据量又长大了,不得不将部分数据移植到HBase里去。整个过程中,我们在MySQL折腾了太多的时间,每一次数据库改进都需要花不少人力,而且容易出错,每次的工作成果只能维持很短的一段时间,总结出一个简单道理, 如果有机会再重新做一次,我会更早的拥抱NoSQL的解决方案,避免在MySQL上很多无谓的投入 。

开发和设计“老司机”给入行新手的忠告

每个人都是从新手成长起来的,新手往往是潜力无穷的。我有几点小建议,也是我成长过程中,在多次经历迷惑后的一些体会。首先,要学会确定自己想去的方向,确定自己想成为架构师还是某个领域专家,一旦确定目标了就可以多向周边的大牛学习,看看优秀的同事都是如何思考问题的。 第二,保持学习的热情,计算机行业新技术层出不穷,需要不断的充电,了解最新的技术动态。第三,在学习过程中,要坐的住冷板凳,学会渔而非鱼,对于每种新技术,每一类问题,都会有学习的曲线,往往需要经历过一段黑暗的曲线,坚持下去就是光明。另外,在解决问题的时候,尽量了解问题的原理,把问题想透,学会刨根问底的思考。

最后,也祝愿刚入门的新手能够享受计算机技术的欢乐和痛苦,这是一条长长的路,道长且阻,行则将至,加油!

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

【责任编辑:wangxueyan TEL:(010)68476606】

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址