滴滴CTO详解大数据战略与三次生死战役的架构变迁

浏览: 3600
文摘:基础层面是数据平台,主要是大数据计算和存储,用的是业内比较成熟的开源系统,Hadoop。基础层上是自建的数据仓库,然后是策略架构,通过实验平台让策略迭代更加敏捷,如快速提取特征完成模型训练,并通过小流量测试验证模型,通过后迅速上线。这些都是工程方面的研发。再上面是机器学习,滴滴打车现在每天涌入的数据接近10TB,通过不断搜集用户标准数据特征,优化机器学习模型。比如推送给司机订单,司机是否抢单,这就是一个天然的标注。而通过这些标注,就可以优化学习体系。最上面就是整个大数据体系,支持新产品开发和策略决策
未命名-1.png

2012年成立的滴滴打车,仅用了三年时间就书写了:覆盖300个城市,用户数从2200万增到1.5亿,月活跃用户增长了600多倍(2014年平安夜当天,全国用滴滴打车出行人数超过了3000万人),打车成功率高于90%……这些永远会被铭记在移动互联网历史中的神奇记录。而不为人知的是,支撑滴滴打车如此庞大用户数量的架构,以及那些曾无数次不眠不休应对挑战的技术伙伴们。
人称“博师傅”的滴滴打车CTO张博这样描述:“三年来,基本天天都在‘打仗’。每天一睁眼就要想生和死的问题。比谁能最先稳定,能将用户留住,谁就是胜利者。我们用技术和时间赛跑。而生死时速之后,我们开心地发现沉淀了非常多的宝贵经验,培养了大批优秀的实战人才。”
滴滴打车CTO张博往往被朋友们亲切地称为“博师傅”
三款产品背后的架构变迁
滴滴打车成立初衷是为了解决司机与乘客之间的信息不对称的问题,通过移动互联网和智能手机来打破信息的壁垒。从打车到专车再到顺风车,滴滴打车三款产品的背后是架构的挑战和系统的变迁。
问:如果从产品角度来看,滴滴打车发展有几个阶段?作为CTO,你的工作重点有哪些?
张博:滴滴打车成立初衷就是为了解决司机信与乘客之间的信息不对称的问题。乘客和司机通过传统手段往往无法实现息对接,一方是打不到车或被拒载;另一方是空车行驶耗时耗力耗费资源。这是信息的壁垒,完全可以通过移动互联网和智能手机来打破。而在后续运营中,我们发现即使出租车空驶降低到O,也无法满足早晚高峰乘客出行需求。以北京为例,出租车10.6万辆,但人口却有2000万常住人口,1000万流动人口。要匹配这样的需求需要集中社会用力,调度社会资源,这就是滴滴打车的第二款产品——滴滴专车。目前专车订单量已经逼近出租车订单量,而车租车订单量没有下降,显然撬动的是新增量市场。第三款产品是顺风车,满足的场景很有代表性。通过滴滴大数据分析系统,发现很多人居住地和工作地都比较接近,收入水平相当,行业属性相近,这些人往往都会使用出租车或专车,如果能够将需求合并,显然无论是帮助乘客提供低成本出行,还是节省社会资源,都很有价值。更有趣的是,其上增加了社交属性,人们可以结交新的朋友,出行变得更有意思。作为CTO,我的工作主要有三部分:第一是产品,第二是工程技术,第三是大数据。
问:三款产品代表了滴滴打车的不同发展阶段。相信每个阶段背后的架构都有很明显的特征?
张博:2012年滴滴打车刚成立时,流量很小,不需要架构,2台服务器就能解决所有问题。随着快速的发展,第一次发现性能瓶颈是在2014年初“补贴大战”时,我们的订单量一周之内涨了50倍。而当时的预估是增加10%。500%对10%,结果可想而知。网络、存储等故障不断,Webserver和MySQL也频出问题。团队所面临的挑战非常大。更为紧张的是,靠传统采购机器来实现扩张,显然完全无法满足业务需要。通过分析比较,我们最终决定整体搬到腾讯云中。这是面对高并发、海量数据挑战时,架构的第一次非常大的调整。但搬迁也并非一帆风顺,代码需要做大量重构,来解决技术上的单点问题。
第二次架构变化是在第二款产品滴滴专车时,因为最初架构设计是为支撑一款产品,而今架构要同时支撑多款产品。产品之间,有相同也有不同。为此,我们特别成立了技术架构部,将通用型服务下沉到架构,避免重复造轮子,将个性化服务放到业务层,实现服务开发。举个例子,比如支付、账号体系、计算、存储等,都是通用型服务,可以放到架构中。这次架构重构是比较成功的,也正是这样的组织和技术变化,所以在第三款产品顺风车的时候,以及我们马上发布的更多新产品时,都可以得到很顺畅的支撑和服务。
问:腾讯云新品发布速度很快。后续滴滴打车还会重点用到哪些新服务?
张博:
滴滴打车和腾讯云是深度合作的,安全、网络、运维之外,还有优化整体系统,部分调优、新产品实践等。滴滴打车甚至会深入到腾讯新业务中,比如征信系统。通过滴滴打车平台收集的乘客/司机的爽约次数、爽约频率等都会成为一个数据源。再如未来顺风车中,基于大数据分析,如何为一个互联网的屌丝优先匹配一个互联网女神,这些有趣的场景在底层都需要数据交换的。需要应用到腾讯云更多的新技术,新服务。我们双方都非常开放,希望能够给社会创造更大价值。
问:业内对滴滴打车当时遇到的挑战印象深刻。当时和腾讯云在技术方面有哪些合作?
张博:
当时滴滴打车已经接受了腾讯的投资,和腾讯云自然比较亲近。而且腾讯云也已经历了QQ和微信海量用户高并发的考验,比如春节红包,稳定性和经验是毋庸置疑的。和腾讯云的合作,在技术方面有三个方向:首先是安全,在滴滴打车发展过程中,遭受了多次黑客攻击,所以安全对我们至关重要,而腾讯云的大禹安全体系可以很好地帮助我们;其次是CDN等网络服务,有些技术是创业公司很难实现的。比如网络层优化,用户手机发送订单时,需要接入最近的基站,需要找到最优质链路,这些只有投入巨大人力物力的企业才能实现。而这些服务对用户体验极为重要,所以初创企业通过云服务反而可以走的更快更好;第三是在基础平台构建等方面节省大量人力,如硬件采购、硬件运维等,不需要费心费力,而是可以将更多精力集中到应用层和业务层,以及其他更有价值的数据分析等新技术方面。实际上,当时在补贴大战时,作为一个当时仅1年半的初创企业,在如此大流量面前是根本顶不住的。也正是那时,腾讯高级架构师直接驻场,和我们建立了兄弟般的友谊。
问:携程、艺龙事件之后,CTO们更加重视数据安全。滴滴打车在安全方面如何规划的?
张博:
目前滴滴打车大部分服务都在云上,也有部分服务是通过租赁腾讯机房自己运维的。整体架构是混合云的模式。安全对每个公司而言都很私密。现在内部有严格的安全控制,外部主要是通过腾讯云,如防黑客攻击,如DDos攻击等。安全防护是没有止境的,我们需要做的工作还有很多。

开源优化构建技术核心竞争力
滴滴打车正在滴米系统、用户画像系统、精准营销、智能匹配、需求预测系统和运能预测系统等方面构建自己的技术核心竞争力。在研发的路上,大数据、机器学习不仅是滴滴打车产品的心脏,还是滴滴打车商业的心脏。
问:2015年在滴米系统、用户画像系统、精准营销、智能匹配、需求预测系统和运能预测系统等方面,滴滴大数据技术逐步深入。那么研发的整体思路是怎么样的?
张博:
是的。大数据是滴滴打车的心脏。不只是滴滴打车产品的心脏,还是滴滴打车商业的心脏。我们的研发的基本原则是想办法撮合乘客和司机,满足他们的需求,保证他们的体验。举个例子,某一个时刻在中关村,同时出现很多订单,周围有很多司机。我们要做的决策是:将订单发送给合适的司机。因为司机在任何时刻都只能听到同时爆发订单中的一个。所以匹配要准确,那么背后就是推荐算法要准确,匹配效率要高,计算要快,推送要及时。这还不够。我们在推送订单到这位司机之前,应该先预测他对订单感兴趣的程度,广告领域称为CTR,我们称为STR。在后验过程中,滴滴可以做到80%的准确度。其中,不仅要计算司机的个人特征,还要结合其决策体系,如喜好,是对小费敏感,长短途敏感,时间敏感,还是对方向敏感等静态特征和司机和订单之间的位置关系、时间关系等动态特征进行综合分析。除此以外,还有补贴,给乘客什么样的补贴,给司机什么样的补贴,谁更敏感,多少金额影响更积极,这些策略的背后都是大数据在起作用。我们希望用有限的资源最大化提升用户的质量和活跃度,这不可能通过人肉实现,只有技术才能实现这些。而实现的过程中,对架构、运营、产品等挑战都很大。
问:滴滴打车在大数据方面是倾向于开源技术优化还是自主研发?
张博:
我们业务分了几层。基本都是使用的开源技术。基础层面是数据平台,主要是大数据计算和存储,用的是业内比较成熟的开源系统,Hadoop。基础层上是自建的数据仓库,然后是策略架构,通过实验平台让策略迭代更加敏捷,如快速提取特征完成模型训练,并通过小流量测试验证模型,通过后迅速上线。这些都是工程方面的研发。再上面是机器学习,滴滴打车现在每天涌入的数据接近10TB,通过不断搜集用户标准数据特征,优化机器学习模型。比如推送给司机订单,司机是否抢单,这就是一个天然的标注。而通过这些标注,就可以优化学习体系。最上面就是整个大数据体系,支持新产品开发和策略决策。在我看来,目前很多开源项目演化的比较稳定,性能表现也不错,没有必要从头开始搭积木了,尽快将技术服务于应用最重要。而在不断实践中,通过对开源技术的改进和优化,在反馈给社区,我们是愿意这样做的。
问:人工智能发展速度很快。滴滴在机器学习方面已经到了什么样的程度?
张博:
我们马上会有重量级产品发布。滴滴大数据领域负责人是机器学习领域世界级顶尖学者何晓飞。我们在机器学习的投入是相当巨大的。
问:哪些宝贵的经验可以分享出来?
张博:
第一是如何应对大流量、高并发的挑战。比如每一个接口可能被访问频次如何设计,背后访问多少次缓存,数据库会读写多少次,后端每一个服务,瞬间并发量能到什么级别,每一层压力测试要扛住多大读写并发,10台机器能扛住多大读写并发等,都要做到心中有数。再比如每一次营销活动前,要对系统做一次体检,评估到底可以承接多大的量。第二是要有非常好的运维工具,要能实时监测线上每一个后端服务模块的负载,能够及时发现问题并报警。第三是设定多套应急预案,当问题发生时,团队可以尽快反应,做准备好的动作。第四是要有降级策略,在大流量冲击下,要优先保证主流层。对滴滴而言就是发单,用户发单、司机抢单是主流程,在这样的特殊情况中,积分商城等都是非主流层,可以被舍弃。
“我最开心的是,大家都飞速成长”
每一次生死战役,都是拼命在和时间赛跑。而每一次战役胜利之后,都为滴滴打车培养了优秀的实战人才。最让张博开心的是,团队成员在飞速的成长的同时,没有一个流失。
问:滴滴打车成立只有三年,但对产业的影响有目共睹。作为技术负责人,你认为最大的挑战是什么?
张博:
这三年,基本上每天都在打仗。每天都是一睁眼就要想生和死的问题。就像补贴大战时,一周数据涨了50倍,但我们完全无法应对。当时甚至出现了这样一幕,每到高峰,我们就宕机。我们宕机,对手就宕机。因为以用户都去他们那边了。当然,他们宕机,我们也宕机。当时比的是谁先稳定下来,谁能把用户留住。当时就是拼命在和时间赛跑,我们团队60多人曾7天7夜没有睡觉,吃住在公司。走过以后,回头看看,发现我们沉淀了非常多的宝贵经验,也用实战培养了更多的人才。也许,很难说一周之内就好像变了一个人,但三年来,平均每几个月就要闯一次生死关,过去了迎来新机会,过不去就死了。这样的压力下,你自己都会惊讶于自己的成长速度。一个快速成长的行业,一个快速发展的企业,你的快速成长是必然的。很多人都知道,在创业前,我在百度做搜索技术,那个时候只要在策略方面做好就可以,下面的基础设施层,如计算存储层都不要考虑。而在滴滴几乎负责各个层面,要搭建系统、要应对业务挑战、要做更多产品设计。基本没办法枚举更多了,所以最大的挑战就是应对挑战加速成长。
问:如何评价和你“共生死”的团队?
张博:
我的团队非常优秀,正因为经历了非常多的生死战役,他们每个人的成长速度会是大公司的2-3倍。也许2-3年前,他们还只是大公司技术团队的不知名的一员,但现在他们已经是滴滴打车的顶梁柱,承担了非常重要的工作。比如曾经一个iOS工程师如今负责滴滴公共产品和技术,已经成为全栈选手。这样的例子还有很多。我最开心的也是这一点,看到他们飞速的成长,而且从入职开始,没有一个流失。我们下一步会建立滴滴技术学院,每一个角色都有技术成长路线图,会有导师辅导,会有定期培训。我们也会引入高精尖人才,比如何教授等,请这些顶级专家带领大家走下去。
问:滴滴快的合并后,实施联合CEO制度,人员架构不变。但在技术团队方面是否会有合并?
张博:
技术平台和相应的架构正在做合并。我们希望变成不同的专业团队,将所负责领域做深,做精,帮助业务跑的更快。
问:未来技术规划是如何考虑的?
张博:
加大在大数据等方面的持续投入,加大在基础架构层面的投入。我们看到硅谷很多企业在大规模分布式计算、存储和机器学习的平台的投入是巨大的。比如谷歌通过对MapReduce的优化,使得其计算要远胜于其他平台。我们在这些方面也要继续学习,完善在技术方面的核心竞争力。
问:你的转型很成功。对于从CIO到CTO或者从技术骨干到CTO,这两条不同的发展路径,有什么好建议么?
张博:
从CIO到CTO,要清晰认识到技术为产品服务,产品为商业服务。CTO要有商业眼光。倒推回来,CIO要从技术入手,支撑产品发展,进而支撑公司现在和未来的商业计划。简单来说就是:从技术骨干到产品骨干,要懂互联网产品、明白用户需求,知道如何做出一款满足用户需求的产品、你要知道这些用户过来了以后,商业模式是什么,企业如何创造利润。而从技术骨干到CTO,难度更大。技术专家往往在某一领域精深,但要变成全能选手,就需要对每个领域都有所了解,找到这个领域真正的顶尖人才,然后组织起你的团队,驾驭团队实现目标。
   文章来源于大数据帮
未命名-2.png
未命名-3.png


 
推荐 1
本文由 hl_zhang0912 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

0 个评论

要回复文章请先登录注册