对"架构"的解析
前言
平常在工作中,经常能听到产品架构、功能架构、系统架构、技术架构
等各种关于架构的名词,这就引申出了几个问题,到底是什么架构,架构有什么用,架构都有哪些,我们该如何设计架构等等。本篇文章是从以下三个方面来对架构进行阐述的:
- 架构的定义
- 架构设计的关键要素
- 如何做架构
平常在工作中,经常能听到产品架构、功能架构、系统架构、技术架构
等各种关于架构的名词,这就引申出了几个问题,到底是什么架构,架构有什么用,架构都有哪些,我们该如何设计架构等等。本篇文章是从以下三个方面来对架构进行阐述的:
当前团队内有多个围绕着“特征”建立的系统,有特征系统、用户画像系统、分析门户等。在业务发展初期,这些产品都是紧贴业务的发展而建设的,系统功能模块和沉淀下来的特征也是基于运营活动、业务单元而垂直开发的,给后期带来了巨大的维护和开发成本。
本文的目的在于找到构建自身知识体系的方法,主要是从知识体系的作用、如何看待问题、怎样去划分知识体系以及如何填充知识体系框架来写的。
当需要掌握的知识越来越多时,对个人的挑战也越来越大,如果不把这些知识体系化的组织起来,不仅很容易遗忘一些知识点,个人水平也很难提高。构建知识体系可以帮助我们建立长期的规划和系统性的方法来帮助查缺补漏、确定长期目标,以更好的发展。
ps -eo nlwp,pid,args --sort nlwp
watch -n 1 'ps -eo nlwp,pid,args --sort -nlwp | head'
top -H -p pid
在上篇文章中主要是叙述了特征管理系统的顶层设计,从业务的角度对其进行了产品定位,根据它的定位将其划分为元数据管理、特征加工、特征服务三个功能模块,并简要的描述了实时特征计算的大致实现流程。本文再细化特征管理系统的实现。
实时特征对运营活动是必不可少的,特征的质量也会对业务产生直接的影响。但是由于当前没有一个统一的实时特征接入和生产平台,导致特征的产出过程过于混乱,实时特征的质量也是不可控的。当前现象及主要问题有:
近来在优化一个java项目的性能,在服务架构、gc、代码实现方式都做了基本的优化后,思考如何对其进行更进一步的优化。进一步的优化有两个方向:
组内有好几个线上服务,除了业务逻辑不一样,请求处理过程基本上都是一致的。这些服务的执行逻辑都非常简单,但是有几个问题:
OLAP 联机分析处理(OnLine Analytical Processing)。OLAP系统是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。
OLTP 联机事务处理(Online Transaction Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。
数据工程师( DE )和数据产品经理(DPM)日常的一部分工作是和运营、PM对接,根据需求产出APP层数据和可视化报表。 DE分别通过Tableau和数易来产出报表,但这两个产品都有局限性:
最近在做一个数据分析门户的过程中,引发了一个思考:我应该怎么才能把这个项目做好?
不仅仅追求技术上的精进,也能够跳出来看业务全局。
不仅能解决技术难题,还会主动关注业务,用技术加速业务的成功。
不要将业务和技术割裂来看,它们应该是一体的。
业务的需求能够促使技术进行创新,业务上的成功才能让技术产生意义。