标签筛选

博客

一次openLooKeng的Pipeline之旅:上游算子处理能力加快会使得下游算子也加快么?

廖登宏

| April 29, 2022 |

openLooKeng 算子下推

1 背景 在大数据处理的软件中,如openLooKeng或presto,数据处理往往是以pipeline的方式,通过将data在不同的Operator之间流转,从而实现对数据的处理。 以处理以下sql为例:select sum(ss_sales_price), sum(ss_list_price) from store_sales_partition_1 where ss_sold_date_sk > 0 group by ss_hdemo_sk; 以上sql会形成三个stage,在读数据的source stage主要包含Scan、Agg(partial)、FilterAndProject、PartitionOutput四个算子,数据处理的大部分时间都在这个stage(因为partial agg后,数据量大大减少),一种典型的pipeline如下: 2 问题 那么在pipeline的模式下,TableScanOperator的处理速度加快后,是否其他算子的处理速度也会加快呢? 为了验证这个猜想,我们构造了以下两种场景: 正常的table scan,读取ORC文件; 使用ORC Cache,将读取后生成的block缓存在内存中,下次读取无需读取原始文件。 以下为测试数据: «test result.xlsx» 3 结论 结论:从以上数据可知,通过ORC Cache后,Scan的CPU时间减少了约一半,E2E的时间也因为Scan算子的减少而相应减少,但是其他算子的处理速度却不会因此而提升。 理论分析:A算子从上游算子获取的数据是一定的,无论上游算子是在1s内还是10s内给算子A,那么算子A执行addinput和getoutput进行数据处理的时间就是一定的,因为假设10s某些时间上游算子没有喂给A数据,那么A是不参与运算的,即既不记录CPU时间也不计wall time。 以下为scan和agg处理速度的截图,从图中直观看到scan处理速度加快,而下游的hashagg几乎没有变化: 几个发散的思考 ORC cache 开启hetu.split-cache-map.enabled=true后并执行cache table,那么table cache后的split会cache,会使用cache的split调度策略,而非默认的调度策略,此时会突破node-scheduler.max-splits-per-node的限制,这看起来更像是个bug。 hive.orc.row-data.block.cache.enabled开启后,split和row data都会cache,且cache的data是解压后的block,同时filetail、footer等元数据信息没有开启,因此仍然会去读元数据信息,但是感觉已经没有必要了,因为读这些信息并不能过滤数据,仍然会使用cache的数据?—-这是一个bug? 调度影响 当node-scheduler.max-splits-per-node使用默认值100时,由于单节点处理的数据量很小,因而queued和running的split最大为100,需要分多批次调度,而hetu.split-cache-map.enabled=true后queue和running的splits无限大,为何分批次调度的影响这么大,值得进一步分析。 文件系统Cache row data cache后减少的这一半时间主要是ORC读取上来后的解压缩时间,因为实际数据已经缓存在文件系统cache中,因而数据从内核态拷贝到用户态是很快的。 在最早的分析中,我们发现算子级别的wall和cpu time一样,而端到端时间差异几倍,怀疑是IO wait,但是实际上通过IOstat等命令看,没有io wait,甚至没有io读写,发现是因为文件只有700M,基本全缓存到文件系统cache了,从而进一步理解了文件系统cache。 同时我们怀疑是否有异步线程的时间没有统计到driver的process中,实际上也没有这种情况发生,因为哪怕是异步线程处理,那么在cpu图上一定能看到痕迹。 通过以下两篇文章,能较好的了解异步IO: [译] Linux 异步 I/O 框架 io_uring:基本原理、程序示例与性能压测(2020) 来自 https://arthurchiao.

更多...

动态过滤测试报告

支海东

| April 27, 2022 |

openLooKeng 动态过滤

1 概述 Join在SQL语言中,是数据库查询永远绕不开的话题,也是SQL中最为复杂,代价最大的操作类型。而在hash join中,如何使构建端(build –side)和探测端(probe-scan)高效运行,便成为了需要研究的问题。动态过滤(Dynamic Filtering)就是为了解决这个问题而应运而生的机制。在openLooKeng中,我们广泛地采用了这种机制。 1.1 背景 SQL语言中join大致有几种执行机制。最简单的是Nested-Loop join和Blocked Nested-Loop join。假设现在有两张表R和S, Nested-Loop join会用二重循环的方式扫描每个(r,s)对,若符合join的条件,就匹配成功,其时间复杂度也很简单地可推导为O(|R||S|)。而Blocked Nested-Loop join是基于前者的改进版,其思路是对于外层循环的表R,不再逐行扫描,而是一次加载一批(即所谓Block)数据进入内存,并且将它们按join key散列在哈希表里,然后也按批扫描表S,并与哈希表进行比对,能够对的上的行就作为join的输出。一个block数据的大小一般是一个或多个内存页的容量。这样就可以将I/O复杂度从O(|R||S|)降低到O[p(R) * p(S) / M],其中p(R)、p(S)分别代表R和S换算成页数的大小,M代表可用内存中的总页数。 此二种loop join的原理图如下所示: 除此以外,主要是Hash join和Grace Hash join。Sort-Merge join由于和动态过滤并不相关,本文在此不予以讨论。Hash join分为两个阶段,构建(build)和探测(probe)。我们将join两端中较小的那个集合R作为构建集(build set),另一个S作为探测集(probe set)。在构建阶段,我们将R的所有数据按照主键进行哈希散列,构成一张哈希表,而哈希表的值便是R原来的行数据。而在探测阶段,我们扫描探测集S,取得S的主键的哈希值并判断其是否在哈希表之中,输出结果。此二阶段的过程的示意图如下所示。易知,其时间复杂度为O(|R|+|S|)。 而Grace Hash join的原理,只是改进版,并不影响我们对于动态过滤机制的理解,因而在此处略去不表。 1.2 原理 上文中已经介绍了join本身的原理,接下来我们介绍动态过滤。 在筛选机制比较苛刻的场景中,绝大多数探测端的行是一经筛选,不匹配则直接丢弃的。但如果我们将这个谓词从计划阶段下沉到执行阶段,在构建端已经有严格筛选条件的情况下,直接减少构建集的计算,从而不去读取探测端那些不匹配的行而不是先读取再丢弃,就节约了大量的筛选时间,极大地提高了运行效率。而这个过程,就叫做动态过滤。 如上图所示,item作为一个已经被严格筛选过的构建集,我们用过滤器F将筛选机制直接传递给探测集。如此,探测端的工作效率便会提升。而动态过滤机制的主要难点就在于如何把构建端的值从inner-join操作符传递到探测端,因为操作符很可能是在不同的机器上运行的。 而在实施的时候,我们主要依靠“基于代价的优化器”(CBO, cost-based optimizer),这个优化器让我们可以使用“广播合并”(broadcast join)。在我们的案例中,构建端远小于探测端,探测端的扫描和inner-join操作符运行在同一进程中,这样信息的通信机制会容易很多。 在确保了广播合并被使用且构建端的信息也能被传送到探测端的时候,我们加入“收集操作符”(collection operator),就放在哈希构建操作符之前。 如图,收集操作符收集了构建端的值,而当构建端的值输入完毕后,我们将动态过滤机制放到探测端一边。由于探测端的哈希映射和收集操作符的哈希映射是并行执行的,这里并不需要花费多余的时间。然后哈希匹配的时候,探测端就可以直接去被筛选过后的构建端的哈希表进行查找。 2 测试 为了审视动态机制开启后的具体效果,我们进行一个测试:对同样的几个节点在先不开启后开启动态过滤机制的状态下,测试同样的几段SQL代码在相同节点上的运行时间。最终通过运行时间的变化体现执行效率的变化。值得一提的是,工作节点(worker nodes)的数量尽可能要大于1个。 2.1 环境配置 https://openlookeng.io/zh-cn/docs/docs/installation/deployment.html https://openlookeng.io/zh-cn/docs/docs/installation/deployment-ha.html https://openlookeng.io/zh-cn/docs/docs/admin/dynamic-filters.html 以上3个网页已经详细讲述了如何配置协调节点(Coordinator Node)和工作节点(Worker Node),以及是否开启动态过滤机制。需要注意的是,等待动态过滤条件生成的最长等待时间最好加上,并且设置为2s,即在etc/config.properties里加入语句 Dynamic-filtering-wait-time=2s 否则有些SQL语句可能会出现由于等待时间不合适而并未开启动态过滤机制的情况。 2.2 测试结果 在看具体数字前,我们首先看看计算图的变化。 这两张图分别是动态过滤机制开启前后,在同样的节点上运行同样的程序的计算图。可见,就像原理部分中所叙述的那样,计算图中出现了动态过滤机制,右图中标红的SQL语句就是体现。 最后,这张表是6段不同的代码在动态过滤机制开启前后的运行效率对比。 如果您有任何疑问或建议,欢迎在社区代码仓内提Issue;也欢迎加小助手微信(openLooKengoss),进入专属技术交流群。 社区代码仓

更多...

CTE测试报告

支海东

| April 26, 2022 |

openLooKeng CTE

1 概述 CTE(Common Table Expression) Reuse是一种能够专门存放临时查询结果,从而减小反复查询带来的硬件开销的机制。在openLooKeng中,我们为了提高数据库整体的运行效率,广泛地采用了这种机制。 1.1 背景 在编写SQL语句时,很多时候,我们想选取一段数据,为了之后使用的便捷性,会为其取名。形如WITH … AS (SELECT … FROM …)。 例如,在如下程序(这段代码即是Q95.sql)中,我们在程序刚开始的时候就声明了“ws_wh”的具体内容,并在声明后3次用到了这部分数据,如图所示。 然而,SQL中用WITH … AS …所声明的SQL表达式并不是C/C++/java/python中所声明的变量。后者在每次被使用的时候可以直接调用,但前者即便被声明了,在之后被使用的时候仍然需要重新用具体的语句去选取并计算相应的数据。这就消耗了极大的机器资源。至此,我们便很容易思考一个问题,能否将被声明的SQL表达式存储在一个“表格”中以避免反复查询和生成,从而极大地节约运算资源,提高运算效率? 1.2 原理 CTE机制就是为了解决上述问题,应运而生的。当第一次声明某个SQL表达式作为临时表时,我们将该SQL表达式从硬盘读取、计算并储存至缓存,此时这张表被称为“生产者”(producer);而当这张表被反复从缓存中读取以便使用时,我们称其为“消费者”(consumer)。由于消费者是被储存在缓存中的,我们不需要反复生成“生产者”。而从缓存读取数据又比从硬盘读取要快,且不需要二次计算,这样同一段SQL代码,在有了CTE机制后,执行速度会大大提高。比如,下图中,若不开起CTE机制,同一个SQL表达式在声明后仍需要被反复生成。但开启了CTE机制,从计算流程图上,我们都能很轻易地看出流程被大大简化。 用户执行一段启动了CTE机制的SQL代码的流程图如下图所示。首先解析是否存在相似的子查询,若存在,则将其查询结果储存在外部的缓存中以便之后使用。 2 测试 为了审视CTE机制开启后的具体效果,我们进行一个测试:对同样的几个节点在先不开启后开启CTE机制的状态下,测试同样的几段SQL代码在相同节点上的运行时间。最终通过运行时间的变化体现执行效率的变化。 2.1 环境配置 https://openlookeng.io/zh-cn/docs/docs/installation/deployment.html https://openlookeng.io/zh-cn/docs/docs/installation/deployment-ha.html https://openlookeng.io/zh-cn/docs/docs/admin/state-store.html 以上3个网页已经详细讲述了如何配置协调节点(Coordinator Node)和工作节点(Worker Node),而是否开启CTE机制,取决于是否在/etc/config.properties这个文件中加入语句: optimizer.cte-reuse-enabled=true 2.2 测试结果 在看具体数字前,我们首先看看计算图的变化。 这两张图分别是CTE机制开启前后,在同样的节点上运行同样的程序(Q95.sql)的计算图。可见,就像原理部分中所叙述的那样,计算图本身已经被简化。左图中标红的两段SQL语句,在右图中,已经被CTE Reuse机制“融合”成了一个部分,精简了计算流程。 最后,这张表是5段不同的代码在CTE机制开启前后的运行效率对比。 不开CTE运行时间(s) 开启CTE运行时间(s) 如果您有任何疑问或建议,欢迎在社区代码仓内提Issue;也欢迎加小助手微信(openLooKengoss),进入专属技术交流群。 社区代码仓 https://gitee.com/openlookeng https://github.com/openlookeng openLooKeng,让大数据更简单!

更多...

openLooKeng+Ranger:使用指南

马晓琦

| April 8, 2022 |

Ranger

一 openLooKeng 编译和部署 代码路径:https://gitee.com/openlookeng/hetu-core,下面以master分支为例。 (master、1.0.1分支,ranger插件使用均测试通过) 1. 代码编译 git clone https://gitee.com/openlookeng/hetu-core.git # 进入代码根目录 cd hetu-core mvn clean compile package install -DskipTests ls hetu-service/target/ # target 目录下生成hetu-server-1.0.0-SNAPSHOT.tar.gz安装包 2. 部署openLooKeng 使用上面编译得到的hetu-service/target/hetu-server-1.0.0-SNAPSHOT.tar.gz安装包进行安装部署,openLooKeng的安装部署可参考官网教程:https://openlookeng.io/zh-cn/docs/docs/installation/deployment.html。 3. 添加数据源 在openLooKeng的catalog目录项,新增数据源配置文件。具体数据源有哪些配置项可以参考官网的连接器章节:https://openlookeng.io/zh-cn/docs/docs/installation/deployment.html 1)新增MySql数据源 Mysql连接器配置文件: 新建测试数据库:create database db_test;插入数据: use db_test; CREATE TABLE table_test (id int(10),name char(20),column_test varchar(20), date_test DATETIME); INSERT INTO table_test (id,name,column_test,date_test) VALUES(01,'Tom','11AAGada110110','2011-11-11 11:11:33'); INSERT INTO table_test (id,name,column_test,date_test) VALUES(02,'Jack','119asf19119','2012-11-12 11:22:33'); INSERT INTO table_test (id,name,column_test,date_test) VALUES(03,'Rose','112Gfaf112112','2013-11-13 11:33:33'); INSERT INTO table_test (id,name,column_test,date_test) VALUES(04,'Adam','1111kkk1HG11','2014-11-14 11:44:33'); INSERT INTO table_test (id,name,column_test,date_test) VALUES(05,'Haya','222afaf222222','2015-11-15 11:55:33'); 查看新建的表数据:select * from table_test;

更多...

postgreSQL和openGauss的connector支持update/delete的实现

熊鹰飞

| March 21, 2022 |

Update/Delete postgreSql openGauss

1 相关背景 1.1 需求 当前openLooKeng postgreSQL connector不支持对数据表的update和delete操作,同时,openGauss和postgreSql同源,因此本文拟在openLooKeng框架的基础上,开发postgreSql/openGauss connector支 持update/delete操作的代码。 1.2 openLooKeng语句执行流程 一条SQL语句的执行的整体流程如下图所示: 这里面主要涉及到两种类型的节点,分别为Coordinator和Worker节点。 Coordinator 节点是用来解析语句,执行计划分析和管理 openLooKeng 的 Worker 节点,同时Coordinator 跟踪每个 Work 的活动情况并协调查询语句的执行。Coordinator 为每个查询建立模型,模型包含多个Stage,每个Stage再转为Task 分发到不同的 Worker 上执行。 Worker 是负责执行任务和处理数据。Worker 从 Connector 获取数据。Worker 之间会交换中间数据。Coordinator 是负责从 Worker 获取结果并返回最终结果给 Client。 具体步骤为: 客户端通过协议发送一条查询语句给openLooKeng集群的Coordinator; Coordinator接手到客户端传送到的查询语句,对语句进行解析、生成查询执行计划,根据查询执行计划一次生成sqlQueryExecution->sqlStageExecution->HttpRemoteTask; Coordinator将每个task分发到所需要处理的数据所在的Worker节点上执行; Task通过Connector从数据源中读取数据,并执行Source Stage的task; 处于下游的Stage中的task会读取上游Stage产生的输出结果,并在该Stage的每个task所处的Worker的内存中进行后续处理; Coordinator从发布的task后,持续地从Singe Stage中的task获取结果,并将结果缓存到buffer中,知道查询结束; Client从提交查询之后,会持续地从Coordinator获取本次查询的计算结果,知道获得所有的计算结果。 1.3 openLooKeng内核调用 openLooKeng的多源查询能力是通过 Connector 机制来实现的。其中MySQL、postgreSQL等Connector是主要是通过presto-base-jdbc中的代码来实现对SQL等数据源的读写。

更多...

openLooKeng-gaussDB多分片tpc-ds指导

陈平增

| January 26, 2022 |

openLooKeng 多分片特性

本文旨在介绍对openLooKeng进行多分片特性进行tpc-ds 99语句性能测试的方法,使用的工具为apache jmeter,使用的数据源为gaussDB 200。 1 gaussDB连接使用方法指导 1.1 数据库连接 以操作系统用户omm登录gaussDB 200集群的任一主机 执行“gs_om -t status --detail”命令查询集群各实例情况 确认CN的端口号的方法,执行“cat /srv/BigData/mppdb/data1/coordinator/postgresql.conf | grep port” , 结果如下图所示: ps:port=25308为CN的端口号 1.1.1 本地连接数据库的方法: 使用用户omm登录集群主机 执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile 登录命令行客户端:gsql -d postgres -p 25308 1.1.2 远程连接数据库的方法: 默认情况下gaussDB 200只能在集群主机上通过自带的客户端登录数据库,通过配置IP规则后方能从远程登录数据库。 从浏览器登录(URL一般为http://serverIp:8080/web),在manager上添加数据库用户testuser,执行过程如下图: 允许用户testuser从xx.xx.xx.xx(openLooKeng服务器server ip)访问gaussDB 以omm登录集群主机执行以下shell命令: gs_guc set -Z coordinator -N all -I all -h "host all testuser xx.

更多...

openLooKeng多分片管理特性介绍

陈平增

| January 25, 2022 |

openLooKeng 多分片特性

本文介绍openLooKeng的多分片特性,该特性主要应用于提升类型为关系数据库的数据源的数据读取性能,进而提升SQL语句的执行效率。本文将从以下小节进行介绍: 多分片特性背景介绍 多分片原理及业务交互流程 多分片配置使用方法 多分片特性性能测试效果表现 简要结果分析 1.1 多分片特性背景介绍 特性的价值:在数据源不具备多分片能力的情况下,openLooKeng对数据表进行扫表工作时(table scan),所有的负载集中在单个worker上,无法充分利用集群多worker并发工作的优势,因此读取数据的效率不高。考虑在openLooKeng侧增加多分片处理能力,通过多分片并发访问数据表以提高数据查询的处理的效率。 实现原理:分片管理模块按照用户指定的列对目标表拆分为相应数量的分片,分片的分割以逻辑区段来划分。如果目标表在分割列上存在数据分布不均的情况,分片管理功能通过动态步长算法来均衡分片间的数据量。 1.2 多分片原理及交互流程(1) 对于只读数据表,分片划分时直接按用户的设置将表分割为N个分片。 对于非只读数据表,分割规则在只读数据表的基础上增加(-∞,minValue)和(maxValue,+ ∞)这两段,分割为N+2个分片。 1.3 多分片原理及交互流程(2)-动态步长调整 核心思想:对所有分片按它们的取值范围进行排序,合并记录数小于平均值的连续分片,按比例拆分记录数大于平均值的分片,在调整前、后总的分片个数保持不变。 1.4 多分片原理及交互流程(3)-业务流程 1.5 多分片原理及交互流程(4) 1.6 多分片配置使用方法介绍: 详细配置说明: https://openlookeng.io/zh-cn/docs/docs/admin/multi-split-for-jdbc-data-source.html 多分片配置使用-注意事项及经验传递 本特性针对JDBC数据源做优化,如MySQL、PG、openGauss等; 需要用户选定表中的整形值的列,设置为分片列; 建议选取重复值少、分布均匀的列; 大规模结果集回显占据大量时间,避免选取此类语句进行对比测试; 对网络延时较大或者数据源jdbc连接延时较大的场景,推荐在connector配置”use-connection-pool=true”,性能对比效果更显著; 同样环境条件下执行同一SQL语句的时延波动明显,建议每轮测试取多次执行(比如10次)的平均时延; 1.7 多分片特性的效果表现-单表测试

更多...

openLooKeng算子接口和执行流程

刘玉

| January 22, 2022 |

openLooKeng

1 openLooKeng算子接口 1.1 openLooKeng算子相关类 ▲ 图1-1 算子相关类 openLooKeng生成物理执行计划后,真正执行计划的是一个一个的算子(即Operator)。openLooKeng中将算子抽象为Operator接口,将算子工厂抽象为OperatorFactory接口,如图1-1所示。 而具体的算子则实现相应的OperatorFactory接口和Operator接口即可。例如Limit算子,在openLooKeng中会相应的有LimitOperatorFactory和LimitOperator。 1.2 openLooKeng算子接口 OperatorFactory提供的接口如表1-1所示: 1) createOperator,创建算子,返回相应的算子实例对象; 2) noMoreOperators,不再创建算子,可以释放OperatorFactory相关的资源; 3) duplicate,在right outer join或者full outer join时用到,用于复制OperatorFactory,返回OperatorFactory实例对象。 ▲ 表1-1 OperatorFactory接口 Operator提供的接口如表1-2所示: isBlocked,当前算子是否被Block,返回ListenableFuture; isFinished,当前算子处理是否结束,结束返回true,不再输出page; needsInput,当前算子是否可以接收输入page,可以则返回true; addInput,当前算子接收输入page,前提是当前算子的needsInput返回true; getOutput,当前算子输出page,如果没有输出page则返回null; finish,通知当前算子不再接收输入page,当前算子可以开始计算或者结束计算; close,当前算子释放相关资源; getOperatorContext,返回OperatorContext; startMemoryRevoke,内存不足时,将中间数据spill to disk,实现可以参考HashAggregationOperator,返回ListenableFuture; finishMemoryRevoke,startMemoryRevoke完成后调用,用于清理资源。 ▲ 表1-2 Operator接口 2 openLooKeng算子执行流程 openLooKeng算子的执行流程代码在Driver#processInternal()方法中,其中核心代码片段如下图所示: 翻译如下: 如果 !

更多...

一个小技巧,教你提升openLooKeng语句执行效率

崔敏

| January 20, 2022 |

openLooKeng

1 问题描述 利用之前一套老的集群环境测试一组数据时,发现openLooKeng当前测试的数据与其他环境测试的相差较大,且性能明显低于impala。 选择性能差距最大的query72在当前环境和之前环境跑,发现两个问题: 两个环境数据传输差异比较大 两个环境的执行计划差别比较大 2 问题定位 执行对hive表的analyze命令,可以收集给定表的表和列的统计信息,包括numFiles、numRows、rawDataSize、totalSize等。在执行复杂和包括join操作的大型数据集查询时,analyze可以通过统计信息来提高查询性能。由于11节点执行stage个数大大多于之前环境stage的数量,因此怀疑执行计划没有优化。也就是说执行后没有统计信息。 针对这个疑问,在hive client端找一个表,以表customer_demographics为例,在openLooKeng客户端执行show stats for customer_demographics;在查看对应的统计信息发现,统计信息全部为null。如下图: 基于此有两个怀疑,一是统计信息没有生成,另一个就是生成了,但openLooKeng没有读到。第二个原因基本可以排除,因为有一些表,比如store是可以读到统计信息的。所以怀疑是统计信息没有生成。 在执行analyze命令,openLooKeng会将表级的统计信息存储到TABLE_PARAMS表中,列级信息存储到TBL_COL_STATS表中,登录dbservice客户端,查询customer_demographics表对应的TABLE_PARAMS表中生成的数据,发现生成了numFiles,totalSize等字段但是并没有生成numRows字段,因此统计字段并非完全没有生成。 因此尝试跟踪代码确认openLooKeng读取数据并生成统计信息的流程。 定位代码MetastoreHiveStatisticsProvider类方法getTableStatistics中发现,calculateAverageRowsPerPartition方法计算得到的optionalAverageRowsPerPartition的值,其中会判断rowCount的值,当rowCount不存在时会直接返回空的统计信息。经上述查询可知,数据库中没有生成rowCount字段因此在查询customer_demographics表统计信息时均返回null。 3 解决方式 由上分析,尝试在openLooKeng客户端执行analyze操作。 查询dbserver中TABLE_PARAMS表中字段,此时生成了numRows字段。 openLooKeng客户端查询统计信息也可以查到。 此时重新执行上述sql,stage数量由21个降到13个,查询耗时与之前环境的测试数据差别不大,且传输速率也提高了。 4 总结 为提高查询效率,在执行查询之前还是要执行analyze,生成统计信息,进而提升openLooKeng的执行性能。 如果您有任何疑问或建议,欢迎在社区代码仓内提Issue;也欢迎加小助手微信(openLooKengoss),进入专属技术交流群。 社区代码仓 https://gitee.com/openlookeng https://github.com/openlookeng openLooKeng,让大数据更简单!

更多...

openLooKeng ODBC/JDBC对接BI工具操作指导手册

余梅&邓冉

| January 15, 2022 |

openLooKeng BI工具 ODBC

1 安装指南 1.1 安装准备 预先部署Hetu服务,启动服务 BI工具为Power BI、Tableau、永洪 下载Power BI Desktop软件 下载TableauDesktop软件,安装软件时用默认配置即可,默认软件安装位置C:\Program Files\Tableau 下载Yonghong Desktop软件,安装软件时用默认配置即可,默认软件安装位置C:\Yonghong Desktop 2 ODBC连接 2.1 配置ODBC 安装 ODBC 驱动 配置ODBC,方法如下: 点击添加 选择安装的数据源驱动为OneQuery ODBC 1.1 Driver 填写创建数据源信息 添加完成后,用户数据源处会出现新创建的数据源 2.2 Tableau 连接 ODBC 首次登录Tableaau在选择ODBC连接数据源时点击“更多” 选择“其他数据库ODBC” 确认ODBC连接方式后,会弹框选择之前配置ODBC时的名称,然后点击连接 2.3 PowerBI连接ODBC 登录PowerBI – 获取数据源 搜索ODBC 确认ODBC连接方式后,会弹框选择之前配置ODBC时的名称Hetu_test,然后点击确定 输入Hetu server服务器的用户名密码,点击连接 3 JDBC连接

更多...