摸不到Java的顶峰,咱就转战大数据,绝不在一棵树上吊死

2023-10-15 01:59

本文主要是介绍摸不到Java的顶峰,咱就转战大数据,绝不在一棵树上吊死,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

这篇文章的目的是带那些对大数据不了解又有兴趣的人入门。如果你是老手可以忽略,或者想看看有没有不一样的东西也行。

我们学习一个新知识,第一步应该是给它个明确的定义。这样才能知道你学的是什么,哪些该学,哪些又可以先不用管。

然而,大数据虽然很火,但其实是个概念没那么清晰的东西,不同的人可能有不同的理解。

这次我们不去纠结具体的定义,也忽略那些 4 个 V、6 个 C 之类传统说教的东西,甚至不想聊架构演进以及各种调优的方法,这些东西讲了大家也不一定懂,懂了也记不住,记住了也用不起来。

我们也不去关注 AI、Machine Learning 那些炫酷的应用层面的东西,而是去看看大数据这栋房子的地基是什么模样。限于篇幅,很多技术细节点到即止,有兴趣的同学可以再按需了解,这也正是入门的含义所在。

首先第一个问题,大数据,大数据,多大叫大?或者换一个角度,什么时候需要用到大数据相关的技术?

这依然是个没有标准答案的问题,有些人可能觉得几十 G 就够大了,也有人觉得几十 T 也还好。当你不知道多大叫大,或者当你不知道该不该用大数据技术的时候,通常你就还不需要它。

而当你的数据多到单机或者几台机器存不下,即使存得下也不好管理和使用的时候;当你发现用传统的编程方式,哪怕多进程多线程协程全用上,数据处理速度依然很不理想的时候;当你碰到其他由于数据量太大导致的实际问题的时候,可能你需要考虑下是不是该尝试下大数据相关的技术。

从刚才的例子很容易能抽象出大数据的两类典型应用场景:

  • 大量数据的存储,解决装不下的问题。
  • 大量数据的计算,解决算得慢的问题。

因此,大数据的地基也就由存储和计算两部分组成。

我们在单机,或者说数据量没那么大的时候,对于存储有两种需求:

  • 文件形式的存储
  • 数据库形式的存储

文件形式的存储是最基本的需求,比如各个服务产生的日志、爬虫爬来的数据、图片音频等多媒体文件等等。对应的是最原始的数据。

数据库形式的存储则通常是处理之后可以直接供业务程序化使用的数据,比如从访问日志文件里处理得到访问者 ip、ua 等信息保存到关系数据库,这样就能直接由一个 web 程序展示在页面上。对应的是处理后方便使用的数据。

大数据也只是数据量大而已,这两种需求也一样。虽然不一定严谨,但前者我们可以叫做离线(offline)存储,后者可以叫做在线(online)存储。

离线存储这块 HDFS(Hadoop Distributed File System) 基本上是事实上的标准。从名字可以看出,这是个分布式的文件系统。实际上,「分布式」也是解决大数据问题的通用方法,只有支持无限横向扩展的分布式系统才能在理论上有解决无限增长的数据量带来的问题的可能性。当然这里的无限要打个引号。

 

这是 HDFS 的简易架构图,看起来仍然不太直观,其实要点只有几句话:

  • 文件被以 block 为单位拆分后存放在不同的服务器上,每个 block 都在不同机器上做了多份冗余。
  • 有 NameNode 和 DataNode 两种角色,前者存放元数据也就是每个 block 保存在哪里,后者负责存放实际数据。
  • 读和写数据都要先向 NameNode 拿到对应文件的元数据,然后再找对应的 DataNode 拿实际的数据。

可以看到,HDFS 通过集中记录元数据的方式实现了分布式的效果,数据量增长只需要添加一些新的 DataNode 就可以了,单机容量不再是限制。

而为了保证数据的高可用,比如某台服务器突然坏了再也起不来了,HDFS 通过冗余的方式(通常是 3 副本)来解决这个问题。这也是分布式系统里最常用的高可用方式,虽然成本可能很高。

系统级别的高可用才有意义,所以除了数据的高可用,元数据的高可用也至关重要。思路一样 -- 备份。HDFS 提供了 Secondary NameNode 来提供元数据的冗余。当然更好的方式是使用 NameNode HA 的方式,通过 active/standby 一组 NameNode 来保证不间断的元数据读写服务。

同样,扩展性刚才也只考虑到数据的横向扩展,元数据呢?当数据量大到一定程度,元数据也会非常大,类似我们在传统关系数据库里碰到的索引膨胀的问题。解决的思路是 NameNode Federation。简单讲就是把原来的一组 active/standy NameNode 拆分成多组,每组只管理一部分元数据。拆分后以类似我们在 Linux 系统里挂载(mount)硬盘的方法对外作为整体提供服务。这些 NameNode 组之间相互独立,2.x 版本的 HDFS 通过 ViewFS 这个抽象在客户端通过配置的方式实现对多组 NameNode 的透明访问,3.x 版本的 HDFS 则实现了全新的 Router Federation 来在服务端保证对多组 NameNode 的透明访问。

可以看到,元数据的横向扩展和实际数据的横向扩展思路完全一样,都是拆分然后做成分布式。

和离线存储对应的是在线存储,可以参照传统的 MySQL、Oracle 等数据库来理解。在大数据领域最常用的是 H

这篇关于摸不到Java的顶峰,咱就转战大数据,绝不在一棵树上吊死的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/214628

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类,它们之间的依赖,构建起了整个框架。想要理解整个架构,最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文(security context)的信息。当前操作的用户是谁,该用户是否已经被认证,他拥有哪些角色权限…这些都被保

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定