批处理会将源业务系统中的数据通过数据抽取工具（例如Sqoop）将数据抽取到HDFS中，这个过程可以利用MapReduce、Spark、Flink技能对数据进行ETL洗濯处理，也可以直接将数据抽取到Hive数仓中，一样平常可以将构造化的数据直接抽取到Hive数据仓库中，然后利用HiveSQL或者SparkSQL进行业务指标剖析，如果涉及到的剖析业务非常繁芜，可以利用Hive的自定义函数或者Spark、Flink进行繁芜剖析，这便是我们常日说的数据指标剖析。剖析之后的结果可以保存到Hive、HBase、MySQL、Redis等，供后续查询利用。一样平常在数仓构建中，如果指标存入Hive中，我们可以利用Sqoop工具将结果导入到关系型数据库中供后续查询。HBase中更善于存储原子性非聚合查询数据，如果有大量结果数据后期不须要聚合查询，也可以通过业务剖析处理考虑存入HBase中。对付一些查询需求结果反馈非常快的场景可以考虑将结果存入Redis中。
对付大多数企业构建数仓之后，会将结果存入到Hive中的DM层中。DM层数据存入的是与业务强干系的报表数据，DM层数据是由数仓中DWS层主题宽表聚合统计得到，这种报表层设计适宜查询固定的场景。对付一些查询需求多变场景，我们也可以利用impala来直接将主题宽表数据基于内存进行交互式查询，对web或者数据剖析做到交互式返回结果，利用impala对内存开销非常大。还有其余一种办法是利用Kylin进行估量算，将结果提前打算好存入Hbase中，以供后续交互式查询结果，Kylin是利用空间获取韶光的一种办法，预先将各种维度组合对应的度量打算出来存入HBase,用户写SQL交互式查询的是HBase中估量算好的结果数据。末了将数据剖析结果可以直接对web以接口做事供应利用或者公司内部利用可视化工具展示利用。
以上无论批处理过程还是流处理过程，利用到的技能险些离不开Hadoop生态圈。
ClickHouse是一个开源的，用于联机剖析（OLAP）的列式数据库管理系统（DBMS-database manager system）, 它是面向列的，并许可利用SQL查询，实时天生剖析报告。ClickHouse最初是一款名为Yandex.Metrica的产品，紧张用于WEB流量剖析。ClickHouse的全称是Click Stream，Data WareHouse，简称ClickHouse。
ClickHouse不是一个单一的数据库,它许可在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动做事器。ClickHouse同时支持列式存储和数据压缩，这是对付一款高性能数据库来说是必不可少的特性。一个非常盛行的不雅观点认为，如果你想让查询变得更快，最大略且有效的方法是减少数据扫描范围和数据传输时的大小，而列式存储和数据压缩就可以帮助我们实现上述两点，列式存储和数据压缩常日是伴生的，由于一样平常来说列式存储是数据压缩的条件。
二、OLAP场景的特色绝大多数是读要求。数据以相称大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。已添加到数据库的数据不能修正。对付读取，从数据库中提取相称多的行，但只提取列的一小部分。宽表，即每个表包含着大量的列。查询相对较少(常日每台做事器每秒查询数百次或更少)。对付大略查询，许可延迟大约50毫秒。列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)。处理单个查询时须要高吞吐量(每台做事器每秒可达数十亿行)。事务不是必须的。对数据同等性哀求低。有副本情形下，写入一个即可，后台自动同步。每个查询有一个大表。除了他以外，其他的都很小。查询结果明显小于源数据。换句话说，数据经由过滤或聚合，因此结果适宜于单个做事器的RAM中。通过以上OLAP场景剖析特点很随意马虎可以看出，OLAP场景与其他常日业务场景(例如,OLTP或K/V)有很大的不同， 因此想要利用OLTP或Key-Value数据库去高效的处理剖析查询场景，并不是非常完美的适用方案。例如，利用OLAP数据库去处理剖析要求常日要优于利用MongoDB或Redis去处理剖析要求。
三、ClickHouse特性1、完备的DBMS功能ClickHouse是一个数据库管理系统，而不仅是一个数据库，作为数据库管理系统具备完备的管理功能：
DDL(Data Definition Language-数据定义措辞)：可以动态地创建、修正或删除数据库、表和视图，而无须重启做事。DML(Data Manipulation Language)：可以动态查询、插入、修正或删除数据。分布式管理：供应集群模式，能够自动管理多个数据库节点。权限掌握：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。数据备份与规复：供应了数据备份导出与导入规复机制，知足生产环境的哀求。2、列式存储目前大数据存储有两种方案可以选择，行式存储(Row-Based)和列式存储(Column-Based)。
行式存储在数据写入和修正上具有上风
行存储的写入是一次完成的，如果这种写入建立在操作系统的文件系统上，可以担保写入过程的成功或者失落败，可以担保数据的完全性。列式存储须要把一行记录拆分成单列保存，写入次数明显比行存储多(由于磁头调度次数多，而磁头调度是须要韶光的，一样平常在1ms~10ms)，再加上磁头须要在盘片上移动和定位花费的韶光，实际花费更大。
数据修正实际上也是一次写入过程，不同的是，数据修恰是对磁盘上的记录做删除标记。行存储是在指定位置写入一次，列存储是将磁盘定位到多个列上分别写入，这个过程仍是行存储的列数倍。
以是，行式存储在数据写入和修正上具有很大上风。
列式存储在数据读取和解析、剖析数据上具有上风。数据读取时，行存储常日将一行数据完备读出，如果只须要个中几列数据的情形，就会存在冗余列，出于缩短处理韶光的考量，肃清冗余列的过程常日是在内存中进行的。列存储每次读取的数据是凑集的一段或者全部，不存在冗余性问题。
列式存储中的每一列数据类型是相同的，不存在二义性问题，例如，某列类型为整型int,那么它的数据凑集一定是整型数据，这种情形使数据解析变得十分随意马虎。比较之下，行存储则要繁芜得多，由于在一行记录中保存了多种类型的数据，数据解析须要在多种数据类型之间频繁转换，这个操作很花费CPU，增加理解析的韶光。
以是，列式存储在数据读取和解析数据做数据剖析上更具上风。
综上所述，行存储的写入是一次性完成，花费的韶光比列存储少，并且能够担保数据的完全性，缺陷是数据读取过程中会产生冗余数据，如果只有少量数据，此影响可以忽略，数量大可能会影响到数据的处理效率。列存储在写入效率、担保数据完全性上都不如行存储，它的上风是在读取过程，不会产生冗余数据，这对数据完全性哀求不高的大数据处理领域比较主要。一样平常来说一个OLAP类型的查询可能须要访问几百万或者几十亿行的数据，但是OLAP剖析时只是获取少数的列，对付这种场景列式数据库只须要读取对应的列即可，行式数据库须要读取所有的数据列，因此这种场景更适宜列式数据库，可以大大提高OLAP数据剖析的效率。ClickHouse便是一款利用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会由不同的文件分别保存，在对OLAP场景剖析时，效率很高。
3、数据压缩为了使数据在传输上更小，处理起来更快，可以对数据进行压缩，ClickHouse默认利用LZ4算法压缩，数据总体压缩比可达8:1。
ClickHouse采取列式存储，列式存储相对付行式存储另一个上风便是对数据压缩的友好性。例如：有两个字符串“ABCDE”，“BCD”，现在对它们进行压缩：
压缩前：ABCDE_BCD 压缩后：ABCDE_(5,3)
通过以上案例可以看到，压缩的实质是按照一定步长对数据进行匹配扫描，当创造重复部分的时候就进行编码转换。例如：(5,3)代表从下划线往前数5个字节，会匹配上3个字节长度的重复项，即:“BCD”。当然，真实的压缩算法比以上举例更繁芜，但压缩的实质便是如此，数据中重复性项越多，则压缩率越高，压缩率越高，则数据体量越小，而数据体量越小，则数据在网络中的传输越快，对网络带宽和磁盘IO的压力也就越小。
列式存储中同一个列的数据由于它们拥有相同的数据类型和现实语义，可能具备重复项的可能性更高，更利于数据的压缩。以是ClickHouse在数据压缩上比例很大。
4、向量化实行引擎在打算机系统的体系构造中，存储系统是一种层次构造，范例做事器打算机的存储层次构造如上图，上图表述了CPU、CPU三级缓存、内存、磁盘数据容量与数据读取速率比拟，我们可以看出存储媒介间隔CPU越近，则访问数据的速率越快。
把稳：缓存便是数据交流的缓冲区，缓存每每都是RAM(断电即掉的非永久储存),它们的浸染便是帮助硬件更快地相应。CPU缓存的定义为CPU与内存之间的临时数据交流器，它的涌现是为理解决CPU运行处理速率与内存读写速率不匹配的抵牾，CPU缓存一样平常直接跟CPU芯片集成或位于主板总线互连的独立芯片上，现阶段的CPU缓存一样平常直接集成在CPU上。CPU每每须要重复处理相同的数据、重复实行相同的指令，如果这部分数据、指令，CPU能在CPU缓存中找到，CPU就不须要从内存或硬盘中再读取数据、指令，从而减少了整机的相应韶光。
由上图可知，从内存读取数据速率比磁盘读取数据速率要快1000倍，从CPU缓存中读取数据的速率比从内存中读取数据的速率最快要快100倍，从CPU寄存器中读取数据的速率为300ps(1000ps 皮秒 = 1ns)，比CPU缓存要快3倍还多。从寄存器中访问数据的速率，是从内存访问数据速率的300倍，是从磁盘中访问数据速率的30万倍。
如果能从CPU寄存器中访问数据对程序的性能提升意义非凡，向量化实行便是在寄存器层面操作数据，为上层运用程序的性能带来了指数级的提升。
作甚向量化实行？向量化实行，可以大略地看作一项肃清程序中循环的优化。这里用一个形象的例子比喻。小胡经营了一家果汁店，虽然店里的鲜榨苹果汁深受大家喜好，但客户总是抱怨制作果汁的速率太慢。小胡的店里只有一台榨汁机，每次他都会从篮子里拿出一个苹果，放到榨汁机内等待出汁。如果有8个客户，每个客户都点了一杯苹果汁，那么小髯毛要重复循环8次上述的榨汁流程，才能榨出8杯苹果汁。如果制作一杯果汁须要5分钟，那么全部制作完毕则须要40分钟。为了提升果汁的制作速率，小胡想出了一个办法。他将榨汁机的数量从1台增加到了8台，这么一来，他就可以从篮子里一次性拿出8个苹果，分别放入8台榨汁机同时榨汁。此时，小胡只须要5分钟就能够制作出8杯苹果汁。为了制作n杯果汁，非向量化实行的办法是用1台榨汁机重复循环制作n次，而向量化实行的办法是用n台榨汁机只实行1次。
为了实现向量化实行，须要利用CPU的SIMD指令，SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据。当代打算机系统观点中，它是通过数据并行以提高性能的一种实现办法(其他的还有指令级并行和线程级并行)，它的事理是在CPU寄存器层面实现数据的并行操作。
ClickHouse列式存储除了降落IO和存储的压力之外，还为向量化实行做好了铺垫，除了读取磁盘速率快之外，ClickHouse还利用SSE4.2指令集实现向量化实行，为处理数据提升很大效率。
5、关系模型与标准SQL查询比较HBase和Redis这类NoSQL数据库，ClickHouse利用关系模型描述数据并供应了传统数据库的观点(数据库、表、视图和函数等)。ClickHouse完备利用SQL作为查询措辞(支持GROUP BY、ORDER BY、JOIN、IN等大部分标准SQL)，ClickHouse供应了标准协议的SQL查询接口，可以与第三方剖析可视化系统无缝集成对接。在SQL解析方面，ClickHouse是大小写敏感，SELECT a 和 SELECT A所代表的语义不同。
6、多样化的表引擎与MySQL类似，ClickHouse也将存储部分进行了抽象，把存储引擎作为一层独立的接口。ClickHouse拥有各种表引擎，每种表引擎决定不同的数据存储办法。个中每一种表引擎都有着各自的特点，用户可以根据实际业务场景的哀求，选择得当的表引擎利用。将表引擎独立设计的好处是通过特定的表引擎支撑特定的场景，十分灵巧，对付大略的场景，可直策应用大略的引擎降落本钱，而繁芜的场景也有得当的选择。
7、多线程与分布式向量化实行是通过数据级并行的办法提升了性能，多线程处理是通过线程级并行的办法实现了性能的提升。比较基于底层硬件实现的向量化实行SIMD，线程级并行常日由更高层次的软件层面掌握，目前市情上的做事器都支持多核心多线程处理能力。由于SIMD不适宜用于带有较多分支判断的场景，ClickHouse也大量利用了多线程技能以实现提速，以此和向量化实行形成互补。ClickHouse在数据存取方面，既支持分区(纵向扩展，利用多线程事理 )，也支持分片(横向扩展，利用分布式事理)，可以说是将多线程和分布式的技能运用到了极致。
8、多主架构
HDFS、Spark、HBase和Elasticsearch这类分布式系统，都采取了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。而ClickHouse则采取Multi-Master多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。这种多主的架构有许多上风，例如对等的角色使系统架构变得更加大略，不用再区分主控节点、数据节点和打算节点，集群中的所有节点功能相同。以是它天然规避了单点故障的问题，非常适宜用于多数据中央、异地多活的场景。
9、交互式查询Hive,SparkSQL,HBase等都支持海量数据的查询场景，都拥有分布式架构，都支持列存、数据分片、打算下推等特性。ClickHouse在设计上吸取了以上技能的上风，例如：Hive、SparkSQL无法担保90%以上的查询在秒级内相应，在大数据量繁芜查询下须要至少分钟级的相应韶光，而HBase可以对海量数据做到交互式查询，由于不支持标准SQL在对数据做OLAP聚合剖析时显得捉襟见肘。ClickHouse吸取以上各个技能的上风，在繁芜查询的场景下，它也能够做到极快相应，且无须对数据进行任何预处理加工。
10、数据分片与分布式查询数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，办理存储和查询瓶颈的有效手段，是一种分治思想的表示。ClickHouse支持分片，而分片则依赖集群。每个集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个做事节点。分片的数量上限取决于节点数量（1个分片只能对应1个做事节点）。
ClickHouse拥有高度自动化的分片功能。ClickHouse供应了本地表 （Local Table）与分布式表（Distributed Table）的观点。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其浸染类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。
这种设计类似数据库的分库和分表，十分灵巧。例如在业务系统上线的初期，数据体量并不高，此时数据表并不须要多个分片。以是利用单个节点确当地表（单个数据分片）即可知足业务需求，待到业务增长、数据量增大的时候，再通过新增数据分片的办法分流数据，并通过分布式表实现分布式查询。
