Hive

作者：蒋晓伟（量仔） 阿里巴巴研究员 因为侧重点的不同，传统的数据库可以分为交易型的 OLTP 系统和分析型的 OLAP 系统。随着互联网的发展，数据量出现了指数型的增长，单机的数据库已经不能满足业务的需求。特别是在分析领域，一个查询就可能需要处理很大一部分甚至全量数据，海量数据带来的压力变得尤为迫切。这促成了过去十多年来以 Hadoop 技术开始的大数据革命，解决了海量数据分析的需求。与此同时，数据库领域也出现了一批分布式数据库产品来应对 OLTP 场景数据量的增长。 为了对 OLTP 系统里的数据进行分析，标准的做法是把里面的数据定期（比如说每天）同步到一个 OLAP 系统中。这种架构通过两套系统保证了分析型查询不会影响线上的交易。但是定期同步导致了分析的结果并不是基于最新数据，这种延迟让我们失去了做出更及时的商业决策的机会。为了解决这个问题，近几年出现了 HTAP 的架构，这种架构允许我们对 OLTP 数据库里的数据直接进行分析，从而保证了分析的时效性。分析不再是传统的 OLAP 系统或者大数据系统特有的能力，一个很自然的问题是： 既然 HTAP 有了分析的能力，它是不是将取代大数据系统呢？大数据的下一站是什么？ 背景 为了回答这个问题，我们以推荐系统为例分析一下大数据系统的典型场景。 当你看到购物应用给你展示正好想要买的商品，短视频应用播放你喜欢的音乐时

背景：数据从hive写入HBASE http://hbase.apache.org/book.html#precreate.regions 我们先来了解一下这个步骤： 第一步：生成HFILE 第二步：把HFILE导入到HBASE 其中生成HFILE的方式有： 先写一个注意事项，HBASE表要预分区，只有能启动duogereduce 来源： oschina 链接： https://my.oschina.net/u/3267050/blog/4444240

Hive 分区表 Select 优化 对hive分区表执行select操作时，经常执行很慢，原因竟是因为一个点！ 优化适配情况： 分区表执行select操作where选择某一分区或多个分区查询 操作： where条件内分区选择时 在分区字段上加单引号' ' 原始写法： hive -e "select * from table where dt=20200709" 修改后写法: hive -e "select * from table where dt='20200709'" 实际测试： 单分区测试： 增加前执行select操作，mapper数为45004: 增加前执行select操作，mapper数为3000: 多分区测试： 增加前执行select操作，mapper数为45004: 增加前执行select操作，mapper数为1500: Tip: 分区表执行select操作，这里不加引号' '，hive会默认从全部分区扫一遍，因此会启动很多mapper去扫，把满足条件的记录下来，所以不管一个分区还是两个分区条件，都启动了45000个mapper，相当于是全部分区扫描；加了' '相当于指定分区，单分区情况下启动3000mapper，加到双分区时变成1500个mapper，说明dt分区下type分区有两个小分区，如果指定第二个分区时，mapper数变为1000，则说明dt分区下包含

UI： 用于提交查询的客户端，hive自带有CLI(command line)，现在推荐使用beeline DRIVER： 1.用于接收客户端提交的SQL，并实现了session控制 2.并提供了jdbc/odbc的fetch和execute功能 COMPILER： 编译器，负责解析SQL，并从METASTORE那里获取元数据生成执行计划，然后发给DRIVER 执行计划就是一个DAG(有向无环图) 组件： 1.Parser：将查询语句转变成一个parse tree 2.Semantic Analyser：将parse tree变成一个内部的查询表示(依然是基于查询块，而不是operator tree)。同时在这一步也会做语法检查，类型检查和类型隐式转换 3.Logical Plan Generator：将内部的查询表示转变成一个逻辑计划(包含一个operator tree)，一些operator是关系代数的filter，join等，另一些是hive特定的，用于将逻辑计划变成一系列的map/reduce job,比如reduceSink operator(出现在map-reduce边界)；这一步Optimizer也会对查询进行优化,比如map端聚合等 4.Query Plan Genertor：将逻辑计划转换成一系列的map-reduce tasks.做法是，通过对operator

一、前言 Hive默认计算引擎时MR，为了提高计算速度，我们可以改为Tez引擎。至于为什么提高了计算速度，可以参考下图： 用Hive直接编写MR程序，假设有四个有依赖关系的MR作业，上图中，绿色是Reduce Task，云状表示写屏蔽，需要将中间结果持久化写到HDFS。 Tez可以将多个有依赖的作业转换为一个作业，这样只需写一次HDFS，且中间节点较少，从而大大提升作业的计算性能。 二、安装包准备 1）下载tez的依赖包： http://tez.apache.org 2）拷贝apache-tez-0.9.1-bin.tar.gz到hadoop102的/opt/module目录 [root@hadoop102 module]$ ls apache-tez-0.9.1-bin.tar.gz 3）解压缩apache-tez-0.9.1-bin.tar.gz [root@hadoop102 module]$ tar -zxvf apache-tez-0.9.1-bin.tar.gz 4）修改名称 [root@hadoop102 module]$ mv apache-tez-0.9.1-bin/ tez-0.9.1 三、在Hive中配置Tez 1）进入到Hive的配置目录：/opt/module/hive/conf [root@hadoop102 conf]$ pwd /opt/module

1. 摘要 Hudi表允许多种类型操作，包括非常常用的 upsert ，当然为支持 upsert ，Hudi依赖索引机制来定位记录在哪些文件中。 当前，Hudi支持分区和非分区的数据集。分区数据集是将一组文件（数据）放在称为分区的桶中的数据集。一个Hudi数据集可能由N个分区和M个文件组成，这种组织结构也非常方便hive/presto/spark等引擎根据分区字段过滤以返回有限的数据量。而分区的值绝大多数情况下是从数据中得来，这个要求一旦一条记录映射到分区/桶，那么这个映射应该 a) 被Hudi知道；b) 在Hudi数据集生命周期里保持不变。 在一个非分区数据上Hudi需要知道recordKey -> fileId的映射以便对记录进行 upsert 操作，现有解决方案如下：a) 用户/客户端通过payload提供正确的分区值；b) 实现GlobalBloomIndex索引来扫描指定路径下的所有文件。上述两个场景下，要么需要用户提供映射信息，要么会导致扫描所有文件的性能开销。 这个方案拟实现一种新的索引类型，维护 (recordKey <-> partition, fileId) 映射或者 ((recordKey, partitionPath) → fileId) 映射，这种映射由Hudi存储和维护，可以解决上述提到的两个限制。 2. 背景 数据集类型

云栖号快速入门： 【点击查看更多云产品快速入门】 不知道怎么入门？这里分分钟解决新手入门等基础问题，可快速完成产品配置操作！ 结合阿里云日志服务，您可以通过分析负载均衡的访问日志了解客户端用户行为、客户端用户的地域分布，排查问题等。 什么是负载均衡访问日志 负载均衡的访问日志功能收集了所有发送到负载均衡的请求的详细信息，包括请求时间、客户端IP地址、延迟、请求路径和服务器响应等。负载均衡作为公网访问入口，承载着海量的访问请求，您可以通过访问日志分析客户端用户行为、了解客户端用户的地域分布、进行问题排查等。 关于更多负载均衡访问日志的使用案例，访问 云栖社区 。 在开启负载均衡访问日志后，您可以将访问日志存储在日志服务（SLS）的日志库（Logstore）中，采集分析访问日志。您可以随时删除访问日志的配置。 负载均衡访问日志无需额外付费，您仅需要支付日志服务的费用。 负载均衡访问日志优势 负载均衡访问日志有以下优势： 简单 将开发、运维人员从日志处理的繁琐耗时中解放出来，将更多的精力集中到业务开发和技术探索上去。 海量 负载均衡的访问日志数据规模通常很大，处理访问日志需要考虑性能和成本问题。日志服务可以一秒钟分析一亿条日志，相较于自建开源方案有明显成本优势和性能优势。 实时 DevOps、监控、报警等场景要求日志数据的实时性。传统手段无法满足这一需求

万级TPS亿级流水-中台账户系统架构设计 标签：高并发 万级TPS 亿级流水 账户系统 背景 业务模型 应用层设计 数据层设计 日切对账 背景 我们需要给所有前台业务提供统一的账户系统，用来支撑所有前台产品线的用户资产管理，统一提供支持大并发万级TPS、亿级流水、数据强一致、风控安全、日切对账、财务核算、审计等能力，在万级TPS下保证绝对的数据准确性和数据溯源能力。 注：资金类系统只有合格和不合格，哪怕数据出现只有0.01分的差错也是不合格的，局部数据不准也就意味着全局数据都不可信。 本文只分享系统的核心模型部分的设计，其他常规类的（如压测验收、系统保护策略-限流、降级、熔断等）设计就不做多介绍，如果对其他方面有兴趣欢迎进一步交流。 业务模型 基本账户管理： 根据交易的不同主体，可以分为 个人账户 、 机构账户 。 账户余额 在使用上没有任何限制，很纯粹的账户存储、转账管理，可以满足90%业务场景。 子账户功能： 一个用户可以开通多个子账户，根据余额属性不同可以分为基本账户、过期账户，根据币种不同可以分为人民币账户、虚拟币账户，根据业务形态不同可以自定义。 （不同账户的特定功能是通过账户上的 账户属性 来区分实现。） 过期账户管理： 该账户中的余额是会随着 进账流水 到期自动过期。 如：在某平台充值1000元送300元，其中300元是有过期时间的，但是1000元是没有时间限制的

相关文章链接 CentOS7安装CDH 第一章：CentOS7系统安装 CentOS7安装CDH 第二章：CentOS7各个软件安装和启动 CentOS7安装CDH 第三章：CDH中的问题和解决方法 CentOS7安装CDH 第四章：CDH的版本选择和安装方式 CentOS7安装CDH 第五章：CDH的安装和部署-CDH5.7.0 CentOS7安装CDH 第六章：CDH的管理-CDH5.12 CentOS7安装CDH 第七章：CDH集群Hadoop的HA配置 CentOS7安装CDH 第八章：CDH中对服务和机器的添加与删除操作 CentOS7安装CDH 第九章：CDH中安装Kafka CentOS7安装CDH 第十章：CDH中安装Spark2 CentOS7安装CDH 第十一章：离线升级CDH版本 CentOS7安装CDH 第十二章：YARN的资源调优 CentOS7安装CDH 第十三章：CDH资源池配置 CentOS7安装CDH 第十四章：CDH的优化 1. CDH的下载 以 CentOS7.5 和 CDH5.7.0 举例： 1.1. cm的tar包下载 下载地址： http://archive.cloudera.com/cm5/repo-as-tarball/5.7.0/ 请选择需要的版本。 1.2. parcels包下载 下载地址： http://archive

本文来源于公众号【胖滚猪学编程】，转载请注明出处！ 关于数据中台的概念和架构，我们在 大白话 六问数据中台 和 数据中台全景架构及模块解析！一文入门中台架构师！ 两篇文章中都说明白了。从这一篇文章开始分享中台落地实战。 其实无论是数据中台还是数据平台，数据无疑都是核心中的核心，所以闭着眼睛想都知道数据汇聚是数据中台/平台的入口。纵观众多中台架构图，数据采集与汇聚都是打头阵的： 本文将从以下几个方面分享数据采集的方方面面： 一、企业数据来源 二、数据采集概念和价值 三、数据采集常用工具 四、数据采集系统设计原则 五、数据采集模块生产落地分享 有来源才能谈采集，因此我们先来归纳下企业中数据来源。 数据来源 企业中的数据来源极其多，但大都都离不开这几个方面： 数据库，日志，前端埋点，爬虫系统等。 数据库我们不用多说，例如通常用mysql作为业务库，存储业务一些关键指标，比如用户信息、订单信息。也会用到一些Nosql数据库，一般用于存储一些不那么重要的数据。 日志也是重要数据来源，因为日志记录了程序各种执行情况，其中也包括用户的业务处理轨迹，根据日志我们可以分析出程序的异常情况，也可以统计关键业务指标比如PV,UV。 前端埋点同样是非常重要的来源，用户很多前端请求并不会产生后端请求，比如点击，但这些对分析用户行为具有重要的价值，例如分析用户流失率，是在哪个界面，哪个环节用户流失了