详解数据中台
本文作者郭忆,网易大数据平台的负责人。
为了加深彼此的了解,我先简单介绍一下自己。我在网易主要负责大数据平台团队,对内服务于网易各个业务线(包括网易云音乐、严选、有道、新闻,以及已经离开网易大家庭的考拉),主要是为业务提供大数据建设需要的产品和技术;对外呢,主要帮传统企业实现数字化转型,提高运营效率,我们的客户涉及零售、教育、农业、金融、物流等多个行业。
前段时间,我带着团队,在网易完成了多个业务线的数据中台项目落地,有了一些量化的成果,也获得了业务方的高度认可。除此之外,我还总结了一套数据中台建设的方法论,以及经过实践验证的数据中台支撑技术体系,再加上自己在数据领域积累了十多年的经验,所以我觉得自己可以在这个时间点跟你聊一聊,到底什么是数据中台?如何来建设数据中台?数据中台有哪些应用价值?
说到数据中台,你肯定不陌生,从 2018 年末开始,它突然在大数据圈儿走红。大家聊天如果不提中台,好像就落伍了。也正是因为数据中台,大数据受到了前所未有的关注。作为一个数据人,我非常高兴,也感到责任重大,因为大家对数据中台寄予了很大的期望,把它当作企业数字化转型的金钥匙,投入了上百万,甚至是千万,希望解决企业经营效率的问题。但是我们也看到一些企业未能达到预期的结果,比如说,指标口径不一致造成数据不可信;数据经常无法按时产出,影响工作效率;敏感数据泄露,引发安全危机。最终的结果就是数据不好用,无法发挥应有的价值。所以有人泼冷水说:数据中台就是一个充满诱惑的陷阱,看上去很美好,但是根本不可能落地成功。那数据中台到底是陷阱?还是金钥匙呢? 为什么这些项目很难成功呢?
在我看来,这里面既有客观原因,又有主观原因:
- 客观上讲,数据中台的建设是一项系统性工程,从组织架构、支撑技术到流程规范,既要有宏观的顶层设计,又要有强有力的落地执行,所以对整个团队的要求会比较高;
- 从主观上讲,这些企业本身数据建设经验不足,或者还处于比较初级的阶段,不知道数据建设中有哪些痛点,更不知道用什么样的技术手段和管理机制去解决这些问题。
两方面的原因最终造成数据中台项目往往虎头蛇尾,开始的时候规划得很大,实际却草草收场。而我希望通过这门课程,帮你少走一些弯路。
如果你是一名数据开发,每天累死累活地做需求、排查问题,还天天被人怼,嫌质量差、嫌速度慢;如果你是一个企业的数据负责人,正在为如何建设数据中台而犯愁,不知道如何向你的老板描述数据中台的价值;如果你是一个企业的老板,觉得目前企业的经营太过粗暴,决策完全凭经验,拍脑袋决定,需要实现数字化转型,提高企业经营效率。
那么我相信这门课会对你有一定的启发和帮助,这也是我写这个专栏的初衷。
当然了,在你打开这个专栏之前,也许看到过很多“洗脑”的文章,比如《数据中台,企业数字化转型的利器》《迷信中台是一种病,得治》。值得肯定的是,这些文章很好地宣传了数据中台的理念,让数据中台一跃成为网红。
可如果你认真分析这些文章,就会发现它们太过抽象,很难有可以执行落地的方案,也缺少实践的案例,对应用价值的描述缺少量化的成果,更像是一些项目感悟。比如,赋能业务是这些文章反复提到的点,但具体如何赋能?赋能得怎么样?业务得到了哪些改变?这些却很少提及。
总的来说,这些文章与实际数据中台建设的距离比较远,可供学习和参考的内容非常有限。我相信,对你来讲,最想知道的是大量的实践案例,从概念到实现,如何来搭建一个数据中台,让数据好用。 我举个例子,很多文章会提及避免烟囱式的开发模式,可具体怎么做呢?如果你已经是烟囱式的开发模式,实际存在了很多分散的小数仓,那怎么样才能让它变成一个数据中台呢?我想这才是你最关心的问题。
这也是我写这个专栏最大的不同,那就是结合网易数据中台的实践经验,给你大量一线的案例。结合这些案例,你能由浅及深地了解数据中台如何在企业落地,而不仅仅浮于概念的表面。此外,在每篇文章结束前,我还为你准备一个思维脑图,帮你梳理每篇文章的知识点,让你形成知识体系,帮你融会贯通。
如果用一句话概括我的讲解方式,那就是从原理到实现,最后到实践。你从中既可以看到数据中台支撑技术的全貌,又不会错过每一个实现细节。配合大量的实践案例,你可以深入掌握数据中台的落地过程。
为此,我把内容划分了原理篇、实现篇。
在原理篇中,我会告诉你数据中台的来龙去脉,数据仓库、数据湖、大数据平台以及数据中台的区别,以及它们有什么样的内在联系,然后会跟你讨论什么样的企业适合建数据中台。最后,我会从全局的视角出发,讲解数据中台如何在企业落地。
通过原理篇的介绍,我希望可以回答你三个问题:什么是数据中台,数据中台解决了什么问题,如何来规划数据中台的建设。
实现篇是我讲解的重点,我会基于数据中台支撑技术的整体架构,逐一讲解每个模块的具体实现。
在这部分内容讲解中,我会遵循从问题入手,然后给出解决方案,接着评估解决的效果,最后问题解决不是一次性的工作,为了使得问题得到长久化的解决,需要借助产品化的实现方式,所以最后我会讲如何将管理方法沉淀成产品。
接着我会讲解数据服务化相关内容,比如告诉你为什么要实现数据服务化,如何设计一个数据服务。数据安全也是数据中台的核心内容,尤其是随着最近删库跑路的热点事件,安全问题也被企业越来越重视,那么我们将讨论如何实现精细化的权限管理,如何做好企业数据的备份。
最后,我会讲一下基于数据中台之上的通用数据应用(包括自助取数、可视化分析等)。在这个过程中,我会以电商场景为例,通过大量的案例,帮助你理解这些问题以及问题的解决过程。
通过实现篇的学习,你可以了解企业在数据建设中到底存在哪些痛点,如何解决这些痛点,这些经验和案例可以立即应用到你目前的工作中,帮助你解决当前遇到的问题(例如指标口径不一致、数据无法按时产出……)。
除此之外,我会以网易电商的数据中台为例,从项目立项、推进到成果汇报,详细地描述数据中台在网易电商的落地过程。同时我还会对数据中台未来的方向进行展望,包括实时数据中台、跨云数据中台、自动化代码生成能力、智能元数据管理和增强分析等热门技术方向的探讨。
总的来说,通过这个专栏,你将获得这样几点:
- 一线互联网公司数据中台的实践经验
- 大量实践案例讲解如何躲过数据中台建设的那些坑
- 可落地执行的数据中台建设方法
- 经过实践的数据中台支撑技术体系
最后,我想跟你说点儿掏心窝子的话,数据中台到底是陷阱还是金钥匙?我想这主要取决于你有多懂数据中台,把它用好了,绝对是企业打开数字化转型的金钥匙,用不好,那就是一个充满诱惑的陷阱。
因为我也曾和你一样,刚开始面对数据中台的时候,一点儿经验都没有,后来我一边探索,一边总结,不断反思和复盘,最终总结出自己的一套数据中台建设经验,我希望将这些经验分享给你,让你少走一点儿弯路,相信你只要肯下功夫学习,一定能够让数据中台成功在企业落地。
数据中台原理篇一
“数据中台”无疑是今年大数据圈最火的词,如果你关注数据相关的行业会议,但凡有数据中台相关的主题,人员都会爆满。去年 5 月,我作为演讲嘉宾参加了由 ITPUB 主办的中国数据库大会,一个 100 人的“数据中台”场次,最后涌进来 200 多人,前排地下、走廊、过道到处都挤满了人,还有很多人因为挤不进来在外面看直播,数据中台的火爆程度可见一斑。
除了支撑集团的大数据建设,我的团队还提供 To B 的企业服务,因此我也有机会接触到一些正在做数字化转型的传统企业。从 2018 年末开始,原先市场上各种关于大数据平台的招标突然不见了,取而代之的是数据中台项目,建设数据中台俨然成为传统企业数字化转型的首选,甚至不少大数据领域的专家都认为,数据中台是大数据的下一站。
那么为什么数据中台被认为是大数据的下一站呢?它与你之前遇到的数据仓库、数据湖、大数据平台又有什么区别?
今天这节课,我想带着这个问题,与你深入大数据的发展历史,先从数据仓库的出现讲起,途径数据湖,再到大数据平台,因为这样,你才能理解大数据发展的每个阶段遇到的问题,从而深入理解数据中台在大数据发展中的历史定位。
启蒙时代:数据仓库的出现
商业智能(Business Intelligence)诞生在上个世纪 90 年代,它是将企业已有的数据转化为知识,帮助企业做出经营分析决策。比如在零售行业的门店管理中,如何使得单个门店的利润最大化,我们就需要分析每个商品的销售数据和库存信息,为每个商品制定合理的销售采购计划,有的商品存在滞销,应该降价促销,有的商品比较畅销,需要根据对未来销售数据的预测,进行提前采购,这些都离不开大量的数据分析。而数据分析需要聚合多个业务系统的数据,比如需要集成交易系统的数据,需要集成仓储系统的数据等等,同时需要保存历史数据,进行大数据量的范围查询。传统数据库面向单一业务系统,主要实现的是面向事务的增删改查,已经不能满足数据分析的场景,这促使数据仓库概念的出现。
在 1991 年出版的《Building the Data Warehouse》中,数据仓库之父比尔·恩门(Bill Inmon)首次给出了数据仓库的完整定义,他认为:
数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的,不可修改的数据集合。
为了帮你理解数据仓库的四要素,我举个电商的例子。
在电商场景中,有一个数据库专门存放订单的数据,另外一个数据库存放会员相关的数据。构建数据仓库,首先要把不同业务系统的数据同步到一个统一的数据仓库中,然后按照主题域方式组织数据。
主题域是业务过程的一个高层次的抽象,像商品、交易、用户、流量都能作为一个主题域,你可以把它理解为数据仓库的一个目录。数据仓库中的数据一般是按照时间进行分区存放,一般会保留 5 年以上,每个时间分区内的数据都是追加写的方式,对于某条记录是不可更新的。
除了这个概念之外,我还要提一下他和金博尔(Kimball) 共同开创的数仓建模的设计方法,这个方法对于后来基于数据湖的现代数据仓库的设计有重要的意义,所以你有必要了解。
恩门提出的建模方法自顶向下(这里的顶是指数据的来源,在传统数据仓库中,就是各个业务数据库),基于业务中各个实体以及实体之间的关系,构建数据仓库。
比如,在一个最简单的买家购买商品的场景中,按照恩门建模的思维模式,首先你要理清这个业务过程中涉及哪些实体。买家、商品是一个实体,买家购买商品是一个关系。所以,模型设计应该有买家表,商品表,和买家商品交易表三个模型。
金博尔建模与恩门正好相反,是一种自底向上的模型设计方法,从数据分析的需求出发,拆分维度和事实。那么用户、商品就是维度,库存、用户账户余额是事实。
这两种方法各有优劣,恩门建模因为是从数据源开始构建,构建成本比较高,适用于应用场景比较固定的业务,比如金融领域,冗余数据少是它的优势。金博尔建模由于是从分析场景出发,适用于变化速度比较快的业务,比如互联网业务。由于现在的业务变化都比较快,所以我更推荐金博尔的建模设计方法。
传统数据仓库,第一次明确了数据分析的应用场景应该用单独的解决方案去实现,不再依赖于业务的数据库。在模型设计上,提出了数据仓库模型设计的方法论,为后来数据分析的大规模应用奠定了基础。但是进入互联网时代后,传统数据仓库逐渐没落,一场由互联网巨头发起的技术革命催生了大数据时代的到来。
技术革命:从 Hadoop 到数据湖
进入互联网时代,有两个最重要的变化。
- 一个是数据规模前所未有,一个成功的互联网产品日活可以过亿,就像你熟知的头条、抖音、快手、网易云音乐,每天产生几千亿的用户行为。传统数据仓库难于扩展,根本无法承载如此规模的海量数据。
-
另一个是数据类型变得异构化,互联网时代的数据除了来自业务数据库的结构化数据,还有来自 App、Web 的前端埋点数据,或者业务服务器的后端埋点日志,这些数据一般都是半结构化,甚至无结构的。传统数据仓库对数据模型有严格的要求,在数据导入到数据仓库前,数据模型就必须事先定义好,数据必须按照模型设计存储。
所以,数据规模和数据类型的限制,导致传统数据仓库无法支撑互联网时代的商业智能。
而以谷歌和亚马逊为代表的互联网巨头率先开始了相关探索。从 2003 年开始,互联网巨头谷歌先后发表了 3 篇论文:《The Google File System》《MapReduce:Simplified Data Processing on Large Clusters》《Bigtable:A Distributed Storage System for Structed Data》,这三篇论文奠定了现代大数据的技术基础。它们提出了一种新的,面向数据分析的海量异构数据的统一计算、存储的方法。关于这三篇论文,在这里我们不做深入的解读,如果对实现技术感兴趣的话,也可以查看我在文末提供的链接。
但 2005 年 Hadoop 出现的时候,大数据技术才开始普及。你可以把 Hadoop 认为是前面三篇论文的一个开源实现,我认为 Hadoop 相比传统数据仓库主要有两个优势:
- 完全分布式,易于扩展,可以使用价格低廉的机器堆出一个计算、存储能力很强的集群,满足海量数据的处理要求;
- 弱化数据格式,数据被集成到 Hadoop 之后,可以不保留任何数据格式,数据模型与数据存储分离,数据在被使用的时候,可以按照不同的模型读取,满足异构数据灵活分析的需求。
随着 Hadoop 技术日趋成熟,2010 年,Pentaho 创始人兼 CTO James Dixon 在纽约 Hadoop World 大会上提出了数据湖的概念,他提到:
数据湖(Data Lake)是一个以原始格式存储数据的存储库或系统。
数据湖概念的提出,我认为是 Hadoop 从开源技术走向商业化成熟的标志。企业可以基于 Hadoop 构建数据湖,将数据作为一种企业核心资产。
数据湖拉开了 Hadoop 商用化的大幕,但是一个商用的 Hadoop 包含 20 多种计算引擎, 数据研发涉及流程非常多,技术门槛限制了 Hadoop 的商用化进程。那么如何让数据的加工像工厂一样,直接在设备流水线上完成呢?
数据工厂时代:大数据平台兴起
对于一个数据开发,在完成一项需求时,常见的一个流程是首先要把数据导入到大数据平台中,然后按照需求进行数据开发。开发完成以后要进行数据验证比对,确认是否符合预期。接下来是把数据发布上线,提交调度。最后是日常的任务运维,确保任务每日能够正常产出数据。
如此繁杂的一个工作流程,如果没有一个高效的平台作为支撑,就跟写代码没有一个好用的 IDE, 用文本编辑器写代码一样,别人完成十个需求,你可能连一个需求都完成不了,效率异常低下,根本无法大规模的应用。
提出大数据平台的概念,就是为了提高数据研发的效率,降低数据研发的门槛,让数据能够在一个设备流水线上快速地完成加工。
大数据平台是面向数据研发场景的,覆盖数据研发的完整链路的数据工作台
大数据平台按照使用场景,分为数据集成、数据开发、数据测试……任务运维,大数据平台的使用对象是数据开发。大数据平台的底层是以 Hadoop 为代表的基础设施,分为计算、资源调度和存储。
Hive、Spark、Flink、Impala 提供了大数据计算引擎:
- Hive、Spark 主要解决离线数据清洗、加工的场景,目前,Spark 用得越来越多,性能要比 Hive 高不少;
- Flink 主要是解决实时计算的场景;
- Impala 主要是解决交互式查询的场景。
这些计算引擎统一运行在一个称为 Yarn 的资源调度管理框架内,由 Yarn 来分配计算资源。目前最新的研究方向中也有基于 Kubernetes 实现资源调度的,例如在最新的 Spark 版本(2.4.4)中,Spark 已经能够运行在 Kubernetes 管理的集群上,这样的好处是可以实现在线和离线的资源混合部署,节省机器成本。
数据存储在 HDFS、Kudu 和 HBase 系统内。HDFS 不可更新,主要存全量数据,HBase 提供了一个可更新的 KV,主要存一些维度表,Kudu 提供了实时更新的能力,一般用在实时数仓的构建场景中。
大数据平台像一条设备流水线,经过大数据平台的加工,原始数据变成了指标,出现在各个报表或者数据产品中。随着数据需求的快速增长,报表、指标、数据模型越来越多,找不到数据,数据不好用,数据需求响应速度慢等问题日益尖锐,成为阻塞数据产生价值的绊脚石。
数据价值时代:数据中台崛起
时间到了 2016 年前后,互联网高速发展,背后对数据的需求越来越多,数据的应用场景也越来越多,有大量的数据产品进入到了我们运营的日常工作,成为运营工作中不可或缺的一部分。在电商业务中,有供应链系统,供应链系统会根据各个商品的毛利、库存、销售数据以及商品的舆情,产生商品的补货决策,然后推送给采购系统。
大规模数据的应用,也逐渐暴露出现一些问题。
业务发展前期,为了快速实现业务的需求,烟囱式的开发导致企业不同业务线,甚至相同业务线的不同应用之间,数据都是割裂的。两个数据应用的相同指标,展示的结果不一致,导致运营对数据的信任度下降。如果你是运营,当你想看一下商品的销售额,发现两个报表上,都叫销售额的指标出现了两个值,你的感受如何? 你第一反应肯定是数据算错了,你不敢继续使用这个数据了。
数据割裂的另外一个问题,就是大量的重复计算、开发,导致的研发效率的浪费,计算、存储资源的浪费,大数据的应用成本越来越高。
如果你是运营,当你想要一个数据的时候,开发告诉你至少需要一周,你肯定想是不是太慢了,能不能再快一点儿?
如果你是数据开发,当面对大量的需求的时候,你肯定是在抱怨,需求太多,人太少,活干不完。
如果你是一个企业的老板,当你看到每个月的账单成指数级增长的时候,你肯定觉得这也太贵了,能不能再省一点,要不吃不消了。
这些问题的根源在于,数据无法共享。2016 年,阿里巴巴率先提出了“数据中台”的口号。数据中台的核心,是避免数据的重复计算,通过数据服务化,提高数据的共享能力,赋能数据应用。之前,数据是要啥没啥,中间数据难于共享,无法积累。现在建设数据中台之后,要啥有啥,数据应用的研发速度不再受限于数据开发的速度,一夜之间,我们就可以根据场景,孵化出很多数据应用,这些应用让数据产生价值。
本章小结
现在,回到我们本节课的题目:为什么说数据中台是大数据的下一站? 在我看来,有这样几个原因:
- 数据中台构建于数据湖之上,具备数据湖异构数据统一计算、存储的能力,同时让数据湖中杂乱的数据通过规范化的方式管理起来。
-
数据中台需要依赖大数据平台,大数据平台完成了数据研发的全流程覆盖,数据中台增加了数据治理和数据服务化的内容。
-
数据中台借鉴了传统数据仓库面向主题域的数据组织模式,基于维度建模的理论,构建统一的数据公共层。
总的来说,数据中台吸收了传统数据仓库、数据湖、大数据平台的优势,同时又解决了数据共享的难题,通过数据应用,实现数据价值的落地。
为了帮你把数据中台诞生的大事件串联起来,我做了一张时间图,在这个时间线里,你可以很清晰地看到数据中台诞生的前期、中期,和后期的大事件,这样可以帮你更清晰的掌握数据中台背景。
如果您觉得作者写的不错,请继续查看 数据中台原理篇2
版权声明
本站部分原创文章,部分文章整理自网络。如有转载的文章侵犯了您的版权,请联系站长删除处理。如果您有优质文章,欢迎发稿给我们!联系站长:
愿本站的内容能为您的学习、工作带来绵薄之力。
评论