- 博客(59)
- 收藏
- 关注
RSS订阅原创 多维分析预汇总的方案探讨
我们在《多维分析预汇总的存储容量》中计算过，如果想做到 O(1) 的复杂度，至少要考虑界面用到的各种维度组合，这在维度总量稍多一点时就不可行了。这样，我们就只能放弃 O(1) 复杂度的期望了，不把每种可能出现的维度组合都预汇总出来，只能预汇总部分维度组合。在查询时，对于已经有预汇总的数据则可以直接返回，而如果碰到没有预汇总的维度组合时，则仍然从原始 CUBE 遍历聚合出来，这时的计算复杂度要么...
2019-03-13 15:39:32
473
原创 多维分析预汇总的功能盲区
在进一步讨论如何在有限空间内实现多维分析的预汇总之前，我们有必要再了解一下预汇总方案还有什么功能上的不足，也就是要搞清还有什么查询需求很可能无法通过预汇总数据获取。1. 非常规聚合预汇总方案是将测度聚合值先计算好并存储起来，那么，显然，在预汇总阶段没有想到的测度聚合值就无法直接从预总汇的数据中查询出来了。比如，如果我们只存储了销售额的合计值，而没有存储最大值，那就无法直接查询出来了。S...
2019-03-13 15:37:24
331
原创 多维分析预汇总的存储容量
多维分析一般是交互式操作的，也就要求有极高的响应速度，而多维分析涉及的数据量常常很大，几千万上亿行甚至更大都有，临时统计很可能跟不上界面的操作。为了保证性能，一些多维分析产品采用了预汇总方案，也就是把需要看到的统计结果事先计算好，这样计算复杂度就从 O(n) 变成 O(1)，在常数时间（秒级甚至毫秒级）内就可以返回结果，满足了交互分析的需求。我们都知道，预汇总的基本逻辑就是用空间换时间，将会额...
2019-03-13 15:36:45
419
原创 数据库的封闭性
我们知道，数据库的数据处理能力是封闭的。所谓封闭性，这里是指要被数据库计算和处理的数据，必须事先装入数据库之内，数据在数据库内部还是外部是很明确的。数据库一般有 OLTP 和 OLAP 两个用途。对于 OLTP 业务来讲，因为要保证数据的一致性，而一致性只有在一个确定的范围内谈论才有意义，这样就自然就会带来封闭性：数据库系统将保证也只负责数据库内部的数据的一致性。如果不关注 OLTP 业务...
2019-02-22 16:23:46
6418
转载 怎样让国产芯片性能超越 Intel
做一次标题党，其实我们做软件的当然没办法改变芯片的性能，也不可能真地让国产芯片超越 Intel。这个话题从去年做过的一次性能测试说起，先看测试结果：这些题目原本是某大用户在选型数据库时用于评测性能的。给定了数据（结构和规模）和 SQL，在同样的硬件环境下让各家数据库都跑一下，看谁的速度最快。我们从中选择了几个耗时最长的 SQL，再做了少量补充。然后准备了两组集群，一组用 Intel...
2019-02-22 16:22:52
525
转载 第 39 期：数据分段讨论
现代计算机一般都有多 CPU 核，而日益广泛应用的固态硬盘也有较强的并发能力，这些硬件资源都为并行计算提供了有力的保证。不过，要实现并行计算还需要有较好的数据分段技术，也就是能方便地把待计算的数据拆分成若干部分，让每个线程（或进程，这里以多线程为例讨论，多进程情况是类似的）分别处理。设计数据分段方案时，有这么几个目标：1. 每段的数据量基本相同并行任务的最终耗时是以那个最慢的线程为准的...
2018-12-19 18:01:46
436
转载 第 40 期：倍增分段技术
区块分段方案能够满足我们设定的 4 个目标。不过，除了处理区块标记的麻烦外，这个办法对于列存也不是非常适合。数据按列分别存储后，分段时必须保证各列同步，即各列的分段点对应的是同一条记录的列，否则就会出错数据错位。而各个列的宽度是不同的，同样大小的区块在存储不同列的值时，能装下的个数是不同的，继续按区块分段就无法保证同步了。各列要同步分段，就需要按记录数分段，但这样就不能采用固定大小的区块了...
2018-12-19 18:01:15
332
转载 第 41 期：文件的性能分析
我们以前讲过硬盘的性能特征，主要是针对硬件层面进行分析的，现在我们来考虑软件层面的差异。理论上讲，软件可以穿过操作系统直接进行磁盘扇区的访问，但实在太过于麻烦而几乎不会实践机会，这里就不考虑了，我们只讨论操作系统下的存储形式，而文件就是其中重要的存储形式。文件一般有两种：文本文件和二进制文件，我们分别来讨论。文本文件文本是很常见的数据存储形式，它具有通用性易读性等优点而被广泛使用。...
2018-12-19 18:00:32
248
转载 中国报表漫谈
这两年来雨后春笋般地冒出二三十家做报表工具的公司，统统号称能处理中国式报表，大概是这中国报表复杂得都世界闻名了，但凡能搞得定中国的报表，那也就没什么搞不定的报表了。弄到后来有好些所谓的报表只要能在格子里摆条斜线就敢说能对付中国报表（这也太小瞧祖国文化了），而且老外也开始扬言适合于中国报表了，这时髦，不赶怕是不行了。可话说回来，这中国的报表确实够复杂、巨费劲。用户拿出一撂纸往咱面前一堆：“就照这...
2018-12-19 17:56:29
652
1
转载 第 42 期：RDB 与 NoSQL 的访问性能 数据蒋堂
我们继续从软件角度上看外存数据源的性能，来考察数据库的性能特点，在这篇文章中，我们只关心数据的访问性能，而不涉及计算性能。关系数据库关系数据库也是很常见的数据存储方式。本质上讲，数据库其实也是一种特殊的二进制文件，但它的性能会弱于直接写在操作系统下的文件，主要原因在于数据库通常都要提供数据更新的能力，这就会产生影响性能的因素：1. 紧凑性与压缩手段数据库要考虑数据的更新，一般会采用...
2018-12-11 11:34:48
322
转载 第 43 期：报表开发的现状
报表开发，看起来只是数据呈现环节的事务，并不起眼，但仔细想想，它涉及的工作范围却非常广。如果把查询和交互分析也认为是报表事务的话（呈现形式本来也是报表），那么可以说，绝大多数 ETL 都是在为报表准备数据而存在的；而且，在数据库中的表，有相当多（经常超过半数）也不是用来存放原始数据，而是为了报表服务的。不过，有许多程序员对报表开发过程还有些理解误区。对此，我们用三句话来概括报表开发的现状：报...
2018-12-11 11:34:01
551
转载 应对报表没完没了的五个步骤
报表的业务稳定性天生很差，业务开展过程中会催生出许多新的查询统计需求，这就造成了没完没了的报表，这是个无法被消灭的任务，也是许多行业软件开发商非常头疼的事情。投入了很多人力，也引入了专业报表工具以及敏捷 BI 产品，却依然搞得灰头土脸，常常被客户抱怨。这是为什么呢？又该怎么解决呢？因为报表工具只能解决报表呈现环节的那部分工作，而报表开发过程中，占据工作量更大的部分是在数据准备的环节，这就不是报...
2018-12-05 19:41:38
402
转载 内存数据集产生的隐性成本
当我们要对数据做一些非常规的复杂运算时，通常要将数据装入内存。现在也有不少程序设计语言提供了内存数据集对象及基本的运算方法，可以较方便地实现这类运算。不过，如果对内存数据集的工作原理了解不够，就可能写出低效的代码。我们看数据集的产生。比如要生成一个 100 行 2 列的数据集，第一列 x 为序号，第二列 xx 是第一列的平方。第一种方法，先生成一个空数据集，再一行一行地追加数据进去。...
2018-12-05 19:40:27
468
转载 【数据蒋堂】第 44 期：谈谈临时性计算
临时性计算，顾名思义，是指临时发生的一些计算需求。这种计算在日常数据处理中很常见，我们举一些例子：应对业务部门的取数需求：比如销售部门想获得进行了某项促销活动前后的销售情况变化信息； 数据挖掘算法前的清理准备：将来自各个业务系统的数据（甚至一些企业外部的数据）整理成规则一致的二维表，这些动作常常比挖掘本身耗时还长得多； 有业务规则的测试数据生成：测试数据不能完全随机生成，必须满足一定的业务...
2018-11-29 16:00:28
761
转载 【数据蒋堂】第 45 期：大数据计算语法的 SQL 化
回归 SQL 是当前大数据计算语法的一个发展倾向。在 Hadoop 体系中，现在已经很少有人会自己从头来写 MapReduce 代码了，PIG Latin 也处于被淘汰的边缘，而 HIve 却始终坚挺；即使是 Spark 上，也在更多地使用 Spark SQL，而 Scala 反而少很多。其它一些新的大数据计算体系一般也将 SQL 作为首选的计算语法，经过几年时间的混战之后，现在 SQL 又逐步拿...
2018-11-29 15:56:31
261
转载 【数据蒋堂】第 46 期：大数据集群该不该透明化？
这好像是个多余的问题，大部分大数据平台都把集群透明化作为一个基本目标在努力实现。所谓集群透明化，是指把一个多台机器的集群模拟得像一个巨大的单机，只是系统管理层面知道体系是由很多单机集群而成，应用程序则应当尽量少地感受到集群的存在，在概念上可以把整个集群理解成一台机器，甚至在代码级都可能和单机运算兼容。透明化主要有两个方面。一方面是数据存储，提供统一的集群文件系统或者数据库系统，应用程序不需...
2018-11-29 15:55:55
395
1
转载 【数据蒋堂】第 47 期：Hadoop – 一把杀鸡用的牛刀
Hadoop 是个庞大的重型解决方案，它的设计目标本来就是大规模甚至超大规模的集群，面对的是上百甚至上千个节点，这样就会带来两个问题：1.自动化管理管任务分配机制：这样规模的集群，显然不大可能针对每个节点提供个性化的管理控制，否则工作量会大到累死人，必须采用自动化的管理和任务分配手段，而这并不是件简单的事情。2.强容错能力：大规模集群在某个任务执行周期内，也就是几小时之内，都有可能发生设备...
2018-11-29 15:55:11
191
转载 【数据蒋堂】第 48 期：Hadoop 中理论与工程的错位
Hadoop 是当前重要的大数据计算平台，它试图摒弃传统数据库的理念，重新构建一套新的大数据体系。但是，这并不是件很容易的事，在 Hadoop 的设计和实现中能看到一些先天不足的地方，其中一点就是把理论问题和工程问题给搞拧了。所谓理论方法，是指试图解决问题的一般情况，设计通用的算法能适应尽量多的情况，并努力使算法的复杂度降低。在研究问题时不会考虑具体环境下某个具体动作是否可以执行以及该动作消耗...
2018-11-29 15:54:25
173
转载 区块链技术的一些疑问
下面是我在学习了解区块链技术过程中产生的疑问，思考问题的过程中也会让自己对这项技术理解得更深刻。我不算初学者（知道区块链已有五年之久了），但一直也没有深入学习，不能算链圈的专业人士，所以可能孤陋寡闻，不能确认这些问题是不是已经被解决了，或者根本就是问得毫无意义，权当学习笔记。1. 区块链只适合执行低频高价的交易？单纯的链式结构未必会产生分叉，但考虑到去中心化和网络的不稳定性，分叉就是不可避...
2018-11-28 18:41:02
490
转载 存储和计算技术的选择
前一阵子公司有个售前来沟通某个用户的情况：数据量比较大，又涉及很多复杂的关联计算，在数据库中用 SQL 计算性能很差。本来这种场景是比较适合集算器的集文件（集算器特有的压缩二进制格式）存储并计算，但据说这个用户的历史数据还会经常变动，而集文件目前没有提供改写能力（为了保证压缩率和性能），也就不容易直接用。于是想推荐用户采用 nosql 产品做存储，集算器在上面做计算。赶快打住！如果用户真的听了...
2018-11-28 18:36:16
1283
转载 人工智能中的“人工”
自从 AlphaGo 赢了之后，人工智能就变得非常热门了。不过，大家在关注“智能”时，却很少把注意力放在“人工”上，似乎感觉上了人工智能之后，一切都能自动化了。其实，这份智能的背后有着大量的“人工”，还有相当多不能自动化的事情。这里的人工主要体现在两个方面：1. 数据准备现代的人工智能技术，或者说机器学习，其基本方法和 N 多年前的数据挖掘并没有什么太大的不同，也还是将大量数据喂给计算...
2018-11-28 18:32:01
605
转载 应对报表没完没了的五个步骤
报表的业务稳定性天生很差，业务开展过程中会催生出许多新的查询统计需求，这就造成了没完没了的报表，这是个无法被消灭的任务，也是许多行业软件开发商非常头疼的事情。投入了很多人力，也引入了专业报表工具以及敏捷 BI 产品，却依然搞得灰头土脸，常常被客户抱怨。这是为什么呢？又该怎么解决呢？因为报表工具只能解决报表呈现环节的那部分工作，而报表开发过程中，占据工作量更大的部分是在数据准备的环节，这就不是报...
2018-11-28 18:26:09
147
转载 “后半”有序的分组
上一期我们说了前半有序的数据，这次我们来看看“后半”有序的情况。回顾一下前半有序的说法：我们要把数据集 T 按字段 a,b 排序时，如果 T 已经对 a 有序，则可以利用这一特点实现高性能算法。但后半有序却不是对称地把问题理解成 T 已经对 b 有序时要对 a,b 排序的任务，这个“后半”序信息并没有多大利用价值。这里说的“后半”有序问题是指：如果 T 已经对 a,b 有序，现在我们要将 T ...
2018-11-28 18:12:42
128
转载 国产数据库通通都没戏！
这标题摆明了就是招人骂，一下子把国内做数据库的同行们都得罪了，甚至连自己都没落下（我也算做数据库的，而且当然也是国产的）。这观点已经有 N 年了，而且也多次讲过。这次正好有个热点来蹭，就把它写出来。既然蹭热点嘛，那就不怕标题党了。不过，还是要先澄清一下，这里说的“没戏”，并不是说国内厂商做不出一个可用的数据库来（事实上早已做到了），而是指做不到在市场上普及，击败国外产品，获得足够的市场占有...
2018-11-19 11:35:30
1918
2
转载 国产操作系统还能怎么做？
一家之言，开个脑洞。操作系统在市场上的关键点，并不在于进程管理、文件系统这些看起来很核心的东西，这些东西真地可以抄（借鉴一下没关系的）。操作系统要普及成功，关键在于上面开发技术的方便性，也就是开发工具的易用性以及 API 的丰富性。开发工具就是操作系统的用户界面，决定了用户体验；下层核心是为上层 API 服务的，也可以说是被 API 决定的，而不是倒过来。从这个意义上讲，Windows 的...
2018-11-19 11:34:55
211
转载 前半有序的大数据排序
最近碰到这么一个案例，情况可以简化总结成这样：数据库中有表 T，其中有两个重要的字段 a 和 b，a 是一个时间戳，精确到秒；b 是用户号；其它字段用来表示用户 b 在时刻 a 发生的事件属性。现在任务是：把数据按 a,b 排序导出。简单来讲，就是把 SELECT * FROM T ORDER BY a,b 的结果集写出到文件。但是，这个 T 表有几十亿条记录，这个 SQL 发出去之后，数...
2018-11-19 11:33:53
230
转载 做基础软件要投入很多钱？
现在有个说法，国家对基础软硬件的投入太少，经常会说微软、Oracle、Intel 这些巨头每年的研发费有多少多少，我们的投入连个零头都不到，当然做不出什么象样的东西了。看起来还真是，似乎还要再加大投入才行？我不懂芯片的事，不知道是不是需要花很多钱才能建出基本的实验生产环境，但软件的研发成本还是比较熟悉的。在我的意识中，国家在这方面投入的钱并不是太少了，已经足够多了。和国外巨头比研发费，...
2018-11-12 19:02:54
161
转载 做基础软件很悲壮？
这几天中国数据库界出了一件悲伤的事情，南大通用创始人崔维力先生突然因病去世。我和崔先生神交已久，但却未曾谋面，一直希望有机会当面沟通讨教，这一下就成永远的遗憾了。崔先生的英年早逝（60 多岁的年纪而已）又引发一个话题：做基础软件，特别是做国产基础软件，是个苦行僧的活。相比于应用软件，基础软件的技术含量高得多，熬得年头也长，累得死去活来，实际收益却很低。敢于做基础软件的，那都是悲壮之士。虽然...
2018-11-12 19:02:16
182
转载 如何将数据热导出到文件
随着时间推移，数据库中数据量会越来越大，如果把查询分析都挂到数据库上，有可能会影响到生产系统的正常运行。所以，一般都会将生产数据库中不再变动的数据定期移出到另一个分析数据库中，由分析数据库来承担查询分析的压力。不过，我们知道，文件系统比数据库有更好的 IO 性能，对于不再变动的历史数据，使用文件还可以采用更灵活的压缩技术。这样，如果我们把移出的数据存储到文件中，只要有好的计算引擎（比如集算器）...
2018-11-12 19:00:49
769
转载 大数据技术的 4 个 E
大数据的 4 个 V 说法在业界已经尽人皆知，这是指的大数据本身的特征。现在我们来考察一下用于处理大数据的技术应该具有的特性。为方便记忆，类似 4 个 V，我们把这些特性总结成 4 个 E，用户在选择大数据技术解决方案时可作为参考。1. Easy 大数据技术要足够简单易用这个 E 很容易理解。要进行大数据处理的场景很多，涉及工作人员也是各种各样的。如果技术的难度太大，那会导致只有少数人...
2018-11-05 17:09:38
331
转载 大清单报表应当怎么做？
在数据查询时，有时会碰到数据量很大的清单报表。用户输入的查询条件很宽泛，可能会从数据库中查出几百上千万行甚至过亿的记录。如果等着把这些记录全部检索出来再生成报表呈现，那需要很长时间，用户体验恶劣；而且报表一般采用内存运算机制，大多数情况下也装不下这么多数据。所以，我们一般都是使用分页呈现的方式，尽量快速地呈现出第一页，然后可以随意翻页显示，每次只显示一页，也不会造成内存溢出。那么，一般的报表工...
2018-11-05 17:08:56
247
转载 大清单报表的打印？
我们谈了大清单报表的呈现方法，其实有时候这些报表还需要打印，比如银行打印流水对账单。那么，打印是不是也要像呈现那样做一个缓存机制呢？没有这个必要。打印和浏览不同，一般是从头到尾过一遍就行了，过程中没有翻页的需求。这样，只要流式读入数据逐步生成打印页就可以了，不会发生内存溢出的问题。但这个做法仍然比较麻烦，特别是现代浏览器加强了安全控制，applet 等插件经常被禁用，打印功能常常不能直...
2018-11-05 17:08:11
170
转载 时序数据从分表到分库
这里的时序数据泛指一切随时间推移而不断增长的数据，比如通话记录、银行交易记录等。对于数据库来讲，时序数据并没有什么特殊性，可以和普通数据一样放在数据表中。不过，因为不断增长，积累时间较长后，这种数据的量常常都会很大。一个物理表的数据量太大时，就会影响查询和计算的性能。现代数据库一般都提供有表分区（PARTITION）的机制，就是把一个大表纵向（按行）分成若干区段，分区规则由数据库管理员来设...
2018-11-02 17:34:40
621
转载 最简单的大数据性能估算方法
大数据的性能是个永恒的话题。不过，在实际工作中我们发现，许多人都不知道如何进行最简单的性能估算，结果经常被大数据厂商忽悠:)。这个办法我在以往的文章中也提到过，不过没有以这个题目明确地点出来。其实很简单，就是算一下这些数据从硬盘上取出来用的时间。除了个别按索引取数的运算外，绝大多数运算都会涉及对数据的整体遍历，比如分组汇总统计、按条件查询（非索引字段）；那么，这些运算耗用的时间，无论如何不...
2018-11-02 17:33:11
2015
转载 这个产品能支持多大数据量？
经常有用户会问这个问题，你家的产品能处理多大数据量？似乎是这个值越大产品就越牛。这个问题，其实没多大意义。能处理多大的数据量，还有个很关键的因素是期望的响应时间，在脱离这个因素单纯谈大数据产品的数据处理量，就不知道怎么回答了。考虑只有单台机器的简单情况。如果是希望秒级响应的 OLAP 式汇总，那么 GB 级都是挺大的数据了，几乎不可能有什么产品能处理 TB 级数据（除非有巨大内存）。而...
2018-11-02 17:32:28
302
转载 BI 系统中容易被忽视的数据源功能
用户在选购 BI 解决方案的时候，常常会更关注界面环节的功能指标，比如美观性、操作的流畅性、移动端支持等等。毕竟，BI 是要给业务人员使用的，这些看得见的内容一般不容易被遗漏。然而，有些与数据源有关的后台功能点就可能被忽略掉。如果在项目实施时才发现就会非常麻烦，可能造成上线延迟，或者有些功能只能绕路而行。在选购 BI 系统时反而要特别注意这些功能点。1. 对大清单报表的支持OLAP 分...
2018-10-29 15:01:09
483
转载 BI 系统的前置计算
某机构上了一套分布式数据仓库，历史数据逐步装进了仓库，然后，基于数据仓库构建了 BI 系统（主要是多维分析）。刚开始，一切都顺利，但随着时间推移，基于中央数据仓库的应用越来越多，几年下来积累了数十个应用。这些应用都需要依赖数据仓库计算，导致中央数据仓库的负担越来越重，BI 系统的响应开始变得迟钝起来。对于交互性很强的多维分析业务来讲，这是很难容忍的。咋办呢？扩容？这已经是个分布式系统了，节点...
2018-10-29 14:58:21
187
转载 用 HBase 做高性能键值查询？
最近碰到几家用户在使用 HBase 或者试图使用 HBase 来做高性能查询，场景也比较类似，就是从几十亿甚至上百亿记录中按键值找出相关记录来。按说，这种 key-value 式的数据库很适合用键值查询，HBase 看起来就是个不错的选择。然而，已经实施过的用户却反映：效果非常差！其实，这是预料之中的结果，因为 HBase 根本不适合做这件事！从实现原理上看，key-value 式的数...
2018-10-22 17:30:11
670
转载 一些数据压缩手段
我们知道，外存（硬盘）的性能远远低于内存，即使是同样复杂度的运算（CPU 计算量相同），如果能减少外存的访问量，也会大大提高整体性能。甚至有时我们需要用 CPU 换硬盘，即宁可多消耗些 CPU 时也要减少硬盘访问量，一方面 CPU 性能更好，另一方面是 CPU 比硬盘更容易并行，现代计算机的 CPU 核数常常远远超过硬盘的并发访问能力，数据密集型的任务应当更多地使用 CPU 的能力。如果能物理...
2018-10-22 17:29:29
1908
转载 性能优化是个手艺活
大数据的技术本质就是高性能，性能优化也是程序员们的永恒话题。这里说的性能优化，主要是指在程序员的努力下能达到某种性能提升效果的过程。只要简单换台机器就能加速的事情，业主方要么早就做过了，要么就是条件不允许这么做。这时候，优化方案的关键在于算法，具体来讲，就是要设计出低复杂度的计算方案。我们说过多次，软件不可能提高硬件的性能，只有采用了低复杂度的算法，也就是计算规模有了实质性的下降时，才可能...
2018-10-18 18:38:01
249
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人