星环大数据技术
文章平均质量分 91
星环科技TDH社区版
星环科技社区版家族基于商业版强大的技术底座打造,目前免费提供了多个极具竞争力的核心子产品及开发管理套件,致力于让广大开发爱好者快速享受到大数据技术所带来的技术红利,提供了一个更轻量、更简单、更易用的数据分析开发环境。
展开
-
预告预告-首款3A巨作《黑神话悟空》攻略集大放送,开发版图数据库StellarDB构建通关指南
在最后一个地点也就是黑风洞的黑风洞_见谛峰土地庙可以跟最终boss黑熊精战斗,在此之前已经通过与各路妖王包括隐藏妖王战斗解锁各类技能及物品,比如避火罩、聚形散气,增加了闪避、定身等技能的能力,最终击败黑熊精。天命人至此,获得大圣化身的灵器,名曰喜看眼,得到了六大根器中的一个,除了这个之外打败黑熊精还能获得材料烈火金乌、精石、玲珑内丹等。等众多优势,充分降低了用户的安装以及资源门槛,只需有docker环境,执行3个命令(解压,加载镜像,启动)就可以一键启动完成。接下来就可以开启第二篇章:风起黄昏。原创 2024-09-09 19:35:14 · 394 阅读 · 0 评论 -
开源产品GeoMesa、MobilityDB存在哪些不足
支持大规模矢量数据、遥感影像数据、数字高程数据、时空轨迹数据的存储与计算,具有完备的数据查询、分析和挖掘能力,可用于时空查询分析、时空模式挖掘、时空轨迹聚类等时空轨迹数据分析场景,广泛应用于交通物流、城市管理、位置服务等场景。传感器网络、移动互联网、射频识别、全球定位系统等设备时刻输出时间和空间数据,数据量增长非常迅速,这对存储和管理时空数据带来了挑战,传统数据库很难应对时空数据。GeoMesa仅支持对矢量数据的存储,不支持对多维时空轨迹数据、栅格数据、瓦片数据的存储。原创 2024-08-28 16:50:32 · 965 阅读 · 0 评论 -
当出现数据倾斜时如何应对---倾斜key单独处理/MapJoin/星环SkewJoin的原理及使用方法
本篇文章为本系列最终篇,将为您介绍在计算过程中出现数据倾斜的问题时应该如何处理应对,不同手段的使用方式,如果您还有其他想了解的可以多多留言反馈,后续进行补充描述。但是MapJoin只适用于大表小表Join的情况,因为MapJoin会将指定表的数据全部加载在内存,表在被加载到内存后,数据大小会急剧膨胀,因此指定的表只能是小表。如上述样例,计算引擎会对表 jt_1 中,所有 id=1,name='qwh' 以及 id=2,name='ly' 的所有列做均匀处理,避免倾斜。原创 2024-06-26 13:45:00 · 2242 阅读 · 0 评论 -
星环科技计算引擎针对数据倾斜现象的引擎保护机制
上一篇文章从原理开始为读者介绍了为什么会出现数据倾斜现象,它的诱因是什么,以及星环针对数据倾斜问题的诱因做的一些技术改造及创新。本篇文章将续上节继续为读者介绍下星环在不同的倾斜诱发阶段下的引擎保护机制,如何避免最终内存溢出以及集群崩坏的风险。星环的保护机制为了防止因为数据倾斜导致executor不稳定甚至故障,影响系统的稳定运行,星环科技针对倾斜场景在task中增加了一些安全保护参数,当到达参数上限后,我们将判定存在数据倾斜,为了保护计算引擎,任务将中断并返回一些报错提醒。shuffle write阶段。原创 2024-06-26 09:00:00 · 878 阅读 · 0 评论 -
分布式计算框架系列文章(二)数据倾斜现象诱因、原理、影响,以及星环对此的应对策略
如果文件数量特别巨大,对文件读写的性能会带来比较大的影响,此外由于同时打开的文件句柄数量众多,序列化,以及压缩等操作需要分配的临时内存空间也可能会迅速膨胀到无法接受的地步,对内存的使用和GC带来很大的压力,在Executor内存比较小的情况下尤为突出,例如Spark on Yarn模式。当涉及到多个数据表时,JOIN是SQL中最常用的操作之一。JOIN的作用是将多个数据表中的数据组合在一起,从而使用户可以根据不同的条件组合过滤和查询多个表中的数据,最终提取记录形成一个新的结果集,实现数据关联和查询分析。原创 2024-06-25 02:30:00 · 1362 阅读 · 0 评论 -
分布式计算框架系列文章(一)MapReduce计算框架工作流程详解以及框架限制
后续Spark基于MR框架做了进一步的优化,解决了MapReduce计算框架的不足,基于内存和DAG的计算模式有效的减少了数据shuffle落磁盘的IO和子过程数量,实现了性能的数量级上的提升。在容错性方面,由于MapReduce的分布式架构设计,在设计之初即设定了硬件故障的常态性,因此其计算模型设计了大量的容错逻辑,如任务心跳、重试、故障检测、重分布、任务黑/灰名单、磁盘故障处理等机制,覆盖了从JobTracker、TaskTracker到Job、Task和Record级别的从大到小各个层级的故障处理。原创 2024-06-24 16:45:29 · 965 阅读 · 0 评论 -
【性能优化】表分桶实践最佳案例
分桶在生产实践中一直占据着十分重要的角色,如果分桶策略不当可能会引发各种问题,如小文件问题,数据倾斜问题等。因此本篇文章将为读者介绍如何分桶,何时分桶,并提供了一个最佳实践案例辅助读者更深刻的了解分桶策略。原创 2024-06-22 02:30:00 · 895 阅读 · 0 评论 -
【0-1系列】从0-1快速了解搜索引擎Scope以及如何快速安装使用(下)
近期,星环社区版家族发布了单机即可一键部署、开箱即用的开发版Scope,本篇文章将介绍如何安装部署使用星环自研的搜索引擎Scope,以及提供使用示例原创 2024-06-20 11:27:50 · 592 阅读 · 0 评论 -
【0-1系列】从0-1快速了解搜索引擎是什么以及怎么用(上)
近日,社区版家族社区开发版系列重磅发布搜索引擎Scope开发版以及图数据库StellarDB开发版。 为了可以让大家更进一步了解产品,本系列文章将从搜索引擎的背景概念开始介绍,深入浅出的为读者介绍Scope的优势以及能力,在最后一个章节也将为大家提供使用示例辅助读者上手体验。原创 2024-06-20 11:15:17 · 1434 阅读 · 2 评论 -
搜索引擎数据库介绍
本篇文章主要介绍了搜索引擎数据库的基础背景及知识。原创 2024-06-20 11:10:25 · 1085 阅读 · 0 评论 -
不同表格式下的小文件治理方式(开源RC file/ORC/Text非事务表、事务表、Holodesk表格式..)
本篇文章将为读者介绍不同表格式如何处理小文件合并相关问题,涉及非事务表、事务表以及星环自研的高性能Holodesk表。原创 2024-06-19 11:35:09 · 1388 阅读 · 0 评论 -
小文件过多的解决方法(不同阶段下的治理手段,SQL端、存储端以及计算端)
在生产上小文件一直以来都是很棘手的问题,从上游到下游的各个步骤都有可能产生小文件问题,虽然技术上星环针对此类问题做了很多处理机制。本篇文章介绍了不同阶段下的小文件问题如何处理。原创 2024-06-18 17:52:56 · 888 阅读 · 0 评论 -
小文件治理系列之为什么会出现小文件问题,小文件过多问题的危害以及不同阶段下的小文件治理最佳解决手段
大数据场景下会产生海量文件,其中,小文件会对系统造成一系列影响。在实际业务中,小文件现象出现频率并不低,客户现场开发环境和或生产环境多或少都会遇到小文件问题,这些问题或来自上游系统,亦可能是因为表的分区分桶不合理,也可能是来自于不规范的sql等等。当小文件过多时,将会导致内存占用高、集群不稳定,增加计算资源的开支等一系列问题。因此小文件治理是必要的也是迫切的。原创 2024-05-07 15:58:58 · 1056 阅读 · 1 评论 -
Raft协议详解--背景+概念介绍+算法剖析
Raft提供了一种在计算系统集群中分布多个状态机的通用方法,可以确保集群中的每个节点都同意相同的一系列状态变更,同时其采用了更强的领导形式。比如日志条目仅会从leader节点流向其他节点,如果客户端与其他节点建立通信,那么其他节点将会将其重定向给leader,简化了日志复制等操作的管理。原创 2024-02-02 15:50:38 · 4371 阅读 · 0 评论 -
星环分布式一致性技术是如何实现的?什么是分布式一致性协议?作用是什么?
举个比较有意思的例子,我们都知道在参与多人战斗的游戏时,当出现需要团体进攻时,大家的目标需要是一致的,比如是选择优先攻击输出还是先攻击血量低的,如果对方开团了,大家在没有优势的情况下是先撤退还是直接发起进攻?如果大家最开始的目标是一致的,比如如果开始开团就选择优先攻击输出。但是中途突然有个玩家玩着玩着摆烂不想玩了,跟其他几个人说要撤退或者自己跑去送人头了,有的玩家没听他的还是发起攻击,有的玩家蒙圈了也停止攻击了,那这种情况下就出现了决策不一致的情况,最终结果一定会跟预期结果出现偏差,导致整个团队的失败。原创 2023-12-19 11:11:39 · 901 阅读 · 1 评论 -
Raft in TDDMS--在星环分布式系统底层存储中Raft承担的作用以及能力
相比于3副本来说,5副本有更好的数据容错性。如图所示,对于写请求,客户端首先从master处获取要写的表的元信息(主要包含各个分片的元信息),接着客户端根据分片元信息,将写请求发送至对应的tablet server,在tablet server管理的数据分片上先写leader,leader收到客户端发送的写请求,经过 raft 算法在副本之间达成共识同步至follower(具体详见前述章节的介绍),写入日志之后各副本尝试应用写请求,满足leader+follower的1/2以上写完即可回复客户端写成功。原创 2024-02-04 10:36:13 · 1405 阅读 · 1 评论