2021H1小组述职记录
1. 数据框架上了解，数据处理的流程
2. 对数据交付有一个明确的标准，比如说准确性和及时性，衡量结果用数据说话
3. 了解清楚需求的背景、目标、收益
4. 说话太腼腆

设计原则

单一职责原则

并不单单指方法或者类的单一职责，对于微服务来讲，仍然是大的指导原则，每个服务的职责尽量单一

封装变化（开闭原则、高内聚）

在不稳定组件上创建稳定的抽象接口，将可能的变化封装在接口之后，使得系统内部的不稳定或者变化不会对系统的其它部分产生不良影响

依赖倒置（低耦合）

高层不直接依赖于底层的实现，需要依赖于接口

java基本功

分层思想

文章：https://www.jianshu.com/p/cbc3846df8d5

好处：专注、复用、扩展

核心：接口定义，面向接口编程

service层

业务逻辑，不同的需求千奇百怪；数据服务大多是查询维度的处理，比如说事业部表现、品类表现；针对不同的表现，需要处理的业务逻辑也是不同的。

这一层一定不要耦合存储引擎的查询逻辑，比如说mapper直接用在这一层，es查询直接用在这一层，并且还进行了一些es api的Response的处理；只有pm需求迭代的时候，我才能动这一层的代码，我们自己的一些技术优化，禁止改动这一层的代码。

这一层最常用的两种设计模式：策略模式、责任链模式。

manager层

通用业务处理层，屏蔽不同需求的千奇百怪，抽象出最通用的；

对第三方平台封装的层，预处理返回结果及转化异常信息；
对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；
与 DAO 层交互，对多个 DAO 的组合复用。

尤其这一层需要特别注重接口的入参和输出的规范性，需要通用，输入和输出不能跟第三方的类耦合。

关键API

stream
- flatmap
optional

抽象类、接口、继承、实现接口的应用场景总结

什么时候用接口，什么时候用抽象类，什么情况是继承，什么情况是实现接口

思考：如何在实际开发中抽象出通用的接口，而不是所有逻辑平铺在一个方法中

每一层需要接收什么信息，提供什么能力
每层内部需要执行什么样的流程，流程能否抽象成统一的接口

队列与线程池

自己抽象一个接口，调用这个接口，每次能够获取一条消息
自己抽象一个接口，调用这个接口，可以批量将消息写入某个存储

实现这样一个写入功能，要求：数据写入能够支持并发和批量写入，并且并发度和批量大小可以通过参数调节

自己起一个本地的小项目，类似我们的platform，使用springboot，要求项目能够启动运行

存储引擎

列式存储与行式存储|olap&oltp

优缺点分析

列存优点：

单列数据保存在一起，不同列分开存储，导致存下同样一个表需要更多的Block文件，看起来是更复杂了，但是基于列和列分开存储，这种形式天生就适合分布式的存储，并能完全利用并发写入和并发读取的能力
同一列存放在一起，数据类型相同，则更好的进行压缩
同一列存放在一起，则排序更加方便，基于排序方便，where某一列会更加快

行存优点：

行式存储对于 OLTP(事务型) 场景是很自然的：大多数操作都以实体（entity）为单位，即大多为增删改查一整行记录，显然把一行数据存在物理上相邻的位置是个很好的选择。
更容易实现事务性、一致性控制。

总结：

行：一致性、事务更加容易实现
列：吞吐量高、性能强，一致性、事务性较弱

从需求到表结构设计

需求来了，不是等数仓出表结构，我们才有表结构，而是我们先设计应用层的表结构，转而去向数仓提要求，要求他们的表是什么粒度的

两种数据模型

聚合结果冗余模型（cube）
细粒度聚合模型

分布式

es&doris：hash、路由

doris

数据模型：唯一、重复、聚合
数据存储：列存
数据索引：前缀索引，rollup
高可用&高性能：分区、分桶、cpu资源充分发挥
重点数据结构：bitmap

olap

olap方面doris为什么比es强

暂时先不考虑doris的rollup和聚合模型，假设只用doris的duplicate模型

工具&规范

通过idea进行commit和push，push之前打开代码对比，再过一遍自己的代码

数据治理

为了能够全面的衡量数仓治理的效果，我们新建了数据衡量指标体系，总体分为五大类：质量类、成本类、安全、易用性和价值。在监控方式上分为日常监控和定期监控（周、月、季度监控），让我们知道整体数据治理是整体向好、平稳还是向坏的。

总体来说，数据治理分为三个大阶段：被动治理、主动治理、自动治理。

维度和指标体系

维度建模

指标表和维度表关联
星型模型和雪花模型

衍生指标

通过已有指标，还能直接计算出新的指标，而不用数仓再加工一次
烟囱式开发问题

sql join比较多，可以通过DAG的形式进行逻辑优化

线上稳定性

es一台机器fullgc导致集群不可用的解决思路，分析问题的本质：

事前：规范、演练
事中：告警、监控、降级、降噪追踪（日志）
事后：复盘、大查询治理

监控：事前预防，事中监控，事后追踪

架构图

C4架构

业务学习

业务学习，报表对业务的价值，尤其pm的看板需求，了解其中业务背景

需求上线之后，需要有方式监控需求的效果，访问人数、访问频次、下载量等