前言

物化视图（Materialized View）本质是一种预计算，即把某些耗时的操作（例如JOIN、AGGREGATE）的结果保存下来，以便在查询时直接复用，从而避免这些耗时的操作，最终达到加速查询的目的。其作为一种检索加速技术，应用在许多 olap 引擎中，本文以 Doris 为例，主要介绍 Doris 的物化视图实现、应用场景以及如何查看是否命中物化视图、如果没有命中的话，原因又是哪些。

前言

为什么要了解数据索引呢？我们都知道索引结构一般会加速查询，那这些索引是如何加速查询的呢？我们有时候建立了索引，但是查询比没建索引都要慢，这又是为什么呢？我们有时候会根据不同的业务场景选择不同的索引类型，选择的依据又是什么呢？

带着以上几个疑惑，让我们开始了解数据库索引到底是啥，它的底层数据结构是什么样子的，是怎样加速查询的，索引本身又做了哪些优化。希望读完本文后，可以为你解决上述存留在心中的疑问。

在这里也顺便提下个人对大数据的理解，大数据其实就是海量数据的存储和检索，前者关注于如何更高效的把数据放到存储介质上，后者关注于如何更高效的把数据从存储介质上检索出来，需要注意这里的检索指的是检查数据是否存在，如果数据存在则返回。而索引又是检索的核心，了解索引之后会对理解整个检索过程有更深刻的理解，比如执行计划的解析，join order 等等的影响。

前言

在作业帮工作过程中，接触了 leads 线索数据、端外信息流广告，端内营销广告、用户画像平台等各种数据的处理。每种数据结合其业务查询场景又有不同的架构选型。本文主要用来记录这几份业务数据的数据流架构，并讨论为什么这样实现，有哪些优缺点。

前言

作业帮内部营销中台（以下简称 IMP）承载着整个公司各个 app 端的流量分发，对智能化运营，精细化的营销广告投放起着至关重要的作用。对这些流量数据的链路转化进行有效的分析更是重中之重。

IMP 的整个链路流量数据处理采用的 flink + druid，并强依赖于 druid 提供上层的 BI，监控平台，算法接口，策略平台数据服务等线上应用。作为内部最大的 druid 集群，如何保证其能稳定的支撑海量数据的摄入与查询就成为了一个大问题。本来主要记录在对 druid 集群运维过程中碰到的一些问题以及优化。

前言

2020 年末入职作业帮，接触到了 doris，当时还是 doris on es，后来随着业务的发展，从 doe 切到 dorisdb，再到 starrocks，期间做过了很多基础测试（包括离线，实时摄入，doris 本身的数据集成工具，apache seatunnel 的 doris connector 等），也碰到过很多慢查询问题，内部的广告用户画像平台也是基于 starrocks 进行构建的。本文主要在回忆下碰到的问题吧，对一些至今仍未解决的问题也会留下自己的猜想，希望后面有机会可以在验证吧。

前言

2022 年5月份之后发生了很多事情，面试的身心俱疲，亲人的突然病故，面对各种选择时的犹豫不决。未来到底要做成什么样子呢？工作的意义又是什么呢？

前言

观察 flink-doris-connector 和 RoutineLoad 的数据摄入情况，包括 kafka消费速率、doris 集群情况、doris 数据导入速率、各种调参造成的性能波动、不同 doris 表数据模型以及数据处理语义对导入性能的影响。

前言

好久没有更新过博客了，去年接触了很多大数据技术相关的东西，也做过一些基准测试。但是很多东西依然了解的相对浅显，只停留在使用层面，想下笔却又不知道从何写起。2021 年结束的时候曾列过一些计划，也算是学习过程中的一份指南吧。

前言

2021 年下半年主要做的是 IMP 实时/离线数据流的摄入以及涉及的各种 BI 报表工作。IMP 即内部营销平台，也可以叫作端内广告投放，作为最前置的业务，IMP 整个链路横跨广告投放、策略分流、落地页、微信导流、短信/PUSH、成单等多个垂直业务单元。随着业务需求的频繁迭代，之前构建的业务数仓暴露出来越来越多的问题，表、字段的命名不统一，同一业务不同表之间的逻辑耦合，相同指标不同口径实现的来回对数也对数据研发侧造成了很大困扰，由此本身产出的数据指标的置信性也开始受到挑战。

基于以上问题，2022 年开始做了一些离线业务数仓方向上的调研以及落地规划。目标是在支撑业务快速迭代开发的前提下，统一化字段业务口径，规范化离线数据开发，降低离线表的存储资源，去除逻辑的冗余开发，提高离线 ETL 的开发效率。

本文主要介绍个人基于 OneData 的一些看法，并举一些例子。

前言

MapReduce 的 Counters 对任务执行分析有一定帮助，本文主要记录其中参数的含义及一些使用。