【BDTC 2017讲师专访】彭冬：微博商业基础大数据平台（D+）的架构演进

BDTC 2017中国大数据技术大会将于12月7日-9日在北京新云南皇冠假日酒店举行，大会为期三天。届时，近百位技术专家将为现场数千名的大数据行业精英、技术专家及意见领袖带来多场技术演讲，分享最新技术与实践的洞察与经验，探寻大数据发展的未来，领略数据与智能之美，欢迎大家前来参会。 大会官网：http://bdtc2017.bigdataforum.org.cn/

日前我们采访了大会推荐系统论坛的讲师微博广告技术专家彭冬，他讲带来题为《微博商业化大数据平台从0到1架构演进及应用实践》的分享，以下为正文：

彭冬，微博广告技术专家，目前主要带领基础架构团队，负责商业基础大数据平台（D+）及数据可视化平台（Hubble）、智能运维体系等广告基础设施建设，关注于大数据、人工智能、智能运维等方向。

CSDN：请向大家介绍一下自己你和目前所从事的工作，以及关注哪些技术领域？

彭冬：我2011年加入微博广告团队，先后负责了品牌广告和竞价粉丝通广告等多个微博商业化产品的架构设计和核心功能开发。目前主要带领基础架构团队，负责商业基础大数据平台（D+）、数据可视化平台（Hubble）、智能运维体系等广告基础设施建设，关注于大数据、人工智能、智能运维等方向。

CSDN：最近几个月以来，微博热点事件出现一些新的特点，一方面热点更频繁，吃瓜群众络绎不绝，另一方面影响的业务范围越来越广。同时我们也知道，微博也是的社交场景也极其复杂，随着数据量日益增长的情况下，微博的大数据平台正面临着怎样的技术挑战？

彭冬：热点事件经常出现在微博上面，也体现了微博非常强的社交属性及其传播特性，热门事件发生时，用户活跃度剧增，沉睡的用户也会被唤醒，流量会在短时间内出现成倍的增长，会对我们整个系统带来极大的挑战。对于我们大数据平台而言，数据存储部分主要是数据规模的突增以及网络IO的突增对集群的考验，计算部分尤其是实时计算部分需要更多的资源，此时我们通常会通过一定智能调度策略优先保证核心计算资源。从数据分析层面，因为主要使用离线计算，对实时性要求不高，可以适当避开高峰对资源的争抢。

CSDN：目前微博的商业基础大数据平台（D+）的架构是怎样的？

彭冬：这里也简单讲一下微博商业基础大数据平台（D+）的定位和设计目标。微博从2011年开始进行商业化尝试，逐渐形成了非常完善的广告产品生态，如果说商业化第一阶段主要以新产品形态的开拓为目标的话，微博商业化的第二个阶段应该是商业产品的精细化。精细化尤其是依托大数据平台来构建商业数据分析的上层决策会显得至关重要。D+定位于建立商业化数据（与商业化有关的一切数据）的完整生态，他包含数据采集、存储、数据仓库和数据建模、计算（离线和实时）、数据可视化和数据APIs平台的整个体系。其设计目标是作为最基础最底层的基础平台，支撑任何业务方对商业数据的分析需求。D+的架构技术栈如下图所示。

图1 D+整体架构技术栈

简单来说，D+分为数据层、计算层、中间层和应用层。D+通过APIs可以与上层更多的应用进行组合，比如监控系统和实验平台等。

CSDN：可否简单分享D+的架构演进过程？

彭冬： D+经历了大致三个阶段的发展：

1. 0.1版本 （2011-2015） 这个版本主要是将各种异构数据进行整合与搜集，通过scribe搜集所有的广告业务数据、日志数据到数据中心，为监控平台提供了数据分析能力，同时建立了简单的数据报表功能。
2. 1.0版本（2016-2017） 我们发现scribe作为数据搜集工具经常会有严重的日志堆积问题，在1.0的版本我们引入了ELK套件，我们对filebeat进行了二次开发，同时发布了微博广告版本的日志采集工具farmer，另一方面，我们将scribe替换成了Kafka，引入了多种数据聚合与关联技术。对于时序数据我们引入了Druid作为引擎，为监控平台、实验平台、查询引擎提供实时的数据存取架构。同时，我们对日志搜索这块使用了ES，对全量数据构建索引。广告主报表引擎则基于OLS（微博内部实时流计算引擎）来构建。
3. 2.0版本（2017-） 在2.0版本中，我们对D+做了重新定位，D+作为底层基础数据平台，为各个业务方提供数据存取、数据分析、数据挖掘等基础数据支撑。我们构建了分层的数据仓库系统，建立了基于业务需求的数据集市。同时在实时计算部分引入了flink。为了提供高效的数据分析能力，我们构建了OLAP平台，在D+上支持ad-hoc查询。

CSDN：同时，微博微博广告系统Hubble也是具有着极其强大的，是一个秒级大规模分布式智能监控平台，Hubble在目前的核心功能是什么？解决了哪些核心问题？

彭冬：我们知道Hubble是比较著名的太空望远镜，微博广告Hubble平台就如同这颗先进的望远镜能窥探浩瀚宇宙（大数据）的价值。我们是希望Hubble能够作为一个开发的数据可视化平台，为商业数据分析、数据计算等提供可视化的功能。Hubble 1.0最初是构建在从数据采集到实时处理再到可视化的一个智能监控平台，随着Hubble的不断发展，Hubble 2.0目前已经超越了当时仅仅支撑了智能监控平台的定位，目前专注于数据可视化，而底层数据部分托管于D+平台。我们智能监控平台也在不断发展演进，不仅在大规模时序数据实时监控上，也在动态阈值、故障预测、异常点监测等智能运维（AIOps）方向有一定的实践和尝试。

CSDN：它的整体架构是？

彭冬： Hubble 1.0（监控平台部分）底层计算部分的整体架构如图2所示：

图2 Hubble 1.0（监控平台部分）底层计算部分的整体架构图

CSDN：不管是大数据平台（D+）还是Hubble，都有着哪些机器学习的应用？

彭冬：说到大数据，不可避免就要说到数据挖掘和用户画像。D+以其强大的数据平台工程体系，在存储上和计算上可以支撑广告的用户画像和数据挖掘的能力，当然我们也依赖于公司构建的集群基础设施如Spark、Tensorflow等。在AIOps上我们使用LSTM尝试使用动态阈值来进行监控报警。由于LSTM（长短时记忆网络，RNN变体）能很好抓住时间序列上下文可能存在的联系的特性，因此模型训练方面，我们选择了LSTM模型，Python中有不少包可以直接调用来构建LSTM模型，比如Keras，Tensorflow，Theano等，我们选用Keras作为本文模型定义与算法实现的机器学习框架，选择backend为TensorFlow，同时使用均方误差（mean squared error）作为误差的计算方式，并采用RMSprop算法作为权重参数的迭代更新方案。

图3基于机器学习的趋势预测架构图

CSDN：其实您做了非常多的架构工作，可否谈下您对架构的理解？

彭冬：我觉得架构要做到三点。第一个是架构要适应业务的发展，你可以看到我们在D+和Hubble上进行了多次的迭代和架构优化，这个也是随着业务的不断发展演进而进行的，鸟枪换炮是一个过程；其次是架构要有一定程度的前瞻性，要借鉴业界的做法吸纳别人的长处，当然这里面也有不少系统工程问题，比如如何考虑系统可扩展性和兼容性；最后一点是架构存在一定的方法论，架构应该是方法论与实践论的结合，纸上得来终觉浅，绝知此事要躬行。

CSDN：以及一个架构师需要具备的技能或素养？

彭冬：我经常跟团队的同学分享一个架构师的成长阶段。第一个阶段应该是习惯养成阶段，应该注重于培养良好的编码和设计习惯，注重代码量和代码质量，注重抽象；第二个阶段应该是培养模块和系统设计能力，在关键系统设计上总结方法积累经验，懂得资源（网络IO、磁盘IO、内存、CPU等等）如何最优化利用，系统如何分层，掌握可用性、高并发、高性能的一些方法论和设计技巧；第三个阶段是培养业务思维，能站在业务需求角度思考系统架构的合理性和架构演进方向，能发现影响业务发展的系统瓶颈；第四个阶段架构师应具备产品思维。

这四个阶段也决定了架构师的四个层次，大部分架构师停留在第二个阶段和第三个阶段，第四个阶段的架构师非常稀缺，产品思维是要求架构师能够具备极其强大的系统抽象能力，将系统转化为产品，产品能非常方便地被使用。如果说前面的阶段是把系统做的足够复杂，第四个阶段则是把系统做的足够简单，所谓架构师的终极目标是恶心自己（设计了非常强大的系统），成全别人（非常易于用户使用）就是这个道理。

CSDN：最后，我也通过您的博客了解到，您对区块链的知识也非常感兴趣，可否分享下您和区块链技术的缘分？

彭冬：其实接触比特币很早，2013年挖过比特币，差点还做了比特币交易平台方向的创业。去年开始深入研究了一下比特币底层的区块链技术，发现原来技术也有玩的这么溜的，因为区块链技术其实只是进行了一些成熟技术的整合，没想到却在全球范围影响这么大。这里面有个比较有意思的事情我经常拿来鼓励我们的工程师，比特币的创始人中本聪大概是60岁完成的比特币代码，能够风靡全球，咱们还这么年轻还怕什么。

CSDN：比特币的底层区块链技术被发明之后，大量的基于区块链技术的应用被开发出来，可否从您角度分析下区块链技术的应用？

彭冬：区块链技术的研究这两年热度开始逐渐起来，很多国家央行等政府部门都开始重视，包括微软、IBM、谷歌、百度、腾讯、微博在内的各大企业也纷纷入场，也印证了区块链技术的热度。因为去中心化、安全性、时间戳机制等机制和特点，能够保证系统容错和公平性，保证信息不可篡改，区块链技术被应用在数字货币、版权、预测、社交、授权等方向。目前微博广告团队正在研究如何建立可信网络联盟，以在各个广告主、第三方监测机构和微博广告平台之间建立客观公正的监测机制；同时我们也在研究在大数据场景下，如何使用区块链技术建立公平的自动化的数据市场交易平台等等。