我的大数据之路:2023年度总结
2024-01-02 23:03:25
2023年度最值得骄傲的事
从0到1搭建了离线数仓体系,针对Hadoop生态组件的原理和特性有了深入的理解。
同时对“数据治理”有了一定的实践经验:
存储治理:
- HDFS基于纠删码的存储空间占用上优于多副本存储;
- 冷数据使用对象存储可以大幅降低成本。
计算治理:
- 基于RoaringBitmap的去重统计方案适合高性能的产品功能使用,但针对运营产品人员进行内部分析使用则不够友好,内部的多维分析可以考虑标签化的解法,参考:奇思妙想的SQL|去重Cube计算优化新思路;
- 跨任意时间段的统计是一个可以考验一个产品技术方案整体平衡性的场景,这里业务上需要回答是否一定需要跨任意时间段,真实的查询量是否支持这样的性能成本开销,技术上除了提供真实访问数据量外,还需要计算产品体验最优的成本和折中方案的成本,来支持产品决策。
2023年度吐血的经验教训
现在小公司都在走架构轻量化,所以基于Hive+Spark等Hadoop生态组件构建离线数仓体系,对小公司而已可能有些过重,基于Kafka+Flink+StarRocks/Doris的实时离线一体化方案正在成为小公司数仓架构首选。
StarRocks官网:什么是 StarRocks | StarRocks
性能方面可以参考某SAAS公司做的测试:
- QPS:
Queries Per Second
?是每秒查询率,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数,也即是最大吞吐能力。
Spark和Flink都具有流和批处理能力,但是他们的做法是相反的。Spark Streaming是把流转化成一个个小的批来处理,这种方案的一个问题是我们需要的延迟越低,额外开销占的比例就会越大,这导致了Spark Streaming很难做到秒级甚至亚秒级的延迟。Flink是把批当作一种有限的流,这种做法的一个特点是在流和批共享大部分代码的同时还能够保留批处理特有的一系列的优化。
同时,Flink 相比于 Spark 而言还有诸多明显优势:
- 支持高效容错的状态管理,保证在任何时间都能计算出正确的结果;
- 同时支持高吞吐、低延迟、高性能的分布式流式数据处理框架;
- 支持事件时间(Event Time)概念,事件即使无序到达甚至延迟到达,数据流都能够计算出精确的结果;
- 轻量级分布式快照(Snapshot)实现的容错,能将计算过程分布到单台并行节点上进行处理。
2023年度难忘的面试经历
1. 面试官问为什么选择Azkaban?这是个技术选型问题完全没答好。
2. 面试官又问项目的业务价值?这个也没答好,完全没发挥出来,临场反应过于仓促。
解法:
你在之前的某个项目中主要担任怎样的角色,具体做了些什么?
* STAR法则:从情景到做了什么到产出什么
* 模板:在之前的Xx项目中,主要的目标是xxx,我担任的是小组领队的角色,主要负责了线上公众号的运营,线下的活动策划/组织,最后成功完成了(如用户增长200%)
什么是star法则
star法则,是situation-task-action-result的缩写。
- situation: 事情发生的背景,为什么会去做这件事?
- task: 明确自己的任务,怎样在事情的背景下明确自己的任务。
- action: 采取什么行动,为了完成任务,做了哪些事,为什么要这么做,有其他方案吗?
- result: 最终取得的成果,行动中收获了什么,有没有完成目标?
文章来源:https://blog.csdn.net/weixin_40035038/article/details/135350002
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!