数据基础设施支撑企业数字化转型

前言

刚刚过去的21世纪的第二个十年，是消费互联网蓬勃发展的十年，也是云计算、大数据、人工智能等新一代信息技术，即“数字化技术”快速崛起的十年。

在这一时期，以信息服务为主的消费互联网行业，如电商、互联网金融、社交娱乐等，充分享受了数字化技术带来的“数字化红利”，极大推动了其终端用户的消费行为与体验的数字化转型。

但相比于消费互联网行业在数字经济浪潮下的蓬勃发展，以传统线下服务、实体商品制造为主的传统行业逐渐显得落寞。在国际局势不明朗、国内市场红利逐步耗尽、存量竞争日益明显、人才成本日益高企、产业升级换代压力增大的当下，传统行业的经营与效益上正面临三十年未有之变局，在新兴的数字化业态冲击下，还同时面临着客群与市场相对萎缩的困局。

因此，投资数字化技术，充分接纳技术带来的变革，推动企业数字化转型，从而实现经营策略由粗放式向精细化的转变，对抗经济周期带来的下行压力，将成为传统企业的必然抉择。

根据华为&牛津经济研究院报告显示，自2000年以来，金融、制造、ICT服务、交通、公用事业、房地产、农业等传统行业的数字化技术投资的年复合增长率，明显超越以消费互联网为代表的数字化技术制造业。

图1：各行业的数字投资增长

该报告还表明，过去三十年中，数字化技术投资每增加1美元，便可撬动GDP增加20美元，而1美元的非技术投资仅能推动GDP增加3美元，数字化技术投资的平均回报是非数字化技术投资的6.7倍。这也说明，驱动传统行业的数字化技术投资的动力来源，本质上是企业对效益提升的追求。

在数字化技术中，数据库、数据仓库、大数据平台和云数据平台等基础软件，构成了企业数字化转型的重要基础设施，即“数据基础设施”。随着各行业的数字化场景的发展，新的业务挑战对“数据基础设施”的技术路线演进产生了极大的推动作用。

但是，迄今为止的数据基础设施发展，仍然难以彻底解决以集团型、多分支-企业为代表的大中型企业数字化转型的痛点。

比如，银行、保险等金融机构普遍采用夜间“跑批”的方式对当日交易数据进行ETL处理，从而将数据汇总到数据仓库、数据集市中，供用户进行报表分析与即席查询，但数据基础设施底层的复杂查询性能，成为“跑批”结果时效性的主要瓶颈，这也影响了用户进行决策的频次和时效性。

再如，电力、电信等关乎国计民生、用户数量巨大、IT基础设施复杂的行业，普遍面临的挑战是数据规模及其庞大，而数字化应用的计算与存储需求也及其巨大。为了提升工作负载能力，多集群的数据基础设施已经成为行业普遍现状。由此，尽管交易型数据库的“数据孤岛”得到了一定程度的治理，但在数据基础设施内部，却因为多集群间的数据共享难题，产生了新的“数据孤岛”。

由此可见，数据基础设施的技术架构、功能与性能特点的不断演进和发展，仍具备无限的想象空间。以“云数据平台”为代表的新一代数据基础设施，正逐渐成为集团型、多分支企业推进整体数字化转型的最佳选择。

01

数据基础设施支撑企业数字化转型

在宏观经济走向中低速增长的今天，“重资产、薄利润、现金流短缺”等经营现状，愈发困扰着传统企业，产业升级任重而道远。

相比于从诞生第一天起就带有浓重“数字化基因”互联网企业，许多传统企业对数字化技术的应用还处在摸索阶段。但是，中国经济已经开始迈入“数字经济”的新阶段，快速涌现和崛起的数字原生企业，以及数字化技术带来的竞争优势，意味着传统企业如果不快速接纳数字化技术带来的变革，那么将必然无法维持原有竞争优势。

因此，通过积极接纳数字化技术，重塑业务流程，拓展业务边界，将成为传统企业实现可持续发展的必然选择。

1.1 企业数字化的战略规划

国务院发展研究中心课题组发布的《传统产业数字化转型的模式和路径》对产业数字化进行了定义：利用新一代信息技术，构建数据的采集、传输、存储、处理和反馈的闭环，打通不同层级与不同行业间的数据壁垒，提高行业整体的运行效率，构建全新的数字经济体系。

在这一基础之上，爱分析认为，企业的数字化转型，则是指企业依托于数字化技术（即“新一代信息技术”），构建与数字化技术相适应的战略规划、人才能力、组织架构、运营方法，推动业务及运营模式的不断变革与敏捷创新，从而帮助客户创造更大价值，实现业绩增长与运营效率提升。

相比于传统企业，数字化企业具备四大基本特征：以客户为中心、以数据价值为基础、以AI能力为引领、以敏捷能力与驱动型IT组织为支撑。

由此可见，企业数字化转型是一项系统性、全员性工程，绝非能够一蹴而就。传统企业的数字化转型项目，普遍存在“成本高、周期长、难度大”等问题，这使得传统企业的数字化转型步伐显得迟缓且保守。

为了降低数字化转型项目的失败风险，降低试错成本，提升项目整体效益，进行自顶向下的战略规划显得至关重要。根据先进企业的数字化实践经验来看，成功的企业数字化战略，至少应当包括数字化战略、数字化场景、数字化技术与数字化组织等四个层次。

图2：企业数字化的战略规划

数字化战略：企业数字化战略具备系统性特征，是“一把手工程”，责任首先在于企业高层，成功的关键也在于企业高层观念与理念的转变。因此企业首先需要进行战略目标的设定，从而充分调动全企业、各部门的资源，对业务场景、组织架构、数据基础设施进行整体规划，并对实施流程进行整体把控。

数字化场景：数字化战略的核心价值在于赋能业务场景，缺乏落地场景的数字化战略只是“空中楼阁”。因此，企业应当在具体业务场景中衡量数字化的真实价值，这就需要企业全面梳理业务场景，并对各场景的业务需求、现有条件、预估投入、波及范围和预期业务收益进行全面评估，保证数字化转型的目标与收益相对明确、实施过程与影响相对可控。

数字化技术：数字化技术主要指为企业数字化战略提供技术支撑的云、数据、AI等技术能力。其中，数据能力主要指企业基于数据分析来支撑业务决策的能力，其在基础软件层面的具体载体是“数据基础设施”。

数字化组织：数字化战略的内在要求是对数字化组织架构的打造。为了深度应用各类数字化技术，企业需要推动数字化人才的引进和培养，比如数据分析师、数据科学家、算法工程师等专业性技术人才，以及具备数字化意识的业务人才和管理人才。在人才基础上，企业需要进一步搭建最大化人才价值的数字化团队。在文化层面，企业需要通过一系列的规范标准、制度安排、激励措施，推动“以数据发现问题所在、以数据分析问题成因、以数据预测发展趋势、以数据推动业务变革”成为全企业、各部门的集体共识，将数据文化内化为企业文化的一部分。

1.2 数据基础设施的定义

爱分析认为，数据基础设施是一套建立在过往的交易数据基础之上，并结合一定的技术手段与业务流程，为业务场景提供数据服务，实现数据价值变现的生态体系。数据基础设施的建设方式、建设质量直接决定了数字化团队的协作方式与工作效果，也进一步影响了整个企业数字化战略的最终效果。

一般来讲，数据基础设施包括数据体系、技术体系、运营体系、服务体系等四个部分。

图3：数据基础设施架构

数据体系：包含了企业内可利用数据的组织方式，包括源系统的交易数据，各类非结构化、半结构化、二进制数据，以及结构化数据的数据分层关系、数据模型、数据表结构、视图关系、字段名称、数据容量、数据权限分配等。

技术体系：包含了一系列数据相关的技术产品，如交易型数据库、数据接入工具（数据同步/消息中间件）、分析型数据库、NoSQL数据库、数据开发工具、AI算法开发工具等，以及不同产品之间的协同关系与业务流程。

运营体系：通过数据标准、数据质量、数据资产目录、数据服务培训与推广、平台操作流程与规范等，搭建数据的资产化管理与运营体系，从而为服务体系提供稳定的运营支撑，并保证数据基础设施与组织架构之间的协同效率。

数据运营体系建设在金融行业的重要性： 在中国经济转型、金融科技高速发展、金融环境及监管政策变化的大背景下，金融行业尤其银行业面临着持续挑战和变革压力，亟需推进全面的数字化转型。 在需求层面，数据已经成为金融机构的战略资产，数据的准确性、完整性、一致性等数据质量指标对金融机构至关重要。 在政策层面，银监会、人民银行、外管局等监管机构对商业银行等金融机构的数据良好标准、数据一致性、完整性等数据质量指标的要求也日趋严格。比如，银保监会于2018年5月21日正式发布《银行业金融机构数据治理指引的通知》（银保监发【2018】22号），对银行数据治理体系建设提出了规范要求，并将数据治理与监管评级挂钩，将银行业金融机构开展数据治理工作的重要性提高到了战略高度。 但是，当前许多金融机构仍然普遍存在“缺少数据治理体系、数据质量较差、数据应用难以有效开展”等问题，与满足监管的基本要求还有较大距离，也难以满足日益增长的数据应用需求。 因此，构建完善的数据运营体系，加强数据治理、提升数据质量、发挥数据资产价值、支持业务创新和精细化管理的必要性和紧迫性日益凸显。

服务体系：是数据与业务结合的关键环节，主要以可视化大屏、固定报表、自助式报表、数据API服务、数据应用等数据服务形态，以便捷的方式为业务部门提供数据服务，实现数据变现。

1.3 数据基础设施的演进历程

作为企业数字化转型的核心支撑，数据基础设施的技术架构特点，决定了其支撑数字化团队与数字化场景的能力上限。

根据业务场景、组织架构、技术架构、功能特点、性能特点的差异，数据基础设施的演进历程，已经经历了数据库、数据仓库、大数据平台三个完整阶段。目前，数据基础设施正在迈向前三个阶段之后的第四个阶段，即“云数据平台”阶段。而在这一演进过程中， 还出现了像“数据中台”这样的阶段性概念。

图4：数据基础设施的演进历程

1.3.1 数据库阶段

数据库是数据基础设施的萌芽阶段，而最早的商用数据库产品，如Oracle、DB2，均诞生于1970年代末到1980年代初。

早期的数据库应用于以OLTP（联机事务处理）场景为主，即直接承载来自业务系统、交易系统的数据存储与计算，因此这类数据库又被称之为“事务型数据库”或“交易型数据库”。在许多情况下，人们也将它等同于狭义的数据库。

业务场景

该阶段的企业缺乏成熟、可落地、面向一线业务人员的数字化场景，核心痛点是为企业管理层解决宏观层面的经营决策问题。

因此，该阶段的数据查询维度、数字化展现形式都比较单一，主要是基于固定的若干张数据表，生成面向管理层的固定报表、可视化大屏等。

组织架构

该阶段的企业普遍缺乏专业的数字化人才，也缺乏成熟的数字化组织架构与文化，主要由IT人员承担面向管理层的数字化场景的落地。

数据基础设施的技术架构

该阶段的数据基础设施，尚未完全从业务系统的交易数据库中分离出来。对数据分析需求，企业一般基于交易型数据库单独建设一套用于分析查询的历史数据库，汇集来自不同交易数据库的原始数据。在少部分数据分析场景下，企业还会直接用交易数据库进行支持。

交易型数据库的软硬件架构都采取共享存储架构，即计算节点能够访问到任意的存储节点，同时需要基于专有物理硬件，由此保证对性能的良好优化。

数据基础设施的功能及性能特点

功能特点：对各类SQL标准、ACID特性（指数据库事务的四个属性，包括原子性、一致性、隔离性、持久性）的支持都相当完善，因此带来了很强的稳定性。但是，共享存储架构带来的缺点是可扩展性差，一般只能扩展到十几节点就会遇到瓶颈。

性能特点：主导第一代数仓的Oracle、IBM等IT巨头公司具备深厚的基础研究和性能优化能力，因此在OLTP场景中表现优良，但是由于共享存储架构在可扩展性方面的不足，使得其在大数据分析场景中的性能表现相对一般。

*典型产品：Oracle、IBM DB2

1.3.2 数据仓库阶段

1990年代后，尤其是随着E.F.Codd于1993年正式提出联机分析处理（OLAP）的概念，数据基础设施开始进入“数据仓库”时代。

业务场景

该阶段的企业开始具备一定的数字化意识，数据分析的需求开始从管理层下沉到业务部门，核心痛点是为一线业务人员的解决业务决策问题。

由于OLAP的数据查询维度更加复杂，查询频次更高，企业开始将承载OLAP工作负载的数据库与业务系统的交易数据库进行分离，从而避免OLAP对核心交易造成干扰。因此，专用于OLAP的分析型数据库诞生，并逐步从交易型数据库中分离出来，也因此获得了“数据仓库”这一更加形象的别称。

该阶段的数字化展现形式，仍然以传统报表和可视化大屏为主，因此为了支撑业务部门的数据分析需求，需要具备专业的数据分析人员响应需求，并提供技术支持。

但是，为了满足业务人员需要，企业需要存储更多的历史数据，常常需要对数据仓库进行扩容，而Oracle、DB2等交易型数据库扩展性较差，难以满足扩容需求。因此，基于MPP无共享架构的数据库逐步进入人们视野。

组织架构

在组织架构层面，该阶段的企业大多仍然由IT部门来支撑数字化，业务部门、IT部门均缺少数字化人才。因此，其IT组织架构尽管能够支撑一定频次的业务需求，但对于紧迫需求仍然难以充分响应。

数据基础设施的技术架构

数据仓库的软硬件架构经历了较为漫长的发展历程。

1980年代，Teradata首次推出了采取MPP无共享存储架构的数据库，其主要特点是基于大规模并行处理（MPP）架构，即在每个计算节点都有自己独有的存储节点，数据并均匀打散到所有节点存储，并将多个并行任务分散到不同的节点上执行。此外，Teradata继续采用了类似早期Oracle、DB2等数据库的专有物理硬件。到1990年代之后，MPP数据库被越来越多的应用到数据仓库的构建之中。

到2006年前后，Greenplum、Vertica等支持x86通用服务器的MPP数据库出现，降低了数据仓库的建设和扩容成本。

数据基础设施的功能及性能特点

功能特点：无共享架构使得节点扩展变得更加容易，而不再受到共享存储架构的制约，节点数量上限一般能达到数百个；基于x86通用服务器的无共享架构，降低了扩展成本，提升了灵活性；对SQL标准、ACID特性的支持性较好。

性能特点：主导MPP数仓的Teradata、EMC（收购Greenplum）、惠普（收购Vertica）等公司，在整体实力上同样较为雄厚，具备较强的基础研究和性能优化能力；无共享和MPP架构消除了在大数据场景下的性能瓶颈，提升了负载均衡能力，在大数据分析场景中有着超越交易型数据库的性能表现。

典型产品：Teradata、EMC Greenplum、HPE Vertica

1.3.3 大数据平台阶段

2005年后，由于互联网、移动互联网的逐步普及，业务系统的终端用户量的爆发式增长，企业内沉淀的数据量同样呈现爆发式增长，数据基础设施开始进入“大数据平台”阶段。

业务场景

在互联网、移动互联网技术的推动下，金融、电商、社交娱乐等领域的企业开始越来越多地触及终端用户的线上数据。这些数据具有多样、多维度、大规模的特点。

首先，数据类型十分多样，包括结构化数据（关系型数据库中的表）、半结构化数据（如CSV、XML、日志、JSON）、非结构化数据（电子邮件、文档）、二进制数据（图形、音频、视频）等。其次，数据维度更多，包含了用户的各类行为数据。此外，存储的数据量也从过去的GB、TB级别，进一步提升高PB、EB级别。

该阶段的数字化展现形式更加多样，除了传统报表、可视化大屏，具备自助式分析能力的敏捷BI工具逐步普及。这使得在部分场景下，业务人员能够自行进行数据探索与分析，而不再需要IT人员、数据分析师随时进行技术支持。

但是，MPP数据仓库的扩展规模仅能到数百节点，难以进一步扩容，而且不支持非结构化、半结构化数据，逐渐难以满足企业需求。在这样的背景下，以Hadoop为代表的大数据技术逐步成为数据基础设施的核心技术之一。

组织架构

该阶段的企业，普遍开始拥有具备业务理解能力和数据分析能力的数字化人才，但人才往往分散在各业务线，或归并在IT部门，缺乏统一的数字化组织架构，以及对数字化的整体推动能力。

数据基础设施的技术架构

以Hadoop为代表的大数据技术为企业统一采集、存储与处理各类等多种类型数据提供了技术可能性，“数据湖”架构的理念也由此诞生，而许多企业又将“数据湖”称之为“大数据平台”。

基于Hadoop生态的大数据平台，需要兼容前一阶段建设的MPP数据仓库，同时提供基于SQL-on-Hadoop（如Hive、SparkSQL）的数据仓库，以及包括NoSQL数据库（如HBase）、流处理、批处理、分布式存储（如HDFS）在内的大数据套件。

与MPP数据仓库的共享存储架构不同，SQL-on-Hadoop数据仓库基于HDFS等分布式、软件定义的存储，在软件层面实现了存储节点与计算节点的相互独立，因此可以实现计算、存储独立扩展。

数据基础设施的功能及性能特点（仅针对SQL-on-Hadoop数据仓库）

功能特点：由于计算存储分离架构的特点，SQL-on-Hadoop数仓能够实现计算、存储分别扩展，因此在扩展性、在线扩容等方面有明显优势，支持上千节点的扩展规模；但是，由于HDFS的只读限制，SQL-on-Hadoop数仓在对传统事务型数据库所具备的SQL标准、ACID特性支持较差，这也使得应用从事务型数据库、MPP数据库向SQL-on-Hadoop数仓迁移的过程中，存在大量不兼容的问题，即应用易迁移性较差。

性能特点：SQL-on-Hadoop数仓由开源项目、互联网公司、初创型公司所主导，生态相比于前两代数仓更加开放，但是由于缺乏针对性能和功能的深度优化，在大多企业客户中只被应用于边缘场景，一直未达到能够全面取代传统数仓的要求。

典型产品：Hive、SparkSQL、Cloudera Impala、Facebook Presto

1.3.4云数据平台阶段

2015年后，企业上云已经成为普遍共识，同时企业各业务部门对大数据分析的需求更加普遍化、敏捷化、个性化、场景化，数据的业务价值也由辅助决策转变为推动创新。在这一背景下，数据基础设施开始进入“云数据平台”阶段。

业务场景

该阶段的企业，其数字化场景更加广泛且普遍，而且产生了大量的跨部门、跨业务线，甚至跨分支机构、跨组织、跨地域的数据共享与联动分析。同时，孵化于企业原有体系内，但又需要由数据来驱动迭代优化的创新业务层出不穷。

因此，企业数字化转型思路需要从过去的单个场景突破，转变为全集团、跨组织、跨地域的数据共享与资产化管理，以及全场景数据赋能。

组织架构

为了推动集团层面的业务、数据共享，加速业务的敏捷创新，企业需要在组织架构层面对数字化人才、数据基础设施的管理和运营团队进行统筹规划。

比如，以阿里巴巴、腾讯为代表的互联网巨头都先后提出了“中台战略”，成立中台部门对数字化战略进行统筹。为了推动数据的跨部门复用与共享， “数据中台”的概念也被同时提出。

数据基础设施的技术架构

然而，“数据中台”概念的局限性在于并未改变数据基础设施的底层技术架构，而是沿用了大数据平台阶段的技术架构，并保留了传统技术路线带来的弊端。

对此，云数据平台采用了计算与存储分离、虚拟计算集群等新型技术架构，对象存储等云原生技术对数据平台进行了深度优化。

数据基础设施的功能特点

基于云原生、计算存储分离、虚拟计算集群等新型技术架构，云数据平台实现计算、存储节点独立扩展，突破了基于MPP、SQL-on-Hadoop技术的大数据平台在扩展性、灵活性方面的局限。

此外，云数据平台还克服了SQL-on-Hadoop数据库在SQL标准、ACID特性等方面的不足，可以支持数字化应用从传统共享存储数据仓库、MPP数仓向云数据平台的平滑迁移。

最后，大数据平台的基础上，云数据平台吸纳了来自“数据中台”理念的数据资产层与数据服务层，从而形成“数据平台-数据资产-数据服务”的三层架构。

图5：云数据平台“平台-资产-服务”三层架构

数据基础设施的性能特点

相比于大数据平台，云数据平台摆脱了以Hadoop为核心的技术体系的影响，克服了其在性能优化和并发等方面的缺陷，对云平台进行了原生优化，尤其是在分析型云数据仓库方面，可以支持计算与存储分离，弹性可扩展，支持数千节点规模集群，虚拟计算集群，湖仓一体，并对性能做了深度优化，从而大幅度提升面向多张表、批量数据、复杂表关联的复杂查询性能。

02

企业数字化深入推进，云数据平台价值显现

尽管数据基础设施经历了漫长的演进历程，但从数据库、数据仓库到大数据平台阶段，数据基础设施在扩展能力、弹性能力、查询性能、易迁移性等方面，始终受到技术路线繁杂、遗留问题重重的MPP、SQL-on-Hadoop等上一代数据仓库技术的制约。

同时，企业数字化实践的主战场，已经从过去的互联网、创新型企业，全面转到以集团型、多分支企业为代表的大中型传统企业，数字化需求的深度、广度出现全面提升。

然而，时下的“数据中台”解决方案，本质上只是在大数据平台的基础上，融合了数据资产化与数据服务化的管理能力，并没有对大数据平台的原有技术路线进行革命性升级。

因此，数据基础设施需要对技术进行彻底变革，变得更加统一与强大，而新一代数据基础设施——“云数据平台”的出现，则预示着数据基础设施的未来变革方向。

2.1 四大新挑战困扰企业数字化转型

金融、能源、制造、零售等行业内，存在着许多体量庞大、组织架构复杂的集团型、多分支企业。然而，这类企业在推进数字化转型过程中，数字化应用逐步表现出了“大规模”、“强敏态”、“高时效”、“智能化”等四大新特征，对数据基础设施提出了相应的四大挑战，如下图所示。

图6：数据基础设施面临的四大挑战

2.1.1 数据规模膨胀，数据基础设施产生新“数据孤岛”

金融、电力、电信等行业内企业，普遍存在业务系统众多、交易次数巨大、交易额度巨大、数据积累量巨大等特征。据公开数据显示，2019年全国银行卡交易总次数为3219.89亿笔，日均8.82亿笔，交易总金额886.39万亿元，日均2.43万亿元。

因此，企业内的数字化应用对数据基础设施的计算并发量、存储上限的要求越来越高，数据基础设施的节点规模出现了急剧膨胀。比如，某国有大行需要分析数十PB级交易数据，需要3000以上的数仓节点才能满足存储需求。

图7：数据规模膨胀对数据基础设施的挑战

在这样的背景下，两方面因素共同导致了数据基础设施内的“数据孤岛”产生，进一步拉高了企业的数据运维管理成本。

传统交易型数据库与MPP数仓的节点规模限制

目前，MPP凭借对SQL标准、ACID特性的良好支持，仍然是大型企业的核心数字化应用的主流选择。此外，许多企业还在采用Oracle、DB2等传统的交易型数据库来支撑数据分析业务。

面对膨胀的数字化应用规模，企业内的数据基础设施一旦达到可扩展的节点上限，必须采用多集群部署方式，即通过应用级的多集群划分来支撑更多的应用带来的并发计算，通过多集群间的数据分散存储来支撑更高规模的数据存储。

但是，传统交易型数据库、MPP数据仓库的可扩展节点上限仅在十几到上百节点，在许多数字化较为领先的大型企业内，节点需求已经很容易突破上限，因而同时部署多个MPP集群，已经成为大型企业数字化的必须。

比如，某国有大行需要分析10PB级交易数据，需要3000以上的数仓节点才能满足存储需求，因此只能建立40个MPP集群。但是，多集群间的数据共享十分困难，该行只能对部分数据在多个集群进行多份冗余存储，导致最终的实际数据存储量高达几十PB，集群之间数据很容易产生不一致，给该行造成了极大的运维负担。

由此可见，尽管数据基础设施的出现与发展始终是为了实现数据共享利用，消除交易型数据库之间的“数据孤岛”，但是多集群的现状，事实上在数据基础设施内部制造了新的“数据孤岛”。

不同技术架构的数据仓库间的应用易移植性问题

与传统交易型数据库、MPP数仓不同，Hive、SparkSQL等SQL-on-Hadoop数仓具备上千节点规模的扩展能力，但其缺陷在于对SQL标准、ACID特性的支持能力不足，性能比MPP差多倍，并发支持有限，因此许多大型企业倾向于将更多地应用在边缘业务的数字化场景中，与MPP数仓并行使用，共同构建数据基础设施。

然而，传统交易型数据库、MPP数仓、SQL-on-Hadoop数仓在计算存储架构方面的差异，以及在SQL标准、ACID特性上的不兼容，意味着双方之间的数据迁移和共享十分困难。

但是，未来大型企业的数字化，往往不再是过去由单个部门、单条业务线驱动的数字化，而是越来越多地由战略层面进行统筹规划，全部门、全业务线协同推进的数字化。在这种背景下，大型企业常常需要将过去独立建设的数字化应用进行迁移，以同一套数据基础设施支撑上层各个业务线的数字化应用，不但实现了管理的统一，还可提升其扩展能力。

因此，在将遗留的数字化应用在不同技术架构进行迁移过程中，往往需要进行大量的代码重构，移植成本较高，难以实现平滑迁移。

例如，某电网系统内分公司搭建了基于Hive的大数据测试环境，但是拥有更多计算节点的Hive大数据分析性能对比Oracle几乎没有提升，且原有基于Oracle的众多应用系统向Hive迁移时，由于Hive不支持存储过程等Oracle很多功能，需要改写的代码量巨大。

因此，大型企业在数字化过程中，亟需探索一套通过“大一统”方式来建设数据基础设施的解决方案，消除数据基础设施内的“数据孤岛”现象。

为了应对这些挑战，新一代数据基础设施——“云数据平台”应具备以下能力：

计算存储分离架构，及其带来的强扩展性、强共享性：采取计算、存储分离的技术架构，支持数千节点的集群规模，支持多虚拟计算集群；

强SQL标准支持、ACID特性、Hadoop原生支持（即支持传统Hadoop生态系统），及其带来的强兼容性：具备完善的SQL标准、ACID特性的支持能力，兼容过去采用Oracle、DB2等传统交易型数据库、MPP数据库的数字化应用，并支持对接访问HDFS等Hadoop原生组件，从而兼容过去采用SQL-on-Hadoop数据库的数字化应用。

图8：云数据平台应对数据规模膨胀挑战

2.1.2 敏态特征凸显，数据基础设施弹性能力受挑战

早在2014年，Gartner就提出了融合“稳态IT”与“敏态IT”的“双模IT”概念。对于传统行业内的集团型、多分支企业来说，加强“敏态IT”能力建设，是推进数字化转型的重要组成部分。

在“敏态IT”模式下，企业需要更加关注业绩增长、品牌营销与客户体验，大幅增强面对不确定场景的响应能力，这就要求企业IT团队在资源获取、应用迭代、系统运维等方面实现敏捷化转型。

比如，国内某大型航空公司，为了推进全公司的IT敏捷化转型，从团队、工具、方法、实践等四个层面实践敏捷理念。在工具层面，该航司依托云计算IaaS平台，以及基于云数据库、Docker、Kubernetes、AIOps等技术的PaaS平台，构建了一站式敏捷开发管理平台，将过去基于传统IT环境的应用交付过程迁移到云上，有效提升了产品迭代速度，优化了客户体验，促进了业绩增长。

由此可见，具备按需取用、快速弹性、自动化编排等优势的云计算、云原生技术，成为支撑“敏态IT”的新型IT基础设施。

这一趋势对数据基础设施的影响表现为两个层次，第一层是传统业务上云带来的数据的上云，第二层是数字化场景拓展带来的数字化应用上云。

传统业务与数据上云

随着数字化转型的深入推进，企业上云从互联网企业逐步渗透到传统企业，从创新业务、边缘业务逐步渗透到传统业务、核心业务。同时，随着企业上云的推进，全球范围内的数据的产生与存储过程，越来越多地从传统数据中心转移到公共云环境中。

根据IDC报告显示，到2025年，公共云中的数据百分比将接近50%。

数字化应用上云

随着数字化营销与销售、数字化生产制造、数字化采购、数字化协同办公等新兴数字化场景不断出现，企业IT的“敏态”特征不断增强，工作负载量、负载量的波动性相比过去都有明显提升。

因此，数字化应用上云也成为大势所趋。另一方面，来自传统业务、核心业务的交易数据的逐步上云，也为数字化应用的上云铺平了道路。

在这两大背景之下，为了保证数字化应用的高可用性，数据基础设施同样应当具备“敏态”特征，满足资源快速取用、快速启停的弹性能力。因此，对数据基础设施进行云化改造将成为必然趋势。

图9：数字化应用的敏态化对数据基础设施的挑战

但是，数据基础设施在进行云化改造时面临的两大挑战。

首先，共享存储、MPP无共享、SQL-on-Hadoop等技术架构对云环境的特性（如弹性能力）、组件（如云存储）适应性不足，存在弹性性能瓶颈，难以充分发挥云的弹性优势。

其次，共享存储、MPP无共享等技术架构的计算、存储节点深度耦合，无法实现计算、存储性能的非等量扩容，对IT资源的高效利用带来障碍。

再如，某制造型企业上线数字化的排产管理系统后，经常会遇到两种情况：首先，随着应用上线时间推移，数据存储量呈快速的线性增长；其次，在生产高峰期内，计算工作负载往往在短时间内会出现波峰，但在生产高峰期结束后则会迅速恢复到正常水平。过去，该企业采用基于MPP架构的Greenplum集群，计算、存储节点完全耦合，不支持存储和计算独立扩容。因此，当该企业处于生产高峰期内，如果选择充分满足计算性能需求，则存储性能容易造成浪费，但如果选择有限满足计算性能需求，则会造成服务可用性不足。

图10：计算存储耦合与计算存储分离架构的对比

因此，企业数字化的新阶段下，为了应对应用上云、数字化应用比例增加的趋势，“云数据平台”应具备以下能力：

云原生特性、计算存储分离架构，及其带来的高弹性：利用云服务器、分布式存储等云原生技术，对数据基础设施的扩展性能进行深度优化，充分适应云上数字化应用对高度弹性、无限扩容能力的要求；采取计算、存储分离的技术架构，充分适应数字化应用对计算、存储分别独立扩展的要求，增强弹性扩展的灵活性。

图11：云数据平台应对数字化应用敏态化挑战

2.1.3 数据时效性要求提升，数据基础设施查询性能受限

面对激烈的市场竞争，大型企业在决策效率方面的劣势，同样亟需通过数字化手段进行改变。

在金融、零售等具有强烈营销导向的行业内，越来越多的企业决策者和业务人员，都期望能够实现T+1、甚至T+0的数据反馈，从而基于更有时效性的数据进行业务决策，避免因决策周期过长而导致错失商机，这意味着大型企业对数字化应用的时效性要求将持续提升。

从技术原理来看，数字化应用的时效性，主要依托于大数据平台所提供的面向批处理、即席查询等分析型场景（OLAP）的复杂查询能力。但是，数据量的增长带来的数据处理量的增长，以及基于SQL-on-Hadoop的数据基础设施在OLAP复杂查询场景的性能瓶颈，使得数字化应用的时效性越来越难以得到保证。

图12：数据时效性要求提升对数据基础设施的挑战

批处理的性能瓶颈：在批处理模式下，数据服务依托于构建好的分层数据模型。Hive、SparkSQL、MPP等查询引擎，对来自ODS（贴源数据层）的数据进行批量计算，分层将数据抽取到DWD（明细数据层）、DWS（聚合数据层）、ADS（应用数据层）/DM（数据集市层）中，最后由ADS或DM来为可视化大屏、报表分析、数据API等数据服务提供数据支撑。因此，批处理性能的瓶颈，将会导致数据基础设施难以在T+1日内完成批处理工作，从而影响数据服务的时效性。

即席查询的性能瓶颈：在即席查询模式下，数据服务不依托于数据模型，而是由用户自行定义查询维度，直接从数据库中进行关联查询。因此，即席查询性能的瓶颈，将会导致用户查询时面临较高的时间延迟，影响用户体验。

例如，某股份制商业银行在Oracle、DB2传统数据仓库上，建设了管理会计系统、绩效考核系统、监管报送系统、数据集市系统等几十个大型分析系统，数据在PB级以上，但是传统数据仓库的性能瓶颈造成了两方面的困扰。一方面，管理会计系统、绩效考核系统等分析系统全部无法全部满足T+1时间需求，严重影响银行领导的决策分析，以及各分行业务部门每日运营工作的安排部署。另一方面，大数据分析人员需要在海量历史数据中进行即席查询，但随着银行数据量快速增加，每运行一条分析SQL都需要10分钟以上时间。

因此，企业数字化的新阶段下，为了应对数字化应用、数据服务的高时效性要求，“云数据平台”应具备以下能力：

高性能并行执行能力，及其带来的强复杂查询性能：采取最新的SIMD指令集，实现指令内并行技术，从而实现更高性能的并行执行器，从而提供面向PB级大数据的，比MPP、SQL-on-Hadoop数据仓库更快的复杂查询性能，从而明显降低批处理、即席查询所需的时间，提升数据服务的时效性。

图13：云数据平台应对数据时效性的挑战

2.1.4 智能化场景逐步成熟，数据基础设施AI支持能力不足

近些年来，金融行业作为数字化较为领先的行业，其客户画像、信贷信用评分、反欺诈、反洗钱、合规审计等智能化场景逐步成熟。由此，数据的价值逐步由“数据驱动问题发现”“数据驱动问题分析”走向“数据驱动趋势预测”、“数据驱动业务决策”，这进一步要求数据基础设施能够支撑智能化应用的快速开发。

传统的数据仓库中通常会内置In-Database机器学习库，但对于使用者的AI知识水平要求较高，而许多传统行业企业缺乏AI人才，如果选择从零开始构建AI团队、建设AI平台，投入成本十分高昂。

图14：智能化应用对数据基础设施的挑战

因此，企业数字化的新阶段下，为了应对数字化应用的智能化需求，“云数据平台”应具备以下能力：

自动化机器学习支持：基于AutoML技术，允许业务人员通过托拉拽、低代码的方式，实现自动化AI建模；融合云数据平台的数据模型，构建从业务理解、数据接入与处理、特征工程、模型选择、优化算法选择、参数调优、模型评估、模型部署与发布、模型优化等AI全生命周期管理流程。

2.2新一代数据基础——云数据平台

为了满足以集团型、多分支企业为代表的大中型企业数字化转型的新挑战，新一代数据基础设施应当通过底层技术变革，推动技术能力变革，最终满足上层业务的变化。

为此，爱分析从底层技术变革、技术能力变革、业务场景变革三个层次，对新一代数据基础设施“云数据平台”进行定义。

2.2.1 云数据平台的定义

爱分析认为，“云数据平台”是新一代的数据基础设施，它能够依托云原生特性、计算存储分离架构、强ACID特性、强SQL标准支持、Hadoop原生支持、高性能并行执行能力等一系列底层技术的变革，实现高弹性、强扩展性、强共享性、强兼容性、强复杂查询能力、自动化机器学习支持等上层技术能力的变革，最终帮助企业有效应对大规模、强敏态、高时效、智能化等愈发明显的数字化趋势。

图15：云数据平台的概念

云原生特性、计算存储分离架构，及其带来的高弹性：利用云服务器、分布式存储等云原生技术，对数据基础设施的扩展性能进行深度优化，充分适应云上应用对高度弹性、无限扩容能力的要求，并采取计算存储分离架构，进一步提升数据基础设施的扩展灵活性；

计算存储分离架构，及其带来的强扩展性、强共享性：采取计算、存储分离的技术架构，充分适应数字化应用对计算、存储分别独立扩展的要求，增强了弹性能力，并能够支持数千节点的集群规模，尽可能避免多集群部署，并可低成本地支持跨集群的数据共享；

强ACID特性、SQL标准支持、Hadoop原生兼容，及其带来的强兼容性：具备完善的SQL标准、ACID特性的支持能力，兼容过去采用Oracle、DB2等传统交易型数据库、MPP数据库的数字化应用，并支持对接访问Hive、HDFS等Hadoop原生组件，从而兼容过去采用SQL-on-Hadoop数据库的数字化应用，实现数字化应用在数据基础设施间的平滑迁移；

高性能并行执行能力，及其带来的强复杂查询性能：面向PB级大数据，具备比MPP、SQL-on-Hadoop数据仓库更快的复杂查询性能，从而明显降低批处理、即席查询所需的时间，保证数据处理能力的高时效；

自动化机器学习支持：具备对自动化机器学习技术的支持能力，基于AutoML等技术，为业务人员提供自动化AI建模能力，实现AI模型全生命周期管理，降低AI研发与管理成本。

数据资产管理能力：具备数据标准管理、数据质量管理、元数据管理、数据资产目录（敏感数据/业务术语表关联/数据标签/血缘分析）等数据资产化管理能力，从而更好地赋予数据以价值，实现数据的资产化管理与运营。

数据服务管理能力：通过数据API管理模块提供的低门槛、可视化的操作方式，以及分组、权限管理、服务上下线、计量与计费等管理功能，帮助数据分析人员将各类数据查询语句封装为API服务，供各业务部门和业务系统调用，从而实现数据的价值变现。

2.2.2云数据平台对数字化技术的“有机统一”

作为新一代的数据基础设施，“云数据平台”实现了两方面的“大一统”，即对多种数据基础设施技术架构、多种数字化技的有机统一。

一方面，“云数据平台”本质上是对传统的数据库、数据仓库、大数据平台阶段遗留的一系列底层技术、技术能力的升级与替代。

图16：云数据平台是对数据库、数据仓库、大数据平台的升级与替代

另一方面，“云数据平台”实现了对云、大数据、AI等多种数字化技术价值的有机统一。在实际的数字化项目落地过程中，以云能力、数据能力、AI能力为中心的数字化转型往往相互割裂，未能实现充分协同。

以云能力为中心的数字化转型：通过云基础设施建设及组织架构的变革，推动企业IT资源管理能力的数字化转型；缺乏数字化能力的IT组织难以充分支撑业务部门数字化的需求，同时又是企业更好地沉淀、利用数据的基础；

以数据能力为中心的数字化转型：通过数据基础设施建设及组织架构的变革，推动企业数据利用能力的数字化转型；既是对云基础设施价值的进一步提升，也为AI应用的开发建立良好的数据基础，在整个企业数字化转型中居于承上启下的地位；

以AI能力为中心的数字化转型：通过AI平台建设、智能化应用的落地应用及组织架构的变革，推动企业分析决策能力的智能化转型，也是对数据基础设施价值的进一步挖掘。

整体来看，“云数据平台”充分整合了云原生特性，更统一、更强大的数据能力，以及对AI应用的支持能力，为企业提供了“更统一、更强大”的数字化技术能力，未来将进一步推动企业数字化深度、广度的全面升级。

图17：云数据平台的价值

2.2.3以云数据平台为核心的企业数字化转型方案

近些年来，随着企业数字化深度、广度的全面升级，国内外分别崛起了一系列典型的“云数据平台”提供商。

国外较为领先的云数据平台提供商Snowflake，在2020年9月17日于纽交所上市当天，市值突破700亿美元。截止2020年11月底，Snowflake的市值更是已高达830亿美元。

国内较为领先的云数据平台提供商偶数科技，核心创始团队来自EMC数据库团队，其核心产品为新一代云原生数据仓库Oushu Database。

偶数科技基于云数据平台的企业数字化方案

偶数科技除了具备核心产品新一代云原生数据仓库Oushu Database，还提供了包括数据管理平台Oushu Lava、自动化机器学习平台Oushu LittleBoy等一系列配套产品，共同构成一套完整的云数据平台解决方案，从而有效支撑金融、能源、制造等行业的大中型企业客户的全面数字化转型。

图18：偶数科技云数据平台解决方案

新一代云原生数据仓库Oushu Database：Oushu Database（简称OushuDB）是由新一代云原生数据仓库，具备ANSI-SQL标准兼容、ACID特性支持、Hadoop原生支持等特性，兼容Oracle、Greenplum Database、PostgreSQL和Hadoop原生技术体系，采用了存储与计算分离和虚拟计算集群技术架构，实现弹性伸缩、秒级扩容和超大规模集群（几千节点级别）的支持。OushuDB在业界首次解决了大数据量下跨数据中心的数据存储和分析问题，并设计了新一代SIMD执行器，性能比传统数仓快大约5-10倍，提供PB级数据交互式查询能力，提供对主要BI工具的描述性分析和AI支持，对于金融等行业的吸引力进一步增强。

数据管理平台Oushu Lava：Oushu Lava是一款定位于帮助企业构建云数据平台的工具集，包括数据接入工具、数据开发工具、数据资产管理工具、数据服务管理工具等部分，支持客户进行敏捷数据应用开发，助力企业实现数字化转型。

自动化机器学习平台Oushu LittleBoy：Oushu LittleBoy是一个通用的自动化机器学习平台，可以帮助企业级用户轻松实现人工智能落地。Oushu LittleBoy可通过内置的AutoML从上亿个模型中自动挑选出优化的模型，让用户在不了解算法原理的情况下自动选出最优配置，提升业务效率。

爱分析认为，“云数据平台”未来将成为以集团型、多分支企业为代表的大中型企业数字化的坚实底座。

03

以云数据平台为中心的企业数字化落地方法论

正如章节2.2.2所述，云数据平台在数据基础设施的基础上，实现了对云、AI能力的无缝融合，是企业数字化落地的一种更先进的技术形式。

但是，以云数据平台为中心的企业数字化转型，需要更加完善和体系化的落地方法论。一般来讲，数字化方法论包括战略规划与落地实施两个维度。

按照章节1.1中的描述，企业数字化的战略规划应当包括数字化战略、数字化场景、数字化技术、数字化组织等四个层次。

从落地实施维度上看，企业数字化实施过程包括：路径规划、需求分析、方案设计、方案实现、方案支持与迭代等五个步骤。

图19：企业数字化实施过程

3.1 路径规划

路径规划阶段的主要目标是确立数字化转型路径。为此，企业首先需要确立数字化愿景与整体目标，梳理业务场景、数字化现状，并构建数字化实施团队，最终交付现状调研报告与数字化转型路线图。

图20：路径规划

数字化愿景与整体目标确立

确立企业数字化愿景与整体目标的主要价值，在于使得企业上下达成对数字化的同一认知，从而有助于协调资源，降低数字化推行阻力。为此，企业高层领导需要对数字化转型进行统筹规划，提出宏观层面的方针与指示。

应用场景梳理

梳理数字化场景的主要价值，在于使企业能够正确认识数字化带来的潜在价值，明确数字化转型项目的波及范围及投入规模。为此，企业需要对应用系统现状进行梳理，并对现有的痛点及业务价值进行判断。

应用系统现状梳理：各应用系统的产品名称、版本、开发商、使用者、运维方，应用系统的对接方式（接口类型、模板、语言、工具）及数据库对接方式；

痛点及业务价值判断：对用户在使用各应用系统过程中存在的痛点进行调研与收集，对潜在的数字化价值进行初步判断。

数字化现状梳理

梳理数字化现状的主要价值在于帮助企业判断业务场景数字化的当前阶段。为此，企业需要对源系统数据存储、现有大数据平台、BI平台、人工智能、基础设施及架构的现状进行系统性梳理。

源系统数据存储现状：交易型数据库产品名称、版本、应用情况、使用者、运维方；对外数据接口方式、负载现状、元数据信息；

数据基础设施现状：分析型数据库产品名称、版本、使用者、运维方、应用场景、数据存量；用户规划、权限分配等情况；运维、监控、预警平台现状；schema数量、名称、作用；主题域、逻辑模型和物理模型；表、视图、函数数量；

比如，数据基础设施往往存在多种负面现状，如集群数量过多、不利于数据共享与维护，计算存储耦合、弹性能力受限，数据跑批与即席查询性能不足、数据报表与查询结果产出时效性差等；在云数据平台的实施过程中，企业对这些现状应当予以重点解决；

BI平台现状：BI产品名称、版本、使用者、运维方；BI报表数量、BI是否支持自助式报表；

人工智能现状：AI平台产品名称、版本、使用者、运维方；AI模型的应用场景；AI模型的名称、数量及算法；建模任务现有运行时间；特征工程建立方式；

比如，企业往往以使用规则引擎、传统机器学习算法来实现AI预测，且仅面向少量应用系统，无法实现对深度学习AI模型的敏捷开发；在云数据平台的实施过程中，企业对该现状应对予以重点解决；

基础设施及架构现状：现有系统架构图、现有系统组件构成、现有集群数量及系统部署情况、现有服务器单节点硬件配置。

数字化转型实施团队构建

构建数字化转型实施团队主要价值在于为企业数字化战略提供人才支撑，因为缺乏人才支撑的数字化转型，在启动阶段就会遇到重重障碍。数字化转型实施团队主要包括以下三类人才。

数据战略和数据治理类：数据战略顾问、数据治理专家、数据项目经理；

数据科学和数据工程类：数据科学家、人工智能机器学习算法工程师、大数据工程师、数据测试工程师、数据运维工程师；

数据管理和数据应用类：数据建模顾问、数据分析顾问。

在一系列现状梳理工作过程中，数字化转型实施团队可通过交付《现状调研报告》来作为中间成果，从而帮助企业高层明确企业现状，并为未来的需求分析工作积累文档素材。

在战略规划阶段结束时，数字化转型实施团队需要交付《数字化转型路线图》作为阶段性成果，以确定企业数字化转型阶段划分，从而帮助企业高层合理安排资源投入，并确定项目排期。

3.2需求分析

需求分析阶段的主要目标，是将路径规划阶段制定的整体目标拆解到具体业务场景中，以制定更加具体的数字化实施排期方案。为此，企业需要首先对应用场景进行定义与分析，并对数字化需求进行分析，从而进行初步的系统演示，并交付数字化需求分析报告。

从这一阶段开始，企业可与有大量成功实施经验的数字化厂商（如偶数科技）展开密切合作，从而有效降低学习成本，提升实施效率，降低失败风险。

图21：需求分析

应用场景定义与分析 应用场景定义与分析的主要价值，在于使得企业更加明确各个场景内数字化的潜在价值、所需投入，并有效指导数字化需求分析过程的分析范围与最终目标。为此，企业需要确定应用场景对应的业务目标，并对场景内的流程与需求功能进行分析。 数字化需求分析 数字化需求分析的主要价值，在于对数字化解决方案架构中的各个系统、模块与组件应达成的目标与效果进行确认，包括对数据存储与计算、数据资产、数据服务、数据平台、硬件部署、人工智能等各个模块的需求分析。

数据存储与计算需求：未来数年数据量增长、存储需求、灾备需求及批处理、实时查询性能需求；数据存储和计算需求功能列表；

比如，业务部门需要在T+1完成跑批结果，同时希望进一步扩大跑批所分析的数据量，从PB级到十PB级以上；业务部门希望将长达数分钟的即席查询周期，提升到秒级获取查询结果；

数据资产管理需求：数据治理的目标分析，元数据管理、数据标准、数据质量规则需求，数据治理需求功能列表；数据资产目录需求，数据资产管理需求功能列表；

数据服务管理需求：数据服务接口需求，数据服务部署需求；数据集市需求，数据可视化需求，数据报表需求；

现有数据平台需求：现有大数据平台存在的优势，以及与源数据系统、外围应用系统的适配性分析；数字化转型对大数据平台的新需求，现有大数据平台对业务需求及数据需求的不满足之处，以及所需的需求功能列表；

硬件部署需求：业务增长及数字化转型对新型平台硬件的变更需求，平台硬件部署拓扑结构变化需求分析，平台硬件部署需求功能列表；

人工智能需求：AI模型最终用户确认；AI模型需求分析，如业务应用准确率与召回率，样本库数据，模型指标库，AI模型更新频率等；AI工具需求分析，如AI模型生命周期管理，应用系统调用AI模型方式；AI模型开发运维团队分配；现有AI模型问题汇总。

在需求分析阶段结束时，数字化厂商可基于测试环境，对数字化转型方案进行系统安装演示，并与企业客户密切配合，共同交付《业务及数据需求分析报告》。

3.3方案设计&方案实现

方案设计阶段的主要任务，是对数字化转型方案中的各个系统、模块与组件的技术实现方式进行设计，提前发现实施中可能存在的难点，指导各个实施小组的具体分工协作方式，以保证方案实现阶段的工作能够合理、有序进行。

方案实现阶段的主要任务，是按照方案设计阶段输出的交付物，通过实际的编码、实施，将设计方案进行落地交付。

在理想状态下，方案设计与方案实现的内容能够完全一一对应，而且不会交替进行。但是，在许多情况下，由于设计阶段考虑的不周，或者项目排期的客观原因，这两个阶段可能是交替进行的，即在方案实现过程中或阶段完成后，方案设计仍需要重复进行。

在方案设计与实现阶段，企业需要对应用场景、数字化技术方案进行设计与实现。

图22：方案设计&方案实现

应用场景设计与实现

应用场景设计与实现的主要价值，在于保证云数据平台与企业业务场景的良好适配，从而实现其最大化的业务价值。

业务架构设计与实现：对应用场景下，企业自有的业务流程体系、业务运营模式、组织结构及其对应IT应用系统架构进行设计与实现，该工作一般需要企业或相应的外部服务商来完成；

平台功能设计与实现：对应用场景下，云数据平台自身的交互流程、功能界面及接口进行设计与实现；

数据流设计与实现：对应用场景下，数据在云数据平台、BI平台及外部系统的流动方式进行设计与实现。

数字化技术方案设计与实现

数字化技术方案的设计与实现，是整个数字化转型项目的核心内容，其时间与人力成本投入在整个项目中占据较高比重。

数据模型设计与实现：数据模型的设计规范；逻辑数据模型的设计与实现，包括主题域分析，建立实体模型，建立实体间依赖关系；物理数据模型的设计与实现，包括转换逻辑数据模型为物理数据模型，对模型设计进行优化；

数据处理设计与实现：通过ETL、任务调度等工具进行数据转换与加载，包括数据抽取、转换和加载策略的设计与实现，以及自动化调度依赖关系的设计与实现；

比如，企业可应用Oushu Lava，以OushuDB高性能云数据仓库替代Hive引擎，基于同样的PB级数据和仅一半服务器节点数，跑批性能提升几十倍，复杂即席查询分析可在秒级完成；

数据资产管理设计与实现：元数据管理的设计与实现，包括元数据功能、元数据提取规则及周期、元数据变更；数据标准的设计与实现；数据质量检查的设计与实现；错误数据处理的设计与实现；数据资产目录的设计与实现，包括数据权限分配等；

数据服务管理的设计与实现：数据服务接口的设计与实现；数据服务部署的设计与实现；数据集市模型的设计与实现；数据可视化、数据报表、图形可视化的设计与实现；

AI模型设计与实现：AI模型特征工程设计与实现；AI模型算法/参数设计与实现；AI模型指标库设计与实现；AI模型服务设计与实现；AI应用场景数据宽表设计与实现；

比如，应用LittleBoy自动化机器学习系统深度学习算法自动化完成关于客户画像、电信反欺诈等应用场景的模型训练、发布、生命周期管理，显著提升预测准确率、召回率。

基于企业与数字化厂商的密切配合，在方案设计阶段结束时，双方需要交付《数字化转型方案设计报告》，而在方案实现阶段结束时，双方需要交付《数字化转型方案交付报告》，并由企业对项目进行验收测试与试运行。

3.4方案支持与迭代

在方案支持与迭代阶段的主要目的，是保持数字化转型方案的生命力，让其产生更加持久的业务价值。为此，企业需要与数字化厂商配合，对现有方案进行培训与推广，对已完成的数字化转型项目的业务价值进行复盘，对数字化技术方案进行持续迭代，对潜在业务场景进行持续探索。

图23：方案支持与迭代

用户培训与应用推广：对业务场景、操作规范、云数据平台相关技术进行培训；制定应用推广计划，包括应用准备、应用推广启动、业务需求交流、专题应用开发、专题结果分析、应用评估总结、应用跟踪提升等环节；

业务收益复盘：通过业务部门的持续反馈以及对项目前后的业务指标的统计，通过定性判断、定量计算等多种方式，对数字化转型项目的业务价值与收益进行复盘，发现不足并寻找原因，从而指导未来的方案优化迭代；

数字化技术方案迭代：基于业务收益复盘的结果，对数据存储和计算进行性能调优，对数据资产管理、数据服务管理进行回顾与优化，对AI模型进行持续迭代与优化；

新应用场景探索：通过业务部门的持续反馈，确定企业新的业务场景、业务需求，并重复需求分析、方案设计、方案实现等环节，最终实现业务价值的验证。

04

典型行业实践案例

4.1 银行行业案例

企业概况

某银行是12家全国性股份制商业银行之一，以四大业务板块（公司、小微、零售、同业）作为品牌支柱。该行于2016年在香港联交所上市，于2019年在上海证券交易所上市，系全国第13家“A+H”上市银行。

截至2019年末，在全国19个省（直辖市）及香港特别行政区设立了260家分支机构，实现了对长三角、环渤海、珠三角以及部分中西部地区的有效覆盖。

面对经济新常态，该行顺应互联网信息技术发展新趋势和客户价值创造新需求，确立了“两最”总目标和平台化服务战略，坚持“服务实体经济、创新转型、合规经营、防化风险、提质增效”五项经营原则，打造平台化服务银行，为客户提供开放、高效、灵活、共享、极致的综合金融服务。

数字化愿景与整体目标

为实现全行数字化转型，打造行业领先的零售银行、普惠金融，该行需要通过建立云数据平台满足业务创新应用敏捷开发、大数据数据资产价值最大化、人工智能深入应用的需求，从而不断提升客户体验，进一步加强在股份制银行中的地位。

应用场景梳理

该行现有应用系统包括管理会计系统、绩效考核系统、风险预警系统、客户画像系统、反电信诈骗系统、反欺诈系统、监管报送系统等几十个基于全行数据分析完成的应用。

数字化现状梳理

该银行已建设大数据智能平台来推动数字化转型，其基本现状如下：

Oracle、DB2传统数据仓库几百TB级数据，几万张表、上万个ETL作业任务，全行大数据在快速增长；

ODS区是采用文本文件的方式从源系统获取数据；标准数据集市区为统一交换平台，为分行大数据平台服务；总行大数据平台区实现数据粘帖、数据汇总、数据应用；分行大数据平台区实现数据粘帖、数据汇总、数据应用；沙盘演练区：开发测试环境区域，供开发测试以及各种演示使用

只有少数场景使用规则引擎加手工修改脚本参数的方式实现人工智能预测。

数字化需求分析

该行现有的数据基础设施存在大量痛点，难以支撑数字化转型的进一步推进：

由于传统数据仓库存储及计算性能接近上限：无法满足全行数据未来几年的增长；

数据孤岛依然存在：没有沉淀数据资产，缺少数据治理系统工具及完备的数据标准；

无法快速赋能业务应用创新；对于某个分析业务的需求，用户从准备数据，汇集数据，建立模型，生成报表整个过程需要的周期太长，效率低下；

规则引擎预测准确率比较低、缺少自动化机器学习模型预测。

数字化技术方案设计与实现

偶数科技为了帮助该行应对数字化中存在的痛点，从数据战略、云数据平台整体架构、数据资产管理、数据治理、人工智能建模平台建设等方面为该行完成了详细的设计与实施方案：

图24：新一代云数据平台方案

数据来源：偶数科技

应用Oushu Lava，以基于HDFS的OushuDB高性能云数据仓库替代Oracle、DB2数据仓库，现有上百个节点可以支持PB级数据、可动态扩容，单一集群支持上千节点，满足行方未来十年数据高速增长，且跑批性能是之前传统数据仓库的数倍；

应用Lava数据治理套件实现数据治理，完成数据标准管理、元数据管理、数据资产管理；

应用LittleBoy自动化机器学习系统完成风险预警、反洗钱、反欺诈等应用场景的模型训练、发布、生命周期管理，显著提升预测准确率、召回率；

应用Lava数据服务套件，将数据资产、AI模型发布为数据与AI Rest API服务实现上层共享。

业务收益复盘

在偶数科技的方案成功实施之后，该行获得了以下方面的业务收益：

Oushu Lava实现上层应用敏捷开发、数据资产价值最大化，使得数据及时赋能业务，提升用户体验 、提高业务部门效率；

OushuDB实现了传统数据仓库所无法处理的海量数据、且系统迁移时间短；其在秒级时间内给出交互式分析结果，为业务人员针对重点问题及时决策分析提供了强有力的工具保障；

LittleBoy自动化机器学习系统提供的模型预测增强了全行风险管控能力、智能获客能力。

4.2保险行业案例

企业概况

某保险公司属国家大型金融保险企业。2018年，该保险公司的集团公司合并营业收入7684亿元；合并保费收入6463亿元；合并总资产近4万亿元。

该保险公司已连续17年入选《财富》世界500强企业，排名由2003年的290位跃升为2019年的51位；连续12年入选世界品牌500强。该保险公司所属股份有限公司继2003年12月在纽约、香港两地同步上市之后，又于2007年1月回归境内A股市场，成为全球第一家在纽约、香港和上海三地上市的保险公司。

目前，集团公司下设8家一级子公司、1家全国性股份制银行，业务范围全面涵盖寿险、财险、企业和职业年金、银行、基金、资产管理、财富管理、实业投资、海外业务等多个领域多家公司和机构；2016年开启保险、投资、银行三大板块协同发展新格局。

近年来，该保险公司坚持高质量发展，扎实推进保险主业价值和规模协调发展，努力提升投资板块贡献，积极做好银行金融服务，有序开展综合化经营、科技化创新、国际化布局，全面推进国际一流金融保险集团建设。

数字化愿景与整体目标

该保险公司在战略层面，确立数字化转型的“四大行动”：客户体验数字化、运营管理数字化、商业模式数字化和全面夯实数字化基础平台。

该保险公司通过科技化创新，持续深化业务与科技融合、数据融合、平台融合、线上线下融合、科研融合、生态融合，不断提升科技创新能力和赋能水平，提供企业级数据资产管理平台，统一数据标准，通过数据标准体系与数据指标系统建设，统一数据指标口径，统一数据服务，实现数字化平台、智能服务与运营服务。

应用场景梳理

该保险公司现有包括综合业务处理系统、个人渠道销售人员管理信息系统、团体销售人员管理信息系统、中介代理短险销售系统、客户主数据管理系统等几十个业务应用及分析系统。

数字化现状梳理

该保险公司已建设传统数据仓库来推动数字化转型，其基本现状如下：

几十个SQL Server、Oracle传统数据仓库，累计近PB级数据，上万张表、几千个ETL作业任务，集团大数据在快速增长；

数据庞杂而分散，前台和后台、内部与外部、全景汇聚数据、结构化与非结构化的数据，分散在不同大数据平台来分别进行加工处理；

面向少数应用系统使用规则引擎、传统机器学习算法实现人工智能预测，但是无法实现对模型的敏捷开发，上层各应系统无法便捷获取模型/数据服务。

数字化需求分析

该保险公司现有的数据基础设施存在大量痛点，难以支撑数字化转型的进一步推进：

集团与各省分公司业务指标一致性不理想，急需建立统一的数据模型与数据标准，提高数据一致性；

公司系统的数据质量问题，而数据差错的溯源比较困难；急需建立数据治理的闭环和数据质量体系；

数据孤岛依然存在，没有沉淀为全集团共享的统一的数据资产；

无法快速赋能各省业务应用创新；对于某个业务创新的需求，从分析数据，汇集数据，建立AI模型，完成自动打标签，直至生成报表整个过程需要的周期太长，效率低下。

数字化技术方案设计与实现

偶数科技为了帮助该保险公司应对数字化中存在的痛点，从数据战略、云数据平台整体架构、数据治理、数据资产、数据标准、元数据管理等方面上为此保险公司完成详细的规划设计和实施方案：

图25：某保险公司方案

数据来源：偶数科技

应用Ouhshu Lava，以OushuDB高性能分析型云数据库替代SQL Server、Oracle传统数据仓库，现有近百个节点可以支持PB级数据、可动态扩容，满足未来数据高速增长需求，且跑批性能是之前传统数据仓库的数倍；

应用Lava数据治理工具数据治理，完成数据标准管理、元数据管理、数据资产管理；

应用Lava标签和指标管理套件，完成标签和指标体系的可视化定义、建模、自动化打标签、标签展示、上线、权限管理、访问监控、统计分析、全生命周期管理；

应用Lava数据服务模块，将数据资产、AI模型发布为数据与AI Rest API服务实现上层共享。

业务收益复盘

在偶数科技的方案成功实施之后，该保险公司获得了以下业务收益：

Oushu Lava实现数据指标一致性管理、数据质量管理、标签和指标体系管理、数据资产价值最大化，为降本增效、实现精细化管理、赋能保险业务等起到重要支撑作用

OushuDB实现了传统数据仓库SQL Server、Oracle所无法处理的海量数据、且跑批任务所用时间大幅缩短近50%；并同时支持在秒级时间内为业务人员提供交互式即席分析结果。

4.3电信行业案例

企业概况

某国内电信运营商在国内31个省（自治区、直辖市）和境外多个国家和地区设有分支机构，并在香港、北美、欧洲、日本和新加坡设有境外运营公司，是中国唯一一家在纽约、香港、上海三地同时上市的电信运营企业，连续多年入选“世界500强企业”。

该电信运营商提供电话业务、互联网接入及应用、数据通信、视讯服务、国际及港澳台通信等多种类业务，能够满足国际、国内客户的各种通信需求，主要经营GSM、WCDMA和FDD-LTE制式移动网络业务，固定通信业务，国内、国际通信设施服务业务，卫星国际专线业务、数据通信业务、网络接入业务和各类电信增值业务，与通信信息业务相关的系统集成业务等。

该电信运营商在英国《银行家》杂志“2019年全球银行1000强”榜单上，按一级资本位列第107位、按总资产位列第98位。

数字化愿景与整体目标

近年来，该电信运营商实施聚焦创新合作战略，开展“一型两化”布局，聚焦非传统链接、平台型、应用集成型创新领域，快速提升自主研发、自主集成、自主运营、自主维护能力。

该电信运营商通过云数据平台建设实现“1+2”大数据管理模式，即“数据运营方+管理方+审计方”，在加强数据隐私保护的基础上，增强大数据数据资产价值及业务创新应用，扩展运营商大数据在客户画像、智能推荐等人工智能应用领域的深入发展。

应用场景梳理

该电信运营商现有包括话务流量分析系统、通讯费用管理系统、银行对账系统、综合维修系统、客户服务管理系统、反电信诈骗系统、客户画像系统等几十个基于全集团数据分析的应用。

数字化现状梳理

该电信运营商已建设大数据智能平台来推动数字化转型，其基本现状如下：

现有大数据平台基于Hadoop Hive 集群近2000个节点，存储全国几十PB级数据，上万张表、上万个ETL作业任务，全集团大数据随着5G的发展增长迅猛，日均数据增长量几百TB；

Hadoop Hive通过读取大量文本文件每日多次定时从源系统批量获取源端导出的数据；Hive集群每天几乎不间断的基于PB级数据为几十个应用分析系统的上万个作业任务进行跑批运算分析，目前一般在T+3得到跑批结果，随着数据量的增加，跑批时间在不断延长；业务部门基于大数据分析的即席分析时间长达数分钟；

大数据平台中的数据资产尚未实现服务化管理为业务人员其他应用系统提供数据服务；

只有少数场景使用规则引擎和传统机器学习算法实现人工智能预测。

数字化需求分析

该电信运营商现有的数据基础设施存在大量痛点，难以支撑数字化转型的进一步推进：

各业务部门需要在T+1完成跑批结果，同时希望进一步扩大跑批所分析的数据量--从现在的PB级到十PB级以上；

业务部门需要基于大数据分析秒级获取查询即席分析结果，但是目前即席分析时间长达数分钟；

缺少数据治理系统工具及完备的数据标准，没有沉淀为统一的数据资产；

规则引擎预测准确率比较低、新模型开发周期长，缺少自动化机器学习模型预测系统和自动打标签系统。

数字化技术方案设计与实现

偶数科技为了帮助该电信公司应对数字化中存在的痛点，从数据战略、云数据平台整体架构、数据仓库及维度模型建设、数据治理和数据标准建设、自动化机器学习平台建设、标签和指标平台建设等方面，分别为集团本部及省分机构完成详细的规划设计和实施方案：

图26：某电信运营商方案

数据来源：偶数科技

应用Oushu Lava，以基于HDFS与Hive共享数据的OushuDB高性能云数据仓库替代Hive 引擎，基于同样的PB级数据和仅一半服务器节点数（几百个节点），跑批性能较Hive提升几十倍，复杂即席查询分析可在秒级完成；

应用Lava数据治理套件实现数据治理，完成数据标准管理、数据资产管理，与AI Rest API服务实现上层共享；

应用LittleBoy自动化机器学习系统深度学习算法自动化完成关于客户画像、电信反欺诈等应用场景的模型训练、发布、生命周期管理，显著提升预测准确率、召回率；

应用Lava标签和指标管理系统，便捷实现标签定义、标签引擎计算、自动打标签、标签展示 、标签统计等。

业务收益复盘

在偶数科技的方案成功实施之后，该电信运营商获得了以下业务收益：

OushuDB对比原有Hive数据分析实现了几十倍的性能提升，可以满足业务部门T+1获得跑批结果的及秒级获得即席查询结果的需求，为业务人员针对重点问题及时决策分析提供了强有力的工具保障；

LittleBoy自动化机器学习系统提供的模型预测增强了集团客户画像、客户挖潜的能力；

Oushu Lava实现数据治理、数据资产管理和数据服务化全生命周期管理，实现数据价值最大化，使得数据及时赋能业务部门和数据科学家团队，提高了业务部门基于集团大数据开发智能推荐的效益。

审核编辑 ：李倩