InfoQApache Kafka 迎来了“后浪”( 二 )

一套新的开源大数据平台

本文插图
“Steam is the new file system for continous data."
有了 Pravega 提供的存储层以后，大数据架构将会变成如上图右侧所示，并带来以下改变：
在整个流水线中，无论有多少计算处理单元，原始的数据只会被保存一份。
不再需要根据数据的“时间”属性去选择不同的处理流水线 (streaming or batch) ，可以同时对实时和历史数据的聚合做低延时的实时处理。
计算处理逻辑统一，降低应用开发难度。
为了详细解释这三点，我们可以先用下表来简单对比一下 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 官方的做法是设计一个新的存储引擎去挖新坑。