infobright

亿级数据,秒级响应,Smartbi究竟如何做到?

ぃ、小莉子 提交于 2021-02-09 11:57:34
关于 Smartbi,似乎有很多标签:真Excel、复杂报表、性能、自助分析、数据挖掘、NLP….其中,一个“性能”标签,江湖上就有很多的传说,例如应用于火星探测器飞行数据的分析,应用于某省的经济普查,应用于某银行的大规模数据挖掘等等。 数据处理的性能,对于一款 BI软件 来说,是最基本的要求。然而,恰恰最基本的要求,却最能体现产品的品质,使其在众多竞品中脱颖而出。 那么, Smartbi又是如何做到数据处理性能如此强悍呢? 一、 支持列式数据库 传统行式数据库的存储格式按照 ‘行’的方式把一行各个字段的数据存储在一起,一行行连续存储。对于把一行的数据写到数据库中,或者对一行数据中的某些字段进行修改,或者删除整行数据这些事务型的数据库操作来说,既直观也高效。 但是,在行式数据库上做 统计分析 的时候,这种存储格式效率并不高。例如:统计各地区的销售额和利润同比变化、统计各部门的业绩完成情况等等,都是在其中某些字段上的操作,但行式数据库却需要读取每一行的所有字段。在只分析销售额和利润的时候,把其它字段的数据如客户名称,签约时间,客户经理等等也统统都读了进来,浪费了大量资源。虽然通过 “索引”有一定的改善,但大量的索引所带来的存储空间浪费以及为维护这些索引所带来的时间浪费都会以指数级别增长。 图源:网络 列式数据库将同一个数据 “列”的各个值存放在一起,插入某一行数据时

Clickhouse 在58的实践之路

限于喜欢 提交于 2021-01-23 09:04:52
文章目录 1 Clickhouse简介 1.1 为什么选择Clickhouse 1.2 Clickhouse特性 2 Clickhouse建设 2.1 整体架构 2.1.1 数据接入层 2.1.2 数据存储层 2.1.3 数据服务层 2.1.4 数据应用层 3 Clickhouse运维管理平台 3.1 配置文件结构 3.2 元数据管理 3.3 自动化运维 3.4 监控与报警 4 Clickhouse应用 4.1 BI查询引擎 4.2 集群构建 4.3 问题及优化 5 实时数仓 5.1 分层架构 5.2 数据输入与输出 5.3 数据产品 6 常见问题 6.1 数据写入 6.2 JOIN操作 6.3 常用参数 7 总结与展望 在数据量日益增长的当下,传统数据库的查询性能已满足不了我们的业务需求。而Clickhouse在OLAP领域的快速崛起引起了我们的注意,于是我们引入Clickhouse并不断优化系统性能,提供高可用集群环境。本文主要讲述如何通过Clickhouse结合大数据生态来定制一套完善的数据分析方案、如何打造完备的运维管理平台以降低维护成本,并结合具体案例说明Clickhouse的实践过程。 Clickhouse简介 为什么选择Clickhouse 目前企业用户行为日志每天百亿量级,虽然经过数仓的分层以及数据汇总层通用维度指标的预计算

Infobright startup error: Fatal error:

心不动则不痛 提交于 2019-12-13 04:21:19
问题 This is the install log 11:30:18 11:30:18 Installing infobright 4.0.7-0 (i686) 11:30:18 The installer will generate /tmp/ib4.0.7-0-install.log install trace log. 11:30:18 [step: pre (4.0.7-0, 1=1)] 11:30:18 build type: static 11:30:23 [step: post (4.0.7-0), 1=1] 11:30:23 Install with RPM_INSTALL_PREFIX=/usr/local, current prefix=/usr/local/infobright, prefix_actual=/usr/local/infobright-4.0.7-i686 11:30:23 upgrade= 11:30:23 Config file /etc/my-ib.cnf created 11:30:23 sed -e 's+@BH_PORT@+5029+

Load data infile csv file in infobright

喜你入骨 提交于 2019-12-08 12:38:45
问题 I have a table ( created successfully in infobright). I m using windows system CREATE TABLE `file_records` ( `id` int(11) NOT NULL , `file_id` int(11) NULL, `file_url` varchar(255) NULL, `switch_id` int(11) NULL, `carrierid_supplier` int(11) NULL, `technical_profileid_supplier` int(11) NULL, `carrierid_customer` int(11) NULL, `technical_profileid_customer` int(11) NULL, `billing_increment_supplier` varchar(10) NULL, `billing_increment_customer` varchar(10) NULL, `billable_duration_supplier`

Time and date dimension in data warehouse

故事扮演 提交于 2019-12-03 05:06:48
问题 I'm building a data warehouse. Each fact has it's timestamp . I need to create reports by day, month, quarter but by hours too. Looking at the examples I see that dates tend to be saved in dimension tables. (source: etl-tools.info) But I think, that it makes no sense for time. The dimension table would grow and grow. On the other hand JOIN with date dimension table is more efficient than using date/time functions in SQL . What are your opinions/solutions ? (I'm using Infobright) 回答1: My guess

Time and date dimension in data warehouse

江枫思渺然 提交于 2019-12-02 18:21:57
I'm building a data warehouse. Each fact has it's timestamp . I need to create reports by day, month, quarter but by hours too. Looking at the examples I see that dates tend to be saved in dimension tables. (source: etl-tools.info ) But I think, that it makes no sense for time. The dimension table would grow and grow. On the other hand JOIN with date dimension table is more efficient than using date/time functions in SQL . What are your opinions/solutions ? (I'm using Infobright) My guess is that it depends on your reporting requirement. If you need need something like WHERE "Hour" = 10