另一种挂载ceph为文件系统的方式，是ceph官方文档推荐的方式，使用fuse的缺点就是读写速度太慢，官方推荐使用rados原生方式挂载。当然前提条件也是创建好相关的pools，跟cephfuse方式前置条件是一样的。mount -t ceph admin@cbe5153d-0d61-488b-b0e9-9deaac3f519b.cephfs=/ /cephfs mount -t ceph adm
最近在某个外包项目上用到了ceph，迫不得已学习了一下安装部署和优化. 把学习使用过程总结一下。于ceph一路纯新手，不喜勿喷。项目背景是一数据仿真项目，需要将实验数据导入到一个存储集群中，然后经过裁剪优化，以动画形式仿真还原导弹飞行过程和雷达扫描范围等。数据量较大，包含视频等内容，大约每次实验几百G到十几T不等。需求方将项目包给一国企，国企将项目包给一有资质私企，资质私企将项目中存储和仿真还原生
23年初, 挺过了明略秒针22年一轮又一轮的裁员, 到了也没能坚持到最后, 还是被裁了. 最后到我走的时候大概从最多时候不到5000人裁到了几百人吧. 两年没发年终奖, 补偿金也要延后几个月发. 这个就不多说了, 今年大厂普遍都不怎么样.在家找了四个月工作, 投哪哪都不要, 不是学历不行就是经验不行, 行吧, 10多年大数据系统白搞了, 被HR回复经验不行. 最后靠朋友推荐找了个小厂,
昨天花两小时帮可口可乐的dmp集群排查了一个集群故障.故障表象为块的复制很慢, 导致集群报超时错误, 大量机器报超时错误. 还有一批机器报Slow BlockReceiver write packet to mirror 的WARN首先按常规排查处理, 检查机器操作系统环境, 各种tcp参数已优化, 各种limit也已经优化.然后检查硬件用 hdparm 测试了几个服务器的几块硬盘读写速
本次记录一下限制用户spark8s进程数量的方法, 我们的jupyterlab是跑在pod里面的, sparkui是通过自定义jupyterlab url的方式来映射出来, 而lab url只有一个, 所以每次只能允许用户开启一个pyspark8s的notebook, 但使用过程中发现, 用户可以开好几个spark8s kernel的notebook, 其实使用是没什么问题的, 只是后面几个开的s
今天记录一下如何开发jupyter自定义magic,就是jupyter里面%%或者!这样用来标识解释器环境的东西.以下代码以访问greenplum数据库为例.importpsycopg2importpsycopg2.extrasfromconfigparserimportConfigParserimportpandasaspdfromIPython.core.magicimport(cell_ma
因为甲方的“数据科学家”经常执行一些危险代码或命令而不自知, 而lab本身又不记录用户的操作记录, 导致一些数据被删除了缺找不到人背锅, 所以我们必须给jupyter加上code和terminal执行的日志, 以防甲方甩锅. 也是不得已而为之. 我们给甲方“数据科学家”用的jupyterlab是放在k8s pod里面的, 算是个云平台吧. 以后有时间再说说我们这个私有数据云的架构设计.现在在搞大老
这次改的是用jupyterlab跑sparkonk8sjupyterlab本身是跑在k8s里面的，然后甲方因为无论开多大内存，无论用vaex还是pandas都会内存溢出，所以打算用sparkonk8s方式跑，认为这样就不会溢出了，当然，实际上还是会溢出的。如何搭建sparkonk8s就不说了，官网就有教程。只说一下改造思路。这里有两个难点，一个是sparkkernel的创建，因为有人用spark，
这篇文章记录一下基于 jupyterlab做自定义接口和插件的二次开发过程和关键点目前我们给甲方提供的机器学习平台是基于k8s + jupyterlab实现的, 这样的好处是数据科学家可以在一个相对隔离的环境里开发自己的数据应用, 但是缺点是每个人之间无法共享自己开发的脚本给其他人. jupyter生态并不提供这样的功能, hub这种多用户系统也没有. 所以我们的思路是用第三方云存储来实现文件的共
很久没有写博客了, 这两年搞hadoop集群搞的少了, 总觉得没啥可写的. 最近因为业务需要, 在k8s和jupyter上面做了不少二次开发, 除了之前写的乱七八糟记录, 打算把一些阅读源码的经验和二次开发的代码记录一下. 内容可能包括之前写的乱七八糟记录的内容, 整理一下, 写个系列.这篇先整理记录一下之前的kerberos整合.本身jupyterhub似乎提供krb的验证方法, 但是不太合适给
记录一个调试 pyspark2sql 访问 HDFS 透明加密的问题。访问源码如下，使用 pyspark2.1.3，基于 CDH 5.14.0 hive 1.1.0 + parquet，其中select的部分会访问 hdfs 加密区域。from pyspark.sql import SQLContext from pyspark.sql import HiveContext, Row from p
一分钟内部署jupyterlab + pyspark2 + hive，前提是spark2是可以在yarn上正常运行的。最近甲方打着滚的向乙方要求装 jupyterlab，然后还要用spark2，所以，也是没辙，谁让人家是金主爸爸呢。搁我自己是绝不想在生产集群里装jupyter的。Terminal潜在危险性还是有的，按说是不符合甲方的安全小组规定的，但是业务小组又哭闹说没有不行，就看上jupyter
耗时很长时间解决了一个spark in docker的问题，记录一下。这是个非常奇怪的问题，找遍谷歌都找不到答案，与其说是分析出来倒不如说是偶然发现。先介绍一下架构和环境。Z机器是docker的宿主机，在每个docker里面都跑了一个Zeppelin用作数据分析，之所以这样弄，是客户要求每个人的环境都必须是独立的。Zdocker假设是Z上面跑着zeppelin的运行的一个docker镜像。Zdoc
从这篇开始记录一下集群迁移的事情早先因为机房没地方，就已经开始规划集群搬机房的事情，最近终于开始动手了，我会把这次不停机迁移的过程遇到的主要问题和矛盾以及各种解决方法记录下来。集群规模说大不大，几百台，总容量30PB左右。Hadoop使用CDH加一些自定义patch的rpm打包编译版本。总的方案是集群不停机，在两个机房之间架设专线，旧机房decommission，拉到新机房recomm
最近做集群机房迁移，在旧机房和新机房之间接了根专线，做集群不停机搬迁，也就是跨机房，同时要新加百多台服务器，遇到几个问题，记录一下。旧集群的机器是centos 6, 新机房加的机器是centos 7。一、丢包问题在跨机房的时候，datanode显示很多Slow BlockReceiver的日志WARN org.apache.hadoop.hdfs.server.datanod
今天抽空解决了一个Hadoop的一个非常有意思的故障，之所有有意思，是这个故障既可以称之为故障，又不算是故障，说不算问题吧，作业跑的特慢，说算问题吧，作业不但都能跑出来，还没有任何报错，所以还比较难查。故障表象是一帮人嚷嚷作业太慢了，跑不动，但是基本上嚷嚷一会就能跑出来，但相对于原来还是慢。我看了下，确实比较慢，有些作业一个map要半小时，但不是所有作业都这样，部分作业就很快，没有什么规律可循
其实不太想用opentsdb，一直以来用influxdb+grafana挺方便的，而且tsdb依赖hbase，虽说容量和速度有保证，但是分布式系统对于一个监控平台来说，终归还是有些重了，出问题定位更繁琐，但领导说用那就用吧。在这里必须吐一下OpenTSDB和Tcollector的文档更新，太落后，看官方文档根本找不到配置文件的位置。最后还得看源码，尤其是TCollector，这个tsdb官方推出的
Mac下安装配置Kerberos了解一下。公司强迫开发人员全部使用mbp，我很不爽，因为mac下面使用mit的kerberos简直是灾难，申请用普通笔记本装linux也不批。MacOSX是闭源系统，安装配置开源的东西都很麻烦。是的，port和brew很方便，但是有些需要的C语言开发头文件貌似是不软链的，而且源码编译还有一堆的依赖要编译，比如kerberos源码依赖openssl头文件，而opens
继续说一下Kerberos与Hadoop的集成。其实这个话题在网上已经很普遍了，没什么太新鲜的。就是顺带说一下吧，Hadoop账号的集成与管理。之前已经装了kdc和kadmin，所以接下来就需要创建hadoop相关的账号了。首先需要用kadmin进入kerberos管理prompt，这里需要输入之前创建的admin账号的密码。然后就可以创建了，用 ? 可以查看允许使用的命令。比如我们创建如下账号。
在实际开始安装配置Kerberos以前，我打算先说一下keytab。keytab，key table。上一篇的Principal里面，我们了解到了，Principal是kerberos的认证主体，相当于是你的账号。而keytab，可以粗浅的理解为SSH里面对应账号的私钥，而不同的是，SSH的私钥每个账号会有一个，而keytab是可以多个principal合并为一个的。原因是，keytab并不是作为
Kerberos古已有之，是由MIT开发，对三方进行验证鉴权的服务安全管理系统，很好的体现了西方三权分立的思想。名字来源于希腊神话地狱三个脑袋的看门狗，这只狗在哈利波特中也路过脸。对，跳吧，跳进坑里去吧。一入K坑深似海，从此作者不早起。 系统设计上采⽤用客户端/服务器器结构与DES加密技术，并且能够进⾏行行相互认证，即客户端和服务器器端均可对对⽅方进⾏行行
今天下午写了一会代码，然后帮同事解决了一个hbase相关的故障分析，定位了问题根源，觉得比较有代表性，记录一下。先说一下问题的发生与背景。这个故障其实是分为两个故障的，第一个比较简单，第二个相对复杂一些。同事写了一个HBase相关的测试代码，使用Hbase原生JavaAPI，编译打包后分别放在两台测试服务器测试，一台可以，另一台不可以。第一个故障是发生在两台测试服务器的：A服务器是正常连通的服务器
51CTO博客开发E网情深bsder李晨光原创技术博客
Zeppelin启用https过程和Hack内核以满足客户需求的记录。原因是这客户很有意思，该客户中国分公司的人为了验证内网安全性，从国外找了一个渗透测试小组对Zeppelin和其他产品进行黑客测试，结果发现Zeppelin主要俩问题，一个是在内网没用https，一个是zeppelin里面可以执行shell命令和python语句。其实这不算大问题，zeppelin本来就是干这个用的。但是渗透小组不
记录一下spark和pyspark在Zeppelin里面访问lzo文件报错的问题。由于甲方全球500强极度抠门，死活不愿意加服务器，然后接入的数据源又多，小集群很快就会被撑满，所以没办法，原始日志均采用lzo压缩存储。hadoop和spark都是采用正版Cloudera Manager部署，这方面没有太大问题。在命令行方式下，spark-shell是完全可以直接读取lzo的。但是在Zeppelin
Kerberos保护下的Hive排错记录，5月14日，Megadeth北京见。同事想在zeppelin里面使用Hive，这是在新的kerberos保护下的集群里第一次使用Hive，不幸的是，使用过程中还是出现了验证授权的问题，所以我不得不去排查问题。Hive的客户端服务器已经安装的hadoop-client，并且把所有需要的keytabs文件都放到了配置文件夹下且设置了正确的权限。但是仍然无法连接
之前为了练习英语用英文写的这个博客，然后被编辑置为转载了，所以想想还是翻译过来比较好。原文发表于 https://xianglei.tech 确实是我自己原创的。英文很烂，所以才需要练习。使用Cloudera Manager启用Kerberos安全增强的Hadoop集群(包括一步步安装和配置kerberos)以及kerberos基本原理目前我工作于AdMaster，某个全球五百强的大企业是我们的深
This is the first time I try to use english to write my blog, so don't jeer at the mistake of my grammar and spelling.Because of multi threaded drelephant will cause JobHistoryServer’s Loads very high
Hadoop集群监控需要使用时间序列数据库，今天花了半天时间调研使用了一下最近比较火的InfluxDB，发现还真是不错，记录一下学习心得。Influx是用Go语言写的，专为时间序列数据持久化所开发的，由于使用Go语言，所以各平台基本都支持。类似的时间序列数据库还有OpenTSDB，Prometheus等。OpenTSDB很有名，性能也不错，但是基于HBase，要用那个还得先搭一套HBase，有点为
公司基础架构这边想提取慢作业和获悉资源浪费的情况，所以装个dr elephant看看。LinkIn开源的系统，可以对基于yarn的mr和spark作业进行性能分析和调优建议。DRE大部分基于java开发，spark监控部分使用scala开发，使用play堆栈式框架。这是一个类似Python里面Django的框架，基于java?scala?没太细了解，直接下来就能用，需要java1.8以上。prer
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
