数据计算-腾讯云开发者社区

开发者社区

文档建议反馈控制台

腾讯云架构师技术同盟

文章/答案/技术大牛

发布

数据计算

专栏成员

55

文章

5685

阅读量

13

订阅数

这可能是最轻量级的列存技术了

列式存储是提高数据分析计算性能的重要手段。如果数据表的总列数很多而计算涉及的列很少，采用列存就只读取需要的列即可，能够减少硬盘访问量，提高性能。而且，同一列数据往往是同一类型的，甚至有些情况取值都很接近，这样的一批数据连续存储，通常可以实施更高效的数据压缩。

2025-03-04

150

为 Lambda 语法增加序运算能力

SQL 延用了数学上的无序集合概念，遍历集合时也不关注次序。但计算机只能一步步地执行，循环时总会有个次序，充分利用这个次序就可以方便地表达更丰富的计算需求。

2025-01-21

410

Python 在企业级应用中的两大硬伤

关系数据库是最常见的数据存储方案，SQL自然也成为数据处理的第一选择。但随着企业级应用越来越复杂，使用SQL实现数据运算和处理也开始面临许多架构层面的严重问题。复杂的SQL（存储过程）很难移植、计算处理都压进数据库会造成数据库负担沉重而成为整个应用的瓶颈、被多应用共享的数据库容易导致应用间强耦合等等。所以，越来越多的现代应用开始采用其它技术来处理数据。

2025-01-16

830

从集合运算设计 Lambda 语法

拥有集合化特性的程序语言能让我们用很少的语句写出针对集合的复杂运算，其中处于核心地位的是 Lambda 语法设计得是否方便，直接决定了程序语言的描述效率。

2025-01-10

630

流计算需要框架吗？SPL 可能是更好的选择

高性能计算

流数据源通常是动态、无界的，看起来与静态、有限的批数据源区别较大，传统的数据库技术在架构上难以直接处理流数据源，只能让位于后来者。heron\samza\storm\spark\flink等计算框架最先完成突破，在流计算技术中占得先发优势。这些框架非常成功，以至于一说到流计算，应用程序员通常都会去转头寻找某种框架，而不宣称是某种框架的计算技术，则通常被认为不适合实现流计算。

2025-01-08

1000

TP 库太撑就上 AP 库吗？

clickhouse oracle

TP 太撑上 AP，这几乎是业界的通识，而且也有了多年的成功实践，这还有什么可讨论的吗？

2024-12-30

560

跑在文件系统上的数据仓库

数据仓库文件系统

我们知道数据仓库是晚于数据库出现的，当 TP 数据库无法满足日益增长的数据分析需要时，人们便通过架设单独的数据库把 AP 业务独立出来就形成了数据仓库（逻辑概念）。后续出现了专门的数据仓库产品为 AP 业务服务，由于数据仓库在技术上本身也是个数据库，因此继承了数据库的诸多特性，比如元数据和数据约束，这使得从 TP 数据库过渡到 AP 数据仓库较为平滑。

2024-12-23

640

WEB 上的计算引擎

Web 上的数据接口以 restful 和 WebService 为主，格式通常是多层的 Json 和 XML。多层数据可承载更通用更丰富的信息，但结构上比传统的二维数据复杂，计算难度也更大。可用于 Web 计算的工具或引擎表面上不少，但都有各自的缺点，JsonPath/XPath 等类库解析能力强，但计算能力不足；Python Pandas 计算能力较强，但难以被 Java 集成，而且数据对象 DataFrame 不是专为多层数据设计的，遇到复杂计算时代码也难写；Scala Spark 在集成性方面好一些，但架构沉重，学习难度也大。

2024-12-18

800

ORM 技术的终结者

Hibernate,Mybatis 以及新兴的 JOOQ 等 ORM 技术能够方便地将数据库表映射成 Java 对象，并提供自动读写能力。ORM 技术使得用 Java 开发数据库应用变得更为高效。

2024-12-13

600

万亿秒查是真地吗？比 ORACLE 快 N 倍是不是吹牛？

我们经常听到大数据产品宣传自己性能好，“万亿秒查”是个常见的说法，大概意思就是上万亿行数据中找出查出满足条件的数据，可以秒级返回。

2024-12-09

130

轻量级的大数据处理技术

大数据处理大数据

作为数据中心（中间部分）处于各种应用与数据源之间，对下对接多种数据源处理分析所有数据，对上要为各个应用提供数据服务，其重要性不言而喻。数据中心由于要处理的数据规模庞大、要响应的任务繁多，几乎都会采用大数据集群技术实现，这样才能满足庞大的业务需求，同时还可以横向扩容提升算力以满足不断增长的业务需要。

2024-12-05

1350

SQLite 的挑战者

很多小微型应用程序也需要一些数据处理和计算能力，如果集成一个数据库就显得太沉重了，这种情况下 SQLite 是一个不错的选择，它架构简单，集成方便，可持久化存储数据，并提供 SQL 实现计算能力。

2024-12-04

810

数据湖的不可能三角

提到数据湖就要先说一下数据仓库，数据仓库是集成多业务系统数据、面向主题的、专门用于数据查询分析的数据组织形式。当业务系统数据量不断增大、业务系统数量不断增多以后，数据仓库的出现就会成为必然。原始数据入仓时需要经过一系列清洗转换，以及深度组织才能满足业务的需要。因此数据仓库要解决的核心问题是：回答业务中已有的问题。这些问题必须事先定义好。

2024-12-03

880

分布式是大数据处理的万能药？

大数据处理分布式

使用分布式集群来处理大数据是当前的主流，将一个大任务拆分成多个子任务分布到多个节点进行处理通常能获得显著的性能提升。因此，只要发现处理能力不足就可以通过增加节点的方式进行扩容，这也是很多拥趸者最朴素的想法。以至于当我们接触一项新的大数据处理技术往往首先问的就是支不支持分布式以及能支持多大规模的集群，可见“分布式思维”已经根深蒂固。

2024-12-02

940

解放数据科学家的神器

数据科学家几乎都会用 SQL 做探索分析，SQL 看上去很简单，也有一定的交互性，做数据探索分析似乎很不错。

2024-11-29

820

为什么大数据平台会回归SQL

大数据平台主要是为了应对海量数据存储和分析的需求，海量数据存储的确不假，除了生产经营产生的结构化数据，还有大量音视频等非结构化数据，这部分数据很大，占用的空间也很多，有时大数据平台 80% 以上都存储着非结构化数据。不过，数据光存储还不行，只有利用起来才能产生价值，这就要进行分析了。

2024-11-28

630

三行五行的 SQL 只存在于教科书和培训班

教科书中 SQL 例句通常都很简单易懂，甚至可以当英语来读，这就给人造成 SQL 简单易学的印象。但实际上，这种三行五行的 SQL 只存在于教科书和培训班，我们在现实业务中写的 SQL 不会论行，而是以 K 计的，一条 SQL 几百行 N 层嵌套，写出 3K5K 是常事，这种 SQL，完全谈不上简单易学，对专业程序员都是恶梦。以 K 计本身倒不是大问题，需求真地复杂时，也只能写得长，Python/Java 代码可能会更长。但 SQL 的长和其它语言的长不一样，SQL 的长常常会意味着难写难懂，而且这个难写难懂和任务复杂度不成比例。除了一些最简单情况外，稍复杂些的任务，SQL 的难度就会陡增，对程序员的智商要求很高，所以经常用作应聘考题。

2024-11-27

590

云上真有无穷算力吗？

自从 Hadoop 兴起之后，业界好象就有了这么一种共识：不再关注单机的运算性能，全靠集群堆。大家都在比谁的集群能更大，至于单机能力是否被充分发挥了，那没人关心。Hadoop 体系的诸多技术都有这个特征，单机性能奇低，但并不妨碍 Hadoop 推广得遍地都是。

2024-11-26

610

数据库太慢跑崩的另一罪魁

没错，就是著名的 JOIN。 JOIN 一直是数据库计算的老大难问题，业界想了很多办法来计算它。如果不做任何优化，那就是两个关联表循环遍历，这是个乘法级的复杂度，数据量稍大一点就受不了。成熟的数据库当然不会这么傻，对于最常见的等值 JOIN（关联条件为键值相等），通常会采用 HASH JOIN 的办法，能将计算量下降 K 倍（K 是 HASH 空间长度，这里不赘述细节了，资料很多）。 HASH JOIN 算法用在内存上还好。对于数据量大到内存装不下的时候，很可能会涉及 HASH 分堆缓存，运气不好时还要二次 HASH，性能不可控。分布式就更麻烦，数据库界发明了 broadcast join 和 shuffle join 等办法换成单机 JOIN（这里也不赘述了），很麻烦，性能也会陡降，以至于会发生集群节点更多时反而速度更慢的现象。有些数据库为了图快，只实现了内存算法，这样数据量一大就崩掉也不奇怪了。

2024-11-25

710

数据库太慢跑崩的一大罪魁

就是非常不起眼的帐号去重计数，用 SQL 写就是 COUNT(DISTINCT …)。

2024-11-22

910

点击加载更多

社区活动

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·干货材料·成员作品最新动态