关于数据:数字化转型时代的企业数据新基建-爱分析报告

93次阅读

共计 26520 个字符,预计需要花费 67 分钟才能阅读完成。

前言

刚刚过来的 21 世纪的第二个十年,是生产互联网蓬勃发展的十年,也是云计算、大数据、人工智能等新一代信息技术,即“数字化技术”疾速崛起的十年。
在这一时期,以信息服务为主的生产互联网行业,如电商、互联网金融、社交娱乐等,充沛享受了数字化技术带来的“数字化红利”,极大推动了其终端用户的消费行为与体验的数字化转型。
但相比于生产互联网行业在数字经济浪潮下的蓬勃发展,以传统线下服务、实体商品制作为主的传统行业逐步显得落寞。在国际局势不明朗、国内市场红利逐渐耗尽、存量竞争日益显著、人才老本日益高企、产业升级换代压力增大的当下,传统行业的经营与效益上正面临三十年未有之变局,在新兴的数字化业态冲击下,还同时面临着客群与市场绝对萎缩的困局。
因而,投资数字化技术,充沛接收技术带来的改革,推动企业数字化转型,从而实现经营策略由粗放式向精细化的转变,反抗经济周期带来的上行压力,将成为传统企业的必然抉择。
依据华为 & 牛津经济研究院报告显示,自 2000 年以来,金融、制作、ICT 服务、交通、公用事业、房地产、农业等传统行业的数字化技术投资的年复合增长率,显著超过以生产互联网为代表的数字化技术制造业。
图 1:各行业的数字投资增长

该报告还表明,过来三十年中,数字化技术投资每减少 1 美元,便可撬动 GDP 减少 20 美元,而 1 美元的非技术投资仅能推动 GDP 减少 3 美元,数字化技术投资的均匀回报是非数字化技术投资的 6.7 倍。这也阐明,驱动传统行业的数字化技术投资的能源起源,实质上是企业对效益晋升的谋求。
在数字化技术中,数据库、数据仓库、大数据平台和云数据平台等根底软件,形成了企业数字化转型的重要基础设施,即“数据基础设施”。随着各行业的数字化场景的倒退,新的业务挑战对“数据基础设施”的技术路线演进产生了极大的推动作用。
然而,迄今为止的数据基础设施倒退,依然难以彻底解决以集团型、多分支 - 企业为代表的大中型企业数字化转型的痛点。
比方,银行、保险等金融机构广泛采纳夜间“跑批”的形式对当日交易数据进行 ETL 解决,从而将数据汇总到数据仓库、数据集市中,供用户进行报表剖析与即席查问,但数据基础设施底层的简单查问性能,成为“跑批”后果时效性的次要瓶颈,这也影响了用户进行决策的频次和时效性。
再如,电力、电信等关乎国计民生、用户数量微小、IT 基础设施简单的行业,广泛面临的挑战是数据规模及其宏大,而数字化利用的计算与存储需要也及其微小。为了晋升工作负载能力,多集群的数据基础设施曾经成为行业广泛现状。由此,只管交易型数据库的“数据孤岛”失去了肯定水平的治理,但在数据基础设施外部,却因为多集群间的数据共享难题,产生了新的“数据孤岛”。
由此可见,数据基础设施的技术架构、性能与性能特点的一直演进和倒退,仍具备有限的设想空间。以“云数据平台”为代表的新一代数据基础设施,正逐步成为集团型、多分支企业推动整体数字化转型的最佳抉择。

目录

  1. 数据基础设施撑持企业数字化转型
  2. 企业数字化深刻推动,云数据平台价值浮现
  3. 以云数据平台为核心的企业数字化落地方法论
  4. 典型行业实际案例

1.  数据基础设施撑持企业数字化转型

在宏观经济走向中低速增长的明天,“重资产、薄利润、现金流短缺”等经营现状,愈发困扰着传统企业,产业降级任重而道远。
相比于从诞生第一天起就带有浓厚“数字化基因”互联网企业,许多传统企业对数字化技术的利用还处在摸索阶段。然而,中国经济曾经开始迈入“数字经济”的新阶段,疾速涌现和崛起的数字原生企业,以及数字化技术带来的竞争劣势,意味着传统企业如果不疾速接收数字化技术带来的改革,那么将必然无奈维持原有竞争劣势。
因而,通过踊跃接收数字化技术,重塑业务流程,拓展业务边界,将成为传统企业实现可继续倒退的必然选择。
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 为外围的技术体系的影响,克服了其在性能优化和并发等方面的缺点,对云平台进行了原生优化,尤其是在剖析型云数据仓库方面,能够反对计算与存储拆散,弹性可扩大,反对数千节点规模集群,虚构计算集群,湖仓一体,并对性能做了深度优化,从而大幅度晋升面向多张表、批量数据、简单表关联的简单查问性能。
2.  企业数字化深刻推动,云数据平台价值浮现
只管数据基础设施经验了漫长的演进历程,但从数据库、数据仓库到大数据平台阶段,数据基础设施在扩大能力、弹性能力、查问性能、易迁移性等方面,始终受到技术路线繁冗、遗留问题重重的 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 从上亿个模型中主动挑选出优化的模型,让用户在不理解算法原理的状况下主动选出最优配置,晋升业务效率。

爱剖析认为,“云数据平台”将来将成为以集团型、多分支企业为代表的大中型企业数字化的松软底座。
3.  以云数据平台为核心的企业数字化落地方法论
正如章节 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 模型进行继续迭代与优化;
新利用场景摸索:通过业务部门的继续反馈,确定企业新的业务场景、业务需要,并反复需要剖析、方案设计、计划实现等环节,最终实现业务价值的验证。
4.  典型行业实际案例
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 实现数据治理、数据资产治理和数据服务化全生命周期治理,实现数据价值最大化,使得数据及时赋能业务部门和数据科学家团队,进步了业务部门基于团体大数据开发智能举荐的效益。

报告编委
报告执笔
黄勇  爱剖析  合伙人 & 首席分析师
冯伟  爱剖析  分析师

正文完
 0