开发者学堂课程【分布式计算入门：大数据和数据库的结合】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/375/detail/4705
大数据和数据库的结合
内容简介：
一、基础设施发展
二、数据库的历史
三、引申
一、基础设施发展
商用CPU的速度以及核心的飞跃式发展，给单计算计算能力增强带来了可能性，单机的大规模内存设备以及SSD硬盘和SATA硬盘的混合架构，单服务器挂载盘数上限增加，网络拓普以及光线设备、万兆网卡的引入等等，这些硬件条件使得在进行整体系统设计方面有非常大的施展空间。
在分析整个分布式计算的大数据背景，大数据实际上存在部分的数据被大量频繁复用的情况。比如互联网公司对人的挖掘的数据，这批数据被很多个业务、很多个计算任务频繁使用。部分数据一次写成百上千次上万次，也就意味着这个数据价值极高。很多业务的计算逻辑任务都需要读取这个数据。那显而易见读写比高的数据一定是要被cash，能得到整个的roi的提成。
问题：从小型机到分布式到单机能力提升，矛盾么？是否单机能力越强越好？
阿里云飞天的伏羲打破了世界saltdenmark的记录，外部也有一些质疑，机器规模是不必要的。其实分布式系统并不是十台机器一定比两台机器有五倍的提升，一万台机器跟一千台机器也不是十倍的提升。
线性计算意味着，第一，硬件可以线性扩展，第二，性能可以随着物理集群的扩展进行扩展，这本身就是一个及其核心的能力。
aws的模式是把物理机切成虚拟机，然后再把虚拟机用分布式计算系统连成一个大的。
二、数据库的历史
1.DB(Data Base)
数据是业务用户产生，数据 schema 化，强一致性，更多的访问是随机访问，数据本身是实时的，Data Base 是分散的。
单元化的意思是整个业务集群、数据库集群是随着业务，或者说距离最终用户靠近的地方而单独部署的小集群。单元化强调的好处是将用户的体验延时降到最低，同时保留多集群论可靠性，也带来了很大的挑战，非常重延时。
强调 Transaction processing 领域，也就是 OLTP 领域，“某用户买了两个 apple watch ”这是一个动作、事件。
反观分布式计算领域最传统的当属出仓，数据源是业务的数据库，或者log、其他领域 SDK 的数据。处理 ETL 建模，也叫BD(Big Data)。强调宽表，将所有的数据扫描，侧重离线，强调数据计算而不是访问，
idc、Big data基本上都是数据机房大集中，与Bb相反重吞吐，机器学习 OLAP 与 OLTP 相对应，买 apple watch 的用户地域分布情况。
2.BD
Big Data强调3V，Volume 数据量与之对应的是成本，Velocity 速度——数据入口的吞吐，用户的数据延时、体验，Variety 多样性——是指数据源、格式、质量的多样性。
比如结构化数据、非结构化数据、半结构化数据、音频、图片、视频、数据库的数据，数据源有各种 datebase 、物联网采集的数据、其他子系统汇总上来的数据。
传统数据库扩展性不够，DB表示能力有机器学习、图计算，图计算包括离线图计算、在线图计算以及图数据库，计算模式目前以扫描为主。
3.GFS
GFS 提供了大文件块的存储方案，小文件和流式文件的存储都可以以大文件为基础衍生，系统产品设计遵从了Immutable，不可变使得整个系统的容错复制变得非常容易，可以在 Immutable 的基础上实现 Mutable 和随机读写。这是 slm 的大致思路。
扩展性可以做到跨核心、跨IDC甚至可以跨国，可靠性要求极高，成本低廉。
4.编程模型
表达能力有SQL、MPI、RPC，考察扩展性，即在这个编程模型下系统如何有效的切分任务？如何考虑网络拓扑？如何考虑数据的本地化？以及你的计算所相关的多个数据或者多个表，这些表之间的摆放的相关性如何容错？
集群大的情况下容错每时每秒都在发生，因为一千台服务器整体让它运行良好，每台都不能出错。当集群规模上万时，基本上内存错误、CPU错误、主板错误、断电散热问题、网络问题、硬盘问题、踢掉网线每时每秒都可能在发生。
这些情况硬件的问题加之软件设计的问题，极容易造成系统的全面循雪崩。数据倾斜、异构服务器。系统的服务化、相同物理机超卖、部署多个任务都会造成整个计算任务的长尾计算整个不均匀，都会带来雪崩的风险。
5.编程模型要求
在编程模型中考虑到达它的计算逻辑与编程模型的表示能力，会考虑ETL、建模、OLAP、机器学习、图计算、迭代计算等场景。考虑表示能力和自由度，只有原语进行有效的约束，整个系统的容错才会高效。操作是否可被重录等等都是考虑编程模型核心的因素。
6.MR
通用的数据密集型编程模型，osdi2004 论文发表介绍每天的处理量为20PB/天，现在增长了 100 倍不止。Hadoop 社区快速跟进推出了新一代调度系统 Yarn 。随后 Pregel 、Spark 、Dremel 、Drill 的出现使得分布式领域呈现出不断细分同时不断整合的趋势。
MapReduce 编程模型，第一代 MapReduce 存在着非常明显的问题，即 MapReduce 控制结点、单节点的问题。JobTracker 全局为1，在小文件数激增的情况下，原数据膨胀，资源分配与任务类调度混合，将资源的分配和资源的摆放合一，粒度太粗，都造成了 Hadoop 第一代无法大规模使用和线性扩张。整体slots资源的模板基本上将资源静态化、无法共享，划分粒度大，导致有些 slots 的 CPU 用满 Memory 不够用，隔离性差，单一计算，系统升级时必须停机。
这些问题在 Hadoop2.0 得到提升解决。Yarn 最显著的特征是将资源的分配与任务内给定资源怎么摆放任务分离。RM所做的事情是今天要向老板、老师去申请多少个人。如何将人和事情搭配得更有效这是 AM 所做的事情。之前的Hadoop2 将这两件事情混为一谈，在2.0被有效的解决。
7.抽象
将分布式计算分成五个问题，第一，任务如何切分？第二，如何去找RM选资源？第三，拿到资源如何运行下发的任务？第四，如何下发执行？在任务运行中如何控制时机、结果、容错？
8.SQL
Facebook开源的内部HIVE系统极大地刺激了 hadoop 社区发展，因为 HIVE 可以使传统的数据开发工程师、BI 的人员乃至运营用 SQL 很方便的写出大数据的应用。
HIVE 并不是放在数据库上，如图所示，HIVE 是将 SQL 通过客户端 SBK 、JDBC 协议传导下来，通过 SQL Parser 转换成 Query 计划进而根据源数据优化为物理层计划，最终将物理层计划翻译成 MapReduce，最终将整个 SQL 组合成MapReduce 一个大的 DEG ，下发到 MapReduce 的执行框架中。
可以很清晰的看出，HIVE 是架构在 MapReduce 基础上，将数据库的上半身平移到大数据技术栈的下半身。
9.back to SQL
用户视角——重新返回到数据库的SQL受众面广、易用性、既定行业标准。
系统视角—— SQL 对应 table，Schema 是非常密集的知识、质量控制的前置条件。能有效控制脏数据禁止进入系统，发现脏数据进入系统的时间越久，系统的污染面越大。数据安全是精细化的、数据粒度、SQL 的引入可以使基础算子组合出非常复制的运算，优化的可能，压缩。
DB MPP 的系统栈，最上面是应用层到 SQL，SQL 翻译成物理执行计划，最终对接存储引擎。
BD（分层）应用可以直接使用物理执行引擎也就是原语层，也可以执行使用表示层，也可以直接使用 SQL、ML、DSL 和其他相关的语言，所以DSL是建立在表示层、物理执行引擎之上。HIVE 是把 SQL 的上半身嫁接在BD技术栈的下半身。
三、引申
在某些场景下，DB 与 BD 的融合是相互学习，BD 优化 Schema 、逻辑执行计划、物理执行计划的优化。大量使用 Index 节省扫描时间，更精细化的列式存储格式以及引入更丰富的元数据。引入物化视图、存储过程等数据库的标准。
数据库领域也会借鉴大数据分布式计算的一些有效经验，比如抽象出表示层，有很多图数据库和传统数据库支持图运算、迭代运算，可以支持更复杂的运算，同时支持更复杂的数据结构、嵌套数据结构。
其他计算系统：TEZ、Dremel、Drill、Impala、Stinger、Hana、Percolator、Piccolo、Spark Fink。
