网易余利华：大数据技术升级脉络及认知陷阱

多年来，大数据技术经历了几轮更迭，在计算、存储、大规模落地等层面均取得了不错的进展，并在不断的成长和成熟，整个生态领域也得到了快速发展。目前，基于分析的大数据计算平台在各大公司发挥着非常重要的基础设施的作用。本期大咖说直播，InfoQ 邀请到了网易数据科学中心总监、网易有数总经理余利华结合他在大数据领域的从业经验，与大家分享大数据技术应用逐步升级的脉络，解读背后的业务需求以及认知陷阱。

关注的大数据技术：流批一体与 AI 应用

InfoQ：您方便简单介绍一下目前在网易负责的主要工作吗？

余利华：我目前负责网易的数据科学中心，这个部门是网易的大数据部门，为网易内部提供公共的大数据工具，包括大数据平台，以及 BI 等一些基础的通用软件。除了这些工具，我也负责网易的一些公共数据的建设，比如网易跨业务的数据，用户画像等公共的数据资产。目前，我们也有对外的商业化品牌网易有数，把我们用得很好的工具对外商业化输出。

InfoQ：您个人最近一年比较关注的技术或者应用场景是什么？具体原因是什么？

余利华：最近我们在关注的技术方向主要有以下两个。

第一个是流批一体。我们一直在做数据中台，我关注流批一体技术也是期望未来能够把数据中台从离线变成实时。从需求上来讲，流批一体在技术上要解决好两个问题，一是能解决存储统一的问题。受限于目前的技术，我们存储最新数据的实时表，和我们存储 T+1 数据的离线表通常是两张表，这两张表实际上是代表了一份数据，但是因为在实时性上有要求，通常就存储在不同的系统里，比如说离线的表存储在 Hive 里面，实时的表存储在 Kudu 或者 HBase 里面，这样造成的问题不仅仅是存储和维护的成本上升，使用也很复杂。做流批一体的存储统一就是希望把这样的两张表重新合并在一起，并且还能实现一些增量的消费，这样能够直接实时计算，在存储方向上我们也在做一些预研的项目。

解决完存储统一的问题之后，要解决编程语言的统一。现在采用的 Lambda 架构通常需要写两份代码，实时计算一份代码，离线计算一份代码，未来有可能做到流计算和批计算都用同一套代码，因为目前他们都已经支持了 SQL，未来有可能统一到 SQL。或许未来有可能在数据中台上做少量的变更，做少量的配置，就能帮我们把离线数据中台转成实时的数据中台，流批一体是一个大的方向。

第二个关注的技术方向是 AI 在大数据系统方面应用。首先是自然语言的交互，这也是目前热点的方向，很多的国外企业像微软都在往这个方向发展。自然语言交互是访问大数据比较自然的方式，举个例子，假设我们要问“这款奶粉最近的销售额是多少”，如果大数据系统能够直接告诉你答案，甚至给出一个图表，是不是我们非专业的人员也能用大数据了？当然，要做成这样还是非常难的，因为这里面充满了歧义，就像销售额，销售额指的是数据库里的哪个字段，哪张表呢？最近是距离多长时间，是最近一天还是最近一个月？充满歧义。我们之前也跟浙大的大数据实验室的老师做过交流，也做了一些自然语言到 SQL 翻译的测试，目前这块精度还不是很高，但是我们会一直保持关注。

AI 在大数据里面还有其他的用途，比如数据治理、数据管理，一个简单的例子就是，假设我们的一些表里有身份证，那我们应该能自动识别出这些具有敏感信息的字段，然后自动的匹配通用的规则，比如说给身份证打上很多的星号。而且还要关注一些校验的规则，比如检查这个身份证的质量好不好，未来身份证自带校验，我们是不是要直接匹配一个校验规则，帮助我们检测身份证是不是有效的，提升我们数据质量。目前，很多公司都在朝这个方向发展。

另外 AI 也能用于一些运维的途径。大数据的系统大大小小有几十个组件，部署起来特别麻烦，如何保证数据按时产出是一个复杂的问题。在这个方向上，我们需要去预测数据的产出时间，提前预警。很多时候，大数据计算都是在晚上计算，在晚上生成数据，这个计算过程特别耗时，如果不能提前预警，我们几乎是没有时间来处理紧急情况的。因为大数据的任务用时特别长，所以应该提前预警这样的数据，甚至让大数据给我们推荐一个任务应该配置什么参数、内存配置多大，这些应该是系统自动配置的，不应该让管理员去配置。这样不仅能节省人力，而且能够优化大数据资源的使用。未来通过这种自动运维，我们就能够实现自动驾驶的大数据系统，就像 Oracle 现在号称自己是自动驾驶数据库，未来大数据系统也是自动驾驶的。

InfoQ：最近几年，我们陆续看到业内很多公司在落地流批一体。根据您的经验，这个过程有哪些需要注意的问题呢？

余利华：从两个方面来看，一个是从语言同步来看，其实语言到 SQL 层面流跟批还是有所不同的，所以怎么能够统一语言，目前还要再探索。在存储方向上，之前在 HDFS 或者在对象存储上，没有一个存储能解决好数据的更新问题，但是如果我们对数据的实时性要求不是那么高的话，目前有一些开源的项目在做这个方向，未来有可能我们在数据湖里面具备实现更新的能力和实时数据的能力，这样我们就有可能把存储也统一起来，做了存储跟代码的统一，未来才有可能做到流批一体。

亲历大数据技术更迭：提升人效是核心

InfoQ：您方便聊一下自己经历了大数据技术的几轮更迭，每一个阶段的特点和主流的架构大概是什么样的？

余利华：我会从能效角度，就是用户使用方便程度、使用效率角度把大数据的技术划分为三个阶段，每个阶段大数据的人效都被提升了数倍。

第一个阶段是大数据诞生之初，以 Hadoop 的诞生为标志，这个阶段是解决了大规模数据的存储和计算的问题。Hadoop 的诞生使我们能够处理更大规模的数据，这个阶段重点是分布式技术，解决规模和性能的问题，以及后来的 Spark 也是为了能解决更大规模的数据，更高的效率。这是第一个阶段。

第二个阶段是 SQL 语言成为大数据编程的主流。Hadoop 诞生之初并没有 SQL，处理数据都要写代码，门槛太高。当时，图灵奖获得者、数据库领域的专家 Stonebraker 曾经批判 MapReduce 是一个技术的大倒退，原因之一就是 MapReduce 非常难用，比当时已经成熟的数据库 SQL 技术差得太远了。在编程语言方面，现在业内也提供很多尝试，比如 Java、Scala、Pig 和 Google 开源的 Beam 等，但这些语言的使用效率都远远赶不上 SQL。最终事实证明，SQL 才是数据处理语言的胜利者。

从我们自己的平台上统计，大部分的任务都是 SQL。大数据的 SQL 技术起源于当时 Facebook 开发的一个 Hive 项目。Hive 以后，SparkSQL 逐渐发展起来了，SparkSQL 可以支持更多的 SQL 标准，内存计算性能也更好，我们最近几年也在推动用 SparkSQL 来替代 Hive 系统，根据实测数据，从 Hive 切换到 SparkSQL 会有两倍以上的性能提升。我们自己也在做一个开源项目叫做 Kyuubi，它的定位非常类似于 HiveServer，它是一个 SparkSQL 的查询服务器，我们也正在往 Apache 社区推这个开源项目。在 SQL 的生态里面还有很多，包括 Impala，将 MPP 技术和 Hadoop 结合提供更好的查询性能，还有 Presto 等，当然目前 SparkSQL 还是主流。有了 SQL 之后大数据操作就已经简化了很多了。

第三个阶段是集成开发和管理的阶段。随着云和大数据开源技术的发展，大数据的基础设施和大数据技术变得比较容易获得，目前大数据的重点往往是怎么样去快速地构建大数据应用，提供大数据应用。构建大数据应用需要把各种大数据技术组合在一起，通过这种集成化的方式提高数据应用交付的效率。这里的技术涉及到数据集成，任务的开发、调度和运维，数仓的设计，数据治理，数据服务等技术点，只有把这些技术点组合起来，才能提供比较好的开发效率。目前这个阶段还没有形成统一的标准。举个例子，大数据测试就是一个还没有解决好的问题。很多时候大家做数据的开发和测试环境都是不分离的，在线上开发的代码随便检查一下就上线了，也没有任何的回归测试。所以我说，我们大数据整个研发还是不成熟，相比在线的 CI/CD 差得比较远。我们也在这个方向上尝试做出一个比较好的大数据开发和管理平台，能够把各个大数据的技术很好地组合在一起，从而提高应用的开发效率。

InfoQ：最近有关 Apache 软件基金会（ASF）宣布将其至少 19 个开源项目撤回到 Apache Attic，其中有 13 个项目与大数据相关，10 个项目属于 Hadoop 生态系统的事情引发了业内的广泛讨论。您对于目前整个 Hadoop 生态的发展有哪些想法和观点呢？

余利华：这个问题比较大，其实现在广义的 Hadoop 生态，我不把它定义为像 MapReduce 这样的东西，而是包含 Spark、Impala 等等。现在这些底层技术还是很成熟的，要性能有 Impala，要 SQL 全、性能也不错，有 SparkSQL 等等，而且云端也可能会提供这样的大数据服务。但是从我的角度来讲，怎么样把这些大数据的技术用起来，去快速地开发应用，保障我们的数据按时产出，这个是比较关键的。

对于大数据项目撤回到 Apache Attic，我觉得这件事情很正常，并不是每个项目都能成功。刚才我把 Hadoop 生态定义成包含 Spark 在内的所有大数据技术的集合，我们可以基于最新的、最主流的技术做自己的发行版，而淘汰的都是比较边缘的、很少人在用的项目。

湖仓一体：逻辑数据湖更实用

InfoQ：最近一段时间业内在湖仓一体的落地方面也有很多进展和输出，也想听下您对这一方面架构落地的建议。

余利华：湖仓一体这个概念，可能不同人有不同的定义。我先澄清“湖”和“仓”这两个概念，仓是指数据仓库，就是类似于 Teradata、Greenplum 这些系统，这些系统的特点是，数据要经过 ETL，形成定义良好的表，之后导入到数据仓库系统里面去，主要场景是数据分析和报表。数据仓库的优点是支持 ACID，支持更新，性能也不错，但是性能好是来自它的查询引擎跟存储是耦合的设计，这样查询能够用到底层存储的高级特性，比如索引，存储也能为查询做一些优化。性能好的另一个原因，是数据仓库一般有专用硬件。但是它的缺点也很明显，它没法处理这种非结构化的数据，也没法支持这种复杂的计算，比如机器学习。

湖是数据湖，数据湖其实是一套存储系统加上一些标准的文件格式，再加上一些数据查询和处理的系统。存储可以是对象存储，也可以是 HDFS，典型的文件格式有 Parquet、Orc 等。数据湖一般采用 ELT 技术，它强调数据先入湖，在数据湖的内部进行结构的转化，这种方式的好处是非常灵活，能够存储任何数据，也支持各种复杂的计算引擎，包括机器学习。其实 Hadoop 就是一套数据湖的系统。

数据湖也是有些缺点的，一个是它跟数仓正好相反，不支持 ACID，性能吞吐力还可以，但是很难做到及时响应，因为它为了通用性和标准化，存储和查询引擎不是深耦合的，同样的存储数据可以换查询引擎来查，但这样做带来的缺点是不能做得深度耦合的优化，一般没有什么索引结构。另外很多时候数据湖上面的负载是多变的，它不是一个专用的环境，所以性能不稳定，容易受到其他负载的干扰。

湖和仓有各自的优缺点。在企业内部，像网易，湖和仓一般是同时存在的，我们可以称之为“湖仓结合”。最原始的数据，比如说用户访问日志、数据库的数据，都会先导入到数据湖里面进行加工，然后比较关键的、用于决策的一小部分数据会导到数据仓库系统里面去。湖仓结合是能满足业务需求的，它既能处理各种复杂的负载，成本也不太高，并且也能用上数仓的一些好处。当然它也有问题，比如我要维护两套系统，数据可能要冗余一份，数据的一致性维护上也会存在一些问题，这就是为什么现在要提出湖仓一体的概念。

湖仓一体的定义有很多，我采用的是发表在 CIDR2021 会议上的一篇 LakeHouse 论文里的定义。论文里说，湖仓一体的主要思想是把仓融入到湖里，在数据湖的基础之上提供 ACID 特性，提供更好的查询性能。也就是说，湖能够一定程度上替代仓的功能，Databricks 公司的 Delta Lake 项目也是朝着这个方向做的。

湖仓一体的想法非常好，如果未来发展好的话，是能替代掉很多数仓的使用的。但完全替代数仓还是不大可能的，因为像数据湖的特点是能力比较强，什么产品都能用，这往往意味着它在某些方向上不会太精，所以它不能完全替代数仓。它能替代一些数仓的场景，但最终还是脱离不了湖仓结合。

在湖仓结合的情况下，我们的数据可能分散在湖里，分散在仓里，甚至很多时候，一个企业里可能还会有很多个湖，有可能云端有一套系统，自己的机房里有一套大数据系统，甚至可能有多个数据仓库。我们现在的理念是，做一个“逻辑数据湖”，虽然把这些数据分布在不同的地方，但是能不能让它看起来是统一的视图，在同一个地方能看见，这些数据有统一的标准，含义是清晰的，它的血缘等各方面的元数据信息都是完善的，这样的数据通过逻辑入湖，构成逻辑数据湖。这是性价比较高的一种方式，如果真的把数据全都导到一个湖里，它的改造成本是非常大的。

警惕数据中台的陷阱

InfoQ：在过往的职业生涯中，您有经历过或者说有了解过，开发者群体对于大数据技术或者应用存在哪些认知陷阱，具体的原因是什么呢？

余利华：我在工作中经常看到的现象是，开发群体往往比较关注技术本身，有时候会对技术要解决的问题，或者技术的价值关注得比较少。我自己以前也做开发，也有这个倾向，但后来，我负责部门之后就深刻的认识到，能说清楚技术的价值的重要性。所以我们的团队做产品、做技术之前都会去问问，做这个事情对用户有没有价值。

举个例子。数据中台是最近比较火的一个词，大家经常会听到别人说怎么去构建一个统一的数据中台。但是很多时候，这些人说不清楚数据中台的价值。我们做数据中台是业务需求驱动的，并没有去强求整个集团要一个数据中台，因为网易的每个业务相差是比较大的，比如电商跟教育明显就不一样，所以我们会有两层的数据中台，每个业务会有自己数据中台，集团层面也会有公共的数据中台，通过这样的方式来解决业务的问题。

之前我们数据中台立项的时候，从用户角度梳理出要解决的一些问题，在效率方面，我们当时面临的问题是找数据特别困难，一个业务有几万张表，而且这些表的命名还不规范，很难从中找到相应的数据。这就导致我们的业务存在大量的数据重复建设，交付的速度比较慢，平均需要一周的时间。针对这些问题，我们和业务一起共建了模型设计中心的产品，这也是我们数据中台的一个子产品，并且还获得了网易集团的一个技术贡献大奖。

通过这个产品，我们把业务模型做了规范，模型的复用度从原来的 2.4 提升到 9.6。也就是说，一张表原来是 2.4 个表的复用度，后来能做到 9.6 张表来复用。同时我们还做数据地图的产品，提升数据的效率。最终通过我们的数据中台产品，需求交付的速度从一周以后降低到 2.5 天。

在数据质量和成本方面，我们也做了很多的统计去量化我们的效果。比如说在质量方面，我们之前面临的问题是，每周都有十多个数据质量的问题，当时一个比较严重的事情是，我们有个运营在他们的季度总结大会上说，他来网易工作最大的困难是数据不符合常识逻辑，这让我们数据团队面临很大的压力。后来，我们上线了数据质量的功能，去找出线上的问题；还做了数据测试的功能，去找出更多代码的 Bug；也做了任务运维，保证任务能够按时产出。最终我们任务完成率提升了很多，研发的 Bug 下降的也非常多。

总结一下就是，我们做一件事情很多时候是从用户的角度来思考的，我们把遇到的效率的问题、质量的问题、成本的问题，都进行了量化，这样才能把我们的技术成果讲得比较清楚，而不是为了建设中台而建设中台，从而保证我们走的方向是正确的。

数据生产力的内涵与落地要点

InfoQ：在中台最开始火的时候，我就看到过网易对于中台方面的一些分享和观点，以及实践的案例。我最近也注意到网易对于全链路数据生产力有一些研究跟想法，您方便跟我们分享一下全链路数据生产力具体指什么？它的意义是什么吗？

余利华：很多时候我们都说大数据是一家企业的核心竞争力之一，但是怎么去判断一家公司的大数据应用的水平？看这家公司的数据量够不够大吗？还是看这家公司每年在大数据上花的钱？这些都不是太科学，我们用数据生产力这个概念来衡量大数据应用的水平，怎么样才算是企业有好的数据生产力，我们总结为一句话：人人用数据，天天用数据。

以前我们的数据都是数据分析师在用，或者是老板在用，但是这样用数据的人数和频率是非常有限的，决策的颗粒度也不够，很多细节的问题没有用上数据。事实上很多一线的岗位都是需要数据的，比如一个门店的店长，他可能需要看商品的销售、库存的情况，还要及时地补货，增加营收。营销人员要实时地看促销的效果，提升营销的水平。

只要能做到人人用数据，天天用数据，哪怕每天只是用数据改进一点点业务，长期的累计下去，企业也能得到很大的进步，这样数据就能转化为生产力，企业也就有了竞争力。

InfoQ：在大数据整个的发展过程当中，无论是数据的可视化，还是体验，或者是开发者对于数据的重视程度都在不断的提高，尤其是这两年，随着数据中台在企业内部的落地，帮助企业去打通数据孤岛，这些其实还不足以解决数据生产力的问题，对吗？

余利华：刚才提到了一些数据中台的作用，比如说提升效率了，提升质量了，降低成本了，但这些解决不了业务问题，也没法提升企业的大数据应用的水平。数据生产力是通过数据应用来实现的，数据中台最重要的是支撑好更多有价值的数据应用的落地，这样数据中台就会更有价值。

我们观察到很多客户要立项做数据中台的时候，总会带一些应用，比较常见的是带一些 BI 报表。但很多时候只有 BI 还是不够的，第一，BI 看数据不那么好看，之前有个业务方就跟我们反馈说，他们现在部门有五百张报表，但是他不知道从哪里看起。这些报表没有按照一定的数据分析的思路来设计，没有按照一定的业务和故事来组织起来，看起来比较杂乱无章。而且这些报表只能看，不能跟业务系统联动。

所以在数据生产力方向上，我们更强调做数据产品，数据产品是一类决策性的产品，它首先看数据比较容易，其次能跟业务系统联动。比如像网易严选做的供应链协同决策系统，它能生成自动补货的请求，发到采购系统里面去，让采购系统去执行采购动作，这就是一个典型的数据产品。我们的业务系统加上数据中台，加上数据产品，这三个构成一个数据生产力的循环。我们的业务系统为数据中台提供原始的数据，数据中台加工这些原始的数据，形成高质量的数据，以服务化的形式提供到我们的数据产品，数据产品生成决策又会把这个决策推回到业务系统。比如刚才说的补货数据产品，就是把补货的请求推送到我们的采购系统里面去。通过这样的数据生产力的循环，就能够提升数据应用水平。

我们内部的业务像电商，同时就有接近 20 个数据产品，而其他的业务也正在建设大量的数据产品。只有有了数据中台，我们建设数据产品才会更高效，才能支撑更多的应用，才能产生价值。

InfoQ：如果企业没有构建数据中台，仅用大数据系统做支撑也是 OK 的吗？会影响最终的效果吗？

余利华：我们说的数据中台也是建立在大数据基础上的数据中台，它可能强调的是数据的打通，强调的是以服务化的方式来提供，这样构建数据应用会更加快速一点。

InfoQ：从技术层面来看，数据生产力工具的技术生态大概包含哪几部分内容，具体每一部分是解决什么样的问题，网易是如何做的？

余利华：数据生产力包含三个层面的内容。第一个是大数据平台方向的，我们自己叫大数据开发计算平台，主要是帮助我们内部的业务，或者帮助客户去建立数据中台。

第二个是有数 BI，我们不仅仅把它定义成一个 BI 产品，更多把它定义成一个数据产品的研发工具，比如我们有数据门户、决策引擎等等这些产品，数据门户能以无代码的方式，开发一个数据产品出来，决策引擎也可以把我们决策的知识放在决策规则和决策引擎里面。我们之前内部的一些业务，它的会员运营系统找不到人来开发的时候，数据团队就通过这种无代码的方式很快地去搭建出来自己的数据产品。有了这样的无代码搭建数据产品的工具，我们就有可能为每个角色都创建自己的数据产品，这样才能真正做到人人用数据，天天用数据。我们一些业务已经用这样的工具构建了十多个数据产品。

第三个是通用的一些数据产品，比如说像标签系统，就是各行各业通用的一些数据产品。

通过以上三个层面，就能够把数据中台建设起来，把数据产品加工出来，从而推动数据生产力的落地。

网易有数大数据平台的演进与未来

InfoQ：您方便分享一下，网易的整个数据平台大概经历了几轮的更迭，目前的架构特点是什么样子的吗？

余利华：我们经历了几个阶段，第一个阶段是我们最早期的时候，当时是 09 年以前，Hadoop 不太成熟的时候，我们自研了一套计算框架，搭配了我们自己做的分布式文件系统，形成我们最早的一套大数据处理的系统。当时也是胆子比较大，做这样的系统。当时主要的用户还是自己，我们用这套系统给每个业务去开发它的数据统计的代码。

在第二个阶段，随着 Hadoop 的成熟，我们引入了 Hadoop，逐渐地把自己研发的框架淘汰掉了。这个阶段我们主要是保证 Hadoop 的稳定性、规模的问题，我们的用户也是业务线的一些大数据的专家。

第三个阶段，因为我们的应用、用户越来越多，这时候就考虑要把很多大数据的技术工具做产品化。我们做了模型设计、数据开发、数据治理、数据服务等功能，从而形成了我们自己的大数据平台。总体的目的是提高大数据的人效，让我们能够更快地做大数据的应用。

到未来，我们要对接各种其他的大数据发行版，比如 CDH，甚至也对接我们的数据仓库系统，比如像 GP 这样的引擎，使我们的数据应用、数据中台能够建立在各种复杂的环境下，能够跨发行版、跨湖、跨仓，从而形成一种更灵活的架构。

InfoQ：对于大数据技术的未来发展，您认为还有哪些是值得开发者和企业去多多关注的呢？

余利华：首先是大数据方面流行的开源技术，我们相信开源是标准，大家都要往这个方向去投资。当然，研究开源对我们自己找工作也是非常有利的。像在湖仓一体这个方向上，Delta Lake、Iceberg 这些开源项目可以关注起来。另外有些提升数据生产力的技术也建议关注一下，因为怎么去搭建数据产品，怎么去搭建数据应用，肯定是未来的一个重要的方向。有个开源项目叫 Dash，就是让数据科学家通过少量的编程就能自行开发应用，像这样的技术可以关注一下。

InfoQ：网易在大数据方面未来的重点改进方向大概是什么？

余利华：刚才基本上也都提到过了，第一个就是云原生大数据平台，大数据的技术未来可能基于 K8s 在运行，可能适配了一些云端的存储等等。我们现在因为一些业务出海的需要已经在适配了，比如我们大数据系统适配了 AWS 这样的云服务，未来也可能会适配其他的云。第二个就是实时的数据平台。现在数据中台都是离线的，未来希望能够支撑到实时的。因为数据实时化也是个趋势。第三个是 AI 在大数据系统中的应用，无论是自然语言的查询，还是在数据管理或者运维上的一些应用，都希望能做一些探索。另外，未来也希望能用无代码这样的工具，帮助各个行业去打造一些典型的数据产品。

嘉宾介绍：

余利华，网易数据科学中心总监，网易有数总经理，网易服务端技术委员会主任委员，2008 年获浙江大学计算机专业博士学位，之后加入网易公司研发第一代分布式存储系统和分布式数据库系统，并一直专注于后端数据存储处理方向。目前负责网易全链路大数据生产力平台以及数据库产品研发，支撑网易大部分互联网业务，并在零售、制造、物流、传媒等行业领头羊推广应用。