文章

以 Hadoop 生态系统为核心构建了整套大数据平台,为整个苏宁集团所有业务团队提供大数据的存储以及计算能力。

在苏宁中台供应链计算等应用场景下,我们基于 Apache Spark 来构建整套零售核心数据计算与分析平台,解决海量数据离线和在线计算时效和性能问题。

苏宁大数据平台和整体框架结构

苏宁大数据平台的整体架构以开源的基础平台为主,辅助以自研的组件。

苏宁大数据平台架构

苏宁大数据平台架构

阅读更多

说别人家的故障,总有点隔鞋搔痒,看人家笑话的感觉。

先说一个小故事吧,某一年三四月份,我和几个同事一起去拜见某大客户的IT总经理木总,聊大型系统的运维经验,聊我们的管控手段,木总很不屑的说,这些我们都做了好几年了……紧接着2个月发生了“由于某些原因将某数据库重启后,系统性能运行非常缓慢,后面发现原因是重启后SGA变为几百兆了,而正常是几十GB”,“某数据库出问题,需要恢复的时候,发现Veritas软件恢复的时候不支持,需要打一个补丁”,“所有的用户权限都是DBA,某天突然应用用户drop了个生产表,需要立即恢复”…..木总原以为这些数据库有备份、有流程、有规范的在运维了,事实上是情况已经不像他以为的那么好。比较幸运的是,我们的团队开始支持他们的系统。所以我们一直说,运维是个持续的过程,要靠专业的运维团队来做,而且流程规范要与时俱进更新和完善。

今天发生故障的是一家代码托管的创业公司gitlab.com,说实话我第一反应以为是github,虽然名字很像,其实不是。

简单介绍一下:

1. 工作了一天,疲惫的工程师YP同学在23点的时候,想把一个自己以为是空目录的文件夹rm –rf删除了。大概一两秒之后,YP同学突然意识到,他大爷的,是不是搞错机器了!没错,他确实搞错机器了!

2. 23点27分的时候,YP同学终止了这个操作,然后发现,310GB的数据,只剩4.5GB了,99%的数据已经被误删除。

3. 非常不幸的是,之前号称的所有备份都失效了:常规备份(说好像有,但是备份在哪不知道呢)、LVM备份(是24小时一次的。说YP在故障发生的6小时前做了一次,但从恢复进度来看,应该也是失败的)、Azure上的磁盘快照(以为做了,其实没做DB的)、S3上的备份好像也没成功、自动同步程序不稳定,也失效了。

阅读更多

最近的一个项目是风控过程数据实时统计分析和聚合的一个 OLAP 分析监控平台,日流量峰值在 10 到 12 亿上下,每年数据约 4000 亿条,占用空间大概 200T。

面对这样一个数据量级的需求,我们的数据如何存储和实现实时查询将是一个严峻的挑战。

经过对 Elasticsearch 多方调研和超过几百亿条数据的插入和聚合查询的验证之后,我们总结出以下几种能够有效提升性能和解决这一问题的方案:

集群规划
存储策略
索引拆分
压缩
冷热分区等

百亿级数据实时统计分析和聚合的优化实战

阅读更多