手机扁平化网站模版,制作购物网站需要多少钱,网站空间管理信息,网站后台验证码无法显示处理大数据的基础架构#xff0c;OLTP和OLAP的区别#xff0c;数据库与Hadoop、Spark、Hive和Flink大数据技术
2022找工作是学历、能力和运气的超强结合体#xff0c;遇到寒冬#xff0c;大厂不招人#xff0c;可能很多算法学生都得去找开发#xff0c;测开 测开的话OLTP和OLAP的区别数据库与Hadoop、Spark、Hive和Flink大数据技术
2022找工作是学历、能力和运气的超强结合体遇到寒冬大厂不招人可能很多算法学生都得去找开发测开 测开的话你就得学数据库sqloracle尤其sql要学当然像很多金融企业、安全机构啥的他们必须要用oracle数据库 这oracle比sql安全强大多了所以你需要学习最重要的你要是考网络警察公务员这玩意你不会就别去报名了耽误时间 与此同时既然要考网警之数据分析应用岗那必然要考数据挖掘基础知识今天开始咱们就对数据挖掘方面的东西好生讲讲 最最最重要的就是大数据什么行测和面试都是小问题最难最最重要的就是大数据技术相关的知识笔试 文章目录 处理大数据的基础架构OLTP和OLAP的区别数据库与Hadoop、Spark、Hive和Flink大数据技术[TOC](文章目录) 处理大数据的基础架构之后我们一个个来学习上述提到的东西形成一个大数据处理的框架备考大数据类的试题Hadoop、Spark、Hive和FlinkOLTP是啥为什么要大数据 kafka传输技术快速现有的消息模型kafka监听器kafka的消息模型生产者apikafka序列化实际订餐和菜品看不到 总结
处理大数据的基础架构
处理大数据的基础架构主要有以下几种
分布式计算框架。 如Hadoop、Spark、Hive和Flink等这些框架可以处理大规模的数据并支持分布式存储和计算。
分布式文件系统。 如HDFSHadoop Distributed File System和Google File System等这些系统可以存储大规模的文件并支持分布式访问和读取。
数据库集群。 如MySQL集群、PostgreSQL集群等这些集群可以提高数据处理效率和可用性并支持分布式事务处理。
NoSQL数据库。 如MongoDB、Cassandra和Redis等这些数据库可以处理半结构化和非结构化的数据并支持高并发写入和读取。
云平台。 如Amazon AWS、Google Cloud和阿里云等这些云平台可以提供虚拟化资源、弹性伸缩和自动化运维等功能使得处理大数据更加灵活和高效。
这些基础架构可以相互组合和扩展以适应不同的大数据处理场景和需求。
之后我们一个个来学习上述提到的东西形成一个大数据处理的框架备考大数据类的试题
冲
Hadoop、Spark、Hive和Flink 小数据问题不大
OLTP是啥
OLTP( On-Line Transaction Processing ) 联机事务处理过程 通常也可以成为面向交易的处理系统。
个人理解为主要场景针对用户人机交互频繁数据量小操作快速响应的实时处理系统中。 Mysql以及Oracle等数据库软件可以理解为OLTP的工业应用软件体现。
OLAP( On-Line Analytical Processing)联机分析处理过程。 个人理解为主要场景针对大批量数据实时性无要求基于数仓多维模型进行分析操作的系统中。 Hadoop体系中MapReduce、Hive、Spark、Flink等都可以进行为OLAP实现。
原来如此了数据库做不了大数据的分析类的问题
T是事务 A是分析
为什么要大数据 06年写Java的MapReduce程序难理解
后来写sql得了很简单 yarn出来就调度一把 美滋滋 docker现在听说得很多隔离空间 yarn是container集装箱 只写sql然后转译为hive那边的Java
还有pyspark写Python很容易 相当于是兼容超级多的程序
批处理这些是【离线一大批】
下面是流式计算【实时快速处理】
两家很骚后来俩都能处理了 各种技术你看看是不是穿起来了……………… 你是做那一层呢
kafka传输技术快速
我们从传输开始学起 TB级别量的数据后续可以对接很多大数据处理技术框架 有点厉害了
现有的消息模型 半结构化的东西
kafka是分布式消息系统 使得kafka有扩展性 offset不可重复 map消息 不给key那就随机分配 否则分区 同样的key同样的key放一起 follower就去复制数据同步保持数据的可恢复性 这样的话就不会丢失了 broker就是一台服务器负责读写 主分区由broker读写
kafka监听器 docker去部署kafka的内外网监听端口
kafka的消息模型 处于性能和开销的考虑 否则还要维护锁加锁减锁 否则就会引入竞争麻烦 最大化我们要提升性能和吞吐量 这种是一对一 不同分区之间的消费顺序不知道 offset早的是先消费 你想要保证顺序会设置key同 tcp ack确认信息 先读信息至少读一次 给位置最多读一次可以不读
生产者api 生产者只大量生产不管消费现在就是中国缓冲区满了老百姓没钱消费导致生产过剩
需要通过一带一路出去消费这时候美国不乐意 物流系统 就是网购系统一次精确消费 我扣款那边就要收款 我失败他不能收款 我付款了他不能允许说没收到
这就是原子性
数据库就这样的特性
kafka序列化 前序、中序、后序序列化 跟买电脑一样 一堆零件你送到了找师傅安装 实际上 要卡主时间顺序的
骚 注册制 header标识一下
实际订餐和菜品看不到 如果前面完不成后面就gg 网络延时导致的 异步重试顺序如何保证 一会上菜半天看不到gg 消息积压很恶心 不看所有信息只看id 又有问题看日志 有几个商户的订单贼多都放一个partition怎么办
那按照用户编号来放这样某个订单就走同一个partition 这样好多了 后面呢 促销…… 太骚了 哈哈哈技术太难了 消息积压有不同的原因
单表存了太多的菜品 并发太大俩请求同事查到id不存在 同时插入第二个就gg 加锁
Redis分布式锁怎么说 不行消费着网络超时gg 尝试插入不行就改key 主从服务器 有订单但是没有菜 主从数据库同步延时 就查不到数据 或者查不到最新数据 精确传才行
kafka默认就是容易重复 不存在插入存在就更新 公用数据库和kafka系统
在不同环境中切换容易出错 所以配置要搞清楚
cpu容易挂的话gg
kafka是牛逼的很少出问题大多都是逻辑出了问题。 总结
提示重要经验
1 2学好oracle即使经济寒冬整个测开offer绝对不是问题同时也是你考公网络警察的必经之路。 3笔试求AC可以不考虑空间复杂度但是面试既要考虑时间复杂度最优也要考虑空间复杂度最优。
