版本升级背景

spark 2.4.0 最近刚发版，新增了很多令人振奋的特性。由于本司目前使用的是spark 2.3.0版本，本没打算这么快升级到2.4.0。无奈最近排查出的两个大bug迫使我们只能对spark进行升级。排查的两个bug如下：


前言

Flink 近几年来一直备受业界瞩目，相对于同时期一夜成名的Spark来说，有种厚积薄发的味道。 当然，从根本上来看，也是因为这几年对于实时分布式计算引擎的需求日渐强烈，要求也越来越高（数据的latency，一致性）。而这也意味着以微批次来fake实时处理的Spark Streaming不再能满足实时处理系统的硬性要求(忽略spark continuous processing实现)。最近本司也正在考虑将实时处理任务从Spark Streaming迁移到Flink；于是就有了下面这篇实战总结文章。

前言

Spark作为一款分布式计算查询引擎，在大数据领域逐渐扮演着越来越重要的作用。传统的MapReduce因计算模型缺陷导致在面对海量数据，复杂的计算场景下计算效率十分低下。于是Spark作为一种互补的即席查询实现方案被各大公司采用。下面是对Spark一些概念和使用的总结

介绍

airflow是一款开源的，分布式任务调度框架，它将一个具有上下级依赖关系的工作流，组装成一个有向无环图。

• 特点:
  • 分布式任务调度：允许一个工作流的task在多台worker上同时执行

前言

说起Impala，很多人都不会陌生。它区别于MapReduce 中间结果溢写，跨节点数据获取的低效，采用MPP 查询引擎，各查询节点并发执行查询语句，并将生成的查询结果汇总输出。
近期开始真正的使用impala，之前只是小玩过已经集成好的环境，并没有真正的从0到1的去构建Impala集群。基于我司所有的大数据组件都是采用容器的方式部署以便统一管理，我们需要先构建Impala镜像

前言

虽然百度的Palo是个很强大的，基于MPP Search Engine的OLAP框架，但是由于处于开源的早期阶段，各方面都不是很完善。其中，Palo集群的稳定性对于日渐依赖Palo的核心的业务来说显得尤为重要。最近也一直在做Palo稳定性建设相关的工作。在对全链路监控这块，自然而然地想到对业务中使用频繁的http-mini-load接口进行SDK封装，以实现对请求进行失败重试以及失败率的监控报警的功能。

HotSpot JVM Architecture

前言

最近我们组负责数据建模的同学抱怨kylin的relization选择策略：同一个project下一条查询语句本来期望命中某一个cube的，结果系统却选择了其他cube。之前也有大概翻阅过kylin这块的实现源码，知道如果同一个project下如果有多个满足条件的的实现，会按照成本排序并选择成本最低的那个实现。对于成本这块的度量标准，没有做过多研究，于是带着问题，对这块源码进行了一次梳理。

前言

• 由于数据组目前重度依赖kylin，然而kylin并没有官方开源的数据可视化工具。所幸kylin提供了丰富的查询API供我们直接传入SQL进行查询，与此同时发现superset有非官方对接kylin的开源插件，虽然两年没有维护了，对代码进行了部分重构也就成功将superset和kylin对接起来了。

前言

• 众所周知，Java长期以来比较遭业界嫌弃的是太笨重，代码冗余过大。然而依托于Java庞大健全的开源社区，这些缺点正在逐渐改善。Java 8 引进的lambda以及函数式编程的思想让我们的代码越来越简洁。lombok等各大开源神器让我们的冗余代码越来越少。