破晓

前言 Doris 支持两种物理算子，一类是 Hash Join，另一类是 Nest Loop Join。 Hash Join：在右表上根据等值 Join 列建立哈希表，左表流式的利用哈希表进行 Join 计算，它的限制是只能适用于等值 Join。 Nest Loop Join：通过两个 for 循环，很直观。然后它适用的场景就是不等值的 Join，例如：大于小于或者是需要求笛卡尔积的场景。它是一个通用的 Join 算子，但是性能表现差。 作为分布式的 MPP 数据库， 在 Join 的过程中是需要进行数据的 Shuffle。数据需要进行拆分调度，才能保证最终的 Join 结果是正确的。举个简单的例子，假设关系S 和 R 进行Join，N 表示参与 Join 计算的节点的数量；T 则表示关系的 Tuple 数目。 Doris Join 调优方法Doris Join 调优的方法： 利用 Doris 本身提供的 Profile，去定位查询的瓶颈。Profile 会记录 Doris 整个查询当中各种信息，这是进行性能调优的一手资料。 了解 Doris 的 Join 机制。知其然知其所以 ...

问题在使用Tableau连接Kylin进行多维分析的时候，偶现查询失败，连接超时的问题，由此开始排查事故出现的原因。 1、在Kylin的logs里面定位到有JVM OOM的情况，然后查看Kylin Server的JVM GC日志，发现在某个时间段会频繁的发生Full GC，Full GC可以持续十几分钟，同时GC后，老年代空间没有任何变化，这次Full GC无法回收一个对象，开始怀疑发生了内存泄漏。 2、生产中部署了三个Kylin Server节点，前面由Nginx进行反向代理，进行负载均衡。查看Nginx日志，发现只有其中一个节点有Timeout的错误日志，于是怀疑Nginx负载均衡配置有问题，大部分流量分到一个节点，导致OOM。但是查看nginx配置，发现没有任何问题，同时Count Nginx请求日志，发现流量也不大，因此和Nginx与大流量高负载可能没有关系。 3、到这里，只能利用MAT对JVM的Heap Dump文件*.hprof进行分析，文件有20G大，分析过程中一度导致服务器CPU狂飙至99%，顺利完成后，得到三个zip压缩文件，查看后，检测到内存泄漏，是由两个超大Li ...

只需要下载对应的flink-sql-connector-hive-3.1.2_2.12-1.14.5.jar,放在{FLINK_HOME}/lib下面即可。 不需要下载什么flink-shaded-hadoop-3-uber-3.1.1.7.2.9.0-173-9.0.jar放在{FLINK_HOME}/lib下面,现在Flink通过 1>export HADOOP_CLASSPATH=`hadoop classpath` 来寻找Hadoop相关的Jar包。 当Flink on YARN时，还需要在{FLINK_HOME}/lib中添加以下依赖： 123456789>要么是这个： flink-shaded-hadoop-2-uber-2.7.5-8.0.jar>要么是，可以直接从hadoop/share/hadoop/mapreduce/等目录拷过来： hadoop-common-3.0.0-cdh6.3.1.jar hadoop-mapreduce-client-common-3.0.0-cdh6.3.1. ...

SS-Table SSTable 最早出自 Google 的 Bigtable 论文 An SSTable provides a persistent, ordered immutable map from keys to values, where both keys and values are arbitrary byte strings. Operations are provided to look up the value associated with a specified key, and to iterate over all key/value pairs in a specified key range. Internally, each SSTable contains a sequence of blocks (typically each block is 64KB in size, but this is configurable). A block index (stored at the end of the SSTable) is us ...

Doris 中用于控制Compaction的参数非常多。本文尝试以下方面，介绍这些参数的含义以及如果通过调整参数来适配场景。 数据版本是如何产生的，哪些因素影响数据版本的产出。 为什么需要 Base 和 Cumulative 两种类型的 Compaction。 Compaction 机制是如何挑选数据分片进行 Compaction 的。 对于一个数据分片，Compaction 机制是如何确定哪些数据版本参与 Compaction 的。 在高频导入场景下，可以修改哪些参数来优化 Compaction 逻辑。 Compaction 相关的查看和管理命令。 Why need CompactionDoris 的数据写入模型使用了 LSM-Tree 类似的数据结构。数据都是以追加（Append）的方式写入磁盘的。这种数据结构可以将随机写变为顺序写。这是一种面向写优化的数据结构，他能增强系统的写入吞吐，但是在读逻辑中，需要通过 Merge-on-Read 的方式，在读取时合并多次写入的数据，从而处理写入时的数据变更。 Merge-on-Read 会影响读取的效率，为了降低读取时需要合并的 ...

本篇将从实际使用场景的角度出发，介绍 Compaction 的调优思路和策略。通过本文将了解到 Compaction 相关的日志分析、参数调整和 API 的使用。 什么情况下需要调整 Compaction 参数Compaction 的目的是合并多个数据版本，一是避免在读取时大量的 Merge 操作，二是避免大量的数据版本导致的随机IO。并且在这个过程中，Compaction 操作不能占用太多的系统资源。所以我们可以以结果为导向，从以下两个方面反推是否需要调整 Compaction 策略。 检查数据版本是否有堆积。 检查 IO 和内存资源是否被 Compaction 任务过多的占用。 查看数据版本数量变化趋势Doris 提供数据版本数量的监控数据。如果你部署了 Prometheus + Grafana 的监控，则可以通过 Grafana 仪表盘的 BE Base Compaction Score 和 BE Cumu Compaction Score 图表查看到这个监控数据的趋势图： 这个图表展示的是每个 BE 节点，所有 Tablet 中数据版本最多的那个 Tablet ...

Thrift-Java-Maven使用指北 1、下载安装Thrift，配置Thrift环境变量 2、Maven中引入libthrift依赖 12345<dependency> <groupId>org.apache.thrift</groupId> <artifactId>libthrift</artifactId> <version>0.14.1</version></dependency> 3、引入Maven插件maven-thrift-plugin 12345678910111213141516171819<build> <plugins> <plugin> <groupId>org.apache.thrift.tools</groupId> <artifactId>maven-thrift-plugin</artifact ...

优化的两个基本原则 Runtime Filter

前言 Oracle的binlog日志已经由DBA通过OGG同步到Kafka中了，因此用不到Flink CDC 同步到Kafka中的JSON样式12345678910111213141516171819202122{"before": { "id": 111, "name": "scooter", "description": "Big 2-wheel scooter", "weight": 5.18},"after": { "id": 111, "name": "scooter", "description": "Big 2-wheel scooter", "weight": 5.15},"op_type": "U& ...