NoSQL
——
大数据时代的机遇和挑战
2015/10/25
asdfa
Who Am I?
许建辉
广州巨杉
研
发总监，主导大数据的产品架构设计和总体研发
前华为员工，在华为拥有
4
年电信级软件设计开发经验和
5
年大数据产品设计开发经验；
2012
年加入广州巨杉核心团队
xujianhui@
2
Agenda
3
大数据面临的挑战
Big Data, Big World
4
业务的革新
数据成为业务发展的核心
银行提供所有历史交易信息查询
航空根据机票信息分析用户属性，并提供个性化的优化推荐
QQ
空间日均上传
2
亿张照片，每分钟
万
双
11
支付宝交易达
亿笔，每分钟
约
万；淘宝天猫吸引
亿独立用户访问
新浪微博日均发博
亿条
用数据对话数据
6
近
5
年数据增涨
5
倍以上
结构化数据增涨缓慢，非结构化数据呈指数增涨态势
全球数据产生十年增涨趋势
全球数据存储增涨趋势
数据增涨背后是业务的不断革新
“大数据”的诞生
大量化、多样化、时效性、价值密度低是大数据显著特征
大量化
非结构化数据增涨是结构化数据的
10
到
50
倍
Google
每天处理
24PB
的数据
手机、传感器等终端产生大量数据
PB
是临界值
多样化
来源多
：
搜索引擎、社交网终、终端设备
格式多：结构化数据、半结构化数据以及文件、图片、视频、音频等无结构化数据
时效性
数据实时检索和分析
数据动态关联
1S
是临界值
价值密度
大量不相关的信息，价值密度低
对未来趋势和模式的可预测分析
深度复杂分析（价值挖掘）
“大数据”思维
——
先有数据，再找模型
从数据中挖掘价值催生新型业务
IT
人员
把数据关系结构化，抽取样本数据
业务人员
决定问什么问题？
定量问题
IT
人员
提供全量数据和探索性分析工具
定性问题
业务人员
探索关联关系、因果关系
大数据并不仅仅是某一种新的技术，而是一种全新的思维模式的变更。
，大数据思维的特性，用一句话来讲，就是：先有数据，再找模型。
传统大家在做数据分析的时候，首先业务人员要定义出想要解决什么问题，然后拿着这个问题去找
IT
，
IT
呢根据这个命题建立一个模型，然后找小样本的数据去验证一把。
如果验证结果合适，那么再把这个模型应用上去，定期出报表之类的。
而大数据的思维，则是迭代不断探索的分析方式。是由
IT
人员通过挖掘的方式，从无数指标特性中挖掘出最可能相关的一些维度，先找到结果。然后再拿着结果和业务人员一起探索关联的关系和因果关系。
也就是说，传统的做法是先想模型，然后对数据应用。
大数据则是先有数据找到结果，然后再找对应的模型。
asdfa
企业的数据资产
存储和分析非结构化数据成为企业业务突破的关键
利用和分析非结构化数据
作为现有数据仓库的有效补充
外部
的“大数据资产”作用
更好了解客户
–
客户画像
/
征信
更好了解竞争对手
–
竞争分析
更好了解市场和行业趋势
-
舆情监控
更实时的风险监控
–
渠道风控
内部
的“大数据资产”作用
历史数据的充分再利用
提升客户体验和营销有效性
产品创新与定价，提高利润
电子渠道的欺诈防范
想要做到这一点，全量数据是非常重要的。如今企业内部真正被有效使用的数据只有
20%
。另外
80%
的非结构化数据仅仅是保存下来，根本无法得到有效利用。
asdfa
传统关系型数据库的核心
传统关系型数据库
ACID
基于单机或共享存储实现
SQL
接口
标准的
SQL
接口
存储过程
ACID
Atomicity
（原子性）：事务中的所有操作要么全部成功，要么全部失败
Consistency
（一致性）：事务的过程中整个数据加的状态是一致的，不会出现数据花掉的情况
Isolation
（隔离性）：相个事务不会相互影响，覆盖数据等
Durability
（持久化）：事务一旦完成，数据是被写到安全的、持久化的存储设备
传统关系型数据库面临的挑战
大数据时代必须寻求新的技术
Data Model
数据模型
严格的数据模型阻碍业务的快速变化
无法存储半结构化和
非
结构化数据
Huge Storage
海量数据存储
新型构架
存储量有限（只能达到
TB
级容量，十亿级记录），无法扩展
PB/EB
级容量，百亿
/
千亿级记录
SQL
查询效率低，无法提供百万每秒的查询性能
无法满足“无限水平扩展”的架构
无法部署
PC
服务器集群
无法提供云化服务
敏捷开发
繁重的数据设计和系统维护，无法简化开发流程
不能响应变化，不能满足迭代式开发
10
NoSQL
的机遇和发展
NoSQL
解决方案
NoSQL
为大数据而生
使用
PC
服务器进行水平扩张
Schemaless
带来
开发的敏
捷
和可扩展性的提升
分布式集群模式
+
数据冗余
+
读写分离等提供高可用、高可靠和高性能
高可用高性能
数据模型灵活
低成本
分布式架构
+
非结构化存储
=
水平扩张
海量数据
什么是
NoSQL
？
NoSQL
不是
SQL
的替代，而是补充
它是
N
ot
O
nly
SQL
的缩写
基于
CAP
理论、
BASE
模型
一类非关系数据存储系统
通常不需要一个固定的表的模式
提供多样化、灵活方面的接口
一定程度上淡化了一个或多个
ACID
属性
能运行在廉价
PC
服务器上，支持无限扩展
追求简单和易用
CAP
理论、一致性策略和
BASE
模型
CAP
，
BASE
和最终一致性是
NoSQL
数据库存在的三大基石
C
P
A
Consistency
Availability
Partition tolerance
只能同时满足两个？
A
P
Cassandra
CouchDB
Dynamo
CA
MySQL
PostgreSQL
SQL Server
CP
SequoiaDB
MongoDB
BigTable/Hbase
Redis
R
：读节点个数
W
：写节点个数
N
：副本数
R+W>N
：强一致策略
R+W<=N
：弱一致策略
最终一致性
：当很长一段时间没有更新，最终的所有更新通过系统传播，和所有节点将是一致的。
B
asically
A
vailable
（基本可用）：支持分区失败
S
oft-state
（软状态）：状态可以有一段时间不同步
E
ventually consistent
：最终数据是一致的
CAP
理论由
Eric Brewer
提出，所以有时又被称为
Brewer
理论。
CAP
理论在
2002
年被
MIT
的
Seth Gilbert
和
Nancy Lynch
所证明。
Consistency
：
All client always
have the same view of data
Availability
：
All client can always read and write
Partition tolerance
：
The system works well despite physical network partitions
Quorum NRW
模型
N
：存储备份的节点数目，可以理解为备份的数目。
W
：更新（写）操作成功之前所必须更新的最少备份数目。假设
W=3
，表示至少等到
3
个备份的数据得到更新时，更新操作才算完成。
R
：读操作所需要连接的最少备份数目。假设
R=3
，表示读取一个数据时，至少要读取到这个数据的
3
个备份，然后选其中最新的备份。
调整
N
、
W
、
R
的取值，数据库系统的性质就会发生改变。
N
越大，同一个数据的备份越多，系统相对也就越不容易丢失数据。
W
越大，系统的一致性会越高，但更新操作也就越慢。
R
越大，系统的一致性会越高，但读操作也就越慢。
W+R>N
，系统是强一致性的。为什么？举例来说，假设
N=6
，
W=R=3
，当一个更新操作完成的时候，它至少更新了
6
个备份中的
3
个备份，那么当我们去读取这个数据的时候，因为
R=3
，所以我们至少得读
3
个数据，并从中选择最新的数据，而
W+R>N
就意味着读取的
3
个数据跟更新的
3
个数据至少有一个是重叠的，所以读取的
3
个数据中一定存在最新的数据，因而就能保证系统是强一致性的。
W+R<=N
，系统是弱一致性的。
几种特殊情况：
W = 1
，
R = N
，对写操作要求高性能高可用。
R = 1
，
W = N
，对读操作要求高性能高可用，比如类似
cache
之类业务。
W = R = N / 2 + 1
一般应用适用，读写性能之间取得平衡。如
N=3
，
W=2
，
R=2
。
asdfa
NoSQL
的分类
NoSQL
产品和形态呈现多样化
K/V
Redis
MemcacheDB
宽表
Cassandra
Hbase
文档
SequoiaDB
mongoDB
C
ouchDB
图形
Neo4j
FlockDB
InfoGrid
NoSQL——KV
KV
是高并发的简单存储系统
键值对存储类型
Fast
，
Faster
，
Fastest
所有的数据只能使用主键检索，数值作为整体存放
数据结构与算法针对主键检索实现，基本不提供数据库引擎计算功能，大部分计算功能交由应用程序完成
适用于针对主键的快速随机读写操作
不适用于复杂计算，分析等
领域
代表产品：
R
edis
、
M
emcacheDB
asdfa
KV
的数据模型和关键技术
KV
适应于高速缓存的场景
只提供
PUT/GET/DELETE
简单操作
DHT
，一跳访问，高性能
Hinted handoff
，节点故障用临时节点替代，节点恢复从临时节点同步增量数据；动态维护可用性、可靠性
Gossip-based membership protocol
，实现去中心化
NRW
模型，向量版本提供一致性保障
KV
数据模型
分布式
HASH
（
DHT
）
asdfa
NoSQL——
宽表（列式存储）
宽表是有效的分析型存储系统
使用列簇（
Column Family
）机制将存在大量字段的记录分解成相对较小的子记录
存放，高压缩比
来自于
Google
的
BigTable
使用列簇的方式避免每次读取整条记录
使用日志文件记录的方式保证写入操作的高效
使用布隆过滤提升读取性能
适用于字段数量很多的分析类场景
不适用于大量随机访问，非主键随机查询等
场景
代表产品：
Hbase
、
Cassandra
asdfa
列存数据模型和技术特点
宽表是有效的分析型存储系统
基于日志追加的写入（顺序写盘），通过合并文件加速数据有序化；不适合大量更新操作
主键数据有顺存储，索引和
Bloom Filter
加速数据在文件定位
支持万级以上字段，支持按列读取数据；高压缩率；随机访问性能差，不支持非主键索引
asdfa
NoSQL——Graph
图型
NoSQL
只用于特定的场景
非常规数据库
保存对象之间关系信息
适用于社交网络类型应用
不适用于其他场景
代表产品：
Neo4j
、
FlockDB
、
InfoGrid
asdfa
Graph
数据模型和技术特点
图型
NoSQL
只用于特定的场景
Node
和
Relationship
的
Property
是用一个
Key-Value
的双向列表来保存
的
Node
的
Relationship
是用一个双向列表来保存
的
通过关系，可以方便的找到关系的
from-to Node
数据模型
存储示意
模型
1
、
A~E
表示
Node
的编号，
R1~R7
表示
Relationship
编号，
P1~P10
表示
Property
的编号
2
、
Node
的存储示例图
,
每个
Node
保存了第
1
个
Property
和 第
1
个
Relationship
3
、
从示意图可以看出，从
Node-B
开始，可以通过关系的
next
指针，遍历
Node-B
的所有关系，然后可以到达与其有关系的第
1
层
Nodes,
在通过遍历第
1
层
Nodes
的关系，可以达到第
2
层
Nodes
asdfa
NoSQL——
文档型
文档型
NoSQL
最接近关系型数据库
使用
JSON
或兼容数据结构存储数据
支持灵活数据模型，不需预定义数据结构
使用行存储
功能最接近关系型
数据库，可以拥有与之相当的
ACID
适用于操作类应用场景，以及作为通用存储保存可检索的半结构化数据
不适用与超高性能数据访问需求以及事务类操作
代表产品：
SequoiaDB
、
MongoDB
、
CouchDB
asdfa
文档型数据模型和技术特点
文档型
NoSQL
最接近关系型数据库
{
“_id”: {
“$oid”:”561f4452d2a4a22e10000000”
},
“Name”:”John”,
“Phone”:[
13501258963,
13963659896,
]
“Address”:{
“Home”:”xxxxxx”,
“Office”:”xxxxxx”,
}
…
}
JSON/BSON/LOB
数据模型
>
、
>=
、
<
、
<=
、
=
、
!=
、
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
驱动
权限管理
多副本、自动分区
……
asdfa
Nosql
技术介绍（基于
Sequoiadb
）
10
SequoiaDB
的总体架构
SequoiaDB
采用
高可靠、高可用、水平无限扩展的分布式架构
成熟的分布式架构
独立的接入层，可以动态收缩扩张，可与应用一起部署，也可以数据一起部署
数据层以“数据组”为单位，组内为副本，组间为分区
协调节点在产生缓存冲突才更新编目
编目属于特殊数据组
asdfa
SequoiaDB
数据模型
支持结构化、半结构化和无结构化的数据模型
数据按对象描述
(JSON)
存储，避免
SCHEMA
僵硬，灵活适应
变化
弱关系型数据存储，同时提供
SQL
支持
数据类型一致，数据特征相似
-
高效压缩
分布并行查询，多索引
文件按照
LOB
处理
自动按照
64/128KB
的数据块进行切分，放在不同分区存储
使用
DIO
避免二进制数据占用文件系统缓存
并行处理
asdfa
SequoiaDB
的
HA
数据组自动选举策略保证业务高可用
一个数据组支持
1-7
个数据节点
1
主多备
；
主提供读写服务，备只提供读服务
基于权值的
Paxos
选举算法
基于
Push-Pull
日志的副本数据同步，有“主
-
备”和“备
-
备”两种模式
协调节点
数据节点
(P)
数据节点
(S)
数据节点
(S)
{ hello: “world” }
{ hello: “world” }
{ hello: “world” }
{ hello: “world” }
选举
数据节点
(P)
asdfa
SequoiaDB
的副本一致性
数据组内的数据向主节点对齐
主节点宕机后，
LSN
最新节点当选为主，每次升主，
LSN
版本号加
1
升主后，向其它节点广播；其它节点向新的主节点对齐数据
如果开启事务，则新当选的主节点回滚所有未完成的事务
A
主
备
备
A
A
B
B
C
我想当主节点
我想当主节点
我当前任务号
是
B
我当前任务号
是
A
主
我当主了，大家向我看齐
同步请求
B
asdfa
SequoiaDB
的副本不一致协商回滚
数据组内的
LSN
协商和回滚保证异常下的数据一致性
主节点恢复后，与新的主节点进行数据对齐
LSN
不一致（版本或
HASH
校验）则协商至上一相同版本号的最后
LSN
，协商失败则发起全量同步
对于协商点
LSN
之后的日志全部进行回滚，回滚失败发起全量同步
主
备
A
A
B
C
主
B
A
B
备
D
同步请求
D
D
我最新的版本号是
1
我最新的版本号是
2
1
版本号最后的步骤
为
B
将
B
之后
的操作回滚
asdfa
SequoiaDB
热备节点（
Hot-Spare
）
热备节点自动处理分布式下的节点故障，始终保持数据可靠
数据组节点故障时，自动踢除该故障节点
从热备组中挑选
1
个节点加入该数据组
新加入的节点进行全量数据构建
Hot-Spare Node
Hot-Spare Node
…
Hot-Spare Group
Data Node
Data Group
Data Node
Data Node
asdfa
SequoiaDB
灵活的一致性策略
灵活的一致性和副本策略满足业务数据一致性和可靠性要求
可基于
Collection
或操作设置一致性策略
可配置副本个数
支持强一致和最终一致
异步批量日志同步机制
asdfa
SequoiaDB
副本
并发同步机制
并发日志同步在保证一致性前提下大大提升副本性能
对于
Insert/Update/Delete
操作，备节点根据
OID
进行
hash
，并分发至
Hash Bucket
由线程池驱动
Hash Bucket
，实现并发
Reply
如果失败，则回滚至“最小完成
LSN
”
asdfa
SequoiaDB
水平分区机制
水平分区实现海量扩容和性能扩展
将
Collection
根据
ShardingKey
切分到多个数据组
Hash
分区 和 范围分区两种方式
实现
Collection
数据无限扩容
asdfa
SequoiaDB
垂直
分区机制
垂直分区实现数据逻辑大集合
Collection
按照某字段划分多个分区
每个分区可以对应到子
Collection
子
Collection
可以进行水平分区
子
Collection
可以在不同的
CollectionSpace
协调节点
数据节点
数据表可按照字段范围切割到多个逻辑分区中
数据节点
数据节点
数据分区
数据分区
数据分区
数据分区
一月份数据
二月份数据
三月份数据
四月份数据
asdfa
SequoiaDB
的时间序数据模型
垂直分区实现数据时间序模型
实现数据按时间的冷热隔离
实现数据按时间的快速处理（删除、查询、统计）
可以适应数据逻辑的变化，而对外提供统一的操作
避免单一集合的膨胀和腐烂，提供更高的业务操作性能
My0101
20140201
20140101
MyHistory
(“My0101”)
(
“”,
{
UpBound
:{date:”20140201”},
LowBound
:{date:”20140101”}}
)
My0201
20140301
20140201
My0301
20140401
20140301
My0401
20140501
20140401
My0501
20140601
20140501
(“My0201”)
(
“”,
{
UpBound
:{date:”20140301”},
LowBound
:{date:”20140201”}}
)
(“My0301”)
(
“”,
{
UpBound
:{date:”20140401”},
LowBound
:{date:”20140301”}}
)
asdfa
SequoiaDB
读写分离机制
读写分离机制帮助业务实现“数据湖”
会话可以指定读取的副本策略（主、备、编号
ID
）
所有数据组相同副本
ID
共同构建一个数据库“实例”
数据组的副本可以进行物理隔离，对不同“实例”的访问同样可以物理隔离，互不干扰
SequoiaDB
平台
实时海量数据查询
交互式批量分析
中心节点
–
数据自动复制
海量数据湖
海量数据挖掘
除了数据模型的变化，
SequoiaDB
另一个特点是把数据在数据库内部进行多份存储，一方面可以保证高可用性，另一方面可以进行读写分离，将不同类型的业务分发到不同的物理盘上，做到实时操作和批处理分析互不干扰。这种模式也是大数据平台的一个基础。所谓大数据平台就好像一个垃圾桶，或者说云存储一样，把任何类型的数据都可以往里面扔，使用的时候随意做结构化、非结构化、实时或批量的检索，并且最大化地保证业务之间的相互独立不干扰。
SequoiaDB
内部机制支持读写分离，多类型业务可以运行在同一平台上
数据在多个分布节点内可以自动分片和复制，可以定制数据分布策略
.
高频读写数据和批量处理数据可以通过不同的数据节点实现分离操作
有一致性要求的数据可以集中在单个节点上写，以保证强一致性和性能兼顾的要求
高频读写数据和批量统计数据可以通过
”
冷
/
热分区
”
分开放在不同性能的节点上
.
asdfa
SequoiaDB
图形化管理
垂直分区实现数据时间序模型
一键式安装和扩容（容量规划，机器发机，部署向导
……
）
节点和性能自动化监控，图形展示
全新的数据展示模型、开放的
REST
接口
asdfa
SequoiaDB
与
Spark
的整合
SequoiaDB
预集成
Spark
应用
层面
整合
充分
利用
Spark
内存加速
机制
支持
用
Scala
开发存储
过程
支持
RDD
、
transformation
等操作，减少
I/O
操作
提供数据块级和副本级并行能力
数据
层面
Spark
SQL
原生方式高效访问
SequoiaDB
的数据
管理
层面
SDB
企业版提供的管理工具
Admin Center
可以同时管理
Spark Standalone
模式。
获得
Databricks
的官方认证分销权
asdfa
SequoiaDB
与
Hadoop
的整合
多种数据存储方式的共存
,
支持
多个发行商
的
Hadoop
版本
应用
层面
整合
现有
M/R
和
Spark
代码可以同时访问
SequoiaDB
和
HDFS/
Hbase
现有
SQL/JDBC
客户可以同时访问
SequoiaDB
和传统
关系数据库
提供数据块级和副本级并行处理能力
数据
层面
提供
Connector
在异构数据源中相互交换数据
管理
层面
SDB
企业版提供的管理工具
Admin Center
可以同时管理
HDFS
和
Spark
，
Hive
。
asdfa
SequoiaDB
的大数据构想
SequoiaDB
提供完整的套件
Hive
Map/Reduce
SequoiaDB
（结构化、半结构化、非结构化数据）
Spark
SQL
Spark
RDD
标准
SQL
Engine
Native
API
动态仪表板
图表容器
ETL
HQL
、
M/R
、
JDBC/SQL
、
Spark
Scala
、
Mongo API
、
Python
在线实时查询
应用
Admin
Center
asdfa
大数据案例
——
历史全量数据的利用
23
数据的时间轴全量
–
历史数据的价值发掘
整合内部已有的结构化数据和线上非结构化数据形成
Schema Free
的以客户为核心的全量数据视图
过去的数据放到磁带里面，几乎从来不用
如果我们能够将历史数据有效利用起来呢
?
现有的挑战
数据量越来越大
各个业务系统的历史归档存在不同软件、硬件、版本的平台中
数据增量加速，现有系统不堪重负，数据维护越来越困难
半结构化数据越来越多
各个业务系统经过多年运行，交易明细数据版本繁多，数据结构不统一
不同的数据源不同的数据结构
:
结构化数据、半结构化数据、非结构化数据
业务实时性要求越来越强
业务的查询实时性要求越来越高
,
低成本的存储介质无法满足实时性要求
主要归档在冷存储上，部分在线，任何对早期历史数据的查询都需要漫长的过程
能不能使用一个平台存储所有历史全量数据，同时满足现有
SQL
应用的复杂检索和快速查询？
ECIF 09
年到现在，全量都保存在
DB2
，在线
2
年，大数据平台保存
10
年，全量数据
500-600G
，每月增量大概
1
亿
回单
12
年到现在，全量都保存在
DB2
，在线
2
年，大数据平台保存
5
年，
16
亿条，每月增量数据大概在
1
亿，
ecif
和回单系统每个月的增量大概是
1
亿条流水。
影像平台全量
30T
，之前数据都是存储在
EMC
的
documentum
上管理，增量数据入库时，首先从存储中取出增量文件，放到指定目录中，文件名以
documentum
中
Oracle
的
id
号命名。影像平台和管控系统每个月分别有
2T
左右的影像增量。
管控历史影像主要是运营管理部用于“事后监督”的柜员做业务的凭证。以前放在在光盘里，全量
150T
1.
业务表结构的历史变化问题
同一个业务系统每年的数据表结构都会变化，历史库要包容变化的数据，统一进行查询、检索和分析
2.
对于
DBA
来说历史数据要分类管理
时间序是最直观的管理方式
热点数据保证高性能，总体保持低成本
3.
简化调用方式，但是不同使用者需要不同的数据利用方式
数据的使用方式需要同时支持
SQL, MapReduce
（排序、
wordcount
等）、
Spark
（内存数据加工）、
Hive
（简单分析）等主要手段
管理海量历史数据的挑战
解决业务表结构的历史变化问题
灵活的数据模型
JSON
和时间序模型
为什么历史库需要使用半结构化存储
同一个业务系统每年的数据表结构都会变化，历史库要包容变化的数据，统一进行查询、检索和分析
很多业务系统的非结构化数据（文件类型）是与其描述数据分开存储的，在历史库中再分开的话也很难查找。
架构上看，历史归档系统最好不要与前端业务系统耦合过于紧密
业务系统的所有变更不需要立刻实时通知归档系统
历史数据需要时间序管理，方便
DBA
进行分优先级分配资源
冷热数据隔离
历史数据模型的特性是数据以递增为主
旧数据的热度随着时间的推移递减
传统将所有数据存放在一张表中的做法不可取
数据量膨胀时索引树过高，导致数据写入性能急剧降低
很难按照时间范围删除大块数据
SequoiaDB
提供集合分区（主子集合）机制可以轻松应对历史数据
按历史顺序能直观反映数据热点
保障热点数据的性能
直观的分配资源给不同集合
直观的备份、归档规则
SequoiaDB
如何满足历史全量数据的需求
海量数据存储
传统存放在磁带甚至直接丢弃的数据如今归档在全量数据平台中
日增数据几百
GB
甚至上
TB
灵活的数据模型
应用层数据模型的变化应当被自动感知，且不需要手工调整归档平台数据模型
便于检索使用
提供随机字段检索与索引的功能
海量数据存储
弹性水平扩张分布式架构
灵活的数据模型
JSON
非结构化数据存储自适应数据结构的变更
便于检索使用
支持随机字段索引
支持随机查询
历史全量数据的用途
1
：用户流水实时查询
ECIF
柜面、网银、手机银行等渠
道
DB2
SQL
增删改
批量同步
SQL
查询
交易流水数据
六年的历史流水数据
网银
/
手机
柜面
历史全量数据的用途
2
：交易
/
交互历史的随机查询和分析
网银
/
渠道
信用卡
核心
……
实时或批处理任务
随机营销分析
客
户接触历史
客户画像
历史数据的应用类型
后台分析
优势
临时增加分析维度
实时查询和分析
保留数据细节
支持非结构化存储
降低开发成本
客户交易历史
客户交互历史
客服
信贷
Ad-hoc
统计
Ad-hoc
报表
历史数据来源
固定统计
固定报表
历史全量数据的统一利用管理
历史全量数据管理平台
历史全量数据库
实时查询服务
批量检索服务
随机定义查询
数据清洗
网银
理财
信贷
国际
基金
实时用户画像
反洗钱
审计
/
后督
SQL
微信
/
手机
批量导入
反欺诈
M/R
Hive
ETL
1
2
3
4
大数据未来的畅想
23
大
数据能力创新的方向
未来
NoSQL
还面临哪些挑战
SQL
能力挑战？
旧的基于
SQL
的应用无法直接移植到
NoSQL
旧的应用
SQL
能力暂无法满足
ACID
挑战？
数据丢失的风险真的能接受？
一致性、原子性、隔离性同样很重要。传统应用没有改变，唯一变化的是数据量
与大数据计算平台的挑战？
混合型、异构存储？
回归
MPP
模型？
asdfa
xujianhui@
37
asdfa
