Apache ORC

VirtualBox辅助工具安装 swingcoder VritualBox作为最流行的虚拟系统工具之一，虽然Docker发展很快，但VM模式仍有其必要性，例如是开发者个人测试环境的搭建，用Docker来配置一套开发环境也并不容易，这时还不如直接用VM来解决。 使用过VirtualBox产品的人应该知道，除了系统虚拟化，VirutalBox本身还提供了一个增强工具包，叫Guest Additions（或者叫vboxClient），一般包括一些Host机与Guest机进行更加方便的配合操作，如分辨率的修改、剪切板的使用等。 在安装VirtualBox的增强辅助工具时，在安装Guest Additions时也经常会出现问题，下面分别讲解各个问题的解决办法。 所先，系统环境如下 VirtualBox: 6.1 Guest Additions: 6.1.8 Host OS: Darwin MacBook-Pro.local 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64 Guest OS: CentOS 8.0，Linux localhost.localdomain 4.18.0-147.8.1.el8_1.x86

编者按 由于篇幅原因，本文仅精选该书第八章中具有跨时代意义的发现、巨作或事件进行介绍，强烈推荐感兴趣的朋友自行阅读英文原版，也欢迎大家在评论区指正、补充。 文章作者：留德华叫兽 责任编辑：疑疑 文章发表于 微信公众号【运筹OR帷幄】： 报道 | 运筹学发展简史之1979-2004 欢迎原链接转发，转载请私信 @运筹OR帷幄 获取信息，盗版必究。 敬请关注和扩散本专栏及同名公众号，会邀请 全球知名学者 发布运筹学、人工智能中优化理论等相关干货、 知乎Live 及行业动态 更多精彩文章，欢迎访问我们的机构号： @运筹OR帷幄 前言 首先向大家隆重介绍一本书： An Annotated Timeline of Operations Research - An Informal History | Saul I. Gass 此书是我在准备德国博士答辩general exam借相关教材时，偶然发现的“宝贝”，接着就不务正业地泡了一下午浏览了运筹学的发展史。 本书的目录按照年代，分为八个章节： 1.运筹学（OR）的前身：1564-1873 2.运筹学的前身：1881-1935 3.运筹学的诞生：1936-1946 4.运筹学的扩张：1947-1950 5.运筹学中数学、算法的发展：1951-1956 6.运筹学中国际活动、算法、应用、教科书发展：1957-1963 7.运筹学中方法、应用

本章是面向对象23种设计模式系列开篇，首先我们来看下什么是设计模式？ 面向对象23种设计模式 ： 　　1、面向对象语言开发过程中，遇到的种种场景和问题，提出了解决方案和思路，沉淀下来就变成了设计模式。 　　2、解决具体问题的具体招数---套路---站在前辈的肩膀上。 　　3、没有什么设计模式是完美无缺的，一种设计模式就是解决一类问题，通常设计模式在解决一类问题的同时，还会带来别的问题，我们设计者要做的事儿，就是要扬长避短，充分发挥长处！ 设计模式可以大概分为三大类 ： 　　1、创建型设计模式：关注对象的创建。 　　2、结构型设计模式：关注类与类之间的关系。 　　3、行为型设计模式：关注对象和行为的分离。 我们要做的就是学习核心套路，这里就不做过多的描述，如果有机会会通过具体例子再和大家分享。下面我们正式进入本章主题。 创建型设计模式：关注对象的创建 。（5个） 1、单例模式（Singleton Pattern） 单例模式： 　　就是限制了对象的创建，重用了对象。保证进程中，某个类只有一个实例。 　　即使是单例，变量也不是线程安全的，单例不是为了保证线程安全。 　　单例的好处就是单例，就是全局唯一的一个实例。 　　应对一些特殊情况，比如数据库连接池(内置了资源) ，全局唯一号码生成器。 　　单例可以避免重复创建，但是也会常驻内存，除非是真的有必要，否则就不要使用单例。 1.1

背景 在数据中台建设过程中，一个典型的数据集成场景是将 MQ (Message Queue，例如 Kafka、RocketMQ 等)的数据导入到 Hive 中，以供下游数仓建设以及指标统计。由于 MQ-Hive 是数仓建设第一层，因此对数据的准确性以及实时性要求比较高。 本文主要围绕 MQ-Hive 场景，针对目前字节跳动内已有解决方案的痛点，提出基于 Flink 的实时解决方案，并介绍新方案在字节跳动内部的使用现状。 已有方案及痛点 字节跳动内已有解决方案如下图所示，主要分了两个步骤： 通过 Dump 服务将 MQ 的数据写入到 HDFS 文件 再通过 Batch ETL 将 HDFS 数据导入到 Hive 中，并添加 Hive 分区 痛点 任务链较长，原始数据需要经过多次转换最终才能进入 Hive 实时性比较差，Dump Service、Batch ETL 延迟都会导致最终数据产出延迟 存储、计算开销大，MQ 数据重复存储和计算 基于原生 Java 打造，数据流量持续增长后，存在单点故障和机器负载不均衡等问题 运维成本较高，架构上无法复用公司内 Hadoop/Flink/Yarn 等现有基础设施 不支持异地容灾 基于 Flink 实时解决方案 优势 针对目前公司传统解决方案的痛点，我们提出基于 Flink 的实时解决方案，将 MQ 的数据实时写入到 Hive，并支持事件时间以及

物化视图作为一种预计算的优化方式，广泛应用于传统数据库中，如Oracle，MSSQL Server等。随着大数据技术的普及，各类数仓及查询引擎在业务中扮演着越来越重要的数据分析角色，而物化视图作为数据查询的加速器，将极大增强用户在数据分析工作中的使用体验。本文将基于 Spark SQL（2.4.4） + Hive （2.3.6）， 介绍物化视图在 Spark SQL中的实现及应用。 文章目录 1 什么是物化视图 2 物化视图现状及实践目标 2.1 SparkSQL目前有哪些预计算相关的优化呢？ 3 物化视图设计详解 3.1 SparkSQL + Hive 整合 3.1.1 为什么选择Hive2.3 4 Plan Rewrite 设计 4.1 设计概览 4.2 优化步骤简介 4.3 优化过程中的问题 4.3.1 列相等问题 4.3.2 条件匹配问题 4.3.3 表达式匹配问题 4.3.4 多表查询问题 4.3.5 聚合函数问题 4.3.6 多个物化视图匹配问题 5 物化视图实战 5.1 测试用的查询 5.2 测试用的物化视图 5.3 逻辑计划比较 5.4 Spark UI统计比较 5.5 性能数据比较 6 物化视图 VS Kylin 6.1 Kylin on HBase 6.2 Kylin on Parquet 7 总结 8 参考资料 什么是物化视图

记录一个客户问题 客户用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

删除行 A表数据如下 id(String) name(String) ---------------------------- 1 aaa 2 bbb 3 ccc ----------------------------- 要求删除2 bbb hive 脚本如下： insert overwrite table A select id,name from A where id !=2; TRUNCATE: truncate 用于删除所有的行，这个行为在 Hive 元存储删除数据是不可逆的 DROP: 删除 hive 中的表 truncate 不能删除外部表！因为外部表里的数据并不是存放在 Hive Meta store 中 truncate: truncate table table_name; 例子： truncate table employees; Hive 1.x 版本中没有 delete 操作 2.x 版本更新后支持，如果一个表要实现 update 和 delete 功能，该表就必须支持 ACID，而支持 ACID，就必须满足以下条件： 1、表的存储格式必须是 ORC（STORED AS ORC）； 2、表必须进行分桶 3、Table property 中参数 transactional 必须设定为 True 来源： oschina 链接： https://my

MapReduce 主要内容 ① MapReduce概述 1.1 MapReduce定义 1.2 优缺点 优点： 缺点： 1.3 MR核心编程思想 MR进程： ② MR框架原理 2.1 MapReduce工作流程 Map Task工作机制： 具体过程： Read阶段 ：从文本中一行一行的读取数据，并返回一个个的k,v数据，并将数据交给map函数处理； Map阶段 ：用map函数处理读取到的k,v数据，并得到新的k,v数据； Collect收集阶段 ：将map函数处理的结果存储到环形内存缓存区中； Spill溢写阶段 ：当环形缓存区达到阈值时，就会将数据溢写到磁盘上。溢写前要对数据进行排序、合并等操作；（溢写阶段详情见文档） Combine合并阶段 ：当所有数据处理完以后，对磁盘上的所有数据进行一次归并排序，合并成一个文件；（详情见文档） Reduce Task工作机制： 具体流程： Copy阶段 ：当Map Task任务结束以后，Reduce Task从各个Map Task上去拷贝数据，放到内存或者磁盘中； Merge阶段 ：对内存和磁盘上拷贝过来的数据进行合并，防止内存和磁盘被占用过多； Sort 阶段： 和Merge阶段一起工作，在合并的同时使用归并排序进行排序； Reduce 阶段 ： reduce() 函数将计算结果写到 HDFS 上。 MR整体流程图： 2.2

这个作业属于哪个课程 < 2020 春 W 班 (福州大学) > 这个作业要求在哪里 < 作业要求 > 团队名称 <旗山的骄傲> 这个作业的目标 <Beta 冲刺> 作业正文 < 作业正文 > 其他参考文献 <《构建之法》> part.01 组长是否重选的议题和结论 方式：在组内召开了线上会议进行了讨论 结论：组长不需要进行更换 理由： 没有特殊情况，组长无需重选，组长认真负责且能力足够。在一直以来的团队合作中组长未出现严重的失误。 就目前而言，现组长仍为对项目整体了解度最高的成员，更换组长反而可能影响开发的进度。 part.02 下一阶段需要改进完善的功能 前端 web前台 界面UI美化优化 进一步进行测试，寻找潜在bug 接口逻辑性能优化 web后台 界面UI美化优化 进一步进行测试，寻找潜在bug 接口逻辑性能优化 Android 界面UI美化优化 进一步进行测试，寻找潜在bug 接口逻辑性能优化 后端 框架内接口部分 代码进行重构，统一规范 进一步进行测试，寻找潜在bug 优化后端逻辑，提高性能 工具类部分 封装框架内的常用方法到工具类 服务器端 增加服务器的安全性，完善安全策略 增加服务器的承载能力，负载测试（ 学生机这么玩真的合适吗？ ） part.03 下一阶段需要新增的功能 前端 web前台 完成附加功能界面及子界面 登录模块完成orc验证及找回密码的验证功能

问题描述 Hive ORC table常规小文件过多问题，于是用Spark写了一个Application来自动的Merge分区数据，思路很简单 大概就是 insert overwrite table partition (分区 XXX) select * from table where (分区 XXX) 当然已经把该dataframe repartition到想要的目标并发度，来控制最终分区下的文件个数 但是发现生成的文件个数虽然是对的，但是最后整个分区的Size竟然几乎翻倍。 排查过程以及结论 怀疑是Spark SQL没有压缩或者压缩格式不对 https://stackoverflow.com/questions/48759909/how-to-check-if-zlib-compression-is-enabled-in-hive-tables 用这个链接的方式自查一下 发现 hive 生成的文件默认是zlib 而spark生成的文件默认是snappy 这个导致了最终文件大小相差较大 来源： oschina 链接： https://my.oschina.net/u/4303818/blog/4287399