HDFS

本文来自: PerfMa技术社区 PerfMa(笨马网络)官网 接触Flink一段时间了，遇到了一些问题，其中有一个checkpoint失败导致作业重启的问题，遇到了很多次，重启之后一般也能恢复正常，没有太在意，最近2天有同事又频繁遇到，这里记录一下解决方案和分析过程。 我们的flink测试环境有3个节点，部署架构是每个flink节点上部署一个HDFS的DataNode节点，hdfs用于flink的checkpoint和savepoint 现象 看日志是说有个3个datanode活着，文件副本是1，但是写文件失败 There are 3 datanode(s) running and no node(s) are excluded 网上搜了一下这种报错，没有直接的答案，我看了下namenode的日志，没有更多直接的信息 50070 web ui上看一切正常，datanode的剩余空间都还有很多，使用率不到10% 我试了一下往hdfs上put一个文件再get下来，都ok，说明hdfs服务没有问题，datanode也是通的 日志现象1 继续前后翻了一下namenode的日志，注意到有一些warning信息， 这时候怀疑块放置策略有问题 按照日志提示打开相应的的debug开关 修改 etc/hadoop/log4j.properties 找到 log4j.logger.org

​ 成长这一路就是懂得闭嘴努力，知道低调谦逊，学会强大自己，在每一个值得珍惜的日子里，拼命去成为自己想成为的人 Hadoop配置日志聚集 应用场景 为了让应用运行完成以后，将程序运行日志信息上传到HDFS系统上，有了日志之后就可以查看程序中的报错信息，从而调试程序 配置步骤 1.配置yarn-site.xml <!-- 日志聚集功能使能 --> <property> <name>yarn.log-aggregation-enable</name> <value>true</value> </property> <!-- 日志保留时间设置7天 --> <property> <name>yarn.log-aggregation.retain-seconds</name> <value>604800</value> </property> 2.重启集群 sbin/stop-yarn.sh sbin/stop-dfs.sh sbin/mr-jobhistory-daemon.sh stop historyserver sbin/start-dfs.sh sbin/start-yarn.sh sbin/mr-jobhistory-daemon.sh start historyserver 3.运行程序 上传数据到HDFS 赋给文件权限 运行程序 查看运行结果 4.查看日志 相关资料 本文配套

写在前面： 最近，数据湖的概念非常热，许多前线的同学都在讨论数据湖应该怎么建？阿里云有没有成熟的数据湖解决方案？阿里云的数据湖解决方案到底有没有实际落地的案例？怎么理解数据湖？数据湖和大数据平台有什么不同？头部的云计算玩家都各自推出了什么样的数据湖解决方案？带着这些问题，我们尝试写了这样一篇文章，希望能抛砖引玉，引起大家一些思考和共鸣。感谢南靖同学为本文编写了5.1节的案例，感谢西壁的review。 本文包括七个小节：1、什么是数据湖；2、数据湖的基本特征；3、数据湖基本架构；4、各厂商的数据湖解决方案；5、典型的数据湖应用场景；6、数据湖建设的基本过程；7、总结。受限于个人水平，谬误在所难免，欢迎同学们一起探讨，批评指正，不吝赐教。 一、什么是数据湖 数据湖是目前比较热的一个概念，许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，搞清楚什么是数据湖，明确一个数据湖项目的基本组成，进而设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖，有如下定义。 Wikipedia是这样定义的： A data lake is a system or repository of data stored in its natural/raw format,[1] usually object blobs or files. A data lake is usually

背景 在数据中台建设过程中，一个典型的数据集成场景是将 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，并支持事件时间以及

桔妹导读：滴滴HBase团队日前完成了0.98版本 -> 1.4.8版本滚动升级，用户无感知。新版本为我们带来了丰富的新特性，在性能、稳定性与易用性方便也均有很大提升。我们将整个升级过程中面临的挑战、进行的思考以及解决的问题总结成文，希望对大家有所帮助。 1. 背景 目前HBase服务在我司共有国内、海外共计11个集群，总吞吐超过1kw+/s，服务着地图、普惠、车服、引擎、金融等几乎全部部门与业务线。 然而有一个问题持续困扰着我们：版本较社区落后较多——HBase线上集群使用0.98版本，而社区目前最新的release版本为2.3。这为我们的工作带来了很多额外的掣肘与负担，主要包括以下几点： 新特性引入成本极高： 0.98版本可以算是HBase第一个稳定版本，但过于老旧，社区已经不再维护。想要backport新特性难度越来越大。 自研patch维护成本较高： 我们基于0.98版本有数十个大大小小的自研patch，涵盖了从label分组、ACL鉴权等大的feature到监控体系建设、审计日志优化等Improvement以及各种bug fix。这些patch或是新版本中已支持但和我们实现有差异，或是由于版本差异过大无法合入社区，而且随着时间线的拉长，这种问题只会进一步恶化。 上层组件对于HBase存在一定需求： 得益于活跃的HBase生态圈，目前我们的用户使用形态也比较丰富，OLAP

1.创建hbase表 create 'lyj:lyja','cf1' 2.写入数据 put 'lyj:lyja','1','cf1:name','zhangsan' put 'lyj:lyja','1','cf1:age','lisi' 3.查询hbase 表权限 (**给hive授权hbase表的操作权限否则不能操作hbase中的数据**) user_permission 'lyj:lyja' 4 . 在hbase中先授权给hive用户 su hbase hbase shell grant 'hive','RWXCA','lyja' 5.创建hive hbase 外部表 CREATE EXTERNAL TABLE lyja( key string, name string, age string ) STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' WITH SERDEPROPERTIES ("hbase.columns.mapping" = ":key,cf1:name,cf1:age") TBLPROPERTIES("hbase.table.name" = "lyja"); 6.准备数据 2,wangwu2,320 3,lisi2,110 7.上传数据到hdfs hdfs dfs -put test

pipe(command, [envVars]) 对于每个分区，都执行一个perl或者shell脚本，返回输出的RDD 1 2 3 4 5 6 7 8 9 10 11 scala> val rdd = sc.makeRDD(List( "wangguo", "yangxiu", "xiaozhou", "kangkang"),3) rdd: org.apache.spark.rdd.RDD[String] = ParallelCollectionRDD[9] at makeRDD at <console>:24 scala> rdd.pipe( "/opt/test/spark/pipe.sh").collect res4: Array[String] = Array(wangcen, wangguohehe, wangcen, yangxiuhehe, wangcen, xiaozhouhehe, kangkanghehe) scala> val rdd = sc.makeRDD(List( "wangguo", "yangxiu", "xiaozhou", "kangkang"),4) rdd: org.apache.spark.rdd.RDD[String] = ParallelCollectionRDD[11] at makeRDD at <console>:24

0.Hive中的优化分类 真正想要掌握Hive的优化，要熟悉相关的MapReduce，Yarn，hdfs底层源码，明晰Hive的底层执行流程。真正让你明白Hive调优系列，会征对下面分类逐一分析演示。 大类1：参数优化 文件输入前看是否需要map前合并小文件 控制map个数，根据实际需求确认每个map的数据处理量，split的参数等 Map输出是否需要启动压缩，减少网络传输，OOM处理等 控制redcue个数，控制每个reduce的吞吐量，OOM处理等 是否将common-join转换成map-join处理策略 文件输出是否需要启动小文件合并策略 其他相关参数的配置：如严格模式，JVM重用，列剪切等 大类2：开发中优化 数据倾斜，这个是Hive优化的重头戏。出现的原因是因为出现了数据的重新分发和分布，启动了redcue。Hive中数据倾斜分类：group by ，count(distinct)以及join产生的数据倾斜（当然一些窗口函数中用了partition by一会造成数据倾斜） j oin相关的优化 ：分类大表join大表，小表join大表的优化 代码细节优化分类 ： 比如去重用group by替代distinct ； 多表关联，先进行子查询后再进行关联 ；表关联时一定要在子查询里过滤掉NULL值，避免数据倾斜； 不要对一个表进行重复处理，多使用临时表

导读： 众所周知，在大数据/数据库领域，数据的存储格式直接影响着系统的读写性能。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 字段不是

ClickHouse大数据分析技术与实战课程 课程基于ClickHouse的最新的20.x版本，从理论到实践，由浅入深详解ClickHouse的原理和使用。 本课程从零开始，有Linux操作系统和SQL使用经验即可。 课程以案例驱动，包含大量的实践案例。 将ClickHouse与MySQL、Kafka、HDFS等第三方系统集成，增强ClickHouse的功能。 课程覆盖面广，既有基础功能的详细讲解， 也包含了集群部署、查询优化、运维管理等高级内容。 来源： oschina 链接： https://my.oschina.net/u/4334316/blog/4316430