Apache Spark

深入理解数砖的 Delta Engine

故事扮演 提交于 2020-08-14 03:12:30
在 Spark AI Summit 的第一天会议中,数砖重磅发布了 Delta Engine。这个引擎 100% 兼容 Apache Spark 的向量化查询引擎,并且利用了现代化的 CPU 架构,优化了 Spark 3.0 的查询优化器和缓存功能。这些特性显著提高了 Delta Lake 的查询性能。当然,这个引擎目前只能在 Databricks Runtime 7.0 中使用。 文章目录 1 数砖研发 Delta Engine 的目的 2 Delta Engine:高性能的查询引擎 3 Photon:原生向量化执行引擎 3.1 String 优化 数砖研发 Delta Engine 的目的 过去十年,存储的速度从 50MB/s(HDD)提升到 16GB/s(NvMe);网络的速度从 1Gbps 提升到 100Gbps;但是 CPU 的主频从 2010 年的 3GHz 到现在基本不变。 如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号: iteblog_hadoop NVM Express(NVMe),或称非易失性内存主机控制器接口规范(英语:Non-Volatile Memory Host Controller Interface Specification,缩写:NVMHCIS),是一个逻辑设备接口规范。它是与 AHCI 类似的

Spark Sql之Catalog

别说谁变了你拦得住时间么 提交于 2020-08-14 02:32:07
基于版本: Spark 2.2.0 把一些概念搞清楚,Spark轮廓就清晰了。 什么是 Catalog ,中文翻译 目录 ,那啥叫目录呢?下面是百度百科的解释: `目录,是指书籍正文前所载的目次,是揭示和报道图书的工具。目录是记录图书的书名、著者、出版与收藏等情况,按照一定的次序编排而成,为反映馆藏、指导阅读、检索图书的工具。 简单说,目录是检索工具,那么 Catalog 就是Spark的检索工具。 我们从它实现的主要功能入手看一下: 获取SparkSession可见的数据库、表和函数(不可见就抛出异常); 给定数据库名、表名和函数名,提供get函数获取这些实体的信息; 列举方法,包括列举可见的数据库,数据库中的表和函数; 判断数据库、表或者函数是否存在; 缓存/去缓存表数据、刷新数据库、表的内存meta信息; 创建外部表(createExternalTable)。 从上面实现的功能看, Catalog 其实是Spark了解session级别可见实体(数据库、表和函数)的一个入口,在它的具体实现 CatalogImpl 中还包括了创建一个新数据库、表和函数的功能。 总结下就是: Catalog 围绕数据库、表和函数三种实体,提供创建、检索、缓存数据和删除的功能。 来源: oschina 链接: https://my.oschina.net/u/4412457/blog

大数据实践解析(下):Spark的读写流程分析

旧巷老猫 提交于 2020-08-14 01:57:30
导读: 众所周知,在大数据/数据库领域,数据的存储格式直接影响着系统的读写性能。spark是一种基于内存的快速、通用、可扩展的大数据计算引擎,适用于新时代的数据处理场景。在“ 大数据实践解析(上):聊一聊spark的文件组织方式 ”中,我们分析了spark的多种文件存储格式,以及分区和分桶的设计。接下来,本文通过简单的例子来分析在Spark中的读写流程,主要聚焦于Spark中的高效并行读写以及在写过程中如何保证事务性。 1、文件读 如何在Spark中做到高效的查询处理呢?这里主要有两个优化手段: 1)减少不必要的数据处理。数据处理涉及文件的IO以及计算,它们分别需要耗费大量的IO带宽和CPU计算。在实际的生产环境中,这两类资源都是有限的,同时这些操作十分耗时,很容易成为瓶颈,所以减少不必要的数据处理能有效提高查询的效率; 以下面的查询为例: spark.read.parquet("/data/events") .where("year = 2019") .where("city = 'Amsterdam'") .select("timestamp") 由于在events表中按照year字段做了分区,那么首先通过 year 字段我们就可以过滤掉所有year字段不为 2019 的分区: 因为文件是parquet的文件格式,通过谓词下推可以帮助我们过滤掉 city 字段不是

Scala 隐式(implicit)详解

老子叫甜甜 提交于 2020-08-13 18:46:54
参考文章: Scala 隐式(implicit)详解 文章正文 通过隐式转换,程序员可以在编写Scala程序时故意漏掉一些信息,让编译器去尝试在编译期间自动推导出这些信息来,这种特性可以极大的减少代码量,忽略那些冗长,过于细节的代码。 1、Spark 中的隐式思考 隐式转换是Scala的一大特性, 如果对其不是很了解, 在阅读Spark代码时候就会很迷糊,有人这样问过我? RDD这个类没有reduceByKey,groupByKey等函数啊,并且RDD的子类也没有这些函数,但是好像PairRDDFunctions这个类里面好像有这些函数 为什么我可以在RDD调用这些函数呢? 答案就是Scala的隐式转换; 如果需要在RDD上调用这些函数,有两个前置条件需要满足: 首先rdd必须是RDD[(K, V)], 即pairRDD类型 需要在使用这些函数的前面Import org.apache.spark.SparkContext._;否则就会报函数不存在的错误; 参考SparkContext Object, 我们发现其中有上10个xxToXx类型的函数: implicit def intToIntWritable(i: Int) = new IntWritable(i) implicit def longToLongWritable(l: Long) = new LongWritable

精心整理,kafka常见面试题,看这篇文章就够了(共17题,含详细解答)

試著忘記壹切 提交于 2020-08-13 17:46:40
【 Java架构师面试网 】收集整理了几乎整个架构师学习途中会遇到的面试题,希望大家都能早日圆自己的架构师梦~ 公众号: Java架构师面试网 ,关注回复“ 资料 ”即可领取精美整理的面试资料一份哦~ Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 1.Kafka 的设计时什么样的呢? Kafka 将消息以 topic 为单位进行归纳 将向 Kafka topic 发布消息的程序成为 producers. 将预订 topics 并消费消息的程序成为 consumer. Kafka 以集群的方式运行,可以由一个或多个服务组成,每个服务叫做一个 broker. producers 通过网络将消息发送到 Kafka 集群,集群向消费者提供消息 2.数据传输的事物定义有哪三种? 数据传输的事务定义通常有以下三种级别: ( 1)最多一次: 消息不会被重复发送,最多被传输一次

程序员的崩溃,是从“你收入比我高”开始的!

折月煮酒 提交于 2020-08-13 16:31:57
今年的 6·18,你买买买了吗 ?疫情之后,多少年轻人在反思自己的消费方式,从前想怎么花就怎么花,疫情后开始考虑量入为出和理财。 比起 (不可能做到的) 在购物节时忍住剁手冲动,面对未知的变化和已知的通货膨胀, 唯有让自己变得更“贵”,才是保持财务安全感的唯一方式 。 要说互联网行业中,什么人群平均薪资最高,无疑是大数据开发。 在拉勾网上,同一公司提供的岗位里,同等资历的开发工程师和大数据工程师,月薪可能相差20k。 随着物联网、5G的普及,大数据人才会越来越贵,别的不说,至少涨薪幅度能跑得赢通货膨胀。不过正因为薪资高, 从事数据开发的任职要求也高 ,除了基础知识扎实,各种层出不穷的新技术也都要求精通。 其实只要是做开发,就无法停止学习,业务需求的变化永远快于你的进步。 何况今天你比同行多学一个技术,明天就多一点跳槽、升职的优势。 正好今天是 拉勾教育 6·18 年中知识特惠的最后一天 ,原价98元的重磅好课1元秒杀可得,学习成本超低,今天是大数据专场,像 Spark 和 Flink 这样的数据处理技术,不管你是从未使用过,还是略有涉猎,要想在大数据开发领域有所发展,都是必不可少的,可以趁机囤课慢慢学。 (而且我还为你争取到了买一赠一的福利,通过我这里秒杀专栏,还能免费获得任一原价专栏。) 1元秒杀,时机最佳 1元秒杀|原价¥98的 「即学即用的Spark实战44讲」

大数据就业前景如何?现在学习大数据已经晚了吗?

て烟熏妆下的殇ゞ 提交于 2020-08-13 16:30:14
  大数据就业 前景如何?现在学习大数据已经晚了吗?作为初入社会的大学生,或者想改变环境转行的同学,看到大数据技术开发者的高薪资都想进入这个行业,但是现在大数据技术依然想之前那样火爆吗?是不是学习了大数据技术就可以获得高薪呢?   大数据从最开始的概念兴起,到现在各大互联网公司逐步推广使用。已经逐渐成熟,目前营销、电商、教育领域等等对大数据的应用已经初见效果。大数据也从最开始的概念过渡到实际应用领域。对技术人员的招聘也更加趋于理性。所以并非大数据技术不再火爆,而是企业对于大数据从业人员的要求提高了。   根据招聘网站显示,目前大数据工作招聘需求,薪资普遍稳定在15-30K之间。其中目前刚入行的大数据工程师平均薪资在1万左右,而随着工作时间的增加,3~5年经验的大数据工程师的薪资待遇将达到3万元左右。   据相关机构统计,未来的3~5内大数据人才的缺口将达到150万,而且随着大数据的发展,人才缺口将不断扩大,所以大数据不管是目前还是未来长期都将是紧缺人才,受到各大互联网企业的关注。   如果你想投入大数据的怀抱,但却苦于不知如何下手。而当你准备学习大数据技术时,你可以了解一下博斌去计算大数据课程,主要是针对有一定编程开发经验的学员研发的课程。从大数据基础增强开始,内容精准聚焦大数据开发过程中必备的离线数据分析、实时数据分析和内存数据计算等重要内容;涵盖了大数据体系中几乎所有的核心技术

从 Exadata 到 TiDB,中通快递 HTAP 实践

六眼飞鱼酱① 提交于 2020-08-13 14:48:27
作者介绍:朱志友,中通快递大数据架构师。 中通快递背景介绍 中通快递业务的规模目前是世界第一,是第一个达成年百亿业务量的快递企业,在 2019 年的双十一更是完成了订单量超过 2 亿的佳绩。中通科技是中通快递旗下的互联网物流科技平台,拥有一支千余人规模的研发团队,秉承着“互联网+物流”的理念,与公司的战略、业务紧密的衔接,为中通生态圈的业务打造全场景全链路的数字化平台服务。 上图展示了快递物流的生命周期,简单举个例子,大家如果在某宝上下了一个订单,从付款结束开始,到商家打单,大家的包裹基本上就开启了一个快递的旅程。简单的介绍可以分为五个字,收发到派签,整个物流的全链路中可以拆解成以下的关键节点,客户下单之后快递员的揽收,揽收网点的建包,建包之后会把快递交到中心,至此快递就开启了转运和运输的过程,最终负责派件的末端网点会根据三段码的解析去末端的中心把快递拉到末端的快递网点进行分拣,分拣之后会指派到指定的快递员,进行派件,快递小哥会把快递送到客户的手里,客户完成签收,在我们看来这一票件就完成了快递的全链路的生命周期。在每个环节中会产生大量的数据,对每个环节的每一个数据我们都会进行相关的分析,包括时效的监控。 2017 年的时候,我们就已经开始关注 TiDB ,那时候的关注点主要在解决一些分库分表的问题上,从 2018 年底开始调研测试大数据,我们主要想去解决存储和计算的问题,2019

阿里云 MaxCompute 2020-6 月刊

…衆ロ難τιáo~ 提交于 2020-08-13 13:49:40
导读 【6月新发布功能】 【6月新发布文档】 【6月精选技术文章】 【7月精选活动预告】 【6月新发布功能】 1. MaxCompute备份与恢复功能(公测)发布 MaxCompute备份与恢复功能提供持续备份用户修改/删除历史数据,支持快速恢复,持续保护数据安全。 适用客户 对数据保护有强需求客户/担心数据误删除的客户/担心数据被恶意删除的客户,适合广泛的企业级客户。 发布功能 MaxCompute提供数据备份与恢复功能,系统会自动备份数据的历史版本(例如被删除或修改前的数据)并保留一定时间,您可以对保留周期内的数据进行快速恢复,避免因误操作丢失数据。备份与恢复功能具备以下特点: 默认开启,不需要手动开通 -- 该功能不依赖外部存储,系统默认为所有MaxCompute项目开放的数据保留周期为1天,备份和存储免费。 自动持续备份 -- 系统自动对发生变更的数据进行备份,多次变更时将备份多个数据版本,相比固定周期性的备份策略,可以有效避免因误操作丢失数据。 恢复快速,操作简单 -- MaxCompute具备先进的元数据和多数据版本管理能力,备份和恢复操作不占用额外的计算资源,您可以通过命令快速恢复不同规模的数据。 查看文档 >> 2. MaxCompute通过DataWorks管控平台新建项目支持选择数据类型 适用客户 中国Region使用DataWorks管控台的客户 发布功能

Spark SQL repartition 为啥生成的文件变大了?

回眸只為那壹抹淺笑 提交于 2020-08-13 12:58:22
记录一个客户问题 客户用Spark SQL的repartition接口来解决Hive ORC表小文件的问题,发现文件膨胀的很厉害 比如原来有1000个小文件,总大小是500MB repartition(10) 再 insert overwrite之后 10个文件 总大小是2~3GB 但是检查了一下最终的两个分区的 row count是一致的 调查结论 先说一下这两接口不同 repartition 把record完全打乱最终随机插入到10个文件 有Shuffle coalesce 把相邻的分区的数据捏在一起,没有Shuffle 为啥shuffle打乱数据会让最终的表输出文件变大 其实就是 ORC 数据编码问题 原来的源分区其实是通过HashPartition的方式分布的,这样的数据分布可以让ORC的编码压缩得更加极致,而repartition完全打乱后导致本来在一个文件的相同记录分布到10个文件,那就是每个文件都有该记录的编码索引,那么最终文件就变大了 所以推荐使用 coalesce 接口来做类似的事情 来源: oschina 链接: https://my.oschina.net/u/4287236/blog/4295721