上一篇书评向大家推荐了 Desinging Data-Intensive Applications 这本书. 由这本书启发, 我也想整理一下自己在大数据这一块的知识体系. 首先, 我们要理解数据系统面对的场景和挑战, 我们才能更好的理解其设计动机和原理. 本文主要总结这些场景和挑战, 会提到一些目前的相应技术, 但不会展开讲. 后续系列文章会渐渐深入分析这些技术. 本文的目的是描绘一个概括性的逻辑性的框架.
基本数据存取
我们从最简单的场景开始, 对于一个数据系统, 最基本的需求就是数据的存取, 在某个时间点, 把数据存起来, 下一个时间点再把数据取出来[1].
似乎一个简单的 append only 文件就可以满足这个需求, 每次存数据就是写文件, 取数据就从文件读. 然而这样的话, 查找一个特定数据就需要全局扫描, 效率低下. 这里引出了第一个挑战: 存取效率. 一方面, 我们有 hash 索引, Btree,LSM 树等技术来提高查找效率. 另一方面, 我们针对数据访问模式(OLAP), 改变数据存储方式(列式存储), 提高读取效率.
有的数据存取操作之间是绑定的, 应用会希望绑定的操作要么全部成功, 要么都不成功, 也就是原子性. 当多个客户端同时访问数据时, 应用希望这些访问就像是顺序发生的(Serializability), 所有并发可能引起的问题都应该避免掉, 也就是隔离性. Transaction 主要就是为了应对这两个挑战.[2]
大规模数据存取
当数据量和访问规模大到一定程度, 为了突破单机的性能瓶颈, 我们会希望不同的用户可以通过不同的节点访问数据, 提高吞吐量, 同时部分节点故障不影响系统服务, 提高可用性. 因此, 我们会做 Replication, 把同一份数据保存到多个不同的节点. 我们会做 Partitioning, 把数据集按照一定策略划分成一个个分区, 每个节点负责一个或几个分区.
当我们做了 Replication, 一份数据有多个副本, 理想情况下, 我们希望不同客户端对数据的访问不要出现不一致, 仍然就像只有一个副本一样 (Linearizability/strong consistency). 而当从单机数据系统扩展到集群之后, 我们会面临分布式系统无法避免的三个问题. 机器不可靠, 单个节点故障的几率不高, 但是大规模集群中有节点故障概率就很高; 网络不可靠, 通过网络传输的数据可能会延迟, 也可能会丢失; 时间不可靠, 机器时钟的误差会累积, 而通过网络同步时间, 网络又有延迟, 所以全局时间无法一致. 为此, 我们抽象出了共识问题(Consensus), 提出了各种算法(Paxos,Raft) 来解决这个问题. 因为解决了这个问题, Linearizability 就好实现了.
保证 Linearizability 有时候会损失可用性(CAP). 因此, 我们会根据具体情况, 适当降低一致性要求, 提供各种不同的一致性保证, 即最终一致性.
数据生态
同一份数据我们可以有不同的用途. 例如在一个电商系统中, 商品, 订单, 支付, 物流等数据, 支撑着整个业务流程, 随着业务进行更新(OLTP). 同时, 公司的决策层需要判断电商行业的发展趋势, 例如需要查看不同年龄段消费者购买不同品类商品所占比例随年份变化的情况. 要满足这类数据需求(OLAP), 需要对业务数据进行连接, 过滤, 聚合等计算操作. 为了提高查询效率, 我们不会每次 OLAP 查询都重新从业务数据库计算. 而是事先把这些数据预处理, 按照星型模型或雪花模型单独存在一个数据库中.
现在, 我们除了业务数据库, 还增加了一个数据冗余的 OLAP 数据仓库. 一般数据仓库中的数据每天凌晨用很多较大的批处理任务更新. 对于批处理作业我们优先考虑的是吞吐量. 批处理作业处理的数据量大, 时间长, 我们希望其有较好的容错性, 不能由于某些局部错误导致整个作业重跑. 这些批处理任务一般是 MR 或 Spark 任务, 它们用不同的方法提供容错性, Spark 效率更高. Hive 和 SparkSQL 使我们可以用简单的 SQL 语句创建这些任务. 即使我们有了数据仓库, 对于多数 OLAP 查询的结果仍然要进行计算才能得到, 对于这种即时查询, 查询速度更加重要, presto 和 kylin 从不同的角度优化这类查询的效率.
数据仓库的数据每天更新一次, 意味着我们的 OLAP 查询无法反映实时的数据. 为了对实时的数据进行计算, 我们需要不同于批处理的计算模式, 也就是流式计算. 对于流式计算, 数据随着时间不停的产生, 没有边界. 相对于固定输入的批处理, 这带来一些新的挑战. 首先, 要对数据的传输进行负载均衡路由和限流, 防止计算模块处理不过来. 其次, 数据可能会延迟, 且没有边界, join 之类的计算需要考虑的情况更多了. 最后, 输入数据不是固定的, 容错也不像批处理一样重试即可. 另外, 我们还要考虑流式计算与批处理如何统一起来.
除了 OLAP 应用, 我们可能还会有其它的数据应用, 如推荐系统, 搜索服务等. 这些都相应的有更合适的数据模型和存储, 而其中部分数据也可能来源于业务数据库. 一个完整的数据系统, 除了原始的数据库, 还有各种衍生的不同模型的冗余数据库. 因此, 要保证这整个数据系统的正确稳定运行, 不仅要提供单个数据库的可靠性和容错性, 还要考虑数据流动的整个生命周期可能出现的各种问题.
来源: http://www.jianshu.com/p/2ef1781ccab5