分布式数据库或成为新增量

news/2024/11/30 3:50:04/

以下文章来源于华泰证券:http://www.microbell.com/repinfodetail_775272.html

作者:谢春生、郭雅丽

数据库行业螺旋上升,分布式数据库或成新增量

纵观计算机行业发展历程,计算载体经历了从大型机到小型机,再到分布式数据中心的演变。在数据库领域,小型机时代促成了 Oracle 等关系型数据库兴起,分布式架构时代 AWS、Snowflake 等分布式数据库兴起。在计算载体变革的过程中,数据库市场往往不是简单的代替旧市场,而是不断创造新的增量。据 Gartner,2018 年全球数据库管理系统市场规模达 461 亿美元, 预计于 2024 年整体市场规模达千亿美元,但与此同时关系型数据库市场规模增长渐趋平缓。伴随着分布式计算架构的兴起,分布式数据库或成为数据库市场新的增量,以史为鉴,该领域也有望诞生新的龙头。

数据、计算场景变革推动分布式数据库时代到来

随着智能终端的普及及云计算的兴起,据 IDC 全球数据产生量从 2010 年的1.2ZB 上升至 2018 年的 33ZB。另一方面,数据类型不断丰富,非结构化数据逐渐增加。应运而生的分布式数据库能够较好的满足大数据分析的需  求。而随着 Snowflake、Databricks 等厂商推出分布式数据库产品满足云计算、大数据的使用需求,分布式数据库时代到来的趋势逐步确定。

开源或商业闭源模式均导向企业级服务,自研内核具有稳定性优势

数据库在 IT 架构中向下对接操作系统,直接调度硬件,向上则需支撑大量不同形态的上层应用。与应用软件相比,数据库作为基础软件更加注重稳定性。开源与商业闭源模式的商业策略,最终均需要导向优质的产品及企业级服务,为客户创造价值,获得客户及行业认可。另一方面,自研内核有助于数据库厂商从源头解决问题,并且能掌握迭代控制权,同样是影响稳定性的重要因素,因此自研内核厂商有望凭借稳定性在企业级服务市场获得优势。

数据库的六大评判维度

我们认为评判数据库有六大维度,除了上文提到的商业架构、内核基础外,还包括品牌基因、技术架构、商业落地、人才体系。其中品牌基因影响技术路线、侧重领域、应用场景等。技术架构方面,分析型、大数据场景驱动分布式数据库发展。商业落地方面,金融、电信等的落地场景由于具备高并发、宕机代价高的特点,因此在这一领域的商业落地案例一定程度上能够说明数据库产品稳定性高。人才体系则体现了数据库厂商的生态建设成效。

 

风险提示:市场竞争加剧,芯片及 AI 行业发展导致 IT 投资倾斜。

 

数据库行业:行业螺旋上升,分布式数据库时代到来

数据库发展需要关注增量市场,分布式数据库或成新机遇

数据库的发展与计算载体紧密相关。数据库是计算机行业的基础核心软件,所有应用软件的运行和数据处理都要与其进行数据交互。数据库的开发难度,不仅体现在与其他基础器件的适配,更在于如何实现对数据高效、稳定、持续的管理。从数据库的发展历程来看, 计算架构的变化,计算载体的变化、计算场景的变化,以及计算数据格式的变化都对数据库的发展带来的一定的影响。或者说,在以上计算环境变化下,其需要的数据库类型也发生了变化。

从计算载体来看,数据的计算从原来的大型机、到小型机、个人电脑 PC、互联网、移动互联网、云计算,以及未来更多终端的物联网智能终端。计算的载体更加多样化。

从计算场景来看,数据计算也从单独的单机计算,到互联网多群体交互的联网计算和云计算,以及万物互联的高并发、低时延的物联网计算。

从计算架构来看,传统的 IT 架构也正逐步向云架构迁移。我们也经历了从 C-S 架构到 B-S 架构,而目前的云原生、分布式计算架构正对传统计算架构带来深刻变革。而新的计算架构也对计算的基础软件(操作系统、数据库、芯片等)提出更高的需求。

图表1: 计算的变化

在以上计算环境的变化下,我们看到,联网的数据也在发生深刻变化。

数据的大小。目前联网数据量也在高速增长。通信技术的发展带动从 2G 到 3G、4G、5G 的演进,每代通信技术之间,联网的数据规模也呈现(几个)数量级的增加。对大容量、高性能计算提出更高要求。

数据的类型。计算场景的演变,我们对数据的定义也在发生变化。图片、语音、视频等非结构化数据成为增量数据的主要类型。联网的数据类型也逐步从原来的结构化数据到非结构化数据演变,这就对计算的并发性提出了更高的要求。

数据的快慢。对数据的高速计算是计算机一直以来的追求。但原有的 IT 架构下,计算速度的提升存在一定的物理条件限制。经典的 IT 架构已经存在了几十年的历史,当时的 IT 架构并没有完全考虑到目前计算场景的变化。因此,新的计算场景下,对数据高速计算的追求,需要我们从底层基础软件的变革开始。我们看到无论芯片、操作系统还是数据库,都在经历深刻变革。

图表2: 数据的变化

在以上计算和数据多个维度变化的情况下,我们认为,数据库行业也正在经历历史演进的深刻变革。在传统计算环境和数据类型方面,传统数据库依然发挥比较重要的作用。但在面向未来新的计算场景方面,我们需要的可能是新型的数据库产品。这种新型数据库,是计算架构迁移、计算载体演进以及计算环境变化之后的产物;同时,也是数据规模大幅增加,数据结构变化之后所需要的产品。

图表3: 数据库发展

全球关系型数据库市场增速渐趋平稳。数据库是对数据的管理,数据库诞生于上世纪 60 年代,传统的数据库产品面临的是以事务型、交易处理为主的任务,事务支持性能较好的关系型数据库如 Oracle、DB2 迅速兴起。而近年来,传统的关系型数据库市场增长渐趋平稳,据Gartner,2018 年全球数据库管理系统(DBMS)市场规模达 461 亿美元,同比增长 18.4%,增速达到近十年峰值。但关系型数据库市场增长渐趋平缓,据 T4.ai 预测,全球关系型数据库市场规模 2018-2022E CAGR 为 6%,较 2012-2017 的 11%或将有所下降。

数据量上升催生分析需求,数据库市场新机遇显现。随着智能移动手机的普及及云计算的兴起,全球数据产生量不断上升,从 2010 年的 1.2ZB 上升至 2018 年的 33ZB。未来几年内随着各类智能物联设备的推广以及云计算的进一步应用,数据量有望进一步上升。随着数据量上升,大数据分析的需求逐步显现,传统的关系型数据库在高并发、分析等方面存在一定的劣势,应运而生的分布式数据库能够较好的满足大数据分析的需求,或形成数据库市场新的增量。

图表4 全球数据库市场规模

图表5 全球数据产生量

图表6: 数据库演进

数据库发展历程复盘:计算载体变革往往催生新兴数据库龙头

阶段一:大型机到小型机时代促成了 Oracle 的兴起

上世纪 90 年代小型机兴起促成 Oracle 兴起。上世纪 80 年代到 90 年代,IBM PC 兼容机的出现使新兴中小厂商能够提供价格更低,并且同样能兼容多种第三方软件的计算机产品, IBM PC 兼容机市场份额也因此迅速增长,推动了计算机在美国家庭内普及。此后, Windows3.0 于 1990 年推出,提供了较为成熟的图形界面操作系统,推动了计算机的普及。这一阶段内,Oracle 数据库等产品最终战胜了主机数据库占领了这一新增市场,从收入规模变化看,1990-2000 年 Oracle 营业收入高速增长,期间 CAGR 达到 27.3%。

图表790 年代美国计算机销售快速增长

图表890 年代 Oracle 营业收入规模高速增长

技术积累帮助 Oracle 开拓小型机市场。基础软件从产品诞生到走向成熟往往需要十年左右的时间。以 Oracle 为例,公司于上世纪 80 年代初开始产品化,一直处于技术与商业的积累过程。直到 1992 年,公司推出旗舰产品 Oracle7,迅速把握小型机发展带来的市场机遇,在与 IBM DB2 for LUW、Informix、Sybase 等著名数据库厂商的一系列竞争后,一跃成为行业的霸主。

图表9Oracle 主要数据库产品(2010 前)

阶段二:小型机到分布式时代,AWS 兴起分布式架构时代,AWS 等数据库兴起。随着数据量的增长,传统数据库面临挑战,分布式数据库的访问模式从过去单一标准化的 SQL,向包括 SQL 在内的多种访问模式转化,催生了分布式数据库的发展。2005 年起,人们开始了针对分布式数据库的探索,以 HBase、Cassadra、MongoDB 为代表的 NoSQL 数据库快速发展。此类数据库通过提供 KV 接口、简化存储模型等方式实现容量水平扩展,但对业务的支撑有所减弱。2012 年左右随着Google 关于 Spanner 和 F1 论文的发表,以 Aurora、Spanner 为代表的分布式数据库迅速发展。分布式数据库结合了非关系型数据库的存储管理能力、关系数据库的 ACID 特性和SQL 便利性。从结果看,分布式技术历经十年左右的发展,如今逐步被大量企业接受,而在这一阶段内,AWS aurora 等新兴数据库逐步兴起。

国产分布式数据库 2011 年陆续起步。自 2011 年起,以 Oceanbase、巨杉数据库、TiDB 为代表的国产分布式数据库相继诞生。三者发展路径及商业化时间有所区别,其中Oceanbase 诞生于2011 年,最初主要用于阿里集团内部,在 2017 年首次实现商用;巨杉数据库诞生于 2011 年,于 2013 年正式发布商用版本,并持续服务于金融银行行业;TiDB于 2015 年发布,重点经营开源策略。

图表10: 分布式数据库发展历程

AWS 发展全新的技术体系,把握分布式数据库浪潮。AWS 数据库平台可以视为一个大型数据服务资源池,在底层共享统一的存储与计算资源,在上层则提供了 Aurora、RDS、DynamoDB、Neptune 等数据库服务实例,从而实现对更多业务场景和服务模式的覆盖。

通过全新的技术体系,亚马逊 AWS 满足了多样化的计算需求,2013-2020 年收入 CAGR 达到 46.7%。并且凭借云计算业务的快速扩张,获得了领先的市场地位。截至 2019 年,据Canalys,AWS 在云基础设施市场份额达到 32.3%,具有一定的优势。

图表11 AWS 收入及占亚马逊总收入比

图表12 2019 年全球云基础设施市场份额

图表13AWS 数据库技术体系

进入战国时代,云计算场景推动分布式数据库时代到来

分布式数据库满足云计算场景的需求

计算场景不断变化,云成为重要的计算场景。不同的计算场景对数据库有不同的要求,随着数据量的不断增长,传统的终端计算场景难以满足大量的数据处理需求。而云计算将计算与存储资源弹性、动态分配,边缘计算通过边缘节点提升了计算的效率,实现了高效的数据处理,云端、边缘端的计算场景重要性逐步提升。据 Gartner,全球云计算市场规模由2011 年的 910 亿美元增长到 2019 年的 1880 亿美元,期间 CAGR 达到 9.5%。

图表14: 全球云计算市场规模

分布式数据库能够较好满足云计算场景的需求。分布式数据库将数据库进行资源池化管理, 具备多模式、多租户、HTAP、弹性扩张、高可用等特性,与云计算、分布式应用开发模式相匹配。分布式数据库包括底层数据库资源池化管理、多模式两大重要特点。

(1)底层数据库资源池化管理:指以资源池的方式,上层应用中所有模块在底层数据库资源池中创建独立的数据库实例,服务于自身业务。每一个数据库实例可以提供完全不同的兼容 MySQL、PostgreSQL、MongoDB、S3 等接口,也可以将所使用的底层物理资源扩展到多个服务器中做到自由伸缩,同时也能够保障不同实例之间的数据可以根据策略做到物理或逻辑层面的相互隔离。在这种体系架构中,应用程序依然能保持独立的微服务形态。

(2)“多模式”特性:指同一套分布式架构底座同时支撑上层超过一种数据访问接口, 访问方式包括但不限于 SQL 引擎、类似 JSON 的半结构化数据、S3 的非结构化数据、KV 键值对存储、图数据库接口、时序型数据接口等。通过此种方式,可以对存储于不同的物理服务器、不同格式的数据进行数据结构与算法的优化,从而形成“数据服务平台”,突破数据库类型的限制,对上层不同类型的应用同时提供多种类型的数据服务。

图表15: 云原生概念变迁

分布式数据库满足云原生需求,或将成为新的增长点:从云原生概念变迁看,云原生使用微服务、容器等技术,目的在于提供更加敏捷的服务支持,协助业务更易于实现扩展及持续交互。分布式数据库通常是基于一个数据集合,这些数据分布在由计算机网络连接起来的若干节点上,每个节点可以管理本地的数据应用,也可以参与全局数据应用,同时这些数据在逻辑上形成一个整体,由统一的数据库管理系统进行管理。从架构上看,分布式数据库提供了灵活的数据服务支持,实际上是一种“云原生”的架构体现。

图表16: 全球数据库市场规模(分类别)

大数据向分布式数据库倾斜,或形成新增量。以 Hadoop 为代表的第一代大数据系统框架对大数据技术的落地起了重要的作用。Hadoop 起源于 2004 年,并于 2006 年成为一套独立完整的软件。Hadoop 主要包括文件系统 HDFS 及计算系统 MapReduce,采用计算存储一体化的方式,将巨大的数据集分派到由普通计算机组成的集群中的多个节点进行存储, 并能对数据进行索引和跟踪。但随着数据量和分析需求的复杂性的进一步增加,Hadoop 中“Map+Reduce 模型不适合描述复杂的数据处理过程”、“查询效率较低”、“时刻在线处理导致使用成本高”等问题逐步显现,分布式数据库或成为大数据领域的新选择。

图表17Hadoop 生态模型

SnowflakeDatabricks 引领数据湖兴起

数据仓库性能较强,数据湖更具灵活性。数据仓库与数据湖侧重点有所区别,数据仓库关注的是数据使用效率和数据管理,为企业各级别、业务线的决策制定提供统一的数据支持,其数据主要来源于业务系统,存储格式以结构化为主,并且历经加工清洗,数据形态显得更加范式化、模型化,因此数据的灵活度较低。相比之下,数据湖则是以原生格式(或者经过粗加工后)进行积累和沉淀,格式丰富多样,有结构化、半结构化、非结构化类型, 强调数据的原始性、灵活性和可用性。相比数据仓库,数据湖所储存的数据类型更加丰富, 同时开放存储让上层引擎灵活度增加,引擎可随意读写数据湖中数据,兼容的宽松性强。但另一方面,数据湖中文件系统直接访问使得很多更高阶的功能很难实现,如细粒度权限管理、读写接口升级等。

图表18: 数据湖 vs 数据仓库

Snowflake:提供数据仓库、数据湖等多种产品

Snowflake 满足并发性、可扩展性、易用性、平台中立性的需求。公司完全基于公有云,提供包括数据仓库(Data Warehouse)、数据湖(Data Lake)在内的多种产品,支持非结构化数据、数据可视化和分析。公司意在打造综合性的云数据平台,其数据库可在三大公有云 AWS、Azure 和 Google Cloud Platform 上部署,对于企业多云异构的复杂环境有适用性、中立性,同时亦提供数据交换功能,解决了过去用户面临着投入高、灵活度低等问题,可吸引中小型客户。据公司财报,截至 2020 年 7 月,公司有 3117 个企业客户,同比增长超 100%,截至 2021 财年 Q3,公司的数据提供商已经突破 100 家。

图表19Snowflake 数据湖产品 vs 数据仓库产品

图表20Hadoop vs snowflake

数据仓库满足多种使用场景需求。其中弹性数据仓库的系统会随着负载变化自动扩展或收缩,根据需要向主机复制数据,且并不限制处理请求的数量,从而实现数据服务弹性。数据仓库采取 Shared-nothing 架构,在节点之间不共享任何数据,此外 Snowflake 基于Multi-cluster, shared data 的概念,将存储和计算分离,解决了升级扩容时需要重新分配节点资源等痛点。在数据支持方面,Snowfalke 支持结构化和半结构化数据的组合使用,可以接收 JSON、XML 或 Avro 格式的数据,并且支持嵌套和重复数据类型,从而满足传统数据库、Hadoop 等半结构化使用场景的使用需求。

图表21Snowflake 数据仓库架构

Snowflake 数据湖产品强调查询性能、数据管道集成可扩展、安全等。利用内置数据治理和安全性的同时实现快速的数据访问,具备较好的查询性能,并且对数据转换进行了良好的支持,通过云的模式为客户省去运维成本。在查询性能方面,支持即时和几乎无限的可扩展性和并发性;此外,通过集成和可扩展的数据管道,实现简化数据管道开发以优化性能。依靠管道实时可靠地扩展来处理繁重的数据工作量和可扩展的数据转换;在安全方面, 则提供了安全的数据协作功能。

图表22Snowflake 数据湖

Snowflake 服务各行业客户。以 hookit 为例,据公司官网,Snowflake 为 hookit 构建具有可扩展性的多集群共享数据架构数据库,提高了 Hookit 的运营效率。查询效率提高 30 倍,每天可自动评估社交帖子 5 亿条,数据仓库基础架构成本降低 40%,消除了 88%的内部支持请求,提升了客户的运行效率,使客户能够专注于产品创新。

图表23Snowflake 客户

DatabricksLakehouse 概念,帮助客户构建统一分析平台

Databricks 推出 Lakehouse 概念。Lakehouse 是由“Data Lakes”与“Data Warehouses”融合而成。普通的数据湖在数据质量、一致性/隔离性、混合处理追加读取等方面不如数据仓库。Lakehouse 兼容了数据仓库和数据湖的优势,在数据湖的低成本存储上实现数据仓库的数据结构和管理功能。Lakehouse 功能包括事务支持、模式执行和治理、BI 支持、存储与计算分离、开放性、支持多种数据类型、各种工作负载、端到端流。

图表24Lakehouse

为客户提供统一分析平台提升效率:构建统一分析平台,简化跨功能团队的分析工作流程, 使用单一平台查询、调试和探索流式处理和批次数据,以及构建和部署 ML 模型。打造交互式工作空间,促进与共享笔记本环境的合作,使数据科学家能够快速实时在模型上进行重复。同时简化管理,使公司无需人工干预即可完全自动化作业调度、监控和集群管理。以RB 为例,Databricks 为 RB 提供了一个统一的数据分析平台,该平台在数据科学和工程领域营造了可扩展的协作环境,使数据团队能够更快地进行创新,并为业务提供 ML 驱动的见解。据公司官网,该方案使得公司业务可支持量提高 10 倍,数据从 80TB 压缩到 2TB,降低了运营成本,24*7 个任务的数据管道性能提高 2 倍。

图表25Databricks 客户

数据库六大评判维度

综合前文数据库行业的发展历程,我们总结了数据库的几个评判维度,主要包括品牌基因、商业模式、内核基础、技术架构、商业落地、人才体系。

品牌基因:品牌定位和创始团队背景

关注品牌基因。包含品牌的背景,商用首发时间,资金背景,创始团队背景、厂商主营业务等。品牌基因反映出数据库的品牌特性,商用首发时间较早的数据库厂商往往在传统数据库领域具有较为深厚的积累,近年来新诞生的势力包括独立创新品牌和大厂的数据库产品。从创始团队背景看,则反映出数据库产品的技术背景,当前国产数据库创始团队多来自国内顶尖院校、海外数据库厂商或国内互联网大企业内部培育。此外,由于大数据时代数据库的作用日益重要,在传统的数据库厂商之外,金融服务厂商、ICT 等主营业务非数据库的厂商也推出了自己的数据库产品。主营业务非数据库的厂商基于特定场景延伸出的数据库产品针对特定的行业可能存在一定的竞争优势。但与此同时,相比独立数据库厂商, 此类厂商的发展路径及方向可能会受到母公司策略方向的制约。

图表26: 数据库品牌基因对比

商业模式:基础软件需要企业级服务,开源具有两面性

数据库是基础软件,稳定性较为重要。基础软件指操作系统、数据库、中间件等服务于软件开发者的,最底层的软件。此类软件直接调度 CPU、内存、磁盘、网络等硬件设备,因此稳定性较为重要。数据库在 IT 架构中扮演着承上启下的角色,向下对接操作系统,需要直接调度各类硬件,分布式数据库还需要协调多台服务器形成整体的可管理集群,深度参与跨节点事务控制及网络优化以获得最佳性能;向上则需要支撑大量不同形态的上层应用。与应用软件相比,数据库作为基础软件更加注重稳定性。

图表27: 数据库在 IT 架构中的位置

开源具备两面性,企业级服务厂商具备稳定性优势。开源将二次修改使用源代码的权利公开,有助于快速的积累用户,当客户将包含开源产品的内容通过闭源方式销售时则需要支付费用,厂商实现用户资源变现。但相比企业级服务,开源往往通过技术社区的方式维系, 缺乏法律合约关系,开发者响应速度难以保障,并且在社区参与者过多的情况下维护难度也有所提升。相比之下,企业级服务具有稳定性的优势。因此对于数据库等重视稳定性的基础软件,企业级服务产品具备一定的优势。

图表28: 基础软件 VS 应用软件

图表29: 各开源产品协议调整情况

开源或闭源模式均需导向企业级服务。开源具有两面性,通过将二次修改使用源代码的权利公开,打造开发者生态,有助于快速的积累用户。但开源和闭源并非不会改变,同一家数据库厂商可能在不同的阶段选择开源或闭源,此外,在同一时期,也可能同时发布开源、闭源的不同版本产品。如 Oceanbase、GaussDB 均经历过开源与闭源的切换。但一般来说开源版本往往较低,企业级服务需要最新,最稳定的性能,因此闭源模式的产品较为适合。

内核基础:原厂自研能力关键,掌控核心代码或成重要竞争力

企业级原厂服务有助于从源头解决问题。企业级服务包括企业级原厂服务及第三方支持服务。企业级原厂服务指掌握每一行核心代码,可以从源头解决软件核心问题的厂商,企业通过购买其产品及服务,可以获得系统故障过后第一手的服务承诺。而第三方支持服务, 如同数据库行业中各类运维服务商,在成熟的市场体系下可以协助客户以更低的成本获取常规服务支持,但由于第三方支持服务商往往不具备产品的核心研发能力,因此往往作为服务辅助。

图表30: 企业级原厂服务 VS 第三方支持服务

企业级原厂服务掌握迭代控制权,有助于持续发展。开源社区及第三方厂商虽然拥有更改源代码的能力,但其更改存在不被主流社区接纳,最终与主社区脱节的风险,因此稳定性上存在一定隐患。相比之下,企业级原厂服务掌握迭代控制权,有助于持续发展。在分布式数据库的厂商选择上同样如此,具有全面掌握所有核心代码主导权的厂商所提供的企业级原厂服务能形成更加有力的技术支持。国内商业闭源的分布式数据库厂商大多为主研发, 具备企业级服务基因。

图表31: 企业级原厂服务 VS 开源数据库

关注是否为完全自研可控。数据库内核是否自研关系到数据库厂商是否完全能掌握迭代控制权,目前国产数据库多采取具备自主知识产权的自研内核。选取具备自研内核的数据库产品有助于提升产品升级迭代的稳定性和可控性,对于重视稳定性的基础软件领域,自研可控是重要的考虑因素。

图表32: 数据库内核自研情况

技术架构:不同数据库适用于不同场景

关系型数据库 vs 非关系型数据库。根据数据存储结构区分,可以分为关系型数据库、非关系型数据库,其中非关系型数据库根据存储方式又可以分为键值数据库、列数据库、文档数据库、图数据库等。非关系型数据库在读写性能、扩展性上具有一定的优势,因此较适应大数据、高并发等场景,而关系型数据库具备强一致性,遵循 ACID 原则,因此在事务支持中具备优势。

图表33: 关系型数据库 vs 非关系型数据库

图表34: 非关系型数据库分类

集中式数据库 vs 分布式数据库。根据系统架构分,可以分为集中式数据库、分布式数据库。分布式数据库在可扩展性、高并发支持方面具有优势,集中式数据库在事务性支持上遵循ACID 原则,在事务支持上具备优势。从优劣势看,分布式数据库的优劣势与非关系型数据库类似,而近年来,分布式数据库不断发展,在提供高弹性、支持高并发的同时,与关系型数据库强事务性支持的特性进一步结合。

图表35: 集中式数据库 vs 分布式数据库

磁盘数据库 vs 内存数据库。根据存储设备分,可以分为磁盘数据库、内存数据库。内存数据库指将数据放在内存中直接操作的数据库,具备读写速度快的优势。相比之下,磁盘数据库在容量大小、数据安全性能方面具有一定的优势。从内存数据库及磁盘数据库的特点看,内存数据库适用于对读写要求较高,快速开发的场景。

图表36: 内存数据库 vs 磁盘数据库

数据库技术架构评判要点与计算场景、数据类型相关。计算场景的变化、数据结构的丰富等,催生出不同的数据库需求。纵观数据库的发展历程,我们总结出了以下几个评判数据库技术架构的要点,不同的场景对每个维度的侧重有所不同。

查询:随着数据类型的丰富,传统的关系型数据库难以满足需求,新兴的非关系型数据库增加了针对多种非结构化数据类型的查询方法,数据库查询方式决定了其适用的数据类型。在数据类型日益丰富的今天,查询方法是评判数据库的重要维度。

容量大小&弹性:随着数据量的不断提升,容量大小和弹性的重要性逐步上升。

(1)容量大小:内存数据库受限于物理内存大小,相较于磁盘数据库容量上存在劣势,因此使用场景也相应受到限制;

(2)弹性:分布式数据库支持通过添加服务器的横向扩展方式,使数据库获得了更高的性能,而传统的集中式关系型数据库支持提升处理器性能的方式纵向扩展,相比之下弹性较弱。面对高并发的分析型、大数据类任务,分布式数据库就体现出一定的优势。

事务支持:事务支持要求具备一致性原则,传统的关系型数据库在事务支持方面遵循了ACID 原则,包括原子性、一致性、隔离性、持久性,从而实现较好的事务支持。非关系型数据库在事务支持方面仅能遵循大部分 BASE 原则,即基本可用、软状态、最终一致性,在事务支持上相对较弱。

安全性:数据安全性是评判数据库的重要维度之一,随着云计算、大数据等新技术在数据库领域逐步应用,安全性的概念也不断延伸,不仅包括容灾能力,还包括数据安全、数据协同的权限管控等方面。

成本:成本包括硬件成本、软件成本、运维成本等,云数据库通过云模式降低了运维成本及硬件采购成本。此外,随着分析场景的丰富,在评判数据库成本时应该采取动态的视角, 考虑包括弹性扩容成本、后续运维成本在内的各项成本。

落地情况:中标客户行业&应用场景

关注数据库的落地情况。不同行业对数据库的需求有所区别,处理事务的复杂性、对安全稳定的要求、付费意愿均会产生不同。一般来说,金融、电信类场景由于处理量大,宕机代价较高,因此对于安全、稳定性有较强的诉求,能够首先在金融、电信类场景落地通常意味着在性能、安全等方面达到了较高的标准;因此金融、电信等领域落地情况可以大致作为数据库安全、稳定性的筛选维度之一;此外金融、电信、互联网类场景往往具备高并发特征,需要不断扩展,并且往往能够积累下大量数据,为分析打下了良好的基础,适合分布式数据库,因此分布式数据库的选择可以重点关注以上行业的案例。在此之外,能够积极向其他场景延伸则体现出数据库产品的延伸性,有助于不断打开新的市场空间。从国内分布式数据库当前的落地情况看,金融、党政、电信也是目前主要的落地场景,除此之外,互联网、电力能源、教育也是重要的落地场景。

图表37: 代表客户及覆盖行业

公开的人才体系:自营培训认证体系、企业技术级社区

公开人才体系体现生态建设成效。公开的人才体系包含自营社区、培训认证等部分。数据库厂商推出培训认证,系统的培养厂商数据库人才,在提升数据库人才水平的同时培养了使用者的使用习惯,有助于生态的建设。另一方面,通过自营社区论坛,能够提供开发者交流的空间,有助于使用者拓展技术前沿视野,在提升使用者水平的同时,促进技术生态发展,一定程度上社区论坛的活跃度能够反映数据库的生态建设成效。

图表38: 国产数据库厂商公开人才体系

图表39: 商用首发及行业重要协议发布时间对比

图表40: 数据库比较维度

国内数据库市场:新兴与传统厂商并存

人大金仓:背靠 CETC 中国电子科技集团,老牌数据库

背靠 CETC 中国电子科技集团,拥有三类核心产品。人大金仓背靠 CETC 中国电子科技集团,由中国人民大学最早一批从事数据库研究的专家于 1999 年发起创立,先后承担了国家“863”、“核高基”等重大专项。人大金仓拥有三类核心产品,分别为数据存储计算、数据采集交换以及数据应用分析。其中金仓交易型数据库 KingbaseES,是入选国家自主创新产品目录的数据库产品,也是国家级、省部级实际项目中应用较为广泛的国产数据库产品。

图表41: 人大金仓发展史

分布式数据库产品 KSOne 具备应用透明,支持水平扩展等特点。人大金仓旗下的 KSOne 是一款面向交易型业务场景、实时分析场景、时间序列等场景的 HTAP 分布式数据库产品, 具有可横向弹性伸缩、高可用、可跨域分布部署、应用透明度高等特点。该产品采用分布式集群架构,支持水平数据分片等智能分片算法。此外,支持并行加载与并行计算,数据导入速度达到 50GB/分钟,有助于进行实时分析。

图表42: 人大金仓数据库产品

人大金仓主要致力于为政务、能源、国防、金融、公安、电信等国家企事业单位提供解决方案。据公司官网,人大金仓为北京市资源中心构建大数据平台,面向大数据中心用户以及委办局用户提供数据管理和服务,用户可利用北京市大数据管理平台的能力和服务,开展数据的管理、处理、分析与可视化等工作,支撑各类业务应用。

图表43: 人大金仓北京市资源中心大数据平台示意图

武汉达梦:背靠中国电子,主攻混合型数据库 HTAP

背靠 CEC 中国电子,主攻混合型数据库 HTAP武汉达梦成立于 2000 年,为中国电子信息产业集团(CEC)旗下基础软件企业。应用于金融、电力、航空、通信、电子政务等 30 多个行业领域。武汉达梦主攻混合型数据库 HTAP,旨在用一种数据库模式处理客户所有数据库需求,适合业务广、数据量大的综合型客户使用。武汉达梦目前已掌握数据管理与数据分析领域的核心前沿技术,拥有全部源代码,具有完全自主知识产权。其主要产品有:达梦 HTAP 数据库管理系统 DM8、达梦大数据集群软件 DMMPP 等产品。

图表44: 达梦数据库产品

达梦主推透明分布式数据库DMTDD技术。达梦提出的 DMTDD 技术包括灵活横向扩展、完整的 SQL 特性支持、多副本数据异地容灾的特点。结合了分布式数据库高可扩展、高可用、高并发处理能力,并支持传统数据库开发接口和业务开发框架的技术架构。

(1)灵活横向扩展:DM8 TDD 采用计算存储分离的系统架构,实现计算、日志、存储三层分离,可实现各层独立扩展、按需配置设备的特点。

(2)完整的 SQL 特性支持:支持多表连接查询、子查询、视图嵌套查询、递归表达式查询等高级查询语法。提供存储过程、触发器、Package、序列等高级功能特性。

(3)多副本数据异地容灾:支持异地部署,通过将数据副本存储在不同的容灾域,实现数   据的异地容灾。日志服务本身具备副本与容灾能力,可在每个数据中心分别部署日志服务节点。数据库服务在主机房按需部署,在本地和异地备用机房日常无需部署,只需在检测到灾害时,即时启动。

图表45: 达梦透明分布式数据库(DMTDD

为解决能源行业神华集团加强集中管控能力、解决信息孤岛问题、提升跨区交互能力、进行复杂统计、提高应用型容灾的需求,武汉达梦使用 DM7 数据库管理系统以及相关数据集群、DMETL 组件、DMHS 同步套件等产品、DMHS 数据同步工具,从而保证业务系统的连续性和跨站点的高可用性。此外,据公司官网,神华集团数据库工程使用普通 PC SERVER 的达梦数据库服务器成功替换 Oracle 一体机,降低用户成本。同时,达梦采用现有设备创建同城容灾系统,保障系统稳定运行。

图表46: 达梦能源行业解决方案示意图

巨杉数据库:自研金融级分布式数据库独立厂商

巨杉数据库成立于 2011 年,是一家专注分布式数据库技术研发的自研数据库独立厂商。针对市场对业务中台、微服务架构、非结构数据管理、敏捷开发的不同需求,SequoiaDB 巨杉数据库已推出:DP(湖仓一体数据平台)、TP(事务型数据库)、CM(内容管理数据库) 和 DOC(文档型数据库)四大产品线。

企业基因:从商用首发时间看,巨杉数据库是国内最早进行商业化布局的分布式数据库。2011 年,SequoiaDB 巨杉数据库作为独立数据库公司开始研发,进行原生分布式架构布局。2013 年 SequoiaDB v1.0 产品化正式商用并进军企业级领域,开始为客户提供产品及技术服务支持。

商业模式:打造企业级产品标杆。银行业是体现数据库产品能力的标杆行业,据赛迪顾问,2019 年中国金融 IT 市场规模中,银行 IT 占据了 50%以上的市场份额。一家银行历经了几十年的法律和业务规则的演进,通常拥有超过上百种的业务系统。因此业界公认,在选择技术产品的过程中,银行对于数据稳定性、安全性和数据处理性能等企业级功能,要求是最为严苛的。银行作为企业级产品应用的标杆行业,能被其采用的产品均达到了金融级产品的最高标准,自然更能够满足其他行业的要求。

巨杉采用企业级服务的商业化策略,对于重视稳定性的基础软件数据库而言,相较于开源模式在版本迭代的稳定性上具有更符合企业运行标准的竞争优势。借此,巨杉数据库不断向金融等关键行业拓展。自 2014 年首次进入金融行业以来,已经在国内金融行业进行了大规模的实践与使用,应用场景也覆盖了联机交易、数据中台、内容管理以及实时数据服务等多类业务。

图表47: 巨杉数据库发展历程

自研内核:自研内核具有领先性。巨杉数据库坚持从零开始打造原生分布式数据库引擎, 专注数据库技术研发,聚焦金融赛道,致力于以金融行业为核心,打造安全可靠、高性能, 适合全行业通用的分布式数据库产品。基于分布式技术架构,研发出引擎级多模及 STP 逻辑时钟协议分布式数据库技术,能够实现分布式交易与 ACID 与传统技术完全兼容,架构及功能特性与传统数据库完全兼容,提供跨引擎事务支持和一致性保障。基于多副本隔离机制,其 HTAP 混合负载能力能够实现计算、I/O 资源互不干扰的OLTP/OLAP 混合负载管理, 充分释放资源,进一步提升系统稳定性。巨杉数据库支持多种级别的容灾部署形态,如同城双中心、同城三中心、两地三中心甚至三地五中心等,独创四级熔断容灾安全保护机制, 充分保证数据安全,满足核心交易业务的严苛要求。

图表48: 巨杉数据库架构

客户:巨杉主要为金融业提供数据库产品。巨杉数据库具备丰富的服务大型企业的解决方案和经验,据公司官网,巨杉数据库已在超过 100 家大型银行及金融机构的生产业务规模上线应用。其中民生银行的生产环境集群包含超过 160 台物理服务器,三副本数据量达2460TB,基于巨杉数据库实现的非结构化数据管理平台已接入的各类系统达到 100 套。

图表49: 巨杉数据库在民生银行的应用架构

同时,巨杉数据库的应用范围已扩展至证券、保险、电信、政府、能源、互联网、交通等多个行业。据公司官网,目前,巨杉数据库的企业用户总数超过 1000 家。目前,巨杉数据库支持超过 4096 节点,超 10PB 级别存储容量,已成功协助客户在高达 1.2 万亿数据量生产环境下,提供安全稳定、可灵活扩展、高性能、高并发的数据底座。

图表50: 巨杉数据库主要客户

生态:助力技术生态体系建设。巨杉数据库积极参与信创生态建设,据 2021 年信创产业技术与应用大会,截至 2021 年 3 月,巨杉已经与鲲鹏、飞腾、统信、银河麒麟等产品完成兼容认证,合作伙伴总数超 50 家,为企业客户打开丰富的上下游产品生态。

2019 年,巨杉数据库搭建「巨杉大学」认证与学习体系,讲师团队由巨杉数据库官方的数据库架构师、资深分布式技术专家以及开源社区技术大咖共同组成。目前,已有超 180 家金融机构,30 余家知名技术服务开发商参加巨杉大学计划。截至 2020 年底,经过短短 1年的发展,巨杉大学已认证工程师超过 1 万人,网站用户注册数量超过 5 万人,为分布式技术业界发展提供坚实的人才积淀。

PingCAP TiDB:开源分布式关系型数据库

建立以分布式数据库为统一中心的架构。TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库,是一款同时支持在线事务处理与在线分析处理的融合型分布式数据库产品。2015 年 9月,借鉴 Google Spanner 及 F1 论文的实现,TiDB 在 Github 上开源,从仅有 SQL 层及 KV 层的 beta 版本到现在已经衍生出庞大家族的 4.0 版本,始终围绕着解决分库分表问题,为用户提供一站式 OLTP、OLAP、HTAP 解决方案的目标演进。在内核设计上,TiDB 分布式数据库将整体架构拆分成了多个模块,各模块之间互相通信,组成完整的 TiDB 系统。与传统的单机数据库相比,TiDB 的纯分布式架构拥有良好的扩展性且具有丰富的工具链生态,覆盖数据迁移、同步、备份等多种场景。

图表51TiDB 整体架构图

多应用场景,适合不同业务需求。依托纯分布式架构,及开源社区,TiDB 持续扩展出丰富的应用场景。一是对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景,TiDB 采用多副本+Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器,当部分机器出现故障时系统可自动进行切换;二是对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景,TiDB 采用计算、存储分离的架构,可对计算、存储分别进行扩容和缩容,计算最大支持 512 节点,每个节点最大支持 1000 并发,集群容量最大支持PB 级别;三是Real-time HTAP 场景,TiDB 在4.0 版本中引入列存储引擎TiFlash结合行存储引擎 TiKV 构建真正的 HTAP 数据库,在增加少量存储成本的情况下,可以同一个系统中做联机交易处理、实时数据分析,极大地节省企业的成本;四是数据汇聚、二次加工处理的场景,TiDB 通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB,在 TiDB 中直接生成报表,便于将分散在不同系统中的数据汇总,以便决策层了解公司的整体业务状况及时做出决策。

“开源社区”助力“开源商业化”。PingCAP 拥有丰富的开源技术社区活动,依托开源社区, 在自身快速发展过程中不断回馈社区,形成开源社区和自身研发的有效协同。通过开源及免费策略,快速扩展开发者及技术粉丝用户群体,以长期积累未来商业变现的机会。据GitHub,截至 2021 年 3 月,TiDB  项目在 GitHub  上已总计获得超过 27000  颗星,超 4200位开源代码贡献者,参与企业包括美团、知乎、小米、微众银行等众多企业,高度活跃的开源社区为 TiDB 产品发展带来了正向反馈闭环。在此基础上,TiDB 已被广泛应用于互联网、游戏、金融、大型企业、政府等多领域的领先企业的实际生产环境中,当中还包括多个国外不同地区的用户。

图表52TiDB 国内主要用户

阿里 Oceanbase:金融级分布式关系数据库

发端于阿里内部,逐步商业化。OceanBase 是由蚂蚁金服、阿里巴巴完全自主研发的分布式关系型数据库,始创于 2010 年。应用于支付宝全部核心业务以及阿里巴巴淘宝业务。从2017 年开始,开始服务外部客户。2020 年 6 月 8 日,蚂蚁集团将自研数据库产品 OceanBase 独立进行公司化运作,同年 9 月,中国工商银行开始采用蚂蚁自研数据库 OceanBase,其对公(法人)理财系统已完成从大型主机到 OceanBase 分布式架构的改造。Oceanbase 商业化逐步推进。

图表53Oceanbase 发展历程

OceanBase 是一个金融级分布式关系数据库。具备在线水平扩展能力;GeaBase 是一款针对特殊巨型复杂网络、超大实时更新数据场景的分布式实时图数据库产品,拥有简单易用、性能高的特点。该产品定位是一款分布式关系数据库,适合于金融、证券等涉及交易、支付和账务等对高可用、强一致要求较高,同时对性能、成本和扩展性有需求的金融属性场景,以及各种关系型结构化存储的 OLTP 应用。

图表54Oceanbase 架构

Oceanbase 主要客户包括网商银行、支付宝、淘宝网、阿里妈妈。其中,为了解决支付宝一致性、扩展性、可用性、成本性能方面的业务挑战,OceanBase 在架构层面引入 Paxos 协议,多重数据校验机制,完善支付宝业务模型,多重机制保障金融级别的一致性。此外,支付宝的订单型业务采用了"同城三中心"的部署方式,具备单机和单 IDC 故障的容灾,通过 RFO 的方式提供异地容灾能力,在性能和可用性方面做到了极致的权衡。账务型业务采用"三地五中心"部署方式,除了具备单机,单 IDC 的容灾能力,还具备城市级故障自动容灾能力。据公司官网,OceanBase 在同城容灾和异地容灾场景下,RPO=0,RTO<30  秒。

图表55Oceanbase 主要客户

华为 GaussDBAI 原生,支持异构计算

AI 原生&支持异构计算。华为 GaussDB 是一个企业级 AI-Native 分布式数据库。为超大规模数据管理提供高性价比的通用计算平台,也用于支撑各类数据仓库系统、BI(Business Intelligence)系统和决策支持系统,为上层应用的决策分析提供服务。华为的数据库产品系列命名为:GaussDB,高斯数据库。华为 GaussDB 是一个企业级 AI-Native 分布式数据库。 GaussDB 采用 MPP(Massive Parallel Processing)架构,支持行存储与列存储,提供 PB(Petabyte, 2 的 50 次方字节)级别数据量的处理能力。华为 Gauss 数据库是全球首款 AI-Native 数据库,能够同时支持 X86、ARM、GPU、 NPU 等异构计算。

图表56GaussDB 产品

GaussDB:三大产品线系列。据华为官网,目前华为已经开发有三个产品系列:GaussDB100、 GaussDB 200、 GaussDB 300。 1) GaussDB 100:主要以 OLTP 为主。目前该产品已经应用在招商银行。 2) GaussDB 200:以 OLAP 为主,兼顾 OATP。该产品目前已经在工商银行得到上线应用。 3) GaussDB300:HTAP,是企业级分布式HTAP 数据库(Hybrid Transaction andAnalytical Process,混合事务和分析处理)。

图表57Gauss 数据库产品线

华为 GaussDB 产品主要用于互联网、物联网、电商、金融、游戏。在电商应用中,数据库可支持热销商品展示、秒杀推荐等数据面临高并发压力的场景。此外,云数据库兼容 Redis 生态,高并发分布式缓存服务 Redis 提供超过 10 万的高 QPS,轻松应对高并发访问,业务爆发时可以通过一键扩容,满足秒杀场景下的访问量增长产生的计算需求。

图表58Gauss 电商类应用架构示意图

总结:分布式数据库或诞生新龙头,关注六大评判维度

1、数据量增大、类型丰富、计算场景扩展,分布式数据库或成为新的增量

数据库行业发展与计算载体变革紧密相关,而随着计算载体的变革,在新市场内往往会诞生新的数据库龙头。从发展变革看,大型机向小型机的变革,数据库在事务处理中的应用逐步增加,催生了 Oracle 为代表的关系型数据库厂商;随着云计算的兴起,以 AWS 为代表的新兴数据库厂商逐步兴起。

分布式数据库或成为新的增量。随着数据的累积,分析型任务的重要性逐步提升,擅长于事务支持、结构化数据查询的传统关系型数据库市场增长逐渐放缓,据 T4.ai 预测,全球关系型数据库市场规模 2018-2022E CAGR 为 6%,较 2012-2017 的 11%或将有所下降。另一方面,数据类型持续丰富,从结构化数据向非结构化数据延伸,支持非结构化数据的查询方法变得日益重要。而分布式数据库、数据仓库在大数据分析中展现出了较好的支持性, 综上,我们认为分布式数据库或成为数据库领域新增量。

2、商业模式:企业级服务&开源社区,核心在于解决客户的问题

数据库作为基础软件,在 IT 架构中扮演承上启下的重要作用,因此相比于功能的快速更新, 数据库的安全与稳定性更为重要。开源社区有助于快速积累用户,但企业级产品通过更加紧密的组织方式,保障了开发者的响应速度,在提供企业级服务方面具有优势。

3、内核基础:自主研发能力重要性上升

原厂自研在稳定性上具备优势。原厂自研的数据库厂商能够提供企业级原厂服务,相比于提供第三方服务的厂商,更有助于从源头解决问题,在安全性和稳定性上具备优势;在功能的迭代上,掌握源代码的自研厂商能够主导功能的迭代,相较于开源社区,在稳定性上更有优势,与企业级客户的需求更为契合。

我们总结了评判数据库的六个维度,除了上文提到的商业架构、内核基础外,还包括品牌基因、技术架构、商业落地、人才体系

(1)品牌基因:影响技术路线、侧重领域、应用场景等。包含品牌的背景,商用首发时间,资金背景,创始团队背景、厂商主营业务等。品牌基因反映出数据库的品牌特性,品牌基因对数据库的技术路线、侧重领域、应用场景均会产生一定的影响,在选择数据库厂商时, 品牌基因是重要的考量因素。我们认为,国产数据库厂商大致可以分为传统数据库、创新品牌、大厂子产品三类,不同类厂商的优势领域有所区别。

(2)技术架构:分析型、大数据场景适合分布式数据库。集中式数据库在事务性支持上遵循 ACID 原则,在事务支持上具备优势。分布式数据库在高并发支持、扩展性上具备优势。而近年来,分布式数据库不断发展,在提供高弹性、支持高并发的同时,与关系型数据库强事务性支持的特性进一步结合。

(3)商业落地:金融、电信场景体现稳定性。一般来说,金融、电信类场景对于安全、稳定性有较强的诉求,能够首先在金融、电信类场景落地通常意味着在性能、安全等方面达到了较高的标准;因此金融、电信领域落地情况可以大致作为数据库安全、稳定性的筛选维度之一;此外能够积极向其他场景延伸则体现出数据库产品的延伸性,有助于不断打开新的市场空间。

(4)人才体系:体现生态建设成效。公开的人才体系包含自营社区、培训认证体系等部分。我们认为,数据库厂商通过推出针对自由数据库产品的培训认证,在提升数据库人才水平的同时培养了使用者的使用习惯,有助于生态的建设。另一方面,社区论坛作为技术爱好者的交流空间,从侧面体现出数据库产品的活跃度,是生态建设成效的体现。

风险提示

市场竞争加剧风险。分布式数据库快速发展,但参与者众多,存在竞争加剧的风险。

芯片及 AI 行业发展导致 IT 投资倾斜风险。随着芯片及 AI 行业迅速发展,存在 IT 投资向芯片、AI 领域倾斜,对数据库领域投资产生影响的风险。

免责声明

分析师声明

本人,谢春生、郭雅丽,兹证明本报告所表达的观点准确地反映了分析师对标的证券或发行人的个人意见;彼以往、现在或未来并无就其研究报告所提供的具体建议或所表迖的意见直接或间接收取任何报酬。

一般声明及披露

本报告由华泰证券股份有限公司(已具备中国证监会批准的证券投资咨询业务资格,以下简称“本公司”)制作。本报告所载资料是仅供接收人的严格保密资料。本报告仅供本公司及其客户和其关联机构使用。本公司不因接收人收到本报告而视其为客户。

本报告基于本公司认为可靠的、已公开的信息编制,但本公司及其关联机构(以下统称为“华泰”)对该等信息的准确性及完整性不作任何保证。

本报告所载的意见、评估及预测仅反映报告发布当日的观点和判断。在不同时期,华泰可能会发出与本报告所载意见、评估及预测不一致的研究报告。同时,本报告所指的证券或投资标的的价格、价值及投资收入可能会波动。以往表现并不能指引未来,未来回报并不能得到保证,并存在损失本金的可能。华泰不保证本报告所含信息保持在最新状态。华泰对本报告所含信息可在不发出通知的情形下做出修改,投资者应当自行关注相应的更新或修改。

本公司不是 FINRA 的注册会员,其研究分析师亦没有注册为 FINRA 的研究分析师/不具有 FINRA 分析师的注册资格。

华泰力求报告内容客观、公正,但本报告所载的观点、结论和建议仅供参考,不构成购买或出售所述证券的要约或招揽。该等观点、建议并未考虑到个别投资者的具体投资目的、财务状况以及特定需求,在任何时候均不构成对客户私人投资建议。投资者应当充分考虑自身特定状况,并完整理解和使用本报告内容,不应视本报告为做出投资决策的唯一因素。对依据或者使用本报告所造成的一切后果,华泰及作者均不承担任何法律责任。任何形式的分享证券投资收益或者分担证券投资损失的书面或口头承诺均为无效。

除非另行说明,本报告中所引用的关于业绩的数据代表过往表现,过往的业绩表现不应作为日后回报的预示。华泰不承诺也不保证任何预示的回报会得以实现,分析中所做的预测可能是基于相应的假设,任何假设的变化可能会显著影响所预测的回报。

华泰及作者在自身所知情的范围内,与本报告所指的证券或投资标的不存在法律禁止的利害关系。在法律许可的情况下,华泰可能会持有报告中提到的公司所发行的证券头寸并进行交易,为该公司提供投资银行、财务顾问或者金融产品等相关服务或向该公司招揽业务。

华泰的销售人员、交易人员或其他专业人士可能会依据不同假设和标准、采用不同的分析方法而口头或书面发表与本报告意见及建议不一致的市场评论和/或交易观点。华泰没有将此意见及建议向报告所有接收者进行更新的义务。华泰    的资产管理部门、自营部门以及其他投资业务部门可能独立做出与本报告中的意见或建议不一致的投资决策。投资者应当考虑到华泰及/或其相关人员可能存在影响本报告观点客观性的潜在利益冲突。投资者请勿将本报告视为投资或其他决定的唯一信赖依据。有关该方面的具体披露请参照本报告尾部。

本报告并非意图发送、发布给在当地法律或监管规则下不允许向其发送、发布的机构或人员,也并非意图发送、发布给因可得到、使用本报告的行为而使华泰违反或受制于当地法律或监管规则的机构或人员。

本报告版权仅为本公司所有。未经本公司书面许可,任何机构或个人不得以翻版、复制、发表、引用或再次分发他人 (无论整份或部分)等任何形式侵犯本公司版权。如征得本公司同意进行引用、刊发的,需在允许的范围内使用,并需在使用前获取独立的法律意见,以确定该引用、刊发符合当地适用法规的要求,同时注明出处为“华泰证券研究所”,且不得对本报告进行任何有悖原意的引用、删节和修改。本公司保留追究相关责任的权利。所有本报告中使用的商标、服务标记及标记均为本公司的商标、服务标记及标记。

中国香港

本报告由华泰证券股份有限公司制作,在香港由华泰金融控股(香港)有限公司向符合《证券及期货条例》及其附属法律规定的机构投资者和专业投资者的客户进行分发。华泰金融控股(香港)有限公司受香港证券及期货事务监察委员会监管,是华泰国际金融控股有限公司的全资子公司,后者为华泰证券股份有限公司的全资子公司。在香港获得本报告的人员若有任何有关本报告的问题,请与华泰金融控股(香港)有限公司联系。

香港-重要监管披露

  • 华泰金融控股(香港)有限公司的雇员或其关联人士没有担任本报告中提及的公司或发行人的高级人员。更多信息请参见下方 “美国-重要监管披露”

美国

在美国本报告由华泰证券(美国)有限公司向符合美国监管规定的机构投资者进行发表与分发。华泰证券(美国)有限公司是美国注册经纪商和美国金融业监管局(FINRA)的注册会员。对于其在美国分发的研究报告,华泰证券(美国)有限公司根据《1934 年证券交易法》(修订版)第 15a-6 条规定以及美国证券交易委员会人员解释,对本研究报告内容负责。华泰证券(美国)有限公司联营公司的分析师不具有美国金融监管(FINRA)分析师的注册资格,可能不属于华泰证券(美国)有限公司的关联人员,因此可能不受 FINRA 关于分析师与标的公司沟通、公开露面和所持交易证券的限制。华泰证券(美国)有限公司是华泰国际金融控股有限公司的全资子公司,后者为华泰证券股份有限公司的全资子公司。任何直接从华泰证券(美国)有限公司收到此报告并希望就本报告所述任何证券进行交易的人士, 应通过华泰证券(美国)有限公司进行交易。

美国-重要监管披露

  • 分析师谢春生、郭雅丽本人及相关人士并不担任本报告所提及的标的证券或发行人的高级人员、董事或顾问。分析

师及相关人士与本报告所提及的标的证券或发行人并无任何相关财务利益。本披露中所提及的“相关人士”包括FINRA 定义下分析师的家庭成员。分析师根据华泰证券的整体收入和盈利能力获得薪酬,包括源自公司投资银行业务的收入。

  • 华泰证券股份有限公司、其子公司和/或其联营公司, 及/或不时会以自身或代理形式向客户出售及购买华泰证券研究所覆盖公司的证券/衍生工具,包括股票及债券(包括衍生品)华泰证券研究所覆盖公司的证券/衍生工具,包括股票及债券(包括衍生品)。
  • 华泰证券股份有限公司、其子公司和/或其联营公司, 及/或其高级管理层、董事和雇员可能会持有本报告中所提到的任何证券(或任何相关投资)头寸,并可能不时进行增持或减持该证券(或投资)。因此,投资者应该意识到可能存在利益冲突。

评级说明

投资评级基于分析师对报告发布日后 6 至 12 个月内行业或公司回报潜力(含此期间的股息回报)相对基准表现的预期(A 股市场基准为沪深 300 指数,香港市场基准为恒生指数,美国市场基准为标普 500 指数),具体如下:

行业评级

增持:预计行业股票指数超越基准

中性:预计行业股票指数基本与基准持平减持:预计行业股票指数明显弱于基准

公司评级

买入:预计股价超越基准 15%以上增持:预计股价超越基准 5%~15%

持有:预计股价相对基准波动在-15%~5%之间卖出:预计股价弱于基准 15%以上

暂停评级:已暂停评级、目标价及预测,以遵守适用法规及/或公司政策

无评级:股票不在常规研究覆盖范围内。投资者不应期待华泰提供该等证券及/或公司相关的持续或补充信息

 

法律实体披露

中国:华泰证券股份有限公司具有中国证监会核准的“证券投资咨询”业务资格,经营许可证编号为:91320000704041011J         

香港:华泰金融控股(香港)有限公司具有香港证监会核准的“就证券提供意见”业务资格,经营许可证编号为:AOK809

美国:华泰证券(美国)有限公司为美国金融业监管局(FINRA)成员,具有在美国开展经纪交易商业务的资格,经营业务许可编号为:CRD#:298809/SEC#:8-70231

 

华泰证券股份有限公司

南京

南京市建邺区江东中路228 号华泰证券广场1 号楼/邮政编码:210019

电话:86 25 83389999/传真:86 25 83387521

电子邮件:ht-rd@htsc.com

北京

北京市西城区太平桥大街丰盛胡同28 号太平洋保险大厦A 座18 层/邮政编码:100032

电话:86 10 63211166/传真:86 10 63211275

电子邮件:ht-rd@htsc.com

深圳

深圳市福田区益田路5999 号基金大厦10 楼/邮政编码:518017

电话:86 755 82493932/传真:86 755 82492062

电子邮件:ht-rd@htsc.com

上海

上海市浦东新区东方路18 号保利广场E 栋23 楼/邮政编码:200120

电话:86 21 28972098/传真:86 21 28972068

电子邮件:ht-rd@htsc.com

 

华泰金融控股(香港)有限公司

香港中环皇后大道中 99 号中环中心 58 楼 5808-12 室

电话:+852-3658-6000/传真:+852-2169-0770

电子邮件:research@htsc.com http://www.htsc.com.hk

 

华泰证券(美国)有限公司

美国纽约哈德逊城市广场 10 号 41 楼(纽约 10001)

电话:+212-763-8160/传真:+917-725-9702

电子邮件: Huatai@htsc-us.com http://www.htsc-us.com

 

©版权所有2021年华泰证券股份有限公司

 


http://www.ppmy.cn/news/500562.html

相关文章

关于存量和增量的杂谈

关注存量&#xff0c;好处是稳定&#xff0c;但坏处时会被存量绑架。一个小区门口有一个煎饼摊&#xff0c;此时小区里的每日消费量是一个固定的存量&#xff0c;此时你在旁边也开了一个煎饼摊&#xff0c;这就是典型的存量的竞争&#xff0c;两个竞争对手提供同质化的产品&…

2023商业新变局,如何向存量要增量?

2022财年业绩披露周期到来&#xff0c;过往一年经济下行给企业带来的压力愈发体现出来。除了AI、新能源造车等少数赛道&#xff0c;已经很少看到高投入、高增长的经营模型&#xff0c;转而变为稳定增长&#xff0c;积极盈利的发展模式。 宏观策略传递到互联网广告市场&#xff…

MySQL数据库学习笔记二

数据库存储引擎 数据库存储引擎是数据库底层软件组织&#xff0c;数据库管理系统&#xff08;DBMS&#xff09;通过数据引擎&#xff0c;对数据进行创建、查询、修改和删除的操作。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能&#xff0c;使用不同的存储引擎…

【头歌-Python】Python第七章作业(初级)

第1关&#xff1a;字符串去重排序 任务描述 输入一个非空字符串&#xff0c;去除重复的字符后&#xff0c;从小到大排序输出为一个新字符串。 输入格式 一个非空字符串 输出格式 去重排序后的字符串 示例 输入&#xff1a; Life is short, you need Python!输出&#…

flex三兄弟

连接&#xff1a;https://blog.csdn.net/m0_37058714/article/details/80765562

ibm服务器日志文件提取,IBM X3850 X5服务器搜集日志

搜集服务器日志信息是定位服务器具体故障的常用方法之一&#xff0c;绝大部分的IBM系列服务器搜集日志方法比较简单&#xff0c;以企业中常见的IBM X3850 X5为例&#xff0c;给大家分享一下搜集服务器硬件日志的方法。 第一步 修改本机IP地址 IBM服务器X3850 X5默认综合管理模块…

3.25。

/*** 1、題目內容:* 从键盘输入一个整形数n&#xff0c;如果输入正确的话&#xff0c;输出1-n的值&#xff0c;如果输入错误的话输出“not int”* 最后输出end** 输入输出说明:* 输入&#xff1a;* asd* 输出&#xff1a;* not int* end*/System.out.print…