Zalando邱腾——Big Data Platform as MicroService,DCon2015文字实录

0001.jpg

邱腾:大家好,像刚才刘老师介绍的,我在德国一家电商做大数据平台架构这一块。

0002.jpg

简单自我介绍一下,我是也接触IT这行很多年,之前最早的时候是因为自己家里破电脑中了CIH病毒,被逼着接触了技术方面的东西,到现在被拉近坑里面将近有20年了,最早在一些网络安全的一些论坛,比如傲气雄鹰,还有一些IRC上面都是比较活跃的,比如超古老的sunnet IRC,然后自己架了一些BBS,用过一些BBS系统,比如Firebird BBS、YTHT BBS,由于种种原因大都被封了。2006年在新浪网络的系统部工作过一段时间,2008年来到德国柏林,在西门子和Fraunhofer研究机构工作,2013年开始在德国电商Zalando公司任大数据架构师,下面是我个人主页,也是有10多年的年头的,很久没有更新了,有一些老东西大家可以有兴趣看一下。刚入IT这一行的时候就看了很多杂志,这个是比较意思的一本,有没有人看到过这个杂志,当年的一个叫《电脑高手》的杂志,集齐了当年半年的杂志才能凑起来一个小人头,挺有意思的。

0003.jpg

回到正题,这次们我们分享的一个大概的内容,首先是想给大家简单介绍一下这几个Buzzword,电子商务、大数据、微服务,现在大多数的互联网企业都在往微服务的架构上靠,这个几个新的模式只是潮流词汇,还是真正能够带来生产力量的模式我们可以讨论一下。后面几个点是在向我们下午的这位主持人刘老师致敬,因为他之前做过一个分享,就是调侃了一下互联网三个不要,不要钱、不要脸、不要命,我也说一下这个三个点在德国,或者是在欧洲这样一个互联网企业大概是什么样的,然后还有上午杜总说了咱们的主题是要有干货,要有料,还要有吐槽,最后一个调侃,有大概两三页PPT的量,也就两三分钟的时间调侃一下,吐槽一下德国。

0004.jpg

首先我们来看一下所谓的电子商务,我想在座的大家有一部分是在学校,可能有一部分在互联网企业,可能就互联网从业的人很多是在电子商务这个行业,这个行业现在是一个比较热的话题,然后我所在的公司是在做时尚电商,是时尚电商是一个什么样市场规模呢,我们里看一下这个是综合的一些研究机构的包括IDC,BCG研究报告,大概对电子商务这个行业的一个分析。那么它从体量上来说,基本上和在线旅游和在线消费产品的市场是等量的,体量很大的。但是,美国企业的渗透率是很低的,20%不到,其它行业在美国企业的参透率都很高,尤其像消费品的行业,大家知道的有ebay,包括亚马逊,他们的渗透率是很高的,他们在全球都做的很好,当然在中国不是了,比如我们伟大天朝自有我们的伟大的企业,但是在欧洲亚马逊和ebay的渗透率也是很高的,所以我们的这个公司就是集中在了做时尚电商这一块,美国的企业渗透率并不是很高。

0005.jpg

这就是它的市场规模,是一个很庞大的市场。那么有一个庞大的市场就会带大很多机会,比如说有一个大的平台这么一个整合的机会,就比如说像在当地的企业会有一些平台的整合,比如说像咱们大陆的阿里要跟新浪合并,阿里要把新浪吞掉,这是一个相当惊人的本地合作的的例子;再一个就是电商的企业在做全球的布局,像跨国的一些企业还有现在合作的海外代购,像欧洲一些企业它们都是在瞄准那些新兴市场,除了中国以外比如说东南亚一些市场,这是比较热的一个方向。
基于这些大平台的战略,就会带来一些平台的整合,像并购、收购这些案例。平台的整合会带来的一个问题就是怎么保证用户的体验是一致的,比如说一家企业收购了很多其他甚至是跨国企业的平台,怎么能够保证用户在上这个国家平台和上那个国家的平台看到的界面是相似的,或者说我去购物产生的体验是相似的。再一个就是并购很多平台造成的一个运营成本的增加也是一个很大的问题,这时候大数据就可以派上用场了,大数据可以对平台的整合做一个优化,像在我们主要是在做欧洲15个国家的市场,这样就会涉及到的数据非常的复杂,多种应用都会产生数据处理的需求,然后很有很多的外部第三方平台,比如一些广告平台,做搜索的平台,还有其他的部门的数据包括最传统的一些FTP数据,CSV的一些数据。压缩的形式也多种多样,这个量也是很大,比如我们在用Google DoubleClick这个广告平台,就这一个平台每天的数据量是50个GB,还是压缩过的,就它这个一个平台每天就50GB的数据进来,我们都得要去处理它的数据,先导到我们的数据存储平台里面,然后手里拿到这么多数据有用吗,光把这数据堆着基本上浪费磁盘,这个真的能产生价值吗?这个其实我如果真的做下来这么一个数据分析平台的话,肯定可以产生价值,举一个最简单的前面几位都多次提过的一个用户画像的生成,可能在一些广告平台他们的用户画像的定义和我们的并不是非常一致,对于一个电商企业来说,用户画像可能包含了个更多的信息。因为作为电商平台我们有自己平台的销售记录,就能够对用户进行一个详细的购买行为的描述,我们再把他的购买数据和之前的广告投放中他产生的一个访问数据,以及他在我们网站内部浏览数据结合就可以做出来一个详尽的用户画像。这个用户画像可以在很多场景发挥很大的作用,比如说推荐这一块效果会是很明显的,可以做很多个性化的推荐,个性化的推产品的一个活动。
再一个就是我所在的公司是自己做仓储,大家也都知道做仓储人力成本是比较高的,所以在这块可以有很多的优化可以做。再一个就是客户在等待邮递,即下订单后,与在他收到包裹之间一些浏览行为和点击行为,因为时间关于这次我们不会涉及到这一块,但是也以后可以交流。
然后再一个点就是微服务,微服务为什么可以为平台整合做一个强大的支撑,就是因为微服务通过架构理念,可以给平台整合中,不同的组之间、不同技术团队之间融合提供一个很好的技术框架的基础。这个后面会也再给大家介绍。
 

0006.jpg

这个就之前我们刘老师的一个PPT,就是他的“戏说互联网的三个不要”,第一个就是说“不要钱”这个我不再重复了,这个说的更多的是,我觉得简单的总结一下,所谓“不要钱”更多的是一个特定的领域,概括来说就是一个信息载体的产品,如果这个产品是起到了信息载体的作用,那么它就可以免费提供,但是作为电商企业,我们要钱,不能不要钱。

0007.jpg

Zalando卖的是服装鞋帽,做时尚产品的电商,说白了就是卖服装鞋帽的,我们现在的规模是有大概3000个品牌在我们的网站上,然后初期就是通过一些电视上打广告,打折卷做推广,现在在德国上市,现在的目标是扩大盈利,在扩大盈利过程中一方面是优化一些过程,再一个就想办法挣钱更多的钱,就不可能不要钱。那要么有几个很大的问题,一个是在欧洲的人力成本、物流成本,技术案研发的成本都很高,这个怎么办呢,这个就可能跟咱们国内的邮商就不一个思路,我们很多时候不可能自研一些产品,我们很多就去用一些开源产品或者商业产品,比如像惠普的产品会列入考虑范围,会衡量一下自研产品和用商业产品的区别。再一个就是对于一家电商来说,怎么才能够更好的要钱,更户要的是更好体验,但是这个所谓的体验不等于更好地客服,举个简单的例子,比如说咱们北京的实体店里面,一进门扑上来一个热情的导购,在那边基本上没有这样的,没人搭理你,店里面没有几个人,要试你要自己找店员,完全不同的一个理念。当然可能大家各有各的喜好,体验是不同的,谁优谁劣就是见仁见智。
再一个就是我们在做数据分析方面,我们有很多优化可以做的,这也会给企业带来一定的收益。比说我们做在线推广、在线广告的优化,再一个就是WMO的优化,这是我们在仓储上面的一个概念叫做“Warehouse Movement Order” 就是这个定单可会产生你在仓库之间的一个调动,就是比如说他下了一个定单,这个订单有两件商品,客户肯定只想收到一个包裹,不能分成两个包裹寄给他,但这产品存在两个仓库里面就产生问题了,你要先把一件商品从一个仓库送到另外一个仓库,再打成一个包裹寄给客户,通过数据分析尽量第减少这样定单的产生,给企业减少的支出会是很明显的。再一就是物流上的监控,物流效率上的监控,这个大家都理解,再一个就是罢工的预案,欧洲罢工是自由的,没准物流员工动不动就罢工了,所以这个预案我们也要事先做好统计,避免是不可能的,但是怎么做到损失的最小化,也可以通过数据分析来做。数据分析这么多可以做的,我们就需要有一个大数据的分析平台,我们也提到了,人力成本的问题,我们会考虑是使用商业产品、开源产品,还是去自己研发,我们刚才说了自己去研发的成本也是比较高的,考虑投入产出比,我们还是会选择使用很多的商业产品。
 

0008.jpg

这是我们最早的BI部门的分析平台的一个架构,非常传统,非常经典的一个版本,这里我列了这个平台的一些特点,就是一个非常传统的数据架构,最上面是一个数据可视化的一个工具SAP BO,然后这个工具在当年它的用户体验是OK的,但是它有这么几个问题,软件的使用成本很高,一方面要支付SAP的费用,还有一方面要支付Oracle的费用,中间还有一个叫Exasol的东西,它是一个内存型的数据库,它作为中间的一个连接然后把Oracle里的数据拿到内存cache里面,来制作可视化的报表。这样的一个系统,它的运营成本也比高,Oracle成本也是很惊人的,还有像Exasol的专属软件,所以我们都依赖一些软件提供商,SAP的产品也都是很贵。那么这样一个架构就高度依赖核心的Oracle的这样一个连接,ETL的流程也是不灵活的,因为数据仓库高度的集中。此外查询接口也比较单一,这个接口就是在那个内存cache上的SQL接口,这个大家也能够理解,不符合我们时下最sexy的data science的工作需求。

0009.jpg

接下来是我们过渡时代的数据分析平台的架构,这时候我们就引入了Hadoop,是大概在两年多前的一个架构了。有几个变化吧,一个就是我们最上面的数据可视化的部分,我们增加了两个新的工具,不光是SAP BO,因为SAP BO现在已经有点老气横秋了,它只是支持java6,当时的一个版本太低了,不止是java,然后它的界面的用户体验也很也很差,我们增加了几个新的数据可视化的产品。下面基本上没有变,只不过加了一个Hadoop,因为我们有很大量的外部数据,我们除了一些销售数据,库存数据,还有tracking数据、广告投放数据,就是第三方平台过来的数据,我们要把这些数据导入到Hadoop里面,不让它进Oracle,因为它的量很大,也不要求很高实时性。所以我们增加了Hadoop这一层,这个用户体验跟之前也没有什么区别,但是大家也看到了,软件的使用成本基本上没有任何变化,我们还增加了Hadoop,使得运营成本更加的高。虽然是把Oracle跟上下的关联关系解放出来了,但是也并不是非常的灵活,ETL的流程也是很复杂,而且增加了一个Hadoop ETL流程。再一个就是开支是太大了,这种模式是非常烧钱的模式,就是被钱砸出来。

0010.jpg

这是最新的一个架构图,这个时候我们就是基本上所有的数据节点都云化,在BI部门我们有一个微服务云MicroService Cloud,其他的业务部门也都变成了云端的一个结点,他们也都有自己的云化产品,比如说销售数据只是从定单部门的云中产生,它通过REST API把数据发给我们,我们跟他们之间就没有一个数据库的连接,通过HTTP的协议来传这些数据,它这个量有时候会比较大,而且有实时性的要求,所以我们需要保证这个对外的REST API接口高可用。
然后这个时候我们在BI的云里面,对内也是提供REST API接口,当然还要提供传统的JDBC接口,这时候我们还是用EXASOL做一个in-memory cache,因为确实它的性能还是很好的,所以我们一直没有把它拿掉。然后这个SAP BO,我们已经决定把它拿掉了,在这个架构图中我已经把它虚线化了,我们准备完全转到MicroStrategy上面,当然这只是我们的愿景,这个还是很难在短期内实现,因为很多的员工已经习惯用SAP BO,让他们转过来确实并不容易。这个BI的微服务云中的组成和实现,我后面还会再详细的说一下。
 

0011.jpg

那么来看一下我们要去实现这个云端的微服务架构的部署细节,我们在做部署的时候这个地方的一些小的窍门还是比较多的。首先说一点就是我们现在公司是完全使用AWS云服务,它真是提供非常多的功能,所以我们可以在它的上面做一个灵活的部署工作,我们自己开发了一些小的工具做这个部署,就是一个客户端工具叫Senza,还有一个在云上面跑的所有的东西都是放在docker的容器里面跑,我们做了一个容器池,我们叫Pier One,然后跑这些docker容器虚拟机的镜像我们叫Taupage,这三个都是我们公司代理的服装品牌。大家知道这个三个名字就可以了,所有这些部署的配置,我们都是通过AWS CloudFormation进行的,通过CloudFormation我们可以去定义它的DNS,在AWS里面它叫Route53组建,然后可以定义它的Load balancer,我们可以定义它的IAM访问控制。IAM里叫角色的这么概念,可以通过Role来定义它允许访问哪些文件或者访问服务,然后最重要的一个有Auto Scaling Group,它实现了EC2虚拟机的自动扩容和关闭的工作,这个我们可以定义不同的policy,去定义什么时候需要对已部署的集群去扩容,只要定义好了这些policy,就可以通过AWS的Auto Scaling Group做自动的扩容,这个功能是很方便的,一个大概的流程图就是这个样子,首先是通过客户端的工具,去把我们的CloudFormation定义推到AWS里面,AWS会创建一些EC2的虚拟机,然后这些虚拟机从Pier One把docker拿出来运行在虚拟机上面,是这样一个流程。

0012.jpg

这样一个部署模式有什么优势,首先最重要就是它能够灵活部署系统中的组件,这也是符合企业的一个平台化的发展,各个组开发的产品可以自由地部署到AWS里面,还有一个优势就是在进行新版本发布的时候可以实现灰度发布,因为每一个发布的产品它都有一个DNS,我们可以在这些DNS上面额外做一个加权的DNS record,比如我们看到灰的一块是老版本,橙色的是新版本的应用,那么我在版本切换的时候让这两个DNS record加权的值不一样,这个时候它就可以慢慢把流量导入第二个新部署的产品上。然后直到你看到这个新部属的产品已经稳定运行了,这时候我们再把100%流量导入到新部署的产品上。

0013.jpg

另外一个问题,大家都知道用云服务的话,安全上始终是有顾虑的,那我们怎么保证AWS在公有的网络中安全的传输数据,我们定义了一个DMZ区域(非军事化区域),还有就是我们的内网区,内网区没有公网访问的权限,只有运行在DMZ区域里的虚拟机有公网访问权限,这两个不同的方块是两个不同的云帐号,这两个帐号里面,怎么让这两个在不同AWS账号里面的服务进行通讯呢,这时候我们就用HTTPS和OAuth2做一个安全的保证,我们看这两个ELB是两个Load banlancer,Elastic Load Banlancer,是AWS的负载均衡服务组件,它下面有不同EC2的虚拟机节点,EC2的节点就是提供服务的服务器,他们之上的ELB就是它的一个入口,让这两个入口的通信都是通过OAUTH2加密,身份验证之后才可以做通信,这样就保证了它的数据尽管是在公网上传输,但是它也是做到了加密和认证授权的。

0014.jpg

解决了云中灵活部署和数据传输安全保障的问题,现在就跟大家看一看我们怎么去做的我们BI微服务云的这样一个具体的实现,在这里橙色的方块都是对外服务接口,就是从外部可以访问到的服务的节点,在这个云里面灰色的块就是我们自己内部服务的组件。
我们从下往上说,下面我们有一个数据收集的Data Collection REST API,所有其他团队的云都是通过这个API把数据发给我们,然后我们后面搭建了一个Message Queue,我们现在用的是Kafka,当然这里面所有灰色的块都是我们内部使用的,这些东西可以随时换掉,这个S3换不掉,这个是一个数据存储的一个工具,只要我们还在用AWS,这个S3是换不掉的,但是Kafka有需要的话,随时可以换成其他的,当然这个涉及到我们要重写REST API,但是对外来说他们发出去数据的这个接口是始终不会变的。
然后Message Queue后面的步骤,一方面会把数据写到S3,还会有一些数据分析的业务,可以直接从Kafka里面调数据,对外提供一个数据分析的一个接口。
写在S3里面的数据我们可以通过Spark去做数据的分析,然后数据分析的结果我们也是通过REST API来对外提供,或者就是对外提供一个JDBC的接口让他通过SQL去访问我们在S3上数据。
现在我们这样一个平台的数据量规模是这样的,Zalando技术部门的员工人数现在有800+,我们有800个人的技术团队规模,90多个AWS帐户,就是我们有90多个产品组在用AWS,总共部署了160多个应用,当然不是说所有的应用都要往我们的数据收集REST API写数据,就是说我们对外服务的量,大概是在这样一个数量级,这个时候就是大家可以看到,因为我们Spark这个节点既要连对外提供数据分析服务的REST API,又要提供JDBC server的服务,这个时候Spark结点它的压力就比较大,我们就需要用高可用的spark集群架构。
 

0015.jpg

这所有这些东西都是开源的,代码量其实并不大,只是一些简单的工具,和部署的一些脚本,上面都给大家列出来。

0016.jpg

最后是一些小的吐槽,有上厕所的可以去了,后面就没什么干货了,我们刘老师说的“不要脸”和“不要命”,“不要脸”有很多种,在欧洲也有“不要脸”但是形式可能不大一样。
再一个可能就是“不要命”,刘老师更多的说的在中国的情况,用期权和价值观让员工疯狂的工作,我可以很负责任地告诉大家,欧洲没有这样不要命的,但是也没有期权,有一些小公司有期权,但是一般的公司不会给期权的,像我们卖服装鞋帽屁都没有,就是没事发个衣服,对,我们不是奢侈品,我们刚才有位朋友说我们这连轻奢可能都算不上。。。
 

0017.jpg

要不要脸是个问题,我们公司有一个特别有自知之明的口号,我们的口号是“我们要做全球领先的互联网企业”,因为大家都知道我们现在有将近1000人的技术团队,全公司9000多人,我们有仓储,所以这个人数比较多。但是我们的这个全球领先的互联网企业,带个括弧,(中美两个地区以外),还是要脸的,比不过中国,中国体量太大,我们说是这么说,但是我们有一个专门的市场部门,专门负责研究中国市场的竞争对手,说是竞争力战略研究实际上就是研究中国的竞争对手,出一个报告给高层。
再一个就是,大家都知道欧美的企业老拿知识产权说事,给咱们找事,但实际上我就拿自己公司来说,抄了不少中国市场的移动应用,但是没出格的营销方式,这是我我们确定的,这就是前几天的一个新闻说什么“裸游”就不说了。
 

0018.jpg

再一个就是“不要命”,“不要命”是没有的,命还是要要的,在德国工作条件也还是OK的,至少德国没有雾霾。德国现在有一个比较好的政策就是工作两年就可以拿绿卡,只要你有正经工作的,工作两年,只要通过一个简单德语考试,然后就可以拿到绿卡,工作语言也基本上都是英语,大家都知道德国、欧洲是高税收高福利,尽管是IT企业,真的没有加班,然后有带薪休假,薪资水平倒是不是很高,没有美国那么高,但是因为它是高税收,高福利嘛,福利比较好。消费水平,说实话,我觉得略低于北京,房租差不多,吃饭可能稍微略贵一点点,但是衣服没有北京这么贵,尤其在我们自己卖衣服的企业,我们拿衣服价钱都很低的。另外就是在欧洲对工程师是很尊重的,工程师文化很深,工匠精神也是历史悠久。

0019.jpg

最后吐槽几点,所谓闯红光,德国没有闯红灯的都是胡扯,真有急事了也是有的,当然前提是路上没有什么车,再一个就是避让所谓的应急车辆,你知道为什么大家都避让,因为应急车辆里面有人拍照,它如果拍到你没给它让的话,它给你开罚单,超级贵的罚单,你只要不避让给你拍下来你就等着在家收罚单,罚死你,所以大家当然避让了,然后所谓守时也是因人而异了,最后一个我觉得比较有意思的就是最近大众排放门的事件,我不知道大家有没有看过最新的有一个电影叫《实验者》,我觉得这个电影还蛮有意思的,说的是美国一个心理学家的一个故事,他之前做过一个实验,给你一个实验环境,让你照他说的做,你会不会服从他的说法,如果你服从他的说法你很有可能把那个实验者杀掉,当然这都是假的,不会把他真的杀掉,但是很多人都会去服从这样的安排,在这次大众排放门的事件,我觉得这绝对不是一个或者几个工程师团队能够做出来的事情,肯定是公司高层有这种的想法,他给下面做这样一个工作,他才会把这件事做起来,不管哪个国家的公司,有几个工程师说我搞这几个东西出来我就真的能把它用到发动机里面,那不是开玩笑么,人命关天的事怎么可能把这种东西弄到里面。对,然后这个就是《实验者》的海报,还有是德国的一个邮递员拿着Zalando包裹的照片,还蛮有意思的,收到我们的包裹没准会有惊喜。
我们现在也在招人,好像百度、阿里、新浪,全都已经停止社招了是吧,我们现在有1000的人的技术团队,明年计划是明年要招到2000人,我们现在有一个战略说是可能把我们的电商系统,拿出来作为产品去卖,所以技术团队正在扩张,大家有兴趣可以考虑一下。
 

0021.jpg

最后一个简单的总结:我们在AWS云上做了一个部署简单的Spark HA Cluster,加上Kafka、Zookeeper等等。为什么这么做呢?这样我们实现了微服务这样的一个架构。为什么要有微服务呢?主要就是他灵活的系统架构特性,它提供了非常好的架构模型,他能够给不同的团队一个非常高的自主权,非常的完美的配合了我们平台战略。怎么做的呢?我们自己研发了几个小工具,对外都是提供REST API和JDBC的接口,还有就是使用了AWS提供的很多服务组件API。
谢谢大家。

请点击下载

要回复问题请先登录注册