之前在家里带宝宝之余，也刷了一些有意思的leetcode题目，把他们记录下来也是有意义的。
这里是887 扔鸡蛋问题的基本描述：
给你k个鸡蛋，可以使用这些鸡蛋对1到n共n层楼的每一层扔下，在这些楼层中第f层扔下时鸡蛋会碎，我们需要在不知道f的情况下，最少做多少次测试能确定鸡蛋刚好会碎的楼层f. 因为f不确定，我们的答案需要保证在最坏的情况下，最高效的检测方案。

抽时间记录了一下之前在做大数据平台时候一些问题的记录和解决思路，设计节点性能排查，vpn server部署，以及hadoop生态各个组件的问题记录。

上一篇blog记录了实现一个基本日志包的过程，这里自己尝试实现一个带有rolling功能的日志包

其实从性能和功能单一的角度来说，很多日志库是不支持rolling相关的功能的，比如uber推出的zap日志包，就推荐用户自己通过logrotate等方式自己去处理日志rolling的问题。 不过有些场景下，我们希望日志文件能不需要外界干预的情况下正常运行。 可以通过实现一个支持rolling的io.Writer来解决这个问题。

之前工作中写golang项目的时候，一直都是用别人封装好的日志包，这里尝试自行去实现一个简单封装的日志包，当然，是基于golang自带的log包去封装了。

前面对golang中io读取文件的多种方式做了一个总结，这里记录下golang中文件下载保存的两种常用方式

• 小文件下载保存
  小文件的话，因为http返回的Response.Body 对象是 io.ReadCloser类型，调用io/ioutil包提供的ReadAll可以将其内容全部读取放入一个临时的slice中，然后使用ioutil.WriteFile将内容写入目标文件中。
• 大文件下载保存
  如果文件很大的，将文件内容全部读入一个临时的slice再一次性写入磁盘将占用大量的内存空间，同时写入效率也比较低。 比较推荐使用bufio包创建一个带缓冲区的writer对象，然后使用io.Copy方法实现 Response.Body这个reader到 writer对象的直接写入， 避免了内存大量占用的情况，同时提高了文件写入效率。

在golang中有多种文件读取的方式，这里自己做了个总结，可以根据自己的喜好合理选择。 总结来说，主要就是如下几种：

• 实现io.Reader接口的对象r，调用对应的r.Read()方法
• 实现io.Reader接口的对象r,传入io.ReadFull()方法，进行读取
• 使用”io/ioutil” 提供的ioutil.ReadAll()方法
• 使用”bufio”包提供的基于缓冲区的io.Reader接口实现，进行文件读取

部署概述，ambari 环境部署主要分为两步骤

• ambari server机器部署 （使用者可以通过访问server机器8080端口，在web中进行集群管理）
• ambari client机器部署（接受ambari server调度，进行实际的Hadoop服务组件安装）

有个hadoop集群的datanode节点,datanode rpc端口50010， netstat -antp|grep 50010会发现大量FIN_WAIT1状态的socket，且长时间不消失，看了socket的对端机器，发现同一个连接，显示的状态一直是established. 根据网上的资料，做了一个实验,重现了这个现象

问题描述

有个每小时执行一次的定时mapreduce任务，在数据量差不多的情况下，执行耗时有很大浮动。快的在10分钟以内，慢的要20分钟以上。

问题分析

引子

记录这篇博文是因为是因为有客户反馈过来一个hive问题：
对一个hive中的json数据外表执行 select * from table_name limit 1;报错：RuntimeException org.apache.hadoop.hive.ql.metadata.HiveException: Failed with exception nulljava.lang.NullPointerException

就先用自己的集群做了测试，发现是OK，最后去客户的集群操作同样的测试会报错，最后发现客户的集群hive版本很老1.1的，而我在hive1.2.1, hive 2.3.3上测试都是ok, 最后去社区去查了下，发现是hive 1.1版本的一个bug, 在1.2.0版本已经修复，最后推荐客户升级版本解决问题。