简历面试点

正能量用户奶嘴超人丶
94 阅读5分钟

一、 4paradigm

  1. 交付时效提速：端到端的完成数据集成、模型训练、应用部署、模型监控全流程自动化，实现AI模型生产上线流水线级别的应用部署。同时通过标准化的生产应用产物定义实现沙箱生产一键迁移(场景模板导入导出)，并借助参数化实现多环境的灵活适配(场景参数airflow)。

  2. 上线运维成本降低：

    • 具备高可用稳定运行基座，调度运行具备一定自愈处理能力，并搭配回报处理机制实现告警接入(airflow超时、重试、超时间隔、回填机制、callback函数)。
    • 系统提供标准化清理机制提升系统的稳定性(清理数据库中的scene、task、alertrule、param---清理airflow DAG、Variable---清理minio中的文件---调用k8s API清理alert rules---调用Grafana API清理Dashboard)。
    • 同时内置技术+业务指标实现模型线上的智能监控(模型监控)。

1. 为什么使用airflow？

  1. Airflow支持用户使用Python编写DAG来创建任务之间的依赖关系，从而构建工作流。Aiflow提供完整的DAG支持，且能够编写代码动态的生产DAG或者Task，支持使用ExternalTaskSensor的方式来构建跨DAG的依赖关系。
  2. 提供WebUI来监控任务的运行状态，用户可以在WebUI上或者是使用REST AOI来开启、关闭、触发、重跑DAG任务，查看任务运行的日志。
  3. 不仅支持常规的(Bash、Python、JDBC)Operator，还支持大数据领域(HDFS、Hive、Spark)的各种Operator。且支持机器学习相关的Operator，还支持云原生(Kubernetes、Docker)各种Operator，与各种通讯Operator(Email、Dingding、Wechat)无缝衔接。
  4. Airflow可以使用多种方式进行部署，常规的物理机、Docker容器、K8s集群部署。我们这边采用的是Helm Chart。
  5. 性能优异，自airflow2.0发布之后，各个组件均可以水平扩展，task之间的流转在秒级别，scheduler可以无限的水平扩展，结合k8s使用可以实现动态的缩扩容，极大的提升资源的利用率，降低成本。

支持定时、手动的调度能力。通过代码的方式编排复杂的工作流，并且可以通过XCom机制来实现上下游传输数据，通过trigger_rule来实现复杂的依赖关系。支持DAG&task级别的重试、超时、Callback能力。有着丰富的Operator(常规的BashOperator、PythonOperator、BranchOperator、ExternalTaskSensor)，还可以自定义Operator。还支持添加全局变量使得代码能够在运行时以Jinja模板来去替换。

2. Mysql清理工具

image-20220824222503575.png 0. 数据清理：

-   输入保留最近天数
-   输入保留最近版本数
-   输出总览信息，告知用户本次清理规模
-   确认清理后开始进行数据备份`SELECT ... INTO OUTFILE`

0. 备份恢复 LOAD DATA INFILE

  1. 备份删除

二、百度

image.png

  1. 用例撰写：

image-20220828145648533.png

  1. 由外向内移动，判断当前节点不是目标节点的祖先节点。拿到当前节点以及目标节点的祖先列表，如果当前节点在目标节点祖先列表中，则表示复制移动失败。

image-20220828150417998.png 2. LTS技术架构

LTS目前支持四种任务：
  • 实时任务：提交了之后立即就要执行的任务。
  • 定时任务：在指定时间点执行的任务，譬如 今天3点执行（单次）。
  • Cron任务：CronExpression，和quartz类似（但是不是使用quartz实现的）譬如 0 0/1 * ?
  • Repeat任务：譬如每隔5分钟执行一次，重复50次就停止。
架构设计上，LTS框架中包含以下五种类型的节点：
  • JobClient :主要负责提交任务, 并接收任务执行反馈结果。
  • JobTracker :负责任务调度，接收并分配任务。
  • TaskTracker :负责执行任务，执行完反馈给JobTracker。
  • LTS-Monitor :主要负责收集各个节点的监控信息，包括任务监控信息，节点JVM监控信息
  • LTS-Admin :管理后台）主要负责节点管理，任务队列管理，监控管理等。

LTS的这五种节点都是无状态的，都可以部署多个，动态扩容，来实现负载均衡，实现更大的负载量, 并且框架采用FailStore策略使LTS具有很好的容错能力。

LTS architecture

LTS progress

三、牛客网社区论坛项目

1. Redis(点赞、关注、存储验证码、存储登录凭证、缓存用户信息)

  1. 点赞使用set类型存储，key为点赞对象(人、帖子、评论)，set中保存点赞人的id；isMember()查看该用户是否点过赞

我收到的赞使用string类型存储，key为用户，并用increment(key)，decrement(key)实现

like:entity:entityType:entityId -> set(userId)

like:user:userId -> int

  • 点赞：首先查看set中是否有该用户id，如果有则为取消点赞-->移除并decrement(key)，如果没有则为点赞-->添加并increment(key)
  1. 关注使用zSet类型存储，key为被关注者，set保存关注者以及关注时间为score

followee:userId:entityType -> zset(entityId,now)

follower:entityType:entityId -> zset(userId,now)

  • 关注：关注者添加被关注者id，同时被关注者添加关注者id
  • 取关：关注者移除被关注者id，同时被关注者移除关注者id
  • 关注列表：reverseRange由大到小返回，还可以分页
  • 粉丝列表：同上
  1. 使用Redis存储验证码
  • 验证码需要频繁的访问与刷新，对性能要求较高
  • 验证码不需要永久保存，通常在很短的时间后就会失效
  • 分布式部署时，存在Session共享问题

Cookie里存放一个验证码的key："kaptchaOwner"，Redis将Kaptcha生成的text作为value保存起来。

  1. 使用Redis存储登录凭证
  • 处理每次请求时，都要查询用户的登录凭证，访问的频率非常高

生成登录凭证后，Redis会将该登录凭证随机生成的UUID作为key，loginTicket对象作为value保存起来；Cookie将该key："ticket"存起来。

登录拦截器会从Cookie中拿到该key，然后从Redis中拿到检查该凭证是否有效

  1. 使用Redis缓存用户信息
  • 处理每次请求时，都要根据凭证查询用户信息，访问的频率非常高

优先从缓存中取值，取不到时初始化缓存数据，数据变更时清除缓存数据

avatar
文章
阅读
粉丝