原文链接：走好数据中台最后一公里，数据服务API是数据中台的标配视频回顾：点击这里课件获取：点击这里一、数据服务API建设背景在数字化转型的时代背景下，新需求的大量增长、新技术的不断迭代，“互联网化、数字化”进程的不断深入，越来越多的业务被迁移到互联网上，产生大量的业务交互和对外服务需求，对API接口的需求与日俱增，如何快速提升企业数据开放共享能力，是企业面临数字化转型的关键命题。传统的方式如后端开发人员通过Java或Python等语言进行编写来生成API接口，开发周期过长，运维成本太高，已经不能满足企业的需求。企业在数字化转型过程往往面临诸多难题：为了更多的解决这些问题，我们在企业开放、共享
今天我们来和大家聊一聊一个新话题，一个对于企业业务发展十分关键的东西——指标。指标建设是衡量企业业务效果的主要依据，本文结合自身实践经验和大家分享指标的设计与加工过程，讲述其基础概念和设计加工方法，以及设计加工过程中的注意点，希望对感兴趣的同学有所帮助。一、指标建设的必要性1、什么是指标指标是客观描述某个事物某个特征的可量化的数字度量，如用户最近30天购买次数，某商品最近30天销售额等。指标常从多个维度来描述，如某地区的新增用户数、线上线下的新增用户数，维度让指标更加具象与丰满。2、建设背景大数据时代数字化转型背景下，企业所需要的往往不单单是数据，而是数据背后映射的业务洞察，相比较数据我们更加
今天我们来和大家聊一聊一个新话题，一个对于企业业务发展十分关键的东西——指标。指标建设是衡量企业业务效果的主要依据，本文结合自身实践经验和大家分享指标的设计与加工过程，讲述其基础概念和设计加工方法，以及设计加工过程中的注意点，希望对感兴趣的同学有所帮助。一、指标建设的必要性1、什么是指标指标是客观描述某个事物某个特征的可量化的数字度量，如用户最近30天购买次数，某商品最近30天销售额等。指标常从多个维度来描述，如某地区的新增用户数、线上线下的新增用户数，维度让指标更加具象与丰满。2、建设背景大数据时代数字化转型背景下，企业所需要的往往不单单是数据，而是数据背后映射的业务洞察，相比较数据我们更加
导读：本文将介绍过去15年中，网易大数据团队在应对不断涌现的新需求、新痛点的过程中，逐渐形成的一套逻辑数据湖落地方法。内容分为五部分：关于网易数帆为什么做逻辑数据湖怎么做逻辑数据湖未来规划精彩问答--01关于网易数帆网易数帆是从网易杭州研究院孵化出来的。网易杭研的重要职责是公共技术的研究和产品孵化。下图是网易数帆的整体产品架构。1.网易大数据发展历史网易是国内领先的互联网技术公司，从2006年就开始对大数据相关技术进行探索。2009年为了支撑网易博客等产品的海量数据，开始了分布式文件系统、分库分表中间件（网易DDB）等技术的研发，并且于当年引入了Hadoop进行探索。2014年到2017年，网
导读：本文将介绍过去15年中，网易大数据团队在应对不断涌现的新需求、新痛点的过程中，逐渐形成的一套逻辑数据湖落地方法。内容分为五部分：关于网易数帆为什么做逻辑数据湖怎么做逻辑数据湖未来规划精彩问答--01关于网易数帆网易数帆是从网易杭州研究院孵化出来的。网易杭研的重要职责是公共技术的研究和产品孵化。下图是网易数帆的整体产品架构。1.网易大数据发展历史网易是国内领先的互联网技术公司，从2006年就开始对大数据相关技术进行探索。2009年为了支撑网易博客等产品的海量数据，开始了分布式文件系统、分库分表中间件（网易DDB）等技术的研发，并且于当年引入了Hadoop进行探索。2014年到2017年，网
背景概述最近计划着重分析一下线上各api的HTTP响应耗时情况，检查是否有接口平均耗时、99分位耗时等相关指标过大的情况，了解到nginx统计请求耗时有四个指标：request_time、upstream_response_time、upstream_connect_time与upstream_header_time，在查找资料的过程中，发现无论是nginx官方文档还是热心网友们的分享，都并没有让自己感觉特别详细、明白地说清楚了这四个指标详细具体含义的资料，于是自己动手探究了一番nginx源码，尝试从其中找出这4个指标的代码级别具体含义。特别说明：本文代码分析基于nginx1.10.0版本，从
背景概述最近计划着重分析一下线上各api的HTTP响应耗时情况，检查是否有接口平均耗时、99分位耗时等相关指标过大的情况，了解到nginx统计请求耗时有四个指标：request_time、upstream_response_time、upstream_connect_time与upstream_header_time，在查找资料的过程中，发现无论是nginx官方文档还是热心网友们的分享，都并没有让自己感觉特别详细、明白地说清楚了这四个指标详细具体含义的资料，于是自己动手探究了一番nginx源码，尝试从其中找出这4个指标的代码级别具体含义。特别说明：本文代码分析基于nginx1.10.0版本，从
问题背景大一点的公司都会建立一套规章流程来避免低级错误，例如合入代码前必需经过同行评审；上线前必需提测且通过QA验证；全量前必需经过1%、5%、10%、20%、50%的灰度过程。尤其是最后一步，需要严密的监控发版指标来保证新版本的质量，如果与主力版本的指标相比有异常变动，就需要及时停止放量并分析原因。一个版本的重点观察指标，除崩溃率外有小20项，分布在系统的10多个页面，且每个指标均需要指定多达6-10个过滤条件，最常用的包括版本号、端类型(PC/Mac/Android/iOS/…)、用户类型(user/vip/svip)，此外还有一些复杂的下拉列表选项，每次都记不住，需要参考文档才能确定选对
问题背景大一点的公司都会建立一套规章流程来避免低级错误，例如合入代码前必需经过同行评审；上线前必需提测且通过QA验证；全量前必需经过1%、5%、10%、20%、50%的灰度过程。尤其是最后一步，需要严密的监控发版指标来保证新版本的质量，如果与主力版本的指标相比有异常变动，就需要及时停止放量并分析原因。一个版本的重点观察指标，除崩溃率外有小20项，分布在系统的10多个页面，且每个指标均需要指定多达6-10个过滤条件，最常用的包括版本号、端类型(PC/Mac/Android/iOS/…)、用户类型(user/vip/svip)，此外还有一些复杂的下拉列表选项，每次都记不住，需要参考文档才能确定选对
前言随着Prometheus监控的组件、数量、指标越来越多，Prometheus对计算性能的要求会越来越高，存储占用也会越来越多。在这种情况下，要优化Prometheus性能,优化存储占用.第一时间想到的可能是各种Prometheus的兼容存储方案,如Thanos或VM、Mimir等。但是实际上虽然集中存储、长期存储、存储降采样及存储压缩可以一定程度解决相关问题，但是治标不治本。真正的本，还是在于指标量（series）过于庞大。治本之法，应该是减少指标量。有2种办法：Prometheus性能调优-解决高基数问题根据实际使用情况，只保留（keep）展示（GrafanaDashboards）和告警
