Kafka 加 Flink 不是终点！下一代大数据平台 Pravega

文章来源：加米谷大数据

有人说世界上有三个伟大的发明：火，轮子，以及 Kafka。

发展到现在，Apache Kafka 无疑是很成功的，Confluent 公司曾表示世界五百强中有三分之一的企业在使用 Kafka。实时备份机制让它在推荐、广告等互联网场景中游刃有余，但是实际生产中还有很多不允许丢数据的场景存在。针对这类场景是否有新的技术和框架出现？

Kafka：大数据平台中的核心软件

据中国信通院企业采购大数据软件调研报告来看，86.6% 的企业选择基于开源软件构建自己的大数据处理业务，但大数据人都会感叹大数据领域开源项目的“玲琅满目”。很多软件只经过一两年就形成一次更替，经过多年的厮杀和竞争，很多的产品已经脱颖而出，也有很多产品慢慢走向消亡。比如 Spark 基本上已经成为批处理领域的佼佼者， Flink 成为了低延迟流处理领域的不二选择，而 Storm 开始慢慢退出历史舞台。 Kafka 在消息中间件领域基本上占据了垄断地位，终沉淀出了以这几个软件为核心的大数据处理平台。

那么现在的大数据架构下的底层生态已经足够成熟来帮助企业用户进行数字转型吗？哪些地方还存在优化的空间？

同为开源数据管道，却有不同命运。

回到 7 年前，Kafka 也肯定想不到自己会在大数据系统中起到这么重要的作用。2010 年， LinkedIn 开始研发 Kafka，初的设计理念非常简单，就是一个以 append-only 日志作为核心的数据存储结构。2011 年的时候，Kafka 提出了一个叫做 ISR 实时备份列表的机制，来保证高可用性。

运行过 Kafka 大规模集群的人都知道，Kafka 里面有很多数据持久化的问题。在一些早期版本中或者没有选择正确配置时，如果一个服务器失败（这在分布式系统里很常见），就会导致这个服务器端所存的数据在恢复之前无法再被取得，更有甚者，这些数据有可能就永远丢失了。仅仅作为一个日志系统，这也许是可以勉强接受的。但是当越来越多企业开始使用 Kafka 来传输和保存重要商业数据，没有高可用性是不行的。所以在引入了多备份机制之后，Kafka 脱颖而出，成为了当时整合流数据传输的集中式通道的，并慢慢进化出了强大的社区生态。

但企业采用 Kafka 之后，依然需要踩很多坑。为了应对多租户、支撑上百万 Topics 等要求，雅虎研发了新一代消息平台 Pulsar，并且在设计上采用了数据服务和数据存储分层的架构。2016 年雅虎将这套软件进行了开源，当时有人感慨：“如果 Pulsar 早推出两年，也许就没 Kafka 什么事儿了。“

对比 Pulsar，Kafka 的先发优势非常明显，在强大的社区支撑下，Kafka 背后的公司 Confluent 不断获得融资，估值高达 25 亿美元。但是 Pulsar 背后的公司 Streamlio，发展却不那么顺利，没几年就被 Splunk 以人才收购的方式合并到一起了。关于开源软件的商业模式很难用一两句话讨论清楚，但 Pulsar 一开始的目的是想做“更好的 Kafka”，它在技术上可以认为是成功的，并且是值得被借鉴和被采用的。

也就是在 Pulsar 开发的同时，戴尔科技集团的研发团队发现做一个更好的消息队列 /Kafka 并不能解决新一代大数据平台在数据存储层上的挑战，因此他们重新思考了数据处理和存储的规则，设计并开源了全新流存储”Pravega”项目（ https://github.com/pravega ）。通过一个全新的“stream”存储抽象层，Pravega 让上层计算引擎能更好和无缝去跟底层存储解耦：“所有计算机领域的问题，都可以通过增加一个额外的中间层抽象解决”。

一套新的开源大数据平台

“Steam is the new file system for continous data."

有了 Pravega 提供的存储层以后，大数据架构将会变成如上图右侧所示，并带来以下改变：

1. 在整个流水线中，无论有多少计算处理单元，原始的数据只会被保存一份。
2. 不再需要根据数据的“时间”属性去选择不同的处理流水线 (streaming or batch)，可以同时对实时和历史数据的聚合做低延时的实时处理。
3. 计算处理逻辑统一，降低应用开发难度。

为了详细解释这三点，我们可以先用下表来简单对比一下 Pravega 和 Kafka 设计哲学的不同之处，这也代表了流存储和消息队列的本质差异：

接下来我们可以就点再展开，以理解新系统的优势：

“数据无价，而计算可以重试”， 在左边使用 Kafka+Spark/ES 的大数据技术栈中，很多企业为了保证数据不丢失，必然对重要（甚至所有的）的数据进行 3 拷贝落盘的设定。一份 topic，在 Lamda 架构下，从 Kafka 到离线、实时计算上要形成至少 6 个拷贝。再加上多数据中心，比如说 2-3 个站点，那么一个 topic 就至少形成 12-18 个拷贝。而现在每天产生 PB 级别数据的企业不在少数，那就意味着这些副本也需要 PB 级别的资源去存储，成本相当昂贵。

而在 Pravega+Flink 这套技术栈下，Pravega 是一个抽象的存储接口，在这个流水线上所有的原始数据只被存储一份，然后将数据写到持久存储层如对象存储或 HDFS。并且如果选用支持高效 EC 纠错码的商业分布式存储作为 Pravega 的 long term storage，在保证数据的高可用高可靠性的情况下，对比 Kafka，就节省掉了相当多的数据存储开销。当企业的数据量达到 10+PB 级别后，Pravega/Flink + 商业存储模式远比完全使用开源软件自建要省钱的多。

在接受 InfoQ 的采访时，戴尔科技中国研发集团滕昱解释完这套产品后表示：“我认为，下一个十年企业用户真正需要的大数据平台就应该是这个样子的。“

大数据平台的几个发展方向

开发人员也需要有一个“整体”的商业思维。

丰富的开源项目能让一个大数据系统的初始搭建变得简单，Kafka+Spark/Flink 的 Lambda 架构已经很普遍，一定程度上降低了技术的入门门槛。但一个企业里的端到端方案，并不是简单的堆积一些大数据产品组件，用户需要的也不是 Hadoop、Spark、Flink、Kafka 等这些技术，而是要以这些技术为基础的能解决业务问题的一套完整的产品方案。

现在很多国内的企业，将建设一套解决方案的事情上升到了组织架构层面，形成各种部门，有叫大数据的，有叫基础架构的，有的专门管存储，有的专门管计算…每个部门各司其职，各自负责寻找各自的“局部优解”，比如用 Kafka 的大数据部门就觉得把 Kafka 做好就行了。但是比单个技术应用更重要的，是企业还需要整体去考虑规模化应用、运维管控和成本优化方面的事情。只有把整套架构放到一起，做好优化，同时考虑整体成本，才更具有优势。比如管存储的部门的 KPI 可能是基于有多少数据量来考虑的，那么做一个统一存储层的动力自然不足，但是这从整个公司角度来看其实是有问题的。

“做分布式存储远比做分布式计算更难。”

在一套大数据技术栈下，从数据采集到计算，到存储，再到底层的基础设施，难的往往是存储相关的这一块。

所谓的数字化资产，就是企业保存下来的原始数据。对于有价值的资产，在数据安全性上是不允许有闪失的。大家可以很清楚的发现，相对于计算框架的百花齐放，开源分布式存储项目上其实一直处于“不堪大用”的地步。因为任何软件都有 bug，当存储产品出现 bug 的时候，开源模式就决定了无法找到一个 24*7 的响应模式来帮助客户 fix DU/DL 的支持团队，这其实是没有任何企业用户可以接受的。所以你会发现，到后就变成了自建团队维护自己专属分支的结局，想想 Ceph 的历史上有多少 bug 已经无人问津的现实吧， Ceph 官方的做法是设计一个新的存储引擎去挖新坑。

未来企业数据量只会越来越大，当超过 EB 级别以后，现有开源的存储产品都会有一些基本设计上的问题，即使它们的架构图是那么“完美”。而商业存储产品在 2013-2014 年就已经达到 2-3EB 单个系统的体量，这种积累其实是开源存储产品很难在短时间跟上的。所以当数据量达到一定程度后，所有企业都需要去平衡技术和商业。

这也是 Pravega 被推出的一个重要原因，用开源技术连接底层存储和开源计算，解决“成本”问题。在项目启动早期，仍然可以使用 HDFS/Ceph/ 公有云去“试水”， 正式进入商业以后，可以使用商业分布式存储和公有云存储混布的架构，在满足上层计算完全通过 Pravega 的抽象访问数据无需更改的前提下，用户可以根据自己数字资产特性去自由地在公有云和商业云原生存储平台之间动态迁移，毕竟公有云存储对于绝大部分企业用户来说实在太昂贵了。

“技术当然很重要，但更重要的是顺应技术趋势去思考未来发展。”

从 2012 年开始，Mesos 的流行、Docker 的兴起，然后 Kubernetes 出现并一举打败 Yarn 和 Mesos，到现在整个基础架构正在全面往云原生方向发展。

另一方面，虽然公有云厂商总是宣传让大家“全面上云”，但是除了对公有云存储成本的担忧之外，企业用户更加担心的是数据锁定（Lockdown）隐患。尤其是没有人能保证公有云厂商不会进入自己的商业领域，企业必须选择将自己看重的数据资产放到自己能掌控的硬件环境下或者是更靠近数据产生的边缘端。所以未来的大趋势必然以混合云多云的方式为主。这也是为什么云原生存储对企业用户有吸引力，因为它和上面的趋势是契合的。

云原生重要的一个隐含意义就是做到端到端的存储计算动态可伸缩性。当负载增大时，负责这条流水线的底层架构可以自动感知变化并进行合理调度，并且是在没有 DevOps 人为干预的前提下。而当负载变小后，又可以动态释放多余资源给系统中其他流水线使用，如下图所示。这样可以在大程度上榨干硬件资源每一份能力。

面向传统企业，开源需做出改变

“一切人类活动都是经济活动，软件开发也不例外”。

AWS 曾表示：公有云至今只转移了世界上 3% 的 Workload，另外 97% 仍然还是传统的企业开发。

这 97% 的存量 ToB 市场跟互联网企业有着很不一样的商业模式，主要表现在以下几点：

，这不是一个“从 0 到 1”的市场。这些传统企业往往在本领域已经是头部，它们的营收一般在百亿美元以上，每年的增长可能只有 10%-20%。在它们选择新技术时候，一个 3-4 年的 TCO（Total Cost of Ownership 总拥有成本）往往是其 COO 首先考虑的指标。那么他 / 她必然要在公有云的“弹性”和“昂贵”中作出取舍，更不说上面提到的 Lockdown 的商业风险。

一般互联网企业喜欢的是全新的颠覆性的市场，用全新打法来追求爆炸性的增长率。对比互联网企业，传统企业自然在技术上取舍上会不一致。“先有再演化”的开源软件自然是不二选择。只是随着整体的经济形式变化，每个今天的新兴企业都有可能成为明天的成熟行业。 他们同样会面临技术使用上对成本的整体考虑，比如近两年就出现了从 AWS 等公有云存储回归私有商业存储的“归队”趋势。

第二，垂直细分领域在企业开发中相当常见。不同领域有不同的需求，比如在远洋运输和石油钻井平台行业中，网络连接甚至都不是一个“必选项”，那么其实也就不存在一个能满足所有行业的开源项目。更多是需要在理解这些领域挑战得前提下，有商业化支持的云原生存储计算的混合云方案。

另外一个例子是在很多金融公司和银行里面，对安全的标准往往是物理隔离或者是多年行业形成的一系列规范。绝大部分的开源软件其实完全没有考虑或者也没法考虑这类要求，必须借助商业软件才能完成。比如戴尔科技集团在基于 Pravega+Flink 的 Streaming data platform 上就加入了基于 K8S 的全栈安全特性支持，并且作为默认设置。

第三，在实践中，“ToB”和“ToC”另一个巨大的不同点在于技术方案不再由单个人来评估好坏，更多是一个企业决策者群体共同的决定结果。而这个群体里面每个决策者，又会因为各自代表利益的不一样，需要从很多非技术的角度去考虑。这甚至造成了企业开发中“慢速敏捷”的现状，稳定和兼容性的要求远大于新功能和快速试错的要求。

很多企业甚至表示，“我们不需要一周一个新版本”。因为光是协调升级线上系统的批复流程都需要 1-2 周，一个月一次的 bug fix 升级已经足够敏捷，6-8 个月的大版本升级也“足够好”，但是向后兼容是必须要保证的，而这在开源软件中往往很难做到。业界好的例子莫过于 Intel 的 CPU 指令集，为了大程度的保证向后兼容，x86 不得不一直维护着一些很古老的指令来保证所有的用户都不会因为新 CPU 造成上层程序的兼容出错。

有人说：“这就是企业开发的特点，和市场每年以 300% 甚至 500% 的速度快速膨胀的互联网企业本质上并不一样。只不过经过 10 年高速发展之后，大家终于开始把目光投向了这些巨大的存量企业市场。而这个时候，我们所有的技术，包括开源项目和云技术，都要做出一些相应的商业上的调整，才能抓住这些用户的心和市场（real money） 。”