狠狠撸

大型电商系统数据服务的要点和难点
www.VIP.com
VIP Data Infrastructure
zhuchao@gmail.com

业务逻辑电商系统的平台系统的部分
真正赚钱的部分,
所有其他的工作都是为了这个目的
业务线产物开发测试
开发框架：封装公用开发逻辑，数据库连接，日志，服务治理，
公司架构：系统，应用架构，数据架构。。。合理分工
CI/CD: 持续集成和持续部署和弹性扩容
Operation: 支持业务运营
Infrastructure：网络，计算和存储
?app server, 业务逻辑
?无状态/stateless
?不需要failover
?Scaling相对容易
计算
?保存数据，有状态
?需要failover/高可用难
?Scaling 难
?自动化难
储存
电商技术

数据：存储和访问
在线数据平台
? KV
? Memcache/Redis
? RDBMS
? MySQL/Oracle/SQL
Server
实时计算平台
? Data Transfer: Flume/VDP
? Storage: RMQ, Kafka
? Processing: storm/spark
离线数据平台
? Hadoop
? TD/Greenplum
? Presto/Hawk/Tez/Impala
NoSQL
? Hbase
? Mongodb
? Redis, Twemproxy, Redis cluster
DFS
HDFS/MFS/GFS/Swift/Ceph
FileSystem
XFS/EXT4/EXT3
>>
<<
>>
<<

在线数据平台
? 数据架构
? 系统架构
? 系统运营
实时数据平台
? 系统架构
? 开发平台
Agenda

在线系统：数据架构难点
技术实现的考量
? 数据服务：
? 不仅仅是基础架构，也是业务和数据架构
? 需要熟悉各类常见解决方案的优缺点
? 需要了解互联网常见的数据-业务解决方案
? 用合适的技术，借鉴行业最佳实践，来解决合适的业务需
求
? 设计和实现关键：
? 数据，无非是读，写，存储；
? 所以如何读，如何写，数据量，决定了如何选型和设计
? 读和写：
? 数据量(GB? TB? PB?)
? 读的模式(KV? Batch?)
? 读的量(x QPS? xxk QPS? xMQPS?)
? 写的模式(single? Batch)
? 写的量 (x TPS? xxk TPS? xMTPS?)
? 读写比率(99:1?1:99)
? 可用性要求(99.99% up? 99% up?)
? 响应时间要求(1ms? 1s? xx min?)
? 成本约束
? 开发和运维人员的经验
业务的各个阶段
? Project Design
? choose the right solution
? design the right schema
? Write the right code
? Deploy at right scale
? Project Live
? Schema Changes
? Data fix
? Data to dev environment refresh
? Debug requirement
? Data retention
? Large Scale Operation
? Thousands of instances
? Automate everything

数据架构：方案选型
Guideline
? 表格
? Wizard
最佳实践
? Vip的典型 mc/redis/hbase/mongodb的使用场景和方法
? MC：商品描述，HTML模板，用户登录Session，pure KV Cache
? Redis: 高速KV读写，丰富数据结构，数据固化/复制/Failover支持
抢红包，收藏，UserProfile，大数据实时计算主要存储
? Hbase：海量数据的KV访问，持久化存储, un-predictable storage
如风控，用户行为分析，销售统计等。Non-critical
? Mongo：解决开发快速活动应用开发与设计及其上线的要求。Non-critical
? 核心交易： MySQL

数据架构设计:Cache
? Design & Development：
? 尽量避免同一份数据多个domain各自Cache： stale/inconsistent data
? 同一份数据的不同修改入口: stale/Inconsistent data
? 大对象的Cache的频繁调用: 带宽瓶颈，监控定位
? Hot Key的正确Cache/并发更新和回源:
? Cache Server down的处理:
? by design, cache is just cache, just like cache miss , function should be ok
? 中间件的thread/load 瓶颈和连接池超时处理
? Control single instance load/traffic/qps
? Backend Database capacity/Second Tier Cache
? Deployment & Operation：
? 跨IDC的Cache调用和更新: 带宽和延迟
? Cache instance之间的带宽竞争：快速定位和隔离
? 万兆网络 is the king

数据架构设计:RDBMS
Requirement：
? 交易流程：用户，商品，购物车，库存，支付，订单，物流，仓储，报表
Solution：
? MySQL/Oracle/SQL Server
? Internet transactional storage == MySQL
基本经验：
? Always 5.5+
? Always Best HW(Flash,CPU,Memory)
? Basic best practice (HW/OS/MySQL)
Pain point：
? R/W split 指导思想
? Sharding带来的开发运维复杂度
? Online DDL
? 报表问题/Big Query
? No data lost Failover

数据schema 的设计和SQL的编写
? Domain Ownership：
? 连接池的管理
? 健康检查的方法
? 连接池：最大最小连接池
? 失败处理：DB重启/Failover
? Schema设计
? 按照读写请求Profile来设计
? 一些硬性要求：主键，creation_date, last_modified
? 常见最佳实践：passwd, ip, time,
? Schema Review落地到系统
? SQL Review
? 基于生产系统真实数据和配置的SQL Review
? 理论不这么玩：联合查询，子查询，触发器，自定义函数
? Just data storage
? SQL review落地到系统review + 人工建议
? Schema 设计和SQL Review其实是一个整体

summary
在线basic 在线derived 离线derived
数据量几十~几百GB 几十GB~几TB 几-几十TB
访问模式单条，by user_id，order_id,
单dataset多维度查询
单条, by
user_id/mid/cookie_id/ip/…
By user_attribute
几十-几百万
访问量 xK qps xk~xxk QPS 每小时N次
可用性 99.99% 99.95% 99.9%
准确性 100% 99.99% 99.99%
响应时间要求 1-10ms 1~30ms <1min
数据计算-读模式 Java/Php online app Storm, java
数据使用-读用户网站移动交易流程个性化(推荐广告搜索展现)，
风控，金融
Pms，
EDM, Push, Campaign
数据计算-写模式 Java/PHP online app Storm, spark, hive Hive
数据存储 MySQL/Redis Redis/Hbase Hadoop/GP/Solr

系统架构设计
? 性能: (app) performance by (app/data) design
? 合理的解决方案(KV, RDBMS)
? 合理的数据结构(Schema)
? 合理的访问路径(SQL)
? 标准化/合理的系统配置和监控
? 扩展性
? Scale up
? Scale out
? 可用性（思路：冗余，仲裁，Failover）
读：LVS-read-cluster
写：MHA/Sentinel
? 一致性
? Leave it to application

性能&容量&扩展性：前提
? 什么叫做：
? 性能
? 容量
? 扩展性
? Measure and Log everything:
? HW
? OS
? Application
? 测试和找到瓶颈
? 发挥硬件的性能到极致
? 了解工作原理，了解系统可能瓶颈(竞争点)
? 压力测试，找到真正的瓶颈
? 生产系统的压力测试(读流量)
? 不了解可能瓶颈，监控和告警无从谈起
? Alert and Plan
? alerting
? capacity planning
? performance ~~ capacity

扩展性
? 无状态：扩展很容易
? 把有状态的内容丢入数据存储解决方案(db/cache)
? 启用负载均衡
? 添加更多server到集群
? 有状态的服务扩容：
? 对于只读流量： just Cache/add load balancer ,and add real server
? 对于交易系统的扩容，首先scale up:
? 更好的机器：Faster CPU(more CPU)/More Memory(Faster Memory)/Faster IO(Flash, SSD)
? 更好的软件：更新版本更好解决竞争，充分利用机器资源
? 优化：逻辑优化10x 与 SQL/Schema优化 10x 与系统优化(OS/HW)
? 然后scale out
? 拆分
? shard

扩展性-Scale Out-拆分
? 永远是先拆分，再shard
? 希望大家知道拆分(Split)和分区(shard)的区别
? wait:
? did you know how much a mordern system can handle?
? did you know your system tps/qps?
? How optimize is your code?
? Always measure first
? 拆分
? 拆什么：
? 从最大资源消耗，相对最独立的模块开始
? 你知道你的系统，最大资源消耗，是什么模块么？各自占了多少百分比的资源？
? 怎么拆：双写，还是API化先？
? 怎么验证：
? vip之路：购物车，库存，订单，用户，商品，。。。

扩展性-scale out-shard
? Web Scale：
? 经过单机的极致优化，缓存，读写分离，拆分，数据归档，还是搞不定的高并发：
? Shard 是最后一根稻草：
? 99%的互联网公司不需要
? Shard带来的价值：
? 极大提升系统的数据处理能力
? 极大降低单点失败的影响
? 分片后的数据消减 DML DDL 对整个业务的影响
? 备份恢复变得更高效
?
shard带来的挑战：
1. 增加代码复杂度，任何读写都是通过route规则后确定数据源
2. 选择合理的sharding key，均衡数据与访问量
3. 需要遍历所有sharding 的查询业务难度增加
4. 彻底无法做table join
5. 无法保证分片之间的事务一致性
6. 增加资源信息量，加大DB 变更复杂度
7. 在线报表基本不可能
8. 更加需要自动化的支持：DDL，DML，数据库个数极大的增加

Vip的挑战：20x
? Redis:
? Measure
? 从单机多个小业务，完善标准部署
? 拆分不同业务到不同instance
? 对一个业务进行shard：2种方法
? Redis Cluster(Piloting)：在线扩容、升
级和迁移，更低成本和延迟
? 几千个instance的管理
? MySQL
? 基本HW/OS/MySQL Tuning
? 优化SQL和业务逻辑
? 读写分离，增加Cache
? 拆分：按照模块拆分系统
? Shard：一个系统再次shard
? 测试，测试，测试（压力，失败）
? 关闭non-critical jobs/Batch Job
? 20x 的挑战：
? 不同应用，在大促流量下，行为不同
? So, Measure it~ 3x,5x,20x, ??x
? 系数1：??X = Min-peak-promo/min-peak-avgday
? 系数2：上次大促收藏/本次大促收藏
Cache (MC):
? 10g Network
? Measure(Dashboard/Titan)
? 隔离: (Deployment/TC)

高可用：系统
? Things fails, so we design for failure
? Stateless HA is easy
? load balance
? Healthcheck
? Stateful HA is difficult
? 传统: 基于共享磁盘的Failover (rac/vcs)
? MySQL:
? Read cluster
? Write: MHA
? Application failover logic
? Pain Point
? 缺少统一配置中心的接入或者DNS API支持
? 跨机房无法failover
? 保证无数据丢失的Failover

高可用：应用
? 真正的高可用，是应用/服务的高可用
? 一切设计，都是为了确保对外提供的应用的高可用
? 应用的failover，可以更大程度上保证整个系统的高可用
? 写log (比如用户注册)到文件或者数据库，然后batch job处理
? 写failover host (比如用户登陆写log，写到其他数据库)
? 逻辑的failover (请求A不得到结果, 改为请求B)
? Skip 非关键路径（风控超时跳过）

系统运营
? 非常完善的监控和报警
? 立身之本，系统监控和应用监控
? 展现和告警：Dashboard
? 告警之间的联动~
? 全自动化的部署
? 全自动化申请和部署流程
? 开发测试生产环境的自动化DDL流程
? 大规模系统的自动化运营
? 统一备份系统
? 统一归档系统
? 统一部署，监控
? 统一高可用解决方案

自助平台(DBaaS)：
? Enable and empower the developers：几千个开发的时候，如何才能支持好
? 把人的经验建设进入系统，不仅仅是wiki
? 自助申请(question list?recommendation) 和自助部署
? 自助Schema Review和自助DDL 发布(开发，测试，生产）
? 自助SQL Review（生产系统从库~）
? 自助查询(MySQL, Redis, MC, Mongo, Hbase)
? 自助数据导出
? 自助测试环境数据refresh/数据脱敏
? 自助数据归档系统
? 生产环境系统运行状况(load,容量,慢查询)+app 日志

监控-顿补蝉丑产辞补谤诲

平台服务数据服务
数坊
分析师平台
对外服务
VRC
开发者平台
画像计算 VRE
Sqoop/VDP/Flume/Kafka
Job调度/Yarn调度
运
维
监
控
测
试
数据产物
HIVE Presto SPARK R
HbaseDruidHDFS Redis Cluster
VRE实时算法预测 MLLib实时训练分析统计任务
GP
Storm
自助
报表平台
应用
产物服务
接入
计算
存储
调度
数据平台整体规划
自助
取数平台

元数据管理日志解析 Metric采集自定义函数
storm集群
可视化编程Artemisvrc-engine(esper)
任务管理权限管控监控日志portal
计算中心
基础组件
流式平台
实时计算整体架构规划
应用场景
实时
销售
网站
监测
安全风控实时
推荐
事件
营销
实时
etl

VRC Portal
集成日
志系统
运维权
限管控

VRC Engine
logparser
kafka
vdp+vms
mq
shuffle
rule
Scheduler
esper lib
esper lib
esper lib
db/nosql
vms

VRC-一个all in one的实时计算平台
? 消息接入
能以配置方式接入数据
? 应用开发
降低storm开发困难
? 支持类sql的数据开发方式
? 支持可视化开发topology
? 运维管控
? Backup owner角色
? 发布、停止、重启job的权限管控
? 告警
? 延迟告警
? 数据质量告警
? 统一元数据
? Kafka topic/VMS queue的数据结构维护
? 统一日志解析
? 任务管理
? 以项目的方式管理一个计算topology
? strom操作集成
? 任务更新
? 配置管理
? 参数统一配置
? 附加参数文件
? 统一检查项
? 发布管理
? 集成git远程打包
? 本地上传
? 集成DQP
? h+1/t+1数据质量检验
? 实时数据质量

狠狠撸

大型电商的数据服务的要点和难点

Recommended

More Related Content

What's hot (20)

Viewers also liked (11)

Similar to 大型电商的数据服务的要点和难点 (20)

大型电商的数据服务的要点和难点

Editor's Notes