大数据如果从 Google 对外发布 MapReduce 论文算起，已经前后跨越近二十年。如今的大数据领域还像从前那么火热吗？过去一年，大数据领域都有哪些技术创新需要关注？它又将走向怎样的 2022 年？
在 12 月 28 日晚上的 InfoQ 年度技术展望大数据专场直播中，我们邀请到了蚂蚁集团计算智能部资深技术专家周家英，跟大家畅谈大数据领域在 2021 年的重要进展和 2022 年的发展趋势，希望能帮助你准确把握 2021 年大数据领域的核心发展脉络，在行业内始终保持足够的技术敏锐度。本文由直播内容整理而成，你也可以点击这里查看完整视频回放。
InfoQ：家英老师现在是蚂蚁集团在线计算、虚拟数仓和特征平台三个数据平台的负责人，或许您可以先跟我们聊聊在线计算的过去一年的进展。两年前在 QCon 上我就跟您聊过分布式计算引擎 Ray，当时 Ray 还是一个非常新的项目，过去一年 Ray 有什么新的动态吗？现在 Ray 在蚂蚁集团内部和业界使用情况怎么样？
周家英：
Ray 现在依然算是一个比较新的计算引擎，至少在国内，2021 年只是有更多人知道它，真正去使用的公司数量还远远少于使用像 Fink、Spark 这几个传统引擎的公司数量。
Ray 在 2021 年有两个标志性事件值得一提：第一个事件是在 2021 年年终，Ray 在 GitHub 上的 Star 数量已经超过了 Flink，从增速来看，这是一个非常迅猛的发展，而且它的发展曲线依然是上扬的状态；第二个事件，可能比较关注投资圈或技术创业圈的朋友也听说了，Ray 最早是从 UC 伯克利 AMPLab 孵化出来的一个项目，前年它已经独立出来成立了一家商业公司叫 Anyscale，2021 年 12 月份，Anyscale 获得了 1 亿美元的 C 轮融资，这笔融资把 Ray 在资本圈的整体影响力也带起来了。从数据技术发展趋势来看，我们认为这个方向是未来始终值得关注的，蚂蚁在这个方向上一直在做持续的投入，并且也得到了很多正向反馈。
蚂蚁内部还是在继续使用 Ray 去尝试和解决一些问题，我们三年前提了一个概念叫融合计算，现在这个方向依然没有变，而且现在融合的概念也逐渐变得更清晰。首先融合有一个点是 AI 的计算和数据的计算可以有更好的融合；其次融合也体现在多模态计算领域，我们通过 Ray 的 Low level API 结合应用场景，打造成一个定制的计算 Pipeline，这方面我们最近两年也有一些落地尝试。在蚂蚁 Ray 应用得比较多的场景比如在线机器学习，就是流加机器学习的模式，还有今年比较火的科学计算，可以认为是把分布式的 Pandas 的能力原生地跑在了 Ray 上面，而 Pandas 又可以接很多算法继续去探索和训练，这也是一种融合。还有一些可能偏垂直方向，比如今年我们投入了一部分精力去做运筹计算，它也是需要一个比较灵活的分布式编程框架对各个算法求解器做一些优化。另外还有我们之前做的图计算，比如流加图的模式，也是跑在 Ray 上面。目前 Ray 在蚂蚁的使用规模已经达到了数十万核 CPU 量级，发展很迅速，而且未来发展空间很大。
InfoQ：听起来 Ray 相比两年前已经有了挺多新进展，2022 年，您觉得 Ray 将会有什么样的发展？
周家英：
我个人觉得 Ray 现在比较清晰的方向有几个。首先 Ray 是以 AI 为中心的一种计算方式，它更多是想构建一种分布式计算生态，可能通过模型训练和推理，以 AI 这种偏灵活多实验的方式去构建相关的计算能力，所以 AI 肯定是 Ray 会重点关注的一个方向。其次，Ray 社区也比较关注 Python 生态，因为以前的计算引擎可能更多是基于 Java 或 Scala 生态，而 Python 是 AI 领域的标准语言，为 Python 做定制优化，甚至打造 Python 天然的分布式能力会是比较关键的一个点，所以围绕 AI 和 Python 的生态可能是第一个趋势。
另外我们也能看到，官方 Ray 社区在扩展一些核心 API 时是很谨慎的，社区始终没有把高阶 API 扩展出来，比如我们说的 Streaming 或者 Batch 这样的能力，反而是扩展了一些存储层面的能力。从这个角度看，我个人觉得 Ray 本身还是希望大家去利用这些偏低阶的 API 在上面去构建自己的能力，这些能力很可能是，比如说用这些低阶的 API 来组成一个天然的分布式 Pipeline，或者说在上面构建一些适用于自己场景的框架，这个框架有可能是我刚才提到的在线学习，有可能是运筹计算。从整个 API 的角度看，它应该是一个持续在分布式底层，持续徘徊和深耕的一个分布式计算引擎。
还有一些趋势可能会偏技术一点，比如说它现在开放了比较多的存储接口，而且我们在和社区沟通的时候发现，他们也会在存储的层面更多发力，从这个角度看，分布式计算如何更好地结合存储，无论是从 Ray 的发展方向，还是从大数据的发展方向，都是未来一个很大的趋势，这两者的结合肯定可以有更好的性能和更大的可能性。
InfoQ：所以作为大数据领域的从业者，2022 年大家还是很有必要多了解一下 Ray 这个引擎。过去一年跟很多领域内专家老师交流的时候，有很多人认为 Ray 未来的发展潜力非常大。
周家英：
过去一年我们也搞了一些 Ray 的活动，确实发现国内参与进来的公司和开发者越来越多，头部企业像 Uber、字节、英特尔等，都开始有一定规模的团队探索 Ray 这个方向，甚至是跑一些生态系统，从整个商业环境来讲，对 Ray 也是越来越认可。
InfoQ：下一个问题，想请家英老师从全局一些的视角，跟我们分享一下，您所观察到的过去一年大数据领域有哪些比较重要的变化和趋势？
周家英：
我个人觉得，现在大数据在国内的发展趋势主要还是靠互联网公司和互联网应用场景来带动。这两年，从所有头部互联网公司商业发展的角度来看，实时化是现在非常明显的一个趋势。业务的实时化带来的第一个点就是数据和计算的实时化，如果我们几年前聊实时化，可能更多说的是某些点的实时化，比如报表的实时化或者 UV、PV 指标的实时化，但目前已经进入了全面实时化的模式。这个实时化可能包括整个从传统的 T+1 数仓到实时数仓，数据洞察变得更快了。同时，实时决策也被提到了一个比较重要的位置。我认为全面实时化肯定是一个很关键的趋势。
另外，这一年我个人感觉，也跟一些互联网公司的同事交流过，大家的关注点从对某一两个引擎非常热衷，现在逐渐转变成，思考到底可以用哪些引擎解决哪些问题，也就是把计算场景化，从单引擎转向数据应用场景，技术最后还是要回到本源，即什么引擎能处理什么问题，以及什么问题和场景需要有哪些引擎一起处理和搭配，这样来通盘地看。
之前可能大家唯引擎论比较多，一个引擎可能想做 ABCD 几件事情，但有些是明显不擅长的。这一年计算场景化意味着回归到了数据和计算、还有技术应该天然是为业务服务的，从这个角度看，这是一个很好的趋势。
还有一个我们一直在提的，就是大数据和 AI 的融合。传统的数据计算从单一的计算模式变成有更多的融合，AI 与数据计算两套体系如何更好地融合在一起？围绕这个问题出现了很多有意思的方向和领域。还有一些可能是从 AI 的角度看，比如 AI 怎么能帮助数据计算做得更好，包括提升性能、更加智能化等等，也是很有意思的趋势。
InfoQ：刚才您提到实时化，确实可以感觉到这几年大家对于数据的实时性确实越来越重视了。不过我们同时也听到另一种说法是，未来可能会兴起近实时化架构，介于离线处理和实时处理之间的这么一种架构，它会比离线计算实时性更好，但是比实时计算成本低，大部分应用会使用这个近实时化架构，因为没有那么多工作非要用实时计算不可。您对此怎么看？离线、实时和近实时，未来分别将会如何发展？
周家英：
首先我觉得这两个说法都对，而且能够呼应上我们聊的前一个问题，就是大家不再片面地看问题了。纯离线和纯实时是数据的两个极端，这两个极端以前是由两种引擎能力代表的，一个是 T+1 的批引擎，一个是 Streaming 流引擎。从以前传统的唯引擎论，现在发展到围绕场景，有一些场景可以接受时效性不好，T+1 就够了，然后逐渐过渡到 T+H 小时级，再到分钟级、秒级，甚至再往前走到毫秒级。一方面是大家对于数据的时效性看得更加理智和客观了；另一方面，时效性真正反映的是背后应用场景的需求，比如传统的报表分析更多是从原来的天级别做到分钟级别，那对于这个场景来说已经是实时的了；再往前走秒级和毫秒级的实时，可能更多针对的是线上决策的场景。实时化在目前这个阶段，可能描述的更是一个趋势，而不再是形容某个引擎。
同时，实时化现在更多是个形容词，以前我们说数仓，今年会说实时数仓，原来说分析，今年会说实时分析，决策会说实时决策。这就意味着我们需要将很多能力结合起来，把一个传统离线的事情变成实时的，而不是用一个引擎去搭建一套能力，我觉得这是一个很关键的改变。比如现在实时数仓一定是有多种引擎配合，很少有用了一个引擎就变成了一个实时数仓。
另一个是从系统层面来说，各个厂商也不再只追求单一模式，流批引擎一直在互相追赶，今年 Spark 对流模式做了很多增强，Flink 也对批模式做了很多增强，甚至在往更强的 OLAP 能力去走。从这个角度看，其实厂商们也知道单独的一种能力已经没有太多的核心竞争力，或者说他们也希望有更强的能力去补全自己的技术版图，同时也可以提供更好的时效性的选择给不同的应用场景。所以回到刚才你的问题，近实时也好或者叫准实时也好，它一定是在纯流和纯批、离线和在线中间更细化的一个场景。大家更多从应用的角度来看，不同场景解决不同问题，背后一定是不同的计算能力和存储能力结合，来达到不同的数据时效性。
InfoQ：既然聊到实时化 OLAP，就不得不提今年非常火爆的 ClickHouse，它也是实时架构里面非常重要的一个开源组件。ClickHouse 其实在 16 年就已经开源了，但似乎直到去年热度和关注度才一下子变得特别高，您觉得这背后可能是因为什么原因？
周家英：
先不说 ClickHouse，其实 OLAP 本身从今年和去年就是一个重新被反复提到的关键点，我觉得背后是一个非常好的趋势，就是大家更加关注数据的使用场景，而非它的技术形态了。OLAP 重回高光是一个信号，意味着大家从关注数据过程计算（ETL 等等）回到了关注数据查询计算的能力。即“我用什么样的方式，可以在多少时间，得到多大量的数据计算结果”。前一阵很火的流引擎，更多是一种计算模式，只是一个数据链路中间的一环，很难成为终结者。
另一方面，OLAP 火了以后，今年整个 OLAP 圈还是挺热闹的，国外有刚才提到的性能很好的 ClickHouse、Snowflake、AWS 的 Redshift 等等，国内有 Doris、StarRocks、Hologres 等等。当我们真正回到从使用数据的角度来去看大数据架构设计之后，带出了一系列不同的系统，这些系统各有各的优势，各有各的解决方式。但是今年我觉得大家核心的一点还是拼性能，就是只要性能好就是可以委以重任的好引擎，其他的一些缺点，可能各个大厂都可以克服，但性能是很关键的一个点。
回到刚才你问的 ClickHouse，它确实算是所有这些引擎当中的一个佼佼者，一方面开源、没有所谓的技术壁垒，另一方面性能确实很好，再者它的架构比较简单，便于部署和二次开发，所以它是 OLAP 很好的一个代表。
InfoQ：不过业界一直也有一些唱衰 ClickHouse 的声音，上云一直是 ClickHouse 的痛点，因为它为了追求极致性能，没有选择存算分离、弹性扩展的技术方案，但现在又是云原生的时代。您认为云原生对于大数据来讲是必选项吗？所有的大数据技术都必须具备云原生能力吗？上云这个痛点是否会影响 ClickHouse 在 2022 年的发展？
周家英：
云原生是一种能力，是一系列功能的组合，它从中远期看是一个趋势，就是说我们未来希望有更多的计算系统和引擎具备这些能力，但是它不应该成为一个盲目的“潮流”，“潮流”更多就有点偏盲从了。我个人认为，很多好的技术产品要商业化，一定会朝云原生这个方向走，可能这两年叫云原生，后面又叫其他名字，叫法都没关系，但是肯定是朝这个方向往前走。
从另外一个角度讲，是不是任何一个大数据产品都要上云？都要去做云原生？也不一定。首先看云原生本身，它代表的是更灵活的扩展、存储计算分离、按需订阅和灵活的组合。上云的优势，可能要分两种角色来看，对于售卖能力的服务商来说（比如阿里云、华为云、腾讯云等等），肯定是想把更好的计算能力售卖给客户，那好的技术产品一定要上云，否则很难销售；对使用者来讲，云原生代表的是更低成本的使用能力，无论是开箱即用，还是免运维、云 DevOps 这些能力，都是使用者的红利。
但是刨除这两点，云原生本身也会带来一些问题。比如全云存储+计算的组合会导致性能降低，极致的性能可能会被打破，我们确实看到很多产品，走云原生化以后，上到 K8s、存储和计算完全分离之后，带来的性能下降可能会有一两倍，甚至更多。
所以还是要看具体的应用场景下需要哪种产品，以及这个产品到底是要服务于内部业务，还是要服务于外部客户，还有目前二者的关系是在一个什么阶段。我个人觉得，应该在一两年内，上云这件事情对于 ClickHouse 社区来讲，并不会是一个非常关键的目标，但是不排除很多公司希望把它做到云化，这也很正常。但是从 ClickHouse 本身来看，至少我觉得它目前的最大优势还是在性能和架构设计上。
InfoQ：除了实时化，前面您其实也有提到大数据智能化的趋势，包括经常说的 BI 和 AI 相结合，您觉得 2022 年这个方向上可能会有哪些新的趋势，BI+AI 结合会产生哪些具体的技术价值及应用价值？
周家英：
可以从宏观的结合与微观的结合两个方面来说，
宏观的结合，即 BI+AI 平台一体化，打通数据研发及模型研发体系，平台上全链路打通，使两种计算更加融合，典型的例子比如 Ray 的在线学习、科学计算、特征训练一体化等；
微观的结合，即把 AI 应用到 BI 的各个体系，打造智能数仓；或者通过 AI 来优化计算效率，包括用 AI 来优化物化视图、实现自动调参及无人值守、大规模调度等。
InfoQ：前面我们聊了实时化、聊了 OLAP，也聊了大数据智能化，基本上对大数据领域比较重要的一些方向和趋势都做了探讨。正好最近我看到了一篇文章，是 dbt 的 CEO-Trisan Handy 写的，他在文章里讨论了现代数据技术栈的过去现在和未来，并总结了未来可能会出现的一些创新点。其中有一些创新点跟我们前面聊的不谋而合，也有一些方向目前在国内大家讨论和关注的还不太多。
比如数据技术栈的易用性是很多人都觉得非常重要的一点。组件太多太复杂其实是大数据开源生态被诟病了很久的问题，当前业界很多企业都在沿着“融合”的方向做一些工作，在您看来，未来可能会出现什么都能做的统一数据平台/引擎吗？还是会继续保持现在这样各种引擎百花齐放、各有所长的局面？
周家英：
这篇文章是挺有意思的一篇文章，里面有些观念还是比较新锐的。首先说融合，各个层面的融合一定是趋势，现在应用场景是连续的，但是产品平台、计算系统、存储都可能是独立的，想做一件事需要拼接，费人费钱，所以趋势一定是慢慢融合。
对于一个互联网公司或者一个商业公司来说，在产品和平台这层，我个人觉得最终很可能会有两种产品可以常保永驻，一种是从计算层面上来看通用的一个计算能力研发平台，这个平台可以支持运维、研发、观测、报警等等工作尽可能一站式地完成，这肯定是一个大势所趋，而且很多公司都是这样做的；另外一种是应用平台，它更多的是面向某种场景下的业务研发。这两层未来肯定是大势所趋，而且从提高效率的角度来讲是必不可少的。现在这两者往往是不统一的，无论是在计算引擎的平台层，还是在业务研发的使用层，都是割裂的。
再往下是计算层和存储层，这两者我反而觉得，就像我前面说到的，它有统一的好处，也有分而治之的优势。从计算引擎的角度来看，一个引擎一定有某一个最强的能力，是被别人不可超越和代替的，这是它的立足之本，这种引擎还是会持续存在，但可能会慢慢往另外一个方向去延伸，这个延伸的过程是挡不住的。任何一个引擎在发展到一定阶段之后，绝大多数都会开始做一些所谓走出自己舒适圈的事情，但是在引擎这一层，我觉得很难出现一个真正在任何方面都很强大的系统、能统领所有的引擎，这个难度实在是太大了，而且从体系结构上来讲也不容易，计算引擎层面是这个样子的。
从存储的角度看，首先存储的格式未来一定会有两个方向，一个是行存，一个是列存，大数据领域可能列存更多被认为是一种标准的存储，未来这两者都会存在，但是这两种格式到底会是一个存储，还是两个存储，还是多种存储，我个人觉得他们可能会逐渐往统一的一种体系发展。因为存储往往是一层存储的 API，有行存、列存、文件等等，这是一层 API，下面是格式层，然后再往下才是真正的存储介质这一层，也就是我们说的 HDFS 这一层。未来存储可能还会有一到两个很好的存储产品涌现出来，但最终可能从企业的角度来讲，还是期望部署一套存储、但可以支持多类格式，这会是更好的一个选择。
从整个技术栈来看，从上面的应用层往计算再往存储，越往上统一的可能性越大，而且对于使用者体验的角度一定是更好的。但是在下面可能还是会有各个靠自己核心能力吃饭的系统持续存在，而且在某一些点上会有一些比较深入的体系出来，这个我觉得还是会百花齐放。融合不代表着生态引擎的减少，会有更多更好更专一的引擎出来，只是更容易联合了。
InfoQ：前面聊了很多技术和趋势，最后我们收个尾，早几年我们经常会听到“现在是大数据的黄金时代”这类说法，在您看来现在还是“黄金时代”吗？
周家英：
首先我觉得现在依然是“黄金时代”，甚至是从“黄金时代”开始往所谓“淘金时代”去走。以前还在黄金时代的时候，很多人还在仰望，还是想着开源的这几个东西会用就行，但是最近这一两年国内有越来越多厂商做出了自己的引擎，大家都开始真正参与其中。我经常说的一句话就是，大家去用一个系统，远没有去研发一个系统，或者说去制造一个系统更有感觉。目前国内整个趋势是开始越来越多地往真正去参与研发这个方向去走，所以是从“黄金时代”走向“淘金时代”。
InfoQ：那您觉得 2021 年大数据领域技术发展的速度算是快的吗？
周家英：
肯定是越来越快的，而且大家开始从不同的维度去看大数据，从单一的引擎、单一的计算逐渐开始看到更多层面。近几年依然有很多新的组件推出，只是成熟的时间和具体位置不一样，比如说国外目前正在关注的一些东西，可能在国内暂时关注的不太多，或者说两年以后国内才会开始关注多起来，这个可能大家会有不同的关注点。但我觉得整体从数量上来讲，不管是创业公司也好，创业的项目也好，开源项目也好，都是越来越多的。现在一定是一个非常强的爆发期，我觉得大数据还是一片蓝海。
InfoQ：感觉跟我最近从另一位老师交流中听到的想法不谋而合。现在大数据领域可能发展到了一个相对稳定的阶段，已经有了很多不同的组件，基本可以解决大部分问题，但是每一个不同的细分方向依然有很多可以创新的机会。从引擎的角度来讲，就只是能用、但未必好用。
周家英：
是的，很多一线工程师在做很多工作的时候还是很痛苦的，所以整个发展的过程还有很长，而且机会很多，我依然认为这是一个大数据领域蓬勃发展和爆发的时代。
InfoQ高级编辑
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论