十问“海外名声大噪”的现代数据堆栈：定义、架构特点及发展趋势

嘉宾 ｜吴英骏、李栋、王宇飞

采访 ｜赵钰莹

数据堆栈是近几年在海外方兴未艾的概念，其中，最知名的当属 dbt 的 CEO Tristan Handy 在 2020 年下半年发表的“The Modern Data Stack: Past, Present, and Future”(The Modern Data Stack: Past, Present, and Future)，在文章中，他将现代数据堆栈分成了寒武纪大爆发一期（2012-2016），部署（2016-2020），与寒武纪大爆发二期（2020-2025）三个时代。

在国内，红点中国的合伙人刘岚也在今年初发表的一篇文章中提到，国内也出现了一些在现代数据栈方面布局的企业。那么，到底什么是现代数据堆栈？它是哪些问题的解决之道？如何区分现代数据堆栈和企业内部构建的数据平台、中台、湖仓一体等架构？

本期《极客有约》，我们邀请到了 RisingWave Labs 创始人 &CEO 吴英骏、Kyligence 合伙人兼副总裁李栋、字节跳动数据平台-开发套件方向的负责人王宇飞共同探讨这一新晋技术概念，希望帮助国内开发者和感兴趣的朋友更好地了解现代数据堆栈。

本文将直播精华内容整理后予以刊布，以飨同好。

InfoQ 第一问：“现代数据堆栈”（Modern Data Stack）这个概念具体指的是什么？

吴英骏：我理解现代数据堆栈解决了从数据中提取“信息”的问题。以往主要采用结合 Oracle、DB2、SQL Server 等数据库软件搭建一套平台的方式，现在随着云的兴起和各种商业化创业公司的兴起，主要通过“现代”的方式从原始数据中提取信息。

王宇飞：现代数据堆栈的核心是企业数据上云，在此基础上，大数据从采集到应用的全链路被不同细分领域的 SaaS 服务支撑，并且这些服务是可选择和拼装的，这是堆栈的一个意义。我个人感觉，云数仓的演进进一步催化了各个细分数据领域里 SaaS 场景的发展，围绕云上数据全链路的建设过程，可以选择多个 SaaS 服务来解决。比如：第一，数据上云需要先选择一个云数仓；第二，数据落仓，需要对数据进行建设和加工；第三，需要具备元数据管理能力和数据治理能力来保证数据质量和成本；最后，需要反向 ETL 领域的公司推数据到营销系统或 CRM 系统之中。“现代数据堆栈”概念本身不重要，关键是要关注背后要解决的问题。但不得不说的是，国外能发展数据堆栈的核心是企业数据上云和 SaaS 发展比较成熟，国内的情况与国外相比还是差距比较大的。

李栋：技术的出现往往是要解决特定的问题，想要了解 Modern Data Stack 需要先了解 Modern Data Challenge。首先，从用户的角度来讲，数据安全合规的要求、不同企业技术架构的选型和限制导致数据难以集中储存在一个平台或数据库中，最终形成数据孤岛；第二，从需求方面，整个市场趋势变化很快，需要对新信息有特别快的反应速度；第三，在人力成本方面，企业面临如何用更低的 IT 成本来满足更多业务需求的问题。我认为现代数据堆栈就是充分利用云、AI、大数据等技术简化 data pipeline 来帮助用户提升数据使用效率和数据治理效率。

InfoQ 第二问：与现代数据堆栈相对应的还有传统数据堆栈，这二者之间有何区别？企业在从传统数据堆栈向现代数据堆栈转换的过程中，会不会存在一些中间地带？

吴英骏：与 20 年前相比，当今时代数据变得越来越复杂，但数据栈越来越简化，处理的问题也越来越复杂。传统数据库时代，往往需要招不同的工程师去解决数据库管理、导入数据、提取数据、运维等问题。之后，随着云的出现，将管理、运维等事情“外包”出去，企业不再需要招各种工程师，唯一需要做的就是点几下鼠标，拖拽几下或者写几个 SQL 就能全部搞定，帮助企业降低了成本。

王宇飞：现代数据堆栈，核心是基于云实现模块化，倾向于使用专精的组件构成。刚刚英骏老师也提到，传统数据堆栈，需要自己进行部署运维，维护成本较大，云帮助我们降低了成本。另外，随着云的发展和硬件存储成本的降低，数据处理模型也出现了从传统的 ETL 到 EL（T） 模式的转变，ELT 解耦了 EL 和 T，让数据集成系统专注于解决数据抽取问题，简化数据抽取链路的复杂度，使数据开发同学更专注于业务相关的数据转化部分。从字节的角度来看，数据中台的设计一开始就采用了 EL（T）的模式，近期数据集成组件也会开源出来，希望能帮助解决企业数字化转型过程中的数据集成问题。

李栋：云的引入在成本方面实现了很大的优化和突破，除了资源和 IT 基础设施本身的成本优化外，还带来了企业内部数据使用过程中协作流程的转变和优化。传统的数据使用方式大多以 IT 为中心，相反 Modern Data Stack 简化了流程，并以业务为核心。举一个我们服务的国内头部股份制银行的例子，在过去，传统的 BI 使用方式是堆砌报表，业务运营人员需要依赖数据开发团队来分析客户画像，业务人员什么时候想看什么数据完全取决于数据开发团队的资源排期。后来他们搭建了统一指标中台（指标中台是 Modern Data Stack 的一部分），业务人员可以在平台上自助地创建、使用和管理指标，消除对开发团队的依赖，整体效率大幅提高，完成了从以 IT 为中心向以业务为中心的转变。

InfoQ 第三问：刚刚聊到的云成本控制，不少公司过去一段时间都在抱怨收到的云账单费用太贵，这有解决方案吗？

李栋：在我们公司早期做云产品和业务的性能测试时，也经常会遇到一些血泪教训。后来我们总结了一下，这块也是需要从管理上入手的，我们会用指标中台的实践来管理我们的云成本：定义一个指标体系，除了管理所有的账单数据之外，更多的是去管理云资源的用量数据，除了一些结果指标外还要寻找 CPU 资源利用率、资源闲置率、超期使用率等过程指标。从过程上抓管理，通过这种方式，云研发的 Leader 只需要每周或者每天去跟下属们抓这些云的过程指标，确保没有资源的浪费，或者是在资源到期之后及时停掉，通过这些过程日积月累节省云资源。

王宇飞：我自己的理解是，成本可以从两方面来看，一方面是我们真正使用资源的成本，比如如果数据上云要用哪些 SaaS 服务以及一些实际使用云的资源，如果不上云，需要自己去私有化、部署、运维和开发，这个过程还是有开发成本的。最终要考虑这两部分哪个更划算；另一方面，其实海外也存在成本控制方面的痛点，比如有专门的公司提供云上成本控制相关的服务，把数据治理做得更好，在这个过程中帮助企业降本增效。

吴英骏：尽管大家都觉得 Redshift 或者 Snowflake 卖的很贵，但从厂商角度一直觉得自己卖东西不贵。要理解这件事，实际上要从另外一个角度看问题，卖东西的时候不是只卖机器，也不是只卖数据库，它其实还“卖人”；假设我们去看 Snowflake 这家公司，我们在云上面购买了一台机器，或者说订阅了一个服务，我们不仅仅是订阅了这个服务，我们还订阅了这个服务背后的一些工程师，这个成本就高了，哪怕电费都是非常高的。假设我们不去买这些服务，只是在 AWS 上开一台 EC2 的机器，大家看账单的时候，可能会觉得开一年这个机器的钱似乎可以直接买一台机器了，如果这样想问题，考虑的可能还不够完善，因为要买一台机器，还要考虑找谁去搬这台机器，我还要付房租，而且机器可能过几年又要淘汰掉了等等，如果把这些成本都算上，我觉得云成本没有那么恐怖。

当然了，我们作为用户来讲，肯定还是觉得云是非常贵的，因为最早的时候数据仓库如 Redshift 还是按照机器的数量来付费的，机器开着哪怕不用，还是照样需要为这台机器付费的。所以现在出现了所谓的 Serverless 这种 pay as you go 的方式，使用了多少资源就付多少钱。但是如果使用次数较少，你会看到账单还是比较低的，如果长期用，你会发现还不如去订阅一台机器，这个时候也会更加高效得使用资源。

InfoQ 第四问：如果在企业中推进现代数据堆栈，可能谁会最先推进，最先解决的是谁的生产力？解决的是什么样的问题？

吴英骏：推进现代数据堆栈，首先需要换掉数据仓库，再上其他的服务。因为数据仓库是现代数据堆栈的核心。而针对一些没有数仓需求的小公司，在 AWS 上开一个数据库也是可行的，只要服务在云上，就是整个生态中的一环，就可以连接生态里的其他组件，未来如果想换更加高端的数仓，迁移过程也非常简便。

王宇飞：不管是之前的技术栈还是现在的技术栈，本质上解决的都是让数据高效发挥自身价值的问题。在我的理解中，现代数据堆栈强调的更多是以云上数据为中心的平台技术和产品能力，但让数据发挥价值，还需要符合自身行业模式的一些方法论和沉淀。

推进现代数据堆栈，靠数据驱动、自身有较强研发能力的企业，一般通过自研搭建平台产品的方式解决问题；具有一定研发能力的企业，通常采用拼凑组合一些开源产品或者部分采用商业化产品的模式；一些传统或者初创企业可能会采用完全商业化产品。

现代数据堆栈可以解决企业内使用数据同学的生产力，使得他们可以更专注于解决自身业务问题，而不是数据质量问题或数据研发效率问题等。

李栋：在企业里推进现代数据堆栈，除了可以解决降本增效等问题外，还可以提升数据以及数据团队的价值。举一个电商平台的例子：在传统模式中，通过 ETL 开发各种宽表，每个宽表又支撑一些报表，久而久之就会出现宽表爆炸的情况，即便是存储在云上也会产生很大的成本。在数据湖上搭建指标中台，把数据以指标的方式进行统一管理，所以平台中维护的每个指标都是有业务意义的数据资产而不再是成本，一方面可以从业务价值角度更好地管理数据、提升数据管理 ROI，另外一方面还可以帮助数据/IT 团队从管理成本变为管理资产，不断提升团队价值和影响力。

InfoQ 第五问：这两年，国内的很多企业在解决数据问题上做了不少事情，比如中台、平台、湖仓一体等，这些事情和现代数据堆栈有什么区别和联系？

李栋：不论是国内的湖仓一体、数据中台还是海外的 Data Mesh、Data Fabric 等理念，核心都是解决数据使用和数据管理中遇到的各类问题。Modern Data Stack 的优势在于丰富的技术生态，企业可以根据自身实际情况在生态中选型，比如想帮助企业建立一个指标体系的时候可以考虑指标中台的方式。

王宇飞：数据中台、湖仓一体和现代数据堆栈应该不是一个维度和层面的概念。企业内部，数据中台应当具备平台能力、方法论和组织模式这三个比较核心的要素，三者结合在一起解决了企业内数据体系建设问题；湖仓一体本质上是从数据处理和存储的场景出发，降低不同场景需求下数据的移动和存储成本，在解决非结构化、半结构化和结构化的数据处理和管理的同时兼顾性能和成本；现代数据堆栈可以解决数据中台的平台产品能力方面的问题，现代数据堆栈中的中心存储和云数仓解决方案可以采用湖仓一体的技术方案。

吴英骏：在小公司中，各个团队之间彼此知道对方在做什么，可以使用 USB、Excel 等一些简单的方法传输数据，当发展成比较大的公司后，不同组之间传递数据变得复杂，需要中台这种统一的方式传输数据。在中台中使用的技术栈也可以是现代技术栈，这只是中台的一种实现方式。湖仓一体本质上说的是数据存放到哪里的问题，不管是数据湖还是数据仓库，它都是存储。而现代数据栈的核心是存储，只要存了数据之后，才有管理、分析和可视化数据的需求。现代数据栈的核心是“数据湖”，“湖”的周围是一些生态。

InfoQ 第六问：国内外目前对这件事情的热度差别很大，具体是什么原因？

王宇飞：本质上还是发展阶段不太一样。数据堆栈的核心是基于云，目前国内云的发展和普及度与海外相比还存在一定差距；从客户偏好上来说，国内的客户更喜欢用 All In One 的解决方案。这背后主要有几点原因，一是国内平均 IT 基础能力更差一些，让客户在一个场景的不同细分领域选择不同的产品和解决方案，对客户自身的 IT 要求是比较高的，另外一个原因是国内云 SaaS 产品之间的标准化程度没有海外那么成熟，这也导致目前不同 SaaS 组件之间的成本比较大。

目前来看，整体 All IN ONE 的解决方案对国内企业数据上云和数据化转型过程来说，成本更低。除此之外，ALL IN ONE 还有组件内部联动性和组件之间数据共享方面的优势。举个例子，比如在使用  DataLeap 开发平台的过程中，除了写 SQL、配置任务依赖、部署发布耦合运维管理之外还需要拿到元数据平台的信息去提效整个开发过程，在上线前加上治理平台提供的数据质量检测能力，整个操作链路对用户来说是更闭环而不是跨多个产品的方式，这是核心的操作链路体验一致性方面的优势。

但这并不是说现代数据堆栈的这种多细分领域的 SaaS 模式做不到 ALL IN ONE 产品解决方案的优势，只是如果它做到相同程度，成本会高一些。

现代数据堆栈的兴起一定程度上也验证了我们当初的一些判断：随着 SaaS 细分领域的成熟也会出现灵活的对接需求。比如，虽然目前 DataLeap 开发套件是以 ALL IN ONE 的形式对外，但从比较早期的设计来看，也考虑了各个场景的产品能力，具备一定的独立性，尽量做到了开放兼容的能力，也可以去对接一些其他产品。从最后的发展来说，两种形态可能会是一个长期共存的状态。

最后想说的是，对于企业客户来说，不用过多关注现代数据堆栈、湖仓一体、流批一体等炒热的概念，我们需要看清它背后解决的问题以及给我们带来的价值，依据自身的发展阶段做合理的选择。

吴英骏：我说一下我为什么要做现代数据堆栈，我一开始是不知道这个概念的，等到我创业的时候发现，不管是什么公司都要提这个概念，而这个现象的本质就是，在国外大家非常注重生态，而生态在于打通，我把负责的部分做到最好，其他的部分放心交给其他厂商去做。在所谓的生态里，我可以只做我自己的事情，但同时也希望给用户一个选择的权利，我跟其他厂商的关系不仅仅是单纯的竞争关系，我们两者之间承担一种共建生态的职责而不是内卷。现代数据堆栈就很好地体现了生态这个概念，在现代数据堆栈中，每个平台都会去做集成。而在国内，这相对来说是一件难以接受的事情，大家更习惯一种大一统的解决方案。

李栋：英骏老师针对海外的一些观念和思路介绍的很详细，我多讲一下国内。举一个我们自己的例子，在过去的两年，我们帮国内的很多客户实践了指标中台。去年下半年的时候，我们观察到 Metrics Store 在海外也在兴起并出现了一系列的创业公司。当时，虽然 Modern Data Stack 这样的概念在国内还没有兴起，但是 Modern Data Stack 当中的一些细分领域已在国内有很多沉淀，就像我们的客户在指标中台这个方面已经有了实践。

但是，为什么国内就没有形成 Modern Data Stack 这样的生态或者说还正在起步过程当中？云是一方面，另一方面，国内基于细分领域的生态建设的成熟度还不够。但在过去的一两年，越来越多的云原生技术组件和公司都已发展起来，一些开源技术也都开始向云原生方面切入，开始形成这个生态，这些都是很好的现象。我对国内想形成自己的 Modern Data Stack 还是很有信心的，甚至因为不同国家地区的情况不一样，我们也许会形成一个叫“China Data Stack”的概念，更适合于中国本土的一些企业。

InfoQ 第七问：李栋老师刚才提到很多客户开始部署指标中台，这里面是什么在驱动？

李栋：在指标中台部分，核心要看解决的问题是什么。如前面谈到的，企业都需要把使用效率提升起来以及把数据管理做起来，最简单的一个问题在于数据口径的管理，可能大家都有数据仓库或者数据湖，也有客户在做湖仓一体的建设，也许不是云上，但是久而久之，大家都会遇到，也许就是两个部门的人在做数据分析时发现计算指标的口径是不一样的，比如一个零售的企业开会，可能华南区和华北区销售额的计算口径、计算逻辑各有不同，这样会带来背后的无论是数据开发还是业务决策的整个流程上的很多问题，所以就有了统一管理这些指标的需求，就产生了对指标中台的诉求。

InfoQ 第八问：传统 BI，自助 BI，还有指标中台之间的联系？

李栋：有两点最大的区别。一是一般企业想把 BI 用好，还是有一定的门槛的，比如各大 BI 厂商都有一些认证，想成为 BI 专家一般是需要专业认证的，这就带来了使用门槛上的区别，任何一个业务人员都有自己的 KPI 或 OKR，也就是自己工作中最关心的指标，指标中台是以指标为核心，在指标中台中可以定义、管理、查看、分析这些指标，并开展业务决策，这里的门槛很低，更不需要考认证等；二是数据治理方面，在多数 BI 系统中，核心管理的都是可视化报表，但是不同报表中很容易存在指标重复或口径不一的问题。通过指标中台可以统一管理所有指标的定义，无论是原子指标还是衍生指标，所有的业务用户或者所有下游的应用都可以在这个平台中获取到最可靠的数据指标，确保所有口径的一致性。

InfoQ 第九问：字节跳动在数据治理上面的一些关键动作？

王宇飞：数据治理对我们来说是一个比较看重的问题，这两年我们也在这方面投入了很大的精力，字节的数据治理还是有一些自身的挑战：字节的业务线比较多，组织比较扁平灵活，从上到下发布治理运动的模式在字节不见得行得通；另外由于业务发展快和复杂度高，我们的治理域问题涉及广，不只是成本治理。

基于这些挑战，我们也沉淀了一个全域的数据治理平台，它把像 SLA 治理、成本治理、报警治理等治理域全部都串联在一起，可以通过规划式路径一站式的解决多领域问题，提升治理效率。同时我们提倡“集中决策和分布自治”的理念，让不同的业务根据自身发展阶段，制定自己的治理目标。另外，平台也可以监控整个治理过程与最终效果，治理平台能力我们近期也会对外输出。

InfoQ 第十问：未来三到五年，在数据架构的发展方向上，国内和国外的发展状态和方向大概是什么样子的？

王宇飞：我个人理解，国内的数据架构随着云的发展会越来越加强整个生态的建设。现在看到，很多云厂商其实都是以 All In One 的形式去提供服务，本身也会有局部组件的能力变得越来越开放或局部组件也都在走向开源，像刚刚提到的字节跳动的数据集成工具即将开源，可能也会有一些其他组件开源出来，或者提供第三方对接能力，帮助完善国内整个数据生态的建设和发展。

我个人觉得，如果走到国外这么成熟的 SaaS 服务生态体系，还需要一定时间。

李栋：我觉得接下来技术的发展，云肯定是一个方面，另一方面是自动化或者智能化。因为无论是 AIOps 还是数据分析领域增强分析的概念，这些技术的背后都是更多地把 AI 的自动化技术应用到整个数据平台中。在这样的理念下，Modern Data Stack 中的很多场景都可以通过自动化来简化人工的工作。过去很多需要人力的工作被软件和工具所替代，在替代过程中，就需要有更多的 AI 方面的技术集成进来去实现一些自动化。

吴英骏：针对国外的情况，接下来可能会朝着几个方向发展。第一个方面，接下来会从 Subscription Base 全面转向 Consumption Base；第二个方面 ，所谓天下大事合久必分，分久必合，从 SaaS 角度来讲，我相信还是会有小的领域互相吃掉，这种也是比较良性的；哪怕是在云这个方面，现在有三朵云 AWS、GCP 和 Microsoft Azure，尽管这三朵云之间不会“互吃”，但我们也发现其实已经有一些工具统一了，比如伯克利大学最近搞的 sky computing，把比较割裂的体验做中和；第三个方面，就是我们在做的 realtime 这个方向。现在的公司数据量特别大，大家会更希望看到实时的结果，所以大家会看到现在很多软件都在做实时推送，同步的频率会越来越高，而我们做的就是对实时流进来的数据做实时处理，同时我们也发现哪怕是可视化的部分也已经有实时的倾向了，就比如之前可能是一张静态报表，现在大家会希望看到一张动态的报表，以上这几方面我相信是比较大的趋势