淘宝海量数据技术Word格式.docx
- 文档编号:615070
- 上传时间:2023-04-29
- 格式:DOCX
- 页数:14
- 大小:137.56KB
淘宝海量数据技术Word格式.docx
《淘宝海量数据技术Word格式.docx》由会员分享,可在线阅读,更多相关《淘宝海量数据技术Word格式.docx(14页珍藏版)》请在冰点文库上搜索。
以下为文字实录
大家好,我稍微纠正一下主题,不是数据可持续化之路,今天我给大家带来的是淘宝海量数据产品技术,这里面东西比较多,刚才前面老师也,吴朱华很快结束了,我们交流的时间更充分一些。
首先先自我介绍一下,我叫赵昆,淘宝花名是空无,目前负责淘宝的数据产品团队,这是我的描述,对数据都是很热爱的。
下面是微博描述,大家知道是什么吗?
在一个体育媒体上看到这样一个图我就非常喜欢,因为刚好能够描述我的一个我的微博,此处空无一人。
我先说一下一个误区,首先第一个很多人认为淘宝是一家电子商务公司,其实这个说法是非常错误的。
淘宝不敢我们现在内部和外部,我一直说我们是一家数据公司,为什么说我们不是一家电子商务公司,因为我们这家公司做的不是电子商务,因为我们有很多很多的卖家在上面,他们在上面做的是电子商务,所以他们会比我们更加懂电子商务,实际上会从销售到供应链整个环节做的非常好。
但是,我们给他们提供一个平台,对我们来说最有价值就是他们能够产生海量数据。
第二个数据越多越值钱,这个可能也是一个误区。
很多公司其实都有很多数据,什么某度,某讯,他们都有很多数据,但是淘宝数据特征就是商业数据,所以说我们认为我们的数据是非常值钱的。
后面我会给大家讲一下,我们为什么这样去说。
另一个就是说,什么叫海量?
也是今天所说的大数据,大数据是一个什么概念。
我觉得如果从我自己理解上来说,所谓大数据就是单机无法处理的情况下,这就带来一个问题单机无法处理,并不只是数据更大一些,这肯定不是。
一旦超过一个单机能够处理,所有数据跟以前都不一样了,还有云计算只是一个概念,很多人也都会,一说起云计算,就觉得会想吐的感觉,现在大家都在说云计算,各种各样的服务,各种各样的公司,各种云,总在说云计算是一个概念。
其实,对我们来说云计算是非常实实在在的东西,因为我们现在每天会跑很多很多任务,我们上午看XX,也是一个很典型的云计算平台,他有很多很多的数据会在上万台服务器上出运算,这个可能在传统的一些计算环境是无法满足的。
第二个就是对于传统海量数据产品的误区,所谓传统数据产品,实际上有很多很多,数据怎么去应用。
我们数据有这么大,其实我们要提高这个数据处理性能,其实我们就已经完成目标了,现在所谓云计算更多把目标都是放在怎么样快速把海量数据计算出来,但是很少会去关注这个查询的性能。
实际上,如果你的数据,不管你什么样的方式计算出来,如果不能很快去查,你的数据永远只是一些数字而已,产生不了任何的商业价值。
所以,我们会在怎么样提升查询的性能上,其实会做很多的事情。
我刚才也听了Admaster谢超所讲的,他们很多方面做的很不错,已经关注到别人不去关注的一些点,包括一些传统没有关注到的点,包括怎么样实施性,还有提供一个快速的用户展现,还有快速挖掘方面,这肯定是一个很重要的数据方向。
这个是大型商业产品更好,这个是几个公司大家都很熟悉了。
有些人认为商业产品一定会更好,经常也会有这些公司找我,你们给我们推一下这个产品。
但是,实际上他们能够解决的问题是说,当然能够解决一部分的问题,但对于淘宝目前已经达到海量数据,肯定是解决不了,而且他们实在太贵了,即便我们这样的公司也是买不起的。
还有一个误区就是开源产品,开源产品是不是更好,就提到Hadoop,Hadoop是不是可以解决一切问题。
大家都知道Hadoop,上午也有很多环节在讲,但是Hadoop其实发展到现在,其实时间也是在很早阶段,而且也只是为了解决一个相对来说比较特定的,海量数据存储和计算的问题。
但是,大部分他能够支持的还是一个离线存储环境,但是对于现在未来我们数据应用,我们刚刚提到要提供查询是完全不能解决的。
还有一个问题是说Hadoop的成本是不是更低,我们提到商业产品是很贵,Hadoop是开源的,是不是成本更低呢?
其实肯定也不是的。
因为Hadoop首先你的研发人员,你的工程师是非常资深的,这种开发成本是非常高的,实际上Hadoop其实本质上还是一种暴利的计算,还是有很多资源浪费,我们淘宝也做了很多尝试,都是为了把成本控制更低,如果不去控制也是难以想象,我们淘宝也面对同样问题。
但是其实我们做了很多事情,都是在怎么样来提升这个性能,压缩成本,压缩集群,一个集群去年说1千台,今年说要扩展到,去年年底说要扩展到4千台。
但是如果扩展到4千台,这个成本会有很大提升,所以我们就做很多工作,最终把这个集成规模还是压缩在2千台以内。
不能说因为Hadoop是免费的,就可以毫无截止的去使用。
还有一个数据展现不重要,上午听了很多东西,这块跟数据可视化是有关系的,后面会有一点点章节,数据展现的时候为什么这么重要。
其实前面都是废话了,这里就是我的一个大纲,今天会跟大家分享,我们在这个上面一些经验。
其实很多都是说,会来解决我们一些现实问题,我也希望这些现实问题能够跟更多公司带来一些帮助,我们也会已经开源,或者把我们各种技术都进行开源出来。
其实在淘宝,我们对技术没有一个界限,所有技术,所有代码我们全部都可以开源出来,但唯一只有一样东西是我们不会完全开放的就是数据。
我们一直在说淘宝的数据,我们就看一组数据。
这个数字是,有些可能是最新的,有些不一定是最新的,因为我做这个PPT也是很急了,东拼西凑了一些数据。
我们PV大概是20亿规模,商品数也是在8亿,这是在线商品数,淘宝商品非常多的。
这个也是说在淘宝数据也是一个很大挑战,我们注册用户数有4.4议,品牌数是8万,包括诺基亚,苹果,SPU有334万,做电子商务比较了解,其他可能不了解,SPU可以理解为是一个,或者说产品的数量,实际上本身是一个最小的定价单元。
比方说诺基亚N73就是一个SPU,iPhone4S就是一个SPU这样SPU在淘宝334万,每分钟销售的商品件数是4.8万件,高峰日成交金额是52亿元,这是刚刚过去双十一一个成长金额,所以数据规模来说是非常大的。
我们数据特点,前面是淘宝另外一个同志跟大家也讲了一部分数据特点,我这里再总结一下。
首先数据量大已经说过了,第二我们内容是很多样的,我们每天要处理的数据,日志型的,文本型的,还有关系型的数据。
还有维度非常的丰富,淘宝有一个很大的商品体系,包括近8万个品牌,近100个不同行业,五级商品肋木体系,包括三个维度,商品维度,卖家维度,买家维度,上面这些属于商品维度,卖家包括卖家所在地区,买家是他的性别,年龄这些东西。
再往下就是源数据质量,我们在做数据很多时候就是要跟这些数据作战。
因为有很多很多非法交易都是要剔除掉的,还有一些恶意,作弊的数据。
数据的杂质还是比较多的,但是相对来说,比如相对搜索引擎数据来说其实已经干净很多了,大部分都是结构化的数据。
这就是我们一个数字上,技术角度再去看我们数据量,现在总量是20PB,这里20PB是目前存储在我们存储在里面,每天大概会扫描900TB数据,每月会增加1.5P,日增0.06P数据,一天高峰阶段可能每秒要处理30G的数据。
其实前面是说数据量很大带来的挑战,下面这个是说一些业务上的挑战。
因为我们其实做数据离不开业务,对于淘宝来说业务还是非常复杂的,因为他要一个很大的交易支撑平台,首先是说我们的模式,很多时候是不清楚的。
然后数据本身的处理,因为我前面提到,我们海量数据,其实很多时候需要投入一些研发的东西,或者说白了自己必须去造,还有安全问题,我们数据要出去,或者外面数据要进来,就必须有安全过滤层,如果过滤层过于复杂就会有所影响。
此外还需要开放数据,还要防止很多数据被恶意爬取。
因为在做我们数据基础设施建设周期相对较长,去年整个也只有30亿,今年是将近52亿了,增长是非常快的。
还有自身的变化演进,我们数据本身也会不断变化,比如淘宝内部体系也会发生变化。
还有前面提到基础设施比较长,稍微补充一下,这里会导致,因为业务增长非常快,就会导致我们在做很多设计的时候,不能过度去设计,否则的话系统还没有设计完,业务早就发生很大变化,数据早就增加好几倍了,尽可能满足当前和下一步的需求,不可能考虑的多于长远。
这张是传统数据平台,有一部分还是数据仓库,他们会用到数据的一个流程,就是我们数据同步进来,到了大容量存储,这些存储可能是一些比较大的分布式存储系统。
然后通过一些计算,最初导入高性能DB,有可能是一些其他方案里面,最终提供展现。
我总结一下,有没有说,其实这在我们自己看来,对我们淘宝来说,有没有更加完美的一个数据品牌。
因为前面这个模式,前面谢超讲的很明显,肯定无法适应这种业务多变,对各种实施数据需求。
有没有一种完美平台,这个在我自己心目中是比较完美的,之后讲的我们一些技术都是围绕着这张图上几个东西,增加了一些线条,因为实施传输。
因为我们很多一些场景我们需要能够很快速的去把一些数据能够计算出来,同时就需要实时数据传输等都能配合起来。
另一个这些数据一方面要能够给用户提供一些实时展现,另一方面,这都需要计算完之后把结果反馈出来再次计算,这都是一个相对循环的过程。
其实在前面这个演讲我已经在听,谢超还讲到流计算,现在好象这个概念也是比较兴起。
但是他这里流计算,或者说他们所谓,其实也在说实时计算,更多是说我怎么样把这种实时的数据能够去通过传输,能够去把他计算出来,对数据来说是实时的,但是对于用户来说其实不是真正实时的。
不管是说通过什么模式,最终对其干预都需要你的技术人员,或者通过一些特定的框架去改变,用户无法说非常灵活的去定制自己很需要的一种场景,而且你无法说实现到一个真正一个能力去高并发满足用户外部的场景。
所以,我们这里的实时计算,除了我们诗句,我们查询需要实施之外,更重要还需要满足一个高并发查询,这可能是传统数据平台不太容易碰到的东西。
比如我们有些我们一些数据,产品,每天都会进行各种维度交叉分析,如果是一个用户,两个用户一秒钟得到结果,实际上是很简单,或者开发人员想要得到结果,把结果存在一个地方,让别人通过一个HB系统去快速读取这是比较简单,如果你要满足用户能够实时根据自己各种灵活多变的条件来定制自己的查询请求,就必须要依赖于一个很高效的实时计算系统,之后会跟大家简单讲一下我们一部分成果。
整个数据平台,整个数据流都已经包括在内,比如数据怎么样进来,怎么样能够实时进行同步,到我们底层存储,怎么样能够通过实时处理转变到我们数据到我们一些在线存储,以及支持到在线计算,以及整个离线计算环境数据流都在这个地方。
我们本身PPT也会分享给大家,大家之后可以去看一下我们这张图。
因为有一些数据,我们是需要能够,数据从数据库过来没有经过任何的延迟,直接推到用户前台,但是还需要经过一些计算。
比方说,淘宝双十二要来了,大家知道双十二吗?
双十一之后,又有双十二,12月12号淘宝又有一个大节日,很多用户会涌现到淘宝上各种疯狂购物了。
这种时候我们就需要给用户要能够看到,到底有哪些商品正在实时变化,甚至这些变化的店铺,以及那些购买达人怎么做到。
还有我们实施,后面会有一个介绍流处理引擎,实时进行计算,直接推到前台,用汇就可以看到很多实时数据。
同时还有一部分,一种会直接流到我们底层存储,还有一种流到我们在线存储,提供在线查询,还有直接流到前台去,跟最终终端用户去看,还要支持百万UV的实时查询。
我们前面讲到我们在这几个,前面这张图,我们一些各种技术,这里会相对来说每一个简单展开一下。
我们做的数据非常多,今天想跟大家分享的一个主题,只是一个方面的,我心目中完美的一张数据平台图,我们再返过来看一下。
不管是我们前面提到这些金融的系统,还是电子商务平台,还是很多公司,他如果需要用到数据场景的时候,很多时候他都离不开一个场景,其实就像我们一样,如果我们必须要有一个很清楚的东西,是我们能够用什么样的技术能够,或者搭建一个什么样的完整平台能够去满足用户各种各样的数据需求。
其实这张图,我认为至少在目前我们淘宝来说,我们各种场景其实都已经能够满足了,我们要做的事情就是为里头各个部分去储备,去研发更好的技术就可以了。
其中,首先就是海量数据的存储问题。
分布式存储计算,跟大多数公司一样Hadoop平台是一样的,首先会有一个任务,会有特定的场景,在我们需要用到文本的数据分析,一些数据挖掘,以及在进行一些更复杂计算的时候,我们会用到。
下面会用Hive,因为还会为了给前台数据开发人员提供一个很方便查询接口进行表达,我们也会支持Hive,同时有很多任务也是利用Hive来写的。
这里主要一些场景,是各种数据的中间层,以及维度的转换,指标加工。
这里跟大家分享一组数据,是我们集群,大约有有超过1800+Hadoop集群,24G+2T×
12的容量,我们会有两种类型任务,一种离线,一种在线。
离线所有任务,基本生产任务都要保证3点半前处理完成,今天之前所有任务。
为此我们开发很多实时数据同步的系统,这不是我们今天要讲的重点,所以我们都没有列进来。
我们的实时同步,包括有一些流处理的引擎,他其实不是说为了能够让用户去实时对数据进行分析,而是为了保障我们分析,计算的窗口是足够大的,让我们到这一天开始的时候,其实整个数据就已经全部在我们存储平台之上了,不需要我在去把各个地方收集各种数据。
因为我数量非常大了,会等待数据传输,所有数据进行同步,剩下可能就几个小时的计算任务。
这种一是离线的,另外是在线的,我们会有一些在线的计算,这都是需要Hadoop参与其中做各种维度转换,能够加快在线查询的效率。
另外我们还搭建了一个Mahout集群,我们已经搭建30个节点Mahout集群,实现我们至少所需要的算法。
因为Mahout这个技术还非常不成熟,只是提供一个平台,很多算法都没有完全实现,很多算法都是我们自己实现起来,只是定了一种框架和标准,这样让很多算法去通用,最终算法实现,已经提供的很多算法都不太适合很大量的数据长久,比如数据达到上万的时候就不适用了。
我刚才简单提到了,我们做很多Hadoop任务是为了做什么事情。
为了提高这种任务的复用度,我们也会做很多数据预处理,把很多处理进行一些关联,把很多维度进行预先的汇总。
前面提到,实际说是一个离线分布式存储引擎Hadoop的集群,这里我就提到一个分布式Mysql而集群,目的是为了提供一个在线访问,前面有一张图,其实有一块你需要给用户提供一个快速的查询,你不可能直接说Hadoop,或者说暴露出去给终端用户去查。
这里面很多实现了自己各种录入策略,跟我们传统所说集群有什么不一样,很多公司都会用到Mysql,也会做更多节点,上百个,上千个,我们这个集群能够做一些数据统计,一般数据你进行这种分片之后,最终查询都只需要落到一个节点上,再把你分配策略设计足够优雅,更多为了把你查询负载能够进行一些均衡。
但是我们集群能够在上面做一些统计,其实有很多很多,我们会按照一些路由策略放好,基本上也能够给用户提供快速的查询,而且也能够支持到500个QOS查询,但是不是最终在线,比如在淘宝前台访问,这是一个数据,或者大用户,很多数据分析服务来说,确实已经足够了。
这是我们的一个大概的架构图,会有一些配置,我们也会有冷节点,热结点。
内部也会有一些集成,最终输入用户也涉及到语句,通过分析最后汇总出来的结果反馈给用户。
再一个,我们再说一个挑战,对于我们现在淘宝数据一些挑战。
其实大家可以看一下自己公司,未来部分有没有这样的场景。
比如像淘宝,我们有很多行业,有100多个行业,大概有9千多个内部商品,我们属性值有2千万。
什么叫属性值呢?
就像,比如说对我们商品来说,某一个上来的颜色,红色就是一个属性值,这样类似这样的属性值在整个淘宝商品体系里头大概有2千万。
但是,如果我们能够做到多个属性值组合查询,因为数据量都很大,如果放在一张表里头也很简单,一张很大表,数据量不是很大,也可以很快速的查询出来。
但是,因为数据量很大,所以不可能直接利用数据库来解决这个问题。
很多时候我们就会预想计算出来,把一些常用的组合,或者说进行一些预计算,来减少最终计算的时间。
如果我们没有这些海量数据,又要支持各种属性任意,多个属性交叉怎么办,所以说我们其实就会需要依赖于一个,在我们所说的实施计算系统。
前面这个谢超给我们简单广告一下,这是我们淘宝自己开发的一个Prom系统,这个系统已经经过三代演进,但现在其实我们已经,目前这个东西已经开始开发下一代实施计算,也在这里跟大家简单讲一下。
我们其实最早的时候,因为前面提到,我不知道大家在听谢超讲的时候有没有留心,我们怎么样来实现这里所说的实时计算,很多数据,我们能够把一些索引建立好,最终把一些索引的值,提出来之后,做一些交集,因为交集数据是非常快的,就能满足很高性能,很多个维度实时交叉。
很多问题,一方面索引比较耗时,我们最终发现索引也会越来越大,其实也会遇到一些问题。
我们最早版本,当时是把一个数据存在索引里面,索引又存在磁盘里面,索引的量非常大在内存里面存不下,数据为什么相对小一些呢?
其实所谓的实时是直接基于明细数据计算,如果只是一些这边加在一起,所以无法估量,有很多这种情况,很多很多的组合情况,后来我们又有一个新的方案,前面提到我们引入了hbase。
我们就把索引和数据全部都已经存到hbase里面去了,空间也不是问题了,这个系统也运行一段时间,但是后来又有一个问题,每个索引他的值有一个多的属性,会把整个商品,每个交易本身维度算进去,成为每个数据量非常大,就会引发很多问题,我在计算的时候会导致内存消耗很大。
第二,在数据导入的时候也会非常的耗时。
还有一个问题,因为我们这些把这种数据取出来之后,当时是说,还需要把数据汇总到一些计算节点上,去做汇总计算,后来遇到很大问题,遇到网卡瓶颈,数据传输量非常大,后来我们又改成本地计算,实际上通过hbase的接口,每一个节点上去做本地计算,之后再转换到我们节点上进行汇总。
后面会看一下这样一个系统怎么样支持应用,这是非常灵活的。
同样还有一个问题,现在遇到的问题是说,数据导入,我们通过冗余的方式来提升计算效率的,我们又回到最初方案,直接完全内存的实时计算方案,我们还是把这个数据存在内存里面。
但是,最早我们用时候自己开发一个服务来做这种内存数据,明细数据的存储。
另一方面我们也会把这种索引,从本地进行存储,文件存储,这样的话还是能够保证到数据,一个数据基本上是没有冗余,可能会做一些容灾,本身数据上没有冗余,又能够提升这种实时计算的效率。
因为数据本身在这种内存里头计算数据非常快。
为什么索引能够放入内存,使用量非常小,相比数据来说,因为数据需要能够对本身值进行交并计算,索引可以采用一些高效的系统存储,也是能够满足一些需求的。
这是一个大概的图,为了给我们各种各样的数据应用提供一个非常方便的数据接口就开发一个数据中间岑,这是一个很高效能数据开发层。
其实我们现在已经能够做到所有各种类型数据这种查询,以及数据都是通过数据中间层来做的,基本上已经做到下层对数据应用透明,而且都是统一接口,并且能够支持restful接口,支持很多中数据。
我们可以对多种数据进行关联操作,我们内部会有高速内部商品查询接口,可以直接把Myfox当成一个接口使用,跟其他数据进行一个关联直接查询,我觉得可以把这个结果进行反馈。
而且在这一层也会实现一个简单的RS加工,目前我们测试压测单虚拟机8000qps,配置也不会很高。
再就是一个挑战了,对我们做数据的来说,还有一个挑战是说我们经常会需要进行一些实时,我们刚才前面提到,比如我要知道此时此刻在淘宝的一个实施,女装卖的最好的宝贝是什么。
女装这个内幕只有可能有上亿种商品,商品量非常多,成交也非常大,不知道直接去查,因此就需要利用我们一些云处理技术。
这是一个很快速的两个工程师,本身是基于AKKA实现,他特点能够实时去把实时能够接收到数据过来,能够进行实时处理,最终能够直接推送到这个前台去以及后台存储。
内部从逻辑上来看有一个流处理,有一个计算,没有一个完整计算框架,我们没有一个通用的计算框架,可能没有实现,我们一个相对简单的需求。
其实这个实施系统跟我们很多公司里头,应该有蛮多应用场景,数据来的很快,比如这里单台就要每秒出来1.5万数据量,每天也会处理3亿的数据量。
因为我们这个实时系统现在处理的是交易,实际上我们一天的交易是几千万,为什么有3亿?
因为会有交易状态变更,也都需要去进行处理。
所以说,我们这系统能够给前台提供实时的查询。
这是整个实时阶段应用,比如我可以实时进行汇总,比如5秒钟,5秒钟之前整个淘宝一个个内幕整体数据,以及各个内幕的成交数据,以及店铺数据,还有用户排行。
这个大部分独立其实都会基于一个很多数据累加,又回到前面所提到的一个问题,比如UA怎么处理。
其实本身处理这个系统,并不依赖于本身哪个框架,比如在这个地方我们现在就可以用这种,可以做到比如实时统计,淘宝全网UV,每个店铺的UV,工作方法很简单,就是用了一个很偷懒的,我们只需要对一个K进行一个相对累加的操作一样,如果说本身他是不能够,没有的话,其实你就可以认为这是一个新的UV。
比如说我统计一个店铺的UV,淘宝有很多店铺,我只需要把这个店铺跟用户做一个统计写到里面去。
这个至少目前来说,可能也会怀疑会不会性能上有问题,目前来说,在我们这么大数据量的情况下,其实还是能够很好应对这种场景的,有时候很简单的方法,也是能够解决一些很现实的问题。
这是更简单的数据流,其实我们这个框架更多不是一个计算框架,而是一个快速处理,是一个真正实时,我们可以理解为一个处理引擎,不仅仅需要数据能够快速从,最终能够回到平台里面去,你计算出来结果出来以后,最终能够被用户做一些修改,或者做一些设置最终又回来。
举个例子说,最后做整个店铺排行,或者叫淘宝商品排行,出去完了之后,最后我们会根据这个结果,可能会再回来进行参数调整,实际上是一个完整系统,而不是一个计算框架。
或者可以理解更准确方式,他是一个引擎,不是一个计算框架。
前面就讲到一些,我们在存储计算方面的一部分经验。
下面会看一下,我们前面会提到,为什么说很多最开始提到误区,不是我们光把数据处理完就好了,有没有数据看就不管了,这可能是对做数据的人是一个悲剧,也可能导致你最后做的东西没有任何价值。
我们就说一下为什么要研究,我们这个部门在数据可持续化上也有很多研究,这里大概列举一些,因为数据太多,而且也很难懂,而且又非常复杂,也不知道背后隐藏了什么东西。
我们一直在做数据挖掘,这是一个不得已而为之的方式,因为数据挖掘很多时候,你假设是预先设计好的,很多时候是为了论证你的假设。
但是实际上我们更多希望让大家数据里头自己去发现一些价值,因此我们就需要提供一些很好的,或者很方便的可视化的产品,让用户自己去发现价值,而不是我们分析人员,我们数据分析人员全部把这个工作做好了。
这有一个视频,这个场景,大家去过淘宝,淘宝监控大厅可以看到,是反映整个淘宝实时成交每一个飞过来就是一笔交易,卖家所在的地方发货到那个地方去,这是一笔。
实际上相当外另外一个版本
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 淘宝 海量 数据 技术