南大通用的GBase8s数据库如何实现高并发的OLTP业务系统的

Gbase8s 提供了Fan-in(扇入）和Fin-out（扇出）的并行机制，在数据库只有一个物理CPU的情况下，同时有多个客户端请求服务器时，扇入机制可以将多个客户端请求并行运行在一个VP上，从而实现成千上万的并发的客户请求，而不需要太多的物理CPU，而且不会随着并发用户数上升出现性能下滑的情况。

OLTP主要是事务处理方面的，而OLAP主要是用于数据分析。

一般的数据库通常都是OLTP，因为主要用于在线记录数据，离线进行数据分析。而如果要随时进行数据挖掘，或者提高数据分析的效率，让人们可以随时观察分析数据的情况之类的，就需要OLAP了。

现在一些大型的数据库软件都逐渐提供了部分OLAP的功能，但是这些的实际应用目前还不是很多。

OLTP（On-Line Transaction Processing，联机事务处理系统）也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。

具体体现为实时响应时间（Response Time），即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。

联机分析处理（OLAP）是共享多维信息的、针对特定问题的联机数据访问和分析的快速软件技术。联机分析处理（OLAP）系统是数据仓库系统最主要的应用，专门设计用于支持复杂的分析 *** 作，侧重对决策人员和高层管理人员的决策支持。

可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理，并且以一种直观而易懂的形式将查询结果提供给决策人员，以便他们准确掌握企业（公司）的经营状况，了解对象的需求，制定正确的方案。

在国外，不少软件厂商采取了发展其前端产品来弥补关系数据库管理系统支持的不足，力图统一分散的公共应用逻辑，在短时间内响应非数据处理专业人员的复杂查询要求。

1、首先你得搞清楚建设数仓的目的是什么

是偏向于整合各系统数据，为数据分析决策服务，还是偏向于快速的完成分析决策需求？

如果是前者，那么在数据仓库建模的时候一般会选择ER建模方法；

如果是后者，一般会选择维度建模方法。

ER建模：即实体关系建模，由数据仓库之父BIll Inmon提出，核心思想是从全企业的高度去设计三范式模型，用实体关系描述企业服务。主张的是自上而下的架构，将不同的OLTP数据集中到面向主题的数据仓库中。

维度建模：由Kimball提出，核心思想是从分析决策的需求出发构建模型。这种模型由事实表和维表组成，即星型模型和雪花模型。Kimball倡导自下而上的架构，可以针对独立部门建立数据集市，再递增的构建，汇总成数据仓库。

2、其次你得进行深入的业务调研和数据调研

业务调研：深入的业务调研能使你更加明确数仓建设的目的；同时也利于后续的建模设计，随着调研的开展，如何将实体业务抽象为数仓模型会更加明朗。

数据调研：各部门或各科室的数据现状了解，包括数据分类、数据存储方式、数据量、具体的数据内容等等。这对后续的主数据串联或者维度一致性处理等等都是必须的基础。

3、然后是数据仓库工具选型

传统型数据仓库：一般会选择第三方厂家的数据库和配套ETL工具。因为有第三方支持，相对有保障；但缺点也很明显，受约束以及成本较高。

NoSQL型数据仓库：一般是基于hadoop生态的数据仓库。hadoop生态已经非常强大，可以找到各种开源组件去支持数据仓库。缺点是需要招聘专门人士去摸索，并且相对会存在一些未知隐患。

4、最后是设计与实施

设计：包括数据架构中的数据层次划分以及具体的模型设计；也包括程序架构中的数据质量管理、元数据管理、调度管理等；

实施：规范化的项目管理实施，但同时也需记住一点，数据仓库不是一个项目，它是一个过程。

简单来说，储存引擎分为两大类。针对事务处理(OLTP)和针对分析型(OLAP)。

事务性处理优化架构的数据库通常面对用户，为具体的程序设计。在使用中往往磁盘的寻道时间会是负载的瓶颈。更具体细分的一哈，主要分为两大流派：

日志结构流派，具体的有BitCask、SSTables、LSM-tree等都属于此类;

原地更新流派，B-tree类型是这一类的代表。像我们熟悉的关系型数据库和非关系型数据库。mysql,mongodb等等。

分析型的不面向最终用户，一般是业务分析师使用。需要在短时间扫描百万条记录，磁盘带宽通常是瓶颈。数据库有c-store等。面向列储存是这种数据库工作负载比较流行的解决方案。

希望是你期望的答案~~~~~~~

ETLETL即数据抽取（Extract）、转换（Transform）、装载（Load）的过程

它是构建数据仓库的重要环节

数据仓库是面向主题的、集成的、稳定的且随时间不断变化的数据集合，用以支持经营管理中的决策制定过程

数据仓库系统中有可能存在着大量的噪声数据,引起的主要原因有：滥用缩写词、惯用语、数据输入错误、重复记录、丢失值、拼写变化等

即便是一个设计和规划良好的数据库系统，如果其中存在着大量的噪声数据，那么这个系统也是没有任何意义的，因为“垃圾进，垃圾出”（garbagein,garbageout），系统根本就不可能为决策分析系统提供任何支持

为了清除噪声数据，必须在数据库系统中进行数据清洗

目前有不少数据清洗研究和ETL研究，但是如何在ETL过程中进行有效的数据清洗并使这个过程可视化，此方面研究不多

联机事务处理OLTP联机分析处理(OLAP)的概念最早是由关系数据库之父E

F

Codd于1993年提出的，他同时提出了关于OLAP的12条准则

OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理(OLTP)明显区分开来

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-linetransactionprocessing）、联机分析处理OLAP（On-LineAnalyticalProcessing）

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易

OLAP是数据仓库系统的主要应用，支持复杂的分析 *** 作，侧重决策支持，并且提供直观易懂的查询结果

OLAP是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术

Hbase的优缺点

1 列的可以动态增加，并且列为空就不存储数据,节省存储空间

2 Hbase自动切分数据，使得数据存储自动具有水平scalability

3 Hbase可以提供高并发读写 *** 作的支持

Hbase的缺点：

1 不能支持条件查询，只支持按照Row key来查询

2 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉

四补充

1数据类型，HBase只有简单的字符类型，所有的类型都是交由用户自己处理，它只保存字符串。而关系数据库有丰富的类型和存储方式。

2数据 *** 作：HBase只有很简单的插入、查询、删除、清空等 *** 作，表和表之间是分离的，没有复杂的表和表之间的关系，而传统数据库通常有各式各样的函数和连接 *** 作。

3存储模式：HBase是基于列存储的，每个列族都由几个文件保存，不同的列族的文件时分离的。而传统的关系型数据库是基于表格结构和行模式保存的

4数据维护，HBase的更新 *** 作不应该叫更新，它实际上是插入了新的数据，而传统数据库是替换修改

5可伸缩性，Hbase这类分布式数据库就是为了这个目的而开发出来的，所以它能够轻松增加或减少硬件的数量，并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能

WPS成功上市代表了信息化企业软件国产化的趋势。在雷涛看来，WPS不是简单复制后替代Windows office，而是找到了下一代产品需求。

以往无论是运营商还是银行核心系统，大架构都垄断在西方的 IOE（IBM、Oracle、EMC）这三座大山里。直到2008年阿里提出去“IOE”运动，开始助推信息化软件国产化浪潮。

天云数据就是其中最早一批入场者。2010年为了建立中国完整的云计算产业链，中国宽带之父田溯宁投资建设云基地，天云数据便由此孵化，初备雏形。

2015年，雷涛带领创始团队们正式成立天云数据，率先切入金融领域。天云提供了国内领先的国产HTAP数据库Hubble，完成了“去IOE”中最困难的部分，替代金融A类核心系统惯用的西方IOE架构，在银行的联机事务中解决A类核心系统减负问题。此外，为了降低AI使用门槛，天云数据还推出AI PaaS平台MaximAI，逐步将数据价值逐渐扩展到能源、医药、军事等其它行业。

目前天云数据有70多家行业内大企业客户，单笔合同200-500万，纯软件年营收过亿。

融资方面，天云数据2018年曾获得曦域资本、华映资本B轮1亿人民币投资。

作为行业老兵，雷涛在北美跨国公司有20多年的技术管理经验， 2005年便入席SNIA存储工业协会中国区技术委员会联合主席，CCF中国计算机学会大数据专委会委员。

2011年在云基地时期，雷涛和创始团队通过BDP大数据平台负责了众多运营商业务，如联通的数据魔方、移动总部、南方基地等，2015年天云数据正式独立后，雷涛为了避免同业竞争，选择先聚焦在金融领域。

“天云数据的目标是替代 Oracle 和 SAS ”。云基地时期的积累让天云数据一开始就有高起点，首单就接下了光大银行的核心系统——OLTP线交易系统。比如银行能在全国所有营业厅实时实现OOTD交易，实时查询存钱取钱数额，整个环节涉及的技术都是天云数据早期对Oracle的一些替代。

但之后在多次的项目 *** 作过程中雷涛发现，在几百万条交易规格的强一致性下，数据的移动性、计算框架的变化、联机事务同时要做大规模并行计算，这对计算场景的通用性、即时性和全量数据要求极高，传统 Oracle架构根本无法适应。

“在Oracle架构之上，还需要升级满足新需求”。

于是天云数据自主研发HTAP国产分布式数据库Hubble。与传统 IT 架构处理失误需要联机分析和分开处理不同，HTAP 数据库能够在一份数据上同时支撑业务系统运行并做 OLAP 场景，避免在线与离线数据库之间大量的数据交互，为系统减负。

HTAP国产分布式数据库Hubble替代了Oracle一体机,核心表2000余张80T左右、400亿条交易数据、提供56只服务应用交易、满足500个用户并发、500ms交易服务响应、每天在线交易量超200万、占整个银行核心交易量的10%，让银行面向柜面系统可提供78小时A类实时核心交易，面向手机网银系统可提供724小时A类实时核心交易。

从集中式Oracle切换到分布式HTAP，也解决了数据库扩展性的问题。比如天云数据让光大银行解决了 历史 数据查询问题，以往 历史 查询只能查到2年前，但在分布式技术上线后，可以查询15年前所有交易数据，同时让银行柜面系统以及手机APP可以无数人同时查询。

而在BI逐步转向AI的过程中，复杂的商业流程经算法重构。过去要把数据拿到SAS平台先分析，一层一层地把数据提出来搭建。但现在通过分布式技术，流程趋于扁平化，可以实现毫秒级的服务响应。

天云数据一开始就撬动的是行业头部资源。目前天云数据有光大银行、兴业银行、中信银行、中泰证券、中国石油、国家统计局等70余家行业内大企业客户，分布在金融、能源、医药、政府军事等领域，单笔合同级别超百万

针对每个垂直行业，天云数据都会成立一个子公司来专注赛道。目前天云数据有160人，技术人员超六成。

在雷涛看来，如果一年600个项目，全是5万、15万等碎片化的订单，公司总是重复满足初级客户的简单需求，技术很难沉淀和深入。“在当下成长阶段，打造产品需要在用户想要什么和你想做什么中找到平衡”。

对于雷涛而言，专注头部大B发展有两大发展潜力。一方面，大B拥有机器学习的普遍能力和实验室，更容易接受新产品。另一方面，天云数据交付产品和交付服务的同时也在转移大B客户的数据价值。

“AI本身是一个知识生产过程，它能把大型企业规则、流程的经验价值快速地抽样出来进行复制，赋能行业内其它客户甚至类似的其它行业。”

但在头部客户更定制化、个性化的情况下，天云数据是否失去了很强的复制能力？

雷涛解释到，虽然每个企业要求不尽相同，但都在不大的池子里找数据库。企业从海量数据中对数据进行迁徙、清洗、去重，可以去找合适的AI方法让它产生业务的价值，此过程具有通用性。

谈到核心壁垒，雷涛认为天云数据壁垒就是数据的复制价值。

壁垒的构建可分为两个阶段。第一个阶段是前沿 科技 本身的壁垒，比的是效率和产品核心价值，谁能够扎得深和更好的交付，谁就能拔得头筹。而作为国内最早研发大数据和人工智能的团队，天云数据有一定的技术先发优势。

第二个阶段是推理端的服务。数据资源的价值需要通过机器学习进行提炼，形成知识，进而封装成推理服务服务于行业。比如某保险公司20年长周期发生的重疾赔付定价上学习出来的特征和内容能够快速地移植到保险行业，而头部大企业客户给天云数据带来很优质的训练数据库。

未来AI将引爆万亿级大市场，但目前渗透率不到1%，这给各企业留有众多机会和想象空间。但无论哪种圈地方式，最终比的是速度、服务的稳定性以及产品化的能力。

以上就是关于南大通用的GBase8s数据库如何实现高并发的OLTP业务系统的全部的内容，包括:南大通用的GBase8s数据库如何实现高并发的OLTP业务系统的、OLTP和OLAP有何区别、请问数据仓库都用什么建立等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！