首页
学习
活动
专区
工具
TVP
发布

大数据引擎源码阅读

专栏成员
10
文章
52271
阅读量
29
订阅数
两个月30场面试--互联网大厂后端开发面试总结
今年业务调整,终于下定决心走出目前的环境,准备面试换工作。面试进行了2个月,一共30多场面试,最终拿到字节、小红书、蚂蚁、拼多多、SelectDB 5个offer。面试的过程有坎坷也有些感触,总结一下,希望能帮助到寒冬下也在找工作的小伙伴吧。
2011aad
2023-07-16
1.6K0
Spark离线导出Mysql数据优化之路
在业务离线数据分析场景下,往往需要将Mysql中的数据先导出到分布式存储中,如Hive、Iceburg。这个功能实现的方式有很多,但每种方式都会遇到一些问题(包括阿里开源的DataX)。本文就介绍下这个功能的优化之路,并最终给出一个笔者实现的终极方案。
2011aad
2022-05-24
2.7K2
Flink处理腾讯云数据订阅消息实践
在业务场景中,经常会有监听数据库数据变更的诉求,如数据同步、数据推送等场景。对于Mysql,可以监听其binlog日志,并输出到消息队列完成订阅,而腾讯云上有各种各样数据库,还有一些自研的数据库,都让用户来自研对接的方式显然成本太高,所以腾讯云推出了数据订阅任务,满足用户实时处理数据库数据变更的诉求。
2011aad
2022-04-19
2.6K0
Clickhouse Optimize Table全面解析
最近笔者在使用Clickhouse的过程中,用到了Optimize Table命令,而在业务开发过程中,由于不了解Optimize Table命令的明确行为,中间出了很多岔子,在查问题的过程中,也发现网上关于Optimize Table命令的介绍资料很少,因此笔者决定结合源码,全面解析下Optimize Table命令。
2011aad
2021-10-14
16.7K2
Global in在Clickhouse非分布式表查询中的使用
Clickhouse在OLAP查询场景下有显著的性能优势,但Clickhouse在大表join查询的场景下,性能表现并不是很好,因此在实际业务场景需要多表计算时,往往是通过in+子查询的方式代替join查询,以提升查询性能。
2011aad
2021-03-14
5K0
Druid源码阅读(二):Druid Segment存储格式
Druid流数据摄入后会以Index形式保存在内存中,同时会定期将Index序列化成Segment文件持久化到可靠存储中(如HDFS),批数据摄入会直接通过离线任务生成Segment存储,供服务加载使用。本节先对照Druid官方文档中对Segment的描述[1],介绍下Druid Segment,然后在下一节以一个测试Segment为例,并结合Druid源码,详细说明Druid是如何存储数据的。
2011aad
2020-05-10
3.4K0
Druid源码阅读(一):Druid Hadoop-based ingestion实现
Apache Druid是一款开源时序OLAP数据库,支持流数据摄入和批数据摄入两种数据写入方式,其中批数据摄入又包括Native batch和Hadoop-based两种方式。根据官方文档[1],Druid推荐使用Native batch方式摄入数据,因为这种方式更灵活,且没有对外部Hadoop集群的依赖。但Hadoop-based数据摄入也有其优势: 1. 生成Segment的离线计算过程可以使用Hadoop集群的计算资源,减少了druid集群的计算压力,做到计算和存储分离;2. 与大数据处理生态对接更方便,前期的数据预处理可以使用Spark、Flink等计算引擎,将处理结果放在某个HDFS目录下即可。
2011aad
2020-04-23
2.3K1
基于Spark的ID Mapping——Spark实现离线不相交集计算
最近在开发一个ID Mapping业务系统——识别数据上报中社交账号的关联关系,找到系统中哪些社交账号属于现实世界中的同一个人。简单来讲,如果同一条上报数据中出现了两个社交账号(比如一个手机号和一个QQ号),就认为这两个社交账号在现实世界属于同一个人。那么,如何计算这个关联关系呢?
2011aad
2020-04-08
4.2K0
Flink源码走读(一):Flink工程目录
导语 | Flink已经成为未来流计算趋势,目前在很多大厂已经有了大规模的使用。最近在学习Flink源码,就想把自己学习的过程分享出来,希望能帮助到志同道合的朋友。开始阅读源码,说明读者已经对flink的基本概念有一些了解,这里就不再重复介绍Flink了。本文作为学习过程的第一章,首先对Flink的工程目录做一个解读,了解了工程下各个模块的作用,才能在遇到问题时准确定位到代码,进一步学习。
2011aad
2020-02-14
8.6K1
Flink源码走读(二):Flink+Kafka实现端到端Exactly Once语义
Flink通过Checkpoint机制实现了消息对状态影响的Exactly Once语义,即每条消息只会影响Flink内部状态有且只有一次。但无法保证输出到Sink中的数据不重复。以图一所示为例,Flink APP收到Source中的A消息,将其转化为B消息输出到Sink,APP在处理完A1后做了一次Checkpoint,假设APP在处理到A4时发生错误重启,APP将会重新从A2开始消费并处理数据,就会导致B2和B3重复输出到Sink中两次。
2011aad
2020-02-14
5.2K0
没有更多了
社区活动
【纪录片】中国数据库前世今生
穿越半个世纪,探寻中国数据库50年的发展历程
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档