曾经踩坑党,如今护航忙 | 袋鼠云的双11故事之一

普通人提起双11,谈的都是剁手党

袋鼠云提起双11,谈的却是踩坑党

每年双11,同样的通宵达旦、同样的激动万分、同样的心跳加速,同样的肾上腺素增加,不一样的是:剁手党在Happy,踩坑党在忧虑。

这个双11,袋鼠小妹采访了曾经参与过阿里双11的几位袋鼠云技术专家,为大家分享他们别样的双11故事。他们分别是袋鼠云首席大数据架构师申杭、首席数据库架构师俊达(大家尊称:达叔),首席运维专家留良、首席售后服务专家南晨。(恩,都是首席,Teamleader级别)

袋鼠小妹有故事,那你准备好酒了么?

————

“ 曾经踩坑党,如今护航忙 ”

袋鼠云的双11故事 第一章

 from 申杭

申杭(花名)

原阿里巴巴无线事业部-数据服务团队

现任袋鼠云首席大数据架构师

袋鼠小妹:杭哥,先介绍一下原来你在阿里所在的团队吧。

 

申杭:啊,让我想想是哪个团队。。

(袋鼠小妹OS:哥哥,你都不记得你原来的部门名字了么。。。。)

申杭:事业部就是无线事业部,团队好像就叫数据服务团队(疲惫脸),反正就是干活(苦力)的那个部门。

 

袋鼠小妹:那之前在双十一时,你们团队主要负责做什么?

 

申杭:我们是负责为集团所有的移动应用(App)提供数据服务,比如手机淘宝、天猫app、钉钉等。

当时整个阿里无线数据一天大概有数千亿记录的增量,为阿里集团开展广告投放、搜索引擎、个性化推荐、精准营销,GProfile等提供数据技术支撑。

比如我们当时开发的一个产品叫 “无线数读”,这个产品主要为阿里系的各个APP提供运营状况分析。

划重点一:

“ 高效计算鲜活的数据,并让数据价值实时得到体现,在日增数据量几千亿的情况下,需要有强大的计算能力和技术保障能力做为支撑。

袋鼠小妹:那么那时候双11做这些数据应用,技术难点有哪些?

 

申杭:如何对庞大数据进行高效、快速的实时计算和处理,从而为后续数据应用提供支撑,保证数据应用的时效性是最大的难点。

 

数据在它产生的几秒以内,是最鲜活的,是最有价值。拿个性化推荐来讲,比如我下单买了一个登山杖,如果在页面能实时或者下单之后的5秒以内给我推荐一个登山鞋,那我可能会点进去看看,如果推荐的商品符合我的需求和喜好,那么,我可能就会一起下单消费。但是如果要是在一小时之后,一天之后,在我已经关闭掉购买页面之后,再我推荐登山鞋,我可能注意力已经不在登山这件事儿了。

 

再拿精准营销的应用举例,精准营销是以人、商品的数据标签化为基础,以阿里的庞大的用户数量、商家数量、商品类目,进行实时精准营销,这个难度可想而知。

 

所以,高效计算鲜活的数据,并让数据价值实时得到体现,在日增数据量几千亿的情况下,需要有强大的计算能力和技术保障能力做为支撑。

袋鼠小妹:现在在袋鼠云,还在为哪些客户做双11的数据服务?

 

申杭:比如我们现在正在服务的百草味。

袋鼠小妹:啊,百草味我知道,好像我们是在为他们做今年双11的可视化大屏。

 

申杭:对。像往年天猫双11的实时作战大屏一样,百草味也有意愿做一个这样的可视化大屏,对外实时展现百草味各渠道在双11当天的销售信息,物流信息等,对外展示百草味的强大品牌影响力和技术实力。

 

袋鼠小妹:看起来设计酷炫,动态效果震撼的可视化大屏其实背后实现是很复杂的,需要强大的实时计算以及数据处理能力为支撑。那么在做百草味可视化大屏项目时,主要的技术难点有哪些?

划重点二:

“ 业务系统非常复杂,数据分散存储,异表数据实现同步实时计算、处理、展现是难点。

申杭:技术难点主要有两点,数据迁移和双流join

 

先说第一点,数据迁移。数据迁移到云上为什么会成为难点,因为要做的不是普通的数据迁移,而是数据的实时迁移,从云下迁移到云上的过程中,数据指标的计算要是实时的。同时,目前客户采用的是分库分表的数据库架构,巨量的数据分别散落在20多个数据库实例中,需要快速无感知、安全0丢失、保证后期可维护性的同时进行数据迁移。

 

第二点双流join。

 

袋鼠小妹:什么是双流join?我只知道join是一个数据库领域的术语。

 

申杭:确实是数据库相关的。双流,可以顾名思义一下,就是有两个数据流。

由客户本身ERP和业务系统决定,现在客户有两张大表,我们称为主从表结构。主表主要承担主要数据信息的存储,比如用户ID、订单ID、订单金额等。从表则负责承担业务明细信息的存储,比如购买商品的数量、商品的类目尺寸明细等。也就是说同一个订单的数据是分散在两张表中的,需要通过join,进行同步数据处理,像双11这样的时间节点,交易量在瞬间达到峰值,还有很多秒杀、爆款产品的抢购等活动,在这样高并发场景中,做到实时的、同步的数据处理和展现,就是一个技术难点。

 

但是袋鼠云有强大的DBA团队,他们在过去负责和参与双11的活动中,踩过无数的坑、接受过更复杂的技术考验,熟悉双11活动技术演练的环节和流程,感谢DBA团队的技术支撑。同时袋鼠云大数据团队熟悉阿里云大数据的整个技术架构体系,通过两支团队的强强联合,这个难题一定会得到解决。

 

袋鼠小妹:那对比一下,现在在袋鼠云和客户一起作战双11,和以前在阿里护航双11,你觉得有哪些不一样的感受?

 

申杭:先说一样的感受吧,那就是当双11到来的时候,都是既兴奋又忧虑的。兴奋的是,看到双11作战大屏上的交易数字,以及大家买买买的happy时,想到这些背后由自己所在的团队做技术支撑,这么多人在体验和享受自己的努力成果,是很兴奋的。但是也是忧虑的,交易额越来越高的时候,这样高并发的场景,我们的技术到底能不能得到支撑,虽然之前做过无数次的演练,也有无数的预案方案,但会不会有一些突发情况之前没有考虑到,还是心惊胆战的。

 

不一样的感受,之前在阿里是在给整个集团做技术支撑,现在则是给像百草味这样的客户一样,对外输出之前积累的经验,这个是不一样。

(袋鼠小妹OS:恩,这个回答很官方。。。)

袋鼠小妹说:

 作为一个资深的大数据架构师,申杭更多的是从大数据的角度来谈双11狂欢夜背后的技术支撑力量,那么接下来的三篇,还将会结合袋鼠云本次双11期间服务的客户案例,更深入地和大家探讨双11护航工作的每个环节。

最后:

敬请期待  袋鼠云的双11故事 第二章  from 南晨

时间: 2024-10-26 09:48:50

曾经踩坑党,如今护航忙 | 袋鼠云的双11故事之一的相关文章

"双11"网购五大真实诈骗“坑”,求不要踩进去

今天,编辑正在列今年的"双11"购物清单时(老板,是午休时间写的,不要扣工资),360互联网安全中心的朋友发来微信:"听说你这次又想剁手了,需要我告诉你5个可能踩到的网络诈骗坑吗?""你发誓不是在给我安利你家?""不是!拍着胸脯保证!天地良心!" 作为一个资深购物节剁手党,编辑看过了这五个案例后,决定吃了这把"安利".另外,听说这些案例是由 公安部门与360互联网安全中心联合发起成立的猎网平台搜集,这是国内

SQL Server在AlwaysOn中使用内存表的“踩坑”记录

前言 最近因为线上alwayson环境的一个数据库上使用内存表.经过大概一个星期监控程序发现了一个非常严重问题这个数据库的日志文件不会截断,已用空间一直在增加(存在定时的每个小时的日志备份),同时内存表数据库文件也无法删除,下面就介绍一下后面我的处理过程,话不多说了,来一起看看详细的介绍吧. 数据库:SQL Server2014 Enterprise Edition (64-bit) 删除文件 使用一个单独非alwayson环境的数据库测试. 一.创建内存表 ---创建内存表文件组 ALTER

秦苍科技是如何管理数百个微服务并避免踩坑的?

[编者的话]过去两年中,微服务架构是一个非常热门的技术名词.秦苍科技也在微服务方面做了大量的投资和实践,我们有开发.测试.准生产.生产四套环境,每套环境有230+个微服务,总共有近1000个微服务. 本文讲的是秦苍科技是如何管理数百个微服务并避免踩坑的?秦苍科技为什么要采用微服务的架构?如何管理这么多微服务?本文将对这些问题进行阐述,希望对正在踩坑路上和即将踩坑的朋友们有所帮助. 为什么要使用微服务 关于微服务架构优点有很多讨论.但是,个人认为许多优点都可以算作一些"伪优点".例如:

【踩坑经历】一次Asp.NET小网站部署踩坑和解决经历

2013年给1个大学的小客户部署过一个小型的Asp.NET网站,非常小,用的sqlite数据库,今年人家说要换台服务器,要重新部署一下,好吧,虽然早就过了服务时间,但无奈谁叫人家是客户了,二话不说,上,源代码和以前的文件都有,部署还不是分分钟的事情,打开IIS挂上去就行了.谁知道,这个部署将近花了2天的时间.看看踩坑过程和解决方法. 本文原文地址:http://www.cnblogs.com/asxinyu/p/4380380.html 回来一看,9个反对,我心痛啊,这些童鞋,你们觉得这篇文章哪

JavaScript 踩坑心得— 为了高速(下)

一.前言 本文的上一篇 JavaScript 踩坑心得- 为了高速(上) 主要和大家分享的是 JavaScript 使用过程中的基本原则以及编写过程中的心得分享,本文主要和大家聊聊在各个使用场景下的 JavaScript 使用,以及在性能优化方面的优化经验等 二.各种场景下的 JavaScript 1.用于 UI 应用的 JavaScript 与大多数服务器端语言一样,用于客户端应用的 JavaScript 框架从来就不缺少.然而,和用在后端应用与服务中一样,笔者偏好使用较小的模块,将这些小模块

Android Studio踩坑记

拾起Android项目,需要使用Goolgle Play Services.顺应潮流换了Android Studio,开启了踩坑之旅. 尝试直接将Eclipse项目导入AS,结果根本没法用啊.正确的方法应该是升级ADT,在Eclipse下导出build.gradle然后再导入.但是升级的时间还不如直接新建项目把资源拷进去,同时也能了解一下AS默认的项目结构. 第一个遇到的问题是新建的项目没有assert和lib目录.java和res等资源都在src/main目录下,于是我将assets和libs

JavaScript 踩坑心得— 为了高速(上)

一.前言 很多情况下,产品的设计与开发人员一直想打造一套高品质的解决方案,从而快速.平稳地适应产品迭代.速度是衡量产品适应性的真正且唯一的标准,而且,这并不是笔者的一家之言. 「速度是衡量适应能力的真正指标.」 --艾瑞克·埃利奥特 许多公司选择 JavaScript,就是看中了它灵活.快速的优点.尽管此言非虚,但如果你在构建 JavaScript 系统时考虑得不够周全,灵活与高速的特性反而可能将你带入歧途. 一些值得特别关注的问题包括: 代码重复 样式或风格不一致 无法随意扩展 工具与模块选择

踩坑CBO,解决那些坑爹的SQL优化问题

本文根据DBAplus社群第93期线上分享整理而成.   讲师介绍  丁俊 新炬网络首席性能优化专家 SQL审核产品经理   DBAplus社群联合发起人,<剑破冰山-Oracle开发艺术>副主编. Oracle ACEA,ITPUB开发版资深版主,十年电信行业从业经验.   本次分享大纲: CBO优化器存在哪些坑 CBO优化器坑的解决之道 加强SQL审核,将性能问题扼杀于襁褓之中 分享现场FAQ   CBO( Cost Based Optimizer)优化器是目前Oracle广泛使用的优化器

Spark踩坑记:共享变量

前言 前面总结的几篇spark踩坑博文中,我总结了自己在使用spark过程当中踩过的一些坑和经验.我们知道Spark是多机器集群部署的,分为Driver/Master/Worker,Master负责资源调度,Worker是不同的运算节点,由Master统一调度. 而Driver是我们提交Spark程序的节点,并且所有的reduce类型的操作都会汇总到Driver节点进行整合.节点之间会将map/reduce等操作函数传递一个独立副本到每一个节点,这些变量也会复制到每台机器上,而节点之间的运算是相