❶ 国内做分布式数据库开发的现状如何
应该说，现在是国产分布式数据库发展的利好时期。在讨论发展前景前，首先要先看看分布式数据库的发展方向。
大家把传统关系型数据库称作oldsql，给人感觉要被淘汰似的。但其实数据量不是很大或者事务处理的场景夏，关系型数据库的还是占优的。
关系型数据库的主要问题在于：
性能瓶颈，
单一模型（关系模型），只适合OLTP
应对业务的灵活性不够，
弹性扩充能力不够，
两地三中心和双活等问题上不足。
随着互联网和手机的飞速发展，无论从用户规模、使用频率、还是场景多样性都使得这些问题浮出水面。其实Oracle在92年就开始尝试转向分布式，还当时引起了业界的巨大争论，最后失败。更何况过去CPU、内存、存储、带宽的高成本导致分布式数据库的性价比并不高，只能停留在学术阶段，限制了分布式的发展。
新分布式数据库首先是要避免和传统关系型数据库的竞争，这是明智的选择，能够轻装上阵。因此从几个方面入手，应对海量数据处理、分析、缓存、流式处理、开发模式等等。相对应列式，KV，Document等多种存储数据结构。
所有这些都被称为NoSQL数据库，放弃ACID和事务能力还换取性能。然而，NoSQL又收到了大量的批评反对意见，主要是说把数据库应该处理的问题交还给了开发是种发展的倒退。这些问题包括，索引、版本、SQL支持、事务支持等等。市场上超过90%的开发员都需要SQL，而且SQL也是非常有效和成熟。于是大家无论底层是什么存储结构又开始支持SQL，形成了NewSQL。
这里插一句题外话，在硅谷已经不再用SQL、NoSQL、NewSQL来划分数据库了。理由很简单，SQL是一种语言，从来没有SQL数据库的说法，自然也不应该有NoSQL数据库的说法。NewSQL数据库就更不合理，用的SQL并非什么“New“的新东西。所以专业上用关系型和非关系型数据库来划分，分布式数据库主要都是非关系型数据库。
回过头来看国内分布式数据库市场需求，中小企业不满足Mysql的性能，分库分表又很难搞，也不彻底；大型企业被Oracle等垄断支付高额成本，而且又不解决实际碰到的瓶颈问题。因此，用户都在寻找新的解决方案。小型用户、云计算的用
户、大型企业都需要对应的分布式数据库产品。
再加上国产自主和去IOE浪潮，更加推动了国产分布式数据库的发展利好。值得注意的是，数据库研发是个严肃的事情，没法短平快。
❷ 技术选型 - OLAP大数据技术哪家强
Lambda架构的核心理念是“流批一体化”，因为随着机器性能和数据框架的不断完善，用户其实不关心底层是如何运行的，批处理也好，流式处理也罢，能按照统一的模型返回结果就可以了，这就是Lambda架构诞生的原因。现在很多应用，例如Spark和Flink，都支持这种结构，也就是数据进入平台后，可以选择批处理运行，也可以选择流式处理运行，但不管怎样，一致性都是相同的。
Kylin
Kylin的主要特点是预计算，提前计算好各个cube，这样的优点是查询快速，秒级延迟；缺点也非常明显，灵活性不足，无法做一些 探索 式的，关联性的数据分析。
适合的场景也是比较固定的，场景清晰的地方。
ClickHouse
Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。
Clickhouse最大的特点首先是快 ，为了快采用了列式储存，列式储存更好的支持压缩，压缩后的数据传输量变小，所以更快；同时支持分片，支持分布式执行，支持SQL。
ClickHouse很轻量级，支持数据压缩和最终数据一致性，其数据量级在PB级别。
另外Clickhouse不是为关联分析而生，所以多表关联支持的不太好。
同样Clickhouse不能修改或者删除数据，仅能用于批量删除或修改。没有完整的事务支持，不支持二级索引等等，缺点也非常明显。
与Kylin相比ClickHouse更加的灵活，sql支持的更好，但是相比Kylin，ClickHouse不支持大并发，也就是不能很多访问同时在线。
总之ClickHouse用于在线数据分析，支持功能简单。CPU 利用率高，速度极快。最好的场景用于行为统计分析。
Hive
Hive这个工具，大家一定很熟悉，大数据仓库的首选工具。可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能。
主要功能是可以将sql语句转换为相对应的MapRece任务进行运行，这样可能处理海量的数据批量，
Hive与HDFS结合紧密，在大数据开始初期，提供一种直接使用sql就能访问HDFS的方案，摆脱了写MapRece任务的方式，极大的降低了大数据的门槛。
当然Hive的缺点非常明显，定义的是分钟级别的查询延迟，估计都是在比较理想的情况。 但是作为数据仓库的每日批量工具，的确是一个稳定合格的产品。
Presto
Presto极大的改进了Hive的查询速度，而且Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询，支持包括复杂查询、聚合、连接等等。
Presto没有使用MapRece，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。
Presto由于是基于内存的，缺点可能是多张大表关联操作时易引起内存溢出错误。
另外Presto不支持OLTP的场景，所以不要把Presto当做数据库来使用。
Presto相比ClickHouse优点主要是多表join效果好。相比ClickHouse的支持功能简单，场景支持单一，Presto支持复杂的查询，应用范围更广。
Impala
Impala是Cloudera 公司推出，提供对 HDFS、Hbase 数据的高性能、低延迟的交互式 SQL 查询功能。
Impala 使用 Hive的元数据, 完全在内存中计算。是CDH 平台首选的 PB 级大数据实时查询分析引擎。
Impala 的缺点也很明显，首先严重依赖Hive，而且稳定性也稍差，元数据需要单独的mysql/pgsql来存储，对数据源的支持比较少，很多nosql是不支持的。但是，估计是cloudera的国内市场推广做的不错，Impala在国内的市场不错。
SparkSQL
SparkSQL的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成，可以将结构化数据作为 Spark 的 RDD 进行查询。
SparkSQL后续不再受限于Hive，只是兼容Hive。
SparkSQL提供了sql访问和API访问的接口。
支持访问各式各样的数据源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。
Drill
Drill好像国内使用的很少，根据定义，Drill是一个低延迟的分布式海量数据交互式查询引擎，支持多种数据源，包括hadoop，NoSQL存储等等。
除了支持多种的数据源，Drill跟BI工具集成比较好。
Druid
Druid是专为海量数据集上的做高性能 OLAP而设计的数据存储和分析系统。
Druid 的架构是 Lambda 架构，分成实时层和批处理层。
Druid的核心设计结合了数据仓库，时间序列数据库和搜索系统的思想，以创建一个统一的系统，用于针对各种用例的实时分析。Druid将这三个系统中每个系统的关键特征合并到其接收层，存储格式，查询层和核心体系结构中。
目前 Druid 的去重都是非精确的，Druid 适合处理星型模型的数据，不支持关联操作。也不支持数据的更新。
Druid最大的优点还是支持实时与查询功能，解约了很多开发工作。
Ku
ku是一套完全独立的分布式存储引擎，很多设计概念上借鉴了HBase，但是又跟HBase不同，不需要HDFS，通过raft做数据复制；分片策略支持keyrange和hash等多种。
数据格式在parquet基础上做了些修改，支持二级索引，更像一个列式存储，而不是HBase schema-free的kv方式。
ku也是cloudera主导的项目，跟Impala结合比较好，通过impala可以支持update操作。
ku相对于原有parquet和ORC格式主要还是做增量更新的。
Hbase
Hbase使用的很广,更多的是作为一个KV数据库来使用，查询的速度很快。
Hawq
Hawq是一个Hadoop原生大规模并行SQL分析引擎，Hawq采用 MPP 架构，改进了针对 Hadoop 的基于成本的查询优化器。
除了能高效处理本身的内部数据，还可通过 PXF 访问 HDFS、Hive、HBase、JSON 等外部数据源。HAWQ全面兼容 SQL 标准，还可用 SQL 完成简单的数据挖掘和机器学习。无论是功能特性，还是性能表现，HAWQ 都比较适用于构建 Hadoop 分析型数据仓库应用。
❸ OLTP和OLAP有何区别
1、适用人员不同：OLTP主要供基层人员使用，进行一线业务操作。OLAP则是探索并挖掘数据价值，作为企业高层进行决策的参考。
2、面向内容不同：OLTP面向应用，OLAP面向主题；
4、数据特点不同：OLTP的数据特点是当前的、最新的、细节的, 二维的、分立的；而OLTP则是历史的, 聚集的, 多维的，集成的, 统一的；
5、存取能力不同：OLTP可以读/写数十条记录，而OLAP则可以读上百万条记录；
6、工作事件的复杂度不同：OLTP执行的是简单的事务，而OLAP执行的是复杂任务；
7、可承载用户数量不同：OLTP的可承载用户数量为上千个，而OLAP则是上百万个；
8、DB大小不同：OLTP的DB 大小为100GB，而OLAP则可以达到100TB；
9、执行时间要求不同：OLTP具有实时性，OLAP对时间的要求不严格。
(3)oltp列式存储好吗扩展阅读：
OLTP与OLAP的实际应用
OLAP工具是针对特定问题的联机数据访问与分析。它通过多维的方式对数据进行分析、查询和报表。维是人们观察数据的特定角度。
例如，一个企业在考虑产品的销售情况时，通常从时间、地区和产品的不同角度来深入观察产品的销售情况。这里的时间、地区和产品就是维。
这些维的不同组合和所考察的度量指标构成的多维数组则是OLAP分析的基础，可形式化表示为（维1，维2，……，维n，度量指标），如（地区、时间、产品、销售额）。
多维分析是指对以多维形式组织起来的数据采取切片（Slice）、切块（Dice）、钻取（Drill-down和Roll-up）、旋转（Pivot）等各种分析动作，以求剖析数据，使用户能从多个角度、多侧面地观察数据库中的数据，从而深入理解包含在数据中的信息。
应用OLTP，就必须重新定义OLTP在企业信息化体系结构中的地位。OLTP不再只是一套能处理订单的老式应用程序。对典型的OLTP系统处理的大规模数据流更新进行同时分析，这种情况很罕见，因为一般认为这不是OLTP的目的。
数据仓库更新固有的延迟阻碍着对最新数据的近实时分析。组织如果要对于数据的变化迅速作出反应，IT部门就必须让OLTP产生比以往更大的作用。
参考资料来源：网络-OLTP
参考资料来源：网络-联机分析处理
❹ Raid级别有哪些
RAID分为6个级别，不同的级别应满足应用程序的需求。
RAID 0
特点：磁盘在两个以上的磁盘驱动器中传送数据，与I/O同时运行，提高I/O性能。若n代表磁盘数量，则每个磁盘驱动器中有n分之一的数据。
应用：读写性能较高。但是，没有数据冗余。RAID 0本身仅适用于对数据访问具有容错能力的应用程序，以及能通过其它途径重新形成的数据。
RAID 1
特点：具有磁盘镜像，能够保护数据，读性能有所提高。RAID 1将数据在两个以上的磁盘中形成镜像，所以磁盘之间非常相似。RAID 1利用n+n的保护模式，从而需要两倍的驱动器数量。
应用：读操作密集型的OLTP和其它事务数据具有较高性能和可靠性。其它应用程序也能从RAID 1中获益，包括邮件、操作系统、应用程序文件和随机读取环境。
RAID 0+1
特点：对数据进行分条和镜像，使用n+n个驱动器，性能（分条）和可靠性（镜像）较高。一个磁盘驱动器发生故障，不会影响性能和可靠性，而在RAID 0中，驱动器故障会影响性能和可靠性。另外，磁盘分条技术可以提高性能。
应用：OLTP和I/O密集型应用程序需要很高的性能和可靠性。这些性能包括事务日志、日志文件、数据索引等，其成本以每个I/O的花费来计算，而不是以每个存储单元的花费计算。
RAID 1+0 (RAID 10)
特点：与RAID 0+1相似，对数据进行分条和镜像，使用n+n个驱动器，性能（分条）和可靠性（镜像）较高。不同之处在于RAID 10对所有磁盘进行集体分条，然后实现镜像功能。
应用：OLTP和I/O密集型应用程序需要很高的性能和可靠性。这些性能包括事务日志、日志文件、数据索引等，其成本以每个I/O的花费来计算，而不是以每个存储单元的花费计算。
RAID 3
特点：在字节层面进行奇偶校验和分条，具有独立的专用磁盘驱动器，根据所需的驱动器数量，利用n+1的方式存储校验信息。
应用：为视频图像、地球物理学、生命科学和其它顺序处理的应用程序提供良好性能。但是，RAID 3不能很好地适用于那些对多用户或I/O流进行并发操作的应用程序。
RAID 4
特点：与RAID 3相同，但是提供块级的奇偶校验保护模式。
应用：利用读写缓存，能很好地适应文件服务环境。
RAID 5
特点：利用n+1的模式提供磁盘分条和旋转奇偶校验保护模式，为多用户和I/O流并发操作提供良好的可靠性，具有很好的读操作性能。利用空闲的磁盘驱动器，重新构建（磁盘重建）数据，防止重建后数据再次遭破坏。
应用：减少所需的磁盘数量，提供良好的可靠性和读操作性能，如果不利用写入缓存，写操作性能受到一定影响。RAID 5适用的应用程序包括关系型数据、读密集型数据库表格、文件共享和Web应用程序。
RAID 6
特点：利用双奇偶校验模式，对磁盘进行分条和旋转校验，旨在降低磁盘重建过程对数据可靠性的影响，尤其是使用大容量光纤通道和SATA磁盘驱动器时更是如此。RAID 6和其它多驱动器校验模式的问题在于，在写入数据或重建出现故障的磁盘驱动器时，需要校验奇偶，这时性能会受到影响。
应用：总体来说，如果你想实现高性能的读写操作，就要利用小型磁盘驱动器，避免使用RAID 6。另一方面，如果你想存储大量数据，而存储点有可能需要重建，正确配置RAID 5和RAID 6，就能满足应用程序的需求。
❺ 数据库与数据仓库的本质差别是什么
数据库与数据仓库的本质差别如下：
1、逻辑层面/概念层面：数据库和数据仓库其实是一样的或者及其相似的，都是通过某个数据库软件，基于某种数据模型来组织、管理数据。但是，数据库通常更关注业务交易处理（OLTP），而数据仓库更关注数据分析层面（OLAP），由此产生的数据库模型上也会有很大的差异。
2、数据库通常追求交易的速度，交易完整性，数据的一致性等，在数据库模型上主要遵从范式模型（1NF，2NF，3NF等），从而尽可能减少数据冗余，保证引用完整性；而数据仓库强调数据分析的效率，复杂查询的速度，数据之间的相关性分析，所以在数据库模型上，数据仓库喜欢使用多维模型，从而提高数据分析的效率。
3、产品实现层面：数据库和数据仓库软件是有些不同的，数据库通常使用行式存储，如SAP ASE，Oracle, Microsoft SQL Server，而数据仓库倾向使用列式存储，如SAP IQ，SAP HANA。
❻ 数据库与数据仓库的本质区别是什么
1、存放值区别：
数据库只存放在当前值，数据仓库存放历史值；
2、数据变化区别：
数据库内数据是动态变化的，只要有业务发生，数据就会被更新，而数据仓库则是静态的历史数据，只能定期添加、刷新；
3、数据结构区别：
数据库中的数据结构比较复杂，有各种结构以适合业务处理系统的需要，而数据仓库中的数据结构则相对简单；
4、访问频率不同：
数据库中数据访问频率较高，但访问量较少，而数据仓库的访问频率低但访问量却很高；
5、目标人群区别：
数据库中数据的目标是面向业务处理人员的，为业务处理人员提供信息处理的支持，而数据仓库则是面向高层管理人员的，为其提供决策支持；