网易数帆小助手

个人签名

114篇博客

好文分享| 细品中台(下)

网易数帆小助手2021-07-26 17:58

以下文章来源于微信公众号冷技术热思考 ,作者风轻扬,由于字数限制,分上下两篇。


「数据中台篇」


数据中台是目前企业规划建设最多的中台类型,对应的方法论和支撑技术也都最为成熟,但在认知上仍然存在一些模糊之处,方法论和实践上也还在快速发展,这一篇谈谈数据中台的关键问题和发展。


一、数据中台的定义和边界


数据中台是一种特定类型的中台,对照中台的概念,数据中台可以定义为“提供公共数据服务的组织”,职责主要是为整个组织提供标准化、高质量、高效率、低成本、高安全的公共数据服务。


数据中台以数据服务层为边界,这一点是阿里、我们及袋鼠云、数澜、云徙等数据中台厂商的共识。通常来说,在规划建设数据中台时也会同步建设一些上层应用(如报表、数据产品等),因为仅建设中台发挥不了效益,但这些应用本身并不属于数据中台,而是数据中台的支撑对象。如下图我们和数澜给出的数据中台架构图都非常清楚的说明数据中台以数据服务层为界,袋鼠云团队出品的《数据中台架构——企业数据化最佳实践》一书也提到“数据中台应该为可能进行的数据应用提供数据及数据模型支持”。


我们(网易数帆)的数据中台架构


数澜的数据中台架构


但当前也还有一些企业甚至是厂商没有将中台和应用清晰的加以区分,而是笼统的都作为数据中台的内容,如下图国云数据出版的《数字化转型方法论——落地路径与数据中台》一书给出的数据中台架构把大量的数据应用都作为中台的内容。我认为这样的观点是很值得商榷的,因为下图中的很多应用(如智慧门店、智能投保、教学诊改、图书推荐等等)显然并非一种共性能力而是具体的前台业务内容。


国云数据的数据中台架构


强调数据中台不包含应用,主要的原因并不是为了理清数据中台的概念,而是因为这对建设好数据中台非常重要:


  • 数据中台和应用在建设和管理上应当是解耦的。数据中台的内聚度很高,应该由一个团队来建设,如果由乙方来建也只能交给一个乙方(当然如果一个组织建设多个数据中台的话不同的数据中台交给不同的团队或供应商也没问题),但应用完全可以由各个前台团队分别建设,不同的应用交给不同的乙方也没问题。

  • 数据中台和应用所需的支撑能力非常不同。数据中台一般需要的是数据集成、数据开发、数据治理、数据仓库等技术支持,但数据应用则一般需要数据报表、敏捷BI、数据可视化乃至通用的应用开发机制支持。

因此,如果数据中台和应用不分,那么只能都交给一个团队或一个乙方来建设,这就人为的大幅提高了对团队或乙方的要求,导致建设难度无谓增加。


虽然我们一直致力于同时提供数据中台和数据产品的建设能力,但我们也一直秉承解耦的理念,从不宣扬数据中台和应用是密不可分的,这是因为关注架构的“高内聚、低耦合”已经深入我和团队的骨髓。


一个常见问题是数据中台要不要包含面向各个业务的应用数据层。这个问题各路专家的观点比较不一致,如:


  • 阿里《大数据之路:阿里巴巴大数据实践》一书介绍阿里的数据中台只是建设集团的数据公共层。

  • 我们集团级数据中台仅负责数据公共层,但严选、音乐等业务级的数据中台团队也会负责某些业务(但不是所有)的数据集市层。

  • 车品觉老师在《决战大数据》中强调“数据公共层最重要,基础层必须统一”、“决策分析最好放中台部门,业务分析可放业务部门”,这样看来品觉老师应该建议数据中台仅负责数据公共层。

  • 钟华老师没有直接解答这一问题,但书中提出“数据中台包含垂直数据中心、全域数据中心和萃取数据中心”,适合纳入中台的第一条标准是“功能和数据具备共享价值”,由此看来钟华老师也是建议仅包含数据公共层的。

  • 数澜在《数据中台——让数据用起来》一书中给出的数据中台建设范围包含了应用数据层。

汇总以上观点,我认为数据中台是否应该包含应用数据层取决于团队能力和需求灵活性。如果前台部门的数据能力较弱,对数据的需求变化较少,则数据中台包含应用数据层可能能提供更好的支撑,反之如果前台部门数据能力较强,需求变化多样,则对应的数据应用层最好由前台部门自行建设。要是从组织层面,也可以理解为看中台和前台哪个部门势力大。


二、数据中台怎么建


数据中台是对已有一系列数据分析、治理相关技术和最佳实践的综合和发展,不是一个全新的概念和全新的技术。因为有良好的理论基础,加之行业头部企业和服务商的共同努力,现在已经有了比较成熟一致的方法和工具支持。在数据中台行业,有一个“杭州五虎”的戏称,指的是都在杭州的五家服务商,我们、阿里、袋鼠云、数澜和云徙,其中前四家都是获Gartner认可的数据中台代表性厂商(Sample Vendor)。数据中台这个行业将来影响力壮大了,杭州可以说是“数据中台之都”啊。


我们在极客时间《数据中台》专栏中详细介绍了数据中台的建设方法,可能是业界介绍数据中台里最接地气的。袋鼠云、数澜等友商也都出了相关的书,当然也都可以参考,这些书会偏宏观一点。本文简要介绍数据中台建设方法中的核心内容。


数据中台建设方法的核心内容包括方法论和技术两个维度。方法论维度主要是分析框架及指标体系、数据仓库、数据治理和数据网关,技术维度主要是数据开发和数据湖。在此,我并未提及诸如坚定战略、顶层设计、组织变革等高阶方法论,这是因为我们认为数据中台的建设在组织的很多层次都可以进行,而且最好采取迭代演进的方式,因此大多数情况下并不需要那些高阶方法。在此,我也未提及诸如理现状、立架构等常规“咨询套路”,这些当然都是需要的,但面向数据中台的建设的针对性不强。


数据中台建设方法论


A. 分析框架和指标体系


指标体系是数据中台的牛鼻子,是数据中台提供的服务的主体。虽然数据仓库维度建模中的度量和指标很像,但我认为指标体系应该是一套独立的方法论,通过业务流程分析并经由原子指标、派生指标、修饰词等形成规范的指标建设和管理方法,是数据中台方法论超出传统数据仓库的创新之举。可惜的是最近两年的几本新书对指标的体系化建设大多语焉不详,详细介绍看起来主要还是在我们的极客时间专栏或阿里最初的那本书。


这两年我们在不断深入行业的过程中,越来越体会到分析框架的重要性。车品觉老师在《决战大数据》一书中曾多次强调分析框架的重要性,认为分析框架是“数据产品的养分”,是“数据收集的瞄准镜”。分析框架反应了核心的业务逻辑,如营销侧的AIPL、RFM等框架,零售的“总销量=流量 x 转化 x 客单价 x 复购”大逻辑,连锁零售要紧密围绕“门店数量、单店收入、品效、坪效”等做文章。如果不能深入的理解和灵活运用这些核心的分析框架,就不容易把数据中台规划建设好。因此,我认为在业务流程分析法之外,分析框架的指导也应该作为指标体系建设的重要方法


B. 数据仓库


数据仓库为数据中台建设提供了最主要的方法论基础。数据仓库领域有两套截然不同的基本方法,一个是数据仓库之父Bill Inmon所倡导的至上而下的方法,另一个是Kimball所倡导的至下而上的方法。从这两年的业界实践来看,维度建模方法基本上讲已经大获全胜,因为这个方法可以一个业务过程一个业务过程的实施,不需要顶层设计。这也顺应了之前介绍的分布式中台趋势。


C. 数据治理


数据治理为数据中台提供了核心保障。这里说的数据治理是包括元数据管理、主数据管理、数据标准、数据质量管理、数据资产管理、数据安全等系列方法的统称。这些方法中,元数据是数据中台提供服务的一部分,主数据管理和数据标准和数据中台OneID的概念比较接近,同时也为数据仓库的维度建模提供了规范的维度数据,数据质量管理、数据资产管理、数据安全等则分别用于提升数据中台的质量、成本经济性和安全性。


D. 数据网关


数据网关在落地时一般称为数据服务,但从思想和方法论层面,是一种网关。网关作为一种企业架构模式的流行,使得数据中台拥有一个清晰的服务形式和界面,这一点在经典数据仓库实践中是没有的,也属于数据中台相对数据仓库的创新。在网关层面,可以实现协议转换、语法标准化、逻辑模型与物理模型解耦及众多安全性和服务治理职能。


阿里的数据中台建设方法论是OneData,包括OneID、OneModel和OneService,我介绍的方法论和阿里核心是一致的,是对阿里方法论的细化和扩展。数据治理包含了OneID,指标体系和数仓对应OneModel、数据网关对应OneService。


数据中台支撑技术


A. 数据开发


数据开发是数据中台实施的最后一公里。指标的计算、模型的产出,最终都要经由数据开发动作来实现。数据开发又大致包括数据集成、逻辑开发和任务运维等几个方面。数据集成除传统的数据库CDC等技术外,还可能涉及互联网应用的数据埋点、文件传输、API集成等方式;逻辑开发需要专业的IDE、CI /CD、版本控制等系统支持;任务运维也需要全链路数据血缘、运维基线、一键修复等专业能力的支持。


B. 数据湖


数据湖为数据中台提供了便利的技术底座。数据中台之所以能够比较方便的低成本实施,和以HDFS和对象存储为代表的数据湖技术的成熟是很有关系的。在数据湖之前,传统的数据仓库技术非常昂贵,可伸缩性也不是很好,这就很难满足数据中台要集中多个系统、多个业务的大量数据的要求。有了数据湖,就可以把数据都集中到数据湖,在此基础上建数据中台就有了一个可控、低成本、可伸缩的技术底座,方便很多。不过在有些情况下因为成本、安全或政治原因,没有办法基于集中式的物理数据湖建数据中台,业界正在开发“逻辑数据湖”等技术解决这一问题。后面我会再具体介绍逻辑数据湖。


其实数据中台所需要的支撑技术远不止数据开发和数据湖两个,方法论的四个维度都需要各自的支撑技术。指标体系需要指标管理系统,数据仓库需要模型设计和管理系统,数据治理需要的支持系统就更多了(如元数据中心、质量中心、资产中心、安全中心等),数据网关作为对外服务接口对性能和管理的要求则非常高。因为这一节重点是介绍方法而非技术,所以没有展开说明。


小结一下,数据中台的建设方法主要是在分析框架指导下通过业务流程分析梳理指标体系,采用Kimball为主的数据仓库建设方法完成数据模型的设计和开发,并以数据服务的方式提供,同时通过数据治理保证数据中台的质量、成本经济性和安全性


三、数据中台前沿趋势


上一节介绍数据中台建设的基础方法,此外,以下前沿进展和趋势也值得关注。涉及前沿很难给出比较全面的综述,我说的这些主题都是那些业界讨论比较多也有一定实践的小热门主题。


1. (准)实时数仓和批流一体


我之前曾经提了个口号叫“人人用数据,天天用数据”,现在看这个口号似乎得稍微改一下,应该是“人人用数据,时时用数据”,因为基础比较好的企业已经在实践实时数据中台了。我说的实时数据中台指的是所有实时性超越T+1的数据中台,大概率是10分钟到小时级的需求,并非那种秒级的高实时需求,因此其实是准实时。举几个例子,音乐算法的A /B测试需要半小时出结果,有些先进的连锁零售点已经可以做到每天配送2次或更多,物流调度每天也需要多批次,这就需要小时级的决策支持。


实时数据中台的建设方法论和普通(离线)数仓是一样的,但所需要的技术支撑却大不相同。这是因为典型的Hadoop系数据湖技术支持不了这样的实时性需求,计算引擎也需要由典型的MapReduce / Spark换成Flink。我说的是Hadoop体系的技术栈,传统技术栈我还不好判断。


虽然实时数仓已经有不少的案例分享,但因为缺乏成熟的技术支持,目前大多数采用Lambda架构,和离线数仓是完全独立的两条链路,由此导致大量的冗余,整个架构高度复杂,成本高,且实时部分的能力受限。也有采用Kappa架构,也就是完全用Kafka+Flink这样的实时技术来实现的,但在我看来这些案例并非能力全面的数仓,在转换汇总计算复杂度和数据保留周期等方面都存在严重不足。


业界多个机构和社区都在努力研发一套基于Hadoop体系真正全面支持实时数据仓的技术,核心是“湖仓一体”和“批流一体”。


“湖仓一体”就是在HDFS体系内支持实时数仓,主要的苗子是Delta Lake、Hudi、Iceberg三剑客,但我们觉得都不太理想,Delta Lake因为Databricks背景和Spark绑定过深,Hudi虽然阿里初步解决了Flink兼容性,但和Spark耦合的痕迹仍在,且架构比较复杂(如对HBase有依赖),Iceberg的架构最干净但功能也最不完整,且社区的发展方向有很大隐忧。我们、阿里和腾讯都在努力完善Iceberg,但我们也在大力研发另一个湖仓一体技术Arctic。Arctic的优势是对底层依赖最少,基本有HDFS的地方就能跑,且和任何一个计算框架都没有强耦合,目前已经在云音乐和一些外部客户应用。


实时数仓从技术上还依赖“批流一体”。湖仓一体技术可以做到批和流的存储一体,但还需要进一步解决元数据一体、代码一体等问题,让离线和实时数仓链路全方位合二为一,消除资源和工作量冗余,这样实时数仓才能大范围普及。这块包括我们在内,整个业界都还在努力。


2. 逻辑数据湖


在完美世界中,应该有一个集中的数据湖系统(如HDFS或对象存储)存储了所有数据并支持中台、数仓、算法等各种场景,但由于成本和安全等原因,这样的做法不可行或不理想,也可能因为目标是建设数据中台,数据湖并非重点,最好不要引入一套新的技术栈。如此种种原因,都导致需要发展逻辑数据湖技术,在逻辑层面将数据加以整合,但物理层面分散在原有系统之中。


逻辑数据湖的技术还在发展中,Gartner在今年刚发布的Hype Cycle for ICT in China报告中指出当前的数据中台实践采取的是把所有数据集中到一处的“collecting”模式,缺乏连接多个系统的“connecting”模式,现状确实如此。虽然一些产商宣称支持逻辑数据湖,但并非通过成熟的产品提供,而是根据客户的当前需求进行定制开发,这就导致逻辑数据湖的实施成本高,且不能满足后续的需求变化。要提供成熟的逻辑数据湖技术,需要做到数据源的自动接入、元数据的全链路打通、在一个平台进行数据开发、数据治理在一个平台统一进行、权限的统一管理等很多特性,让逻辑数据湖和物理数据湖在研发侧、运维侧、治理侧的表现高度一致。云巨头可能因为战略原因在这条路上不积极,他们的策略通常是说服客户从传统的TD、GP、Vertica等MPP迁移到Hadoop体系或自家的ADB、GaussDB等产品,包括我们在内的数据中台产商应该都认可这一路线,大家的区别在于产品力。


业界有几个和逻辑数据湖相关的概念:Data Mesh、Data Fabric、Data Virtualization。这些技术的提出者包括大名鼎鼎的Gartner和ThoughtWorks。这些概念都打着反对数据湖的旗号,但在我看来他们反对的只是物理上大集中的数据湖,他们推动的方向在数据中台的场景下自然会走到逻辑数据湖。这也进一步说明了逻辑数据湖已经成为一个很有影响力的新趋势。


可能在未来物理数据湖最终会是绝对主流,但在当前的技术环境下,逻辑数据湖兼容并包的体质才能满足更多场景。业界应该加强对逻辑数据湖的认知,不要认为数据中台就必须新建一套数据湖,完全可以在已有的Teradata、Oracle、GreenPlum、Vertica等基础上建。数据湖和数据中台的建设,除了collecting模式还有connecting模式。


3. CI/CD和DevOps


Gartner的Hype Cycle for ICT in China报告也提到缺乏XOps(DataOps、ModelOps、DevOps)技术支持是当前数据中台建设面临的问题之一。Gartner的提醒是对的,因为数据中台离前台业务仅一步之遥,对敏捷的要求较高,需要不停的迭代更新,另一方面数据中台是整个系统的中枢,又要保障稳定,解决这两者之间的矛盾,如果没有成熟的CI /CD等DevOps技术支持,建设的难度和风险都会增加。这里我统一使用DevOps术语,虽然可能DataOps的说法更时髦也更贴近数据中台的环境,但从抽象层面我觉得DataOps和ModelOps都是DevOps的特例。


DevOps能力并非是完全缺失的,我们和阿里都提供了一些支持,比如开发 / 生产环境的隔离和统一管理,数据测试等,但总的来讲,目前数据开发领域的DevOps能力和通用软件开发领域的成熟度还不能比。作为一个老程序员,我在两年前就觉得这是个问题,因此安排团队进行开发。要做到成熟的DevOps,需要很多环节的工具支持,如版本控制、灰度发布、测试自动化、环境隔离等等,这样才能在快速迭代中有信心高频发布上线。但数据开发和普通软件开发毕竟也有本质不同,核心是处理的数据量大,由此导致难以精确测试验证、测试时间长、错误导致的数据成本高等问题,所以得用不一样的手段,如测试通常就通过数据形态探查这样比较模糊的方式而不是普通软件测试通过精确的assert进行、测试数据集往往通过采用而不是构造(构造会造死你)的方式进行。


这个领域的技术和数据质量方面的技术是相通的,我在之前的文章([[数据基础设施创新如火如荼,主要方向有哪些(上)]]里提到目前国际上也有多家厂商在这个领域发力,如Bigeye、Monte Carlo、Great Expectations等,但似乎国内厂商都没有集成这些技术,当然前两个都不是开源组件,难以集成。


一个普通软件开发进到数据开发领域,大概会觉得这个世界怎么干啥都慢,就像《疯狂动物城》里的Sloth(树懒)一样。(话说我们有个同事就把我们的流计算平台取名叫Sloth,这程序员幽默我也很无奈)


四、小结


小结一下,数据中台是“提供公共数据服务的组织”,目的是为前台业务分析提供标准、一致、高质量、高效率、低成本、安全的数据服务。数据中台的范围以数据服务层为边界,不要包含更上层的数据应用或数据产品。数据中台建设方法的核心内容包括方法论和技术两个维度。方法论维度主要是分析框架及指标体系、数据仓库、数据治理和数据网关,技术维度主要是数据开发和数据湖。(准)实时数仓和批流一体、逻辑数据湖、CI/CD和DevOps是几个值得关注的数据中台发展新趋势。