对"架构"的解析

前言

平常在工作中,经常能听到产品架构、功能架构、系统架构、技术架构等各种关于架构的名词,这就引申出了几个问题,到底是什么架构,架构有什么用,架构都有哪些,我们该如何设计架构等等。本篇文章是从以下三个方面来对架构进行阐述的:

  • 架构的定义
  • 架构设计的关键要素
  • 如何做架构
阅读更多

特征平台升级实践

背景

当前团队内有多个围绕着“特征”建立的系统,有特征系统、用户画像系统、分析门户等。在业务发展初期,这些产品都是紧贴业务的发展而建设的,系统功能模块和沉淀下来的特征也是基于运营活动、业务单元而垂直开发的,给后期带来了巨大的维护和开发成本。

阅读更多

构建知识体系

本文的目的在于找到构建自身知识体系的方法,主要是从知识体系的作用、如何看待问题、怎样去划分知识体系以及如何填充知识体系框架来写的。

作用

当需要掌握的知识越来越多时,对个人的挑战也越来越大,如果不把这些知识体系化的组织起来,不仅很容易遗忘一些知识点,个人水平也很难提高。构建知识体系可以帮助我们建立长期的规划和系统性的方法来帮助查缺补漏、确定长期目标,以更好的发展。

阅读更多

系统工具

进程/线程

  1. 查看所有线程数量 ps -eo nlwp,pid,args --sort nlwp
  2. 监控 watch -n 1 'ps -eo nlwp,pid,args --sort -nlwp | head'
  3. 查看进程线程数量,每个线程的cpu利用率 top -H -p pid
阅读更多

特征平台(二)

整体架构

在上篇文章中主要是叙述了特征管理系统的顶层设计,从业务的角度对其进行了产品定位,根据它的定位将其划分为元数据管理、特征加工、特征服务三个功能模块,并简要的描述了实时特征计算的大致实现流程。本文再细化特征管理系统的实现。

阅读更多

特征平台(一)

背景

实时特征对运营活动是必不可少的,特征的质量也会对业务产生直接的影响。但是由于当前没有一个统一的实时特征接入和生产平台,导致特征的产出过程过于混乱,实时特征的质量也是不可控的。当前现象及主要问题有:

阅读更多

服务超时问题

背景

上游一个服务在调用我们服务的时候突然出现了大量的超时。首先怀疑的是docker机器挂掉了,然后看了下服务的调用量监控,如下图。

阅读更多

多进程网络服务

背景

近来在优化一个java项目的性能,在服务架构、gc、代码实现方式都做了基本的优化后,思考如何对其进行更进一步的优化。进一步的优化有两个方向:

  1. 使工程本身(架构、gc、代码)再进一步。
  2. 验证类似nginx一样的多进程网络服务是否可行。较容易实现,且很容易应用到其它线上服务上。
阅读更多

在线服务性能优化

背景

组内有好几个线上服务,除了业务逻辑不一样,请求处理过程基本上都是一致的。这些服务的执行逻辑都非常简单,但是有几个问题:

  1. 单机QPS很低,需要很多台机器
  2. 99分位耗时比理论上的长很多
  3. 在单机qps达到上限时,服务器的负载却非常低
阅读更多

学习的方法

引用两句话:

我想更深入的探讨一个系统的设计是被什么现实和本质问题所逼迫的结果
从乱糟糟的观察到的混乱表象中,抽象出流系统所面对的问题和解决方案的本质
文章连接

阅读更多

OLAP系统

前言

概述

OLAP 联机分析处理(OnLine Analytical Processing)。OLAP系统是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

OLTP 联机事务处理(Online Transaction Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。

阅读更多

分析门户

序言

数据工程师( DE )和数据产品经理(DPM)日常的一部分工作是和运营、PM对接,根据需求产出APP层数据和可视化报表。 DE分别通过Tableau和数易来产出报表,但这两个产品都有局限性:

  • Tableau价格昂贵,使用人数有限制
  • 数易的可视化图表类型过少,不能满足需求
  • 且DE有个性化的需求,Tableau和数易均不能给出及时的响应
阅读更多

技术与业务之间关系的思考

最近在做一个数据分析门户的过程中,引发了一个思考:我应该怎么才能把这个项目做好?

不仅仅追求技术上的精进,也能够跳出来看业务全局。

不仅能解决技术难题,还会主动关注业务,用技术加速业务的成功。

不要将业务和技术割裂来看,它们应该是一体的。

业务的需求能够促使技术进行创新,业务上的成功才能让技术产生意义。

阅读更多