淘宝量子统计架构设计中的核心点

量子统计架构设计淘宝-张茂森

Agenda 量子统计面临的挑战 量子统计架构设计 量子统计的技术研究方向

挑战 成本 高并发数据分析网站的C10K问题 关系型数据库和实时数据计算结果的异构融合 复杂的数据查询接口逻辑和开发效率、查询效率、和正确性 分布式计算和任务管理

一组数据 实时计算处理数据3T/日离线分布式计算处理数据超过20T/日数据接口请求7500w/日网站资源请求9000w/日实时结果请求1700w/日服务超过百万的淘宝卖家

小结 电子商务类的数据处理、计算、分析目前没有“银弹” 整合、整合再整合

量子统计架构示意图网站展现

数据中间层分布式计算实时计算

数据流向基于Ajax的JS前端基于Nginx的数据中间层展现数据库集群实时计算和查询引擎

基于Hadoop的分布式数据仓库

量子Javascript前端 把计算推向客户Browser 利用Ajax技术提升用户体验 模块化的产品形式–展现组件化和控制逻辑分离随着Html5的到来，IE6的老去 Javascript将大放异彩

量子数据中间层 信条：非阻塞、持续优化 核心：Nginx和量子贡献的扩展模块––––非阻塞缓存非阻塞数据库访问实时引擎访问接口单元测试

异构数据的融合– LZSQL 将异构查询透明 将数据库结果和实时引擎结果进行融合 进行针对业务级的SQL优化

Lua作为粘合剂–解决非阻塞程序编写困难–提升数据二次处理能力

相对稳定的专职开发人员 关系型数据库优化技能的持续培养

实时流计算框架SuperMario 纠结– C++、JAVA、Erlang、 Go

选择– Erlang+ZooKeeper

保持简单，先解决：–低延迟、高可靠性–异构数据任务的快速串联

下一步：–封装更复杂的流模型–热迁移

实时计算、查询引擎 成本是梦魇– MySQL方案将是现在所需服务器的5-7倍– Postgresql也差不多–很多NoSQL产品的性能只是传说

选择– B tree+ Sorted list+ Hash的计算引擎，尽可能的优化内存消耗–利用Epoll实现简单查询模型

下一步方向–使用混合存储方案：Memory+Disk,进一步降低成本并提升可靠性

离线分布式计算和任务调度管理 Hadoop集群–原生Map-Reduce代码– Hive代码– Hadoop streaming代码

任务调度–构建任务依赖关系、加入优先级控制，多种时间粒度的任务调度–统一进行任务的调度–高可靠性，监控、报警、自动恢复/重启是关键

cronjob

雅虎 Octopus

淘宝天网

数据生产链的困境–任务依赖要和任务优先级、稳定性要求统筹考虑–数据正确性怎么校验–构造基于经验的检验

规则–数据结果间的四则运算关系–日任务数800个

数据分析网站的运维 别人负载高的时候，我们也高：因为实时计算 别人负载低的时候，我们也高：因为离线计算 运维的压力会是制约一个数据团队发展的重要因素–一定要重视运维，用开放的心态将专职运维人员加入进来–数据计算代码要可重入，去掉状态依赖–上下游依赖要理顺，并建立应急处理手册–重视开发人员中偏运维职能人员培养和提升

量子的技术研究方向 多维数据分析–将昂贵的数据分析技术分享给更多的用户–实时滑动窗口的多维分析–海量数据的多维分析

数据可视化–教育和培养用户解读数据–更直观的展现数据的价值

NoSQL产品在实时计算中的应用–解决K-V服务扩展性的难题–解决数据实时转换的难题–量子和OceanBase的合作

Thanks

Q&A