微服务时代的大数据分析平台的演变
邱腾:大家好,我在德国一家电商做大数据平台架构这一块。
简单自我介绍一下,我是也接触IT这行很多年,之前最早的时候是因为自己家里破电脑中了CIH病毒,被逼着接触了技术方面的东西,到现在被拉近坑里面将近有20年了,最早在一些网络安全的一些论坛,比如傲气雄鹰,还有一些IRC上面都是比较活跃的,比如超古老的sunnet IRC,然后自己架了一些BBS,用过一些BBS系统,比如Firebird BBS、YTHT BBS,由于种种原因大都被封了。
2006年在新浪网络的系统部工作过一段时间,2008年来到德国柏林,在西门子和Fraunhofer研究机构工作,2013年开始在德国电商Zalando公司任大数据架构师,下面是我个人主页,也是有10多年的年头的,很久没有更新了,有一些老东西大家可以有兴趣看一下。刚入IT这一行的时候就看了很多杂志,这个是比较意思的一本,有没有人看到过这个杂志,当年的一个叫《电脑高手》的杂志,集齐了当年半年的杂志才能凑起来一个小人头,挺有意思的。
回到正题,这次们我们分享的一个大概的内容,首先是想给大家简单介绍一下这几个Buzzword,电子商务、大数据、微服务,现在大多数的互联网企业都在往微服务的架构上靠,这个几个新的模式只是潮流词汇,还是真正能够带来生产力量的模式我们可以讨论一下。
后面几个点是在向我们下午的这位主持人刘老师致敬,因为他之前做过一个分享,就是调侃了一下互联网三个不要,不要钱、不要脸、不要命,我也说一下这个三个点在德国,或者是在欧洲这样一个互联网企业大概是什么样的,然后还有上午杜总说了咱们的主题是要有干货,要有料,还要有吐槽,最后一个调侃,有大概两三页PPT的量,也就两三分钟的时间调侃一下,吐槽一下德国。
首先我们来看一下所谓的电子商务,我想在座的大家有一部分是在学校,可能有一部分在互联网企业,可能就互联网从业的人很多是在电子商务这个行业,这个行业现在是一个比较热的话题,然后我所在的公司是在做时尚电商,是时尚电商是一个什么样市场规模呢,我们里看一下这个是综合的一些研究机构的包括IDC,BCG研究报告,大概对电子商务这个行业的一个分析。
那么它从体量上来说,基本上和在线旅游和在线消费产品的市场是等量的,体量很大的。但是,美国企业的渗透率是很低的,20%不到,其它行业在美国企业的参透率都很高,尤其像消费品的行业,大家知道的有ebay,包括亚马逊,他们的渗透率是很高的,他们在全球都做的很好,当然在中国不是了,比如我们伟大天朝自有我们的伟大的企业,但是在欧洲亚马逊和ebay的渗透率也是很高的,所以我们的这个公司就是集中在了做时尚电商这一块,美国的企业渗透率并不是很高。
这就是它的市场规模,是一个很庞大的市场。那么有一个庞大的市场就会带大很多机会,比如说有一个大的平台这么一个整合的机会,就比如说像在当地的企业会有一些平台的整合,比如说像咱们大陆的阿里要跟新浪合并,阿里要把新浪吞掉,这是一个相当惊人的本地合作的的例子;再一个就是电商的企业在做全球的布局,像跨国的一些企业还有现在合作的海外代购,像欧洲一些企业它们都是在瞄准那些新兴市场,除了中国以外比如说东南亚一些市场,这是比较热的一个方向。
基于这些大平台的战略,就会带来一些平台的整合,像并购、收购这些案例。平台的整合会带来的一个问题就是怎么保证用户的体验是一致的,比如说一家企业收购了很多其他甚至是跨国企业的平台,怎么能够保证用户在上这个国家平台和上那个国家的平台看到的界面是相似的,或者说我去购物产生的体验是相似的。
再一个就是并购很多平台造成的一个运营成本的增加也是一个很大的问题,这时候大数据就可以派上用场了,大数据可以对平台的整合做一个优化,像在我们主要是在做欧洲15个国家的市场,这样就会涉及到的数据非常的复杂,多种应用都会产生数据处理的需求,然后很有很多的外部第三方平台,比如一些广告平台,做搜索的平台,还有其他的部门的数据包括最传统的一些FTP数据,CSV的一些数据。压缩的形式也多种多样,这个量也是很大,比如我们在用Google DoubleClick这个广告平台,就这一个平台每天的数据量是50个GB,还是压缩过的,就它这个一个平台每天就50GB的数据进来,我们都得要去处理它的数据,先导到我们的数据存储平台里面,然后手里拿到这么多数据有用吗,光把这数据堆着基本上浪费磁盘,这个真的能产生价值吗?
这个其实我如果真的做下来这么一个数据分析平台的话,肯定可以产生价值,举一个最简单的前面几位都多次提过的一个用户画像的生成,可能在一些广告平台他们的用户画像的定义和我们的并不是非常一致,对于一个电商企业来说,用户画像可能包含了个更多的信息。因为作为电商平台我们有自己平台的销售记录,就能够对用户进行一个详细的购买行为的描述,我们再把他的购买数据和之前的广告投放中他产生的一个访问数据,以及他在我们网站内部浏览数据结合就可以做出来一个详尽的用户画像。这个用户画像可以在很多场景发挥很大的作用,比如说推荐这一块效果会是很明显的,可以做很多个性化的推荐,个性化的推产品的一个活动。
再一个就是我所在的公司是自己做仓储,大家也都知道做仓储人力成本是比较高的,所以在这块可以有很多的优化可以做。再一个就是客户在等待邮递,即下订单后,与在他收到包裹之间一些浏览行为和点击行为,因为时间关于这次我们不会涉及到这一块,但是也以后可以交流。
然后再一个点就是微服务,微服务为什么可以为平台整合做一个强大的支撑,就是因为微服务通过架构理念,可以给平台整合中,不同的组之间、不同技术团队之间融合提供一个很好的技术框架的基础。这个后面会也再给大家介绍。
这个就之前我们刘老师的一个PPT,就是他的“戏说互联网的三个不要”,第一个就是说“不要钱”这个我不再重复了,这个说的更多的是,我觉得简单的总结一下,所谓“不要钱”更多的是一个特定的领域,概括来说就是一个信息载体的产品,如果这个产品是起到了信息载体的作用,那么它就可以免费提供,但是作为电商企业,我们要钱,不能不要钱。
Zalando卖的是服装鞋帽,做时尚产品的电商,说白了就是卖服装鞋帽的,我们现在的规模是有大概3000个品牌在我们的网站上,然后初期就是通过一些电视上打广告,打折卷做推广,现在在德国上市,现在的目标是扩大盈利,在扩大盈利过程中一方面是优化一些过程,再一个就想办法挣钱更多的钱,就不可能不要钱。那要么有几个很大的问题,一个是在欧洲的人力成本、物流成本,技术案研发的成本都很高,这个怎么办呢,这个就可能跟咱们国内的邮商就不一个思路,我们很多时候不可能自研一些产品,我们很多就去用一些开源产品或者商业产品,比如像惠普的产品会列入考虑范围,会衡量一下自研产品和用商业产品的区别。
再一个就是对于一家电商来说,怎么才能够更好的要钱,更户要的是更好体验,但是这个所谓的体验不等于更好地客服,举个简单的例子,比如说咱们北京的实体店里面,一进门扑上来一个热情的导购,在那边基本上没有这样的,没人搭理你,店里面没有几个人,要试你要自己找店员,完全不同的一个理念。当然可能大家各有各的喜好,体验是不同的,谁优谁劣就是见仁见智。
再一个就是我们在做数据分析方面,我们有很多优化可以做的,这也会给企业带来一定的收益。比说我们做在线推广、在线广告的优化,再一个就是WMO的优化,这是我们在仓储上面的一个概念叫做“Warehouse Movement Order” 就是这个定单可会产生你在仓库之间的一个调动,就是比如说他下了一个定单,这个订单有两件商品,客户肯定只想收到一个包裹,不能分成两个包裹寄给他,但这产品存在两个仓库里面就产生问题了,你要先把一件商品从一个仓库送到另外一个仓库,再打成一个包裹寄给客户,通过数据分析尽量第减少这样定单的产生,给企业减少的支出会是很明显的。
再一就是物流上的监控,物流效率上的监控,这个大家都理解,再一个就是罢工的预案,欧洲罢工是自由的,没准物流员工动不动就罢工了,所以这个预案我们也要事先做好统计,避免是不可能的,但是怎么做到损失的最小化,也可以通过数据分析来做。数据分析这么多可以做的,我们就需要有一个大数据的分析平台,我们也提到了,人力成本的问题,我们会考虑是使用商业产品、开源产品,还是去自己研发,我们刚才说了自己去研发的成本也是比较高的,考虑投入产出比,我们还是会选择使用很多的商业产品。
这是我们最早的BI部门的分析平台的一个架构,非常传统,非常经典的一个版本,这里我列了这个平台的一些特点,就是一个非常传统的数据架构,最上面是一个数据可视化的一个工具SAP BO,然后这个工具在当年它的用户体验是OK的,但是它有这么几个问题,软件的使用成本很高,一方面要支付SAP的费用,还有一方面要支付Oracle的费用,中间还有一个叫Exasol的东西,它是一个内存型的数据库,它作为中间的一个连接然后把Oracle里的数据拿到内存cache里面,来制作可视化的报表。
这样的一个系统,它的运营成本也比高,Oracle成本也是很惊人的,还有像Exasol的专属软件,所以我们都依赖一些软件提供商,SAP的产品也都是很贵。那么这样一个架构就高度依赖核心的Oracle的这样一个连接,ETL的流程也是不灵活的,因为数据仓库高度的集中。此外查询接口也比较单一,这个接口就是在那个内存cache上的SQL接口,这个大家也能够理解,不符合我们时下最sexy的data science的工作需求。
接下来是我们过渡时代的数据分析平台的架构,这时候我们就引入了Hadoop,是大概在两年多前的一个架构了。有几个变化吧,一个就是我们最上面的数据可视化的部分,我们增加了两个新的工具,不光是SAP BO,因为SAP BO现在已经有点老气横秋了,它只是支持java6,当时的一个版本太低了,不止是java,然后它的界面的用户体验也很也很差,我们增加了几个新的数据可视化的产品。下面基本上没有变,只不过加了一个Hadoop,因为我们有很大量的外部数据,我们除了一些销售数据,库存数据,还有tracking数据、广告投放数据,就是第三方平台过来的数据,我们要把这些数据导入到Hadoop里面,不让它进Oracle,因为它的量很大,也不要求很高实时性。
所以我们增加了Hadoop这一层,这个用户体验跟之前也没有什么区别,但是大家也看到了,软件的使用成本基本上没有任何变化,我们还增加了Hadoop,使得运营成本更加的高。虽然是把Oracle跟上下的关联关系解放出来了,但是也并不是非常的灵活,ETL的流程也是很复杂,而且增加了一个Hadoop ETL流程。再一个就是开支是太大了,这种模式是非常烧钱的模式,就是被钱砸出来。
这是最新的一个架构图,这个时候我们就是基本上所有的数据节点都云化,在BI部门我们有一个微服务云MicroService Cloud,其他的业务部门也都变成了云端的一个结点,他们也都有自己的云化产品,比如说销售数据只是从定单部门的云中产生,它通过REST API把数据发给我们,我们跟他们之间就没有一个数据库的连接,通过HTTP的协议来传这些数据,它这个量有时候会比较大,而且有实时性的要求,所以我们需要保证这个对外的REST API接口高可用。