上午主题： 大数据 序 孙永革 中国互联网协会副秘书长 互联网态势 移动互联网 电子商务 云计算的商业化 IT产业的发展 80年代计算机 90年代互联网 现在的大数据 关于大会 关于互联网协会 新开”技术大讲堂“ 大数据革命 周涛 电子科技大学 互联网科学中心主任 大数据是否真正不同的新概念？ 信息革命是第三次工业革命？（计算、数据、证析、个性化） 西数东输（西部建立数据中心，东部使用）.... 大数据革命： 原始：数据+理论->解释->预测->控制 现在：数据+理论->解释+预测+控制 作用：定性->半定量->定量（从更大的数据尺度上分析问题，带来更精确的统计结果） 发展： 1.0：自身业务产生大量数据，通过分析，优化业务，指导决策（例如广告精准投放） 2.0：搜集大量异质数据，建立复杂分析预测模型，数据即决策（例如google通过统计环境，话题，预测流感） 3.0：对数据质量、价值、权益、安全等充分认识，出台政策保护，出现数据运营商，学术团体，企业通过数据得到对社会，经济、科学上得到更多的理论/实践 MPP NEWSQL 数据库集群支持企业超大规模数据仓储案例介绍 武新 南大通用高级副总裁兼CTO 大数据引发的行业变革 One Size Fits All的时代 -> 架构多元化（old sql 事务/new sql分析/no sql互联网) NewSQL 列存储、关系型、MPP 数据价值密度高 NoSQL KV MapReduce MPP OldSQL 行存储 关系型 SMP 内存化、一体机化 数据实时性高 Hardware PC服务器+传统小型机 行业与互联网大数据： 行业与互联网数据规模基本相同 行业用户目前带来的商业需求更大 GBase 8a MPP Cluster 定位：分析类应用 全数据处理（行业用） 架构： 传统shared disk：SAN/NAS shared nothing： 多节点，非共享。以读为主，横向扩展好 有master： 管理简单，有瓶颈和宕机风险 无master： 相反 和Hadoop不同，尽量提升每个节点的处理速度，以达到更少节点更大数据处理的能力 高可用： 双副本、动态扩展 电信经分类DW案例介绍 业务场景： 0.5G 用户 200TB数据 最大表500G数据 平台： 80服务器（40*2）+3加载服务器+1监控，10G交换机 用例: 80%为性能 测试： 加载性能： 4.7TB/H，加载时数据压缩。 1：1.7的压缩比 功能： SQL92标准 OLAP 处理性能： 并发，回滚 全表扫描： 224G： 2.5Ks 20G: 多表关联： 3表 560G+224G+0.5G 返回3结果，执行3.8h 列存 多任务： DML： 列存储数据库比传统行存储差一些 混合业务： 压力： 单节点500MB/s吞吐,网络IO 600MB/s，磁盘IO瓶颈 扩展性: 64到80节点： 性能提升20% 扩容60h 高可用： 执行背景SQL时，2台断点，回复所需2小时。 测试总结: 100节点，1PB。处理能力大于SMP架构SQL服务器，(列存!!) 必须架构上的高可用 必须高扩展性，易用性，可维护性 大型行业IT支撑架构现状： 40PB数据，5K小型机 优点： 业务固定，稳定性，成熟 缺点： 节点价位高，100PB以上困难 新型数据库： 去小型机：减少成本 企业简介&QA 大数据分析在移动互联网的应用 陈继东 人人游戏首席数据科学家 大数据分析概述 发展趋势 数据不再删除，数据的分析越来越重要，高可靠性，越来越大，非结构化 整体框架 分析工具和服务 展示，分享，分析 软件平台 metadata， 基础架构 关键技术和工具 数据收集： 非结构化 chukwa flume facebook scribe 结构化 sqoop，hiho 数据存储 分布式文件系统： hadoop hdfs 并行 nosql 内存 数据处理 mapreduce 并行 流式处理 主内存 数据存取 SQL、DataFlow、JAQL 数据序列化 元数据管理和工作流 监控与管理 重点技术： 大规模并行，New/Nosql 流式 机器学习 MapReduce VS. 并行数据库 Map的主要研究/处理的问题 性能 实时处理 标准接口 外围工具 数据库处理的问题 扩展性 容错性 灵活性 成本 NoSQL VS. SQL NoSQL 高扩展性和弹性，灵活数据模型，容错，可用性。海量数据定制化， Spark vs. mapreduce 快速流处理 高性能的主内存抽象，通用的执行图，快速迭代类查询 并行数据挖掘和机器学习 海量装载和处理 数据质量和挖掘效率 数据特征 并行机器学习的计算模型 统计查询模型 图模型：google gregel google graphlearn 定制模型处理迭代 高可扩展，可并行和分布式算法 移动大数据分析 应用需求 移动大数据载体： 智能设备普及 高宽带： 3G WIFI 用途: 基于大量数据统计得到用户最佳结果 传统互联网区别： 一直在线，无处不在，碎片化，社交化（个性化？） 数据特点： 核心节点是人而不是设备 数据量更大，维度更高 更多的个性化和上下文属性 不受限于浏览器和cookie，数据更稳定和准确？？ 用户行为碎片化，实时性强 挑战 数据采集质量 时空行为模式的挖掘和利用 跨平台快设备多维数据分析 实时处理和深入分析 案例分析 移动广告分析 目标： 匹配用户和广告，精准投放 精确性，互动性，位置性，长尾性 内容： 点击率预估 用户分类和行为分析 应用和广告分类 反作弊 数据规模： Admob 300K应用，.35G设备，1M的广告主 4G广告请求 架构： 行为分析： 方法： 朴素的贝叶斯，逻辑回归 特征： 数据特征提取和预处理 属性分类： 问题： 相似度计算的效率 半监督学习的图传播算法 GraphChi 移动应用分析 目标： 理解用户如何与移动应用进行交互 服务： 用户获取、活跃、留存、转换分析 用户分群、行为分析 断代分析、转换漏斗 （用户升级，转换衰减程度） 跨应用和 跨平台分析 数据规模：Flurry 平台： 实时计算：流处理技术 并行处理和离线分析：Hadoop 高性能大数据存储：Nosql 问题： 访问量逐渐增加： JVM优化 MapReduce UV计算对内存占用越来越大 做近似处理 Loglog 实时性要求更高 总结: Big data in action 殷皓 微软***CTO 大数据简介: 思考： 实施参考: 实施场景： 下午 NOSQL 腾讯HOLD平台-支付 雷海林 简介 业务场景： 会员，游戏积分、微博积分，资格限制。高价值，任务简单（适合NOSQL） 高一致性（牺牲了部分实时性） 数据量G级，容量TB级 加入了实时的热扩容 问题： 并发不足，耗时高，容灾方案（太多）不好选择，数据层扩容不变，运维成本大 利用HOLD平台代替传统DB+Cache 结构特点 1、高价值： 要求高一致性 2、高可用性：牺牲部分用户的业务，来确保数据的一致性，镜像，binlog 3、数据层扩容 4、优秀的读写性能 5、数据间关联不大 高一致性的分布式cache 总体架构 主机、备机、管控CC == 一个SET SETS分布在不同的IDC 多个SETS + CloudKeeper： 配置，控制主备切换，扩容控制 + 多个CloudAgent：计算路由，选择set SET请求来，主机先向CC发送数据，再做业务，再返回给备机；CC过段时间查备机是已写入。否的话进入黑名单，主备切换时，这些请求的用户不能生效。 个人问题：CC宕机？ 备机CC，主机和主CC无法同步时，发往备CC。。。(??) 容灾检测; CK ,主，备，两两通信，一旦发现有一个模块无法和其他两个模块通，则认为出错 主备，双版本号： 便于跟踪主备数据流水 提高数据一致性 跨域容灾 不能实时切换（人工干预） 数据请求不能像单SET一样进行CC保护 扩展命令：解决高并发串行化问题（多线程SET问题） 自动扩容： CK把新SET加入路由表，新请求到新set，新set会向老set获取原始数据。 CK要检测老SET主备是否完全一致，一致后，向新SET导入老SET镜像。 性能优化 !!减少锁竞争：业务细分，多个队列 减少系统调用 耗时函数重写 总结： 问题： LevelDB： SSD更有优势 Redis： 本身没什么问题，但与其改造，不容重新写一个适应现有业务的 NOSQL一致性实践-CAP认知 童家旺 阿里 CAP演变 97年 Fox&Brewer提出Base概念《Cluster-Based Scalable Network Service》 !!99年 提出CAP原理《Harvest Yield and Scalable Tolerant Systems》 2000年 PODC keynotes，正式提出CAP《Towards Robust Distributed Systems》 02年 Seth Gilbert& Nancy Lynch 证明CAP CAP流行的重要事件 OSDI 2006 Google发布Bigtable论文 SOSP 2007 Amazon发布Dynamo论坛 INFOQ 2007 08 Amazon Werner Gogeis Available & Consistency 10 Eventually & Consistent 2008 1 Ebay 架构师Dan Prichen介绍base CAP原理 !!共享数据系统CAP仅能同是满足2项 C A是一个量的问题 P 广域网下，分区不可不免 CAP， Pick Two 面对P，真的必须牺牲一致性吗？ !!不同业务由不同的选择 CAP经济上的权衡 时间和金钱的权衡 含金量越大的系统对C要求越高 CAP没有声明不要C，或者放弃事务/SQL CAP与ACID 当NP：支持全ACID 当P： A：不同的分区保持A C：临时违背 I：。。 D：永远不应该（？？） 分区只是另一段Code Path CAP应用 User Proile: 牺牲一定的读一致性 Message Processing 一个节点挂掉，延迟部分持久化消息处理。牺牲少量A Shopping Cart 降低一定的C，交由用户来处理 ATM 先牺牲A，降低C（可选择） 航空订票： 超卖：为了一定的A牺牲一些C，额外补偿机制 总结： CAP实际效果： 平衡不同业务的一致性和可用性 NP： 可 不牺牲CA，获取完整的ACID 可 牺牲一定的C，获得更好的性能和扩展性 P： 选择A： 需要前中后处理策略，做补偿机制 REF： CAP reading list 问题： 1、CAP，P是一个不受人力控制的东西。 2、机票超卖的问题：为不同的票做不同时间的check（做一次回归） 3、一旦外部约束发生变化，我们的设计要做的变更，以便获取更好的设计目标 MongoDB Qihoo360 王超 背景 为什么选择MongoDB？ 高可用性，平滑性，比较自由的架构 历程 10M级别 数据在内存中 问题： 10K/d 超时 问题是磁盘同步时的的IO，以及全局锁。减少同步间隔时间可缓解 问题伴随着move chuck，调整balancer启动时间，避免高峰。 Mongo 连接池，VersionManager Bug 100M级别 问题: 超时，平均latency上涨，锁。白天的数据已无法平衡 原因，数据超出内存 方法： 1、节省业务场景的内存 2、预热内存 何时： 重启、增加secondary，增加shared 工具： vmtouch （dd cat 不好使？？？） 3、balancer：movechunck限速，平衡时间再次开放全天 注意： doucument长度对QPS影响很大（1K，3K） GB： SSD：mongo db shared可以放在不同的ssd上 个人PC自测数据：SSD读写延迟（寻道时间）70us，普通硬盘5-12ms，内存50ns，SSD加入可大幅度增加硬盘的随机性能 10G： 100Server 64GB Mem 2T SSD NUMA架构： 问题：内存无规律换出，某核100%，持续时间几秒（内存抖动？） 原因：单节点超出内存导致Linux换页 长链接事故： 线程达到系统上限导crash Y： php driver <1.20 连接池泄露 在超时时候 Client与每个mongo db 都建立链接， 导致mongod链接X倍 mongos mongod 服务器复用 F： 修bug。调整系统参数，该mongo 取消其链接上限，client只链接一个mongo 跨IDC： 单集群 多个IDC组成一个集群 需要跨IDC写入，区分主次机房（mongod 分主次） 适合读多写少（就近原则） 多集群 集群独立，调整灵活 断了不影响写入，只影响同步和实时性 如何在线迁移： oplog 展望 WEB化集群管理 容量规划，提前 数据压缩 SSD成本高，有压缩的必要 多线程同步、迁移 期待： collection lock， document lock 主流分布式存储NoSQL优缺点 腾讯 对比 OldSQL问题： 单机时代产物，迁移不够方便，无法满足不同存储需求 NoSQL： 不够成熟（bug，支持工具，缺少行业验证） 方案分析 redis 特点: k-structure（支持多样数据结构） 支持数据可靠存储和落地 单进程/线程高性能服务器 crash safe & recovery slow 单机qps可达100K 适合小数据高速读写 缺陷： 运行曲线不够稳定 不同命令延迟差别极大 内存管理开销大 缓存io导致系统oom redis-counter： 定长内存块 开放地址HASH 内存管理开销低 leveldb： 实现： memtable是一个跳表 对应一个logfile（内存） 写满一个memtable后，dump入一个LV0的sst（文件） LV满了之后会merge到下一层 读的话，就是按层次从memtable到LV，可能会导致某些数据多次IO bitcask： 实现： 内存hash表 表中有一个列是file_id对应了一个文件。 文件比较大时，会merge 文件被修改时，需要合并 最多一次IO，但是结构太简单缓存性能不够好 腾讯的最终实现： 实现： 内存有个memtable，每写完一块就dump到磁盘。（lvdb） keyindex（key索引）& blockindex（磁盘块索引） 块修改后，如果可用数据很少的话，就合并块。 最多一次IO，而且保留了leveldb良好的缓存性（leveldb+bitcask） LSM NoSQL特点: SSD友好 写性能出色 handlersocket： 特点： Nosql访问mysql 解决sql解析时间，查询优化 迁移方便 nosql->mysql QPS 8W 缺陷： DDL使用有严重问题 写性能比传统DB更慢 支持从Row Based复制 性能优势建立在没有IO瓶颈的基础上 经典架构 manager | * Client* -proxy* *worker 大规模分布式存储系统设计 保持系统简洁 各个环节的过载保护 存储层资源迁移支持 重要环节可控 设备故障时有发生 快速失败检测 数据多份存储 建立冷备份系统(+流水）