理解数据仓库中星型模型和雪花模型

在数据仓库的建设中,一般都会围绕着星型模型和雪花模型来设计表关系或者结构。下面我们先来理解这两种模型的概念。 星型模型 ​ 星型模是一种多维的数据关系,它由一个事实表和一组维表组成。每个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理,将多个维度集合到一个事实表,形成一个宽表。这也是我们在使用hive时,经常会看到一些大宽表的原因,大宽表一般都是事实表,包含了维度关联的主键和一些度量信息,而维度表则是事实表里面维度的具体信息,使用时候一般通过join来组合数据,相对来说对OLAP的分析比较方便。 雪花模型 ​ 当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小的事实表, »

Mongodb分片集群部署

Mongodb分片概括 分片在多台服务器上分布数据的方法, Mongodb使用分片来支持具有非常大的数据集和高吞吐量的操作的部署 具有大数据集和高吞吐量应用程序的数据库系统,可以挑战单台服务器的容量。 例如,高查询率可以耗尽服务器的cpu容量,工作集大小大于系统的RAM强制磁盘驱动器的I/O容量, 有两种方法来解决系统增长:垂直和水平缩放。 垂直缩放 涉及增加的单个服务器的容量,例如使用更强大的CPU,加入更多的RAM,或增加的存储空间量。可用技术中的限制可能限制单个机器对于给定工作负载足够强大。此外,基于云的提供商具有基于可用硬件配置的硬上限。因此,对于垂直缩放存在实际的最大值。 包括将系统数据和负载在多个服务器,添加额外的服务器,需要增加容量。虽然单个机器的总速度或容量可能不高,但是每个机器处理整个工作负载的子集, »

TCP粘包拆包及解决方法

粘包拆包问题是处于网络比较底层的问题,在数据链路层、网络层以及传输层都有可能发生。我们日常的网络应用开发大都在传输层进行,由于UDP有消息保护边界,不会发生粘包拆包问题,因此粘包拆包问题只发生在TCP协议中。 什么是粘包、拆包? 假设客户端向服务端连续发送了两个数据包,用packet1和packet2来表示,那么服务端收到的数据可以分为三种,现列举如下: 第一种情况:接收端正常收到两个数据包,即没有发生拆包和粘包的现象,此种情况不在本文的讨论范围内。 第二种情况:接收端只收到一个数据包,由于TCP是不会出现丢包的,所以这一个数据包中包含了发送端发送的两个数据包的信息,这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限,所以对于接收端来说很难处理。 第三种情况:这种情况有两种表现形式, »

Java线程的6种状态及切换

Java中线程的状态分为6种。 初始(NEW):新创建了一个线程对象,但还没有调用start()方法。 运行(RUNNABLE):Java线程中将就绪(ready)和运行中(running)两种状态笼统的称为“运行”。 线程对象创建后,其他线程(比如main线程)调用了该对象的start()方法。该状态的线程位于可运行线程池中,等待被线程调度选中,获取CPU的使用权,此时处于就绪状态(ready)。就绪状态的线程在获得CPU时间片后变为运行中状态(running) »

G1垃圾收集器详细介绍

1、G1垃圾收集器介绍 G1垃圾收集器针对具有大量内存的多处理器机器。它试图以很高的概率满足GC停顿时间目标,同时实现高吞吐量且几乎不需要配置。G1旨在在延迟和吞吐量之间提供最佳平衡,应用场景包括如下环境特征: 堆大小可达10 GB或更大,超过50%的Java堆占用实时数据。 随着时间的推移,对象分配速度和晋升(从新生代到老年代的晋升)速度会发生显著变化。 堆中大量的碎片。 可预测的时间停顿目标不超过几百毫秒,避免长时间垃圾收集停顿。 G1取了CMS,G1也是默认的收集器(JVM9、JVM10)。 G1收集器有很高的性能,并尝试通过以下几节所述的几种方式来满足停顿时间的目标。 2、启用G1收集器 »

Java新生代老年代的划分及回收算法

Java堆(Java Heap)是JVM所管理的最大内存区域,也是所有线程共享的一块区域,在JVM启动时创建。 此内存区域存放的都是对象的实例和数组。JVM规范中说到:”所有的对象实例以及数组都要在堆上分配”。 Java堆是垃圾回收器管理的主要区域,百分之九十九的垃圾回收发生在Java堆,另外百分之一发生在方法区,因此又称之为”GC堆”。根据JVM规范规定的内容,Java堆可以处于物理上不连续的内存空间中。 当前JVM对于堆的垃圾回收,采用分代收集的策略。根据堆中对象的存活周期将堆内存分为新生代和老年代。在新生代中,每次垃圾回收都有大批对象死去,只有少量存活。而老年代中存放的对象存活率高。 这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象, »

谈谈JDK堆外内存的创建和回收

堆外内存的优势在于IO操作,相比堆内存可以减少一次copy和gc的次数。下面通过源码去了解堆外内存的分配和回收。一般分配堆外内存通过ByteBuffer allocateDirect(int capacity)方法,其内部是通过如下构造函数来实现。 DirectByteBuffer(int cap) { super(-1, 0, cap, cap);// mark, pos, lim, cap boolean pa = VM.isDirectMemoryPageAligned(); int »

深入分析CMS垃圾收集器原理

前文已经讲过,CMS是老年代垃圾收集器,在收集过程中可以与用户线程并发操作。它可以与Serial收集器和Parallel New收集器搭配使用。CMS牺牲了系统的吞吐量来追求收集速度,适合追求垃圾收集速度的服务器上。 CMS相关参数 | 参数 | 类型 | 默认值 | 作用 | | ----------------------------------- | ------- | -------------------------------------------- | ------------------------------------------------------------ | | -XX:+UseConcMarkSweepGC | boolean | false | 老年代采用CMS收集器收集 | | –XX:ParallelGCThreads=n | int | (ncpus »

Reactor模型的Java NIO实现

实现Reactor模型可分为以下三种: 单线程模型 单Reactor多线程模型 主从Reactor多线程模型。 单线程模型 Reactor单线程模型,指的是所有的IO操作都在同一个线程上面完成,线程的职责如下: 作为NIO服务端,接收客户端的TCP连接; 作为NIO客户端,向服务端发起TCP连接; 读取通信对端的请求或者应答消息; 向通信对端发送消息请求或者应答消息。 由于Reactor模式使用的是异步非阻塞IO,所有的IO操作都不会导致阻塞,理论上一个线程可以独立处理所有IO相关的操作。从架构层面看,一个NIO线程确实可以完成其承担的职责。例如,通过Acceptor接收客户端的TCP连接请求消息,链路建立成功之后,通过Dispatch将对应的ByteBuffer派发到指定的Handler上进行消息解码。用户线程可以通过消息编码通过NIO线程将消息发送给客户端。 Server端 public »

Netty 系列之 Netty 高性能之道

1. 背景 1.1. 惊人的性能数据 最近一个圈内朋友通过私信告诉我,通过使用 Netty4 + Thrift 压缩二进制编解码技术,他们实现了 10W TPS(1K 的复杂 POJO 对象)的跨节点远程服务调用。相比于传统基于 Java 序列化 +BIO(同步阻塞 IO)的通信框架,性能提升了 »