前言

最近 Yarn 队列资源收缩后，部分流量数据的 druid 离线摄入任务执行时间过长，经常由于申请不到 container 导致并发过低或者 reduce task 频繁失败重试，耗时 6~8h 才能完成。由于本身已经是 T+1 数据，离线摄入执行过长对下游使用方造成了很不好的使用体验。本文主要记录如何定位问题及如何解决。

前言

日常工作中采用 Druid 做流量日志分析。因为是刚接触，所以在离线/实时数据摄入过程中经常会碰到一些问题，本文主要用来记录这些问题及一些思考。

前言

目前使用 hexo+github pages 构建博客站，但是作为笔记管理系统有两个缺点：

1. 笔记是学习一个事物的过程，记录可能比较随意。博客是学习一个事物并实践之后得到的思考。放到同一个主站点下面，即使打了 tags，给人的感觉也比较混乱。
2. hexo 笔记分层管理不太方便，需要自己新建 tab，并逐级构建章节文件夹，并且新建的 tab 对目录集成不是很好。

本文主要记录 gitbook 的搭建集成，参考了 打造完美写作系统：Gitbook+Github Pages+Github Actions

前言

最近工作中越来越感受到监控对于查找问题的重要性，一个完备的链路监控对问题定位和趋势分析提效非常高。比如一条实时数据流，从数据采集到消费到入库各个阶段都有一些可观测性的指标（binlog 采集延迟，kafka-lag，读写 QPS，max-request-size，offset 趋势）。如果 kafka-lag 比较小并且 topic 写 QPS没打太高，但是数据有延迟，这里大概率就是上游采集的问题。
这里借用 prometheus 官网的话介绍监控的作用。

• 长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。
• 对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过监控能够方便的对系统进行跟踪和比较。
• 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理或者提前预防问题的发生，避免出现对业务的影响。
• 故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析，能够找到并解决根源问题。

本系列主要用来记录工作中常见系统的监控实现，指标含义以及如何通过监控定位问题并在相关任务挂掉后如何和给下游业务一个较准确的预估恢复时间。大部分借助开源实现。

前言

Homebrew 是 Mac 下方便快捷的包管理器。但是有时候因为其版本迭代等，导致 brew update 执行后各种依赖报错或者 Warning。emmm，碰到好几次了，并且由于网上解决办法参差不齐，每次解决浪费了大量时间。遂记录下每次的解决方法。建议遇到问题去查看官方 issue

前言

最近打算把自己 Mac 卖掉，重装系统碰到了个问题，搞了一天多才搞定，遂记录下。具体是在线重装系统进入到磁盘工具后，找不到主盘，只有一个不到 3G 的 disk0，无法抹掉主盘上的数据且重装系统的时候也识别不到主盘。和这个问题比较类似，不过解决办法真是扯了，网上都是千篇一律，说不清楚，根本不能解决😑 。

前言

工作上存在将 Hive 上的数据刷到 ES 的场景，首先想到的是自己写程序读取 Hive 上的数据，经过业务逻辑处理在写回到 ES 上，不过请教了下，知道了 ES 本身已经可以和 Hive 集成。只需添加对应的 jar 包，在 hive 上建立与 ES 关联的外部表，即可使用 HQL 查询写入 ES 索引库。具体使用请见官方文档 ，本文只举个简单例子及介绍下主要的参数。

前言

最近工作中用到的，以前没有搞过 binlog，遂在本地完整的跑遍 demo 看看。整体数据流如下，Canal 接收 MySQL Binlog 到 Kafka。Spark Streaming 消费数据写到 ES。

前言

2020 经历了太多的事情，很幸运的是我身边有很多朋友，是他们在我落寞的时候给了我鼓励。

前言

个人代码维护在 github，而目前大多数公司代码维护在私有 gitlab。这是两套不同的账户体系，并且一般私有 gitlab 的 commit email 不能更改，git 全局的用户名和邮箱只能有一个。这就导致了如下问题 → 不管配置了几个 SSH pub key，SSH 认证最终走的都是 global 的用户名的认证（比如你全局的用户是 github 的，那么你提交 gitlab 就会报 Permission Denied）。本文主要用来解决此问题。
其实多个 SSH 配置的话都是这样搞的，配个路由就好了。