• 1. NoSQL——大数据时代的机遇和挑战2015/10/25
  • 2. Who Am I?许建辉 广州巨杉研发总监,主导大数据的产品架构设计和总体研发 前华为员工,在华为拥有4年电信级软件设计开发经验和5年大数据产品设计开发经验;2012年加入广州巨杉核心团队 xujianhui@sequoiadb.com 2
  • 3. Agenda大数据面临的挑战1NoSQL技术介绍3NoSQL的机遇和发展2大数据的典型案例43大数据未来的畅想5
  • 4. 大数据面临的挑战Big Data, Big World4
  • 5. 业务的革新传统业务精准营销更久的历史数据检索统一的征信平台实时风险预警分析预测个性化服务互联网微博推送网盘/云存储服务照片/视频/音频服务社交动态推送电商服务社交动态推送数据成为业务发展的核心银行提供所有历史交易信息查询 航空根据机票信息分析用户属性,并提供个性化的优化推荐QQ空间日均上传2亿张照片,每分钟13.9万 双11支付宝交易达1.058亿笔,每分钟约7.3万;淘宝天猫吸引2.13亿独立用户访问 新浪微博日均发博1.3亿条
  • 6. 用数据对话数据6近5年数据增涨5倍以上 结构化数据增涨缓慢,非结构化数据呈指数增涨态势全球数据产生十年增涨趋势全球数据存储增涨趋势数据增涨背后是业务的不断革新
  • 7. “大数据”的诞生大量化、多样化、时效性、价值密度低是大数据显著特征VolumeVarietyVelocityValue大量化 非结构化数据增涨是结构化数据的10到50倍 Google每天处理24PB的数据 手机、传感器等终端产生大量数据 PB是临界值多样化 来源多:搜索引擎、社交网终、终端设备 格式多:结构化数据、半结构化数据以及文件、图片、视频、音频等无结构化数据时效性 数据实时检索和分析 数据动态关联 1S是临界值价值密度 大量不相关的信息,价值密度低 对未来趋势和模式的可预测分析 深度复杂分析(价值挖掘)
  • 8. “大数据”思维——先有数据,再找模型从数据中挖掘价值催生新型业务大数据方式 迭代的、不断探索的分析方式传统方式 结构化的、可重复的分析模型和方法IT人员 把数据关系结构化,抽取样本数据业务人员 决定问什么问题? 定量问题销售和订单报表、成本和利润率分析、客户满意度统计IT人员 提供全量数据和探索性分析工具 定性问题业务人员 探索关联关系、因果关系品牌敏感性、产品定价策略、舆论与社会情绪、营销推荐
  • 9. 企业的数据资产存储和分析非结构化数据成为企业业务突破的关键利用和分析非结构化数据 作为现有数据仓库的有效补充外部的“大数据资产”作用 更好了解客户 – 客户画像/征信 更好了解竞争对手 – 竞争分析 更好了解市场和行业趋势 - 舆情监控 更实时的风险监控 – 渠道风控内部的“大数据资产”作用 历史数据的充分再利用 提升客户体验和营销有效性 产品创新与定价,提高利润 电子渠道的欺诈防范商业智能和数据仓库20% 结构化网站 网银社会媒体银行应用中的文本目录系统, 文件,电子邮件,语音,视频大数据80% 非结构化数据还没有利用
  • 10. 传统关系型数据库的核心传统关系型数据库ACID基于单机或共享存储实现SQL接口标准的SQL接口 存储过程ACIDAtomicity(原子性):事务中的所有操作要么全部成功,要么全部失败 Consistency(一致性):事务的过程中整个数据加的状态是一致的,不会出现数据花掉的情况 Isolation(隔离性):相个事务不会相互影响,覆盖数据等 Durability(持久化):事务一旦完成,数据是被写到安全的、持久化的存储设备
  • 11. 传统关系型数据库面临的挑战大数据时代必须寻求新的技术Data Model 数据模型严格的数据模型阻碍业务的快速变化 无法存储半结构化和非结构化数据Huge Storage 海量数据存储新型构架存储量有限(只能达到TB级容量,十亿级记录),无法扩展PB/EB级容量,百亿/千亿级记录 SQL查询效率低,无法提供百万每秒的查询性能无法满足“无限水平扩展”的架构 无法部署PC服务器集群 无法提供云化服务敏捷开发繁重的数据设计和系统维护,无法简化开发流程 不能响应变化,不能满足迭代式开发
  • 12. 10NoSQL的机遇和发展
  • 13. NoSQL解决方案NoSQL为大数据而生使用PC服务器进行水平扩张Schemaless带来开发的敏捷 和可扩展性的提升分布式集群模式+数据冗余+读写分离等提供高可用、高可靠和高性能高可用高性能数据模型灵活低成本分布式架构+非结构化存储= 水平扩张海量数据
  • 14. 什么是NoSQL?NoSQL不是SQL的替代,而是补充它是Not Only SQL的缩写 基于CAP理论、BASE模型 一类非关系数据存储系统 通常不需要一个固定的表的模式 提供多样化、灵活方面的接口 一定程度上淡化了一个或多个ACID属性 能运行在廉价PC服务器上,支持无限扩展 追求简单和易用
  • 15. CAP理论、一致性策略和BASE模型CAP,BASE和最终一致性是NoSQL数据库存在的三大基石CPAConsistency Availability Partition tolerance只能同时满足两个?AP Cassandra CouchDB DynamoCA MySQL PostgreSQL SQL Server CP SequoiaDB MongoDB BigTable/Hbase RedisR:读节点个数 W:写节点个数 N:副本数 R+W>N:强一致策略 R+W<=N:弱一致策略 最终一致性:当很长一段时间没有更新,最终的所有更新通过系统传播,和所有节点将是一致的。Basically Available(基本可用):支持分区失败 Soft-state(软状态):状态可以有一段时间不同步 Eventually consistent:最终数据是一致的
  • 16. NoSQL的分类NoSQL产品和形态呈现多样化K/V Redis MemcacheDB 宽表 Cassandra Hbase 文档 SequoiaDB mongoDB CouchDB 图形 Neo4j FlockDB InfoGrid
  • 17. NoSQL——KVKV是高并发的简单存储系统键值对存储类型 Fast,Faster,Fastest 所有的数据只能使用主键检索,数值作为整体存放 数据结构与算法针对主键检索实现,基本不提供数据库引擎计算功能,大部分计算功能交由应用程序完成 适用于针对主键的快速随机读写操作 不适用于复杂计算,分析等领域 代表产品:Redis、MemcacheDB
  • 18. KV的数据模型和关键技术KV适应于高速缓存的场景只提供PUT/GET/DELETE简单操作 DHT,一跳访问,高性能 Hinted handoff,节点故障用临时节点替代,节点恢复从临时节点同步增量数据;动态维护可用性、可靠性 Gossip-based membership protocol,实现去中心化 NRW模型,向量版本提供一致性保障KV数据模型分布式HASH(DHT)
  • 19. NoSQL——宽表(列式存储)宽表是有效的分析型存储系统使用列簇(Column Family)机制将存在大量字段的记录分解成相对较小的子记录存放,高压缩比 来自于Google的BigTable 使用列簇的方式避免每次读取整条记录 使用日志文件记录的方式保证写入操作的高效 使用布隆过滤提升读取性能 适用于字段数量很多的分析类场景 不适用于大量随机访问,非主键随机查询等场景 代表产品:Hbase、Cassandra
  • 20. 列存数据模型和技术特点宽表是有效的分析型存储系统基于日志追加的写入(顺序写盘),通过合并文件加速数据有序化;不适合大量更新操作 主键数据有顺存储,索引和Bloom Filter加速数据在文件定位 支持万级以上字段,支持按列读取数据;高压缩率;随机访问性能差,不支持非主键索引
  • 21. NoSQL——Graph图型NoSQL只用于特定的场景非常规数据库 保存对象之间关系信息 适用于社交网络类型应用 不适用于其他场景 代表产品:Neo4j、FlockDB、InfoGrid
  • 22. Graph数据模型和技术特点图型NoSQL只用于特定的场景Node和Relationship 的 Property 是用一个 Key-Value 的双向列表来保存的 Node 的 Relationship 是用一个双向列表来保存的 通过关系,可以方便的找到关系的 from-to Node 数据模型存储示意模型
  • 23. NoSQL——文档型文档型NoSQL最接近关系型数据库使用JSON或兼容数据结构存储数据 支持灵活数据模型,不需预定义数据结构 使用行存储 功能最接近关系型数据库,可以拥有与之相当的ACID 适用于操作类应用场景,以及作为通用存储保存可检索的半结构化数据 不适用与超高性能数据访问需求以及事务类操作 代表产品:SequoiaDB、MongoDB、CouchDB
  • 24. 文档型数据模型和技术特点文档型NoSQL最接近关系型数据库{ “_id”: { “$oid”:”561f4452d2a4a22e10000000” }, “Name”:”John”, “Phone”:[ 13501258963, 13963659896, ] “Address”:{ “Home”:”xxxxxx”, “Office”:”xxxxxx”, } … }JSON/BSON/LOB数据模型LOBLOBLOB>、>=、<、<=、=、!=、mod and、or、not in、all、exist、isnull regular expression type、size…… 丰富的模式匹配丰富的模式更新+、-、*、/ bit operator push/pull/pop/addtoset set/unset/replace……丰富的模式选择include/default elemMatch/slice……丰富的功能CollectionSpace+Collection的逻辑结构 数据导入导出 数据Load 排序 聚集 联合 事务 存储过程 多索引、复合索引 SQL支持 JDBC驱动 权限管理 多副本、自动分区 ……
  • 25. Nosql技术介绍(基于Sequoiadb)10
  • 26. SequoiaDB的总体架构SequoiaDB采用高可靠、高可用、水平无限扩展的分布式架构成熟的分布式架构 独立的接入层,可以动态收缩扩张,可与应用一起部署,也可以数据一起部署 数据层以“数据组”为单位,组内为副本,组间为分区 协调节点在产生缓存冲突才更新编目 编目属于特殊数据组应用程序从数据节点主数据节点从数据节点App ServerApp ServerApp Server协调节点协调节点协调节点编目节点编目节点编目节点从数据节点主数据节点从数据节点从数据节点主数据节点从数据节点通过动态增加复制组 数量达到水平扩张的目的
  • 27. SequoiaDB数据模型支持结构化、半结构化和无结构化的数据模型数据按对象描述(JSON)存储,避免SCHEMA僵硬,灵活适应变化 弱关系型数据存储,同时提供SQL支持 数据类型一致,数据特征相似 - 高效压缩 分布并行查询,多索引 文件按照LOB处理 自动按照64/128KB的数据块进行切分,放在不同分区存储 使用DIO避免二进制数据占用文件系统缓存 并行处理分区2数据块…数据块数据块数据块分区1数据块…数据块数据块数据块分区3 数据块…数据块数据块数据块
  • 28. SequoiaDB的HA数据组自动选举策略保证业务高可用一个数据组支持1-7个数据节点 1主多备;主提供读写服务,备只提供读服务 基于权值的Paxos选举算法 基于Push-Pull日志的副本数据同步,有“主-备”和“备-备”两种模式协调节点数据节点(P)数据节点(S)数据节点(S){ hello: “world” }{ hello: “world” }{ hello: “world” }{ hello: “world” }选举数据节点(P)
  • 29. SequoiaDB的副本一致性数据组内的数据向主节点对齐主节点宕机后,LSN最新节点当选为主,每次升主,LSN版本号加1 升主后,向其它节点广播;其它节点向新的主节点对齐数据 如果开启事务,则新当选的主节点回滚所有未完成的事务A主备备AABBC我想当主节点我想当主节点我当前任务号是B我当前任务号是A主我当主了,大家向我看齐同步请求B
  • 30. SequoiaDB的副本不一致协商回滚数据组内的LSN协商和回滚保证异常下的数据一致性主节点恢复后,与新的主节点进行数据对齐 LSN不一致(版本或HASH校验)则协商至上一相同版本号的最后LSN,协商失败则发起全量同步 对于协商点LSN之后的日志全部进行回滚,回滚失败发起全量同步主备AABC主BAB备D同步请求DD我最新的版本号是1我最新的版本号是2 1版本号最后的步骤为B将B之后的操作回滚
  • 31. SequoiaDB热备节点(Hot-Spare)热备节点自动处理分布式下的节点故障,始终保持数据可靠数据组节点故障时,自动踢除该故障节点 从热备组中挑选1个节点加入该数据组 新加入的节点进行全量数据构建Hot-Spare NodeHot-Spare Node…Hot-Spare GroupData NodeData GroupData NodeData Node
  • 32. SequoiaDB灵活的一致性策略灵活的一致性和副本策略满足业务数据一致性和可靠性要求可基于Collection或操作设置一致性策略 可配置副本个数 支持强一致和最终一致 异步批量日志同步机制异步业务请求w=1Repl-logRepl-logRepl-logSecondaryPull批量Repl-logPush更新通知虚拟复制请求PrimarySecondaryRepl-GroupRepl-log相对窗口HOT-WindowCOLD-WindowLOST-Window同步业务请求w=3
  • 33. SequoiaDB副本并发同步机制并发日志同步在保证一致性前提下大大提升副本性能对于Insert/Update/Delete操作,备节点根据OID进行hash,并分发至Hash Bucket 由线程池驱动Hash Bucket,实现并发Reply 如果失败,则回滚至“最小完成LSN”
  • 34. SequoiaDB水平分区机制水平分区实现海量扩容和性能扩展将Collection根据ShardingKey切分到多个数据组 Hash分区 和 范围分区两种方式 实现Collection数据无限扩容协调节点数据节点协调节点数据节点协调节点数据节点协调节点协调节点协调节点数据节点数据节点数据节点数据节点数据节点数据节点数据节点数据节点数据节点数据表可按照字段哈希或者范围切割到多组服务器上编目节点编目节点编目节点
  • 35. SequoiaDB垂直分区机制垂直分区实现数据逻辑大集合Collection按照某字段划分多个分区 每个分区可以对应到子Collection 子Collection可以进行水平分区 子Collection可以在不同的CollectionSpace协调节点数据节点数据表可按照字段范围切割到多个逻辑分区中数据节点数据节点数据分区数据分区数据分区数据分区一月份数据二月份数据三月份数据四月份数据
  • 36. SequoiaDB的时间序数据模型垂直分区实现数据时间序模型实现数据按时间的冷热隔离 实现数据按时间的快速处理(删除、查询、统计) 可以适应数据逻辑的变化,而对外提供统一的操作 避免单一集合的膨胀和腐烂,提供更高的业务操作性能My01012014020120140101MyHistorydb.cs.createCL(“My0101”) db.cs.MyHistory.attachCL( “cs.My0101”, {UpBound:{date:”20140201”}, LowBound:{date:”20140101”}} )My02012014030120140201My03012014040120140301My04012014050120140401My05012014060120140501db.cs.createCL(“My0201”) db.cs.MyHistory.attachCL( “cs.My0201”, {UpBound:{date:”20140301”}, LowBound:{date:”20140201”}} )db.cs.createCL(“My0301”) db.cs.MyHistory.attachCL( “cs.My0301”, {UpBound:{date:”20140401”}, LowBound:{date:”20140301”}} )
  • 37. SequoiaDB读写分离机制读写分离机制帮助业务实现“数据湖”会话可以指定读取的副本策略(主、备、编号ID) 所有数据组相同副本ID共同构建一个数据库“实例” 数据组的副本可以进行物理隔离,对不同“实例”的访问同样可以物理隔离,互不干扰 SequoiaDB平台实时海量数据查询交互式批量分析中心节点 – 数据自动复制海量数据湖数据并行访问企业3的SequoiaDB集群数据并行访问企业2的SequoiaDB集群数据并行访问企业1的SequoiaDB集群海量数据挖掘
  • 38. SequoiaDB图形化管理垂直分区实现数据时间序模型一键式安装和扩容(容量规划,机器发机,部署向导……) 节点和性能自动化监控,图形展示 全新的数据展示模型、开放的REST接口
  • 39. SequoiaDB与Spark的整合SequoiaDB预集成Spark应用层面整合 充分利用Spark内存加速机制 支持用Scala开发存储过程 支持RDD、transformation等操作,减少I/O操作 提供数据块级和副本级并行能力 数据层面 Spark SQL原生方式高效访问SequoiaDB的数据 管理层面 SDB企业版提供的管理工具Admin Center可以同时管理Spark Standalone模式。 SequoiaDB获得Databricks的官方认证分销权
  • 40. SequoiaDB与Hadoop的整合多种数据存储方式的共存, 支持多个发行商的Hadoop版本应用层面整合 现有M/R和Spark代码可以同时访问SequoiaDB和HDFS/Hbase 现有SQL/JDBC客户可以同时访问SequoiaDB和传统关系数据库 提供数据块级和副本级并行处理能力 数据层面 提供Connector在异构数据源中相互交换数据 管理层面 SDB企业版提供的管理工具Admin Center可以同时管理HDFS和Spark,Hive。HDFSMap/ReduceSequoiaDBPigSequoia Enterprise Spark, Multiple SQL InterfacesSQL/JDBCRDBMSHiveSequoia ConnectorSequoia Connector
  • 41. SequoiaDB的大数据构想SequoiaDB提供完整的套件HiveMap/ReduceSequoiaDB (结构化、半结构化、非结构化数据)Spark SQLSpark RDD标准SQL EngineNative API动态仪表板图表容器ETL HQL、M/R、JDBC/SQL、Spark Scala、Mongo API、Python在线实时查询应用Admin Center
  • 42. 大数据案例——历史全量数据的利用23
  • 43. 数据的时间轴全量 – 历史数据的价值发掘全量 数据整合内部已有的结构化数据和线上非结构化数据形成Schema Free 的以客户为核心的全量数据视图人数占比年龄年收入(元)累计标保和缴付保费合计件均标保寿险缴付金额两全缴付金额年金缴付金额万能缴付金额意外缴付金额医疗缴付金额重疾缴付金额投连缴付金额0.60%474820026900804001900050050007670025001002004004001.37%512940015000966001070050090400580011600100800220030000.84%40180600108002130078001100380012400160010030070002.07%472940074007110011000600510015006370010050013005000.68%33820065003070054002008002930020001001001000.84%53360058008050010400053002500530000200772001.77%42974005300980039004003300300017001003004000
  • 44. 现有的挑战数据量越来越大 各个业务系统的历史归档存在不同软件、硬件、版本的平台中 数据增量加速,现有系统不堪重负,数据维护越来越困难 半结构化数据越来越多 各个业务系统经过多年运行,交易明细数据版本繁多,数据结构不统一 不同的数据源不同的数据结构:结构化数据、半结构化数据、非结构化数据 业务实时性要求越来越强 业务的查询实时性要求越来越高, 低成本的存储介质无法满足实时性要求 主要归档在冷存储上,部分在线,任何对早期历史数据的查询都需要漫长的过程 银行需求各渠道业务系统为客户提供明细账历史查询和实时的回单打印运营管理部对全量历史影像/票据进行“事后监督”全量数据交易流水全量数据2.9T(09年至今,近50亿条记录),目前每月增量2亿条历史影像平台全量150T,以前放在光盘库无法在线查询能不能使用一个平台存储所有历史全量数据,同时满足现有SQL应用的复杂检索和快速查询?
  • 45. 1.业务表结构的历史变化问题 同一个业务系统每年的数据表结构都会变化,历史库要包容变化的数据,统一进行查询、检索和分析 2.对于DBA来说历史数据要分类管理 时间序是最直观的管理方式 热点数据保证高性能,总体保持低成本 3. 简化调用方式,但是不同使用者需要不同的数据利用方式 数据的使用方式需要同时支持SQL, MapReduce(排序、wordcount等)、Spark(内存数据加工)、Hive(简单分析)等主要手段 管理海量历史数据的挑战
  • 46. 解决业务表结构的历史变化问题 灵活的数据模型JSON和时间序模型为什么历史库需要使用半结构化存储 同一个业务系统每年的数据表结构都会变化,历史库要包容变化的数据,统一进行查询、检索和分析 很多业务系统的非结构化数据(文件类型)是与其描述数据分开存储的,在历史库中再分开的话也很难查找。 架构上看,历史归档系统最好不要与前端业务系统耦合过于紧密 业务系统的所有变更不需要立刻实时通知归档系统 历史数据需要时间序管理,方便DBA进行分优先级分配资源
  • 47. 冷热数据隔离历史数据模型的特性是数据以递增为主 旧数据的热度随着时间的推移递减 传统将所有数据存放在一张表中的做法不可取 数据量膨胀时索引树过高,导致数据写入性能急剧降低 很难按照时间范围删除大块数据 SequoiaDB提供集合分区(主子集合)机制可以轻松应对历史数据 按历史顺序能直观反映数据热点 保障热点数据的性能 直观的分配资源给不同集合 直观的备份、归档规则
  • 48. SequoiaDB如何满足历史全量数据的需求海量数据存储 传统存放在磁带甚至直接丢弃的数据如今归档在全量数据平台中 日增数据几百GB甚至上TB 灵活的数据模型 应用层数据模型的变化应当被自动感知,且不需要手工调整归档平台数据模型 便于检索使用 提供随机字段检索与索引的功能海量数据存储 弹性水平扩张分布式架构 灵活的数据模型 JSON非结构化数据存储自适应数据结构的变更 便于检索使用 支持随机字段索引 支持随机查询协调节点数据节点协调节点数据节点协调节点数据节点协调节点协调节点协调节点数据节点数据节点数据节点数据节点数据节点数据节点数据节点数据节点数据节点编目节点编目节点编目节点
  • 49. 历史全量数据的用途1:用户流水实时查询ECIF柜面、网银、手机银行等渠道DB2SQL增删改问题和目标直销银行推动了用线上实时方式实现传统柜面的回单打印交易读写分离,以X86低成本方式水平扩展来应对不断加速增长的数据存储和实时查询需求全量数据同时供应查询和分析,分析时作为ODS的贴源层。需求 高扩展性和稳定性 50亿记录的实时查询性能<3s 数据分析的接口 平滑过渡,不影响原有数据处理流程, 对现有应用影响尽量实现方式T+1 批量将DB2数据全量及增量导入Sequoia DBSDB对外提供SQL接口,可继续使用现有查询应用批量同步SQL查询交易流水数据六年的历史流水数据网银/手机柜面
  • 50. 历史全量数据的用途2:交易/交互历史的随机查询和分析网银/渠道信用卡核心……实时或批处理任务随机营销分析客户接触历史客户画像历史数据的应用类型后台分析 优势 临时增加分析维度 实时查询和分析 保留数据细节 支持非结构化存储 降低开发成本客户交易历史客户交互历史客服信贷Ad-hoc统计Ad-hoc报表历史数据来源固定统计固定报表
  • 51. 历史全量数据的统一利用管理历史全量数据管理平台历史全量数据库实时查询服务批量检索服务随机定义查询数据清洗网银理财信贷国际基金历史数据当前数据历史数据当前数据历史数据当前数据历史数据当前数据历史数据当前数据实时用户画像反洗钱审计/后督SQL微信/手机批量导入反欺诈数据仓库和分析型应用ODS/DSA – 面向主题、当前DW – 面向主题、历史和汇总DMDMM/R历史数据当前数据HiveETL1234
  • 52. 大数据未来的畅想23
  • 53. 大数据能力创新的方向指标/模型随机/ 深入探索延时实时/准实时部分数据‘全量’数据预测与洞察、探索发现、搜索与可视化面向操作、事件驱动、即时分析结构化与非结构化,海量数据封闭/僵化开放/灵活数据与能力的开放,新的商业模式
  • 54. 未来NoSQL还面临哪些挑战SQL能力挑战? 旧的基于SQL的应用无法直接移植到NoSQL 旧的应用SQL能力暂无法满足 ACID挑战? 数据丢失的风险真的能接受? 一致性、原子性、隔离性同样很重要。传统应用没有改变,唯一变化的是数据量 与大数据计算平台的挑战? 混合型、异构存储? 回归MPP模型?
  • 55. xujianhui@sequoiadb.com37