大数据与分布式数据库技术的必然结合

2023-10-28 理论教育版权反馈

【摘要】：某种程度上，Hadoop似乎成了大数据的代名词。但是，SQL在大数据中也扮演着重要角色。随着企业开始把数据移向大数据平台，大家开始考虑如何利用SQL的问题。大数据的流动性和多样性使得问题很复杂。

某种程度上，Hadoop似乎成了大数据的代名词。但是，SQL在大数据中也扮演着重要角色。

对企业来说，其数据汇聚涉及多个方面，如操作性系统、社会媒体、万维网、传感器、智能设备及其应用，因此会采用Hadoop和HDFS构建集中的数据存储仓库。然后使用大数据工具和框架进行管理和分析，构建数据驱动的产品和从数据获得可操作的前景。

不管其功能如何，Hadoop为数学家和开发人员提供了工具，具有如下特征。

●Hadoop并不是为了回答分析问题而设计的。

●Hadoop并不为处理大容量并发用户需求而构建的。

简言之，Hadoop不适合商业用户使用。

随着企业开始把数据移向大数据平台，大家开始考虑如何利用SQL的问题。

Hadoop设计可工作于任何数据类型，如结构化、非结构化、半结构化，非常灵活。但是，使用起来往往需要从最底层API开始。所以有人说，Hadoop的体系结构使得数据存储和数据存取间存在阻抗不匹配。

大数据工作负载中，非结构化和流式数据类型更获关注。然而，大多数企业应用仍然聚焦于传统的数据操作。原来在Hadoop上只能借助Hive实施SQL。现在越来越多的商家和开源产品运行用户开始将SQL使用在大数据上。

传统上，大数据工具和技术主要聚焦在分析空间（从简单的BI到高级分析工具）构建解决方案。事务性或操作性系统（transactional and operational systems）则很少使用大数据平台。后来Hadoop开始支持SQL引擎，形势开始有了变化。

基于SQL的大数据查询可以分为如下几类。

●报表性查询（reporting queries）。

●特定查询（ad hoc queries）。

●交互OLTP查询（iterative OLAP queries）。(www.chuimin.cn)

●数据挖掘查询（data mining queries）。

●事务性查询（transactional queries）。

如大家所知，传统事务处理应用是在线事务处理（online transactional processing，OLTP）。RDBMS就是为OLTP设计的。

可扩展性也是大数据对SQL 数据库系统的挑战，一些商品化数据库系统如Oracle和IBM DB2采用了共享磁盘和分片（sharding），使得存储量达到或超越TB级别。

SQL大数据解决方案的目标甚多，包括传统的从OLTP到OLAP数据分析查询。需要支持的目标如下。

●分布式横向体系结构（distributed scale-out architecture）：思路是在分布式体系结构上支持SQL，跨越数据存储和跨越机器集群计算。有些数据库系统，如MySQL等需要采用大量编码以便在应用层人工分片（sharding）数据。而像Oracle或IBM DB2这样的共享磁盘的数据库系统要实现跨越，成本很高。

●避免将数据从HDFS迁移到外部存储：要处理数据时，把数据从HDFS移到外部存储，如迁移到一个SQL数据库系统，则是一种很糟糕的方法。如果一个数据库引擎能直接在数据存放的地方实施计算和分析，那是大家乐于看到的。

●替代昂贵的分析数据库和装置（如MPP）：以低成本支持的延迟、可伸缩的大数据集分析操作。

●获取数据的即时可用性（immediate availability of ingested data）：SQL大数据一旦写入存储集群，就可以被存取，无需先将其从HDFS层取出，再放置到另外的系统里。这称为“查询到位”（query-in-place），例如：提高敏捷性，较低的操作成本得到复杂的结果，无需维护单独的分析数据库，减少数据从一个系统迁往另一个系统。

●终端用户高并发性：大数据上SQL的目标是在大型数据集上为大量并发用户支持SQL。在处理并发用户上，Hadoop是不足的，无论是特定分析还是ETL，都是如此。工作时的资源分配和调度始终是瓶颈。

●低延迟：在大型数据集上面对特定查询提供的延迟始终是大多数SQL大数据引擎的目标。大数据的流动性和多样性使得问题很复杂。

●非结构化数据处理能力。

●能集成现有BI工具。

大数据与分布式数据库技术的必然结合

相关推荐