Swift
OC
#Web
vue、react
#Java
##基础
常见集合实现原理
多线程
队列
设计模式
##进阶
spring框架原理【IoC、DI、动态注入/静态代理】
mybatis框架原理
##高级：
微服务 SpringCloud、Dubble
RPC、大型复杂项目高可用、分布式
#MySQL
SQL 调优
索引设计
底层设计原理、btree
存储引擎 MyISAM vs InnoDB
分库分表
##大数据
##基础
Hadoop生态
hdfs、yarn、MapReduce
Linux基础
##进阶
spark、flink、kafka架构与原理
##高级：
数据治理、主句中台、数据仓库 可行性架构【技术+业务】方案
架构文档产出
#数据结构&算法
low：
middle：
high：
#架构师之路：
#CTO之路？
#算法、IOT、物联网？
联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。
当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。下表列出了OLTP与OLAP之间的比较。
diyblPic
区别OLTP还是OLAP
在数据库的设计中，就算完全掌握了以上的方法，但是，在不同的数据库类型上，使用起来也是大有差别的，这就需要设计者弄清楚自己的业务类型。如果没有正确地识别自己的业务类型，就盲目地开始设计数据库，或者是盲目地寻求优化方法，则往往是把OLAP的方法使用在OLTP上，或者是把OLTP的方法使用在OLAP上。如果这样，很可能会适得其反。
什么是OLTP
OLTP，也叫联机事务处理（Online Transaction Processing），表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。
注意：如果不特殊指定，本书中的高可用数据库都是指OLTP类型的数据库。
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
CPU出现瓶颈常表现在逻辑读总量与计算性函数或者是过程上，逻辑读总量等于单个语句的逻辑读乘以执行次数，如果单个语句执行速度虽然很快，但是执行次数非常多，那么，也可能会导致很大的逻辑读总量。设计的方法与优化的方法就是减少单个语句的逻辑读，或者是减少它们的执行次数。另外，一些计算型的函数，如自定义函数、decode等的频繁使用，也会消耗大量的CPU时间，造成系统的负载升高，正确的设计方法或者是优化方法，需要尽量避免计算过程，如保存计算结果到统计表就是一个好的方法。关于逻辑读与CPU处理能力的详细计算方法，在第12章还有详细介绍。
磁盘子系统在OLTP环境中，它的承载能力一般取决于它的IOPS处理能力，关于IOPS，在第2章中有详细介绍。因为在OLTP环境中，磁盘物理读一般都是db file sequential read，也就是单块读，但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其IOPS的时候，就会出现大的性能问题。另外，在第2章中，还会详细介绍存储子系统的IOPS承载力的计算问题。
OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术，Cache决定了很多语句不需要从磁盘子系统获得数据，所以，Web cache与Oracle data buffer对OLTP系统是很重要的。另外，在索引使用方面，语句越简单越好，这样执行计划也稳定，而且一定要使用绑定变量，减少语句解析，尽量减少表关联，尽量减少分布式事务，基本不使用分区技术、MV技术、并行技术及位图索引。因为并发量很高，批量更新时要分批快速提交，以避免阻塞的发生。
什么是OLAP
OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。关于磁盘子系统的带宽承载量计算，在第2章也将有详细介绍。
在OLAP系统中，常使用分区技术、并行技术。如分区技术可以使得一些大表的扫描变得很快（只扫描单个分区），而且方便管理。另外，如果分区结合并行的话，也可以使得整个表的扫描会变得很快。并行技术除了与分区技术结合外，在Oracle 10g中，与RAC结合实现多节点的同时扫描，效果也非常不错，可把一个任务，如select的全表扫描，平均地分派到多个RAC的节点上去。
在OLAP系统中，不需要使用绑定（BIND）变量，因为整个系统的执行量很小，分析时间对于执行时间来说，可以忽略，而且可避免出现错误的执行计划。但是OLAP中可以大量使用位图索引，物化视图，对于大的事务，尽量寻求速度上的优化，没有必要像OLTP要求快速提交，甚至要刻意减慢执行的速度。
分开设计与优化
以上描述了OLTP与OLAP的特点，在设计上要特别注意，如在高可用的OLTP环境中，不要盲目地把OLAP的技术拿过来用。如分区技术，假设不是大范围地使用分区关键字，而采用其它的字段作为where条件，那么，如果是本地索引，将不得不扫描多个索引，而性能变得更为低下。如果是全局索引，又失去分区的意义。
并行技术也是如此，一般在完成大型任务时才使用，如在实际生活中，翻译一本书，可以先安排多个人，每个人翻译不同的章节，这样可以提高翻译速度。如果只是翻译一页书，也去分配不同的人翻译不同的行，再组合起来，就没必要了，因为在分配工作的时间里，一个人或许早就翻译完了。
位图索引也是一样，如果用在OLTP环境中，很容易造成阻塞与死锁。但是，在OLAP环境中，可能会因为其特有的特性，提高OLAP的查询速度。MV也是基本一样，包括触发器等，在DML频繁的OLTP系统上，很容易成为瓶颈，甚至是Library Cache等待，而在OLAP环境上，则可能会因为使用恰当而提高查询速度。
作者：黄聪
出处：http://www.cnblogs.com/huangcong/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
分类: SQL学习
标签: OLAP OLTP 介绍
https://zhuanlan.zhihu.com/p/68228184
摘要： 本文主要谈了一些分布式计算框架方面的心得。
如果问 mapreduce 和 spark 什么关系，或者说有什么共同属性，你可能会回答他们都是大数据处理引擎。如果问 spark 与 tensorflow 呢，就可能有点迷糊，这俩关注的领域不太一样啊。但是再问 spark 与 MPI 呢？这个就更远了。虽然这样问多少有些不严谨，但是它们都有共同的一部分，这就是我们今天谈论的一个话题，一个比较大的话题：分布式计算框架。
不管是 mapreduce，还是 spark 亦或 tensorflow，它们都是利用分布式的能力，运行某些计算，解决一些特定的问题。从这个 level 讲，它们都定义了一种“分布式计算模型”，即提出了一种计算的方法，通过这种计算方法，就能够解决大量数据的分布式计算问题。它们的区别在于提出的分布式计算模型不同。Mapreduce 正如其名，是一个很基本的 map-reduce 式的计算模型（好像没说一样）。Spark 定义了一套 RDD 模型，本质上是一系列的 map/reduce 组成的一个 DAG 图。Tensorflow 的计算模型也是一张图，但是 tensorflow 的图比起 spark 来，显得更“复杂”一点。你需要为图中的每个节点和边作出定义。根据这些定义，可以指导 tensorflow 如何计算这张图。Tensorflow 的这种具体化的定义使它比较适合处理特定类型的的计算，对 tensorflow 来讲就是神经网络。而 spark 的 RDD 模型使它比较适合那种没有相互关联的的数据并行任务。那么有没有一种通用的、简单的、性能还高的分布式计算模型？我觉着挺难。通用往往意味着性能不能针对具体情形作出优化。而为专门任务写的分布式任务又做不到通用，当然也做不到简单。
插一句题外话，分布式计算模型有一块伴随的内容，就是调度。虽然不怎么受关注，但这是分布式计算引擎必备的东西。mapreduce 的调度是 yarn，spark 的调度有自己内嵌的调度器，tensorflow 也一样。MPI 呢？它的调度就是几乎没有调度，一切假设集群有资源，靠 ssh 把所有任务拉起来。调度实际上应当分为资源调度器和任务调度器。前者用于向一些资源管理者申请一些硬件资源，后者用于将计算图中的任务下发到这些远程资源进行计算，其实也就是所谓的两阶段调度。近年来有一些 TensorflowOnSpark 之类的项目。这类项目的本质实际上是用 spark 的资源调度，加上 tensorflow 的计算模型。
当我们写完一个单机程序，而面临数据量上的问题的时候，一个自然的想法就是，我能不能让它运行在分布式的环境中？如果能够不加改动或稍加改动就能让它分布式化，那就太好了。当然现实是比较残酷的。通常情况下，对于一个一般性的程序，用户需要自己手动编写它的分布式版本，利用比如 MPI 之类的框架，自己控制数据的分发、汇总，自己对任务的失败做容灾（通常没有容灾）。如果要处理的目标是恰好是对一批数据进行批量化处理，那么 可以用 mapreduce 或者 spark 预定义的 api。对于这一类任务，计算框架已经帮我们把业务之外的部分（脚手架代码）做好了。同样的，如果我们的任务是训练一个神经网络，那么用 tensorflow pytorch 之类的框架就好了。这段话的意思是，如果你要处理的问题已经有了对应框架，那么拿来用就好了。但是如果没有呢？除了自己实现之外有没有什么别的办法呢？
今天注意到一个项目，Ray，声称你只需要稍微修改一下你的代码，就能让它变为分布式的（实际上这个项目早就发布了，只是一直没有刻意关注它）。当然这个代码仅局限于 python，比如下面这个例子，
| Basic Python | Distributed with Ray |
+————————————————+—————————————————-+
| | |
| # Execute f serially. | # Execute f in parallel. |
| | |
| | @ray.remote |
| def f(): | def f(): |
| time.sleep(1) | time.sleep(1) |
| return 1 | return 1 |
| | |
| | |
| | ray.init() |
| results = [f() for i in range(4)] | results = ray.get([f.remote() for i in range(4)]) |
+————————————————+—————————————————-+
这么简单？这样笔者想到了 openmp（注意不是 openmpi）。来看看，
#include
#include”omp.h”
using namespace std;
void main() {
#pragma omp parallel for
for(int i = 0; i < 10; ++i) {
cout << “Test” << endl;
}
system(“pause”);
}
把头文件导入，添加一行预处理指令就可以了，这段代码立马变为并行执行。当然 openmp 不是分布式，只是借助编译器将代码中需要并行化的部分编译为多线程运行，本身还是一个进程，因此其并行度收到 CPU 线程数量所限。如果 CPU 是双线程，那只能 2 倍加速。在一些服务器上，CPU 可以是单核 32 线程，自然能够享受到 32 倍加速（被并行化的部分）。不过这些都不重要，在用户看来，Ray 的这个做法和 openmp 是不是有几分相似之处？你不需要做过多的代码改动，就能将代码变为分布式执行（当然 openmp 要更绝一点，因为对于不支持 openmp 的编译器它就是一行注释而已）。
那么 Ray 是怎么做到这一点的呢？其实 Ray 的做法说起来也比较简单，就是定义了一些 API，类似于 MPI 中的定义的通信原语。使用的时候，将这些 API “注入”到代码合适的位置，那么代码就变成了用户代码夹杂着一些 Ray 框架层的 API 调用，整个代码实际上就形成了一张计算图。接下来的事情就是等待 Ray 把这张计算图完成返回就好了。Ray 的论文给了个例子：
@ray.remote
def create_policy():
# Initialize the policy randomly.
return policy
@ray.remote(num_gpus=1)
class Simulator(object):
def init(self):
# Initialize the environment.
self.env = Environment()
def rollout(self, policy, num_steps):
observations = []
observation = self.env.current_state()
for _ in range(num_steps):
action = policy(observation)
observation = self.env.step(action)
observations.append(observation)
return observations
@ray.remote(num_gpus=2)
def update_policy(policy, *rollouts):
# Update the policy.
return policy
@ray.remote
def train_policy():
# Create a policy.
policy_id = create_policy.remote()
# Create 10 actors.
simulators = [Simulator.remote() for _ in range(10)]
# Do 100 steps of training.
for _ in range(100):
# Perform one rollout on each actor.
rollout_ids = [s.rollout.remote(policy_id)
for s in simulators]
# Update the policy with the rollouts.
policy_id = update_policy.remote(policy_id, *rollout_ids)
return ray.get(policy_id)
生成的计算图为
所以，用户要做的事情，就是在自己的代码里加入适当的 Ray API 调用，然后自己的代码就实际上变成了一张分布式计算图了。作为对比，我们再来看看 tensorflow 对图的定义，
import tensorflow as tf
x = tf.placeholder(tf.float32)
W = tf.Variable(1.0)
b = tf.Variable(1.0)
y = W * x + b
with tf.Session() as sess:
tf.global_variables_initializer().run() # Operation.run
fetch = y.eval(feed_dict={x: 3.0}) # Tensor.eval
print(fetch) # fetch = 1.0 * 3.0 + 1.0
‘’’
输出：
4.0
‘’’
可以看出，tensorflow 中是自己需要自己显式的、明确的定义出图的节点，placeholder Variable 等等（这些都是图节点的具体类型），而 Ray 中图是以一种隐式的方式定义的。我认为后者是一种更自然的方式，站在开发者的角度看问题，而前者更像是为了使用 tensorflow 把自己代码逻辑去适配这个轮子。
那么 ray 是不是就我们要寻找的那个即通用、又简单、还灵活的分布式计算框架呢？由于笔者没有太多的 ray 的使用经验，这个问题不太好说。从官方介绍来看，有限的几个 API 确实是足够简单的。仅靠这几个 API 能不能达成通用且灵活的目的还不好讲。本质上来说，Tensorflow 对图的定义也足够 General，但是它并不是一个通用的分布式计算框架。由于某些问题不在于框架，而在于问题本身的分布式化就存在困难，所以试图寻求一种通用分布式计算框架解决单机问题可能是个伪命题。
话扯远了。假设 ray 能够让我们以一种比较容易的方式分布式地执行程序，那么会怎么样呢？前不久 Databricks 开源了一个新项目，Koalas，试图以 RDD 的框架并行化 pandas。由于 pandas 的场景是数据分析，和 spark 面对的场景类似，两者的底层存储结构、概念也是很相似的，因此用 RDD 来分布式化 pandas 也是可行的。我想，如果 ray 足够简单好用，在 pandas 里加一些 ray 的 api 调用花费的时间精力可能会远远小于开发一套 koalas。但是在 pandas 里加 ray 就把 pandas 绑定到了 ray 上，即便单机也是这样，因为 ray 做不到像 openmp 那样如果支持，很好，不支持也不影响代码运行。
啰嗦这么多，其实就想从这么多引擎的细节中跳出来，思考一下到底什么是分布式计算框架，每种框架又是设计的，解决什么问题，有什么优缺点。最后拿大佬的一个观点结束本文。David Patterson 在演讲 “New Golden Age For Computer Architecture” 中提到，通用硬件越来越逼近极限，要想要达到更高的效率，我们需要设计面向领域的架构（Domain Specific Architectures）。这是一个计算架构层出不穷的时代，每种架构都是为了解决其面对的领域问题出现的，必然包含对其问题的特殊优化。通用性不是用户解决问题的出发点，而更多的是框架设计者的“一厢情愿”，用户关注的永远是领域问题。从这个意义上讲，面向领域的计算架构应该才是正确的方向。
声明：限于本人水平有限，文中陈述内容可能有误。欢迎批评指正。
本文作者：EMR
原文链接
更多技术干货敬请关注云栖社区知乎机构号：阿里云云栖社区 - 知乎
本文为云栖社区原创内容，未经允许不得转载。
发布于 2019-06-06
]]>###《程序员修炼之道：从小工到专家.pdf》
wuchong.me 微博推荐
###《后端架构师技术图谱》
[吴俊笔记本] https://wujun234.github.io/2020/01/07/05%20Java/00%20Java%20%E5%9F%BA%E7%A1%80/07%20%E5%B9%B6%E5%8F%91/4%20%E5%90%8C%E6%AD%A5%E5%99%A8/
https://github.com/xingshaocheng/architect-awesome
###吴军豆瓣
https://book.douban.com/subject_search?search_text=%E5%90%B4%E5%86%9B
浪潮之巅
数学之美
智能时代 : 大数据与智能革命重新定义未来
文明之光（第一册）
见识 : 商业的本质和人生的智慧
全球科技通史
格局 : 格局的大小决定成就的顶点
态度 : 吴军家书
硅谷之谜 : 《浪潮之巅》续集
大学之路（套装） : 陪女儿在美国选大学
###《数据中台：让数据用起来》
[https://mp.weixin.qq.com/s/vdODdbraouHq0MEJekhvAw]
###《数据中台建设五步法》
[https://mp.weixin.qq.com/s/S-76QzniFejCp4XtvGOEBA]
[本文内容节选自《数据中台架构——企业数据化最佳实践》（张旭，戴丽，訚赛华等著，电子工业出版社出版）]
使用 hexo g -d 命令直接发布
]]>1 | $ hexo new "My New Post" |
More info: Writing
1 | $ hexo server |
More info: Server
1 | $ hexo generate |
More info: Generating
1 | $ hexo deploy |
More info: Deployment
]]>