Sunny的专栏

一、常用思考方法技术思考本质还是结构化思考，所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧，而是分享从技术实战中得到的一些思考方法，为此我分为了技术架构设计的方法和技术Leader的思考方法两类。二、技术架构思考方法2.1 0--->1(还原客观事实，快速迭代)当我们在一堆迷茫和混乱中不知道如何下口时，应该先贴近问题本身，还原客观事实，并快速形成 1 个能够拉起认知并快速讨论迭代优化的版本。大

0、背景随着数据驱动业务的需求日益增多，数仓的建设越发频繁，开发人员在数仓构建这一个过程(埋点、埋点数据接收、数据补全、数据清洗、数据写入存储介质)，从事着大量且重复的工作，同时对于实时数仓构建，需要一定的专业技能，例如需要懂得如何利用Flink等框架做过滤、转换、聚合等，对于后端业务团队来说，学习成本高，很难快速上手，开发成本居高不下。为了解决这些问题，低代码数仓构建系统应运而生，通过工程化的思想去解决，将固有领域问题交给系统，让开发人员关注数据本身，解放人力缩短数仓构建周期。一、整体架构

一、什么是架构图1.1 理解与解析如何画好一张架构图，要做好这件事情首先要回答的就是什么是架构图。我们日常工作中经常能看到各种各样的架构图，而且经常会发现大家对架构图的理解各有侧重。深入追究到这个问题，可能一下子还很难有一个具象的定义，如果我们把这个问题进行拆分（如下图）理解起来就会容易一点。架构图=架构+图按照这个等式，我们可以把问题转换： 架构是什么？ 图是什么？ 图是什么？这个比较容易回答，图是一种信息的表达方式，所以架构图，即表达“架构”的图，也就是一...

一、需求场景分析1.1集群如何每天hold住10亿+请求拿电商平台为例，kafka 集群每天需要承载10亿+请求流量数据，一天24小时，对于平台来说，晚上12点到凌晨8点这8个小时几乎没多少数据涌入的。这里我们使用「二八法则」来进行预估，也就是80%的数据（8亿）会在剩余的16个小时涌入，且8亿中的80%的数据（约6.4亿）会在这16个小时的20%时间 （约3小时）涌入。通过上面的场景分析，可以得出如下：QPS计算公式 = 640000000 ÷ (3 * 60 * 60) = 6万，也就.

0、背景搭建ElasticSearch集群是否经常遇到这样的问题：如何评估集群的规模？比如数据量达到百万，千万，亿万，分别需要什么级别的集群，这要怎么评估？Elasticsearch 集群规模和容量规划：是进行 Elasticsearch 集群部署前对所需资源类型和数量的规划。通过本文，您将了解： Elasticsearch 计算资源详解 Elasticsearch 架构、增删改查操作和资源需求 Elasticsearch 集群规模和容量规划的方法论 一、Elast

一、低代码的理解在讨论各个低代码方案前，首先要明确「低代码」究竟是什么？这个问题不好直接回答，因为低代码是非常宽泛的概念，有很多产品都声称自己的低代码，但我们很容易反过来回答另一个问题：「什么是低代码产品唯一不可缺少的功能？」我认为这个功能是可视化编辑，因为非可视化编辑就是代码编辑，而只有代码编辑的产品不会被认为是低代码，因此可视化编辑是低代码的必要条件，低代码其实还有另一个更清晰的叫法是可视化编程。既然可视化编辑是低代码的必要条件，那从实现角度看，实现可视化编辑有什么必要条件？我认为可

一、DSL介绍DSL（Domain Specific Language）是针对某一领域，具有受限表达性的一种计算机程序设计语言。 常用于聚焦指定的领域或问题，这就要求 DSL 具备强大的表现力，同时在使用起来要简单。说到DSL，大家也会自然的想到通用语言（如Java、C等）。为什么没有一种语言同时 兼具『简洁』和『业务表达』能力呢？从信息论本质上来讨论这个问题，每个语言的程序都可以抽象为一个字符串，每个字符串由有限数量的合法字符组成，它在运行时会实现某个功能，因而可以看作是一种需求的信源编码。每

一、基于业务角度建模Elasticsearch 适用范围非常广，包括电商、快递、日志等各行各业。涉及索引层面的设计，和业务贴合紧密。其一：业务一定要细分。分成哪几类数据，每类数据归结为一个索引还是多个索引，这是产品经理、架构师、项目经理要讨论敲定的问题。比如大数据类的数据，可以按照业务数据分为微博索引、微信索引、Twiiter 索引、Facebook 索引等。其二：多个业务类型需不需要跨索引检索？跨索引检索的痛点是字段不统一、不一致，需要写非常复杂的 bool 组合查询语句来实现。为了.

0、前言所有的数据建设都是为了用户更快、更方便、更放心的使用数据。在用户使用实时数据的过程中，最影响用户体感的指标有两个： 数据质量：实时数据产出的准确性。举个例子：实时数据在某些场景下不能保障端到端 exactly-once，因此实时与离线相同口径的数据会有 diff。而 1% 和 0.01% 的 diff 给用户的体验是完全不同的。 数据时效：实时数据产出的及时性。举个例子：延迟 1min 和 延迟 1ms 的用户体验也是完全不同的。 通过以下两个指标就已经能监控和判定 90

0、前言Kafka的度量指标主要有以下三类：1.Kafka服务器（Kafka）指标2.生产者指标3.消费者指标另外，由于Kafka的状态靠Zookeeper来维护，对于Zookeeper性能的监控也成为了整个Kafka监控计划中一个必不可少的组成部分。一、Broker度量指标Kafka的服务端度量指标是为了监控broker，也是整个消息系统的核心。因为所有消息都通过kafka broker传递，然后被消费，所以对于broker集群上出现的问题的监控和告警就尤为重要。broker性

一、集群健康状态之红色或黄色含义红色或黄色集群状态表示一个或多个分片丢失或未分配。这些未分配的分片会增加数据丢失的风险，并会降低集群性能。二、集群健康状态诊断2.1 检测集群健康状态2.1 命令行方式GET_cluster/health?filter_path=status,*_shards2.2 可视化方式 head 插件可视化 kibana 可视化监控 集群状态 含义 绿色 健康状态，未见异常 黄色 至少一个副本分.

一、报错症状线上报错描述：问题 1：“我们目前节点还是有很多 reject 429，用了一些方法，比如增加Thread_pool 好像效果不大，还会load增高。还是很多堆积和reject。现在想咨询一下，是否只能增加服务器节点，如果增加，应该怎么样评估，更加合理？因为没有多余机器来做压测，只能根据现有的监控数据评估，能不能给些建议，重点来看哪些参数？”问题2：“es集群，写入经常reject 429，同时经常会出现 request retries exceeded max retry time

一、报错症状高 JVM 内存使用率会降低集群性能并触发断路器错误（导致内存熔断）。为了防止这种情况发生，如果节点的 JVM 内存使用率持续超过 85%，官方建议采取措施降低内存压力。二、 如何诊断2.1 检查 JVM 内存使用情况借助：node stats API 进行排查。GET _nodes/stats?filter_path=nodes.*.jvm.mem.pools.old召回结果如下：{"nodes" : {"J2-fr3wzSqqJk9cwoi2urw

一、报错症状1.1 客户端请求报 429 错误如果一个请求触发了一个断路器，Elasticsearch会返回一个错误，其 HTTP 状态代码为429。{ 'error': { 'type': 'circuit_breaking_exception', 'reason': '[parent] Data too large, data for [<http_request>] would be [123848638/118.1mb], which is larg

一、报错症状线上环境 Elasticsearch CPU 使用率飙升常见问题如下：Elasticsearch 使用线程池来管理并发操作的 CPU 资源。关于线程池和队列，推荐阅读：Elasticsearch 线程池和队列问题，请先看这一篇。Elasticsearch 高 CPU 使用率通常意味着一个或多个线程池不足以支撑业务需求。如果线程池资源耗尽，Elasticsearch 将拒绝与线程池相关的请求。例如，如果搜索线程池（search thread pool）耗尽，Elasti

一、报错症状当客户端向 Elasticsearch 写入文档时候报错：cluster_block_exception [FORBIDDEN/12/index read-only / allow delete (api)];在 elasticsearch 的日志文件中报错如下：flood stage disk watermark [95%] exceeded ... all indices on this node will marked read-only出现如上问题多半是：磁盘使.

一、简介&用途There’s a new API that supports analyzing thedisk usageof each field of an index, including the entire index itself. The API estimates the disk usage of a field by iterating over its content and tracking the number of bytes readWhat’s new..

0、ElasticSearch监控的指标参考：Elasticsearch Top10 监控指标一、Elasticsearch_exporter1.1 简介选择grafana作为监控是因为它展示出来很漂亮，而且可下载到前人使用过的配置文件，能够快速的搭建起监控系统；选择elasticsearch_exporter是因为它与ES集群是分开独立的，不需要对原有的ES集群(可能有很多个)做任何修改，不需要重启，只要能访问es集群即可，非常方便。1.2 安装过程1.下载链接：elastic.

0、监控Elasticsearch集群的重要性Elasticsearch具有通用性，可扩展性和实用性的特点，集群的基础架构必须满足如上特性。合理的集群架构能支撑其数据存储及并发响应需求。相反，不合理的集群基础架构和错误配置可能导致集群性能下降、集群无法响应甚至集群崩溃。适当地监视群集可以帮助您实时监控集群规模，并且可以有效地处理所有数据请求。本文我们将从五个不同的维度来看待集群，并从这些维度中提炼出监控的关键指标，并探讨通过观察这些指标可以避免哪些潜在问题。一、 集群健康维度：分片和节点

0、背景在工作中是不是经常要做各种分析，但又常常遇到无从下手，抓不住重点，搞不清关键数据的情况。俗话说“工欲善其事，必先利其器。”一个好用的数据分析模型，能给我们提供一种视角和思维框架，从而帮我们理清分析逻辑，提高分析准确性。一、AARRR模型AARRR模型又叫海盗模型，这个模型把实现用户增长拆分成了 5 个指标：获客、激活、留存、收益、传播。分别对应“用户如何找到我们？”、“用户的首次体验如何？”、“用户会回来吗？”、“如何赚到更多的钱？”、“用户会转介绍，告诉其他人吗？”这五个问题。大家