Hive

一、Hive中load语句的语法说明 Hive Load语句不会在加载数据的时候做任何转换工作，而是纯粹的把数据文件复制/移动到Hive表对应的地址。语法格式如下： LOAD DATA [LOCAL] INPATH 'filepath' [OVERWRITE] INTO TABLE tablename \ [PARTITION (partcol1=val1, partcol2=val2 ...)] LOAD DATA [LOCAL] INPATH 'filepath' [OVERWRITE] INTO TABLE tablename \ [PARTITION (partcol1=val1, partcol2=val2 ...)] \ [INPUTFORMAT 'inputformat' SERDE 'serde'] (3.0 or later) 几点说明： 如果命令中带有LOCAL，说明从本地文件系统加载数据，文件路径可以是相对路径，也可以是绝对路径。在这种情况下，首先将文件从本地复制到hdfs相应的位置，然后移动到hive表格中，这个时候原始数据文件是存在于Hive表之下的路径下。 如果不包含LOCAL关键字，则移动HDFS文件到目标表中。 filepath 可以是一个相对路径，也可以是一个绝对路径。可以是一个文件，也可以是一个文件夹目录。如果是一个目录

作者|Karthik Deivasigamani 编译|VK 来源|Medium 介绍 电子商务目录是通过从卖家、供应商/品牌获取数据而创建的。合作伙伴（销售商、供应商、品牌）提供的数据往往不完整，有时会遗漏我们客户正在寻找的关键信息。尽管合作伙伴遵循一个规范（一种发送产品数据的约定格式），但在标题、描述和图像中隐藏着大量数据。除了我们的合作伙伴提供的数据外，互联网上还有许多非结构化数据，如产品手册、产品评论、博客、社交媒体网站等。 沃尔玛正致力于构建一个零售图谱(Retail Graph)，捕捉有关产品及其相关实体的知识，以帮助我们的客户更好地发现产品。它是一个产品知识图谱，可以在零售环境中回答有关产品和相关知识的问题，可用于语义搜索、推荐系统等。本文进一步阐述了什么是零售图谱、如何构建零售图谱、围绕图模型的技术选择、数据库和一些用例。 沃尔玛的零售图谱是什么 零售图谱捕获了零售世界中存在的产品和实体之间的连接。实体是存在的物体、事物、概念或抽象，例如客厅、野生动物摄影、颜色、农舍风格。我们关注的实体大致有两种：抽象的和具体的。前者帮助我们回答诸如“夏日游泳池派对用品”、“农家客厅家具”、“野生动物摄影镜头”之类的问题，而后者帮助我们回答诸如“蓝色牛仔裤裤子”、“木制餐桌”之类的问题。该图谱还将产品之间的关系捕获到两个类别，替代品和补充品（附件、兼容产品等）。它还试图将抽象概念

作者介绍：胡梦宇，知乎数据架构平台开发工程师 背景 Apache Hive 是基于 Apache Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并且提供了 Hive SQL 进行查询和分析，在离线数仓中被广泛使用。 Hive Metastore 是 Hive 的元信息管理工具，它提供了操作元数据的一系列接口，其后端存储一般选用关系型数据库如 Derby、 MySQL 等。现在很多除了 Hive 之外计算框架都支持以 Hive Metastore 为元数据中心来查询底层 Hadoop 生态的数据，比如 Presto、Spark、Flink 等等。 在知乎，我们是将元信息存储在 MySQL 内的，随着业务数据的不断增长，MySQL 内已经出现单表数据量两千多万的情况，当用户的任务出现 Metastore 密集操作的情况时，往往会出现缓慢甚至超时的现象，极大影响了任务的稳定性。长此以往，MySQL 在未来的某一天一定会不堪重负，因此优化 Hive 的元数据库势在必行。 在去年，我们做过数据治理，Hive 表生命周期管理，定期去删除元数据，期望能够减少 MySQL 的数据量，缓解元数据库的压力。但是经过实践，发现该方案有以下缺点： 数据的增长远比删除的要快，治标不治本； 在删除超大分区表（分区数上百万）的分区时，会对 MySQL 造成一定的压力，只能单线程去做

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 数据从业者必须知道的SQL概念（A-Z） 作为数据从业者，大家用的最多的应该就是SQL语言了，那么除了日常的select，你还了解哪些SQL相关的概念呢？今天就按照字母表的顺序(A-Z)来给大家简单介绍一下数据人必须知道的SQL概念大全。 A：Alias 别名，包含表的别名和列的别名。在哪些场景下我们需要用到别名呢？通常是多表join的时候表名过长，多次引用书写比较麻烦的时候我们会给表起一个别名；另外就是表join的时候，如果多个表中有重复的列名而且我们都需要提取出来的时候也需要别名；再则就是列级的别名，通常我们是给表中的列取一个“有意义” 的名字的联合as一起使用。例子如下： select st.id as st_id,sc.id as sc_id --列级别名 from student st --表级别名 left join score sc --表级别名 on st.id=st.id B：Begin Transaction 开始事务操作，SQL里面的事务是是一个操作序列，也就是一次执行的最小单位。一次执行，同一个事务里面的操作要么全部执行要么全部不执行，不存在部分执行部分未执行的可能。依赖事务，我们在数据库里面的部分误操作才有机会被回滚（恢复到本次事务执行之前的状态）。如

1. 背景 Spark SQL的优化器有两种优化方式,即基于规则的优化方式(Rule-Based Optimization，简称为RBO)和基于代价的优化方式(Cost-Based Optimization，简称为CBO)。 Spark 2.4.3模块的Cost Model的核心思想是计算每个物理计划的代价，然后得到最优的物理计划，但是该版本Spark的这部分并没有实现，直接返回多个物理计划列表的第一个作为最优的物理计划，而SPARK-16026引入的CBO优化主要在RBO Optimizer阶段进行的，对应的Rule为CostBasedJoinReorder，并且需要开启spark.sql.cbo.enabled = true，spark.sql.cbo.joinReorder.enabled = true。 spark.sql.statistics.histogram.enabled = false（默认），设置为true则启用column histogram 信息收集。 在开启CBO选项的情况下，Spark会统计收集元数据信息并存储在 CatalogTable 中的CatalogStatistics中，数据表存有sizeInBytes，rowCount，数据列存有distinctCount，min，max，nullCount，avgLen，maxLen，histogram

OLAP（On-Line Analytical Processing），是数据仓库系统的主要应用形式，帮助分析人员多角度分析数据，挖掘数据价值。本文基于QQ音乐海量大数据实时分析场景，通过QQ音乐与腾讯云EMR产品深度合作的案例解读，还原一个不一样的大数据云端解决方案。 一、背景介绍 ​ QQ音乐是腾讯音乐旗下一款领先的音乐流媒体产品，平台打造了“听、看、玩”的立体泛音乐娱乐生态圈，为累计注册数在8亿以上的用户提供多元化音乐生活体验，畅享平台上超过3000万首歌曲的海量曲库。优质 服务的背后，是每天万亿级新增音乐内容和行为数据，PB数据量级的数据计算服务。 海量的数据意味着更高标准的数据分析业务，对于离线分析的时效、实时与近实时的即席实时交互分析，提出了更高的要求。 如何通过用户行为以及音乐内容标签数据，深入洞察用户需求，来优化泛音乐内 容创作分享生态，为亿万用户带来更优质的音乐体验？ 是对QQ音乐大数据团队的巨大挑战以及机遇。 腾讯云弹性 MapReduce（EMR），结合云技术和社区开源技术，提供安全、低成本、高可靠、可弹性伸缩的云端泛Hadoop服务。EMR助力构建企业的大数据平台架构，适用于HBase在线业务，数据仓库，实时流式计算等大数据场景。 QQ音乐大数据团队基于业务需求，搭建和优化基于ClickHouse的OLAP实时大数据分析平台，并与腾讯云EMR团队深入场景合作

1.在uri中配置 hive://localhost:10000/default 2.查询 3.如果你的hive集群是带有kerberos认证的,hive数据源需要这样配置 hive://xxx:xxx/default?auth=KERBEROS&kerberos_service_name=hive 如果在连接的时候报了如下的错 Could not start SASL: b'Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure 那就就是你没有用keytab进行认证 kinit -kt xxx.keytab xxx@XXXX superset也支持模拟用户,配置方法如下 然后就能支持使用hive,impala或者hdfs用户来对普通用户进行模拟,如果模拟出来的用户没有权限的话,就会抛出异常 来源： oschina 链接： https://my.oschina.net/u/4343420/blog/4295357

整理 | 高赟、程鹤群 Review | 王治江 Flink 1.11 版本即将正式宣告发布！为满足大家的好奇与期待，我们邀请 Flink 核心开发者对 1.11 版本的功能特性进行解读与分享。Flink 1.11 在 1.10 的基础上对许多方面进行了完善和改进，并致力于进一步提高 Flink 的可用性及性能。 本文将详细介绍 1.11 版本的新功能、改进、重要变化及未来的发展计划。更多信息可以参考相应的 FLIP 或 Jira 页面，并关注我们后续的专题直播。 集群部署与资源管理 在集群部署方面 1.[FLIP-85] Flink 支持 Application Mode 目前 Flink 是通过一个单独的客户端来创建 JobGraph 并提交作业的，在实际使用时，会产生下载作业 jar 包占用客户端机器大量带宽、需要启动单独进程（占用不受管理的资源）作为客户端等问题。为了解决这些问题，在 Flink-1.11 中提供了一种新的 Application 模式，它将 JobGraph 的生成以及作业的提交转移到 Master 节点进行。 用户可以通过 bin/flink run-application 来使用 application 模式。目前 Application 模式支持 Yarn 和 K8s 的部署方式，Yarn Application

Kafka提供两种启动方式，一种是单机版standalone，一种是分布式版distributed，与之想对应的配置文件也是分开的 单机版的配置文件：connect-standalone.properties 分布式的配置文件：connect-distributed.properties 单机启动方式：bin/connect-standalone.sh -daemon config/connect-standalone.properties config/connect-console-sink.properties 分布式启动方式：bin/connect-distributed.sh -daemon config/connect-distributed.properties 启动完之后就能通过curl的方式请求确认服务是否正常 curl localhost:8083/connectors 单机模式配置信息在提交的配置文件里面，例如：config/connect-console-sink.properties 集群模式需要通过REST API去提交 基于Debezium 的CDC为例，介绍下如何提交一个Kafka Connect source 任务： curl -X POST -H "Content-Type: application/json" http://localhost