漫谈数仓第一篇NO.1 『基础架构』
01. 架构演进
离线数据仓库到实时数据仓库，从lambda架构到kappa架构、再到混合架构。本文不再多再介绍，之前文章已有深入介绍，如有兴趣可看这篇文章：数据仓库介绍与阿里实时数仓案例 （点击链接）。
02. 逻辑分层
数仓分层，一般按ods->dw->dm整体架构。不同的企业，不同的业务场景，有衍生出不同的分层架构模式。例如经典四层架构：ods->dwd->dws-ads，bdl->fdl->gdl->adl等。
技术选型，传统数仓一般以Oracle、greenplum、teradata 等，互联网数仓一般以Hadoop生态圈为主，离线以Hive为核心，准实时以spark为核心，实时以flink为核心构建。
03. 数据调研
业务调研，业务侧对齐，遵循关系型数据库建模方式，从概念模型（cdm）->逻辑模型（ldm）->物理模型（pdm）建模套路，是一个从抽象到具体的一个不断细化完善的分析，设计和开发的过程。
需求调研，现有BI报表需求，统计需求，用户画像，推荐系统等数据应用。
数据库调研，了解数据库表数据结构、数据形态，全局把握业务流程数据流向，做到真正业务流程和数据结构结合。
04. 主题域划分
业务高度抽象，可先确定企业业务bu模块，然后可根据概念模型（cdm）进行一级主题划分，确定一致性维度和事实流程，构建总线矩阵。
图片来源 Kimball《The Data Warehouse Toolkits，- 3rd Edition》
按照kimball大师经典建模四步骤：选择业务过程->声明粒度->确定维度->确定事实 进行维度建模。
05. 数仓规范
构建企业级数据仓库，必不可少的就是制定数仓规范。包括 命名规范，流程规范，设计规范，开发规范 等。无规矩不成方圆，建设数仓也是这样。
开发规范 示例：
06. 数据治理
大数据时代必不可少的一个重要环节，可从数据质量、元数据管理、数据安全、数据生命周期等方面开展实施。数据治理是一个企业安身立命的根本。
数据质量，必须保证完整性、准确性、一致性、时效性。每一个任务都应该配置数据质量监控，严禁任务裸奔。可建设统一数据质量告警中心从以下四个方面进行监控、预警和优化任务。
元数据管理，关于数据的数据。可分为技术元数据和业务元数据。对于数仓开发和维护，模型血缘关系尤为重要。
数据安全，可包含以下五方面的内容，即数据的保密性、真实性、完整性、未授权拷贝和所寄生系统的安全性。
07. 数仓理念
从80年代到现在，数据仓库流派之争已趋于稳缓，比较经典的就是数仓大师Kimball的维度建模、数仓之父Inmon的范式(E-R)建模，另外还有Data Vault建模、Anchor模型等。
Kimball Data Warehouse Architecture：
Inmon Data Warehouse Architecture：
结语：数仓是一种思想，数仓是一种规范，数仓是一种解决方案。
漫谈数仓第二篇NO.2 数据模型（维度建模）
前言：
model对于数仓是最核心的东西，数据模型是数据组织和存储方法，模型的好坏，决定了数仓能支撑企业业务多久。
为什么大多数企业，数仓都要重建，这不仅仅是业务拓展、发展迅速，很大一部分是因为模型建的很烂。
01. 基本概念
维度建模，是数据仓库大师Ralph Kimball提出的，是数据仓库工程领域最流行的数仓建模经典。
维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
它是面向分析的，为了提高查询性能可以增加数据冗余，反规范化的设计技术。
1、1 事实表
事实表产生于业务过程，存储了业务活动或事件提炼出来的性能度量。从最低的粒度级别来看，事实表行对应一个度量事件。
事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。
（1）事务事实表，用于承载事务数据，通常粒度比较低，它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表，例如产品交易事务事实、ATM交易事务事实。
（2）周期快照事实表，按照一定的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表。
（3）累积快照事实表，用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见。
注意：
这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
1、2 维度表
维度表，一致性维度，业务过程的发生或分析角度，我们主要关注下退化维度和缓慢变化维。
（1）退化维度（DegenerateDimension）
在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。
（2）缓慢变化维（Slowly Changing Dimensions）
维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD）。
SCD常用的三种处理方式：
① TYPE1 直接覆盖原值
② TYPE2 增加维度行
在为维度成员增加新行时，需为其分配新的主代理键。
并且，至少需要在维度行再增加三列：
有效日期、截止日期、行标识。
这个地方可联想拉链表设计。
③ TYPE3 增加属性列
④ 混合方式
可根据实际业务场景，混合或选择使用以上三种方式，以快速方便而又准确的分析历史变化情况。
1、3 粒度
用于确定某一事实表中的行表示什么，是业务最小活动单元或不同维度组合，即业务细节程度。
1、4 维度建模流程
维度建模步骤：选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。
声明粒度，为业务最小活动单元或不同维度组合。以共同粒度从多个组织业务过程合并度量的事实表称为合并事实表，需要注意的是，来自多个业务过程的事实合并到合并事实表时，它们必须具有同样等级的粒度。
02.建模方法 -
- 经典数据仓库模型
数据仓库建模方法论可分为：维度建模、范式建模、Data Vault模型、Anchor模型。
2、1 维度模型
企业中最流行、也是最经典的数仓建模经典，数据仓库大师Ralph Kimball的经典著作《数据仓库工具箱 维度建模权威指南 第三版》一本书进行了论述。从事数据仓库/ETL/BI的同学，强烈建议买一本至少读一遍。
按数据组织类型划分可分为星型模型、雪花模型、星座模型。
（1）星型模型
星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。
图来源于Kimball《The Data Warehouse Toolkits -3rd Edition》
（2）雪花模型
雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
（3）星座模型
星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。数仓模型建设后期，大部分维度建模都是星座模型。
2、2 范式模型
即 实体关系（ER）模型，数据仓库之父Immon提出的，从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF。此建模方法，对建模人员的能力要求非常高。
2、3 Data Vault模型
DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性） 三部分组成 ，是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。
2、4 Anchor模型
高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。企业很少使用，本文不多做介绍。
03. 建模工具
建模工具，一般企业以Erwin、powerdesigner、visio，甚至Excel等为主。也有些企业自行研发工具，或使用阿里等成熟套装组件产品。
3、1 PowerDesigner
是Sybase的企业建模和设计解决方案，是能进行数据库设计的强大的软件，是一款开发人员常用的数据库建模工具。使用它可以分别从概念数据模型(Conceptual Data Model)和物理数据模型(Physical Data Model)两个层次对数据库进行设计。
3、2 ERWin
全称是ERwin Data Modeler，是CA公司的数据建模工具。ERwin提供数据库结构，管理界面的容易简单，图形显示对视觉复杂。
另附一张 www.erwinchina.com 中文官网首页截图，这几句话很霸气有木有
3、3
Visio
Visio
是Office 软件系列中的负责绘制流程图和示意图的软件，是一款便于IT和商务人员就复杂信息、系统和流程进行可视化处理、分析和交流的软件。同时它也可以用来数据库建模。
打开visio 2010,文件—>新建—>数据库—>数据库模型图。建立数据库模型图之后，菜单栏多出一个菜单项”数据库”。
3、4 Excel Mapping
通过我们最熟悉的Excel进行维护数据模型、血缘关系和元数据管理，话不多说，直接上图：
04. 结语
对于数仓而言，模型就是命脉，好与坏直接决定企业数据存储、处理和应用。
对于维度建模，真正理解了粒度和一致性维度，也就理解了维度建模的魂。
对于建模工具，没有最好只有更好，适合业务的就是最好的。
漫谈数仓第三篇NO.3 『数据魔法』ETL
本文目录 CONTENTS
☞ ETL同步之道 [ Sqoop、DataX、Kettle、Canal、StreamSets ]
☞ ETL之技术栈 [ 重工具 vs 开发语言 ]
☞ ETL加载策略 [ Merge、Delta、拉链 ]
ETL，是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。
ETL工具或类ETL的数据集成同步工具或语言，企业生产中工具也非常之多，主流的etl工具有Sqoop、DataX、Canal、flume、Logstash、kettle、DataStage、Informatica、Talend等，语言有强悍的SQL、Shell、Python、Java、Scala等。而数据源多为业务系统，埋点日志，离线文件，第三方数据等。
数据同步之道
01. sqoop
Sqoop，SQL-to-Hadoop 即 “SQL到Hadoop和Hadoop到SQL”。
是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。主要用于在Hadoop与关系型数据库之间进行数据转移，可以将一个关系型数据库（MySQL ,Oracle等）中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导出到关系型数据库中。
sqoop命令的本质是转化为MapReduce程序。sqoop分为导入（import）和导出（export），策略分为table和query，模式分为增量和全量。
命令简单示例：
02. DataX
DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。
github地址：https://github.com/alibaba/DataX
支持数据源：
DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader+Writer插件，纳入到整个同步框架中。
目前已到datax3.0框架设计：
datax使用示例，核心就是编写json配置文件job：
03. kettle
Kettle，中文名：水壶，是一款国外免费开源的、可视化的、功能强大的ETL工具，纯java编写，可以在Windows、Linux、Unix上运行，数据抽取高效稳定。
Kettle家族目前包括4个产品：Spoon、Pan、CHEF、Kitchen。
Kettle的最大特点：
- 免费开源：基于Java免费开源软件
- 易配置：可跨平台，绿色无需安装
- 不同数据库：ETL工具集，可管理不同数据库的数据
- 两种脚本文件：transformation和job，transformation完成针对数据的基础转换，job则完成整个工作流的控制
- 图形界面设计：托拉拽，无需写代码
- 定时功能：在Job下的start模块，有一个定时功能，可以每日，每周等方式进行定时
04. canal
canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据实时订阅和消费，目前主要支持了MySQL，也支持mariaDB。
很多大型的互联网项目生产环境中使用，包括阿里、美团等都有广泛的应用，是一个非常成熟的数据库同步方案，基础的使用只需要进行简单的配置即可。
github地址：https://github.com/alibaba/canal
当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x
canal是通过模拟成为mysql 的slave的方式，监听mysql 的binlog日志来获取数据，binlog设置为row模式以后，不仅能获取到执行的每一个增删改的脚本，同时还能获取到修改前和修改后的数据，基于这个特性，canal就能高性能的获取到mysql数据数据的变更。
05. StreamSets
Streamsets是一个大数据实时采集ETL工具，可以实现不写一行代码完成数据的采集和流转。通过拖拽式的可视化界面，实现数据管道(Pipelines)的设计和定时任务调度。
数据源支持MySQL、Oracle等结构化和半/非结构化，目标源支持HDFS、Hive、Hbase、Kudu、Solr、Elasticserach等。创建一个Pipelines管道需要配置数据源(Origins)、操作(Processors)、目的地(Destinations)三部分。
Streamsets的强大之处：
- 拖拽式可视化界面操作，No coding required 可实现不写一行代码
- 强大整合力，100+ Ready-to-Use Origins and Destinations，支持100+数据源和目标源
- 可视化内置调度监控，实时观测数据流和数据质量
二、ETL之技术栈
2.1 工具
重工具，kettle、DataStage、Informatica 三大工具依旧牢牢稳固传统数仓三大主力位置。kettle与时俱进，在大数据数仓，如一些互联网公司也有在使用kettle。
工具本文不再多做介绍。
2.2 语言
开发语言，传统数仓一般SQL/Shell为主，互联网数仓又对Python、Java、Scala提出了新的要求。
不管是传统数仓，还是基于Hadoop生态的构建的(hive、spark、flink)数仓，SQL虽然戏码在下降，但依然是重头戏。强大的存储过程，更是屹立不倒，这么多年都在熠熠生辉。
善于发现的你，一定会发现，在大数据生态，不管哪种数据处理框架，总有一天都会孵化出强大SQL的支持。如Hive SQL，Spark SQL，Blink SQL 等。此时，你或许会得出一个结论：
SQL是最好的语言！****（不接受反驳。****。）
对于SQL，基本技能也是必备技能。
各种join、嵌套/标量子查询，强大的分析/窗口函数，变化无穷的正则表达式，层次查询，扩展分组，MODEL，递归with，多维分析，排列组合，行列互转，json解析，执行计划，四大类型(dql、dml、ddl、dcl)等，依然需要每个etl·er熟悉掌握。
SQLjoin，left/rignt/full join，每一个join都是暗藏韵理，on和where也不容小觑。
分析函数 简捷高效，4类30+个分析/窗口函数最全总结，感兴趣的同学请移步：SQL分析函数，看这一篇就够了 （点击链接即可）。
SQL开发规范和执行计划也需要每个erl·er在实际实践中不断加强、提炼、升级。
SQL开发规范 示例：
如果你还在传统数仓领域，如果你还想将薪比薪，建议赶紧开始学Java、scala，拥抱大数据生态Hadoop/Spark/Flink，机会总是垂青有准备的人。
三、ETL加载策略
数据集成加载策略，按类型可包括快照、流水、增量、全量、拉链等。
01. 增量
有些表巨大，我们需要选择增量策略，新增delta数据需要和存量数据merge合并。欣赏并学习两种处理方式，直接上图，可斟酌体会：
（如果看图不能理解，来数仓ers群里，加入高手如云，我们一起探讨！加小助微：iom1128，备注：ETL）
Merge方式（一）
图片来源于《阿里巴巴大数据之路》
Merge方式（二）
1）只有新增数据
2）新增+删除
图片来源于《美团技术》
02. 全量
每天一个全量表，也可一个分区一个全量。
03. 拉链
拉链表，记录数据生命周期，记录一条数据生命周期的开始和结束。
建议在设计拉链表的时候不仅要有开始时间和结束时间，最好再加一个生命状态字段，如chain_status：有效 active、失效 expired、历史 history。
回想一下前面文章介绍的缓慢变化维，可类比SCD的TYPE2，有异曲同工之处
全量拉链，或许会存在性能问题，故建议根据实际业务场景中进行取舍，可只和最近一个时间周期(eg:1个月)的进行拉链处理。
漫谈数仓第四篇NO.4 『数据应用』（BI&OLAP）
数据应用，是真正体现数仓价值的部分，包括且又不局限于 数据可视化、BI、OLAP、即席查询，实时大屏，用户画像，推荐系统，数据分析，数据挖掘，人脸识别，风控反欺诈等等。
数据仓库架构图
本文侧重于数据应用之BI可视化和OLAP。
一、BI可视化工具
1、1 BI现状
大数据时代商业智能（BI）和数据可视化诉求更为强烈，淘宝大屏更是风靡全球！数据可视化是大数据『最后一公里』。
BI唤醒沉睡的数据。
传统型BI力求大而全的统一综合型报表和分析平台，侧重传统式报表开发，俨然一把屠龙刀。现互联网公司快速迭代的业务发展，需要的却是倚天剑，促使自助式BI和敏捷BI得以迅速发展。
时代召唤，传统BI巨头也逐渐向自助式BI和云BI转型。一时间，BI数据可视化已呈现出”百家争鸣，群雄争霸”的态势！
1、2 BI分类
统看业界可视化BI工具可大致分为：开源bi，商业bi，和传统重bi工具。
业界目前比较流行的开源bi工具有Superset、metabase、Redash、Cboard、Spagobi等，商业bi工具有帆软、tableau、PowerBI、SmartBI、QlinkView、QuickBI等，传统企业、传统数仓，大多依然沿用重bi产品，如Congos、BIEE、BO、MicroStrategydeng等。
详细每一款bi工具，我们前面文章有详细介绍。如果你感兴趣，或正在调研开BI工具选型，可移步：大数据可视化BI工具，呕血总结，通幽洞微（点击链接即可跳转）
二、OLAP基本操作和类型
OLAP，On-Line Analytical Processing，在线分析处理，主要用于支持企业决策管理分析。区别于OLTP，On-Line Transaction Processing，联机事务处理。
OLAP的优势：丰富的数据展现方式、高效的数据查询以及多视角多层次的数据分析。
数据仓库与OLAP的关系是互补的，现代OLAP系统一般以数据仓库作为基础，即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。
2、1 OLAP基本操作：
OLAP的多维分析操作包括：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot）。
★钻取：维的层次变化，从粗粒度到细粒度，汇总数据下钻到明细数据。如通过季度销售数据钻取每个月的销售数据
★上卷：钻取的逆，向上钻取。从细粒度到粗粒度，细粒度数据到不同维层级的汇总。eg. 通过每个月的销售数据汇总季度、年销售数据
★切片：特定维数据（剩余维两个）。eg. 只选电子产品销售数据
★切块：维区间数据（剩余维三个）。eg. 第一季度到第二季度销售数据
★旋转：维位置互换（数据行列互换），通过旋转可以得到不同视角的数据。
2、2 OLAP分类：
OLAP按存储器的数据存储格式分为ROLAP（Relational OLAP）、MOLAP（Multi-dimensional OLAP）和 HOLAP（Hybrid OLAP）。
- MOLAP，基于多维数组的存储模型，也是OLAP最初的形态，特点是对数据进行预计算，以空间换效率，明细和聚合数据都保存在cube中。但生成cube需要大量时间和空间。
- ROLAP，完全基于关系模型进行存储数据，不需要预计算，按需即时查询。明细和汇总数据都保存在关系型数据库事实表中。
- HOLAP，混合模型，细节数据以ROLAP存放，聚合数据以MOLAP存放。这种方式相对灵活，且更加高效。可按企业业务场景和数据粒度进行取舍，没有最好，只有最适合。
三、OLAP数据库选型
在大数据数仓架构中，离线以Hive为主，实时计算一般是Spark+Flink配合，消息队列Kafka一家独大，后起之秀Pulsar想要做出超越难度很大，Hbase、Redis和MySQL都在特定场景下有一席之地。
唯独在OLAP领域，百家争鸣，各有所长。
OLAP引擎/工具/数据库，技术选型可有很多选择，传统公司大多以Congos、Oracle、MicroStrategy等OLAP产品，互联网公司则普遍强势拥抱开源，如
Presto，Druid ，Impala，SparkSQL，AnalyticDB，(Hbase)Phoenix，kudu， Kylin，Greenplum，Clickhouse, Hawq, Drill，ES等
在数据架构时，可以说目前没有一个引擎能在数据量，灵活程度和性能上（吞吐和并发）做到完美，用户需要根据自己的业务场景进行选型。
开源技术选型，MOLAP可选Kylin、Druid，ROLAP可选Presto、impala等
Presto
Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，基于内存的低延迟高并发并行计算（mpp），适用于交互式分析查询。
首先我们先来看一下Presto官方的介绍：
- ☆ 本身并不存储数据，但是可以接入多种数据源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等
- ☆ 完全支持ANSI SQL标准，用户可以直接使用 ANSI SQL 进行数据查询和计算
- ☆ 可以混合多个catalog进行join查询和计算，支持跨数据源的级联查询
- ☆ 基于PipeLine进行设计的，流水管道式数据处理，支持数据规模GB~PB，计算中拿出一部分放在内存、计算、抛出、再拿。
-
☆ SQL on Hadoop：弥补Hive的效率性能和灵活性的不足，Presto和Spark SQL、Impala有很多异曲同工之处。
presto架构（master+slaver模式）：
Presto应用场景：
Druid
Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。
数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。
Druid架构
基本特点
Apache Druid 具有以下特点：
- 亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
- 实时的数据消费，真正做到数据摄入实时、查询结果实时。
- 高效的多租户能力，最高可以做到几千用户同时在线查询。
- 扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
- 极高的高可用保障，支持滚动升级。
应用场景
实时数据分析是 Apache Druid 最典型的使用场景。该场景涵盖的面很广，例如：
- 实时指标监控
- 推荐模型
- 广告平台
- 搜索模型
Druid也有很多不足需要注意，由于druid属于时间存储，删除操作比较繁琐，且不支持查询条件删除数据，只能根据时间范围删除数据。Druid能接受的数据的格式相对简单，比如不能处理嵌套结构的数据。
Druid案例
知乎：技术选型上，知乎根据不同业务场景选择了HBase 和 Redis 作为实时指标的存储引擎，在OLAP选型上，知乎选择了Druid。
OPPO：而OPPO根据自身不同的业务场景，报表层选择了Druid，标签选择了ES，接口层选择了Hbase。
Kylin
Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。
kylin特性：
- 可扩展超快olap引擎，Hadoop/Spark上百亿数据规模
- 提供 Hadoop ANSI SQL 接口
-
交互式查询能力，用户可以与Hadoop数据进行亚秒级交互
-
百亿以上数据集构建多维立方体（MOLAP CUBE）
- 与BI工具无缝整合，如Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和SuperSet
kylin生态圈：
Clickhouse
Clickhouse是一个用于在线分析处理（OLAP）的列式数据库管理系统（DBMS）。
是由俄罗斯的Yandex公司为了Yandex Metrica网络分析服务而开发。它支持分析实时更新的数据，Clickhouse以高性能著称。
先看一下官方定义：
ClickHouse is a column-oriented database management system (DBMS) for online analytical processing of queries (OLAP).
场景特征：
- 大多数是读请求
- 数据总是以相当大的批(> 1000 rows)进行写入
- 不修改已添加的数据
- 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
- 宽表，即每个表包含着大量的列
- 较少的查询(通常每台服务器每秒数百个查询或更少)
- 对于简单查询，允许延迟大约50毫秒
- 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
- 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
- 事务不是必须的
- 对数据一致性要求低
- 每一个查询除了一个大表外都很小
- 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中
clickhouse自身限制：
- 不支持真正的删除/更新支持 不支持事务
- 不支持二级索引
- 有限的SQL支持，join实现与众不同
- 不支持窗口功能
- 元数据管理需要人工干预维护
ClickHouse开源的出现让许多想做大数据并且想做大数据分析的很多公司和企业耳目一新。ClickHouse 正是以不依赖Hadoop 生态、安装和维护简单、查询速度快、可以支持SQL等特点在大数据分析领域披荆斩棘越走越远。
ADB（AnalyticDB for MySQL）
分析型数据库MySQL版（AnalyticDB for MySQL），是阿里巴巴自主研发的海量数据实时高并发在线分析（Realtime OLAP）云计算服务，使得您可以在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索。
adb优势和特性
- 超大规模：极致弹性轻松扩展至PB级规模
- 简单易用：全面兼容MySQL协议和BI工具
- 实时化分析：通过实时同步，报表延时1分钟内
- 查询速度快：传统关系型数据库的5-10倍性能
基于adb实时数仓架构
通过数据传输服务DTS（Data Transmission Service），您可以将RDS for MySQL同步到AnalyticDB for MySQL，帮助您快速构建企业内部BI、交互查询、实时报表等系统。
adb数据化链路架构
四、数据挖掘
分类、聚类、预测、关联
本文不多做介绍，对于这一块，后面会专门写一篇文章介绍。
五、本文结束语
☆☞ 对于数据架构，不管是数据仓库、数据湖，还是数据中台，数据应用才是数据价值体现所在
☆☞ 对于可视化BI工具，通幽洞微，建议熟练掌握2-3款即可，理解工具思想和实现方式
☆☞ 对于OLAP数据库，没有一个引擎能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。
参考资料：
https://help.aliyun.com/document_detail/72987.html
http://kylin.apache.org/cn/
https://clickhouse.yandex/
https://clickhouse.yandex/docs/zh/
[外]-分析型数据库AnalyticDB产品白皮书