Feng

README.md

@@ -1,19 +1,18 @@
 # DataWarehouse
 > 全站第一份数据仓库的学习资料
 
-在数仓岗位，经历了部门向中台的转化，数据仓库向数据湖的过渡，BI到数据平台的开发。历经一年准备，终于把平时工作相关的资料整理起来，自己的一点心得总结输出一下。
+在数仓岗位的日子，经历了公司部门向中台的转化，BI到数据平台的开发，数据仓库向数据湖的过渡。历经一年准备，终于把平时遇到的知识点整理起来，结合自己的心得总结一下。
 
 - [个人杂谈](./docs/me.md)
 - [数据仓库的定义](./docs/数仓定义.md)
+- [从零开始搭建数据仓库](./docs/从零开始搭建数据仓库.md)
 - [数仓建设的十大陷阱](./docs/数仓建设的十大陷阱.md)
-- 数据仓库的古往今来
-- 数据仓库和数据湖
-- 数仓建设
-- 实时数仓
+- [数据模型](./docs/数据模型.md)
+- [数据模型如何评论好坏](./docs/数据模型如何评论好坏.md)
+- [实时数仓](./docs/实时数仓.md)
 - 离线数仓
 - 模型设计
 - 维度建模
-- OLAP
 
 - [数据库和数据仓库, OLTP和OLAP](./docs/数据库和数据仓库的区别.md)
 - [数据湖](./docs/数据湖.md)
@@ -24,4 +23,6 @@
 - 数据质量
 - 工作流
 
+- [OLAP引擎分类](./docs/olap.md)
+
 - 公司把神策copy成了自己的数据平台

docs/me.md

@@ -1,7 +1,7 @@
 ## 加班
 在这个岗位，还是很幸运。如果公司不强制，就没有那么多机会加班。更多的是要求我们对业务的熟悉以及思考，需求也不会像前端开发一样今天调个色明天改个样板，对吧，加班就没了意义。反正我是习惯半夜了去总结去思考，让我加班去梳理业务那就是扯淡，累了一天哪还有精力。
 
-但是，如果岗位是偏开发的，那就可能代码工作量要大些。前段时间公司架构改造，好多离线工程改成实时计算，坚持半年总算结束了，接下来又要搞用户画像。反正我已经半年都处于加班状态了，不过还好，哥一直单身，要不然女朋友跑到别人怀里了都在努力工作呢。
+但是，如果岗位是偏开发的，那就可能代码工作量要大些。前段时间公司架构改造，大部分离线工程改成实时流，坚持半年总算告一段落了，接下来又要搞用户画像。反正我已经半年都处于加班状态了，不过还好，哥一直单身，要不然女朋友跑到别人怀里了都在努力工作呢。
 
 
 ## 岗位思考
@@ -11,6 +11,7 @@
 
 之前总被大佬教育，要想长期在互联网圈发展，必须掌握三种能力之一：业务能力、架构能力、算法能力。当然有资源有爹的人就不算在内了。现在想想还真的有道理。刚从大数据开发进入这个领域时，一头雾水，我一个程序员干嘛还天天写excel、ppt呢？现在明白了，能当上高管的都是ppt写得好的，感谢一致坚持的自己吧。与君共勉！
 
+
 ## 模型
 数据分析有建模，机器学习有建模，数据仓库还有建模......
 

docs/olap.md

@@ -0,0 +1,111 @@
+# OLAP
+
+OLAP和OLTP不同的是，表中单条记录本身并不是查询所关心的，比较典型的特点包括有聚合类算子、涉及多表Join，查询所用谓语/条件没有索引。由于这些操作都非常耗计算资源，而且数据仓库相比数据库在数据量上大很多，因此，OLAP类查询经常表现为cpu-bound而不是io-bound。
+
+按照建模类型划分：
+* [MOLAP](#MOLAP)
+* [ROLAP](#ROLAP)
+* [HOLAP](#HOLAP)
+
+## MOLAP
+这应该算最传统的数仓了，1993年olap概念提出来时，指的就是MOLAP数仓，M即表示`多维`。大多数MOLAP产品均对原始数据进行预计算得到用户可能需要的所有结果，将其存储到优化过的多维数组中，也就是常听到的 `数据立方体`。
+
+由于所有可能结果均已计算出来并持久化存储，查询时无需进行复杂计算，且以数组形式可以进行高效的免索引数据访问，因此用户发起的查询均能够稳定地快速响应。这些结果集是高度结构化的，可以进行压缩/编码来减少存储占用空间。
+
+但高性能并不是没有代价的。首先，MOLAP需要进行预计算，这会花去很多时间。如果每次写入增量数据后均要进行全量预计算，显然是低效率的，因此支持仅对增量数据进行迭代计算非常重要。其次，如果业务发生需求变更，需要进行预定模型之外新的查询操作，现有的MOLAP实例就无能为力了，只能重新进行建模和预计算。
+
+在开源软件中，由eBay开发并贡献给Apache基金会的Kylin即属于这类OLAP引擎，支持在百亿规模的数据集上进行亚秒级查询。
+
+下图是官方对Kylin的描述。
+
+![kylin](/img/kylin.png)
+
+#### 代表
+- **Kylin**是完全的预计算引擎，通过枚举所有维度的组合，建立各种Cube进行提前聚合，以HBase为基础的OLAP引擎。
+- **Druid**则是轻量级的提前聚合(roll-up)，同时根据倒排索引以及bitmap提高查询效率的时间序列数据和存储引擎。
+
+#### 优点
+- **Kylin**
+1. 支持数据规模超大(HBase)
+2. 易用性强，支持标准SQL
+3. 性能很高，查询速度很快
+
+- **Druid**
+1. 支持的数据规模大(本地存储+DeepStorage–HDFS)
+2. 性能高，列存压缩，预聚合加上倒排索引以及位图索引，秒级查询
+3. 实时性高，可以通过kafka实时导入数据
+
+#### 缺点
+- **Kylin**
+1. 灵活性较弱，不支持adhoc查询；且没有二级索引，过滤时性能一般；不支持join以及对数据的更新。
+2. 处理方式复杂，需要定义Cube预计算；当维度超过20个时，存储可能会爆炸式增长；且无法查询明细数据了；维护复杂。
+3. 实时性很差，很多时候只能查询前一天或几个小时前的数据。
+
+- **Druid**
+1. 灵活性适中，虽然维度之间随意组合，但不支持adhoc查询，不能自由组合查询，且丢失了明细数据。
+2. 易用性较差，不支持join，不支持更新，sql支持很弱(有些插件类似于pinot的PQL语言)，只能JSON格式查询；对于去重操作不能精准去重。
+3. 处理方式复杂，需要流处理引擎将数据join成宽表，维护相对复杂；对内存要求较高。
+
+#### 场景
+- **Kylin**：适合对实时数据需求不高，但响应时间较高的查询，且维度较多，需求较为固定的特定查询；而不适合实时性要求高的adhoc类查询。
+- **Druid**：数据量大，对实时性要求高且响应时间短，以及维度较少且需求固定的简单聚合类查询(sum，count，TopN)，多以Storm和Flink组合进行预处理；而不适合需要join、update和支持SQL和窗口函数等复杂的adhoc查询；不适合用于SQL复杂数据分析的场景。
+
+## ROLAP
+与MOLAP相反，ROLAP无需预计算，直接在构成多维数据模型的事实表和维度表上进行计算。R即表示关系型（Relational）。显然，这种方式相比MOLAP更具可扩展性，增量数据导入后，无需进行重新计算，用户有新的查询需求时只需写好正确的SQL语句既能完成获取所需的结果。
+
+但ROLAP的不足也很明显，尤其是在数据体量巨大的场景下，用户提交SQL后，获取查询结果所需的时间无法准确预知，可能秒回，也可能需要花费数十分钟甚至数小时。本质上，ROLAP是把MOLAP预计算所需的时间分摊到了用户的每次查询上，肯定会影响用户的查询体验。
+
+当然ROLAP的性能是否能够接受，取决于用户查询的SQL类型，数据规模以及用户对性能的预期。对于相对简单的SQL，比如TPCH中的Query响应时间较快。但如果是复杂SQL，比如TPC-DS中的数据分析和挖掘类的Query，可能需要数分钟。
+
+相比MOLAP，ROLAP的使用门槛更低，在完成星型或雪花型模型的构建，创建对应schema的事实表和维度表并导入数据后，用户只需会写出符合需求的SQL，就可以得到想要的结果。相比创建 `数据立方体`，显然更加方便。
+
+目前生产环境使用较多的开源ROLAP主要可以分为2大类，一个是**宽表模型**，另一个是**多表组合模型**（就是前述的星型或雪花型）。
+
+### 宽表类型
+宽表模型能够提供比多表组合模型更好的查询性能，不足的是支持的SQL操作类型比较有限，比如对Join等复杂操作支持较弱或不支持。
+
+目前该类OLAP系统包括`Druid`和`ClickHouse`等，两者各有优势，Druid支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能，在广告分析场景、监控报警等时序类应用均有广泛使用；ClickHouse部署架构简单，易用，保存明细数据，依托其向量化查询、减枝等优化能力，具备强劲的查询性能。两者均具备较高的数据实时性，在互联网企业均有广泛使用。
+
+除了上面介绍的Druid和ClickHouse外，ElasticSearch和Solar也可以归为宽表模型。但其系统设计架构有较大不同，这两个一般称为搜索引擎，通过倒排索引，应用Scatter-Gather计算模型提高查询性能。对于搜索类的查询效果较好，但当数据量较大或进行扫描聚合类查询时，查询性能会有较大影响。
+
+#### 代表
+- **ClickHouse**是个列存数据库，保存原始明细数据，通过`MergeTree`使得数据存储本地化来提高性能。 是个单机版超高性能的数据库
+
+#### 优点
+1. 性能高，列存压缩比高，通过索引实现秒级响应
+2. 实时性强，支持kafka导入
+3. 处理方式简单，无需预处理，保存明细数据
+
+#### 缺点
+1. 数据规模一般
+2. 灵活性差，不支持任意的adhoc查询，join的支持不好。
+3. 易用性较弱，SQL语法不标准，不支持窗口函数等；维护成本高
+
+### 多表组合模型
+采用星型或雪花型建模是最通用的一种ROLAP系统，常见的包括`GreenPlum`、`Presto`和`Impala`等，他们均基于MPP架构，采用该模型和架构的系统具有支持的数据量大、扩展性较好、灵活易用和支持的SQL类型多样等优点。
+
+相比其他类型ROLAP和MOLAP，该类系统性能不具有优势，实时性较一般。通用系统往往比专用系统更难实现和进行优化，这是因为通用系统需要考虑的场景更多，支持的查询类型更丰富。而专用系统只需要针对所服务的某个特定场景进行优化即可，相对复杂度会有所降低。
+
+对于ROLAP系统，尤其是星型或雪花型的系统，如果能够尽可能得缩短响应时间非常重要，这将是该系统的核心竞争力。
+
+#### 代表
+- **Presto**、**Impala**以及**Spark SQL**等利用关系模型来处理OLAP查询，通过并发来提高查询性能。同时三者是有很多相似点。我日常工作中，接触最多也就是这三兄弟和一个大哥(Hive)。Hive就不多谈了，是基于MR最基础的OLAP引擎，也是对于大数据量的分析支持最好得。
+
+#### 优点
+1. 支持的计算数据规模大(非存储引擎)
+2. 灵活性高，随意查询数据
+3. 易用性强，支持标准SQL以及多表join和窗口函数
+4. 处理方式简单，无需预处理，全部后处理，没有冗余数据
+
+
+#### 缺点
+1. 性能较差，当查询复杂度高且数据量大时，可能分钟级别的响应。同时其不是存储引擎，因此没有本地存储，当join时shuffle开销大，性能差
+   举例：SparkSql为例子，其只是计算引擎，导致需要从外部加载数据，从而数据的实时性得不到保证；多表join的时候性能也很难得到秒级的响应。
+2. 实时性较差，不支持数据的实时导入，偏离线处理。 如果需要实时数据，经常的做法是Presto或者Impala和Kudu的结合，解决了Kudu的磁盘存储问题，实时性能也不会太差。
+
+
+## HOLAP
+MOLAP和ROLAP各有优缺点，而且是互斥的。如果能够将两者的优点进行互补，那么是个更好的选择。而HOLAP的出现就是这个目的，H表示混合型（Hybrid），这个想法很朴素直接。对于查询频繁而稳定但又耗时的那些SQL，通过预计算来提速；对于较快的查询、发生次数较少或新的查询需求，像ROLAP一样直接通过SQL操作事实表和维度表。
+
+目前似乎没有开源的OLAP系统属于这个类型。相信未来HOLAP可能会得到进一步发展，并获得更大规模的使用。
+

docs/从零开始搭建数据仓库.md

@@ -0,0 +1,9 @@
+## 如何从零开始搭建数据仓库
+
+1. 首先，如果要搭建数仓，前提是你对业务足够熟悉，或者是有一个对业务足够熟悉的同事支持你。如果你打算边搭建数仓边熟悉业务，那就放弃吧，到最后都是坑，我是深有体会。
+
+2. 其次，搭建数据仓库就像盖房子一样，从打地基到装修都是有流程的，而且缺一不可。具体搭建流程查看我的博客—— [数仓构建流程](https://blog.csdn.net/fenglei0415/article/details/99101592)
+
+3. 工作中，遇到很多人花很多时间聊工具的问题，怎么下载、 怎么使用，听到最多的就是powerdesigner和ERwin。 我的建议是，工具是其次，如果掌握了数仓搭建的关键，或者理解了其中的实际思想，工具使用什么并不重要。 powerdesignerh和ERwin是比较成熟的建模工具，但也只是针对传统的Oracle、MySQL建模比较合适，可以一键生成ETL脚本。 我比较喜欢用Excel，虽然俗气，但是比较自由，我认为能快读达到目的就是ok的。
+
+4. 数仓建设的核心是模型设计，同样是维度建模，有的模型能完美支持业务的扩展、公司的发展，而有的却要不断优化甚至是重建。模型的好坏，决定了数仓能支撑企业业务多久。模型设计单独拿出来一篇讲。