传统企业大数据架构的问题

上图是大家都很熟悉的基于 Hadoop 体系的开源大数据架构图。在这个架构中，大致可以分成三层。最下一层是数据采集，通常会采用 kafka 或者 Flume 将 web 日志通过消息队列传送到存储层或者计算层。对于数据存储，目前 Apache 社区提供了多种存储引擎的选择，除了传统的 HDFS 文件和 H ，还提供了 Kudu、ORC、Parquet 等列式存储，大家可以根据自身的需求特点进行选择。在这之上的数据计算层，选择就更丰富了。如果你想做实时推荐，可以采用 Storm、Spark Streaming 这样的流计算引擎对 Kafka 或者 Flume 传递上来的数据进行实时处理。如果你想进行客户画像，可以使用 Mahout 或者 Spark LMlib 里的机器学习算法进行分类。如果你想查看当天的销售排名，可以使用 H 、Impala 或者 Presto。如果想对某些商品的销售进行比较复杂的漏斗分析，则使用 HIVE 或者 Spark 可能会更合适。

当然，大家根据各自的需求，可以叠加上 Redistribution 缓存，ElasticSearch 全文本搜索，或者像 MongoDB、Cassandra 这些产品。所以，大家会发现，其实在大数据计算方面，并没有什么特别成熟的架构，大家所做的大多都是针对一些问题点不断进行创新、改进和修正，再把几个产品想办法整合起来。这是因为做为一个新兴的领域，大数据计算方面的技术积累还很不够，还有很多难点没有攻克，还处在一个不断成长的阶段。而在大数据技术开拓创新上，互联网企业是引领潮流的。目前的大量收到追捧的大数据技术产品，大多都是由互联网企业。做为大数据技术的基石的 Hadoop 的基本思想基于 Google 的 Map/Reduce 和 Google File System，Presto 来自于 Facebook，贡献了 Impala 和 Flume 的 Cloudera 虽然不算一家互联网公司，但是带有很强的互联网基因。国内的 BAT 等互联网企业也对大数据开源社区做出了很大贡献。

但这也带来了一个问题，那就是这些大数据产品即架构都是针对互联网企业的因为需求与场景设计的。虽然这些需求和场景具有一定的普适性，但是在企业的整体 IT 架构上，传统企业与互联网企业有着很大的不同。

首先，传统企业和互联网企业在专业技术人员配备上有很大的不同。互联网企业聚集了大量的高水平计算机软件设计开发维护人员，这是绝大多数传统企业所不具备的。这里的差别一个是在量。传统企业中，一个拥有几百个技术人员的信息中心已经是一个相当大的团队了；而互联网企业的技术人员往往都有数千人的规模，像 BAT 这样的企业，开发维护技术人员都达到了上万人。另一个差别则在质上。互联网企业中通常会有一支专门的平台支撑专家团队，有能力自行及时修复开源产品中的 BUG，保障系统服务的稳定运行。而由于薪资等方面的原因，传统企业往往很难招到掌握开源产品核心技术的顶级开发者。这给开源产品的使用带来的隐患。一旦开源产品出现的 BUG 等问题，无人可以及时应对，将会给企业的生产服务造成很大的损失。

其次，传统企业的 IT 架构也和互联网企业有很大不同。互联网企业的历史相对较短，而且具有以开源软件为基础自行研发应用的基因，各企业自己对各种技术细节业务逻辑都非常了解，大数据系统甚至是和业务系统紧密联系的，不会有太多的集成性的问题。而传统企业往往历史较长，在 IT 建设走过多种技术路线，往往有大量的架构不统一的遗留系统。很多企业过去曾经建设过企业数据仓库，现在又开始建设大数据平台，这之间又没有特别严格的划分，不仅造成很多功能的重叠，更是造成了很多的数据冗余，很多数据会在不同的系统中保留多份拷贝，甚至不少企业需要频繁地把同一份数据在不同的系统中来回传输。这就带来了很严重的集成性问题。

第三，相对于互联网企业，大多数传统企业的数据量其实并没有那么大。相比较 Google 每秒超 10 万次的搜索，支付宝双十一每秒超过 25 万笔交易，绝大多数的传统企业的数据量真没那么大，可能还不至于成为不可攻克的难题。对于这样的数据量，可能传统的技术就可以解决，而不一定非要用到 Hadoop 这样重的架构。而为了挖掘出这些数据中的价值，多源异构的复杂环境可能是一个更加麻烦的问题。

他山之石可以攻玉

有的时候，在考虑一个问题的解决办法时，从类似问题的解决办法中获得一些借鉴是一个不错的开始。

其实，在交易类应用领域，也曾出现过类似的情况。企业中运行这各种各样的应用系统，这些应用由不同的开发者开发，技术路线、体系架构、遵循的标准都相差甚远，造成了一个个信息孤岛，一些需要共享的信息，不能在系统之间交换，造成很多信息的滞后和数据不一致现象。

那么后来这些问题解决了吗？又是怎么解决的？————有人发明了中间件。

什么是中间件，并没有人对它做出一个科学的定义。总体来说，是一个为了解决分布异构问题而提出的一个概念它位于平台 (硬件和操作系统) 和应用之间，为双方或者多方提供的通用服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。 解决多源异构并不是中间件出现的唯一原因，但是是它解决的异构重要问题，一般来说，中间件具有以下特点：

1. 满足大量应用的需要
2. 运行于多种硬件和 OS 平台
3. 支持分布计算，提供跨网络、硬件和 OS 平台的透明性的应用或服务的交互
4. 支持标准的协议
5. 支持标准的接口

也就是说，中间件的主要作用，就是建立跨平台的标准化交互接口。按照应用场景的不同，中间件开源分为网络通信中间件、RPC 中间件、消息中间件、交易中间件、Web 中间件、安全中间件等。这些不同的中间件在实际功能与实现方式上各不相同，在各自的领域中发挥着不同的作用，但是都满足以上列出的特点，都具有上述描述的基本功能。

那么，为什么不考虑在数据应用领域也采用中间件技术呢？

数据计算中间件

为什么提出数据计算中间件这个概念？因为在开发数据应用的过程，大家通常都会被以下的问题所困扰。

- 需要跨系统跨平台操作，从不同的数据源的数据放在一起计算
- 需求变化频繁，不断出现新需求，老需求不断修改
- 业务逻辑与数据耦合过紧
- 复杂计算实现困难，执行性能差

而通过设置异构数据计算中间件，就可以很好地解决多源异构环境下的融合计算问题。当然，仅仅解决异构数据的交互访问还是远远不够的，要解决上面的困难，数据计算中间件还需要能够提供高效的开发效率，优秀的计算性能和方便的代码管理能力。综合起来，我们可以从下面几个方面数据计算中间件进行评估。

- 兼容性 （Cross-platform）

这里的兼容性主要是指的跨平台的数据访问能力。前面我们说到过传统企业 IT 系统的异大特点就是存在大量异构系统，这些异构系统之间的互操作性很差，数据计算中间件的首要任务就是打通这个壁垒，起到连通的作用，将不同异构平台中的数据集成到一起。

- 热部署 （Hot-deploy）

数据应用的特点之一就是需求变化很快，我们对数据分析的要求是无止境的，总是在探求新的目标，总是希望能够从数据中挖掘出更多的信息。因此，数据应用的需求变化是异构持续的常态。这就对应用的部署提出了新的要求，如果每次部署新功能模块时都需要停止服务，势必对服务的质量造成很大的影响。如果应用模块可以热插拔，不需要停止整个服务，模块之间也相互隔离，那么这个应用的运行就会更加平顺，服务质量也可以得到保障。

- 高性能 （Efficient）

数据计算处理的性能对于数据计算中间件也非常重要，即使传统企业的数据量没有互联网企业那么大，数据应用需要处理的数据也是具有相当规模的，高的计算性能是评价数据计算中间件的异构重要指标。虽然不存在异构硬性的性能指标，但是在可能的情况下，我们总是希望处理速度越快越好。

- 敏捷性 （Agile）

敏捷性在这里，强调的是开发的方面。正因为数据应用的需求会持续不断变化，因此开发也会是一个持续的任务，不会像传统业务应用一样在相当一段时间内保持不变。开发的敏捷性可以保证数据应用可以在尽可能短的时间内完成新功能的交付使用，在某些特定的场景中，这可能为企业避免巨大的损失。

- 扩展性 （Scalability）

数据计算中间件需要要很好的可扩展性，支持分布式计算，具备了这种能力，数据计算中间件才可能在实际的应用环境从容面对不同数据量的场景，并且在数据量业务量不断增长的时候，仍然保证自身提供的各种数据服务持续可用。

- 集成性 （ dable）

做为一款中间件，可集成性也是必须的。这里的集成包含两个方面，一个是对第三方软件的集成，一个是被集成到第三方的软件中。数据应用的场景非常多样，只有具备很强的集成性，才能在更多的环境中得到应用。

以上就是我们评估数据计算中间件的几个关键考量，可以简称为 CHEASE。如果在 CHEASE 对应的六个方面都得到很好的满足，那这就是一款优秀的数据计算中间件。

润乾集算器

数据计算中间件是一个全新的概念，目前数据计算方面的产品中，与之最接近的是集算器。集算器是北京润乾信息系统科技有限公司完全自主研发的一款轻量级大数据融合计算平台，一种针对结构化和半结构化数据的计算设计开发的新型计算引擎。集算器的设计目标，是试图解决描述计算的效率和实施计算的效率。集算器具有以下一些特点。

1. 为了达到设计目标，润乾公司首先为集算器设计了一种面向过程计算的脚本编程语言 SPL（Structured Precessing Language），可以方便地描述数据的计算过程。集算器采用了新的数据和计算模型，提供了丰富的基础计算方法，特别适合业务规则复杂的多步骤运算，让计算本身变得易于描述，从而提高代码的开发效率。

2. 集算器在内部的计算实现上，做了大量的优化工作，这些算法的优化使得在对数据集进行排序、汇总、关联等计算时，速度得到很大提升，大大提高了计算实施的效率。

3. 集算器内置大量数据访问接口，可以轻松连接各种数据源并从中获取数据。支持的数据源包括但不限于：

- 商用 RDBMS：Oracle、MS SQL Server、DB2、Informix
- 开源 RDBMS：MySQL、PostgreSQL
- 开源 NOSQL：MongoDB、Redis、Cassandra、ElasticSearch
- Hadoop 家族：HDFS、HIVE、H
- 应用软件：SAP ECC、BW
- 文件：Excel、Json、 、TXT
- 其他：http Restful、Web Services、支持 OLAP4j 的多维数据库、阿里云

4. SPL 为解释型语言，不需要进行编译。这使得集算器的任务脚本在集算器内部的部署十分方便，可以很方便地实现动态热部署。

5. 集算器提供了并行多线程计算和集群分布式计算的能力，而且集群的节点可以动态添加，具有十分优秀的可扩展能力。

6. 集算器的核心功能由若干个 Java JAR 包实现，短小精悍，具有超强的可集成性、灵活性、扩展性、开放性、可定制性，非常易于和 Java 应用进行深度整合。加之对外提供了 JDBC、Restful、Web Services 等标准接口，使之与第三方的应用非常容易进行整合集成。

以上这六个特点，恰恰对应了 CHEASE 的六个方面。虽然润乾集算器设计之初尚没有提出数据计算中间件的概念，但是整个产品的设计宗旨始终围绕着 CHEASE，所以在兼容性、热部署能力、计算性能、敏捷性、可扩展性和集成性几个方面，相当得均衡，各方面的表现都相当优秀。如果你觉得在你的数据计算架构中需要一款数据计算中间件，那集算器恐怕是目前唯一的选择。

尚待解决的一些困难

当然，数据计算中间件的概念刚刚被提出，集算器也是一款新产品，概念需要不断验证完善，产品也肯定会有很多不足之处。目前可见的困难由以下两点。

- 获取数据的性能

数据应用不同于其它的应用，它总是牵扯到大量数据的读取，因此数据读取的性能非常关键。数据读取的性能不仅取决于数据计算中间件本身，还取决于数据源和接口类型。如果通过 JDBC 这样的标准接口，数据访问使没有任何问题的，但是读取速度上是却很难满足数据应用的性能要求的。对于这个问题，润乾为集算器提供了多种格式的内部文件存储做为数据缓存机制来加速计算，这是是一种很实用的折中方法。同时润乾也在尝试开发具有针对性的高性能接口，用于提高了从外部获取数据的速度。当然数据计算中间件涉及的接口极多，要解决好这个问题，是一个很大的挑战。

- 对机器学习的支持

如今，人人都在谈论机器学习，虽然传统数据分析仍然是主流，而且在大多数领域，机器学习并不成熟，实际应用的效果大多也差强人意。但是不可否认的是机器学习是未来的方向，将会是数据应用中不可或缺的重要组成部分。因此，机器学习的功能应该是数据计算中间件必须具备的。集算器目前还不具备机器学习的能力，这使它的使用受到了一定的限制。当然，集算器本身在发展，未来可期。

总结

以上所述是小编给大家介绍的数据计算中间件技术综述 ，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对网站的支持！