总架构师眼里的架构和架构师的成长之道
点击上方“CSDN ”，选择“置顶公众号”
关键时刻，第一时间送达！
特约记者： 卢亿雷，精硕科技(AdMaster)技术副总裁兼总架构师，CCF（中国计算学会）大数据专委委员，北京航空航天大学特聘教授。
受访嘉宾： 邓就庆（Jack），FreeWheel高级副总裁兼总架构师，拥有清华大学计算机科学学士和硕士学位。目前，他带领一支架构师团队全面负责设计和实施FreeWheel的核心系统，包括广告服务器以及报告、预测、收入和费用计算等数据处理模块。他还管理并指导基础架构团队，以支持并增强公司的服务能力，同时与运营部门密切合作，不断优化产品和服务质量。
在加入FreeWheel之前，邓就庆曾在创业公司Roxbeam担任架构师，带领一支几十人的工程师团队设计并实施基于P2P的视频流媒体解决方案，包括客户端应用、服务器程序和管理工具等。职业发展早期，他为香港科技大学供应链管理和物流原型研究项目提供技术支持，其中包括GPS车辆追踪系统和基于RFID的仓库跟踪管理系统等。
FreeWheel高级副总裁、总架构师 邓就庆
FreeWheel的技术团队架构和文化
《程序员》：你在数据视频的广告领域精耕良久，FreeWheel技术团队的组织架构是怎样的？
邓就庆：10年前FreeWheel成立时，FreeWheel CTO Diane说服了另外两个联合创始人，把整个技术团队建立在了中国北京。当时北京团队的组织架构分成两个模块：UI团队和Core团队，前者主要负责将用户的管理数据更新至数据库，后者Core团队又分为三部分：广告服务器AD Server、数据处理Reporting和预测Forecasting。
接着，FreeWheel又成立了一个新的Video Integration（客户端集成）团队，负责与客户端到端的集成，帮助客户将他们网站上的播放器集成到FreeWheel SDK，把客户的广告请求发送到AD Server模块，然后生成特定数据至Reporting模块，再将数据传至Forecasting模块用作预测，最终提供商业智能信息给客户，客户据此在UI上面来管理和调整广告。所以这段时间大概有5个团队。2011-2012年间，FreeWheel逐步开始在美国建设工程师团队，主要集中在API和集成方面。
在FreeWheel技术人员有两个发展方向：管理和技术，前者从经理→总监→高级总监→副总裁→高级副总裁→CTO；后者是从高级工程师→主任工程师→首席工程师→架构师→首席架构师→总架构师。
前面介绍的组织架构已运行多年，从2016年有了调整。在数百名工程师的规模下，若按照原有的5个团队划分会大大降低组织的有效性，所以我们慢慢转向了矩阵式管理。比如，在垂直方向，从前端的UI→广告服务器→报表的工作模式，各个团队根据某些业务应用的领域生成一个Squad（一个垂直的功能性团队），但他们的汇报关系依旧属于原来的团队，只是形成了一个虚拟的团队。目前在这种矩阵的管理模式下，FreeWheel大约有20个Squad。
《程序员》：FreeWheel的技术团队有着跨国性、跨时差性等特点，在团队管理方面有什么心得和体会可分享？
在2007-2013年，FreeWheel的技术团队都在北京，而2013年之后，随着团队壮大、在美国建立了工程师团队，以及收购了一家法国公司StickyADS，所以团队合作方面的挑战骤加，FreeWheel做了不少工作来迎接这些挑战。
首先是调整和细分团队。以一个项目为例，用Hadoop来替换旧的报表系统，在实施的过程中把一个美国团队和一个中国团队糅合到一起，共同开发一个功能，同时在这个层级下进行细微分工，相当于产生了两个Squad垂直功能性团队。
其次是尊重彼此。因为跨国的情况下不在一起工作，且时区不同，所以尊重彼此、承认彼此工作的独立性尤为重要，即使StickyADs被收购后也是独立工作的。
再者有意加强沟通合作。比如采取Rotation（轮岗）计划，中国和法国的工程师可以到美国与产品经理在两个月左右的时间中紧密地合作，访问客户、支持客户的业务、处理客户的问题，由此增加工程师对业务的了解和多边团队的沟通。
FreeWheel的技术栈和技术选型
《程序员》：你们做了很多的垂直系统，FreeWheel系统的技术架构搭建有什么特点？
FreeWheel的垂直系统跟普遍的广告系统不同，FreeWheel不拥有流量而是作为技术提供商，且大部分广告销售是Guaranteed Sale（保障性销售），客户签好合同后FreeWheel来执行合同。比如客户提出广告商的购买需求、目标流量等，FreeWheel帮助他们分配流量进而满足广告商的购买需求并增加收入，这和普通的推荐系统关系不是很大，比较近似的可能是线性规划一类的优化算法。
其次，FreeWheel的业务大多是品牌广告――按照展示收费，所以不太关注CTR（Click-Through-Rate，即点击通过率），但有时品牌广告商认为仅仅展示并不是一个特别好的指标，而会进一步关注不同目标人群的展示价值，也是受众的特性不同所致。
再者，FreeWheel系统会有一些特定的统计信息来跟踪――xTR（类似于CTR），对应的每一个展示有一个评估计数用于计费，会据此来优化广告商计费事件的比例――类似于CTR的优化点击数。现在，最常用的算法还是线性回归，也在用人工神经网络来做一些预测，建立一个基本模型部署到线上，当一个请求过来时再根据模型算它的评估计数对应事件的概率，从而选择较高的概率的结果，这类似于一般的系统。在这个基础上，有时候也会使用A/B Testing来检测模型效果。
值得注意的是，这个模型并非实时更新，而是一天一次，但其中预测是实时的，将模型做成一个服务更新至线上，每收到一个请求就检查一次，并预测应该选择的广告。
《程序员》： FreeWheel技术栈的构成是怎样的？
之前提到的Reporting和数据需求主要建立在Hadoop上，数据收集从各个服务器通过Kafka将事件基本上以接近实时的要求传输至中央数据处理系统。
FreeWheel建立了自己的数据导入模块Data Ingestion Pipeline，把收到的Log经过处理使查询优化，再存到HDFS上，此外还有另外一个Pipeline作为Disaster Recovery用于容错，数据文件放在了Amazon S3上，并通过Kafka实现实时性。在这基础上也有Mini Batch对实时数据处理而生成Dashboard。为了查询方便，存储使用了Parquet格式。存储的粒度基于事件级别，一个事件对应一条记录，不做聚集。在这个基础上，我们使用Presto，自己做了一些Connector用Presto直接查询来得到结果。
而在服务器AD Server方面用了C++和比较多的库，新的代码使用的是C++ 11, 传输用的是Protocol Buffers，NoSQL用的是收费版本的Aerospike。还应用了Memcached来缓存一些元数据。AD Server收到请求会在处理之后再把结果返回去，通过Kafka把这个过程记录下来，进而上传到数据处理系统里。
然后是提供API服务给第三方系统（比如广告管理系统）。举例来说，Operative是一家专门做Order Management的公司。同时客户一般会有自己的CMS系统。通过API，客户将数据导到我们MySQL数据库里。API和UI之前用的是Ruby on Rails，现在我们正在把UI和API分离开来，而使用类似于Single Page App的架构。新的API用Golang，也在尝试用Docker/Kubernetes来管理API服务；UI之前很多是Server Side Rendering，现在因为分离而转移到浏览器端，使用的库是Facebook的React.js。
Forecasting和Machine Learning方面使用的语言是Python和Golang，用来搭建一些服务，性能敏感的地方也有一些C++。主要库是谷歌的TensorFlow。
《程序员》：你们的技术选型选择得很好，其中你选择Presto的原因是什么？市面上也有一些其它选择，Druid如何？
用 Presto的主要原因是数据系统的升级。老系统用的是C++，类似一个自建的MapReduce，将数据记录分到各个节点用C++处理完后再合并到一个中央节点，做额外的聚集和处理。这个系统的主要问题在于做聚集以后数据修改和维护比较麻烦。FreeWheel用列式的数据库Infobright来存聚集后的报表。Infobright与HP Vertica类似，我们使用的是社区版本。这个系统上主要的工作是数据维护，数据有问题以后，更新需要重载一遍数据，量级比较大也很费时。
第二是参考一些实践后，发现Presto的设计相对比较简单，且Connector可以自己实现，相对来讲符合FreeWheel的架构设计要求。用Presto还有一个原因是来自同行业朋友的使用反馈比较好。
Druid的理念和系统设计非常不错，其他比如Impala、Kudu都是Cloudera的系统也很好，但是没有选的原因是考虑到社区规模和背后的技术团队，Facebook显得更加安全一些。
另外，Teradata和Amazon都有Presto的支持，比如Amazon现在也有了一个新服务Athena，把Presto重新包装了，从这方面来讲，Presto是一个比较安全的选择。社区支持也是很重要的考虑。例如我们用的开源版本Infobright，需要自己维护而导致出bug很难处理。
数据分析师的从业指南
《程序员》： FreeWheel的数据分析能力很强，你认为数据分析师大概需要什么样的技能，最看重的是哪一点？毕竟有偏技术、产品和业务的。
我个人认为数据分析的首要是数据，程序第二。如果一个人总是讲编程语言或各种软件等花哨的内容，我会认为他没找到方向。
数据分析师第一个应先看数据，包括数据量和数据特性，比如说数据延迟的要求，毕竟实时性的要求不一样，方法也不同。其次，也有存储策略、数据处理、数据展示、存取模式、查询模式等。举例来说，我们是有多个客户的，开始时数据按照自动方式存，客户ID不在前面，所以要查一个数据时可能需要在硬盘上面跳着查，效率就很低。后来把客户的ID放在前面再查询，读就变成Batch Mode，效率提升了10倍以上。所以，我们关注的重点就是从各个角度理解数据的特性，在这个基础上面再考虑用什么样的工具。所以面试时我们主要关注其对处理数据特性的理解。
《程序员》：你们和运营部门合作比较密切，从而优化产品跟服务质量，你认为数字营销的未来发展方向是怎么样的？
我觉得会有两个比较明显的方向，一是数据驱动，未来会产生越来越多的数据，很多决策都依据数据来驱动，而不是以往的仅凭个人的经验。其中数据有两块，首先是Targeting，即把广告定位到每个人身上， Facebook、雅虎、Verizon和谷歌就是很好的例子，他们的目标都是要接触更多的用户，从用户身上得到更准确的定位讯息，进而提高营销收入。虽然，从雅虎和Verizon的角度，他们的流量并不是特别高端的流量，内容亦不高端（“高端”指专业制作的高质量视频内容，而非用户自行上传的自拍或拍摄内容），YouTube亦是如此，但他们认可Targeting数据的价值。另外一块是报表（或者是Insight和Measurement），即如何评估一支广告的效果：有多少的受众、有多少的到达率、每个人看了多少遍、观感情况等。技术常用的是Hadoop，会有更多的日志属性，提供更多的交互查询，而不受限于预定好的报表。
在数据驱动的框架下会催生更多的Data Science需求，因此FreeWheel会提供长期或短期的一些正在变化的见解。FreeWheel每个季度会发表《FreeWheel视频行业发展趋势报告》（Video Monetization Report，简称VMR），主要是从自身业务和客户身上总结他们的业务发展趋势。我们的内部实现是将原始的数据放在Hadoop上，用Presto查询。从这些数据还会得到很多有意思的内容，比如广告消费的增加、广告消费的比例、不同观看设备的变化等。
第二个趋势是更多的程序化的互动和操作，包括人工智能的加入，程序通过API来直接交互，而不是人。比如DSP集成、SSP集成、Real-Time Bidding、Ad Exchange市场，这些都将由人工智能来完成，用户只要提一个比较高层次的目标和计划之后，就可以由程序自动来集成、优化以及执行所有的板块。
《程序员》：因为当时提到怎么样评估广告的效果。刚好我们Admaster也是做这一块的，所以我也想问一下，现在市场营销这个行业里面确实存在着大量的虚假流量，你们用什么机制和方式来识别和甄别呢？
我明白这个问题，其实我们的业务与普通的那些做市场的企业有一些区别，我们更多是作为广告技术提供商，客户基本上很多都是大的内容商，所以这种反虚假流量的工作并不是特别多。但是我们还是会做一些审计。如之前讲述的，我们用的是原始的Log。现在的主要做法就是跟踪从某个IP出来的所有流量，每个用户有一个ID，也会跟踪每个用户的行为。比如这个用户发来一个重复的请求，或者这个用户包括这个IP每天发来的请求数特别多，而且这个IP不是一个已知的服务端的集成，又或者某个用户在发起请求的时候，速度特别快，发的特别多――类似这些情况，我们就会去统计，就会去留意是否存在问题。其实很多时候我们是靠设一个域值去监控，加一些规则去进行跟踪。之前有家名为White Ops的监控公司，会提供可疑的IP列表。经过检查，我们基本上没有出现在其列表里的IP地址。FreeWheel监测到的虚假流量相对来说是比较少的，因为它没有太多的经济驱动。而我们产生的非法流量更多是因为集成的错误，或者是一些比较低级的机器人，而不是一些很复杂的工具。
《程序员》：国内外数字广告领域有什么异同？
我觉得行业背景可能还是不一样，国内好像没有太多像国外那种比较大的内容商用第三方的系统来帮他们投放广告。国内比较大的内容商，比如说门户网站，有几家他们都用自己的广告系统，做得不错。而大的视频网站，比如优酷、爱奇艺等，也都有自己的广告系统。
另一方面，美国的电视台内容服务相对比较好，且版权保护和版权管理也比较完备，在美国他们也有基础把这个事情做好。所以国外内容商使用第三方的技术提供商从经济上来说会比较合理，不用自己去建立一个系统。因为他们的优势在于内容的制造和销售，而不在于技术，这对他们来说是一个成本问题。这方面的区别比较大。
总架构师眼里的架构和架构师的成长
《程序员》：作为FreeWheel总架构师，你对架构是如何理解的？
关于这点，Microsoft Office的主管Terry Crowley发表过一篇文章，《Education of a Programmer》。文中总结得很好，建议大家可以去看一下。我的理解跟他的文章基本是一致的。此外Google的Jeff Dean也对此有很多独到的见解。
总的来说就是，架构要在理想和现实之间折中，保证架构的设计实用可行“接地气”，且又不过于“山寨”。具体总结为以下几点：
1. 要端到端地审视系统
因为无论在课本教学还是文章介绍中，讲解分析往往只是集中在一个系统的某一个小块地方，会加以简化与假设。但在现实中，系统则应该从端到端来处理，因此用这个模式来考虑问题，会得到一个比较合适的结果。否则可能会只看到局部，而丢掉全局的把控。谷歌的Jeff Dean也曾阐述过这一问题，强调要理解整个系统是如何串在一起的。
2. 对复杂性的理解和控制
因为只要是一个系统，到最后都会变得相当复杂，有各种原因导致它越来越复杂。对此我有一些经验，比如尽量把复杂性控制在一个地方，然后再通过一些分层次、模块之类的方法来将其隔离开来。我觉得对于做架构来说，很重要的一个工作就是对复杂性的控制，因为所有的系统到最后如果崩溃的话，基本上都是因为复杂性失控导致的。
3. 关注分布式
目前，所有的系统基本上都是分布式的，所以在设计系统时基本上都是以分布式为先，应该假设这个系统就是分布的。分布式代表什么？比如说一个请求可能会失败，你要做好对失败的处理，一个请求可能会不在你期望的时间内返回，会有一些超时的设计，可能涉及资源竞争。总而言之，各种在单机和单个程序内不会发生的错误，在这个产品里面都会出现，所以在设计的时候，一定要把这些因素考虑在内。
4. 性能
虽然Donald Knuth曾说过一句颇有名的话，就是“所有未成熟的性能优化是所有罪恶的根源”，意思是过早地做优化对整个系统是不利的。但是，还有一点我觉得可能没有说太清楚。所有的系统设计其实都应该有一些性能的考虑在内。虽然说不要过早做优化，但是应该定好几个标线。与此相关的还有Jeff Dean在一个PPT里列出来的：你应该对各个硬件和软件的各种延迟、各种吞吐量，有一些量化的理解，无论是硬盘、SSD、内存，还是CPU Cache，都应当有一个量级上的理解，以此保证你对这个性能的预估不会差得太离谱。因为如果架构开始出错，性能设计存在瓶颈，最后将极难推广。
5. 技术以外的其他因素
其实在我看来，架构是几个因素的综合考虑，包括：
技术，也就是目前有哪些技术可以用；
人员分配，你现在有哪些技术人员可以用。因为不同的工程师可能使用的技术不一样，举例来说，有些热门语言，比如Erlang VM上的Elixir，还有Spark、Scala等的适用人群和像是Python、PHP，或者Golang、C++等语言是不一样的。
产品，不同的产品对人和技术的要求可能也不一样；
时间表，你打算何时发布你的产品？
架构需要从这几个角度全面考虑，找到一个折中的点，也就是可行的位置。有时在这几点受限的情况下，可能是很难找到这个各方面都满意的平衡点。我认为架构师需要从这些因素排选，比如说某产品不行，就要砍掉一些功能；这些人员、这些技术不合适，可能就需要换技术或人；时间表如果满足不了就往后延迟――这是一个动态的过程，通过调整这几个因素来寻求平衡。
《程序员》：因为我自己是从一个程序员慢慢成长为一个架构师，你觉得这两个角色最大的区别是怎么样的？
程序员更多是考虑一个局部的问题，而架构师可能更侧重全局考量。程序员眼中更倾向于一个点化的世界，可以有很多假设，但架构师往往不能有那么多假设，他需要根据实际情况来考虑问题，包括所掌握的人力资源、技术限制、时间安排等――在这些因素的约束下，选择将受限，一切也不再那么理想化。
另外一方面，架构师对知识了解的广度和深度，可能比程序员要高一些。因为架构师的某些决策，有时甚至会对他人的最终结果产生影响。如果程序员写了很多代码，那个代码却无法做出产品，这无疑是时间的浪费，而我觉得在这一方面，架构师应该承担更多责任。
最后，架构师需要跳出技术――这是我想要给大家分享的一个建议，即不完全只看技术，而是要综合考量包括技术和技术以外的因素，将其想象成一个类似于数学优化的问题。换一个角度来说，就是给你一些材料比如技术和人员，你要获得结果包括产品和团队，而这个时候很多情况是不理想的、有限制的，包括预算和时间的限制，所以你要思考如何灵活处理这个问题，包括调整各种输入、限制，甚至是输出，从而获得更优或者至少是可行的方案。架构师的世界，不仅仅是技术，通常囊括人员、沟通、产品等各种因素。把这些因素都考虑进去，才是一个完整的架构设计。
-------- 热闻回顾 --------
30年编码经验浓缩的10条最佳实践
Facebook如何抄袭逼死其他创业公司的？
程序员有什么错？凭什么杀我祭天
Google 工程师一天写多少代码？