├── .nojekyll ├── 02~数据集成 ├── Canal │ ├── 架构机制.md │ ├── README.md │ └── 部署与配置.md ├── Debezium.md ├── README.md ├── DataPipeline │ ├── 数据转换与检索.md │ ├── 一致性语义.md │ ├── 运行环境与引擎.md │ ├── 数据汇集层.md │ ├── README.md │ └── 数据源监听.md └── ETL │ └── README.md ├── 04~数据可视化 ├── 可视化开发库 │ └── D3 │ │ ├── 交互反馈 │ │ └── README.md │ │ ├── 图表示例 │ │ └── README.md │ │ ├── 数据操作 │ │ └── README.md │ │ └── README.md ├── 数据与图表类别 │ ├── 关联类.md │ ├── 平面比较类.md │ ├── 韦恩图.md │ ├── README.md │ ├── 柱状比较类.md │ └── 数据类别.md ├── 图形语法 │ └── README.md ├── 探索分析 │ ├── 数据透视表.md │ └── README.md ├── 多维数据可视化 │ ├── 可视化过程.md │ └── README.md ├── BI 工具 │ └── 99~参考资料 │ │ └── 2022-吐血测评九款 BI 工具，BI 选型就看这篇.md ├── 可视化基础 │ └── README.md └── README.md ├── 10~OLAP ├── 02.MOLAP │ ├── Kylin │ │ └── README.md │ ├── Druid │ │ └── README.md │ └── HBase │ │ ├── 架构分析.md │ │ ├── CRUD.md │ │ └── 部署与使用.md ├── 03.ROLAP │ ├── Hive │ │ ├── README.md │ │ ├── 文件类型与存储格式.md │ │ ├── 数据类型.md │ │ └── 表操作.md │ ├── Presto │ │ ├── README.md │ │ └── 部署与控制.md │ ├── StarRocks │ │ ├── README.md │ │ └── 99~参考资料 │ │ │ └── 2022-10 分钟带你全面了解 StarRocks！.md │ ├── ClickHouse │ │ ├── 99~参考资料 │ │ │ ├── 2022-陈峰-ClickHouse 架构及源码解析 │ │ │ │ └── README.md │ │ │ └── 2023-ClickHouse 从入门到放弃 │ │ │ │ └── README.md │ │ └── README.md │ ├── QuickSQL │ │ └── README.md │ └── Sqoop │ │ └── 介绍与部署.md ├── 01.引擎架构 │ ├── 99~参考资料 │ │ ├── 2020-Kylin、Druid、ClickHouse核心技术对比.md │ │ └── 2021-常用引擎对比与概述.md │ ├── 03.引擎操作 │ │ └── README.md │ ├── 01.MPP │ │ ├── README.md │ │ └── 99~参考资料 │ │ │ └── 2022-MPP 架构、常见 OLAP 引擎分析.md │ └── 02.建模类型划分 │ │ ├── README.md │ │ ├── 01.MOLAP.md │ │ └── 02.ROLAP.md ├── README.md └── 10.实践案例 │ └── 2021-贝壳 OLAP 平台架构演进.md ├── 03~数仓建模 ├── 05~元数据管理 │ ├── README.md │ └── Amundsen.md ├── 02~多维数据模型 │ ├── 01~事实表、维度表、聚合表 │ │ ├── README.md │ │ ├── 03~聚合表.md │ │ ├── 01~事实表.md │ │ └── 02~维度表.md │ ├── README.md │ ├── 03~数据立方体 │ │ └── README.md │ └── 02~星型与雪花模型 │ │ ├── 99~参考资料 │ │ └── 2021-数据仓库系列：星型模型和雪花型模型.md │ │ └── README.md ├── 03~数仓搭建流程 │ ├── README.md │ ├── 01~数仓分层架构 │ │ └── 数仓分层.md │ ├── 02~事实表设计 │ │ └── README.md │ ├── 03~维度表设计 │ │ └── README.md │ └── 99~参考资料 │ │ ├── 2022-园陌-做数仓必须搞明白的各种名词及关系，吐血整理.md │ │ └── 2021-数据产品小 Lee-数据仓库基础.md ├── 04~指标体系 │ └── README.md ├── 01~Kimball 与 Inmon │ ├── Kimball.md │ └── README.md └── README.md ├── 01~大数据体系 ├── 03~数据组织方式 │ ├── 02~数据仓库 │ │ └── README.md │ ├── README.md │ ├── 05~数据网格 │ │ └── README.md │ ├── 04~数据中台 │ │ ├── README.md │ │ ├── 数据栈.md │ │ └── 评价维度.md │ └── 03~数据湖 │ │ └── README.md ├── 01~大数据生态 │ ├── 99~参考资料 │ │ └── 2021-数据库领域投资总结.md │ ├── 大数据生态圈.md │ ├── README.md │ ├── 大数据的未来.md │ ├── 大数据平台.md │ ├── 数据的特性.md │ └── 不作恶.md ├── README.md ├── 02~数据治理原则 │ ├── 数据零散化.md │ └── 原则与要素.md ├── 04~数据中心 │ ├── README.md │ └── 云数据中心.md └── 99~参考资料 │ └── 2022-一文读懂数据仓库、数据平台、数据中台、数据湖的概念和区别.md ├── 99~参考资料 └── 《Designing Data-Intensive Application》 │ ├── 《DDIA 逐章精读》 │ └── README.md │ └── 原书翻译 │ ├── 01~数据系统基础 │ └── README.md │ └── README.md ├── .gitignore ├── README.md ├── index.html └── _sidebar.md /.nojekyll: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /02~数据集成/Canal/架构机制.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /04~数据可视化/可视化开发库/D3/交互反馈/README.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /04~数据可视化/可视化开发库/D3/图表示例/README.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /04~数据可视化/可视化开发库/D3/数据操作/README.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /04~数据可视化/数据与图表类别/关联类.md: -------------------------------------------------------------------------------- 1 | # 关联类 2 | -------------------------------------------------------------------------------- /10~OLAP/02.MOLAP/Kylin/README.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/Hive/README.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/Presto/README.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /03~数仓建模/05~元数据管理/README.md: -------------------------------------------------------------------------------- 1 | # 元数据管理 2 | -------------------------------------------------------------------------------- /04~数据可视化/图形语法/README.md: -------------------------------------------------------------------------------- 1 | # 图形语法 2 | -------------------------------------------------------------------------------- /04~数据可视化/探索分析/数据透视表.md: -------------------------------------------------------------------------------- 1 | # 数据透视表 2 | -------------------------------------------------------------------------------- /03~数仓建模/02~多维数据模型/01~事实表、维度表、聚合表/README.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /04~数据可视化/数据与图表类别/平面比较类.md: -------------------------------------------------------------------------------- 1 | # 平面比较类图表 2 | -------------------------------------------------------------------------------- /01~大数据体系/03~数据组织方式/02~数据仓库/README.md: -------------------------------------------------------------------------------- 1 | # 数据仓库 2 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/StarRocks/README.md: -------------------------------------------------------------------------------- 1 | # StarRocks 2 | -------------------------------------------------------------------------------- /01~大数据体系/01~大数据生态/99~参考资料/2021-数据库领域投资总结.md: -------------------------------------------------------------------------------- 1 | # Todos 2 | 3 | - https://zhuanlan.zhihu.com/p/452628664 -------------------------------------------------------------------------------- /01~大数据体系/README.md: -------------------------------------------------------------------------------- 1 | # 大数据体系 2 | 3 | # Links 4 | 5 | - https://mp.weixin.qq.com/s/gaYCcBOycQTlTq8zeIrYQg 6 | -------------------------------------------------------------------------------- /04~数据可视化/数据与图表类别/韦恩图.md: -------------------------------------------------------------------------------- 1 | # 韦恩图 2 | 3 | # Links 4 | 5 | - https://zhuanlan.zhihu.com/p/83759111 圆形韦恩图的 3 种布局算法 6 | -------------------------------------------------------------------------------- /03~数仓建模/03~数仓搭建流程/README.md: -------------------------------------------------------------------------------- 1 | # 数据仓库搭建流程 2 | 3 | # Links 4 | 5 | - https://mp.weixin.qq.com/s/TuT0Ob9fFqTOHEFMSDJ3Hg 一文教你如何搭建数据仓库 -------------------------------------------------------------------------------- /03~数仓建模/03~数仓搭建流程/01~数仓分层架构/数仓分层.md: -------------------------------------------------------------------------------- 1 | # Links 2 | 3 | - https://juejin.cn/post/6969874734355841031 详解数仓中的数据分层：ODS、DWD、DWM、DWS、ADS 4 | -------------------------------------------------------------------------------- /03~数仓建模/04~指标体系/README.md: -------------------------------------------------------------------------------- 1 | # 指标体系 2 | 3 | # Links 4 | 5 | - https://mp.weixin.qq.com/s/byRl62YmmbEAnauM6ht7CQ 网易传媒数据指标体系建设实践 6 | -------------------------------------------------------------------------------- /01~大数据体系/03~数据组织方式/README.md: -------------------------------------------------------------------------------- 1 | # 数据组织方式 2 | 3 | ![不同的数据组织方式](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230622211757.png) 4 | -------------------------------------------------------------------------------- /04~数据可视化/多维数据可视化/可视化过程.md: -------------------------------------------------------------------------------- 1 | # 多维数据可视化过程 2 | 3 | 多维数据可视化依托于[多维数据模型](https://github.com/wx-chevalier/Database-Notes/search?unscoped_q=多维数据模型)。 4 | -------------------------------------------------------------------------------- /99~参考资料/《Designing Data-Intensive Application》/《DDIA 逐章精读》/README.md: -------------------------------------------------------------------------------- 1 | > [原文地址](https://github.com/DistSysCorp/ddia/tree/main) 2 | 3 | # 精读 4 | -------------------------------------------------------------------------------- /03~数仓建模/01~Kimball 与 Inmon/Kimball.md: -------------------------------------------------------------------------------- 1 | # Kimball 2 | 3 | # Links 4 | 5 | - https://zhuanlan.zhihu.com/p/265954615 基于 Flink+ClickHouse 打造轻量级点击流实时数仓 作为案例提取 6 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/ClickHouse/99~参考资料/2022-陈峰-ClickHouse 架构及源码解析/README.md: -------------------------------------------------------------------------------- 1 | # ClickHouse 架构及源码解析 2 | 3 | # Links 4 | 5 | - https://www.zhihu.com/column/c_1384650064271351808 6 | -------------------------------------------------------------------------------- /10~OLAP/01.引擎架构/99~参考资料/2020-Kylin、Druid、ClickHouse核心技术对比.md: -------------------------------------------------------------------------------- 1 | # Kylin、Druid、ClickHouse 核心技术对比 2 | 3 | # Links 4 | 5 | - https://blog.csdn.net/u013256816/article/details/108271371 6 | -------------------------------------------------------------------------------- /03~数仓建模/05~元数据管理/Amundsen.md: -------------------------------------------------------------------------------- 1 | # Amundsen 2 | 3 | 数据科学家将大量时间花在数据发现上，这意味着在这一领域能够提供帮助的工具势必会令人兴奋。尽管 Apache Atlas 项目已经成为了元数据管理的实际工具，但数据发现仍然不是那么容易完成的。Amundsen 可以与 Apache Atlas 协同部署，为数据发现提供更好的搜索界面。 4 | -------------------------------------------------------------------------------- /04~数据可视化/BI 工具/99~参考资料/2022-吐血测评九款 BI 工具，BI 选型就看这篇.md: -------------------------------------------------------------------------------- 1 | # Links 2 | 3 | - 吐血测评九款 BI 工具，BI 选型就看这篇（Tableau vs PowerBI vs superset vs DataEase vs ……） https://zhuanlan.zhihu.com/p/543473848?utm_id=0 4 | -------------------------------------------------------------------------------- /04~数据可视化/数据与图表类别/README.md: -------------------------------------------------------------------------------- 1 | # 图表 2 | 3 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230503195821.png) 4 | 5 | # Links 6 | 7 | - https://antv.alipay.com/zh-cn/vis/chart/index.html 8 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/ClickHouse/99~参考资料/2023-ClickHouse 从入门到放弃/README.md: -------------------------------------------------------------------------------- 1 | # ClickHouse 从入门到放弃 2 | 3 | # Links 4 | 5 | - https://developer.aliyun.com/article/1129023?spm=a2c6h.12873639.article-detail.142.63dbdfaaKSJHfD 6 | -------------------------------------------------------------------------------- /04~数据可视化/探索分析/README.md: -------------------------------------------------------------------------------- 1 | # 探索分析 2 | 3 | 探索分析是 BI 领域重要的研究方向之一，随着信息量的激增，业务数据的维度，大小，关联关系逐渐变得愈加复杂，使得即便是拥有多年经验的业务人员，也无法探知数据中蕴藏的全部规律、模式与领域知识。由此带来设计开发对应的探索分析系统，使得用户能够快速的从庞大的数据集中筛选自己关心的数据、选择关心的维度与度量来研究验证某一猜想假设，得出可以指导决策的有效结论。 4 | -------------------------------------------------------------------------------- /03~数仓建模/02~多维数据模型/01~事实表、维度表、聚合表/03~聚合表.md: -------------------------------------------------------------------------------- 1 | # 聚合表 2 | 3 | 数据是按照最详细的格式存储在事实表中，各种报表可以充分利用这些数据。一般的查询语句在查询事实表时，一次操作经常涉及成千上万条记录，但是通过使用汇总、平均、极值等聚合技术可以大大降低数据的查询数量。因此，来自事实表中的底层数据应该事先经过聚合存储在中间表中。中间表存储了聚合信息，所以被称为聚合表，这种处理过程被称为聚合过程。 4 | -------------------------------------------------------------------------------- /02~数据集成/Debezium.md: -------------------------------------------------------------------------------- 1 | # Debezium 2 | 3 | Debezium 是一个变更数据捕获（Change Data Capture, CDC）平台，可以将数据库变更流式传输到 Kafka 的 topics。CDC 是一种流行的技术，具有多种应用场景，例如：将数据复制到其他数据库、输送数据给分析系统、从单体中提取数据至微服务以及废除缓存。Debezium 对数据库日志文件中的变更做出反应，并具有多个 CDC 连接器，适用于多种数据库，其中包括 Postgres、MySQL、Oracle 和 MongoDB。 4 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/QuickSQL/README.md: -------------------------------------------------------------------------------- 1 | # QuickSQL 2 | 3 | 随着业务的不断增多，为满足不同场景下对计算时延和吞吐的需求，各式各样的数据源大显身手。然而，由于不同数据源的发展历程不同，迭代速度不一，无法向用户提供统一的数据处理范式。且数据源所处介质天然隔离，交叉关联分析阻碍重重，导致数据人员要为此承担高额的学习和分析成本。 4 | 5 | # Links 6 | 7 | - https://mp.weixin.qq.com/s/DBcGC1ViNlIda0u9pr7djQ 8 | -------------------------------------------------------------------------------- /01~大数据体系/03~数据组织方式/05~数据网格/README.md: -------------------------------------------------------------------------------- 1 | # 数据网格 2 | 3 | 在管理大量分析数据方面，[Data Mesh](https://martinfowler.com/articles/data-monolith-to-mesh.html) 标志着架构和组织范式的一种可喜转变。该范式建立在四个原则之上： 4 | 5 | (1) 数据所有权和架构的面向领域去中心化; 6 | (2) 将面向领域的数 据视为产品; 7 | (3) 将自助数据基础设施作为平台，支持自治且面向领域的数据团队; 8 | (4) 联合控制以实现生态系统和互操作性。 9 | 10 | 尽管这些原则很直观，并且只是试图解决以前集中分析数据管理的许多已知挑战，它们仍胜过了现有的分析数据技术。 11 | -------------------------------------------------------------------------------- /04~数据可视化/可视化基础/README.md: -------------------------------------------------------------------------------- 1 | # 可视化基础 2 | 3 | # Links 4 | 5 | - https://mp.weixin.qq.com/s?__biz=MzIzMTc4NzIyNw==&mid=2247489265&idx=1&sn=690c1bb677ed107e75d51841d22af5d5&chksm=e89f8945dfe80053270c1b0b9e4ec560de35353a7c05d4975ce57d0eba93ecb42d7280523c7d&mpshare=1&scene=1&srcid=0817pEMgQlcpvg4rRFT0GYuH&sharer_sharetime=1629203025146&sharer_shareid=ab27ca96b5bf5b0b51edd5a0f67fd6c7#rd vivo官网 Web 3D 实战 -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/ClickHouse/README.md: -------------------------------------------------------------------------------- 1 | # ClickHouse 2 | 3 | 数据处理现在还是分为 OLTP 和 OLAP。OLTP（在线事务处理）优化的方向是高并发、高可用，是精确，是各种增删改查。所以面临和解决的问题都是怎么解决高并发下的增删改查，怎么解决脏读、脏写，保证数据一致性等问题。 4 | 5 | OLAP（在线分析处理）的优化方向则是高速数据处理能力、高速读取能力。一般又分为两个优化方向，一个是预先计算好各个维度的数据，存成 CUBE，分析的时候直接查询结果就行，这是 MOLAP（Multidimensional OLAP，多维在线分析处理），典型代表的是 Kylin。一个是结构化存好，然后用尽各种方法优化，分析的时候拼命计算，这是 ROLAP（Relational OLAP，关系型在线分析处理），典型代表就是 ClickHouse 了。 6 | -------------------------------------------------------------------------------- /02~数据集成/README.md: -------------------------------------------------------------------------------- 1 | # 数据集成 2 | 3 | 多个不同数据系统（可能有着不同数据模型，并针对不同的访问模式进行优化）集成为一个协调一致的应用架构时，集成不同的系统是实际应用中最重要的事情之一。例如，为了处理任意关键词的搜索查询，将 OLTP 数据库与全文搜索索引集成在一起是很常见的的需求。尽管一些数据库（例如 PostgreSQL）包含了全文索引功能，对于简单的应用完全够了，但更复杂的搜索能力就需要专业的信息检索工具了。相反的是，搜索索引通常不适合作为持久的记录系统，因此许多应用需要组合这两种不同的工具以满足所有需求。随着数据不同表示形式的增加，集成问题变得越来越困难。除了数据库和搜索索引之外，也许你需要在分析系统（数据仓库，或批处理和流处理系统）中维护数据副本；维护从原始数据中衍生的缓存，或反规范化的数据版本；将数据灌入机器学习，分类，排名，或推荐系统中；或者基于数据变更发送通知。 4 | -------------------------------------------------------------------------------- /10~OLAP/README.md: -------------------------------------------------------------------------------- 1 | # OLAP 2 | 3 | ![OLTP ETL OLAP](https://pic.imgdb.cn/item/6185f7a92ab3f51d9175a4cc.jpg) 4 | 5 | OLAP（On-line Analytical Processing，联机分析处理）是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的 OLTP（On-line Transaction Processing，联机事务处理）的区别来看一下它的特点： 6 | 7 | ![OLAP 与 OLTP 对比](https://pic.imgdb.cn/item/6185f7fd2ab3f51d91761ae1.jpg) 8 | 9 | OLAP 的优势是基于数据仓库面向主题、集成的、保留历史及不可变更的数据存储，以及多维模型多视角多层次的数据组织形式，如果脱离的这两点，OLAP 将不复存在，也就没有优势可言。 10 | -------------------------------------------------------------------------------- /02~数据集成/DataPipeline/数据转换与检索.md: -------------------------------------------------------------------------------- 1 | # 数据转换与检索 2 | 3 | 数据转换是一个业务性很强的处理步骤。当数据进入汇集层后，一般会用于两个典型的后继处理场景：数仓构建和数据流服务。数仓构建包括模型定义和预计算两部分。数据工程师根据业务分析需要，使用星型或雪花模型设计数据仓库结构，利用数据仓库中间件完成模型构建和更新。 4 | 5 | 如前文所述，源端采集的数据建议放入一个汇集层，优选是类似 Kafka 这样的消息队列。包括 Kylin 和 Druid 在内的数据仓库可以直接以流式的方式消费数据进行更新。一种常见的情形为：原始采集的数据格式、粒度不一定满足数据仓库中表结构的需要，而数仓提供的配置灵活度可能又不足够。这种情况下需要在进入数仓前对数据做额外的处理。 6 | 7 | 常见的处理包括过滤、字段替换、嵌套结构一拆多、维度填充等，以上皆为无状态的转换。有状态的转换，例如 SUM、COUNT 等，在此过程中较少被使用，因为数仓本身就提供了这些聚合能力。数据流服务的构建则是基于流式计算引擎，对汇集层的数据进一步加工计算，并将结果实时输出给下游应用系统。 8 | -------------------------------------------------------------------------------- /02~数据集成/Canal/README.md: -------------------------------------------------------------------------------- 1 | # Canal 2 | 3 | 数据抽取是 ETL 流程的第一步。我们会将数据从 RDBMS 或日志服务器等外部系统抽取至数据仓库，进行清洗、转换、聚合等操作。在现代网站技术栈中，MySQL 是最常见的数据库管理系统，我们会从多个不同的 MySQL 实例中抽取数据，存入一个中心节点，或直接进入 Hive。市面上已有多种成熟的、基于 SQL 查询的抽取软件，如著名的开源项目 Apache Sqoop，然而这些工具并不支持实时的数据抽取。MySQL Binlog 则是一种实时的数据流，用于主从节点之间的数据复制，我们可以利用它来进行数据抽取。借助阿里巴巴开源的 Canal 项目，我们能够非常便捷地将 MySQL 中的数据抽取到任意目标存储中。 4 | 5 | 简单来说，Canal 会将自己伪装成 MySQL 从节点（Slave），并从主节点（Master）获取 Binlog，解析和贮存后供下游消费端使用。Canal 包含两个组成部分：服务端和客户端。服务端负责连接至不同的 MySQL 实例，并为每个实例维护一个事件消息队列；客户端则可以订阅这些队列中的数据变更事件，处理并存储到数据仓库中。 6 | -------------------------------------------------------------------------------- /02~数据集成/Canal/部署与配置.md: -------------------------------------------------------------------------------- 1 | # Canal 部署与配置 2 | 3 | # 单机部署 4 | 5 | MySQL 默认没有开启 Binlog，因此我们需要对 my.cnf 文件做以下修改： 6 | 7 | ```cnf 8 | server-id = 1 9 | log_bin = /path/to/mysql-bin.log 10 | binlog_format = ROW 11 | ``` 12 | 13 | 注意 binlog_format 必须设置为 ROW, 因为在 STATEMENT 或 MIXED 模式下, Binlog 只会记录和传输 SQL 语句（以减少日志大小），而不包含具体数据，我们也就无法保存了。从节点通过一个专门的账号连接主节点，这个账号需要拥有全局的 REPLICATION 权限。我们可以使用 GRANT 命令创建这样的账号： 14 | 15 | ```sql 16 | GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON _._ TO 'canal'@'%' IDENTIFIED BY 'canal'; 17 | ``` 18 | -------------------------------------------------------------------------------- /04~数据可视化/多维数据可视化/README.md: -------------------------------------------------------------------------------- 1 | # 多维数据可视化 2 | 3 | 多维关系型数据库的可视化研究一直是 BI 开发中的基础领域，该领域的主要挑战是如何将数据库中的知识呈现出来，发现规律、异常并理解数据间的关系。由此，诞生了基于假设、猜想对数据库进行探索分析的需求。这种探索分析的特性是对于结果、方法与步骤的不确定性，同时要求快速改变用户研究的数据视图以及观察这些视图的方式的能力[2]。 4 | 5 | 常见的方式是将这样的一个多维的关系型数据库视为一个多维的数据立方体(cube)，这种方式最知名的实践之一便是数据透视表，但数据透视表在数据的直观展示能力上非常欠缺。 6 | 7 | ![从数据源到渲染](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230420133356.png) 8 | 9 | # Links 10 | 11 | - http://lobay.moe/2019/06/17/GoG/canary-base-theory/#%E5%8F%AF%E8%A7%86%E5%8C%96%E8%BF%87%E7%A8%8B 12 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/StarRocks/99~参考资料/2022-10 分钟带你全面了解 StarRocks！.md: -------------------------------------------------------------------------------- 1 | > [原文地址](https://zhuanlan.zhihu.com/p/532302941) 2 | 3 | # 10 分钟带你全面了解 StarRocks！ 4 | 5 | StarRocks 是一款极速全场景 MPP 企业级数据库产品，具备水平在线扩缩容，金融级高可用，兼容 MySQL 5.7 协议和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查询等重要特性。StarRocks 致力于在全场景 OLAP 业务上为用户提供统一的解决方案，适用于对性能，实时性，并发能力和灵活性有较高要求的各类应用场景。接下来会从三个方面来剖析 StarRocks 的能力与特点： 6 | 7 | - 首先我们先来看一下 StarRocks 是一款什么样的数据库，他的产品定位是什么样的，他处于大数据生态什么位置上 8 | - 接下来我们详细的看一下 StarRocks 的功能与特性，了解一下为什么说 StarRocks 是一款全场景的 MPP 数据库 9 | - 最后我们通过解读一些基准测试的性能报测试告，看一下 StarRocks 的性能优势如何 10 | 11 | # OLAP 数仓挑战 12 | -------------------------------------------------------------------------------- /10~OLAP/01.引擎架构/03.引擎操作/README.md: -------------------------------------------------------------------------------- 1 | # OLAP 引擎的常见操作 2 | 3 | ![OLAP 引擎的常见操作](https://pic.imgdb.cn/item/6185fe852ab3f51d917ddb8f.jpg) 4 | 5 | 下面所述几种 OLAP 操作，是针对 Kimball 的星型模型（Star Schema）和雪花模型（Snowflake Schema）来说的。在 Kimball 模型中，定义了事实和维度。 6 | 7 | - 上卷（Roll Up）/聚合：选定某些维度，根据这些维度来聚合事实，如果用 SQL 来表达就是 select dim_a, aggs_func(fact_b) from fact_table group by dim_a. 8 | - 下钻（Drill Down）：上卷和下钻是相反的操作。它是选定某些维度，将这些维度拆解出小的维度（如年拆解为月，省份拆解为城市），之后聚合事实。 9 | - 切片（Slicing、Dicing）：选定某些维度，并根据特定值过滤这些维度的值，将原来的大 Cube 切成小 cube。如 dim_a in ('CN', 'USA') 10 | - 旋转（Pivot/Rotate）：维度位置的互换。 11 | 12 | ![OLAP 数据常见操作](https://pic.imgdb.cn/item/61862f132ab3f51d91c2e978.jpg) 13 | -------------------------------------------------------------------------------- /99~参考资料/《Designing Data-Intensive Application》/原书翻译/01~数据系统基础/README.md: -------------------------------------------------------------------------------- 1 | # [第一部分：数据系统基础](https://vonng.github.io/ddia/#/part-i?id=第一部分：数据系统基础) 2 | 3 | 本书前四章介绍了数据系统底层的基础概念，无论是在单台机器上运行的单点数据系统，还是分布在多台机器上的分布式数据系统都适用。 4 | 5 | 1. [第一章](https://vonng.github.io/ddia/#/ch1) 将介绍本书使用的术语和方法。**可靠性，可伸缩性和可维护性** ，这些词汇到底意味着什么？如何实现这些目标？ 6 | 2. [第二章](https://vonng.github.io/ddia/#/ch2) 将对几种不同的 **数据模型和查询语言** 进行比较。从程序员的角度看，这是数据库之间最明显的区别。不同的数据模型适用于不同的应用场景。 7 | 3. [第三章](https://vonng.github.io/ddia/#/ch3) 将深入 **存储引擎** 内部，研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化，选择合适的存储引擎对系统性能有巨大影响。 8 | 4. [第四章](https://vonng.github.io/ddia/#/ch4) 将对几种不同的 **数据编码** 进行比较。特别研究了这些格式在应用需求经常变化、模式需要随时间演变的环境中表现如何。 9 | 10 | 第二部分将专门讨论在 **分布式数据系统** 中特有的问题。 11 | -------------------------------------------------------------------------------- /03~数仓建模/03~数仓搭建流程/02~事实表设计/README.md: -------------------------------------------------------------------------------- 1 | ## 事实表 2 | 3 | 事实表产生于业务过程，存储了业务活动或事件提炼出来的性能度量。从最低的粒度级别来看，事实表的一个行对应一个度量事件。 4 | 5 | 事实表根据粒度的角色划分，可分为 事务事实表、周期快照事实表、累计快照事实表。 6 | 7 | > 需要注意的是，同一张表里的粒度必须相同，以上三种表不能混用。 8 | 9 | 1. **事务事实表** 10 | 11 | 用于承载事务数据，通常粒度比较低。它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表。例如商品交易事实表、用户充值事实表。 12 | 13 | 2. **周期快照事实表** 14 | 15 | 按照一定的时间周期间隔来捕捉业务活动的执行情况。两个关键字：`周期`、`快照`，简单说就是粒度比较粗事务事实表的定期快照。一旦装入事实表就不会再更新，它是事务事实表的补充。用来记录有规律、固定时间间隔的业务累计数据，通常粒度比较高。例如账户的月平均余额事实表、年商品销售额。 16 | 17 | 3. **累计快照事实表** 18 | 19 | 累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。 20 | 21 | 累积快照事实表记录的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点，一个生命周期对应一行。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。 22 | -------------------------------------------------------------------------------- /03~数仓建模/02~多维数据模型/README.md: -------------------------------------------------------------------------------- 1 | # 多维数据模型 2 | 3 | 在 OLAP 中，我们通常会通过 Schema 来定义一个多维数据库，它是一个逻辑概念上的模型，其中包含 Cube（立方体）、Dimension（维度）、Hierarchy（层次）、Level（级别）、Measure（度量），这些被映射到数据库物理模型。 4 | 5 | - Cube（立方体）是一系列 Dimension 和 Measure 的集合区域，它们共用一个事实表。 6 | 7 | - Dimension（维度）是一个 Hierarchy 的集合，维度一般有其相对应的维度表，它由 Hierarchy（层次）组成，而 Hierarchy（层次）又是由组成 Level（级别）的。 8 | 9 | - Hierarchy（层次）是指定维度的层级关系的，如果没有指定，默认 Hierarchy 里面装的是来自立方体中的真实表。 10 | 11 | - Level（级别）是 Hierarchy 的组成部分，使用它可以构成一个结构树，Level 的先后顺序决定了 Level 在结构树上的位置，最顶层的 Level 位于树的第一级，依次类推。 12 | 13 | - Measure（度量）是我们要进行度量计算的数值，支持的操作有 sum、count、avg、distinct-count、max、min 等。 14 | 15 | 概括总结一下：在多维分析中，关注的内容通常被称为度量(Measure)，而把限制条件称为维度(Dimension)。多维分析就是对同时满足多种限制条件的所有度量值做汇总统计。包含度量值的表被称为事实表(Fact Table)，描述维度具体信息的表被称为维表(Dimension Table)，同时有一点需要注意：并不是所有的维度都要有维表，对于取值简单的维度，可以直接使用事实表中的一列作为维度展示。 16 | -------------------------------------------------------------------------------- /10~OLAP/10.实践案例/2021-贝壳 OLAP 平台架构演进.md: -------------------------------------------------------------------------------- 1 | # Links 2 | 3 | - https://sctrack.sendcloud.net/track/click/eyJuZXRlYXNlIjogImZhbHNlIiwgIm1haWxsaXN0X2lkIjogMCwgInRhc2tfaWQiOiAiIiwgImVtYWlsX2lkIjogIjE2MTkxNzY0NzU4NDJfMTg3XzYwNDA0XzY2MDAuc2MtMTBfOV82XzE4MS1pbmJvdW5kMCQzODQ5MjQ1NTJAcXEuY29tIiwgInNpZ24iOiAiZjhkNjJjZTU3NDI0ZjhhMGRkYzE0MDBkNTBkNTFjNmMiLCAidXNlcl9oZWFkZXJzIjoge30sICJsYWJlbCI6ICI2MTkyMDMwIiwgInRyYWNrX2RvbWFpbiI6ICJzY3RyYWNrLnNlbmRjbG91ZC5uZXQiLCAicmVhbF90eXBlIjogIiIsICJsaW5rIjogImh0dHBzJTNBLy92aXAubWFub25nLmlvL2JvdW5jZSUzRm5pZCUzRDUwJTI2YWlkJTNEMjA3MSUyNnVybCUzRGh0dHBzJTI1M0ElMjUyRiUyNTJGdG91dGlhby5pbyUyNTJGayUyNTJGaTJsNm1tMCUyNm4lM0RNVE15Ljcwa3lyQmNnSXU4c0lkeWdYMThFWFFkUkVhSSIsICJvdXRfaXAiOiAiMTA2Ljc1LjguODkiLCAiY29udGVudF90eXBlIjogIjAiLCAidXNlcl9pZCI6IDE4NywgIm92ZXJzZWFzIjogImZhbHNlIiwgImNhdGVnb3J5X2lkIjogNjAzNDl9.html 贝壳 OLAP 平台架构演进 -------------------------------------------------------------------------------- /03~数仓建模/03~数仓搭建流程/03~维度表设计/README.md: -------------------------------------------------------------------------------- 1 | ## 维度表 2 | 3 | 维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，它里面的数据就是一些日，周，月，季，年，日期等数据，维度表只能是事实表的一个分析角度。 4 | 5 | #### 维度表的设计步骤 6 | 7 | 1. 完成维度的初步定义，并保证维度的一致性。 8 | 2. 确定主维表（中心事实表）。此处的主维表通常是数据引入层（ODS）表，直接与业务系统同步。例如，s_auction 是与前台商品中心系统同步的商品表，此表即是主维表。 9 | 3. 确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、卖家、店铺等维度存在关联关系。 10 | 4. 确定维度属性，主要包括两个阶段。第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。以商品维度为例，从主维表(s_auction)和类目、卖家、店铺等相关维表中选择维度属性或生成新的维度属性。 11 | 12 | 维度表常涉及到两种概念：`退化维度`和`缓慢变化维度` 13 | 14 | 1. **退化维度** 15 | 16 | 退化维度不是维度，它表示一种针对维度展现的方法。在实际开发中，经常遇到在一些事实表频繁使用的维度，比如订单表中的用户信息、商品信息。为了使用方便，这些维度信息便可以直接放到事实表中，毕竟对于目前大数据来讲，存储成本还是很低的，这种设计就称为退化维度。 17 | 18 | 2. **缓慢变化维** 19 | 20 | 维度并不是保持不变，它会随着业务的发展而发生改动。这种随着时间发生变化的维度称为缓慢变化维。 21 | -------------------------------------------------------------------------------- /01~大数据体系/01~大数据生态/大数据生态圈.md: -------------------------------------------------------------------------------- 1 | # 大数据与其他技术 2 | 3 | # 云计算 4 | 5 | 说到这里，我们要回答一个很多人心里都存在的疑惑——大数据和云计算之间，到底有什么关系？ 6 | 可以这么解释：数据本身是一种资产，而云计算，则是为挖掘资产价值提供合适的工具。 7 | 8 | 从技术上，大数据是依赖于云计算的。云计算里面的海量数据存储技术、海量数据管理技术、分布式计算模型等，都是大数据技术的基础。 9 | 10 | 云计算就像是挖掘机，大数据就是矿山。如果没有云计算，大数据的价值就发挥不出来。 11 | 12 | 相反的，大数据的处理需求，也刺激了云计算相关技术的发展和落地。 13 | 14 | 也就是说，如果没有大数据这座矿山，云计算这个挖掘机，很多强悍的功能都发展不起来。 15 | 16 | 套用一句老话——云计算和大数据，两者是相辅相成的。 17 | 18 | # 大数据与物联网 19 | 20 | 第二个问题，大数据和物联网有什么关系？ 21 | 22 | 这个问题我觉得大家应该能够很快想明白，前面其实也提到了。 23 | 24 | 物联网就是“物与物互相连接的互联网”。物联网的感知层，产生了海量的数据，将会极大地促进大数据的发展。 25 | 26 | 同样，大数据应用也发挥了物联网的价值，反向刺激了物联网的使用需求。越来越多的企业，发觉能够通过物联网大数据获得价值，就会愿意投资建设物联网。 27 | 28 | 其实这个问题也可以进一步延伸为“大数据和 5G 之间的关系”。 29 | 30 | 即将到来的 5G，通过提升连接速率，提升了“人联网”的感知，也促进了人类主动创造数据。 31 | 32 | 另一方面，它更多是为“物联网”服务的。包括低延时、海量终端连接等，都是物联网场景的需求。 33 | 34 | 5G 刺激物联网的发展，而物联网刺激大数据的发展。所有通信基础设施的强大，都是为大数据崛起铺平道路。 35 | -------------------------------------------------------------------------------- /01~大数据体系/02~数据治理原则/数据零散化.md: -------------------------------------------------------------------------------- 1 | # 数据离散化 2 | 3 | 数据资源平台（数据中台）作为城市大脑一部分，起着业务数据底座的重要作用，在整个城市大脑中，数据资源平台处于一个相对较底层的位置，需要为上层业务提供了有力的数据、算法、数据服务等支撑。数据资源平台包含工具平台、内容平台两大部分，其中最核心的部分是数据内容了数据资源平台（数据中台）作为城市大脑一部分，起着业务数据底座的重要作用，在整个城市大脑中，数据资源平台处于一个相对较底层的位置，需要为上层业务提供了有力的数据、算法、数据服务等支撑。数据资源平台包含工具平台、内容平台两大部分，其中最核心的部分是数据内容。在梳理数据层过程中，我们可能的困难是： 4 | 5 | 1、数据多而广，数据散落，城市底数不清晰。 6 | 7 | 政府数据涉及的面很广，量很大，但是无法直观的讲清楚到底有哪些数据，条目情况，数据更新情况。没有一个清晰的数据资产盘点，就无法有效的使用数据。市里面没用数据清单，数据散落在各个业务系统，也没有人清楚业务系统的数据，业务人员只管用系统，数据摸底十分困难。 8 | 9 | 2、数据共享错综复杂，未融合。 10 | 11 | 政务领域的数据共享情况，一般有两类，一是基于政务畅通工程的共享，将部分重要的数据表项在畅通工程中进行编目，并提供基于库表交换的共享，本质上按需分发式的共享。二是委办局间的点对点共享，由需求方和供给方自行协商数据的交换共享。这两种方式共同的问题是数据共享的广度和深度都不够，数据也未经过整理融合，是浅层次的数据共享。 12 | 13 | 3、多部门数据有冲突的情况。 14 | 15 | 不同的委办局间，因为业务侧重点、数据采集时效、数据口径不同等种种原因，存在着数据相互打架的情况，如个人的家庭住址的信息，在公安、人社、民政等口子的数据存在登记地址不一致的情况。 16 | 17 | # Links 18 | 19 | - https://parg.co/hPH 20 | -------------------------------------------------------------------------------- /02~数据集成/ETL/README.md: -------------------------------------------------------------------------------- 1 | # ETL 2 | 3 | 随着企业应用复杂性的上升和微服务架构的流行，数据正变得越来越以应用为中心。服务之间仅在必要时以接口或者消息队列方式进行数据交互，从而避免了构建单一数据库集群来支撑不断增长的业务需要。以应用为中心的数据持久化架构，在带来可伸缩性好处的同时，也给数据的融合计算带来了障碍。 4 | 5 | 由于数据散落在不同的数据库、消息队列、文件系统中，计算平台如果直接访问这些数据，会遇到可访问性和数据传输延迟等问题。在一些场景下，计算平台直接访问应用系统数据库会对系统吞吐造成显著影响，通常也是不被允许的。因此，在进行跨应用的数据融合计算时，首先需要将数据从孤立的数据源中采集出来，汇集到可被计算平台高效访问的目的地，此过程被称为 ETL，即数据的抽取（Extract）、转换（Transform）和加载（Load）。 6 | 7 | # 离线 ETL 与实时 ETL 8 | 9 | 该领域的传统公司，例如 Informatica，早在 1993 年就已经成立，并且提供了成熟的商业化解决方案。开源工具，例如 Kettle、DataX 等，在很多企业中也得到了广泛的应用。传统上，ETL 是通过批量作业完成的。即定期从数据源加载（增量）数据，按照转换逻辑进行处理，并写入目的地。根据业务需要和计算能力的不同，批量处理的延时通常从天到分钟级不等。在一些应用场景下，例如电子商务网站的商品索引更新，ETL 需要尽可能短的延迟，这就出现了实时 ETL 的需求。 10 | 11 | 在实时 ETL 中，数据源和数据目的地之间仿佛由管道连接在一起。数据从源端产生后，以极低的延迟被采集、加工，并写入目的地，整个过程没有明显的处理批次边界，因此实时 ETL 又被称为 Data Pipeline 模式。 12 | 13 | ![](https://tva1.sinaimg.cn/large/007rAy9hgy1g3spmmv2sij30u00gtq3l.jpg) 14 | -------------------------------------------------------------------------------- /04~数据可视化/数据与图表类别/柱状比较类.md: -------------------------------------------------------------------------------- 1 | # 柱状比较类图表 2 | 3 | # Bullet Graph | 子弹图 4 | 5 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510140055.png) 6 | 7 | 子弹图的样子很像子弹射出后带出的轨道，所以称为子弹图。子弹图的发明是为了取代仪表盘上常见的那种里程表，时速表等基于圆形的信息表达方式。子弹图的特点如下： 8 | 9 | - 每一个单元的子弹图只能显示单一的数据信息源 10 | - 通过添加合理的度量标尺可以显示更精确的阶段性数据信息 11 | - 通过优化设计还能够用于表达多项同类数据的对比 12 | - 可以表达一项数据与不同目标的校对结果 13 | 14 | 子弹图无修饰的线性表达方式使我们能够在狭小的空间中表达丰富的数据信息，线性的信息表达方式与我们习以为常的文字阅读相似，相对于圆形构图的信息表达，在信息传递上有更大的效能优势。 15 | 16 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510140111.png) 17 | 18 | 下图是一个模拟商铺一段时间内的经营情况的数据，一共 5 条数据，分别代表收入（单位：千美元）、利率（单位：％）、平均成交额（单位：美元）、新客户（单位：个）和满意度（1-5）五个方面，每个方面都有代表好、中、差的 3 个范围和预先设定的目标。 19 | 20 | | title | ranges | actual | target | subtitle | 21 | | ------- | ------------- | ------ | ------ | ------------------ | 22 | | Revenue | [150,225,300] | 270 | 250 | US\$, in thousands | 23 | | ... | ... | ... | ... | ... | 24 | 25 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510140132.png) 26 | -------------------------------------------------------------------------------- /02~数据集成/DataPipeline/一致性语义.md: -------------------------------------------------------------------------------- 1 | # 一致性语义 2 | 3 | 批量同步需要以一种事务性的方式完成同步，无论是同步一整块的历史数据，还是同步某一天的增量，该部分数据到目的地，必须是以事务性的方式出现的。而不是在同步一半时，数据就已经在目的地出现了，这可能会影响下游的一些计算逻辑。并且作为一个数据融合产品，当用户在使用 DataPipeline 时，通常需要将存量数据同步完，后面紧接着去接增量。然后存量与增量之间需要进行一个无缝切换，中间的数据不要丢、也不要多。 4 | 5 | DataPipeline 作为一个产品，在客户的环境中，我们无法对客户数据本身的特性提出强制要求。我们不能要求客户数据一定要有主键或者有唯一性的索引。所以在不同场景下，对于一致性语义保证，用户的要求也不一样的：比如在有主键的场景下，一般我们做到至少有一次就够了，因为在下游如果对方也是一个类似于关系型数据库这样的目的地，其本身就有去重能力，不需要在过程中间做一个强一致的保证。但是，如果其本身没有主键，或者其下游是一个文件系统，如果不在过程中间做额外的一致性保证，就有可能在目的地产生多余的数据，这部分数据对于下游可能会造成非常严重的影响。 6 | 7 | # 数据一致性的链路视角 8 | 9 | - 在源端做一个一致性抽取，即当数据从通过数据连接器写入到 MQ 时，和与其对应的 offset 必须是以事务方式进入 MQ 的。 10 | 11 | - 一致性处理，譬如 Flink 提供了一个端到端一致性处理的能力，它是内部通过 checkpoint 机制，并结合 Sink 端的二阶段提交协议，实现从数据读取处理到写入的一个端到端事务一致性。其它框架，例如 Spark Streaming 和 Kafka Streams 也有各自的机制来实现一致性处理。 12 | 13 | - 一致性写入，在 MQ 模式下，一致性写入，即 consumer offset 跟实际的数据写入目的时，必须是同时持久化的，要么全都成功，要么全部失败。 14 | 15 | - 一致性衔接，在 DataPipeline 的产品应用中，历史数据与实时数据的传输有时需要在一个任务中共同完成。所以产品本身需要有这种一致性衔接的能力，即历史数据和流式数据，必须能够在一个任务中，由程序自动完成它们之间的切换。 16 | 17 | # Links 18 | 19 | - https://mp.weixin.qq.com/s/Ws0hy3XY6Bry4AmsMBjOiw 20 | -------------------------------------------------------------------------------- /03~数仓建模/01~Kimball 与 Inmon/README.md: -------------------------------------------------------------------------------- 1 | # Kimball 与 Inmon 2 | 3 | Kimball 和 Inmon 是两种主流的数据仓库方法论，分别由 Ralph Kimbal 大神 和 Bill Inmon 大神提出，在实际数据仓库建设中，业界往往会相互借鉴使用两种开发模式。本文将详细介绍 Kimball 和 Inmon 理论在实际数据仓库建设中的应用与对比,通过数据仓库理论武装数据仓库实践。 4 | 5 | # Kimball 6 | 7 | Kimball 模式从流程上看是是自底向上的，即从数据集市到数据仓库再到数据源(先有数据集市再有数据仓库)的一种敏捷开发方法。对于 Kimball 模式，数据源往往是给定的若干个数据库表，数据较为稳定但是数据之间的关联关系比较复杂，需要从这些 OLTP 中产生的事务型数据结构抽取出分析型数据结构，再放入数据集市中方便下一步的 BI 与决策支持。 8 | 9 | 通常，Kimball 都是以最终任务为导向。首先，在得到数据后需要先做数据的探索，尝试将数据按照目标先拆分出不同的表需求。其次，在明确数据依赖后将各个任务再通过 ETL 由 Stage 层转化到 DM 层。这里 DM 层数据则由若干个事实表和维度表组成。接着，在完成 DM 层的事实表维度表拆分后，数据集市一方面可以直接向 BI 环节输出数据了，另一方面可以先 DW 层输出数据，方便后续的多维分析。 10 | 11 | Kimball 往往意味着快速交付、敏捷迭代，不会对数据仓库架构做过多复杂的设计，在变换莫测的互联网行业，这种架构方式逐渐成为一种主流范式。 12 | 13 | # Inmon 14 | 15 | Inmon 模式从流程上看是自顶向下的，即从数据源到数据仓库再到数据集市的（先有数据仓库再有数据市场）一种瀑布流开发方法。对于 Inmon 模式，数据源往往是异构的，比如从自行定义的爬虫数据就是较为典型的一种，数据源是根据最终目标自行定制的。这里主要的数据处理工作集中在对异构数据的清洗，包括数据类型检验，数据值范围检验以及其他一些复杂规则。在这种场景下，数据无法从 stage 层直接输出到 dm 层，必须先通过 ETL 将数据的格式清洗后放入 dw 层，再从 dw 层选择需要的数据组合输出到 dm 层。在 Inmon 模式中，并不强调事实表和维度表的概念，因为数据源变化的可能性较大，需要更加强调数据的清洗工作，从中抽取实体-关系。 16 | 17 | 通常，Inmon 都是以数据源头为导向。首先，需要探索性地去获取尽量符合预期的数据，尝试将数据按照预期划分为不同的表需求。其次，明确数据的清洗规则后将各个任务通过 ETL 由 Stage 层转化到 DW 层，这里 DW 层通常涉及到较多的 UDF 开发，将数据抽象为实体-关系模型。接着，在完成 DW 的数据治理之后，可以将数据输出到数据集市中做基本的数据组合。最后，将数据集市中的数据输出到 BI 系统中去辅助具体业务。 18 | -------------------------------------------------------------------------------- /03~数仓建模/02~多维数据模型/03~数据立方体/README.md: -------------------------------------------------------------------------------- 1 | # Data Cube 2 | 3 | 数据仓库的另一个值得一提的是物化汇总。如前所述，数据仓库查询通常涉及一个聚合函数，如 SQL 中的 COUNT，SUM，AVG，MIN 或 MAX。如果相同的聚合被许多不同的查询使用，那么每次都可以通过原始数据来处理。为什么不缓存一些查询使用最频繁的计数或总和？创建这种缓存的一种方式是物化视图。在关系数据模型中，它通常被定义为一个标准（虚拟）视图：一个类似于表的对象，其内容是一些查询的结果。不同的是，物化视图是查询结果的实际副本，写入磁盘，而虚拟视图只是写入查询的捷径。从虚拟视图读取时，SQL 引擎会将其展开到视图的底层查询中，然后处理展开的查询。 4 | 5 | 当底层数据发生变化时，物化视图需要更新，因为它是数据的非规范化副本。数据库可以自动完成，但是这样的更新使得写入成本更高，这就是在 OLTP 数据库中不经常使用物化视图的原因。在读取繁重的数据仓库中，它们可能更有意义（不管它们是否实际上改善了读取性能取决于个别情况）。 6 | 7 | 物化视图的常见特例称为数据立方体或 OLAP 立方。它是按不同维度分组的聚合网格。Data Cube 的直观理解，即是对于数据不同维度组合而成的某个指标。 8 | 9 | ![数据立方的两个维度，通过求和聚合](https://s2.ax1x.com/2020/02/06/1ywg0K.md.png) 10 | 11 | 想象一下，现在每个事实都只有两个维度表的外键：在图中，这些是日期和产品。您现在可以绘制一个二维表格，一个轴线上的日期和另一个轴上的产品。每个单元包含具有该日期 - 产品组合的所有事实的属性（例如，net_price）的聚集（例如，SUM）。然后，您可以沿着每行或每列应用相同的汇总，并获得一个维度减少的汇总（按产品的销售额，无论日期，还是按日期销售，无论产品如何）。 12 | 13 | 一般来说，事实往往有两个以上的维度，譬如：日期，产品，商店，促销和客户。要想象一个五维超立方体是什么样子是很困难的，但是原理是一样的：每个单元格都包含特定日期（产品-商店-促销-客户）组合的销售。这些值可以在每个维度上重复概括。 14 | 15 | 物化数据立方体的优点是某些查询变得非常快，因为它们已经被有效地预先计算了。例如，如果您想知道每个商店的总销售额，则只需查看合适维度的总计，无需扫描数百万行。 16 | 17 | 缺点是数据立方体不具有查询原始数据的灵活性。例如，没有办法计算哪个销售比例来自成本超过 100 美元的项目，因为价格不是其中的一个维度。因此，大多数数据仓库试图保留尽可能多的原始数据，并将聚合数据（如数据立方体）仅用作某些查询的性能提升。 18 | 19 | # 指标 20 | 21 | 某个指标包含三个部分：时间修饰、维度（Dimension）以及原子词/度量（Measure）。 22 | 23 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230424144427.png) 24 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Ignore all 2 | * 3 | 4 | # Unignore all with extensions 5 | !*.* 6 | 7 | # Unignore all dirs 8 | !*/ 9 | 10 | .DS_Store 11 | 12 | # Logs 13 | logs 14 | *.log 15 | npm-debug.log* 16 | yarn-debug.log* 17 | yarn-error.log* 18 | 19 | # Runtime data 20 | pids 21 | *.pid 22 | *.seed 23 | *.pid.lock 24 | 25 | # Directory for instrumented libs generated by jscoverage/JSCover 26 | lib-cov 27 | 28 | # Coverage directory used by tools like istanbul 29 | coverage 30 | 31 | # nyc test coverage 32 | .nyc_output 33 | 34 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 35 | .grunt 36 | 37 | # Bower dependency directory (https://bower.io/) 38 | bower_components 39 | 40 | # node-waf configuration 41 | .lock-wscript 42 | 43 | # Compiled binary addons (https://nodejs.org/api/addons.html) 44 | build/Release 45 | 46 | # Dependency directories 47 | node_modules/ 48 | jspm_packages/ 49 | 50 | # TypeScript v1 declaration files 51 | typings/ 52 | 53 | # Optional npm cache directory 54 | .npm 55 | 56 | # Optional eslint cache 57 | .eslintcache 58 | 59 | # Optional REPL history 60 | .node_repl_history 61 | 62 | # Output of 'npm pack' 63 | *.tgz 64 | 65 | # Yarn Integrity file 66 | .yarn-integrity 67 | 68 | # dotenv environment variables file 69 | .env 70 | 71 | # next.js build output 72 | .next 73 | -------------------------------------------------------------------------------- /10~OLAP/01.引擎架构/01.MPP/README.md: -------------------------------------------------------------------------------- 1 | # MPP 2 | 3 | 数仓构建包括模型定义和预计算两部分，数据工程师根据业务分析需要，使用星型或雪花模型设计数据仓库结构，利用数据仓库中间件完成模型构建和更新。一个普遍的共识是，没有一个 OLAP 引擎能同时在数据量，灵活性和性能这三个方面做到完美，用户需要基于自己的需求进行取舍和选型。预计算模式的 OLAP 引擎在查询响应时间上相较于 MPP 引擎（Impala、SparkSQL、Presto 等）有一定优势，但相对限制了灵活性。 4 | 5 | MPP 即大规模并行处理（Massively Parallel Processor）。在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据 库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。 6 | 7 | ![MPP 架构](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230407224442.png) 8 | 9 | ## 案例 10 | 11 | - Greenplum 是一种基于 PostgreSQL 的分布式数据库。其采用 shared nothing 架构（MPP），主机，操作系统，内存，存储都是自我控制的，不存在共享。也就是每个节点都是一个单独的数据库。节点之间的信息交互是通过节点互联网络实现。通过将数据分布到多个节点上来实现规模数据的存储，通过并行查询处理来提高查询性能。这个就像是把小数据库组织起来，联合成一个大型数据库。将数据分片，存储在每个节点上。每个节点仅查询自己的数据。所得到的结果再经过主节点处理得到最终结果。通过增加节点数目达到系统线性扩展。 12 | 13 | - ElasticSearch 也是一种 MPP 架构的数据库，Presto、Impala 等都是 MPP engine，各节点不共享资源，每个 executor 可以独自完成数据的读取和计算，缺点在于怕 stragglers，遇到后整个 engine 的性能下降到该 straggler 的能力，所谓木桶的短板，这也是为什么 MPP 架构不适合异构的机器，要求各节点配置一样。Spark SQL 应该还是算做 Batching Processing, 中间计算结果需要落地到磁盘，所以查询效率没有 MPP 架构的引擎（如 Impala）高。 14 | 15 | ## 预计算/预聚合 16 | 17 | 开源领域，Apache Kylin 是预聚合模式 OLAP 代表，支持从 HIVE、Kafka、HDFS 等数据源加载原始表数据，并通过 Spark/MR 来完成 CUBE 构建和更新。 18 | 19 | Druid 则是另一类预聚合 OLAP 的代表。在 Druid 的表结构模型中，分为时间列、维度列和指标列，允许对任意指标列进行聚合计算而无需定义维度数量。Druid 在数据存储时便可对数据进行聚合操作，这使得其更新延迟可以做到很低。在这些方面，Baidu 开源的 Palo 和 Druid 有类似之处。 20 | -------------------------------------------------------------------------------- /03~数仓建模/02~多维数据模型/01~事实表、维度表、聚合表/01~事实表.md: -------------------------------------------------------------------------------- 1 | # 事实表 2 | 3 | 每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如现金登记事务。所产生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据(事实)，并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性纬度表的主键，而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。 4 | 5 | 包含在事实数据表中的“度量值”有两中：一种是可以累计的度量值，另一种是非累计的度量值。最有用的度量值是可累计的度量值，其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息，例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表，单汇总结果一般是没有意义的，例如，在一座大厦的不同位置测量温度时，如果将大厦中所有不同位置的温度累加是没有意义的，但是求平均值是有意义的。一般来说，一个事实数据表都要和一个或多个纬度表相关联，用户在利用事实数据表创建多维数据集时，可以使用一个或多个维度表。 6 | 7 | 一个按照州、产品和月份划分的销售量和销售额存储的事实表有 5 个列，概念上与下面的示例类似。 8 | 9 | | Sate | Product | Mouth | Units | Dollars | 10 | | ---- | ------------ | -------- | ----- | ------- | 11 | | WA | Mountain-100 | January | 3 | 7.95 | 12 | | WA | Cable Lock | January | 4 | 7.32 | 13 | | OR | Mountain-100 | January | 3 | 7.95 | 14 | | OR | Cable Lock | January | 4 | 7.32 | 15 | | WA | Mountain-100 | February | 16 | 42.40 | 16 | 17 | 在这些事实表的示例数据行中，前 3 个列——州、产品和月份——为键值列。剩下的两个列——销售额和销售量——为度量值。事实表中的每个列通常要么是键值列，要么是度量值列，但也可能包含其他参考目的的列——例如采购订单号或者发票号。事实表中，每个度量值都有一个列。不同事实表将有不同的度量值。一个销售数据仓库可能含有这两个度量值列：销售额和销售量。一个现场信息数据仓库可能包含 3 个度量值列：总量、分钟数和瑕疵数。创建报表时，可以认为度量值形成了一个额外的维度。即可以把销售额和销售量作为并列的列标题，或者也可以把它们作为行标题。然而在事实表中，每个度量值都作为一个单独的列显示。 18 | 19 | 事实表数据行中包含了您想从中获取度量值信息的最底层级别的明细。换句话说，事实表中对每个维度的最详细的项目成员都有数据行。如果有使用其他维度的度量，只要为那些度量和维度创建另一个事实表即可。数据仓库中可能包含拥有不同度量值和维度的不同事实表。 20 | 21 | 事实表前缀为 Fact。 22 | -------------------------------------------------------------------------------- /01~大数据体系/04~数据中心/README.md: -------------------------------------------------------------------------------- 1 | # 数据中心 2 | 3 | 数据中心是一个数据聚合应用，数据聚合的意思就是聚合来自各个来源的数据对外提供统一的服务，而且需要什么数据由你决定，不多不少，只要把 HSF 服务或者 HTTP 服务接入数据中心，你的服务就可以作为数据中心的一个数据源通过数据聚合的方式对方提供服务，如下图所示： 4 | 5 | ![数据源与消费者](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230424144405.png) 6 | 7 | 数据中心的定位是面向后端开发，当然也可以对前端提供 HTTP 服务，数据中心也有一些产品和运营在使用，他们经常通过数据中心查询一些基础数据，然后把字段告诉开发完成对接。 8 | 9 | 数据中心的优势是可以让一个不了解各个数据源开发细节的开发，产品甚至运营，直接通过可视化界面，采用勾选配置的方式，自动化直接聚合出灵活多变的业务数据，并支持异构数据源的装配。在业务多变，组织架构多变，数据来源多元的当下，数据中心可以说是一个强刚需的应用，它可以通过实时配置的方式，自动完成不同数据源的数据路由和装配，帮助技术快速响应需求变化，按需获取自己需要的数据，解放开发资源，并且通过数据的智能并行获取和流量控制，多级缓存优化，达到资源和性能的综合优化与利用。 10 | 11 | # 场景分析 12 | 13 | ## 适用场景 14 | 15 | - 数据多样。数据来源多样，你需要的数据来自多个 HSF 或者 Http 服务，这是数据中心的本源，优势就是数据聚合能力，比如会场数据展示就非常建议使用数据中心。 16 | 17 | - 数据拆分。有的数据源考虑到性能问题，会对调用的数据个数进行限制，比如 MKC 的营销接口，一次性最多只能传入 10 个商品 ID，如果数据量比较多的场景直接调用这种接口的话，你需要写数据拆分和多线程并发调用的代码，写起来费时费力，而且不一定有数据中心的写的好，数据中心对这种数据拆分做了很好的支持。 18 | 19 | - DT 数据。DT 都会将数据灌进 oneservice，然后对外提供服务，数据中心底层整合了 oneservice 常用的调用模型，对 oneservice 做了很好的支持，如果有新接入的指标，数据中心只需要增加配置字段，零开发即可直接使用。 20 | 21 | - 流量缓冲。如果你的服务扛不住流量，那么也可以考虑使用数据中心的缓存功能，一个配置即可搞定，有非常多的服务接入数据中心的目的就是用来做流量缓冲的，典型的就是 MKC 的营销活动服务，这个服务本身的流量就很大，面临大促这种场景的突发流量，需要上层进行一个缓冲。 22 | 23 | - 服务降级。这个跟上面的流量缓冲有点类似，但不一样的是，把入口步在数据中心之后，如果服务出现问题，不降级就可能挂掉，那么数据中心可以快速的进行降级，可以从调用方，单机并发量等维度进行快速降级，避免出现雪崩。 24 | 25 | ## 不适用场景 26 | 27 | 数据中心有比较完善的自我保护功能，如果数据源出现问题，会对其进行降级，所以下面几种场景不太适合使用数据中心。 28 | 29 | - RT 敏感。如果不需要数据聚合场景，而且对 RT 要求很高，建议直接调用数据服务，不建议通过数据中心进行一次中转。 30 | 31 | - 不接受降级。数据中心会对慢数据源进行降级，如果数据源不接受降级，或者降级会导致故障，不建议接入数据中心。 32 | 33 | - 交易系统。交易系统不建议使用数据中心，底层数据源出现问题，数据中心的降级很可能导致资损，引发故障。 34 | 35 | - RT 高。RT 高（100ms 以上）的系统接入数据中心，如果长期 RT 很高，一方面数据中心会对其降级，另外也会影响到数据中心的整体性能，所以 RT 比较高的数据源建议进行优化之后再接入。 36 | -------------------------------------------------------------------------------- /10~OLAP/01.引擎架构/02.建模类型划分/README.md: -------------------------------------------------------------------------------- 1 | # OLAP 分类 2 | 3 | ![OLAP 分类](https://pic.imgdb.cn/item/61862ffe2ab3f51d91c47c5a.jpg) 4 | 5 | OLAP 是一种让用户可以用从不同视角方便快捷的分析数据的计算方法。主流的 OLAP 可以分为 3 类：多维 OLAP (Multi-dimensional OLAP)、关系型 OLAP(Relational OLAP) 和混合 OLAP(Hybrid OLAP) 三大类。 6 | 7 | ## MOLAP 的优点和缺点 8 | 9 | MOLAP 的典型代表是：Druid，Kylin，Doris，MOLAP 一般会根据用户定义的数据维度、度量（也可以叫指标）在数据写入时生成预聚合数据；Query 查询到来时，实际上查询的是预聚合的数据而不是原始明细数据，在查询模式相对固定的场景中，这种优化提速很明显。 10 | 11 | MOLAP 的优点和缺点都来自于其数据预处理（pre-processing）环节。数据预处理，将原始数据按照指定的计算规则预先做聚合计算，这样避免了查询过程中出现大量的即使计算，提升了查询性能。但是这样的预聚合处理，需要预先定义维度，会限制后期数据查询的灵活性；如果查询工作涉及新的指标，需要重新增加预处理流程，损失了灵活度，存储成本也很高；同时，这种方式不支持明细数据的查询，仅适用于聚合型查询（如：sum，avg，count）。 12 | 13 | 因此，MOLAP 适用于查询场景相对固定并且对查询性能要求非常高的场景。如广告主经常使用的广告投放报表分析。 14 | 15 | ## ROLAP 的优点和缺点 16 | 17 | ROLAP 的典型代表是：Presto，Impala，GreenPlum，ClickHouse，Elasticsearch，Hive，Spark SQL，Flink SQL 18 | 19 | 数据写入时，ROLAP 并未使用像 MOLAP 那样的预聚合技术；ROLAP 收到 Query 请求时，会先解析 Query，生成执行计划，扫描数据，执行关系型算子，在原始数据上做过滤(Where)、聚合(Sum, Avg, Count)、关联(Join)，分组（Group By)、排序（Order By）等，最后将结算结果返回给用户，整个过程都是即时计算，没有预先聚合好的数据可供优化查询速度，拼的都是资源和算力的大小。 20 | 21 | ROLAP 不需要进行数据预处理（pre-processing），因此查询灵活，可扩展性好。这类引擎使用 MPP 架构（与 Hadoop 相似的大型并行处理架构，可以通过扩大并发来增加计算资源），可以高效处理大量数据。 22 | 23 | 但是当数据量较大或 query 较为复杂时，查询性能也无法像 MOLAP 那样稳定。所有计算都是即时触发（没有预处理），因此会耗费更多的计算资源，带来潜在的重复计算。 24 | 25 | 因此，ROLAP 适用于对查询模式不固定、查询灵活性要求高的场景。如数据分析师常用的数据分析类产品，他们往往会对数据做各种预先不能确定的分析，所以需要更高的查询灵活性。 26 | 27 | ## HOLAP 28 | 29 | 混合 OLAP，是 MOLAP 和 ROLAP 的一种融合。当查询聚合性数据的时候，使用 MOLAP 技术；当查询明细数据时，使用 ROLAP 技术。在给定使用场景的前提下，以达到查询性能的最优化。 30 | 31 | 顺便提一下，国内外有一些闭源的商业 OLAP 引擎，没有在这里归类和介绍，主要是因为使用的公司不多并且源码不可见、资料少，很难分析学习其中的源码和技术点。在一二线的互联网公司中，应用较为广泛的还是上面提到的各种 OLAP 引擎，如果你希望能够通过掌握一种 OLAP 技术，学习这些就够了。 32 | -------------------------------------------------------------------------------- /10~OLAP/01.引擎架构/02.建模类型划分/01.MOLAP.md: -------------------------------------------------------------------------------- 1 | # MOLAP 2 | 3 | 这应该算最传统的数仓了，1993 年 olap 概念提出来时，指的就是 MOLAP 数仓，M 即表示多维。大多数 MOLAP 产品均对原始数据进行预计算得到用户可能需要的所有结果，将其存储到优化过的多维数组中，也就是常听到的 数据立方体。 4 | 5 | 由于所有可能结果均已计算出来并持久化存储，查询时无需进行复杂计算，且以数组形式可以进行高效的免索引数据访问，因此用户发起的查询均能够稳定地快速响应。这些结果集是高度结构化的，可以进行压缩/编码来减少存储占用空间。 6 | 7 | 但高性能并不是没有代价的。首先，MOLAP 需要进行预计算，这会花去很多时间。如果每次写入增量数据后均要进行全量预计算，显然是低效率的，因此支持仅对增量数据进行迭代计算非常重要。其次，如果业务发生需求变更，需要进行预定模型之外新的查询操作，现有的 MOLAP 实例就无能为力了，只能重新进行建模和预计算。 8 | 9 | 在开源软件中，由 eBay 开发并贡献给 Apache 基金会的 Kylin 即属于这类 OLAP 引擎，支持在百亿规模的数据集上进行亚秒级查询。 10 | 11 | 下图是官方对 Kylin 的描述。 12 | 13 | ![Apache Kylin 概览](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230408135854.png) 14 | 15 | #### 代表 16 | 17 | - **Kylin**是完全的预计算引擎，通过枚举所有维度的组合，建立各种 Cube 进行提前聚合，以 HBase 为基础的 OLAP 引擎。 18 | - **Druid**则是轻量级的提前聚合(roll-up)，同时根据倒排索引以及 bitmap 提高查询效率的时间序列数据和存储引擎。 19 | 20 | #### 优点 21 | 22 | - **Kylin** 23 | 24 | 1. 支持数据规模超大(HBase) 25 | 2. 易用性强，支持标准 SQL 26 | 3. 性能很高，查询速度很快 27 | 28 | - **Druid** 29 | 30 | 1. 支持的数据规模大(本地存储+DeepStorage–HDFS) 31 | 2. 性能高，列存压缩，预聚合加上倒排索引以及位图索引，秒级查询 32 | 3. 实时性高，可以通过 kafka 实时导入数据 33 | 34 | #### 缺点 35 | 36 | - **Kylin** 37 | 38 | 1. 灵活性较弱，不支持 adhoc 查询；且没有二级索引，过滤时性能一般；不支持 join 以及对数据的更新。 39 | 2. 处理方式复杂，需要定义 Cube 预计算；当维度超过 20 个时，存储可能会爆炸式增长；且无法查询明细数据了；维护复杂。 40 | 3. 实时性很差，很多时候只能查询前一天或几个小时前的数据。 41 | 42 | - **Druid** 43 | 44 | 1. 灵活性适中，虽然维度之间随意组合，但不支持 adhoc 查询，不能自由组合查询，且丢失了明细数据。 45 | 2. 易用性较差，不支持 join，不支持更新，sql 支持很弱(有些插件类似于 pinot 的 PQL 语言)，只能 JSON 格式查询；对于去重操作不能精准去重。 46 | 3. 处理方式复杂，需要流处理引擎将数据 join 成宽表，维护相对复杂；对内存要求较高。 47 | 48 | #### 场景 49 | 50 | - **Kylin**：适合对实时数据需求不高，但响应时间较高的查询，且维度较多，需求较为固定的特定查询；而不适合实时性要求高的 adhoc 类查询。 51 | - **Druid**：数据量大，对实时性要求高且响应时间短，以及维度较少且需求固定的简单聚合类查询(sum，count，TopN)，多以 Storm 和 Flink 组合进行预处理；而不适合需要 join、update 和支持 SQL 和窗口函数等复杂的 adhoc 查询；不适合用于 SQL 复杂数据分析的场景。 52 | -------------------------------------------------------------------------------- /10~OLAP/02.MOLAP/Druid/README.md: -------------------------------------------------------------------------------- 1 | # Druid 2 | 3 | Druid 单词来源于西方古罗马的神话人物，中文常常翻译成德鲁伊。Druid 是一个分布式的支持实时分析的数据存储系统（Data Store）。美国广告技术公司 MetaMarkets 于 2011 年创建了 Druid 项目，并且于 2012 年晚期开源了 Druid 项目。Druid 设计之初的想法就是为分析而生，它在处理数据的规模、数据处理的实时性方面，比传统的 OLAP 系统有了显著的性能改进，而且拥抱主流的开源生态，包括 Hadoop 等。多年以来，Druid 一直是非常活跃的开源项目。 4 | 5 | # 背景分析 6 | 7 | ## 设计原则 8 | 9 | 在设计之初，开发人员确定了三个设计原则（Design Principle）。 10 | 11 | - 快速查询（Fast Query）：部分数据的聚合（Partial Aggregate）+内存化（In-emory）+索引（Index）。 12 | 13 | - 水平扩展能力（Horizontal Scalability）：分布式数据（Distributed Data）+ 并行化查询（Parallelizable Query）。 14 | 15 | - 实时分析（Realtime Analytics）：不可变的过去，只追加的未来（Immutable Past，Append-Only Future）。 16 | 17 | ### 快速查询（Fast Query） 18 | 19 | 对于数据分析场景，大部分情况下，我们只关心一定粒度聚合的数据，而非每一行原始数据的细节情况。因此，数据聚合粒度可以是 1 分钟、5 分钟、1 小时或 1 天等。部分数据聚合（Partial Aggregate）给 Druid 争取了很大的性能优化空间。 20 | 21 | 数据内存化也是提高查询速度的杀手锏。内存和硬盘的访问速度相差近百倍，但内存的大小是非常有限的，因此在内存使用方面要精细设计，比如 Druid 里面使用了 Bitmap 和各种压缩技术。 22 | 23 | 另外，为了支持 Drill-Down 某些维度，Druid 维护了一些倒排索引。这种方式可以加快 AND 和 OR 等计算操作。 24 | 25 | ### 水平扩展能力（Horizontal Scalability） 26 | 27 | Druid 查询性能在很大程度上依赖于内存的优化使用。数据可以分布在多个节点的内存中，因此当数据增长的时候，可以通过简单增加机器的方式进行扩容。为了保持平衡，Druid 按照时间范围把聚合数据进行分区处理。对于高基数的维度，只按照时间切分有时候是不够的（Druid 的每个 Segment 不超过 2000 万行），故 Druid 还支持对 Segment 进一步分区。 28 | 29 | 历史 Segment 数据可以保存在深度存储系统中，存储系统可以是本地磁盘、HDFS 或远程的云服务。如果某些节点出现故障，则可借助 Zookeeper 协调其他节点重新构造数据。 30 | 31 | Druid 的查询模块能够感知和处理集群的状态变化，查询总是在有效的集群架构中进行。集群上的查询可以进行灵活的水平扩展。Druid 内置提供了一些容易并行化的聚合操作，例如 Count、Mean、Variance 和其他查询统计。对于一些无法并行化的操作，例如 Median，Druid 暂时不提供支持。在支持直方图（Histogram）方面，Druid 也是通过一些近似计算的方法进行支持，以保证 Druid 整体的查询性能，这些近似计算方法还包括 HyperLoglog、DataSketches 的一些基数计算。 32 | 33 | ### 实时分析（Realtime Analytics） 34 | 35 | Druid 提供了包含基于时间维度数据的存储服务，并且任何一行数据都是历史真实发生的事件，因此在设计之初就约定事件一但进入系统，就不能再改变。 36 | 37 | 对于历史数据 Druid 以 Segment 数据文件的方式组织，并且将它们存储到深度存储系统中，例如文件系统或亚马逊的 S3 等。当需要查询这些数据的时候，Druid 再从深度存储系统中将它们装载到内存供查询使用。 38 | -------------------------------------------------------------------------------- /01~大数据体系/03~数据组织方式/04~数据中台/README.md: -------------------------------------------------------------------------------- 1 | # 数据中台 2 | 3 | 阿里在 2018 年提出了所谓“数据中台”的概念：即数据被统一采集，规范数据语义和业务口径形成企业基础数据模型，提供统一的分析查询和新业务的数据对接能力。数据中台，是通过获取各类数据，对数据进行分析和挖掘，产出结果和洞察，提供给业务和决策者使用，进而打造创新产品和服务，优化管理推动组织数字化转型。“让数据用起来”，是数据中台终极目标，也是数据中台要为处于不同数据认知成熟度阶段的企业实现一个个具体的目标。企业在业务的快速发展、信息化越来越高前提下追求自身的价值，业务部门不停的提出新的需求和挑战，给普惠数据服务提出了数据服务的按需提供、业务流程化、数据自我治理、统一数据服务、智能化数据运营等特点。 4 | 5 | 数据中台并不是新的颠覆式技术，而是一种企业数据资产管理和应用方法学，涵盖了数据集成、数据质量管理、元数据与主数据管理、数仓建模、支持高并发访问的数据服务接口层开发等内容。 6 | 7 | 在数据中台建设中，结合企业自身的业务需求特点，架构和功能可能各不相同，但其中一个最基本的需求是数据采集的实时性和完整性。数据从源端产生，到被采集到数据汇集层的时间要尽可能短，至少应做到秒级延迟，这样中台的数据模型更新才可能做到近实时，构建在中台之上依赖实时数据流驱动的应用（例如商品推荐、欺诈检测等）才能够满足业务的需求。 8 | 9 | 以阿里双十一为例，在极高的并发情况下，订单产生到大屏统计数据更新延迟不能超过 5s，一般在 2s 内。中台对外提供的数据应该是完整的，源端数据的 Create、Update 和 Delete 都要能够被捕获，不能少也不能多，即数据需要有端到端一致性的能力（Exactly Once Semantic，EOS）。当然，EOS 并非在任何业务场景下都需要，但从平台角度必须具备这种能力，并且允许用户根据业务需求灵活开启和关闭。 10 | 11 | # 数据中台的产生背景 12 | 13 | 起初，企业只有一个主营业务，比如电商，但随着公司战略和发展需要，会新增多支业务线，由于存在负责业务线开发的团队不一致，随之而来的就是风格迥异的代码风格和数据烟囱问题。 14 | 15 | 数据中台的产生就是为了解决数据烟囱的问题，打通数据孤岛，让数据活起来，让数据产生价值，结合前台能力，达到快速响应用户的目标。 16 | 17 | 中台只会同步能服务于超过两个业务线的数据，如果仅仅带有自身业务属性(不存在共性)的数据，不在中台的考虑范围内。例如:电商的产品产地信息，对于金融业务来说，其实是没有价值的，但电商的用户收货地址对金融业务来说是有价值的。所以不要简单的认为数据中台会汇集企业的所有数据，还是有侧重点的。导致这个结果的原因还包括数据中台建设本身是一个长周期的事，如果数据仅仅作用于一方，由业务方(前台)自行开发，更符合敏捷开发的特性。 18 | 19 | 关于何时应该建立数据中台这个问题，我的思考是这样的。复杂的业务线、丰富的数据维度和公司上层领导主推。三者缺一，都没有实行的必要。 20 | 一只手都能数的过来的业务线量，跨多个项目的需求相对还是比较少的，取数也比较方便，直接走接口方式基本就能满足。反而，通过数据中台流转，将问题复杂化了。 21 | 22 | 数据的维度越丰富，数据的价值越大。只知道性别数据，与知道性别和年龄，所得到的用户画像，肯定是维度丰富的准确性高。维度不丰富的情况下，没有计算的价值。 23 | 24 | 可能会很奇怪为什么一定需要公司上层的同意。这里就可能涉及到动了谁的奶酪的问题，数据是每个业务线最重要的资源，在推行中台过程中，势必会遇到阻力，只有成为全公司的战略任务，才有可能把事情做好。 25 | 26 | 中台如果没有考虑通用的业务能力，也会导致无法更专注于对中台技术的深入研究。中台如果不从抽象度、共性等角度出发，很有可能局限于某单一业务，导致中台无法很好地适应其他相关业务的要求，从而不能很好地应对业务的变化。如果中台的抽象程度低、扩展性差，则会导致中台无法满足前台业务需求。这时前台应用又因为业务本身的发展目标和压力不得不自行组织团队完成这部分功能，由此可能发生本应由中台提供的能力却最终实现在业务应用中，失去了中台存在的价值。 27 | 28 | ![中台架构图](https://s2.ax1x.com/2019/10/20/Ku7Faj.jpg) 29 | 30 | # Links 31 | 32 | - https://www.infoq.cn/article/zCf76o7YlsAN6AbOeQL0 33 | -------------------------------------------------------------------------------- /01~大数据体系/03~数据组织方式/03~数据湖/README.md: -------------------------------------------------------------------------------- 1 | # 数据湖 2 | 3 | # 为什么需要数据湖？ 4 | 5 | 以 Databricks 推出的 delta 为例，它要解决的核心问题基本上集中在下图： 6 | 7 | ![Delta 架构](https://s1.ax1x.com/2020/04/22/JUNQEQ.md.png) 8 | 9 | 在没有 delta 数据湖之前，Databricks 的客户一般会采用经典的 lambda 架构来构建他们的流批处理场景。以用户点击行为分析为例，点击事件经 Kafka 被下游的 Spark Streaming 作业消费，分析处理（业务层面聚合等）后得到一个实时的分析结果，这个实时结果只是当前时间所看到的一个状态，无法反应时间轴上的所有点击事件。所以为了保存全量点击行为，Kafka 还会被另外一个 Spark Batch 作业分析处理，导入到文件系统上（一般就是 parquet 格式写 HDFS 或者 S3，可以认为这个文件系统是一个简配版的数据湖），供下游的 Batch 作业做全量的数据分析以及 AI 处理等。 10 | 11 | 这套方案其实存在很多问题 12 | 13 | 第一、批量导入到文件系统的数据一般都缺乏全局的严格 schema 规范，下游的 Spark 作业做分析时碰到格式混乱的数据会很麻烦，每一个分析作业都要过滤处理错乱缺失的数据，成本较大； 14 | 15 | 第二、数据写入文件系统这个过程没有 ACID 保证，用户可能读到导入中间状态的数据。所以上层的批处理作业为了躲开这个坑，只能调度避开数据导入时间段，可以想象这对业务方是多么不友好；同时也无法保证多次导入的快照版本，例如业务方想读最近 5 次导入的数据版本，其实是做不到的。 16 | 17 | 第三、用户无法高效 upsert/delete 历史数据，parquet 文件一旦写入 HDFS 文件，要想改数据，就只能全量重新写一份的数据，成本很高。事实上，这种需求是广泛存在的，例如由于程序问题，导致错误地写入一些数据到文件系统，现在业务方想要把这些数据纠正过来；线上的 MySQL Binlog 不断地导入 update/delete 增量更新到下游数据湖中；某些数据审查规范要求做强制数据删除，例如欧洲出台的 GDPR 隐私保护等等。 18 | 19 | 第四、频繁地数据导入会在文件系统上产生大量的小文件，导致文件系统不堪重负，尤其是 HDFS 这种对文件数有限制的文件系统。 20 | 21 | ## 数据湖对比 22 | 23 | | 特性 | Table Schema | 抽象程度高，不绑定 Engine | ACID 语义保证，多版本保证 | 廉价存储 | Python 接口支持 | 流批读写 | 快速 CUDR 和 Pull 增量 | 企业级性能优化 | 24 | | ------- | ------------ | ------------------------- | ------------------------- | -------- | --------------- | -------- | ---------------------- | -------------- | 25 | | Delta | 有 | 无 | 有 | 有 | 有 | 有 | 无 | 无 | 26 | | Hudi | 无 | 无 | 有 | 有 | 无 | 有 | 有 | 无 | 27 | | Iceberg | 有 | 有 | 有 | 有 | 有 | 有 | 无 | 有 | 28 | 29 | # Links 30 | 31 | - https://mp.weixin.qq.com/s/Io6fPomYgBb9E3g8ZzDt1Q 32 | -------------------------------------------------------------------------------- /03~数仓建模/02~多维数据模型/02~星型与雪花模型/99~参考资料/2021-数据仓库系列：星型模型和雪花型模型.md: -------------------------------------------------------------------------------- 1 | # 数据仓库系列：星型模型和雪花型模型 2 | 3 | 数据仓库建模包含了几种数据建模技术，最常用的是：维度建模技术。维度建模的基本概念: 维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。它本身属于一种关系建模方法 4 | 5 | - 维度表(dimension)：表示对分析主题所属类型的描述。 6 | - 事实表(fact table)：表示对分析主题的度量。事实表包含了与各维度表相关联的外键，并通过 JOIN 方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。 7 | 8 | # 1. 星型模型 9 | 10 | ## 1.1 概念 11 | 12 | 星型模型：是一种多维的数据关系，它由一个事实表（Fact Table）和一组维表（Dimension Table）组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。事实表的非主键属性称为事实（Fact），它们一般都是数值或其他可以进行计算的数据；如下图： 13 | 14 | ![星型模型](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230409225817.png) 15 | 16 | 星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一定的冗余 17 | 18 | ## 1.2 示例 19 | 20 | ![星型模型示例](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230410104006.png) 21 | 22 | # 2. 雪花型模型 23 | 24 | ## 2.1 概念 25 | 26 | 雪花型模型：是星型模式的变种，其中某些维表是规范化（将冗余字段用新的表来表示）的，因而把数据进一步分解到附加表中，结果，模式图形成类似于雪花的形状。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。 27 | 28 | ![雪花模型](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230410104406.png) 29 | 30 | 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。 31 | 32 | ## 2.2 示例 33 | 34 | ![雪花模型](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230410104629.png) 35 | 36 | # 3. 维度模型 37 | 38 | ## 3.1 概念 39 | 40 | - 为了分析方便，将同一维度的不同层次的维度（如地市 ID,区县 ID）都融合到事实表中 41 | - 维度模型也是星型模型 42 | - 强调的是先对维度进行预处理，将多个维度集合到一个事实表（包含了多个维度，这样可以组合各维度，形成灵活的报表查询） 43 | 44 | ## 3.2 示例 45 | 46 | ![维度模型](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230410104735.png) 47 | 48 | # 4. 星型模型 VS 雪花型模型 49 | 50 | 星型模型和雪花模型的对比，可以从以下四个角度来对比。 51 | 52 | ## 4.1 查询性能角度来看 53 | 54 | 在 OLTP-DW 环节，由于雪花型要做多个表联接，性能会低于星型架构；但从 DW-OLAP 环节，由于雪花型架构更有利于度量值的聚合，因此性能要高于星型架构。 55 | 56 | ## 4.2 模型复杂度角度 57 | 58 | 星型架构更简单方便处理 59 | 60 | ## 4.3 层次结构角度 61 | 62 | 雪花型架构更加贴近 OLTP 系统的结构，比较符合业务逻辑，层次比较清晰。 63 | 64 | ## 4.4 存储角度 65 | 66 | 雪花型架构具有关系数据模型的所有优点，不会产生冗余数据，而相比之下星型架构会产生数据冗余。 67 | 68 | # 5 总结 69 | 70 | 根据项目经验，一般建议使用星型模型。因为在实际项目中，往往最关注的是查询性能问题，至于磁盘空间一般都不是问题。当然，在维度表数据量极大，需要节省存储空间的情况下，或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型模型。 71 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/Presto/部署与控制.md: -------------------------------------------------------------------------------- 1 | # Presto 2 | 3 | Facebook 拥有世界上最大的数据仓库之一，这些数据被一系列不同种类的程序所使用，包括传统的数据批处理程序、基于图论的数据分析、机器学习、和实时性的数据分析。在以前，Facebook 的科学家和分析师一直依靠 Hive 来做数据分析。但 Hive 使用 MapReduce 作为底层计算框架，是专为批处理设计的。但随着数据越来越多，使用 Hive 进行一个简单的数据查询可能要花费几分到几小时，显然不能满足交互式查询的需求。Facebook 也调研了其他比 Hive 更快的工具，但它们要么在功能有所限制要么就太简单，以至于无法操作 Facebook 庞大的数据仓库。2012 年开始试用的一些外部项目都不合适，他们决定自己开发，这就是 Presto，2013 年 Facebook 正式宣布开源 Presto。 4 | 5 | ![](http://www.mutouxiaogui.cn/blog/wp-content/uploads/2015/11/Presto.files/image002.jpg) 6 | 7 | Presto 主要以 Java 开发，被设计为用来专门进行高速、实时的数据分析。它支持标准的 ANSI SQL，包括复杂查询、聚合(aggregation)、连接(join)和窗口函数(window functions)。在支持基础的对于 HDFS 的查询之外，Presto 还支持对于异构数据库的查询，建立统一的抽象屏蔽层，保证了用户以通用的 SQL 语法能够忽略底层数据库差异进行统一查询。 8 | 9 | ![](http://www.mutouxiaogui.cn/blog/wp-content/uploads/2015/11/Presto.files/image003.jpg) 10 | 11 | ## 架构 12 | 13 | ![](http://tech.meituan.com/img/presto/image1.png) 14 | Presto 查询引擎是一个 Master-Slave 的架构，由一个 Coordinator 节点，一个 Discovery Server 节点，多个 Worker 节点组成，Discovery Server 通常内嵌于 Coordinator 节点中。Coordinator 负责解析 SQL 语句，生成执行计划，分发执行任务给 Worker 节点执行。Worker 节点负责实际执行查询任务。Worker 节点启动后向 Discovery Server 服务注册，Coordinator 从 Discovery Server 获得可以正常工作的 Worker 节点。如果配置了 Hive Connector，需要配置一个 Hive MetaStore 服务为 Presto 提供 Hive 元信息，Worker 节点与 HDFS 交互读取数据。 15 | 16 | ![](http://ww4.sinaimg.cn/large/7cc829d3gw1eaf8601b8bj20k00b9wfv.jpg) 17 | 18 | Presto 的运行模型和 Hive 或 MapReduce 有着本质的区别。Hive 将查询翻译成多阶段的 MapReduce 任务，一个接着一个地运行。每一个任务从磁盘上读取输入数据并且将中间结果输出到磁盘上。然而 Presto 引擎没有使用 MapReduce。为支持 SQL 语法，它实现了一个定制的查询、执行引擎和操作符。除了改进的调度算法之外，所有的数据处理都是在内存中进行的。不同的处理端通过网络组成处理的流水线。这样会避免不必要的磁盘读写和额外的延迟。这种流水线式的执行模型会在同一时间运行多个数据处理段，一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。这样的方式会大大的减少各种查询的端到端延迟。Presto 动态编译部分查询计划为字节码，使得 JVM 能够优化并生成本地机器码。在扩展性方面，Presto 只设计了一种简单的存储抽象，使得能够在多种数据源上进行 SQL 查询。连接器只需要提供获取元数据的接口，获得数据地址后自动访问数据。 19 | 20 | ![](http://www.mutouxiaogui.cn/blog/wp-content/uploads/2015/11/Presto.files/image011.jpg) 21 | 22 | # 部署 23 | 24 | ## 安装 25 | 26 | ## 环境配置 27 | 28 | ### 节点属性 29 | 30 | ### JVM 31 | 32 | ### 日志 33 | 34 | ## 连接配置 35 | 36 | ## 运行 37 | 38 | # 交互 39 | 40 | ## 命令行 41 | 42 | ## JDBC Driver 43 | 44 | # WebUI 45 | -------------------------------------------------------------------------------- /01~大数据体系/01~大数据生态/README.md: -------------------------------------------------------------------------------- 1 | # 大数据 2 | 3 | 大数据时代始于 ApacheHadoop 在 2006 年的亮相，开发人员和架构师将此工具视为有助于处理和存储多结构化数据和半结构化数据。企业在数据方面的理念发生了根本性转变，并不仅限于传统企业数据库的 ACID（原子性、一致性、隔离性和持久性），导致数据使用场合发生了变化，许多公司意识到以前丢弃或保存在静态归档中的数据实际上有助于了解客户行为、采取行动的倾向、风险因素以及复杂的组织、环境和商业行为。Cloudera 这款商业发行版推出后，Hadoop 的商业价值在 2009 年开始得到确立，MapR、Hortonworks 和 EMC Greenplum（现在的 Pivotal HD）紧随其后。 4 | 5 | # 大数据的定义 6 | 7 | 行业里对大数据的定义有很多，有广义的定义，也有狭义的定义。广义的定义，有点哲学味道——大数据，是指物理世界到数字世界的映射和提炼。通过发现其中的数据特征，从而做出提升效率的决策行为。狭义的定义，是技术工程师给的——大数据，是通过获取、存储、分析，从大容量数据中挖掘价值的一种全新的技术架构。 8 | 9 | 大数据往往是一种手段，而不是一个目标。最早提出“大数据”时代到来的是全球知名咨询公司麦肯锡，麦肯锡称：“数据，已经渗透到当今每一个行业和业务职能领域，成为重要的生产因素。人们对于海量数据的挖掘和运用，预示着新一波生产率增长和消费者盈余浪潮的到来。”数据，让一切有迹可循，让一切有源可溯。我们每天都在产生数据，创造大数据和使用大数据，只是，你，仍然浑然不知。企业组织利用相关数据和分析可以帮助它们降低成本、提高效率、开发新产品、做出更明智的业务决策等等。大数据的价值，远远不止于此，大数据对各行各业的渗透，大大推动了社会生产和生活，未来必将产生重大而深远的影响。对海量数据进行存储、计算、分析、挖掘处理需要依赖一系列的大数据技术。然而大数据技术其涉及的技术有分布式计算、高并发处理、高可用处理、集群、实时性计算等，汇集了当前 IT 领域热门流行的技术。 10 | 11 | # 大数据的价值 12 | 13 | 刚才说到价值密度，也就说到了大数据的核心本质，那就是价值。 14 | 15 | 人类提出大数据、研究大数据的主要目的，就是为了挖掘大数据里面的价值。 16 | 17 | 大数据，究竟有什么价值？ 18 | 19 | 早在 1980 年，著名未来学家阿尔文·托夫勒在他的著作《第三次浪潮》中，就明确提出：“数据就是财富”，并且，将大数据称为“第三次浪潮的华彩乐章”。 20 | 21 | 第一次浪潮：农业阶段，约 1 万年前开始 22 | 23 | 第二次浪潮：工业阶段，17 世纪末开始 24 | 25 | 第三次浪潮：信息化阶段，20 世纪 50 年代后期开始 26 | 27 | 进入 21 世纪之后，随着前面所说的第二第三阶段的发展，移动互联网崛起，存储能力和云计算能力飞跃，大数据开始落地，也引起了越来越多的重视。 28 | 29 | 2012 年的世界经济论坛指出：“数据已经成为一种新的经济资产类别，就像货币和黄金一样”。这无疑将大数据的价值推到了前所未有的高度层面上。 30 | 31 | 如今，大数据应用开始走进我们的生活，影响我们的衣食住行。 32 | 33 | 之所以大数据会有这么快的发展，就是因为越来越多的行业和企业，开始认识到大数据的价值，开始试图参与挖掘大数据的价值。 34 | 35 | 归纳来说，大数据的价值主要来自于两个方面： 36 | 37 | 1 帮助企业了解用户 38 | 39 | 大数据通过相关性分析，将客户和产品、服务进行关系串联，对用户的偏好进行定位，从而提供更精准、更有导向性的产品和服务，提升销售业绩。 40 | 41 | 典型的例子就是电商。 42 | 43 | 像阿里淘宝这样的电子商务平台，积累了大量的用户购买数据。在早期的时候，这些数据都是累赘和负担，存储它们需要大量的硬件成本。但是，现在这些数据都是阿里最宝贵的财富。 44 | 45 | 通过这些数据，可以分析用户行为，精准定位目标客群的消费特点、品牌偏好、地域分布，从而引导商家的运营管理、品牌定位、推广营销等。 46 | 47 | 大数据可以对业绩产生直接影响。它的效率和准确性，远远超过传统的用户调研。 48 | 49 | 除了电商，包括能源、影视、证券、金融、农业、工业、交通运输、公共事业等，都是大数据的用武之地。 50 | 51 | 2 帮助企业了解自己 52 | 53 | 除了帮助了解用户之外，大数据还能帮助了解自己。 54 | 55 | 企业生产经营需要大量的资源，大数据可以分析和锁定资源的具体情况，例如储量分布和需求趋势。这些资源的可视化，可以帮助企业管理者更直观地了解企业的运作状态，更快地发现问题，及时调整运营策略，降低经营风险。 56 | 57 | 总而言之，“知己知彼，百战百胜”。大数据，就是为决策服务的。 58 | 59 | # Links 60 | 61 | - https://cubox.pro/c/r3NNli 关于大数据的完整讲解 -------------------------------------------------------------------------------- /01~大数据体系/01~大数据生态/大数据的未来.md: -------------------------------------------------------------------------------- 1 | # 大数据的未来 2 | 3 | 随着大数据的消逝，我们进入到了后大数据时代，包括多云时代、机器学习时代以及实时和无处不在的上下文时代。 4 | 5 | - 多云时代恰恰表明日益需要基于现有的各种应用系统跨多云支持应用软件和平台，也日益需要支持持续交付和业务连续性。“某项任务有一个应用软件”这种观念导致了企业中每个员工平均有一个 SaaS 应用软件的业务环境，这意味着每家大企业在为数千个 SaaS 应用软件支持数据和流量。后端容器化这个趋势导致支持按需和峰值使用环境的存储和工作负载环境日益分散化和专业化。 6 | 7 | - 机器学习时代专注于分析模型、算法、模型训练、深度学习以及算法和深度学习技术的伦理。机器学习需要处理创建干净数据供分析所用所需的大量相同工作，但还需要另外的数学、业务和伦理上下文以创建持久的长期价值。 8 | 9 | - 实时和无处不在的上下文恰恰表明，从分析的角度和交互的角度来看，日益需要及时的更新。从分析的角度来看，公司分析处理仅仅每周更新一次或每天更新一次已不够。员工现在需要近乎实时的更新，否则有可能做出糟糕的公司决策，这些决策在制定的那一刻就已过时或落伍了。有效使用实时分析需要广泛的业务数据，以提供适当的整体上下文以及供针对数据按需执行的分析所用。无处不在还表明了交互的兴起，包括物联网提供表明环境和机械活动的更多边缘观察信息，以及仍在发展中的扩展现实（Extended Reality，包括增强现实和虚拟现实）提供身临其境的体验。为了提供这种级别的交互，必须以交互的速度分析数据，可能短至 300-500 毫秒，以提供有效的行为反馈。 10 | 11 | 随着大数据时代走到尽头，我们现在可以少关注收集大量数据的机制，多关注处理、分析海量数据并与之实时交互方面的无数挑战。我们迈入大数据驱动的新时代时，请牢记以下几个概念。 12 | 13 | - 首先，Hadoop 在企业数据界仍占有一席之地。Amalgam Insights 预计，MapR 最终会被一家以管理 IT 软件出名的公司收购，比如 BMC、冠群或 MicroFocus；并认为 Cloudera 已采取了措施，不仅限于企业 Hadoop，以支持数据的下几个时代。但技术的步伐不可阻挡，Cloudera 的问题在于它的行动是否够快、随势而变。Cloudera 在将其企业数据平台完善成下一代洞察力和机器学习平台方面面临数字化转型挑战。过去几十年，公司能够为转型敲定时间表。现在正如我们从亚马逊、Facebook 和微软等公司看到的那样，仅仅为了活命，成功的科技公司必须准备好每十年就要转型，可能甚至牺牲掉自己的部分业务。 14 | 15 | - 其次，对多云分析和数据可视化的需求比以往任何时候都要大。谷歌和 Salesforce 刚斥资 180 亿美元收购了 Looker 和 Tableau，那些收购基本上是针对颇具规模和收入增长的公司的市场价值收购。会投入更多的巨额资金，以克服这一挑战：针对众多数据源提供分析技术，并支持与多云有关的日益分散且多样的存储、计算和集成需求。这意味着企业需要慎重地搞清楚数据集成、数据建模、分析及/或机器学习/数据科学团队可以在多大程度上应对这个挑战，因为处理和分析异构数据变得越来越困难、复杂，但要支持战略业务需求并将数据用作真正的战略优势又势必需要这么做。而仅看国内发展，企业对多云分析和数据可视化的需求也是一样剧增。2006 年成立的国产 BI 软件厂商帆软软件自 2016 年 300 人左右的团队短短三年内成长到现在的 1100 余人，据知为了应对更多的市场需求其团队还在不断扩大。这样的成长速度源自市场需求的增多和帆软对于市场需求走势的判断。 16 | 17 | - 第三，机器学习和数据科学是下一代分析技术，需要各自做好新的数据管理工作。大规模创建测试数据、合成数据和掩蔽数据，以及数据沿袭、治理、参数和超参数定义以及算法假设，这些都超出了传统大数据假设的范畴。这里最重要的考量因素是，使用由于种种原因未能很好地服务于企业的数据：样本量小、缺乏数据源、数据定义不清晰、数据上下文不明确，或者算法和分类假设不准确。换句话说，不使用失实的数据。失实的数据会导致有偏见、不合规、不准确的结果，还可能导致诸多问题：比如 Nick Leeson 在 1995 年导致巴林银行（BaringsBank）垮台，或法国兴业银行因 Jerome Kerviel 精心操纵交易而蒙受 70 亿美元的交易损失。AI 现在是新的潜在“流氓交易者”，需要得到适当的治理、管理和支持。 18 | 19 | - 第四，需要将实时和无处不在的上下文既视为协作和技术上的挑战，又视为数据挑战。我们正进入这样一个世界：每个对象、流程和对话都可以用附加的上下文加以标记、标注或增强，可以实时处理数 GB 的数据，以生成简单的两个单词警报，可能就像“减慢速度”或“立即购买”这么简单。我们看到“数字孪生”（digital twin）这个概念方兴未艾：在工业界，PTC、GE 及其他产品生命周期和制造公司为设备创建数字孪生；而在销售界，Gong、Tact 和 Voicera 等公司借助额外的上下文以数字方式记录、分析和增强模拟对话。 20 | -------------------------------------------------------------------------------- /01~大数据体系/03~数据组织方式/04~数据中台/数据栈.md: -------------------------------------------------------------------------------- 1 | # 数据栈 2 | 3 | 我们发现，公司处理数据的过程主要分为四个主要阶段，这些阶段与每个阶段数据的外化使用密切相关。 4 | 5 | ![数据阶段](https://s2.ax1x.com/2019/11/01/K7V7rj.png) 6 | 7 | 上图中的每个垂直阶段都是一个相对的平衡点，可根据您的资源，规模和组织中数据的重要性来进行操作。例如，一个有 20 个人的具有典型数据需求的团队可能会直接在 Source 级别上很好地工作，并且在他们开始感觉到增长的痛苦之前，不希望进入 Lake 阶段。但是，随着该公司的规模超过 200 名员工，并且他们的数据需求不断增长，将其推进到 Mart 的整个过程将具有不可估量的价值，甚至可能是至关重要的。 8 | 9 | ## Sources 10 | 11 | 当您开始使用数据时，可能只有几个感兴趣的来源。早期的两个常见来源是 Google Analytics（分析）和产品所使用的 PostgreSQL 或 MySQL 数据库中的应用程序数据。如果您公司中只有少数几个人需要使用这些资源，则可以将其设置为具有直接访问权限；他们直接直接处理数据会更简单，更灵活。 12 | 13 | 在此早期阶段，您将受益于使用 BI 产品，该产品可让您在需要时编写 SQL，因为您的数据很可能是出于交易目的而构造的，并且通常需要某些复杂查询的全部功能。 14 | 15 | ## Lake 16 | 17 | 当您开始依赖更多的数据源，并且更频繁地需要合并数据时，您将需要构建一个 Data Lake，这是所有数据以统一格式一起存在的地方。尤其是当您需要使用 Salesforce，HubSpot，Jira 和 Zendesk 等应用程序中的数据时，您将需要为这些数据创建一个主目录，以便可以使用单个 SQL 语法一起访问所有数据，而不是许多不同的 API。 18 | 19 | 如果这是大量数据（每天> 100GB），则需要将其存储在 S3 中。但是对于大多数使用情况，您将需要将其存储在数据仓库引擎中，例如 Redshift，Panoply，Snowflake 或 Big Query。在这里，您的数据仍处于其原始事务或事件结构中，并且有时会需要一些凌乱的 SQL，这仍然会限制谁可以实际使用数据。但是，Data Lake 将具有更高的性能，可以使用一种 SQL 语法在一个地方使用，并且可以为下一个重要阶段做好准备。 20 | 21 | ## Warehouse (single source of truth) 22 | 23 | 在 Lake 阶段，当您吸引更多人使用数据时，您必须向他们解释每种模式的奇特之处，哪些数据在哪里以及需要在每个表中进行过滤的特殊条件。这变得很繁重，并且会导致您经常遇到数据的完整性问题。最终，您将需要开始将数据整理到一个单一的真实来源中。从历史上看，这个阶段（创建数据仓库）一直是一场噩梦，并且有许多著作着眼于如何最好地建模数据以进行分析处理。但是，如今这并不困难了，它不仅使您不必向新团队成员解释所有架构的怪异，而且还可以节省您重复，编辑和维护自己的混乱查询的时间。 24 | 25 | - 使用您自己的文件或使用 dbt 之类的出色框架，以 SQL 中新的视图模式进行建模。不要使用专有的第三方建模语言；最好用 SQL 完成。它功能强大，性能卓越，与供应商无关，并且您的团队已经知道这一点。 26 | 27 | - 不要阅读过多的有关 Inman 或 Kimball 等传奇人物关于尺寸建模的书籍，以免过分思考您的建模。那里的大多数书籍都有几十年的历史了，正如我上文所述，最佳实践是基于完全不同的技术考量。 28 | 29 | - 您的分析模型现在应该仅是原始事务模式的简化，过滤，最小化，描述性命名的纯净版本。就像您的公司没有在许多不同的详细 SaaS 应用程序和具有奇特情况和复杂集成的事务性数据库上运行一样，创建它们。而是在单个理想的，完美清洁的整体应用程序上运行。这个理想的应用程序具有干净的操作架构，随着它成为您公司的真理之源，它会慢慢发展。 30 | 31 | ## Marts 32 | 33 | 当您拥有干净的数据并在其上拥有良好的 BI 产品时，您应该开始注意到公司中的许多人都能够回答他们自己的问题，并且越来越多的人参与其中。这是个好消息：您的公司越来越了解信息，业务和生产力结果也应显示出来。您也不必担心完整性问题，因为您已经对数据进行了建模，并且不断将其维护为干净，清晰的事实来源。 34 | 35 | 最终，您将在该事实来源中拥有数百张表，并且当用户尝试查找与其相关的数据时，他们将不知所措。您可能还会发现，根据团队，部门或用例的不同，不同的人希望使用以不同方式构造的同一数据。由于这些原因，您将要开始推出 Data Marts。 36 | 37 | 数据集市是团队或调查主题的更小更具体的真理来源。例如，销售团队可能只需要主仓库中的 12 个左右的表，而营销团队可能需要 20 个表。其中一些是相同的，但有些不同。创建这些数据集市的方法与仓库相同。只需使用视图的 SQL（无论是否实现）指向真相的源来创建新的架构。 38 | -------------------------------------------------------------------------------- /02~数据集成/DataPipeline/运行环境与引擎.md: -------------------------------------------------------------------------------- 1 | # 运行环境 2 | 3 | 无论采用何种数据变化捕获技术，程序必须在一个可靠的平台运行。该平台需要解决分布式系统的一些共性问题，主要包括：水平扩展、容错、进度管理等。 4 | 5 | ## 水平扩展 6 | 7 | 程序必须能够以分布式 job 的形式在集群中运行，从而允许在业务增长时通过增加运行时节点的方式实现扩展。 8 | 9 | 因为在一个规模化的企业中，通常要同时运行成百上千的 job。随着业务的增长，job 的数量以及 job 的负载还有可能持续增长。 10 | 11 | ## 容错 12 | 13 | 分布式运行环境的执行节点可能因为过载、网络连通性等原因无法正常工作。 14 | 15 | 当节点出现问题时，运行环境需要能够及时监测到，并将问题节点上的 job 分配给健康的节点继续运行。 16 | 17 | ## 进度管理 18 | 19 | job 需要记录自身处理的进度，避免重复处理数据。另外，job 会因为上下游系统的问题、网络连通性、程序 bug 等各种原因异常中止，当 job 重启后，必须能够从上次记录的正常进度位置开始处理后继的数据。 20 | 21 | 有许多优秀的开源框架都可以满足上述要求，包括 Kafka Connect、Spark、Flink 等。 22 | 23 | Kafka Connect 是一个专注数据进出 Kafka 的数据集成框架。Spark 和 Flink 则更为通用，既可以用于数据集成，也适用于更加复杂的应用场景，例如机器学习的模型训练和流式计算。 24 | 25 | 就数据集成这一应用场景而言，不同框架的概念是非常类似的。 26 | 27 | 首先，框架提供 Source Connector 接口封装对数据源的访问。应用开发者基于这一接口开发适配特定数据源的 Connector，实现数据抽取逻辑和进度（offset）更新逻辑。 28 | 29 | 其次，框架提供一个分布式的 Connector 运行环境，处理任务的分发、容错和进度更新等问题。 30 | 31 | 不同之处在于，Kafka Connect 总是将数据抽取到 Kafka，而对于 Spark 和 Flink，Source Connector 是将数据抽取到内存中构建对象，写入目的地是由程序逻辑定义的，包括但不限于消息队列。 32 | 33 | 但无论采用何种框架，都建议首先将数据写入一个汇集层，通常是 Kafka 这样的消息队列。单就数据源采集而言，Kafka Connect 这样专注于数据集成的框架是有一定优势的，这主要体现在两方面： 34 | 35 | - 首先是 Connector 的丰富程度，几乎所有较为流行的数据库、对象存储、文件系统都有开源的 Connector 实现。尤其在数据库的 CDC 方面，有 Debezium 这样优秀的开源项目存在，降低了应用的成本。 36 | 37 | - 其次是开发的便捷性，专有框架的设计相较于通用框架更为简洁，开发新的 Connector 门槛较低。Kafka Connect 的 runtime 实现也较为轻量，出现框架级别问题时 debug 也比较便捷。 38 | 39 | # 引擎对比 40 | 41 | 数据流服务的构建则是基于流式计算引擎，对汇集层的数据进一步加工计算，并将结果实时输出给下游应用系统。这涉及到流式计算引擎的选择：Spark Streaming、Flink、还是 Kafka Streams 42 | 43 | ## 延迟性 44 | 45 | Spark 对流的支持是 MicroBatch，提供的是亚秒级的延迟，相较于 Flink 和 Kafka Streams 在实时性上要差一些。 46 | 47 | ## 应用模式 48 | 49 | Spark 和 Flink 都是将作业提交到计算集群上运行，需要搭建专属的运行环境。Kafka Streams 的作业是以普通 Java 程序方式运行，本质上是一个调用 Kafka Streaming API 的 Kafka Consumer，可以方便地嵌入各种应用。 50 | 51 | 但相应的，用户需要自己解决作业程序在不同服务器上的分发问题，例如通过 K8s 集群方案进行应用的容器化部署。如果使用 KSQL，还需要部署 KSQL 的集群。 52 | 53 | ## SQL 支持 54 | 55 | 三者都提供 Streaming SQL，但 Flink 的 SQL 支持要更为强大些，可以运行更加复杂的分组聚合操作。 56 | 57 | ## EOS 58 | 59 | Flink 对于数据进出计算集群提供了框架级别的支持，这是通过结合 CheckPoint 机制和 Sink Connector 接口封装的二阶段提交协议实现的。 60 | 61 | Kafka Streams 利用 Kafka 事务性消息，可以实现“消费 - 计算 - 写入 Kafka“的 EOS，但当结果需要输出到 Kafka 以外的目的地时，还需要利用 Kafka Connect 的 Sink Connector。遗憾的是，Kafka Connect 不提供 Kafka 到其它类型 Sink 的 EOS 保证，需要用户自己实现。 62 | 63 | Spark Streaming 与 Kafka Streams 类似，在读取和计算过程中可以保证 EOS，但将结果输出到外部时，依然需要额外做一些工作来确保数据一致性。常见的方式包括：利用数据库的事务写入机制将 Offset 持久化到外部、利用主键保证幂等写入、参考二阶段提交协议做分布式事务等。 64 | -------------------------------------------------------------------------------- /10~OLAP/01.引擎架构/02.建模类型划分/02.ROLAP.md: -------------------------------------------------------------------------------- 1 | # ROLAP 2 | 3 | 与 MOLAP 相反，ROLAP 无需预计算，直接在构成多维数据模型的事实表和维度表上进行计算。R 即表示关系型（Relational）。显然，这种方式相比 MOLAP 更具可扩展性，增量数据导入后，无需进行重新计算，用户有新的查询需求时只需写好正确的 SQL 语句既能完成获取所需的结果。 4 | 5 | 但 ROLAP 的不足也很明显，尤其是在数据体量巨大的场景下，用户提交 SQL 后，获取查询结果所需的时间无法准确预知，可能秒回，也可能需要花费数十分钟甚至数小时。本质上，ROLAP 是把 MOLAP 预计算所需的时间分摊到了用户的每次查询上，肯定会影响用户的查询体验。 6 | 7 | 当然 ROLAP 的性能是否能够接受，取决于用户查询的 SQL 类型，数据规模以及用户对性能的预期。对于相对简单的 SQL，比如 TPCH 中的 Query 响应时间较快。但如果是复杂 SQL，比如 TPC-DS 中的数据分析和挖掘类的 Query，可能需要数分钟。 8 | 9 | 相比 MOLAP，ROLAP 的使用门槛更低，在完成星型或雪花型模型的构建，创建对应 schema 的事实表和维度表并导入数据后，用户只需会写出符合需求的 SQL，就可以得到想要的结果。相比创建 `数据立方体`，显然更加方便。 10 | 11 | 目前生产环境使用较多的开源 ROLAP 主要可以分为 2 大类，一个是**宽表模型**，另一个是**多表组合模型**（就是前述的星型或雪花型）。 12 | 13 | ### 宽表类型 14 | 15 | 宽表模型能够提供比多表组合模型更好的查询性能，不足的是支持的 SQL 操作类型比较有限，比如对 Join 等复杂操作支持较弱或不支持。 16 | 17 | 目前该类 OLAP 系统包括`Druid`和`ClickHouse`等，两者各有优势，Druid 支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能，在广告分析场景、监控报警等时序类应用均有广泛使用；ClickHouse 部署架构简单，易用，保存明细数据，依托其向量化查询、减枝等优化能力，具备强劲的查询性能。两者均具备较高的数据实时性，在互联网企业均有广泛使用。 18 | 19 | 除了上面介绍的 Druid 和 ClickHouse 外，ElasticSearch 和 Solar 也可以归为宽表模型。但其系统设计架构有较大不同，这两个一般称为搜索引擎，通过倒排索引，应用 Scatter-Gather 计算模型提高查询性能。对于搜索类的查询效果较好，但当数据量较大或进行扫描聚合类查询时，查询性能会有较大影响。 20 | 21 | #### 代表 22 | 23 | - **ClickHouse**是个列存数据库，保存原始明细数据，通过`MergeTree`使得数据存储本地化来提高性能。是个单机版超高性能的数据库 24 | 25 | #### 优点 26 | 27 | 1. 性能高，列存压缩比高，通过索引实现秒级响应 28 | 2. 实时性强，支持 kafka 导入 29 | 3. 处理方式简单，无需预处理，保存明细数据 30 | 31 | #### 缺点 32 | 33 | 1. 数据规模一般 34 | 2. 灵活性差，不支持任意的 adhoc 查询，join 的支持不好。 35 | 3. 易用性较弱，SQL 语法不标准，不支持窗口函数等；维护成本高 36 | 37 | ### 多表组合模型 38 | 39 | 采用星型或雪花型建模是最通用的一种 ROLAP 系统，常见的包括`GreenPlum`、`Presto`和`Impala`等，他们均基于 MPP 架构，采用该模型和架构的系统具有支持的数据量大、扩展性较好、灵活易用和支持的 SQL 类型多样等优点。 40 | 41 | 相比其他类型 ROLAP 和 MOLAP，该类系统性能不具有优势，实时性较一般。通用系统往往比专用系统更难实现和进行优化，这是因为通用系统需要考虑的场景更多，支持的查询类型更丰富。而专用系统只需要针对所服务的某个特定场景进行优化即可，相对复杂度会有所降低。 42 | 43 | 对于 ROLAP 系统，尤其是星型或雪花型的系统，如果能够尽可能得缩短响应时间非常重要，这将是该系统的核心竞争力。 44 | 45 | #### 代表 46 | 47 | - **Presto**、**Impala**以及**Spark SQL**等利用关系模型来处理 OLAP 查询，通过并发来提高查询性能。同时三者是有很多相似点。我日常工作中，接触最多也就是这三兄弟和一个大哥(Hive)。Hive 就不多谈了，是基于 MR 最基础的 OLAP 引擎，也是对于大数据量的分析支持最好得。 48 | 49 | #### 优点 50 | 51 | 1. 支持的计算数据规模大(非存储引擎) 52 | 2. 灵活性高，随意查询数据 53 | 3. 易用性强，支持标准 SQL 以及多表 join 和窗口函数 54 | 4. 处理方式简单，无需预处理，全部后处理，没有冗余数据 55 | 56 | #### 缺点 57 | 58 | 1. 性能较差，当查询复杂度高且数据量大时，可能分钟级别的响应。同时其不是存储引擎，因此没有本地存储，当 join 时 shuffle 开销大，性能差 举例：SparkSql 为例子，其只是计算引擎，导致需要从外部加载数据，从而数据的实时性得不到保证；多表 join 的时候性能也很难得到秒级的响应。 59 | 2. 实时性较差，不支持数据的实时导入，偏离线处理。如果需要实时数据，经常的做法是 Presto 或者 Impala 和 Kudu 的结合，解决了 Kudu 的磁盘存储问题，实时性能也不会太差。 60 | -------------------------------------------------------------------------------- /04~数据可视化/数据与图表类别/数据类别.md: -------------------------------------------------------------------------------- 1 | # 数据类别 2 | 3 | # 序数数据 4 | 5 | 可明确每项数据的定义或者边界，数据可被枚举。例：部门；性别；花名；商家常用序数比例尺将数据映射为图形，比例尺为等比例等比例尺，对应图表的序数类型的展示。可使用的图形元素包括不仅限于：序数的 XY 轴，形状或图标，枚举的颜色，区域位置，表格行列··· 6 | 7 | 常见的数据问题： 8 | 9 | - 问题：枚举数目可能过多；解决：取 TOP N，剩余的归纳为“其他”。N 不宜过大 10 | 11 | - 问题：数据项的定义可能不清晰；解决：tooltip，或者说明文案； 12 | 13 | 展示建议：1.采用用户关注的指标进行排序。2.如果数据项固定，则固定展示位置以及固定使用某种图形元素，培养用户习惯。一旦用户养成习惯，即可减少很多繁琐的文字说明，用户认知更能统一。 14 | 15 | # 线性数据 16 | 17 | 连续的不能明确每项的边界。这里容易与上诉等序数数据混淆的类型，例：[1,2) ; [2,3) ; [3,4)······。此类数据可明确每项数据的边界，所以应该归类为序数数据而不是连续数据。例如，SDR 评分，在客户端打分，用户只能打整数分，计算商家平均评分为 1.1 与得分 1.25 的商家数从分析上来说区别不大，我们可以合并为区间数据，假设使用散点图展示，便可解决散点互相覆盖而不清晰的问题。 18 | 19 | 在展示中若用户关注数据变化，可按大小递增递减排序。若用户关注其所携带的值 value 大小，可不用考虑其自身顺序甚至打乱顺序。例：营销额 20 | 21 | 常见的数据问题： 22 | 23 | - 数据区间分布不均，通常表现为，多个指标在一个图表中。例如多条折线图，其中一个折线数据区间值范围分布在[10000，2000]，而其他指标分布在[100,1000],这样会把其他折线压平而看不到变化趋势。从视觉上就是一条横线。 24 | 25 | - 峰值过大压低其他变化趋势。解决方案：将指标按照数据分布区间拆分成同 X 轴或者同 Y 轴的多图展示方式。 26 | 27 | # 时序数据 28 | 29 | 按照时间顺序，以特定时间粒度为步长增长，例：股票，网站日志，周 PV／UV。此类数据展示通常建议采用时间轴的展示方式，通常有横向时间轴，与纵向时间轴。横向时间轴，常用于统计数据折线图，柱状图等。如果时间跨度较大： 30 | 31 | - 可采用拉伸 slider 控制展示的时间范围； 32 | - 通过切换时间粒度控制展示。 33 | 34 | 纵向时间轴，纵向图表的一大特性就是可以展示坐标轴刻度较大的数据。也就是说可展示的内容更多。但纵向时间轴不如横向图表一目了然，所以更适合具有故事发展性但数据展示（例如：大事记；版本修订记录）。 35 | 36 | 常见的数据问题： 37 | 38 | - 数据缺失。时序不像序数数据，类别。缺少某段时间但数据，会使数据视觉上出现跳跃，或者出现空白。非常影响可视化但美观，简而言之，容易误以为有 bug。解决方案建议：1.补全时序，数据值补 0。优点：简单，符合数据情况。缺点：展示 0，不能判断出是真实数据 0，还是缺失数据。2.线性过度。注意，线性过度后的展示一定要区别与正常数据的。例如，鼠标经过无效果，或者用虚线或灰线展示。 39 | 40 | # 地理数据 41 | 42 | 含有单个地理位置的信息， 43 | 例：手机机站位置，商场 wifi 位置 {x:000,y:0001} 44 | 地理信息通常会伴随其他指标，例如人数，城市类型，迁徙。这些即地理信息与其他数据类型的组合。单纯从地理信息的数据考虑，常见问题：1.数据量大，检索、渲染效率低。 45 | 建议优化方案：通过四叉树优化二维空间检索（八叉树优化三维空间）；渲染可以分批次渲染；减少渲染过度效果，等。2.商场园区平面图位置等非经纬度数据，与背景图契合。可采用 0 到 1 的坐标系，按比例尺映射于平面图。 46 | 47 | # 关系数据 48 | 49 | 包含节点信息，关系信息的数据，可能带有方向性，例：微博数据 50 | 关系数据可能包含：节点类别，节点值大小，关系类型，关系数量，关系权重，关系方向，路径等属性，属性可选。 51 | 按照关系类型又可分为：1.树型关系 tree 2.簇群关系 cluster 3.图（包含树和簇群）允许出现关系回路，也称网状关系。4.链路／流程关系，具有明显方向性，通常会结合时序数据。 52 | 53 | 除开算法分析外，在可视化过程中，我们可以做哪些？1.聚类，社群分析。2.关联关系，发现大 V。即关联关系中关键连接点。3.最短路径。从 A 点到 B 节点最短发生关联关系的路径，通常用于线索发现，分析本不存在直接关联的 AB 两个实体之间的关联，从而发现关系线索节点（关系桥接点）。4.边捆绑算法展示与路径热力，用于航线等路径规划等。5.流程／路径／轨迹播放 6.知识图谱与思维导图分析，要求典型树型数据结构。 54 | 55 | 问题：1.布局切换。通常根据数据类型，会选择不同的布局方式。然而在有些场景下，我们需要这样的操作。例如，将网状结构的关系数据，希望通过树形机构进行展示。通常树结构只有一个根节点，并且无回路，所以， 56 | 解决方案：则取最核心（关联关系最多的）的节点为根节点。如果数据是多个集群，即由多个图组成，相当于多个树；可虚拟一个根节点，这样绘制的时候可以作为树结构处理，大大减少计算难度。回路，可以在树的机构上，增加线条。严格意义上，这个可视化只是树布局，并非树。2.强交互的关系图谱 请为每个节点配置唯一 ID，次 id 作为关系链接的标志。尽量不要使用节点数组下标作为关系链接标志。3.两个节点间关系繁杂的情况下，可以先进行统计规整。 57 | 58 | # 组合数据 59 | 60 | 通常我们的数据较少是一维数据，通常都是二维以上数据。在数据可视化中，两个和三个维度的数据展示是最清晰的。四个维度的数据基本是一张图表可视化能理解的上限了。再多就使得图表理解困难。最好对图表进行拆分，进行联动等其他展示方案。 61 | -------------------------------------------------------------------------------- /01~大数据体系/04~数据中心/云数据中心.md: -------------------------------------------------------------------------------- 1 | # 云数据中心 2 | 3 | 所谓的 IT 架构广泛理解即是 Informatica and Communications Technology Infrastructure，其由硬件设备、数据中心系统、企业级软件、电信服务、信息技术服务等几方面构成。而其中的数据中心系统则是现代 IT 核心基础架构，它是云计算的物理载体，为云计算提供底层的数据处理、存储和高性能计算的一体化支撑；数据中心包含了冷却、网络、机房空间、服务器、能耗管理、存储等多个方面。超大规模的云计算数据中心中 PUE(Power Usage Efficiency)则显得尤为重要；现代化的数据中心也采用了虚拟化、软件定义实现按需分配 IT 资源，最大化资源利用率。 4 | 5 | IT 产业始于 1964 年，第一代平台以大型机与终端机为典型代表，服务于百万级用户；第二代平台始于 1981 年，以局域网、服务器、因特网为典型代表，服务于亿级用户，万级应用；第三代平台始于 2012 年，以云计算、大数据、移动与社交为典型代表，服务于数十亿用户。云计算从运营模式分为了公有云、私有云与混合云三种。 6 | 7 | 公有云按照交付模式，又分为 IaaS、PaaS、SaaS 这三种，越来越多的企业也选择了从自建 IT 架构到租借公有云服务商提供的云服务。公有云能够帮助企业实现均衡优化的 IT 资源管理，降低整体成本，并且将企业固定成本转化为可变运营成本；从而能够让企业聚焦其核心业务。云计算将传统的烟囱模式：网络->存储->计算->虚拟化->系统->中间件->运行环境->数据，改造为了硬件资源层->虚拟化层->云管理层->应用平台层->应用层架构。 8 | 9 | 云计算融合了虚拟化技术、分布式数据存储技术、大规模数据管理技术、编程模型、分布式的资源管理、云计算平台管理技术、信息安全等多个领域，其中虚拟化技术是云计算技术的核心之一，为云计算技术提供了基础架构的支撑；不过需要注意的是，云计算不仅仅是虚拟化，而是从单一虚拟化走向了以资源为核心，以应用为核心的阶段。在以应用为核心阶段，云计算的核心技术包括了 PaaS、容器引擎、应用管理框架、容器集群资源管理等方面。 10 | 11 | 大数据指的是所涉及的资料量的规模巨大到无法通过人工在合理时间内获取、管理和处理的数据集合。一般来说，数据类型分为传统企业数据，即企业的 ERP 数据、库存数据、账目数据等；机器产生和传感器数据，包括呼叫记录、智能仪表、工业设备传感器、设备日志、交易数据等等；还有就是社交数据，譬如用户行为记录、反馈数据等。而我们所谓的大数据处理平台包含了数据的采集、传输、存储、分析、挖掘、可视化、价值体现等完整的大数据处理过程。 12 | 13 | 传统企业应用的特征是成熟的架构设计、标准的套装软件与良好的纵向扩展能力，而云计算应用的特征是基于开源平台开发、良好的横向扩展能力与很强的自愈能力。现代互联网用户的应用需求包括了实时-RealTime，按需定制-OnDemand，全在线-All on-line，自助服务-DIY，社交分享-Social 这几个部分。 14 | 15 | AWS 的举措：从 IaaS 向 PaaS 扩展、向传统企业级市场进军。2013 年，CIA 情报社区云项目的竞标中 AWS 以高价但优质的云数据中心服务战胜了 IBM 的传统数据中心，云数据中心已然成为了未来 IT 发展的方向与必然选择。传统数据中心装上云操作系统，变成水平扩展的云数据中心。云操作系统把服务器、网络、安全等 IT 设备能力变为 IT 服务，提供给平台软件和应用软件使用。云数据中心提供 IT 服务，实现了资源共享、资源的水平扩展，提高了资源利用率，并且使能低成本线性扩容，扩容不需要暂停业务。 16 | 17 | NFV 表示网络功能虚拟化，SDN 表示软件定义网络，两种技术的核心即是用 IT 技术改造 CT 网络，重构电信网络的核心。 18 | 19 | 数据中心机房配套层标准与数据中心基础设施层标准，其中机房配套层常见的是 Uptime 标准和 ISO17001 标准，Tier 4 指全年只能有不超过 24 分钟的服务不可用，而 Tier 3 指全年可以有不超过 1.6 小时的不可用；PUE 指机房用电总量是 IT 设备用电量。基础设施层则是 SHARE 78 国际标准，其定义了 1 到 7 级标准，容灾级别越高，RTO 恢复时间就越短，成本越高。而目前云服务的事实标准则是 OpenStack 20 | 21 | 我们还需要强调企业级云数据中心的统一架构，资源池是云数据中心的基本单元，包括了计算资源池、存储资源池、网络资源池等等。统一架构的核心就是物理分散、逻辑集中、异构共存、资源共享、按需服务。 22 | 23 | 大型企业的演进策略是，通过 DC 整合进行全局规划、分布实施：包括建立云 DC 核心样板点，确立云服务标准；建立云 DC 企业级统一调度平台；向周边复制云 DC，强化网络自动化，实现多 DC 互连互通；将业务云化搬迁到云 DC 上；持续优化经营。而小公司的演进策略往往是通过融合资源池，以点带面，逐步渗透。 24 | 25 | 为了更好地实践统一的云管理平台和主动运维模式，Google 建立了全局资源集中管控面与大数据平台。主动运维的核心是企业级 DC 的运行可视化，健康可视化帮助推动运维转型，从被动运维到主动运维；还需要通过脚本编程将运维经验固化下来。还需要辅助以良好的云服务流程机制和资源调度管理，企业级 DC 资源调度往往分为两种方式：IT 系统设置规则或者大的业务部门之间，要考资源的配额调度去管控；企业应该构建具有自我约束、自我修复的云服务流程，并且建立专门的组织保障企业级的资源可调度。 26 | 27 | 传统的数据中心是面向应用软件提供设备，属于典型的烟囱式架构；而云数据中心致力于提供 IT 服务，属于共享服务式架构。 28 | 29 | 传统数据中心的 IT 资源是各个业务应用独占，即使某个业务处于波谷阶段也无法将资源分配给其他波峰阶段的业务使用；并且传统数据中心只能采用垂直扩容方式，扩容时业务需要中断，并且基础设施的建设时间也过长。云数据中心则能有效实现企业级资源共享，能够在分钟级完成资源获取。 30 | -------------------------------------------------------------------------------- /02~数据集成/DataPipeline/数据汇集层.md: -------------------------------------------------------------------------------- 1 | # 数据汇集层 2 | 3 | 数据汇集层在部分场景下又称为变更分发平台。当各类数据从源端抽取后，首先应当被写入一个数据汇集层，然后再进行后继的转换处理，直至将最终结果写入目的地。数据汇集层的作用主要有两点： 4 | 5 | - 数据汇集层将异构的数据源数据存储为统一的格式，并且为后继的处理提供一致的访问接口。这就将处理逻辑和数据源解耦开来，同时屏蔽了数据抽取过程中可能发生的异常对后继作业的影响。 6 | 7 | - 数据汇集层独立于数据源，可被多次访问，亦可根据业务需要缓存全部或一定期限的原始数据，这为转换分析提供了更高的灵活度。当业务需求发生变化时，无需重复读取源端数据，直接基于数据汇集层就可以开发新的模型和应用。数据汇集层可基于任意支持海量 / 高可用的文件系统、数据仓库或者消息队列构建，常见的方案包括 HDFS、HBase、Kafka 等。 8 | 9 | # 数据汇集层的技术考量 10 | 11 | 变更分发平台可以有很多种形式，本质上它只是一个存储变更的中间件，那么如何进行选型呢？首先由于变更数据数据量级大，且操作时没有事务需求，所以先排除了关系型数据库，剩下的 NoSQL 如 Cassandra，mq 如 Kafka、RabbitMQ 都可以胜任。其区别在于，消费端到分发平台拉取变更时，假如是 NoSQL 的实现，那么就能很容易地实现条件过滤等操作(比如某个客户端只对特定字段为 true 的消息感兴趣); 但 NoSQL 的实现往往会在吞吐量和一致性上输给 mq。这里就是一个设计抉择的问题，最终我们选择了 mq，主要考虑的点是：消费端往往是无状态应用，很容易进行水平扩展，因此假如有条件过滤这样的需求，我们更希望把这样的计算压力放在消费端上。 12 | 13 | 而在 mq 里，Kafka 则显得具有压倒性优势。Kafka 本身就有大数据的基因，通常被认为是目前吞吐量最大的消息队列，同时，使用 Kafka 有一项很适合该场景的特性：Log Compaction。Kafka 默认的过期清理策略(log.cleanup.policy)是 delete，也就是删除过期消息，配置为 compact 则可以启用 Log Compaction 特性，这时 Kafka 不再删除过期消息，而是对所有过期消息进行”折叠”：对于 key 相同的所有消息会，保留最新的一条。 14 | 15 | 对应的在 mq 中的流总共会产生 4 条变更消息，而最下面两条分别是 id:1 id:2 下的最新记录，在它们之前的两条 INSERT 引起的变更就会被 Kafka 删除，最终我们在 Kafka 中看到的就是两行记录的最新状态，而一个持续订阅该流的消费者则能收到全部 4 条记录。这种行为有一个有趣的名字，流表二相性(Stream Table Durability)：Topic 中有无尽的变更消息不断被写入，这是流的特质；而 Topic 某一时刻的状态，恰恰是该时刻对应的数据表的一个快照(参见上面的例子)，每条新消息的到来相当于一次 Upsert，这又是表的特性。落到实践中来讲，Log Compaction 对于我们的场景有一个重要应用：全量数据迁移与数据补偿，我们可以直接编写针对每条变更数据的处理程序，就能兼顾全量迁移与之后的增量同步两个过程；而在数据异常时，我们可以重新回放整个 Kafka Topic：该 Topic 就是对应表的快照，针对上面的例子，我们回放时只会读到最新的两条消息，不需要读全部四条消息也能保证数据正确。 16 | 17 | 关于 Kafka 作为变更分发平台，最后要说的就是消费顺序的问题。大家都知道 Kafka 只能保证单个 Partition 内消息有序，而对于整个 Topic，消息是无序的。一般的认知是，数据变更的消费为了逻辑的正确性，必须按序消费。按着这个逻辑，我们的 Topic 只能有单个 Partition，这就大大牺牲了 Kafka 的扩展性与吞吐量。其实这里有一个误区，对于数据库变更抓取，我们只要保证 同一行记录的变更有序 就足够了。还是上面的例子，我们只需要保证对 id:2 这行的 insert 消息先于 update 消息，该行数据最后就是正确的。而实现”同一行记录变更有序”就简单多了，Kafka Producer 对带 key 的消息默认使用 key 的 hash 决定分片，因此只要用数据行的主键作为消息的 key，所有该行的变更都会落到同一个 Parition 上，自然也就有序了。这有一个要求就是 CDC 模块必须解析出变更数据的主键：而这点 Debezium 已经帮助我们解决了。 18 | 19 | # 统一数据格式 20 | 21 | 数据格式的选择同样十分重要。首先想到的当然是 json, 目前最常见的消息格式，不仅易读，开发也都对它十分熟悉。但 json 本身有一个很大的不足，那就是契约性太弱，它的结构可以随意更改：试想假如有一个接口返回 String，注释上说这是个 json，那我们该怎么编写对应的调用代码呢？是不是需要翻接口文档，提前获知这段 json 的 schema，然后才能开始编写代码，并且这段代码随时可能会因为这段 json 的格式改变而 break。 22 | 23 | 在规模不大的系统中，这个问题并不显著。但假如在一个拥有上千种数据格式的数据管道上工作，这个问题就会很麻烦，首先当你订阅一个变更 topic 时，你完全处于懵逼状态——不知道这个 topic 会给你什么，当你经过文档的洗礼与不断地调试终于写完了客户端代码，它又随时会因为 topic 中的消息格式变更而挂掉。参考 Yelp 和 Linkedin 的选择，我们决定使用 Apache Avro 作为统一的数据格式。Avro 依赖模式 Schema 来实现数据结构定义，而 Schema 通常使用 json 格式进行定义，一个典型的 Schema 如下：这里要介绍一点背景知识，Avro 的一个重要特性就是支持 Schema 演化，它定义了一系列的演化规则，只要符合该规则，使用不同的 Schema 也能够正常通信。也就是说，使用 Avro 作为数据格式进行通信的双方是有自由更迭 Schema 的空间的。 24 | 25 | 在我们的场景中，数据库表的 Schema 变更会引起对应的变更数据 Schema 变更，而每次进行数据库表 Schema 变更就更新下游消费端显然是不可能的。所以这时候 Avro 的 Schema 演化机制就很重要了。我们做出约定，同一个 Topic 上传输的消息，其 Avro Schema 的变化必须符合演化规则，这么一来，消费者一旦开始正常消费之后就不会因为消息的 Schema 变化而挂掉。 26 | -------------------------------------------------------------------------------- /99~参考资料/《Designing Data-Intensive Application》/原书翻译/README.md: -------------------------------------------------------------------------------- 1 | > [原文地址](https://vonng.github.io/ddia/#/preface) 2 | 3 | # [DDIA](https://vonng.github.io/ddia/#/preface) 4 | 5 | 如果近几年从业于软件工程，特别是服务器端和后端系统开发，那么你很有可能已经被大量关于数据存储和处理的时髦词汇轰炸过了： NoSQL！大数据！Web-Scale！分片！最终一致性！ACID！ CAP 定理！云服务！MapReduce！实时！ 6 | 7 | 在最近十年中，我们看到了很多有趣的进展，关于数据库，分布式系统，以及在此基础上构建应用程序的方式。这些进展有着各种各样的驱动力： 8 | 9 | - 谷歌、雅虎、亚马逊、脸书、领英、微软和推特等互联网公司正在和巨大的流量 / 数据打交道，这迫使他们去创造能有效应对如此规模的新工具。 10 | - 企业需要变得敏捷，需要低成本地检验假设，需要通过缩短开发周期和保持数据模型的灵活性，快速地响应新的市场洞察。 11 | - 免费和开源软件变得非常成功，在许多环境中比商业软件和定制软件更受欢迎。 12 | - 处理器主频几乎没有增长，但是多核处理器已经成为标配，网络也越来越快。这意味着并行化程度只增不减。 13 | - 即使你在一个小团队中工作，现在也可以构建分布在多台计算机甚至多个地理区域的系统，这要归功于譬如亚马逊网络服务（AWS）等基础设施即服务（IaaS）概念的践行者。 14 | - 许多服务都要求高可用，因停电或维护导致的服务不可用，变得越来越难以接受。 15 | 16 | **数据密集型应用（data-intensive applications）** 正在通过使用这些技术进步来推动可能性的边界。一个应用被称为 **数据密集型** 的，如果 **数据是其主要挑战**（数据量，数据复杂度或数据变化速度）—— 与之相对的是 **计算密集型**，即处理器速度是其瓶颈。 17 | 18 | 帮助数据密集型应用存储和处理数据的工具与技术，正迅速地适应这些变化。新型数据库系统（“NoSQL”）已经备受关注，而消息队列，缓存，搜索索引，批处理和流处理框架以及相关技术也非常重要。很多应用组合使用这些工具与技术。 19 | 20 | 这些生意盎然的时髦词汇体现出人们对新的可能性的热情，这是一件好事。但是作为软件工程师和架构师，如果要开发优秀的应用，我们还需要对各种层出不穷的技术及其利弊权衡有精准的技术理解。为了获得这种洞察，我们需要深挖时髦词汇背后的内容。 21 | 22 | 幸运的是，在技术迅速变化的背后总是存在一些持续成立的原则，无论你使用了特定工具的哪个版本。如果你理解了这些原则，就可以领会这些工具的适用场景，如何充分利用它们，以及如何避免其中的陷阱。这正是本书的初衷。 23 | 24 | 本书的目标是帮助你在飞速变化的数据处理和数据存储技术大观园中找到方向。本书并不是某个特定工具的教程，也不是一本充满枯燥理论的教科书。相反，我们将看到一些成功数据系统的样例：许多流行应用每天都要在生产中满足可伸缩性、性能、以及可靠性的要求，而这些技术构成了这些应用的基础。 25 | 26 | 我们将深入这些系统的内部，理清它们的关键算法，讨论背后的原则和它们必须做出的权衡。在这个过程中，我们将尝试寻找 **思考** 数据系统的有效方式 —— 不仅关于它们 **如何** 工作，还包括它们 **为什么** 以这种方式工作，以及哪些问题是我们需要问的。 27 | 28 | 阅读本书后，你能很好地决定哪种技术适合哪种用途，并了解如何将工具组合起来，为一个良好应用架构奠定基础。本书并不足以使你从头开始构建自己的数据库存储引擎，不过幸运的是这基本上很少有必要。你将获得对系统底层发生事情的敏锐直觉，这样你就有能力推理它们的行为，做出优秀的设计决策，并追踪任何可能出现的问题。 29 | 30 | ## [本书纲要](https://vonng.github.io/ddia/#/preface?id=本书纲要) 31 | 32 | 本书分为三部分： 33 | 34 | 1. 在 [第一部分](https://vonng.github.io/ddia/#/part-i) 中，我们会讨论设计数据密集型应用所赖的基本思想。我们从 [第一章](https://vonng.github.io/ddia/#/ch1) 开始，讨论我们实际要达到的目标：可靠性、可伸缩性和可维护性；我们该如何思考这些概念；以及如何实现它们。在 [第二章](https://vonng.github.io/ddia/#/ch2) 中，我们比较了几种不同的数据模型和查询语言，看看它们如何适用于不同的场景。在 [第三章](https://vonng.github.io/ddia/#/ch3) 中将讨论存储引擎：数据库如何在磁盘上摆放数据，以便能高效地再次找到它。[第四章](https://vonng.github.io/ddia/#/ch4) 转向数据编码（序列化），以及随时间演化的模式。 35 | 2. 在 [第二部分](https://vonng.github.io/ddia/#/part-ii) 中，我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可伸缩性通常是必需的，但带来了各种独特的挑战。我们首先讨论复制（[第五章](https://vonng.github.io/ddia/#/ch5)）、分区 / 分片（[第六章](https://vonng.github.io/ddia/#/ch6)）和事务（[第七章](https://vonng.github.io/ddia/#/ch7)）。然后我们将探索关于分布式系统问题的更多细节（[第八章](https://vonng.github.io/ddia/#/ch8)），以及在分布式系统中实现一致性与共识意味着什么（[第九章](https://vonng.github.io/ddia/#/ch9)）。 36 | 3. 在 [第三部分](https://vonng.github.io/ddia/#/part-iii) 中，我们讨论那些从其他数据集衍生出一些数据集的系统。衍生数据经常出现在异构系统中：当没有单个数据库可以把所有事情都做的很好时，应用需要集成几种不同的数据库、缓存、索引等。在 [第十章](https://vonng.github.io/ddia/#/ch10) 中我们将从一种衍生数据的批处理方法开始，然后在此基础上建立在 [第十一章](https://vonng.github.io/ddia/#/ch11) 中讨论的流处理。最后，在 [第十二章](https://vonng.github.io/ddia/#/ch12) 中，我们将所有内容汇总，讨论在将来构建可靠、可伸缩和可维护的应用程序的方法。 37 | -------------------------------------------------------------------------------- /03~数仓建模/README.md: -------------------------------------------------------------------------------- 1 | # 数据仓库 2 | 3 | 数据仓库（Data Warehouse）,可简写为 DW 或 DWH；数据仓库，是为了企业所有级别的决策制定计划过程，提供所有类型数据类型的战略集合。它出于分析性报告和决策支持的目的而创建。为需要业务智能的企业，为需要指导业务流程改进、监视时间，成本，质量以及控制等支持。 4 | 5 | 一个企业可能有几十个不同的交易处理系统：面向终端客户的网站，控制实体商店的收银系统，跟踪仓库库存，规划车辆路线，供应链管理，员工管理等。这些系统中每一个都很复杂，需要专人维护，所以系统最终都是自动运行的。这些 OLTP 系统往往对业务运作至关重要，因而通常会要求 高可用 与 低延迟。所以 DBA 会密切关注他们的 OLTP 数据库，他们通常不愿意让业务分析人员在 OLTP 数据库上运行临时分析查询，因为这些查询通常开销巨大，会扫描大部分数据集，这会损害同时执行的事务的性能。 6 | 7 | 相比之下，数据仓库是一个独立的数据库，分析人员可以查询他们想要的内容而不影响 OLTP 操作。数据仓库包含公司各种 OLTP 系统中所有的只读数据副本。从 OLTP 数据库中提取数据（使用定期的数据转储或连续的更新流），转换成适合分析的模式，清理并加载到数据仓库中。将数据存入仓库的过程称为“抽取-转换-加载（ETL）”。 8 | 9 | ![ETL至数据仓库的简化提纲](https://s2.ax1x.com/2020/02/06/1yt8hR.md.png) 10 | 11 | > 数据仓库中很多的内容都涉及到[《分布式数据处理》](https://github.com/wx-chevalier/DistributedSystem-Notes)，请自行参阅。 12 | 13 | # 数仓特性 14 | 15 | 数据仓库能够极大地辅助商业智能决策，譬如年度销售目标的制定，需要根据以往的历史报表进行决策，不能随便制定。某电商平台某品牌的手机，在过去 5 年主要的的购买人群的年龄在什么年龄段，在那个季节购买量人多，这样就可以根据这个特点为目标人群设定他们主要的需求和动态分配产生的生产量，和仓库的库存。 16 | 17 | ## 面向主题 18 | 19 | 与传统的数据库不一样，数据仓库是面向主题的，那什么是主题呢？首页主题是一个较高乘次的概念，是较高层次上企业信息系统中的数据综合，归类并进行分析的对象。在逻辑意义上，他是对企业中某一个宏观分析领域所涉及的分析对象。 20 | 21 | 就是用户用数据仓库进行决策所关心的重点方面，一个主题通常与多个操作信息型系统有关，而操作型数据库的数据组织面向事务处理任务，各个任务之间是相互隔离的。 22 | 23 | ## 数据集成 24 | 25 | 数据仓库的数据是从原来的分散的数据库数据（mysql 等关系型数据库）抽取出来的。操作型数据库与 DSS（决策支持系统）分析型数据库差别甚大。第一，数据仓库的每一个主题所对应的源数据在所有的各个分散的数据库中，有许多重复和不一样的地方，且来源于不同的联机系统的数据都和不同的应用逻辑捆绑在一起；第二，数据仓库中的综合数据不能从原来有的数据库系统直接得到。因此子在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键，最复杂的一步，所要完成的工作有： 26 | 27 | - 要统计源数据中所有矛盾之处，如字段的同名异议、异名同义、单位不统一，字长不统一等。 28 | - 进行数据的综合和计算。数据仓库中的数据综合工作可以在原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。 29 | 30 | ## 时序数据 31 | 32 | 数据仓库的数据是随着时间的变化而变化的，数据仓库中的数据不可更新是针对应用来说的，也就是说，数据仓库的用户进行分析处理是不进行数据更新操作的。但并不是说，在从数据集成输入数据仓库开始到最后被删除的整个生存周期中，所有的数据仓库数据都是永远不变的。 33 | 34 | 数据仓库的数据是随着时间变化而变化的，这是数据仓库的特征之一。这一特征主要有以下三个表现： 35 | 36 | - 数据仓库随着时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉 OLTP 数据库中变化的数据，追加到数据仓库当中去，也就是要不断的生成 OLTP 数据库的快照，经统一集成增加到数据仓库中去；但对于确实不在变化的数据库快照，如果捕捉到新的变化数据，则只生成一个新的数据库快照增加进去，而不会对原有的数据库快照进行修改。 37 | 38 | - 数据库随着时间变化不断删去旧的数据内容。数据仓库内的数据也有存储期限，一旦过了这一期限，过期数据就要被删除。只是数据库内的数据时限要远远的长于操作型环境中的数据时限。在操作型环境中一般只保存有 60~90 天的数据，而在数据仓库中则要需要保存较长时限的数据（例如：5~10 年），以适应 DSS 进行趋势分析的要求。 39 | 40 | - 数据仓库中包含有大量的综合数据，这些综合数据中很多跟时间有关，如数据经常按照时间段进行综合，或隔一定的时间片进行抽样等等。这些数据要随着时间的变化不断地进行从新综合。因此数据仓库的数据特征都包含时间项，以标明数据的历史时期。 41 | 42 | ## 不可变性 43 | 44 | 数据仓库的数据主要提供企业决策分析之用，所涉及的数据操作主要是数据查询，一般情况下并不进行修改操作。数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。数据库中进行联机处理的书库进过集成输入到数据仓库中，一旦数据仓库存放的数据已经超过数据仓库的数据存储期限，这些数据将从当前的数据仓库中删去。 45 | 46 | 因为数据仓库只进行数据查询操作，所以数据仓库当中的系统要比数据库中的系统要简单的多。数据库管理系统中许多技术难点，如完整性保护、并发控制等等，在数据仓库的管理中几乎可以省去。但是由于数据仓库的查询数据量往往很大，所以就对数据查询提出了更高的要求，他要求采用各种复杂的索引技术；同时数据仓库面向的是商业企业的高层管理层，他们会对数据查询的界面友好性和数据表示提出更高的要求。 47 | 48 | # 建设难点 49 | 50 | 数据仓库建设难点： 51 | 52 | - 数据孤岛、烟囱式重复建设 缺少公共数据的提炼和汇总，出现烟囱式重复建设，同时也加剧了数据孤岛的问题。 53 | - 数据不一致 孤岛式的建设，缺少统一的组织及方法论，指标口径不统一、数据表级字段名不一致，数据有二义性 54 | - 缺少统一模型规范 当不同业务之间有数据交叉的场景时，为了尽快响应业务需求，直接从其他业务明细层甚至原始数据层获取数据，不同的研发团队不同规范，造成模型设计不统一，复用性差。 55 | - 效率差、响应慢 缺少公共聚合数据的沉淀和积累，每次新的需求都需要 5-7 天以上的研发，无法服用，产出时效差，数据质量低，资源消耗成本高居不下 56 | 57 | # Links 58 | 59 | - http://webdataanalysis.net/web-data-warehouse/ 网站数据仓库 60 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![Contributors][contributors-shield]][contributors-url] 2 | [![Forks][forks-shield]][forks-url] 3 | [![Stargazers][stars-shield]][stars-url] 4 | [![Issues][issues-shield]][issues-url] 5 | [![license: CC BY-NC-SA 4.0](https://img.shields.io/badge/license-CC%20BY--NC--SA%204.0-lightgrey.svg)][license-url] 6 | 7 | 8 |
9 |

10 | 11 | Logo 12 | 13 | 14 |

15 | 在线阅读 >> 16 |
17 |
18 | 代码案例 19 | · 20 | 参考资料 21 | 22 |

23 |

24 | 25 | # 数据仓库 26 | 27 | 在《[Database-Notes/数据库基础](https://github.com/wx-chevalier/Database-Notes?q=)》中我们讨论了数据仓库的基础理论知识，本章则着眼于如何实践数据仓库的相关应用。 28 | 29 | ## Nav | 关联导航 30 | 31 | - 如果你想了解微服务/云原生等分布式系统的应用实践，可以参阅；如果你想了解数据库相关，可以参阅 [Database-Notes](https://github.com/wx-chevalier/Database-Notes)；如果你想了解虚拟化与云计算相关，可以参阅 [Cloud-Notes](https://github.com/wx-chevalier/Cloud-Notes)；如果你想了解 Linux 与操作系统相关，可以参阅 [Linux-Notes](https://github.com/wx-chevalier/Linux-Notes)。 32 | 33 | # Links 34 | 35 | - 万字详解整个数据仓库建设体系 https://cubox.pro/c/CHuVAT 提取关键内容 36 | 37 | # About 38 | 39 | ## Copyright & More | 延伸阅读 40 | 41 | 笔者所有文章遵循 [知识共享 署名-非商业性使用-禁止演绎 4.0 国际许可协议](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh)，欢迎转载，尊重版权。您还可以前往 [NGTE Books](https://ng-tech.icu/books-gallery/) 主页浏览包含知识体系、编程语言、软件工程、模式与架构、Web 与大前端、服务端开发实践与工程架构、分布式基础架构、人工智能与深度学习、产品运营与创业等多类目的书籍列表： 42 | 43 | [![NGTE Books](https://s2.ax1x.com/2020/01/18/19uXtI.png)](https://ng-tech.icu/books-gallery/) 44 | 45 | 46 | 47 | 48 | [contributors-shield]: https://img.shields.io/github/contributors/wx-chevalier/DistributedSystem-Notes.svg?style=flat-square 49 | [contributors-url]: https://github.com/wx-chevalier/DistributedSystem-Notes/graphs/contributors 50 | [forks-shield]: https://img.shields.io/github/forks/wx-chevalier/DistributedSystem-Notes.svg?style=flat-square 51 | [forks-url]: https://github.com/wx-chevalier/DistributedSystem-Notes/network/members 52 | [stars-shield]: https://img.shields.io/github/stars/wx-chevalier/DistributedSystem-Notes.svg?style=flat-square 53 | [stars-url]: https://github.com/wx-chevalier/DistributedSystem-Notes/stargazers 54 | [issues-shield]: https://img.shields.io/github/issues/wx-chevalier/DistributedSystem-Notes.svg?style=flat-square 55 | [issues-url]: https://github.com/wx-chevalier/DistributedSystem-Notes/issues 56 | [license-shield]: https://img.shields.io/github/license/wx-chevalier/DistributedSystem-Notes.svg?style=flat-square 57 | [license-url]: https://github.com/wx-chevalier/DistributedSystem-Notes/blob/master/LICENSE.txt 58 | -------------------------------------------------------------------------------- /03~数仓建模/02~多维数据模型/02~星型与雪花模型/README.md: -------------------------------------------------------------------------------- 1 | # 星型与雪花模型 2 | 3 | 在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。 4 | 5 | # 星型模型 6 | 7 | “星型模式”这个名字来源于这样一个事实，即当表关系可视化时，事实表在中间，由维表包围；与这些表的连接就像星星的光芒。 8 | 9 | 当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。 10 | 11 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510135508.png) 12 | 13 | 下例模式显示了可能在食品零售商处找到的数据仓库。在模式的中心是一个所谓的事实表（在这个例子中，它被称为 fact_sales）。事实表的每一行代表在特定时间发生的事件（这里，每一行代表客户购买的产品）。如果我们分析的是网站流量而不是零售量，则每行可能代表一个用户的页面浏览量或点击量。 14 | 15 | ![用于数据仓库的星型模式的示例](https://s2.ax1x.com/2020/02/06/1ytRu8.png) 16 | 17 | 通常情况下，事实被视为单独的事件，因为这样可以在以后分析中获得最大的灵活性。但是，这意味着事实表可以变得非常大。像苹果，沃尔玛或 eBay 这样的大企业在其数据仓库中可能有几十 PB 的交易历史，其中大部分实际上是表。 18 | 19 | 事实表中的一些列是属性，例如产品销售的价格和从供应商那里购买的成本（允许计算利润余额）。事实表中的其他列是对其他表（称为维表）的外键引用。由于事实表中的每一行都表示一个事件，因此这些维度代表事件的发生地点，时间，方式和原因。 20 | 21 | 例如上图中其中一个维度是已售出的产品 dim_product 表中的每一行代表一种待售产品，包括库存单位（SKU），说明，品牌名称，类别，脂肪含量，包装尺寸等。fact_sales 表中的每一行都使用外部表明在特定交易中销售了哪些产品。为了简单起见，如果客户一次购买几种不同的产品，则它们在事实表中被表示为单独的行 22 | 23 | 即使日期和时间通常使用维度表来表示，因为这允许对日期（诸如公共假期）的附加信息进行编码，从而允许查询区分假期和非假期的销售。 24 | 25 | # 雪花模型 26 | 27 | 星型模型的变体被称为雪花模式，其中尺寸被进一步分解为子尺寸。例如，品牌和产品类别可能有单独的表格，并且 dim_product 表格中的每一行都可以将品牌和类别作为外键引用，而不是将它们作为字符串存储在 dim_product 表格中。雪花模式比星形模式更规范化，但是星形模式通常是首选，因为分析师使用它更简单。 28 | 29 | 在典型的数据仓库中，表格通常非常宽泛：事实表格通常有 100 列以上，有时甚至有数百列。维度表也可以是非常宽的，因为它们包括可能与分析相关的所有元数据——例如，dim_store 表可以包括在每个商店提供哪些服务的细节，它是否具有店内面包房，方形镜头，商店第一次开幕的日期，最后一次改造的时间，离最近的高速公路的距离等等。 30 | 31 | 当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如下图，将地域维表又分解为国家，省份，城市等维表。它的优点是: 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。 32 | 33 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510140223.png) 34 | 35 | 星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。 36 | 37 | # 模型选择分析 38 | 39 | 雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?” 40 | 41 | ## 数据优化 42 | 43 | 雪花模型使用的是规范化数据，也就是说数据在数据库内部是组织好的，以便消除冗余，因此它能够有效地减少数据量。通过引用完整性，其业务层级和维度都将存储在数据模型之中。相比较而言，星形模型实用的是反规范化数据。在星形模型中，维度直接指的是事实表，业务层级不会通过维度之间的参照完整性来部署。 44 | 45 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510140201.png) 46 | 47 | ## 业务模型 48 | 49 | 主键是一个单独的唯一键(数据属性)，为特殊数据所选择。在上面的例子中，Advertiser_ID 就将是一个主键。外键(参考属性)仅仅是一个表中的字段，用来匹配其他维度表中的主键。在我们所引用的例子中，Advertiser_ID 将是 Account_dimension 的一个外键。 50 | 51 | 在雪花模型中，数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中，所有必要的维度表在事实表中都只拥有外键。 52 | 53 | ## 性能 54 | 55 | 第三个区别在于性能的不同。雪花模型在维度表、事实表之间的连接很多，因此性能方面会比较低。举个例子，如果你想要知道 Advertiser 的详细信息，雪花模型就会请求许多信息，比如 Advertiser Name、ID 以及那些广告主和客户表的地址需要连接起来，然后再与事实表连接。 56 | 57 | 而星形模型的连接就少的多，在这个模型中，如果你需要上述信息，你只要将 Advertiser 的维度表和事实表连接即可。 58 | 59 | ## ETL 60 | 61 | 雪花模型加载数据集市，因此 ETL 操作在设计上更加复杂，而且由于附属模型的限制，不能并行化。星形模型加载维度表，不需要再维度之间添加附属模型，因此 ETL 就相对简单，而且可以实现高度的并行化。 62 | -------------------------------------------------------------------------------- /01~大数据体系/02~数据治理原则/原则与要素.md: -------------------------------------------------------------------------------- 1 | # 零散化存放 2 | 3 | 当今的大型企业，内部分工日趋细化，采购、服务、市场、销售、开发、支持、物流、财务、人力等各个环节，无不每时每刻产生着大量的数据。数据的格式也越来越多样化，包括 IT 系统里存储的结构化、非结构化数据，各样电子文档数据等。与此同时，企业管理者对数据的困惑也与日俱增，这些数据从哪里来？我们能相信这些数据吗？数据之间有什么样的关系？谁能理解这些数据？ 4 | 5 | 零散化存放是数据问题根源，造成上述情况最根本的原因是：数据零散化存放。大型企业在不同发展阶段，会根据业务需求建设很多内部 IT 支撑系统，比如 ERP（企业资源计划）系统、CRM（客户服务管理）系统、财务管理系统等，这些系统的分散建设，数据割裂，造成了数据零散化存放的现状。基于数据作分析，首先需要数据的聚合，但由于生产系统和数据的离散化，造成了数据标准、数据模型不统一，因而企业最需要做的就是对数据整合和标准化。 6 | 7 | 根据 DAMA（国际数据管理协会）的定义，数据治理（DG，Data Governance）是指对数据资产的管理活动行使权力和控制的活动集合（规划、监控和执行）。大数据治理，即基于大数据的数据治理。大数据，一般指符合 4V 特征的数据，包括社交数据、机器数据等，大数据对传统数据治理工作带来很多的扩展，在政策/流程上，大数据治理应覆盖大数据的获取、处理、存储、安全等环节，需要为大数据设置数据管理专员制度；需考虑大数据与主数据管理能力的集成，需要对大数据做定义，统一主数据标准；在数据生命周期管理各阶段，如数据存储、保留、归档、处置时，要考虑大数据保存时间与存储空间的平衡，大数据量大，因此应识别对业务有关键影响的数据元素，检查和保证数据质量。此外，在隐私方面，应考虑社交数据的隐私保护需求，制定相应政策，还要将大数据治理与企业内外部风险管控需求建立联系。 8 | 9 | # 大数据治理的商业价值 10 | 11 | 企业只有建立了完整的大数据治理体系，保证数据的质量，才能够真正有效地挖掘企业内部的数据价值，对外提高竞争力。 12 | 13 | 首先，高质量数据是企业业务创新、管理决策的基础。随着互联网企业对其他各行业的冲击，加剧了市场的竞争，许多企业面临收入增速放缓、利润空间逐步缩小的局面，过去单纯的外延式增长已经难以为继。因此，必须向外延与内涵相结合的增长方式转变，未来效益的提升很大程度上要依靠企业的内部挖潜实现，这从客观上对企业的创新能力提出了更高的要求，而提升企业内部数据管理的精细化水平，是企业开展业务创新和管理决策的重要基础，能够为企业创造巨大效益。 14 | 15 | 其次，标准化的数据是优化商业模式、指导生产经营的前提。许多企业的 IT 系统经历了数据量高速膨胀的时期，这些海量的、分散在不同角落的数据导致了数据资源利用的复杂性和管理的高难度，形成了一个个系统竖井。系统之间的关系、标准化数据从哪里获取都无从知晓，通过数据治理工作，可以对分散在各系统中的数据提供一套统一的数据命名、数据定义、数据类型、赋值规则等的定义基准，通过数据标准化可以防止数据的混乱使用，确保数据的正确性及质量，并可以优化商业模式，指导企业生产经营工作。 16 | 17 | 最后，多角度、全方位的数据是企业开展市场营销、争夺客户资源的关键。数据已成为企业最核心的隐形财富，谁掌握了准确的数据谁就能获得先机，在当前竞争日益激烈的市场上，企业如何在不同的细分市场构建客户画像、开展精准营销，如何选择竞争策略、进行经营管理决策，都必须基于 360 度全方位、准确的客户数据加以分析判断才能得出。 18 | 19 | # 核心要素 20 | 21 | - 明确数据治理责任，建立数据治理组织 22 | 23 | 数据出了问题，到底是谁的责任？因为数据主要是 IT 系统产生的，所以一直以来，解决数据问题都被认为是 IT 部门的职责。而 IT 部门也饱受其苦，数据定义和业务规则，业务部门最清楚；数据录入，业务人员负责；数据使用，业务人员是用户；数据考核，业务部门有权力……但实际上，要切实解决数据问题，开展数据治理工作，就必须先清楚一点：数据治理，是业务部门和 IT 部门共同的职责。值得一提的是，越来越多的企业开始重视数据治理工作，一些企业高管团队中也产生了一个全新的职位——首席数据官（CDO），是组织内大数据战略的制定者和推动者，负责组织内数据资产的开发和利用，通过数据推动组织业务的创新和发展，通常直接汇报给 CEO 或 CIO。 24 | 25 | - 管理出成效，制度是保障 26 | 27 | 大数据治理需要管理和制度的有力支撑，可结合企业的现状，制定相应的管理办法、管理流程、认责体系、人员角色和岗位职责等，颁布相关的数据治理的企业规章制度等。 28 | 29 | - 数据规范：没有规矩，不成方圆 30 | 31 | 数据规范是指对企业核心数据进行有关存在性、完整性、质量及归档的测量标准，为评估企业数据质量，并且为手动录入、设计数据加载程序、更新信息以及开发应用软件提供的约束性规则，数据规范一般包括数据标准、数据模型、业务规则、元数据、主数据和参考数据。 32 | 33 | 制定数据标准的目的是为了使业务人员、技术人员在提到同一个指标、名词、术语的时候有一致的含义。数据模型对企业运营过程中涉及的业务概念和逻辑规则进行统一定义。业务规则是一种权威性原则或指导方针，用来描述业务交互，并建立行动和数据行为结果及完整性的规则。元数据能够帮助增强数据理解，可以架起企业内业务与 IT 部门之间的桥梁。主数据用来描述参与组织业务的人员、地点和事物。参考数据是系统、应用软件、数据库、流程、报告中及交易记录中用来参考的数值集合或分类表。 34 | 35 | - 数据治理活动，理论结合实践 36 | 37 | 数据治理活动是指为实现数据资产价值的获取、控制、保护、交付以及提升，对数据规范所做的计划、执行和监督工作，一般包括以下活动。 38 | 39 | 数据架构管理，用于定义企业数据需求，设计实现数据需求的主要蓝图，通常包括数据标准管理、数据模型管理、数据集成架构等；数据质量管理，指通过计划、实施和控制活动，运用质量管理技术度量、评估、改进和保证数据的恰当使用；元数据管理，指通过计划、实施和控制活动，以实现轻松访问高质量和整合的元数据；数据安全管理，指通过计划、制定并执行数据安全政策和措施，为数据和信息提供适当的认证、授权、访问和审计；参考数据和主数据管理，指通过计划、实施和控制活动，达到保证参考数据与主数据的一致性。 40 | 41 | - 数据治理软件：工欲善其事，必先利其器 42 | 43 | 目前业界流行的数据治理软件，一般也称为数据资产管理产品、数据治理产品，主要包括的功能组件有元数据管理工具、数据标准管理工具、数据模型管理工具、数据质量管理工具、主数据管理工具、数据安全管理工具等。 44 | 45 | 利用数据治理软件主要解决企业不同来源数据集成过程中遇到的问题，需要数据治理软件能够为企业提供统一的元数据集成、数据标准管理、数据模型设计、数据质量稽核、数据资产目录、数据分析服务等能力。 46 | 47 | 基于大数据的人工智能时代的到来，为各行业带来基于数据资产进行业务创新、管理创新的契机，伴随着企业数字化转型过程，越来越多的数据被收集，大数据治理将为企业提供更全面更准确的数据，届时人类的大部分行为将可以被计算和预测，这种对社会成员的行为逻辑、社会事件的发展态势提前作出判断、预测和模拟，将使社会治理模式得到极大变革，从而极可能推动社会治理也由传统的人类精英经验治理向基于大数据的智能化治理转型。 48 | -------------------------------------------------------------------------------- /04~数据可视化/README.md: -------------------------------------------------------------------------------- 1 | # 数据可视化与 BI 2 | 3 | [大数据汇聚](https://ng-tech.icu/books/DistributedSystem-Notes/#/?q=大数据)、[数据处理与分析](https://ngte-aidl.gitbook.io/?q=数据处理)、《[CG-Notes](https://github.com/wx-chevalier/CG-Notes?q=)》这三者构成了数据科学的主要流程，本篇数据可视化更多地关注于数据展示相关的技术知识。 4 | 5 | # 可视化定义 6 | 7 | 数据可视化研究的是，如何将数据转化成为交互的图形或图像等，以视觉可以感受的方式表达，增强人的认知能力，达到发现、解释、分析、探索、决策和学习的目的。《数据可视化之美》一书中阐述道：数据可视化（Data Visualization）和信息可视化（Infographics）是两个相近的专业领域名词。狭义上的数据可视化指的是数据用统计图表方式呈现，而信息可视化则是将非数字的信息进行可视化。前者用于传递信息，后者用于表现抽象或复杂的概念、技术和信息。而广义上的数据可视化则是数据可视化、信息可视化以及科学可视化等等多个领域的统称。 8 | 9 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230420133508.png) 10 | 11 | 科学可视化（Scientific Visualization）、信息可视化（Information Visualization）和可视分析学（Visual Analytics）三个学科方向通常被看成可视化的三个主要分支。这三个分支整合在一起形成的新学科“数据可视化”，是可视化研究领域的新起点。 12 | 13 | ## 科学可视化 14 | 15 | 科学可视化（Scientific Visualization）是可视化领域最早、最成熟的一个跨学科研究与应用领域[石教英 1996]。面向的领域主要是自然科学，如物理、化学、气象气候、航空航天、医学、生物学等各个学科，这些学科通常需要对数据和模型进行解释、操作与处理，旨在寻找其中的模式、特点、关系以及异常情况[Schroeder2004]。 16 | 17 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510141035.png) 18 | 19 | ## 信息可视化 20 | 21 | 信息可视化（Information Visualization）处理的对象是抽象数据集合，起源于统计图形学，又与信息图形、视觉设计等现代技术相关。其表现形式通常在二维空间，因此关键问题是在有限的展现空间中以直观的方式传达大量的抽象信息。与科学可视化相比，科学可视化处理的数据具有天然几何结构（如磁感线、流体分布等），信息可视化更关注抽象、高维数据。柱状图、趋势图、流程图、树状图等，都属于信息可视化最常用的可视表达，这些图形的设计都将抽象的数据概念转化成为可视化信息。 22 | 23 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510141017.png) 24 | 25 | ## 可视分析学 26 | 27 | 可视分析学（Visual Analytics）被定义为一门以可视交互为基础的分析推理科学[Thomas2005]。它综合了图形学、数据挖掘和人机交互等技术，以可视交互界面为通道，将人感知和认知能力以可视的方式融入数据处理过程，形成人脑智能和机器智能优势互补和相互提升，建立螺旋式信息交流与知识提炼途径，完成有效的分析推理和决策。 28 | 29 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510140958.png) 30 | 31 | # 可视化流程 32 | 33 | 数据可视化的本质是将数据通过各种视觉通道映射成图形，可以使得用户更快、更准确的理解数据。因此数据可视化要解决的问题是如何将数据通过视觉可观测的方式表达出来，同时需要考虑美观、可理解性，需要解决在展示的空间（画布）有限的情况下覆盖、杂乱、冲突等问题，再以交互的形式查看数据的细节。 34 | 35 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510140938.png) 36 | 37 | 整个可视化流程，可以抽象地分为视觉编码与视觉通道两部分： 38 | 39 | - 视觉编码描述的是将数据映射到最终可视化结果上的过程。这里的可视化结果可能是图标，图片，也可能是一张网页等等；数据映射指把我们要分析的数据转换成可视化结果可以展示的数据,比如在把业务数据转换成 ECharts 或者 G2 Chart，为展示的数据封装了一些组件。 40 | 41 | - 视觉通道是利用几何图形的尺寸、数值、纹理、颜色、方向和形状来表示数据的图形，后来人们又补充了长度、面积、体积、透明度、模糊/聚焦、动画等特征；通过这些特征最终呈现的图形主要有散点图、条形图、直方图、饼形图、线形图和累计图等。 42 | 43 | 数据可视化过程可以分为下面几个步骤： 44 | 45 | - 定义要解决问题 46 | - 确定要展示的数据和数据结构 47 | - 确定要展示的数据的维度（字段） 48 | - 确定使用的图表类型 49 | - 确定图表的交互 50 | 51 | ## 问题定义 52 | 53 | 首先明确数据可视化是要让用户看懂数据，理解数据。所以开始数据可视化前一定要定义通要解决的问题。例如：我想看过去两周销售额的变化，是增长了还是下跌了，什么原因导致的？你可以从 趋势、对比、分布、流程、时序、空间、关联性等角度来定义自己要解决的问题。 54 | 55 | ## 数据选择 56 | 57 | 进行数据可视化首先要有数据，由于画布大小的限制，过量的数据不能够在直接显示出来，所以要确定展示的数据： 58 | 59 | - 我要展示的数据是否已经加工好，是否存在空值？ 60 | - 是列表数据还是树形数据？ 61 | - 数据的规模有多大？ 62 | - 是否要对数据进行聚合，是否要分层展示数据？ 63 | - 如何加载到页面，是否需要在前端对数据处理？ 64 | 65 | ## 维度选择 66 | 67 | 进行可视化时要对字段进行选择，选择不同的字段在后面环节中选择适合的图表类型也不同。 68 | 69 | ## 图表选择 70 | 71 | 视觉编码设计的原则： 72 | 73 | - 表达性、一致性：可视化的结果应该充分表达了数据想要表达的信息，且没有多余。 74 | - 有效性、理解性：可视化之后比前一种数据表达方案更加有效，更加容易让人理解。 75 | 76 | ![](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230510140627.png) 77 | 78 | # 数据可视化场景 79 | 80 | - 通用报表 81 | - 移动端图表 82 | - 大屏可视化 83 | - 图编辑与图分析 84 | - 地理可视化 85 | 86 | # Links 87 | 88 | - https://zhuanlan.zhihu.com/p/24835341 89 | -------------------------------------------------------------------------------- /02~数据集成/DataPipeline/README.md: -------------------------------------------------------------------------------- 1 | # Data Pipeline | 实时数据集成平台 2 | 3 | 传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 4 | 5 | ![批流对比](https://tva4.sinaimg.cn/large/005R6Otmgy1g7b1zsx4q3j30ni0d6wfe.jpg) 6 | 7 | 另一种是 Data Pipeline 模式。与批模式相比相比，其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎，进行各种聚合运算，产生输出结果，并且写入下游。现代的一些处理框架，包括 Flink、Kafka Streams、Spark，或多或少都能够支持批和流两种概念。换言之，流式处理能力是实时数据集成平台必要的组件；结合企业技术栈特点，选用包括 Flink、Spark Streaming、Kafka Streams 等流行的引擎在多数情况下都能够满足要求。端到端数据的 EOS 是数据集成中的一个难题，需要用户根据业务实际需求、数据本身的特性、目的地特点 case by case 去解决。 8 | 9 | ## 系统挑战 10 | 11 | 如果问题简化到一张 MySQL 的表，里面只有几百万行数据，你可能想将其同步到一张 Hive 表中。基于这种情况，大部分问题都不会遇到。因为结构是确定的，数据量很小，且没有所谓的并行化问题。但在一个实际的企业场景下，如果做一个数据融合系统，就不可避免要面临几方面的挑战： 12 | 13 | - 动态性: 数据源会不断地发生变化，主要归因于：表结构的变化，表的增减。针对这些情况，你需要有一些相应的策略进行处理。 14 | 15 | - 可伸缩性: 任何一个分布式系统，必须要提供可伸缩性。因为你不是只同步一张表，通常会有大量数据同步任务在进行着。如何在一个集群或多个集群中进行统一的调度，保证任务并行执行的效率，这是一个要解决的基本问题。 16 | 17 | - 容错性: 在任何环境里你都不能假定服务器是永远在正常运行的，网络、磁盘、内存都有可能发生故障。这种情况下一个 Job 可能会失败，之后如何进行恢复？状态能否延续？是否会产生数据的丢失和重复？这都是要考虑的问题。 18 | 19 | - 异构性: 当我们做一个数据融合项目时，由于源和目的地是不一样的，比如，源是 MySQL，目的地是 Oracle，可能它们对于一个字段类型定义的标准是有差别的。在同步时，如果忽略这些差异，就会造成一系列的问题。 20 | 21 | - 一致性: 一致性是数据融合中最基本的问题，即使不考虑数据同步的速度，也要保证数据一致。数据一致性的底线为：数据先不丢，如果丢了一部分，通常会导致业务无法使用；在此基础上更好的情况是：源和目的地的数据要完全一致，即所谓的端到端一致性，如何做到呢？ 22 | 23 | # Lambda 架构 24 | 25 | Lambda 架构的核心是按需使用批量和流式的处理框架，分别针对批式和流式数据提供相应的处理逻辑。最终通过一个服务层进行对外服务的输出。与之相对，还有一种架构叫 Kappa 架构，即用一个流式处理引擎解决所有问题。我们认为 Lambda 架构是批流一体化的必然要求。 26 | 27 | 实际上，这在很大程度来自于现实中用户的需求。DataPipeline 在刚刚成立时只有一种模式，只支持实时流同步，在我们看来这是未来的一种趋势。但后来发现，很多客户实际上有批量同步的需求。比如，银行在每天晚上可能会有一些月结、日结，证券公司也有类似的结算服务。基于一些历史原因，或出于对性能、数据库配置的考虑，可能有的数据库本身不能开 change log。所以实际上并不是所有情况下都能从源端获取实时的流数据。考虑到上述问题，我们认为一个产品在支撑数据融合过程中，必须能同时支撑批量和流式两种处理模式，且在产品里面出于性能和稳定性考虑提供不同的处理策略，这才是一个相对来说比较合理的基础架构。 28 | 29 | ## 数据融合 30 | 31 | 数据源变化捕获是数据集成的起点，结合日志的解析、增量条件查询模式和数据源主动 Push 模式，最终构建出一个数据汇集层。在这个阶段，推荐考虑 Kafka Connect 这类面向数据集成的专有框架，可以有效缩短研发周期和成本。数据汇集层建议构建在消息队列之上，为后继的加工处理提供便利。如果需要全量持久化长期保存，建议结合使用消息队列和分布式文件系统分别做实时数据和全量数据的存储。 32 | 33 | ### Ad-Hoc 模式 34 | 35 | 假如我需要将数据从 MySQL 同步到 Hive，可以直接建立一个 ETL 的 JOB（例如基于 Flink），其中封装所有的处理逻辑，包括从源端读取数据，然后进行变换写入目的地。在将代码编译好以后，就可以放到 Flink 集群上运行，得到想要的结果。这个集群环境可以提供所需要的基础能力，刚才提到的包括分布式，容错等。 36 | 37 | ETL Job 封装所有的处理逻辑，从源端读取，注入数据，将结果写入到目的地，并且完成有状态，无状态的转换。批流处理框架提供了可重用的源与目的地连接器，Operator 与 DAG，以及分布式的环境与容错。 38 | 39 | ### MQ 模式 40 | 41 | 另一种模式是 ETL JOB 本身输入输出实际上都是面对消息队列的，实际上这是现在最常使用的一种模式。在这种模式下，需要通过一些独立的数据源和目的地连接器，来完成数据到消息队列的输入和输出。ETL JOB 可以用多种框架实现，包括 Flink、Kafka Streams 等，ETL JOB 只和消息队列发生数据交换。。DataPipeline 选择 MQ 模式，主要有几点考虑： 42 | 43 | - 要做数据的一对多分发。数据要进行一次读取，然后分发到各种不同的目的地，这是一个非常适合消息队列使用的分发模型。详情见：数据融合重磅功能丨一对多实时分发、批量读取模式 44 | - 有时会对一次读取的数据加不同的处理逻辑，我们希望这种处理不要重新对源端产生一次读取。所以在多数情况下，都需将数据先读到消息队列，然后再配置相应的处理逻辑。 45 | - Kafka Connect 就是基于 MQ 模式的，它有大量的开源连接器。基于 Kafka Connect 框架，我们可以重用这些连接器，节省研发的投入。 46 | - 当你把数据抽取跟写入目的地，从处理逻辑中独立出来之后，便可以提供更强大的集成能力。因为你可以在消息队列上集成更多的处理逻辑，而无需考虑重新写整个 Job。 47 | 48 | 相应而言，如果你选择将 MQ 作为所有 JOB 的传输通道，就必须要克服几个缺点： 49 | 50 | - 所有数据的吞吐都经过 MQ，所以 MQ 会成为一个吞吐瓶颈。 51 | - 因为是一个完全的流式架构，所以针对批量同步，你需要引入一些边界消息来实现一些批量控制。 52 | - Kafka 是一个有持久化能力的消息队列，这意味着数据留存是有极限的。比如，你将源端的读到 Kafka Topic 里面，Topic 不会无限的大，有可能会造成数据容量超限，导致一些数据丢失。 53 | - 当批量同步在中间因为某种原因被打断，无法做续传时，你需要进行重传。在重传过程中，首先要将数据进行清理，如果基于消息队列模式，清理过程就会带来额外的工作。你会面临两个困境：要么清空原有的消息队列，要么你创造新的消息队列。这肯定不如像直接使用一些批量同步框架那样来的直接。 54 | -------------------------------------------------------------------------------- /03~数仓建模/02~多维数据模型/01~事实表、维度表、聚合表/02~维度表.md: -------------------------------------------------------------------------------- 1 | # 维度表 2 | 3 | 维度表可以看作是用户来分析数据的窗口，纬度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。例如，包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构，这些产品中的每一类进一步多次细分，直到各产品达到最低级别。 4 | 5 | 在维度表中，每个表都包含独立于其他维度表的事实 特性，例如，客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。维度表包含了维度的每个成员的特定名称。维度成员的名称称为“属性”(Attribute)。假设 Product 维度中有 3 种产品，那么维度表将如下所示。 6 | 7 | | PROD_ID | Product_Name | 8 | | ------- | ------------ | 9 | | 347 | Mountain-100 | 10 | | 339 | Road-650 | 11 | | 447 | Cable Lock | 12 | 13 | 产品名称是产品成员的一个属性。因为维度表中的 Product ID 与事实表中的 Product ID 相匹配，称为“键属性”。因为每个 Product ID 只有一个 Product Name，显示时用名称来替代整数值，所以它仍然被认为是键属性的一部分。 14 | 15 | 在数据仓库中，维度表中的键属性必须为维度的每个成员包含一个对应的唯一值。用关系型数据库术语描述就是，键属性称为主键列。每个维度表中的主键值都与任何相关的事实表中的键值相关。在维度表中出现一次的每个键值都会在事实表中出现多次。例如 Mountain-100 的 Product ID 347 只在一个维度表数据行中出现，但它会出现在多个事实表数据行中。这称为一对多关系。在事实表中，键值列(它是一对多关系的“多”的一方)称为外键列。关系型数据库使用匹配的主键列(在维度表中)和外键列(在事实表中)值来联接维度表到事实表。 16 | 17 | 把维度信息移动到一个单独的表中，除了使得事实表更小外，还有额外的优点——可以为每个维度成员添加额外的信息。例如，维度表可能为每个产品添加种类(Category)信息，如下所示。 18 | 19 | | PROD_ID | Product_Name | Category | 20 | | ------- | ------------ | ----------- | 21 | | 347 | Mountain-100 | Bikes | 22 | | 339 | Road-650 | Bikes | 23 | | 447 | Cable Lock | Accessories | 24 | 25 | 现在种类是产品的另一个属性。如果知道 Product ID，不但可以推断出 Product Name，而且可以推断出 Category。键属性的名称可能是唯一的——因为每个键只有一个名称，但其他属性不需要是唯一的，例如 Category 属性可能会出现好几次。这样一来，便可以创建按照产品和类别对事实表信息进行分组的报表。除了名称外，维度表可以包含许多其他的属性。本质上，每个属性都对应于维度表中的一个列。下面是带有其他额外属性的只有 3 个成员的 Product 维度表的示例。 26 | 27 | | PROD_ID | Product_Name | Category | Color | Size | Price | 28 | | ------- | ------------ | ----------- | ------ | ---- | ------- | 29 | | 347 | Mountain-100 | Bikes | Black | 44 | 782.99 | 30 | | 339 | Road-650 | Bikes | Silver | 48 | 3399.99 | 31 | | 447 | Cable Lock | Accessories | NA | NA | 25.00 | 32 | 33 | 维度属性可以是可分组的，也可以是不可分组的。换句话就是，您是否见过按照哪个属性来分组度量值的报表？在我们的示例中，Category、Size 和 Color 全都是可分组的属性。由此自然会联想到可能在某个报表中按照颜色、大小或种类来分组销售额。但 Price 看起来不像是可分组的属性——至少它本身不是。在报表中可能会有一个更有意义的其他属性——例如 Price Group，但价格本身变化太大，导致在报表上分组意义不大。同样地，按照 Product Description 属性在报表上进行分组意义也不大。在一个 Customer 维度中，City、Country、Gender 和 Marital Status 都是可以在报表上按照它们进行有意义分组的属性，但 Street Address 或 Nickname 都应当是不可分组的。不可分组的属性通常称为成员属性(member property)。 34 | 35 | ## Hierarchy 与 Level 36 | 37 | 某些可分组的属性可以组合起来创建一个自然层次结构(natural hierarchy)。例如假设 Product 有 Category 和 Subcategory 属性，在多数情况下，单个产品只会属于单个 Subcategory，并且单个 Subcategory 只会属于单个 Category。这将形成一个自然层次结构。在报表中，可能会显示 Categories，然后允许用户从某个 Category 钻取到 Subcategories，以及最终钻取到 Products。 38 | 39 | 层次结构——或者说钻取路径——不一定要是自然的(例如，每个低层次的成员会决定下一个高层次的成员)。例如，您可能会创建一个按照 Color 分组产品的报表，但允许用户根据每个 Color 钻取到每个不同的 Size。因为报表的钻取能力，Color 和 Size 形成了一个层次结构，但是根据 Size 却没有任何信息可以用来断定产品的 Color 将是什么。这是一个层次结构，但不是一个自然层次结构——但也不是说它是个非自然层次结构。Color 和 Size 形成一个层次结构并没有什么不对，它只是这样一个简单的事实：相同的 Size 可以出现在多个 Color 中。 40 | 41 | 在 OLAP 中定义维度时，层（Hierarchy）与级（Level）是比较让人迷惑的两个概念。简单的说，层就是一种维度成员的分类方式，级就是维度成员之间或维度成员属性之间的包含关系。一个维度至少要包含一个层。以【产品】维度为例，可以创建一个【产地】层，可以创建一个【厂商】层，也可以创建一个【分类】层。在 SSAS 中，可以不定义层，此时维度的默认层为 AllMembers 层。在 Mondrian 的 Schema 定义工具中，则要求全部手工定义。 42 | 43 | 一个层至少要包含一个级，以【产品】维度为例，【产地】层可以包含省-市-县三个级别，【分类】层可以包含日用品-洗涤用品-洗衣粉三个级别。级别的定义有 2 种方式，一种是在一个维度成员的属性之间定义，例如【产品】维度的每个成员都有产品系列、大类、小类三个属性，这样定义【分类】层的级别时，直接利用这三个属性即可，即：每个级别都是一个成员的一个属性。另一种是在维度成员之间进行，例如 HR 中的上下级关系，每个级别都是一个具体的维度成员，即：每个级别都是一个或多个维度成员，每个级都包含多个属性。后一种级别在数据库中往往是以递归的方式进行保存的。 44 | -------------------------------------------------------------------------------- /01~大数据体系/01~大数据生态/大数据平台.md: -------------------------------------------------------------------------------- 1 | # 大数据平台 2 | 3 | 大数据平台是将互联网产品和后台的大数据系统整合起来，将应用系统产生的数据导入大数据平台，经过计算后导出给应用系统使用。大数据平台将互联网应用和大数据产品整合起来，将实时数据和离线数据打通，使数据可以实现更大规模的关联计算，挖掘出数据更大的价值，从而实现数据驱动业务。大数据平台使得大数据技术产品可以落地应用，实现了自身价值。 4 | 5 | 总体来说：大数据平台可以分为四个部分：数据采集、数据处理、数据输出和任务调度管理。 6 | 7 | ![大数据平台](https://s2.ax1x.com/2019/12/18/QH7aqS.jpg) 8 | 9 | # 数据采集 10 | 11 | ## 数据库数据 12 | 13 | 目前比较常用的数据库导入工具有 Sqoop 和 Canal。 14 | 15 | Sqoop 是一个数据库批量导入导出工具，可以将关系数据库的数据批量导入到 Hadoop，也可以将 Hadoop 的数据导出到关系数据库。 16 | 17 | Sqoop 适合关系数据库数据的批量导入，如果想实时导入关系数据库的数据，可以选择 Canal。Canal 是阿里巴巴开源的一个 MySQLbinlog 获取工具，Binlog 是 MySQL 的事务日志，可用于 MySQL 数据库主从复制，Canal 将自己伪装成 MySQL 从库，从 MySQL 获取 Binlog。 18 | 19 | ## 日志数据 20 | 21 | 日志是大数据平台重要数据来源之一，应用程序日志一方面记录各种程序执行状况，一方面记录用户的操作轨迹。Flume 是大数据日志收集常用的工具。Flume 最早由 Cloudera 开发，后来捐赠给 Apache 基金会作为开源项目运营。 22 | 23 | ## 前端程序埋点 24 | 25 | 所谓前端埋点，是应用前端为了进行数据统计和分析采集数据。 26 | 27 | 用户的某些前端行为并不会产生后端请求，比如用户页面停留时间、用户浏览速度、用户点选又取消等等。这些信息对于分析用户行为等都很有价值。但是这些数据必须通过前端埋点获得，有些互联网公司会将前端埋点数据当作最主要的大数据来源，用户所有前端行为，都会埋点采集，再辅助结合其他的数据源，构建自己的大数据仓库，进而进行数据分析和挖掘。 28 | 29 | 对于一个互联网应用，当我们提到前端的时候，可能指的是如下几类： 30 | 31 | - App 程序，比如一个 iOS 应用或者 Android 应用，安装在用户的手机或者平板上； 32 | 33 | - PC Web 前端，使用 PC 浏览器打开； 34 | 35 | - H5 前端，由移动设备浏览器打开； 36 | 37 | - 微信小程序，在微信内打开。 38 | 39 | 这些不同的前端使用不同的开发语言开发，运行在不同的设备上，每一类前端都需要解决自己的埋点问题。埋点的方式主要有手工埋点、自动化埋点和可视化埋点。 40 | 41 | - 手工埋点就是前端开发者手动编程将需要采集的前端数据发送到后端的数据采集系统。通常公司会开发一些前端数据上报的 SDK，前端工程师在需要埋点的地方，调用 SDK，按照接口规范传入相关参数，比如 ID、名称、页面、控件等通用参数，还有业务逻辑数据等，SDK 将这些数据通过 HTTP 的方式发送到后端服务器。 42 | 43 | - 自动化埋点则是通过一个前端程序 SDK，自动收集全部用户操作事件，然后全量上传到后端服器。自动化埋点有时候也被称作无埋点，意思是无需埋点，实际上是全埋点，即全部用户操作都埋点采集。自动化埋点的好处是开发工作量小，数据规范统一。缺点是采集的数据量大，很多数据采集来也不知道有什么用，白白浪费了计算资源，特别是对于流量敏感的移动端用户而言，因为自动化埋点采集上传花费了大量的流量，可能因此成为卸载应用的理由，这样就得不偿失了。在实践中，有时候只是针对部分用户做自动埋点，抽样一部分数据做统计分析。 44 | 45 | - 介于手工埋点和自动化埋点之间的，还有一种方案是可视化埋点。通过可视化的方式配置哪些前端操作需要埋点，根据配置采集数据。可视化埋点实际上是可以人工干预的自动化埋点。 46 | 47 | ## 爬虫系统 48 | 49 | 通过网络爬虫获取外部数据用于行业数据支撑，管理决策等。由于涉及到敏感内容，不做更多的展开。 50 | 51 | # 数据处理 52 | 53 | 大数据平台的核心，分为离线计算和实时计算两类。 54 | 55 | - 离线计算：由 MapReduce、Hive、Spark 等进行的计算处理。 56 | 57 | - 实时计算：由 Storm、SparkSteaming 等流式大数据引擎完成，可以在秒级甚至毫秒级时间内完成计算。 58 | 59 | ## 数据输出 60 | 61 | 大数据处理与计算产生的数据写入到 HDFS 中，但应用程序不会到 HDFS 中读取数据，所以必须要将 HDFS 中的数据导出到数据库中。除了给用户提供数据，大数据平台还需要在一些后台系统中给运营和决策层提供各种统计数据，这些数据也写入数据库，被相应的后台系统访问。 62 | 63 | ## 任务调度 64 | 65 | 将上面三个部分有效整合和运转起来的是任务调度管理系统，它的主要作用是： 66 | 67 | - 合理调度各种 MapReduce、Spark 任务使资源利用最合理 68 | 69 | - 尽快执行临时的重要任务 70 | 71 | - 对作业提交、进度跟踪、数据查看等功能 72 | 73 | 简单的大数据平台任务调度管理系统其实就是一个类似 Crontab 的定时任务系统，按预设时间启动不同的大数据作业脚本。复杂的大数据平台任务调度还要考虑不同作业之间的依赖关系。开源的大数据调度系统有 Oozie，也可以在此基础进行扩展。 74 | 75 | # Hadoop 不足 76 | 77 | 虽然 Hadoop 在通过批处理支持大型存储和 ETL（提取、转换和加载）作业以及支持机器学习任务方面大有价值，但它在支持公司和大型组织用来管理日常运营的较为传统的分析工作方面并非最佳选择。Hive、Dremel 和 Spark 等工具在 Hadoop 上面使用以支持分析，但 Hadoop 从未变得足够快，无法真正取代数据仓库。 78 | 79 | Hadoop 还面临这样的挑战：NoSQL 数据库和对象存储提供商在解决 Hadoop 最初旨在帮助解决的部分存储和管理难题方面取得了进展。随着时间的推移，在 Hadoop 上支持业务连续性面临挑战，加上支持实时、地理空间及其他新兴的分析使用场合方面缺乏灵活性，这使得 Hadoop 面对海量数据时很难在批处理之外大有作为。 80 | 81 | 此外，久而久之，许多公司开始发现大数据难题越来越与此有关：支持一系列广泛的数据源，并迅速调整数据模式、查询、定义和上下文，新的应用程序、平台和云基础设施供应商就体现了这一点。为了克服这个挑战，分析、集成和复制就必须变得更敏捷更快速。许多供应商纷纷创办就体现了这个挑战，包括： 82 | 83 | - 分析解决方案：比如 ClearStory Data、Domo、Incorta、Looker、FineBI、Microsoft Power BI、Qlik、Sisense、Tableau 和 ThoughtSpot 84 | 85 | - 数据管道供应商：比如 Alooma、Attunity、Alteryx、Fivetran 和 Matillion 86 | 87 | - 数据集成供应商：包括 Informatica、MuleSoft、SnapLogic、Talend 和 TIBCO（后者还凭借其 Spotfire 产品组合角逐分析领域）。 88 | 89 | # Links 90 | 91 | - https://www.freebuf.com/articles/database/221147.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 92 | -------------------------------------------------------------------------------- /10~OLAP/02.MOLAP/HBase/架构分析.md: -------------------------------------------------------------------------------- 1 | # HBase Architecture 2 | 3 | HBase 采用 Master/Slave 架构搭建集群，它隶属于 Hadoop 生态系统，由一下类型节点组成：HMaster 节点、HRegionServer 节点、ZooKeeper 集群，而在底层，它将数据存储于 HDFS 中，因而涉及到 HDFS 的 NameNode、DataNode 等，总体结构如下: ![](http://www.blogjava.net/images/blogjava_net/dlevin/HBaseArch1.jpg) 其中**HMaster 节点**用于： 4 | 5 | 管理HRegionServer，实现其负载均衡。 6 | 管理和分配HRegion，比如在HRegion split时分配新的HRegion；在HRegionServer退出时迁移其内的HRegion到其他HRegionServer上。 7 | 实现DDL操作(Data Definition 8 | Language，namespace和table的增删改，column 9 | familiy的增删改等)。 10 | 管理namespace和table的元数据(实际存储在HDFS上)。 11 | 权限控制(ACL)。 12 | 13 | **HRegionServer 节点**用于： 14 | 15 | 存放和管理本地HRegion。 16 | 读写HDFS，管理Table中的数据。 17 | Client直接通过HRegionServer读写数据(从HMaster中获取元数据，找到RowKey所在的HRegion/HRegionServer后)。 18 | 19 | **ZooKeeper 集群是协调系统**，用于： 20 | 21 | 存放整个 22 | HBase集群的元数据以及集群的状态信息。 23 | 实现HMaster主从节点的failover。 24 | 25 | HBase Client 通过 RPC 方式和 HMaster、HRegionServer 通信；一个 HRegionServer 可以存放 1000 个 HRegion；底层 Table 数据存储于 HDFS 中，而 HRegion 所处理的数据尽量和数据所在的 DataNode 在一起，实现数据的本地化；数据本地化并不是总能实现，比如在 HRegion 移动 ( 如因 Split) 时，需要等下一次 Compact 才能继续回到本地化。 26 | 27 | # HFile 28 | 29 | HFile 数据格式中的 Data 字段用于存储实际的 KeyValue 数据，MetaIndex 字段用于 Meta 块的起始点，Magic 字段用于存储随机数，防止数据被破坏。而 HFile 中的 KeyValue 数据格式中的 Key 应该是 byte[] 数组，Value 部分是二进制数据。 30 | 31 | # 预分区 32 | 33 | HBase中，表会被划分为1...n个Region，被托管在RegionServer中。Region二个重要的属性:StartKey与 EndKey表示这个Region维护的rowKey范围，当我们要读/写数据时，如果rowKey落在某个start-end key范围内，那么就会定位到目标region并且读/写到相关的数据。简单地说，有那么一点点类似人群划分，1-15岁为小朋友,16-39岁为年轻 人，40-64为中年人,65岁以上为老年人。(这些数值都是拍脑袋出来的，只是举例，非真实),然后某人找队伍，然后根据年龄，处于哪个范围，就找到它 所属的队伍。: ( 有点废话了。。。。 34 | 然后，默认地，当我们只是通过HBaseAdmin指定TableDescriptor来创建一张表时，只有一个region,正处于混沌时 期，start-end key无边界,可谓海纳百川。啥样的rowKey都可以接受，都往这个region里装，然而，当数据越来越多，region的size越来越大时，大到 一定的阀值，hbase认为再往这个region里塞数据已经不合适了，就会找到一个midKey将region一分为二，成为2个region,这个过 程称为分裂(region-split).而midKey则为这二个region的临界，左为N无下界，右为M无上界。< midKey则为阴被塞到N区，> midKey则会被塞到M区。 35 | 如何找到midKey?涉及的内容比较多，暂且不去讨论，最简单的可以认为是region的总行数 / 2 的那一行数据的rowKey.虽然实际上比它会稍复杂点。 36 | 如果我们就这样默认地，建表，表里不断地Put数据，更严重的是我们的rowkey还是顺序增大的，是比较可怕的。存在的缺点比较明显。 37 | 首先是热点写，我们总是会往最大的start-key所在的region写东西，因为我们的rowkey总是会比之前的大，并且hbase的是按升序方式排序的。所以写操作总是被定位到无上界的那个region中。 38 | 其次，由于写热点，我们总是往最大start-key的region写记录，之前分裂出来的region不会再被写数据，有点被打进冷宫的赶脚，它们都处于半满状态，这样的分布也是不利的。 39 | 如果在写比较频率的场景下，数据增长快，split的次数也会增多，由于split是比较耗时耗资源的，所以我们并不希望这种事情经常发生。 40 | ............ 41 | 看到这些缺点，我们知道，在集群的环境中，为了得到更好的并行性，我们希望有好的load blance，让每个节点提供的请求处理都是均等的。我们也希望，region不要经常split，因为split会使server有一段时间的停顿，如何能做到呢？ 42 | 43 | 随机哈希与预分区。二者结合起来，是比较完美的，预分区一开始就预建好了一部分 region, 这些 region 都维护着自已的 start-end keys，再配合上随机哈希，写数据能均等地命中这些预建的 region，就能解决上面的那些缺点，大大地提高了性能。提供 2 种思路 : hash 与 partition. 一、hash 就是 rowkey 前面由一串随机字符串组成, 随机字符串生成方式可以由 SHA 或者 MD5 等方式生成，只要 region 所管理的 start-end keys 范围比较随机，那么就可以解决写热点问题。long currentId = 1L; byte [] rowkey = Bytes.add(MD5Hash.getMD5AsHex(Bytes.toBytes(currentId)).substring(0, 8).getBytes(), Bytes.toBytes(currentId)); 44 | 45 | 假设 rowKey 原本是自增长的 long 型，可以将 rowkey 转为 hash 再转为 bytes，加上本身 id 转为 bytes, 组成 rowkey，这样就生成随便的 rowkey。那么对于这种方式的 rowkey 设计，如何去进行预分区呢？1. 取样，先随机生成一定数量的 rowkey, 将取样数据按升序排序放到一个集合里 2. 根据预分区的 region 个数，对整个集合平均分割，即是相关的 splitKeys. 3.HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][] splitkeys) 可以指定预分区的 splitKey，即是指定 region 间的 rowkey 临界值 . 46 | 47 | 以上，就已经按hash方式，预建好了分区，以后在插入数据的时候，也要按照此rowkeyGenerator的方式生成rowkey,有兴趣的话，也可以做些试验，插入些数据，看看数据的分布。 48 | 49 | 二、partition故名思义，就是分区式，这种分区有点类似于mapreduce中的partitioner,将区域用长整数(Long)作为分区号，每个region管理着相应的区域数据，在rowKey生成时，将id取模后，然后拼上id整体作为rowKey.这个比较简单，不需要取 样，splitKeys也非常简单，直接是分区号即可。直接上代码吧： 50 | 51 | calcSplitKeys 方法比较单纯，splitKey 就是 partition 的编号, 我们看看测试类 : Java 代码 收藏代码 52 | 53 | 通过partition实现的loadblance写的话，当然生成rowkey方式也要结合当前的region数目取模而求得，大家同样也可以做些实验，看看数据插入后的分布。 54 | 55 | 在这里也顺提一下，如果是顺序的增长型原 id, 可以将 id 保存到一个数据库，传统的也好 ,redis 的也好，每次取的时候，将数值设大 1000 左右，以后 id 可以在内存内增长，当内存数量已经超过 1000 的话，再去 load 下一个，有点类似于 oracle 中的 sqeuence. 56 | 57 | 随机分布加预分区也不是一劳永逸的。因为数据是不断地增长的，随着时间不断地推移，已经分好的区域，或许已经装不住更多的数据，当然就要进一步进行 split了，同样也会出现性能损耗问题，所以我们还是要规划好数据增长速率，观察好数据定期维护，按需分析是否要进一步分行手工将分区再分好，也或者是 更严重的是新建表，做好更大的预分区然后进行数据迁移。 58 | -------------------------------------------------------------------------------- /04~数据可视化/可视化开发库/D3/README.md: -------------------------------------------------------------------------------- 1 | # D3 2 | 3 | D3 是一个 JavaScript 库，用于在网络上创建定制的交互式图表和地图。虽然大多数图表库（如 Chart.js 和 Highcharts）都提供了现成的图表，但 D3 由大量的构件组成，可以从这些构件中构建自定义的图表或地图。D3 的方法比其他图表库的层次要低得多。用 Chart.js 创建一个条形图只需要几行代码。 4 | 5 | 用 D3 创建同样的图表，你需要：创建 SVG 矩形元素并将它们连接到数据上；矩形元素定位；根据数据确定矩形元素的大小；最后添加坐标轴。您可能还想当图表首次加载时，对条形图进行动画处理；容器自适应处理；添加工具提示等。这都是额外的工作，但它能让你完全控制图表的外观和行为。 6 | 7 | 如果一个标准的条形图、线形图或饼形图就足够了，你应该考虑使用 Chart.js 这样的库。然而，如果你希望按照精确的规格创建一个定制的图表，那么 D3 是值得考虑的。D3 的功能包括： 8 | 9 | - 数据驱动的 HTML/SVG 元素的修改 10 | - 加载和转换数据（如 CSV 数据）。 11 | - 生成复杂的图表，如树状图、包装圆和网络。 12 | - 一个强大的过渡系统，用于在不同的视图之间制作动画 13 | - 强大的用户交互支持，包括平移、缩放和拖动。 14 | 15 | # Hello World 16 | 17 | ![D3 示例柱状图](https://s1.ax1x.com/2020/10/30/BtAZ4I.png) 18 | 19 | ```html 20 | 21 | 22 | 23 | DOM Manipulation 24 | 25 | 26 | 59 | 60 | 61 | 62 |
63 |
64 | 65 |
66 | 67 | 68 | 69 |
70 | 71 | 72 | 73 | 74 | 184 | 185 | 186 | ``` 187 | -------------------------------------------------------------------------------- /01~大数据体系/03~数据组织方式/04~数据中台/评价维度.md: -------------------------------------------------------------------------------- 1 | > [评估数据中台成熟度的7个维度](https://insights.thoughtworks.cn/data-zhongtai-maturity-model/) 2 | 3 | # 数据中台的评价维度 4 | 5 | ![数据中台的评价维度](https://s1.ax1x.com/2020/08/30/dH7lhn.png) 6 | 7 | # 数据战略 8 | 9 | 数据中台建设的前提是数据战略的清晰和明确化，评估一个组织有没有数据战略的关注点是：数据战略是什么以及是否一致，管理组织的成立和运作，制度建设的配套和保障等。数据中台的建设通常不是无缘无故发生的，也不是追求“时尚”的产物，在中台建设的行动之上和活动之初必然有个数据战略，这个战略可能是在建设过程中逐渐被清晰化的，也可能只是在小部分成员（通常是负责人）之间共享，更有可能只出现在ppt或者口头表达里，它可能是公司级别的战略，也可能只是部门级别的战略，但这个战略很重要，它就如同一家组织的愿景和目标，是指导行动的灯塔，没有它，组织的决策可能会具有随机性，导致资源利用不集中、行动效率低、重复建设等现象发生。 10 | 11 | 有了数据战略，还需要确认组织（或者部门团队）对战略的理解是否一致，如果理解不一致，数据战略可能只存在口号或者争论里，落地的结果不尽人意或者没有结果产出。 12 | 13 | 如何保证有清晰明确的数据战略，并且这个战略能被统一认识和理解呢？答案是需要一个管理组织，这个组织可能只以虚拟的形式存在，但是管理得当的话，它可以保证战略目标能被有效的分解，并且能在部门和团队之间得到拉通落地。 14 | 15 | 与管理组织配套的还需要一些制度建设，比如保证战略落地的流程，如何处理冲突、不一致，决策流程是怎样的？战略（和行动）的调整和优化机制是什么？ 16 | 17 | # 数据治理 18 | 19 | 并不是所有的组织都会组建单独做数据治理的团队，但数据治理的工作却必须有。有很多组织的原则是“先建设，后治理”，也就是说先把中台的架构搭建起来，循序渐进完善各个功能模块，在这个过程中，绝大多数组织会选择先建设和用户（业务或者业务IT）强相关的功能模块，过一段时间再回头计划数据治理的工作。但建设功能和数据治理的时间间隔通常不会太久，通常来讲会在半年到一年以内，否则组织会发现，功能建设的工作难以为继，治理的难度也会随着时间的推移逐步增加。 20 | 21 | 评估数据治理的时候，也需要关注一些点： 22 | 23 | - 比如，元数据相关的，有没有做元数据管理和怎么来做的元数据管理，是否有元数据分类，技术和业务元数据的管理，有没有完善的元数据管理体系，是自动管理还是手动管理，维护机制是怎样的？ 24 | 25 | - 比如，数据字典相关的，是否有相应的管理和维护机制，字典包括什么内容，数据字典的变更、权限审批流程是怎样的，是否和业务系统保持同步等？ 26 | 27 | - 比如，数据模型相关的，数据建模的方式、标准方法和流程是怎样的，按照哪种方式来建模，模型的自适应能力怎样，是否有统一的建模工具，维护、优化和变更流程是怎样的？ 28 | 29 | - 比如，数据质量相关的，是否有做数据质量管理，是否有质量的评分模型、监控流程和评估流程，是否有完善的反馈、变更和处理机制，质量是否和考评指标联系等等？ 30 | 31 | - 比如，数据标准相关的，是否有数据标准体系，是否有源系统和目标系统的数据标准映射逻辑关系，是否有反馈、变更、处理机制等等？ 32 | 33 | - 比如，数据安全相关的，是否建立数据安全管理机制和定义安全分级分类标准，是否有适当的数据安全控制及措施，是否有数据隐私保护等相关活动及维护数据安全的工具，是否有完善的数据访问权限和回收策略，是否有脱敏机制和策略等？ 34 | 35 | - 比如，数据生命周期相关，数据生命周期的体系规划和落地机制是怎样的？是否有获取与存档方案，是否有备份和恢复计划以及数据销毁方案，是否有保留与归档的日常活动以及归档数据的检索与使用策略？ 36 | 37 | 总的来说，当数据量多并且复杂到一定程度，数据治理的工作如果不能成为中台建设的重点，就极有可能成为中台建设的瓶颈。 38 | 39 | # 数据资产管理 40 | 41 | 数据资产管理也是数据中台必须建设的功能模块，正如其名字所诠释的那样，把数据当成资产，建设好了给组织带来价值增值，建设不好则给组织带来资产流失或贬值。 42 | 43 | 评估数据资产管理的时候，需要关注中台的这样一些点： 44 | 45 | - 有没有数据资产审核能力，也就是对数据资产的注册申请进行审批，保证数据资产能被合规注册和发布的能力； 46 | 47 | - 有没有数据资产发布能力，指的是将审批通过的数据发布到数据资产地图，供数据消费者查询使用； 48 | 49 | - 有没有数据资产标签，比如客户的特征标签、关键业务的指标标签等，以便使用者通过标签组合来消费数据； 50 | 51 | - 有没有数据资产地图，指的是通过地图或者目录的形式，提供数据资产的查询功能，实现数据资产的“可视化”； 52 | 53 | - 有没有数据资产的开放能力，通过接口的方式，数据资产被开放给内外部的用户，实现数据资产“增值”； 54 | 55 | - 有没有数据资产盘点能力，如同组织盘点自己的动产和不动产一样，数据既然已经被当做资产，也需要周期定期不定期甚至实时进行盘点，盘点成果将会被导入到数据资产运营平台进行管理； 56 | 57 | - 有没有数据资产定价，围绕数据的不同价值模型，比如业务价值，成本价值，市场价值等，按照不同的权重配比对数据资产的价值进行评估定价； 58 | 59 | - 有没有数据效益评估，根据数据资产产出的价值，来数据资产的价值进行评估。 60 | 61 | 根据现实经验，上面的所有项可以不是同期同步发生的，许多组织的数据资产管理只是覆盖了以上几项，但中台仍然能“负重”运作，也正是如此，数据资产管理的成熟度评估才显得尤为重要，因为只有认识到数据资产管理的全貌，才有利于设置正确的建设路径。 62 | 63 | # 数据平台和架构 64 | 65 | 数据平台和架构是在全域的数据基础之上，设计出易用的、稳定的、可扩展的、支持多应用的平台架构，此外，进行数据分层建模和标准定义，最终呈现出一套完整的、规范的、准确的数据架构和应用的解决方案，可以方便支撑数据应用。所以数据平台和架构主要关注如下： 66 | 67 | 首先要关注的就是架构标准，有没有架构选择的流程，比如同业调研，选型，POC以及决策机制，是否有专门的架构组来保证流程和机制的落实，是否有部门内部和部门之间的架构评审流程和机制等等； 68 | 69 | 其次，架构方法也至关重要，比如架构规划、整体架构、基础架构、数据架构、功能架构和部署架构的设计原则是什么，有没有标准的架构实施规范，有没有评估机制，是否有调整、优化和改进机制等等； 70 | 71 | 再次，数据是怎样集成的，有无数据整合架构政策和标准，数据集成的流程和标准是什么，包括内外部数据集成、离线和实时数据的集成方案等，是否有自动化的数据集成工具或平台，集成过程中是否有异常处理、回滚等操作； 72 | 73 | 整体来说，这部分既需要整体规划又需要对细节进行考虑，不仅仅是部门内部的工作，还涉及跨部门的协作机制，是非常具有技术含量的一个模块。 74 | 75 | # 数据服务化 76 | 77 | 数据服务化是指数据中台以什么样的方式向外提供服务，而能直接使用这些服务的人通常不是业务人员，却极有可能是业务应用的IT人员，业务通过调用配置好且已开放的服务（比如API）来为业务快速开发满足某一需求的功能。 78 | 79 | 数据服务化的背后也通常会有一个服务平台在支撑，所以在做中台服务化评估的时候既要关注服务平台又要关注服务本身。 80 | 81 | 比如，服务标准的确立，指的是有没有明确的服务目标，以什么样的方式提供服务，提供服务的流程和优先级是怎样的，和业务IT 的协作机制是怎样的？ 82 | 83 | 另外就是服务监控和维护，在平台之上以什么样的方式监控数据服务，有无量化的标准来评估数据服务，数据服务维护的流程和机制是啥？ 84 | 85 | 还有服务结果分析，有没有对服务结果进行分析的机制，结果的读取和分析是否同步，分析结果是否发布、发布给谁、以怎样的方式发布？ 86 | 87 | 最后还要关注数据服务的评估和优化，中台提供数据服务是否被评估，按照什么维度进行评估，评估的流程和机制是怎样的，评估的结果是否会用来指导数据服务化的优化和改进？ 88 | 89 | 在对数据服务化这一维度进行评估的时候，通常既需要关注功能（技术）实现，又需要关注治理，因为规范成熟的治理机制是中台持续不断对外提供“优质”服务的保障。 90 | 91 | # 数据产品化 92 | 93 | 有的组织会把产品化和服务化放在一起，因为这两部分都是比较靠近前端数据消费者的，因为无论是产品化还是服务化，对整个中台来讲，它们都是数据产品。 94 | 95 | 略微不同的是，数据产品化的结果，有相当一部分是可以直接被业务使用的，比如报表的分析服务（产品），业务人员可以直接通过托拉拽的方式在平台配置自己所需的报表以及展示方式。 96 | 97 | 这一维度所要关注的目标就和战略方向特别靠近，比如： 98 | 99 | - 业务支撑能力：数据产品化（或者数据产品平台）支撑什么样的业务功能，有无功能选择的标准，所能支撑的业务是否能反映战略的方向或战略的执行情况，功能支撑能力是不是能被周期性评估和优化； 100 | 101 | - 业务分析响应能力：响应机制是啥，业务功能使用的响应能否做到实时（T+N），产品平台功能开发的响应机制是啥（如果提出一个功能开发需求，多久可以上线），有无对底层数据整合平台的依赖； 102 | 103 | - 数据可视化能力：是否支持业务友好的使用方式，比如指标和数据维度的托拉拽，是否支持数据挖掘和分析结果的呈现，是否有自定义图表的呈现，是否集成第三方分析呈现工具； 104 | 105 | - 统一服务的能力：是否能将业务需求沉淀成统一服务的能力从而能够服务于更多业务团队，沉淀的原则是什么，是否实现跨集市引用的沉淀，等等。 106 | 107 | 数据产品化是比较靠近业务，也比较容易被业务感知到的一个模块，这块的设计和开发应该借鉴产品开发的思路，既需要考虑功能、业务反馈，还需要关注运营指标。 108 | 109 | # 中台运营 110 | 111 | 指的是将整个数据中台作为一个产品来看，是否有运营的指标和控制机制。 112 | 113 | - 比如，是否有中台管理平台，类似于整个中台管理的入口，所有通用文档、规范、标准、流程的管理，都能够列出来并且能被方便的查找，对各个平台运营指标的监控和分析进行区别性的展示； 114 | 115 | - 比如，存储成本、计算成本和研发成本的管理和分析，有没有这些成本的投入计划，估算原则和成本分析； 116 | 117 | - 比如，是否有中台内部各模块之间的整合与协作机制，架构的设计、职责和工作内容是否清晰，互相调用和协作机制是否完善，功能模块间的资源分配是否均衡 118 | 119 | - 比如，在价值层面是否具有良好的用户体验和较高的用户满意度； 120 | 121 | - 比如，在资产的管理方面，是否能反映数据或服务被调用的频率或次数，等等。 122 | 123 | 总之，中台运营评估的是中台作为一款“产品”，它是否能为组织提效降本，是否能为业务带来价值增值。 124 | 125 | 126 | 127 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/Hive/文件类型与存储格式.md: -------------------------------------------------------------------------------- 1 | > - [Hive 文件存储格式的测试比较](http://yugouai.iteye.com/blog/1851606) 2 | 3 | Hive 的三种文件格式：TEXTFILE、SEQUENCEFILE、RCFILE 中，TEXTFILE 和 SEQUENCEFILE 的存储格式都是基于行存储的，RCFILE 是基于行列混合的思想，先按行把数据划分成 N 个 row group，在 row group 中对每个列分别进行存储。另：Hive 能支持自定义格式。基于 HDFS 的行存储具备快速数据加载和动态负载的高适应能力，因为行存储保证了相同记录的所有域都在同一个集群节点。但是它不太满足快速的查询响应时间的要 求，因为当查询仅仅针对所有列中的 少数几列时，它就不能跳过不需要的列，直接定位到所需列；同时在存储空间利用上，它也存在一些瓶颈，由于数据表中包含不同类型，不同数据值的列，行存储不 易获得一个较高的压缩比。RCFILE 是基于 SEQUENCEFILE 实现的列存储格式。除了满足快速数据加载和动态负载高适应的需求外，也解决了 SEQUENCEFILE 的一些瓶颈。 4 | 5 | # TextFile 6 | 7 | Hive 默认格式，数据不做压缩，磁盘开销大，数据解析开销大。可结合 Gzip、Bzip2、Snappy 等使用(系统自动检查，执行查询时自动解压)，但使用这种方式，hive 不会对数据进行切分，从而无法对数据进行并行操作。 8 | 9 | ``` 10 | create table if not exists textfile_table( 11 | site string, 12 | url string, 13 | pv bigint, 14 | label string) 15 | row format delimited 16 | fields terminated by '\t' 17 | stored as textfile; 18 | 插入数据操作： 19 | set hive.exec.compress.output=true; 20 | set mapred.output.compress=true; 21 | set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec; 22 | set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec; 23 | insert overwrite table textfile_table select * from textfile_table; 24 | ``` 25 | 26 | # SequenceFile 27 | 28 | SequenceFile 是 Hadoop API 提供的一种二进制文件，它将数据以的形式序列化到文件中。这种二进制文件内部使用 Hadoop 的标准的 Writable 接口实现序列化和反序列化。它与 Hadoop API 中的 MapFile 是互相兼容的。Hive 中的 SequenceFile 继承自 Hadoop API 的 SequenceFile，不过它的 key 为空，使用 value 存放实际的值，这样是为了避免 MR 在运行 map 阶段的排序过程。 29 | SequenceFile 的文件结构图： 30 | ![](http://dl.iteye.com/upload/attachment/0083/5096/d0399873-2c9e-3923-ab50-93644d9b8138.jpg) 31 | Header 通用头文件格式： 32 | 33 | | SEQ | 3BYTE | 34 | | ---------------- | ----------------------------------- | 35 | | Nun | 1byte 数字 | 36 | | keyClassName | | 37 | | ValueClassName | | 38 | | compression | (boolean)指明了在文件中是否启用压缩 | 39 | | blockCompression | (boolean，指明是否是 block 压缩) | 40 | | compression | codec | 41 | | Metadata | 文件元数据 | 42 | | Sync | 头文件结束标志 | 43 | 44 | Block-Compressed SequenceFile 格式 45 | ![](http://dl.iteye.com/upload/attachment/0083/5099/cd8a8be6-a2e4-39c8-a598-357278f1e336.jpg) 46 | 47 | ``` 48 | create table if not exists seqfile_table( 49 | site string, 50 | url string, 51 | pv bigint, 52 | label string) 53 | row format delimited 54 | fields terminated by '\t' 55 | stored as sequencefile; 56 | 插入数据操作： 57 | set hive.exec.compress.output=true; 58 | set mapred.output.compress=true; 59 | set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec; 60 | set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec; 61 | SET mapred.output.compression.type=BLOCK; 62 | insert overwrite table seqfile_table select * from textfile_table; 63 | ``` 64 | 65 | # RCFile 66 | 67 | RCFile 是 Hive 推出的一种专门面向列的数据格式。它遵循“先按列划分，再垂直划分”的设计理念。当查询过程中，针对它并不关心的列时，它会在 IO 上跳过这些列。需要说明的是，RCFile 在 map 阶段从 远端拷贝仍然是拷贝整个数据块，并且拷贝到本地目录后 RCFile 并不是真正直接跳过不需要的列，并跳到需要读取的列，而是通过扫描每一个 row group 的头部定义来实现的，但是在整个 HDFS Block 级别的头部并没有定义每个列从哪个 row group 起始到哪个 row group 结束。所以在读取所有列的情况下，RCFile 的性能反而没有 SequenceFile 高。 68 | RCFile 结合行存储查询的快速和列存储节省空间的特点：首先，RCFile 保证同一行的数据位于同一节点，因此元组重构的开销很低；其次，像列存储一样，RCFile 能够利用列维度的数据压缩，并且能跳过不必要的列读取。 69 | HDFS 块内 RCFile 方式存储的例子： 70 | ![](http://dl.iteye.com/upload/attachment/0083/5132/012d26f3-eeab-37d2-a59b-a8073d7476a7.jpg) 71 | 72 | ``` 73 | create table if not exists rcfile_table( 74 | site string, 75 | url string, 76 | pv bigint, 77 | label string) 78 | row format delimited 79 | fields terminated by '\t' 80 | stored as rcfile; 81 | 插入数据操作： 82 | set hive.exec.compress.output=true; 83 | set mapred.output.compress=true; 84 | set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec; 85 | set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec; 86 | insert overwrite table rcfile_table select * from textfile_table; 87 | ``` 88 | 89 | ``` 90 | [hadoop@node3 ~]$ hadoop dfs -dus /user/hive/warehouse/* 91 | hdfs://node1:19000/user/hive/warehouse/hbase_table_1 0 92 | hdfs://node1:19000/user/hive/warehouse/hbase_table_2 0 93 | hdfs://node1:19000/user/hive/warehouse/orcfile_table 0 94 | hdfs://node1:19000/user/hive/warehouse/rcfile_table 102638073 95 | hdfs://node1:19000/user/hive/warehouse/seqfile_table 112497695 96 | hdfs://node1:19000/user/hive/warehouse/testfile_table 536799616 97 | hdfs://node1:19000/user/hive/warehouse/textfile_table 107308067 98 | [hadoop@node3 ~]$ hadoop dfs -ls /user/hive/warehouse/*/-rw-r--r-- 2 hadoop supergroup 51328177 2014-03-20 00:42 /user/hive/warehouse/rcfile_table/000000_0-rw-r--r-- 2 hadoop supergroup 51309896 2014-03-20 00:43 /user/hive/warehouse/rcfile_table/000001_0-rw-r--r-- 2 hadoop supergroup 56263711 2014-03-20 01:20 /user/hive/warehouse/seqfile_table/000000_0-rw-r--r-- 2 hadoop supergroup 56233984 2014-03-20 01:21 /user/hive/warehouse/seqfile_table/000001_0-rw-r--r-- 2 hadoop supergroup 536799616 2014-03-19 23:15 /user/hive/warehouse/testfile_table/weibo.txt-rw-r--r-- 2 hadoop supergroup 53659758 2014-03-19 23:24 /user/hive/warehouse/textfile_table/000000_0.gz-rw-r--r-- 2 hadoop supergroup 53648309 2014-03-19 23:26 /user/hive/warehouse/textfile_table/000001_1.gz 99 | ``` 100 | -------------------------------------------------------------------------------- /02~数据集成/DataPipeline/数据源监听.md: -------------------------------------------------------------------------------- 1 | # 数据源监听 2 | 3 | 源数据变化捕获是数据集成的起点，获取数据源变化主要有三种方式： 4 | 5 | - 基于日志的解析模式； 6 | - 基于增量条件查询模式； 7 | - 数据源主动推送模式。 8 | 9 | 基于日志的解析模式常用于各种类型的数据库，例如 MySQL 的 Binlog、Oracle 的 Redo&Achieve Log、SQL Server Change Tracking & CDC 等。 10 | 11 | 不同数据库日志解析的原理差别很大，以 MySQL Binlog 模式为例，解析程序本身是一个 Slave，能够实时收到 MySQL Master 的数据流推送，并解析还原成 DDL 和 DML 操作。而 SQL Server 的 CT 模式下，增量是通过定期查询 Change Tracking 表实现的。 12 | 13 | 基于增量条件的查询模式不依赖于源端开启日志记录，但对于数据源通常有额外的格式要求。例如，数据库表或文档对象需要有标志更新时间的字段，这在一些业务系统中是无法满足的。 14 | 15 | 数据源主动推送模式的常见形式为业务插码，即应用系统通过打点或者配置切面的方式，将数据变化封装为事件，额外发送一份给数据集成平台。这种方式一般需要对源端系统代码进行一定程度的修改。 16 | 17 | # 数据库日志增量捕获 18 | 19 | 通常而言，基于数据库的日志进行增量捕获应当被优先考虑。其具备以下几个显著优点： 20 | 21 | - 能够完整获取数据变化的操作类型，尤其是 Delete 操作，这是增量条件查询模式很难做到的； 22 | - 不依赖特别的数据字段语义，例如更新时间； 23 | - 多数情况下具备较强的实时性。 24 | 25 | 当然，事物都具有两面性。开启数据库日志通常会对源库性能产生一定的影响，需要额外的存储空间，甚至一些解析方法也会对源库资源造成额外消耗。因此，实施过程中需要在 DBA 的配合下，根据数据库特点和解析原理进行 DB 部署规划。 26 | 27 | 推荐使用数据库的复制和灾备能力，在独立服务器对从库进行日志解析。此外，当数据库产生批量更新时，会在短时间内产生大量日志堆积，如果日志留存策略设置不当，容易出现数据丢失。这些都需要根据具体的业务数据增长特点，在前期做好规划，并在上线后根据业务变化定期进行评估和调整。 28 | 29 | # 数据源推送 30 | 31 | 数据源主动 push 模式下，由于事件发送和业务处理很难做到事务一致性，所以当出现异常时，数据一致性就无从保证，比较适合对于数据一致性要求不高的场景，例如用户行为分析。 32 | 33 | # CDC 模块 34 | 35 | 变更数据抓取通常需要针对不同数据源订制实现，而针对特定数据源，实现方式一般有两种： 36 | 37 | - 基于自增列或上次修改时间做增量查询； 38 | - 利用数据源本身的事务日志或 Slave 同步等机制实时订阅变更； 39 | 40 | 第一种方式实现简单，以 SQL 为例：相信大家都写过类似的 SQL, 每次查询时，查询 [last_query_time, now) 区间内的增量数据，lastmodified 列也可以用自增主键来替代。这种方式的缺点是实时性差，对数据库带来了额外压力，并且侵入了表设计：所有要实现变更抓取的表都必须有用于增量查询的列并且在该列上构建索引。另外，这种方式无法感知物理删除(Delete), 删除逻辑只能用一个 delete 列作为 flag 来实现。第二种方式实现起来相对困难，但它很好地解决了第一种方式的问题，因此前文提到的开源方案也都采用了这种方式。下面我们着重分析在 MySQL 中如何实现基于事务日志的实时变更抓取。 41 | 42 | MySQL 的事务日志称为 Binlog，常见的 MySQL 主从同步就是使用 Binlog 实现的： 43 | 44 | ![MySQL Database Replication Internals](https://s2.ax1x.com/2019/10/08/ufd4Bt.png) 45 | 46 | 我们把 Slave 替换成 CDC 模块，CDC 模块模拟 MySQL Slave 的交互协议，便能收到 Master 的 Binlog 推送： 47 | 48 | ![CDC 模块架构](https://s2.ax1x.com/2019/10/08/ufdxH0.png) 49 | 50 | CDC 模块解析 Binlog，产生特定格式的变更消息，也就完成了一次变更抓取。但这还不够，CDC 模块本身也可能挂掉，那么恢复之后如何保证不丢数据又是一个问题。这个问题的解决方案也是要针对不同数据源进行设计的，就 MySQL 而言，通常会持久化已经消费的 Binlog 位点或 Gtid(MySQL 5.6 之后引入)来标记上次消费位置。其中更好的选择是 Gtid，因为该位点对于一套 MySQL 体系（主从或多主）是全局的，而 Binlog 位点是单机的，无法支持主备或多主架构。 51 | 52 | MySQL CDC 模块的一个挑战是如何在 Binlog 变更事件中加入表的 Schema 信息(如标记哪些字段为主键，哪些字段可为 null)。Debezium 在这点上处理得很漂亮，它在内存中维护了数据库每张表的 Schema，并且全部写入一个 backup 的 Kafka Topic 中，每当 Binlog 中出现 DDL 语句，便应用这条 DDL 来更新 Schema。而在节点宕机，Debezium 实例被调度到另一个节点上后，又会通过 backup topic 恢复 Schema 信息，并从上次消费位点继续解析 Binlog。 53 | 54 | 另一个挑战是，我们数据库已经有大量的现存数据，数据迁移时的现存数据要如何处理。这时，Debezium 独特的 Snapshot 功能就能帮上忙，它可以实现将现有数据作为一次”插入变更”捕捉到 Kafka 中，因此只要编写一次客户端就能一并处理全量数据与后续的增量数据。 55 | 56 | # 开源方案对比 57 | 58 | - databus: Linkedin 的分布式数据变更抓取系统； 59 | - Yelp’s data pipeline: Yelp 的数据管道； 60 | - Otter & Canal: 阿里开源的分布式数据库同步系统； 61 | - Debezium: Redhat 开源的数据变更抓取组件； 62 | 63 | 这些解决方案关注的重点各有不同，但基本思想是一致的：使用变更抓取模块实时订阅数据库变更，并分发到一个中间存储供下游应用消费。下面是四个解决方案的对比矩阵： 64 | 65 | | 方案 | 变更抓取 | 分发平台 | 消息格式 | 额外特性 | 66 | | -------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------- | ------------------ | -------------------------------------------------------------------- | 67 | | databus | DatabusEventProducer, 支持 Oracle 和 MySQL 的变更抓取 | DatabusRelay, 基于 Netty 的中间件, 内部是一个 RingBuffer 存储变更消息 | Apache Avro | 有 BootstrapService 组件存储历史变更用以支持全量 | 68 | | Yelp’s data pipeline | MySQL Streamer, 基于 Binlog 抓取变更 | Apache Kafka | Apache Avro | Schematizer, 作为消息的 Avro Schema 注册中心的同时提供了 Schema 文档 | 69 | | Otter | [Canal](https://github.com/alibaba/canal), 阿里的另一个开源项目, 基于 Binlog | work node 内存中的 ring buffer | protobuf | 提供了一个完善的 admin ui | 70 | | Debezium | 提供 MySQL, MongoDB, PostgreSQL 三种 Connector | Apache Kafka | Apache Avro / json | Snapshot mode 支持全量导入数据表 | 71 | 72 | ## databus 73 | 74 | Linkedin databus 的论文有很强的指导性，但它的 MySQL 变更抓取模块很不成熟，官方支持的是 Oracle，MySQL 只是使用另一个开源组件 OpenReplicator 做了一个 demo。另一个不利因素 databus 使用了自己实现的一个 Relay 作为变更分发平台，相比于使用开源消息队列的方案，这对维护和外部集成都不友好。 75 | 76 | ![databus 架构图](https://s2.ax1x.com/2019/10/08/ufabO1.png) 77 | 78 | ## Otter & Canal 79 | 80 | Otter 和 Canal 在国内相当知名，Canal 还支持了阿里云 DRDS 的二级索引构建和小表同步，工程稳定性上有保障。但 Otter 本身无法很好地支持多表聚合到新表，开源版本也不支持同步到分片表当中，能够采取的一个折衷方案是直接将 Canal 订阅的变更写入消息队列，自己写下游程序实现聚合同步等逻辑。该方案也是我们的候选方案。 81 | 82 | ![Otter 架构图](https://s2.ax1x.com/2019/10/08/ufdATf.png) 83 | 84 | ## data pipeline 85 | 86 | Yelp’s data pipeline 是一个大而全的解决方案。它使用 Mysql-Streamer（一个通过 Binlog 实现的 MySQL CDC 模块）将所有的数据库变更写入 Kafka，并提供了 Schematizer 这样的 Schema 注册中心和定制化的 Python 客户端库解决通信问题。遗憾的是该方案是 Python 构建的，与我们的 Java 技术栈相性不佳。 87 | 88 | ## Debezium 89 | 90 | Debezium 不同于上面的解决方案，它只专注于 CDC，它的亮点有: 91 | 92 | - 支持 MySQL、MongoDB、PostgreSQL 三种数据源的变更抓取，并且社区正在开发 Oracle 与 Cassandra 支持； 93 | 94 | - Snapshot Mode 可以将表中的现有数据全部导入 Kafka，并且全量数据与增量数据形式一致，可以统一处理； 95 | 96 | - 利用了 Kafka 的 Log Compaction 特性，变更数据可以实现”不过期”永久保存； 97 | 98 | - 利用了 Kafka Connect，自动拥有高可用与开箱即用的调度接口； 99 | 100 | - 社区活跃：Debezium 很年轻，面世不到 1 年，但它的 Gitter 上每天都有百余条技术讨论，并且有两位 Redhat 全职工程师进行维护； 101 | -------------------------------------------------------------------------------- /10~OLAP/02.MOLAP/HBase/CRUD.md: -------------------------------------------------------------------------------- 1 | # Filter 2 | 3 | 基础 API 中的查询操作在面对大量数据的时候是非常苍白的，这里 Hbase 提供了高级的查询方法：Filter。Filter 可以根据簇、列、版本等更多的条件来对数据进行过滤，基于 Hbase 本身提供的三维有序(主键有序、列有序、版本有序)，这些 Filter 可以高效的完成查询过滤的任务。带有 Filter 条件的 RPC 查询请求会把 Filter 分发到各个 RegionServer，是一个服务器端(Server-side )的过滤器，这样也可以降低网络传输的压力。要完成一个过滤的操作，至少需要两个参数。一个是抽象的操作符，Hbase 提供了枚举类型的变量来表示这些抽象的操作符：LESS/LESS_OR_EQUAL/EQUAL/NOT_EUQAL 等；另外一个就是具体的比较器(Comparator )，代表具体的比较逻辑，如果可以提高字节级的比较、字符串级的比较等。有了这两个参数，我们就可以清晰的定义筛选的条件，过滤数据。CompareFilter ( CompareOp compareOp，WritableByteArrayComparable valueComparator ) 4 | 5 | CompareFilter是高层的抽象类，下面我们将看到它的实现类和实现类代表的各种过滤条件。这里实现类实际上代表的是参数中的过滤器过滤的内容，可以使主键、簇名、列值等，这就是由CompareFilter决定了。 6 | 行过滤器(RowFilter) 7 | 行过滤器的比较对象是行主键 8 | 9 | Scan scan = new Scan(); Filter filter1 = new RowFilter(CompareFIlter.CompareOp.LESS_OR_EUQAL, new BinaryComparator(Bytes.toBytes("hello"))); scan.setFilter(filter1); scan.close(); 10 | 11 | 例中的Filter会将所有的小于等于“Hello”的主键过滤出来。 12 | 簇过滤器(FamilyFilter) 13 | 簇过滤器过滤的是簇的名字。 14 | 列过滤器(QualifierFilter) 15 | 列过滤器过滤的是列的名字。 16 | 值过滤器(ValueFilter) 17 | 值过滤器过滤的是扫描对象的值。 18 | 单值过滤器(SingleColumnValueFilter) 19 | 单值过滤器是以特定列的值为过滤内容，与值过滤器不同的是，这里是特定的列，而值过滤器比较的是行内的所有列。所有在使用单值过滤器的时候要指定比较的列的坐标。 20 | 21 | SingleColumnValueFilter(byte[] family, byte[] qualifier, CompareOp compareOp, WritableByteArrayComparable comparator) 22 | 23 | 对于找不到该列的行，可以有特殊的处理 24 | 25 | void setFilterIfMissing(boolean filterIfMissing) 26 | 27 | 默认缺省行将被包含进过滤的结果集中。 28 | 前缀过滤器(PrefixFilter) 29 | 前缀过滤器将会过滤掉不匹配的记录，过滤的对象是主键的值。 30 | 31 | PrefixFilter(byte[] prefix) 32 | 33 | 页过滤器(PageFilter) 34 | 页过滤器可以根据主键有序返回固定数量的记录，这需要客户端在遍历的时候记住页开始的地方，配合scan的startkey一起使用。 35 | 36 | PageFilter(int size) 37 | 38 | 键过滤器(KeyOnlyFilter) 39 | 键过滤器可以简单的设置过滤的结果集中只包含键而忽略值，这里有一个选项可以把结果集的值保存为值的长度。 40 | FirstKeyOnlyFilter 41 | 在键过滤器的基础上，根据列有序，只包含第一个满足的键。 42 | ColumnPrefixFilter 43 | 这里过滤的对象是列的值。 44 | TimestampsFilter 45 | 46 | TimestampsFilter(List times) 47 | 48 | 这里参数是一个集合，只有包含在集合中的版本才会包含在结果集中。 49 | 包装类过滤器，此类过滤器要通过包装其他的过滤器才有意义，是其他过滤器的一种加强。 50 | SkipFilter 51 | 52 | SkipFilter(Filter filter) 53 | 54 | 过滤器集合(FilterList) 55 | Hbase的过滤器设计遵照于设计模式中的组合模式，以上的所有过滤器都可以叠加起来共同作用于一次查询。 56 | 57 | ## 计数器 58 | 59 | Hbase 提供一个计数器工具可以方便快速的进行计数的操作，而免去了加锁等保证原子性的操作。但是实质上，计数器还是列，有自己的簇和列名。值得注意的是，维护计数器的值最好是用 Hbase 提供的 API，直接操作更新很容易引起数据的混乱。计数器的增量可以是正数负数，正数代表加，负数代表减。 60 | 61 | long icrementColumnValue(byte[] row, byte[] famuly, byte[] qualifier, long amount) Result increment(Increment increment) 62 | 63 | ## 协处理器(Coprocessor ) 64 | 65 | 协处理器的思想是把处理的复杂代码分发到各个 RegionServer，使大部分的计算可以在服务器端，或者扫描的时候完成，提高处理的效率。形式上比较类似 RDBMS 中的存储过程，不同的是，存储过程的原理是在服务器端进行预处理等优化，而协处理器仅仅只是服务器处理，这里又有点类似于 Map-Reduce 中的 Map 阶段。协处理器 (Coprocesssor) 有两种，一种是观察者(Obsever )另外一种是 Endpoint(LZ 跪了，实在不知道翻译成啥)。每个协处理器都有一个优先级，优先级分为 USER/SYSTEM，优先级决定处理器的执行顺序，SYSTEM 级别的处理器永远先于 USER。每个处理器都有自己的执行环境 (CoprocessorEnvironment)，这个环境包含当前集群和请求的状态等信息，是处理中重要的一部分，以构造函数参数的形式被传入到处理器。另外就是 CoprocessorHost，这是 Hbase 管理协处理器的类，用来维护所有的处理器和其环境。 66 | 67 | 协处理器的加载有两种方式，一种是通过配置文件，在配置文件中指定加载路径、类名等，通过这种方式加载的处理器都是SYSTEM级别的，会作用于所有的请求，所有的表；另一种方式是通过在创建表的时候在表中指定，这种方式既可以创建全局的SYSTEM级别的处理器，也可以创建USER级别的处理器，USER级别的处理器是针对表的。 68 | 69 | Path path = new Paht("test.jar"); HTableDescriptor htd = new HTableDescriptor("test"); htd.addFamily(new HColumnDescriptor("family1")); htd.setValue("Coprocessor\$1", path.toString + "|" + className + "|" + Coprocessor.Priority.USER); HBaseAdmin admin = new HBaseAdmin(conf); admin.createTable(htd); 70 | 71 | 这里setValue方法有两个参数，第一个参数是协处理器的名字，$后面跟的是影响执行顺序的序号；第二个参数是||。 72 | Observer 73 | 这是第一种处理器，观察者，观察者有三种，分别用来监听RegionServerObserver、MasterServerObserver、WALObserver。 74 | RegionServer监听的是Region Server上的操作，如在Region Server上的Get、Put等。操作被赋予生命周期：Pending open--open--Pending close 75 | 监听器是可以监听生命周期中的各个阶段，并对其做出处理。 76 | 每一个监听的方法都有一个上下文参数(Context)，通过Context参数可以直接的操作请求的声明周期。 77 | 78 | void bypass(); void complete(); MasterObserver 监听的是 Master Server 上的操作，有点类似 RDBMS 中的 DDL 的操作如表操作、列操作等。具体的操作和 RegionServer 比较类似。Endpoint 这是第二种处理器，Endpoint 相当于被分发到各个 RegionServer 上的存储过程，可以在客户端远程调用的方法。Endpoint 的存在使我们可以进行一些服务器端的计算，如服务器聚集、求和等运算，弥补了查询 API 的不足。服务器端计算的优势是显而易见的，它可以降低网络传输的数据量，合理利用服务器资源。从功能上可以看出 Endpoint 是一个基于 RPC 调用的模块，所以在实现自己的 Endpoint 时候需要定义我们自己的通信协议。在 Hbase 中，通信协议被抽象为 CoprocessorProtocol 接口，要实现我们的协议，我们要创建协议接口继承自 CoprocessorProtocol 接口，然后再实现我们的协议类。\ 79 | public interface MyProtocol extends CoprocessorProtocol { public int work(); } 协议类本身也是处理器，所以还要继承 BaseEndpointCoprocessor 类。 80 | 81 | public class MyEndpoint extends BaseEndpointCoprocessor implements MyProtocol { public int work() { Sytem.out.println("hello"); } } 在抽象的父类 BaseEndpointCoprocessor 中还提供了一些有用的方法，如我们可以拿到对应的环境类。\ 82 | RegionCoprocessorEnvironment getEnvironment() 83 | 84 | 配置好Endpoint重启集群环境以后，我们的实现类会被分发到各个RegionServer，通过HTable实例的方法我们可以调用到Endpoint。 85 | 86 | Map coprocessorExec(Class protocol, byte[] startKey, byte[] endKey, Batch.Call callable); 87 | 88 | startKey和endKey用于确定哪些RegionServer将执行Endpoint，Batch中的内部类将决定协议中方法的调用。 89 | 90 | 四、HTablePool 连接池 在 Hbase 中，创建一个代表表的 HTable 实例是一个耗时且很占资源的操作，类似操作数据库，我们也需要建立我们自己的连接池，于是有了代表连接池的抽象类：HTable。 91 | 92 | HTablePool(Configuaration conf, int maxSize) HTablePool(Configuaration conf, int maxSize, HTableInterfaceFactory factory) 93 | 94 | 创建HTable需要配置文件的实例，连接池的最大连接数也在构造方法中设置。另外，如果想要自己控制HTable被创建的过程，则需要实现自己的工厂方法。在连接池中，最大连接数(maxSize)的含义是，连接池管理的最大的连接数，当所需要的连接数超过最大值时，会临时的创建连接来满足需求，但是这些连接在使用完毕之后会被直接释放且丢弃而不会进入连接池被管理，所以最大连接数代表的是连接池中最大被管理的连接数，而不是使用连接池最大可使用的连接数。 95 | 96 | HTableInterface getTable(String tableName) HTableInterface getTable(byte[] tableName) void putTable(HTableInterface table) 97 | 98 | 需要注意的是，使用完连接以后需要手动的调用putTable方法将连接放回池中。 99 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/Hive/数据类型.md: -------------------------------------------------------------------------------- 1 | Hive 是基于 Hadoop 分布式文件系统的，它的数据存储在 Hadoop 分布式文件系统中。Hive 本身是没有专门的数据存储格式，也没有为数据建立索引，只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据。所以往 Hive 表里面导入数据只是简单的将数据移动到表所在的目录中(如果数据是在 HDFS 上；但如果数据是在本地文件系统中，那么是将数据复制到表所在的目录中)。 2 | 3 | Hive 中主要包含以下几种数据模型：Table(表)，External Table(外部表)，Partition(分区)，Bucket(桶)。 4 | 5 | 1. 表：Hive 中的表和关系型数据库中的表在概念上很类似，每个表在 HDFS 中都有相应的目录用来存储表的数据，这个目录可以通过\${HIVE_HOME}/conf/hive-site.xml 配置文件中的 hive.metastore.warehouse.dir 属性来配置，这个属性默认的值是/user/hive/warehouse(这个目录在 HDFS 上)，我们可以根据实际的情况来修改这个配置。如果我有一个表 wyp，那么在 HDFS 中会创建/user/hive/warehouse/wyp 目录(这里假定 hive.metastore.warehouse.dir 配置为/user/hive/warehouse)；wyp 表所有的数据都存放在这个目录中。这个例外是外部表。 6 | 2. 外部表：Hive 中的外部表和表很类似，但是其数据不是放在自己表所属的目录中，而是存放到别处，这样的好处是如果你要删除这个外部表，该外部表所指向的数据是不会被删除的，它只会删除外部表对应的元数据；而如果你要删除表，该表对应的所有数据包括元数据都会被删除。 7 | 3. 分区：在 Hive 中，表的每一个分区对应表下的相应目录，所有分区的数据都是存储在对应的目录中。比如 wyp 表有 dt 和 city 两个分区，则对应 dt=20131218,city=BJ 对应表的目录为/user/hive/warehouse/dt=20131218/city=BJ，所有属于这个分区的数据都存放在这个目录中。 8 | 4. 桶：对指定的列计算其 hash，根据 hash 值切分数据，目的是为了并行，每一个桶对应一个文件(注意和分区的区别)。比如将 wyp 表 id 列分散至 16 个桶中，首先对 id 列的值计算 hash，对应 hash 值为 0 和 16 的数据存储的 HDFS 目录为：/user/hive/warehouse/wyp/part-00000；而 hash 值为 2 的数据存储的 HDFS 目录为：/user/hive/warehouse/wyp/part-00002。 9 | 10 | [![img](http://cms.csdnimg.cn/article/201401/07/52cc1d1ae43c5_middle.jpg?_=62794)](http://cms.csdnimg.cn/article/201401/07/52cc1d1ae43c5.jpg) 11 | 12 | **Hive 数据抽象结构图** 13 | 14 | 可以看出，表是在数据库下面，而表里面又要分区、桶、倾斜的数据和正常的数据等；分区下面也是可以建立桶的。 15 | 16 | **Hive 的元数据** 17 | 18 | Hive 中的元数据包括表的名字，表的列和分区及其属性，表的属性(是否为外部表等)，表的数据所在目录等。由于 Hive 的元数据需要不断的更新、修改，而 HDFS 系统中的文件是多读少改的，这显然不能将 Hive 的元数据存储在 HDFS 中。目前 Hive 将元数据存储在数据库中，如 Mysql、Derby 中。我们可以通过以下的配置来修改 Hive 元数据的存储方式： 19 | 20 | ``` 21 | 22 | javax.jdo.option.ConnectionURL 23 | jdbc:mysql://localhost:3306/hive_hdp?characterEncoding=UTF-8 24 | &createDatabaseIfNotExist=true 25 | JDBC connect string for a JDBC metastore 26 | 27 | 28 | 29 | javax.jdo.option.ConnectionDriverName 30 | com.mysql.jdbc.Driver 31 | Driver class name for a JDBC metastore 32 | 33 | 34 | 35 | javax.jdo.option.ConnectionUserName 36 | root 37 | username to use against metastore database 38 | 39 | 40 | 41 | javax.jdo.option.ConnectionPassword 42 | 123456 43 | password to use against metastore database 44 | 45 | ``` 46 | 47 | 当然，你还需要将相应数据库的启动复制到\${HIVE_HOME}/lib 目录中，这样才能将元数据存储在对应的数据库中。(责编：周小璐) 48 | 49 | ## Column Types 50 | 51 | Column type are used as column data types of Hive. They are as follows: 52 | 53 | ### Integral Types 54 | 55 | Integer type data can be specified using integral data types, INT. When the data range exceeds the range of INT, you need to use BIGINT and if the data range is smaller than the INT, you use SMALLINT. TINYINT is smaller than SMALLINT. 56 | 57 | The following table depicts various INT data types: 58 | 59 | | Type | Postfix | Example | 60 | | -------- | ------- | ------- | 61 | | TINYINT | Y | 10Y | 62 | | SMALLINT | S | 10S | 63 | | INT | - | 10 | 64 | | BIGINT | L | 10L | 65 | 66 | ### String Types 67 | 68 | String type data types can be specified using single quotes (' ') or double quotes (" "). It contains two data types: VARCHAR and CHAR. Hive follows C-types escape characters. 69 | 70 | The following table depicts various CHAR data types: 71 | 72 | | Data Type | Length | 73 | | --------- | ---------- | 74 | | VARCHAR | 1 to 65355 | 75 | | CHAR | 255 | 76 | 77 | ### Timestamp 78 | 79 | It supports traditional UNIX timestamp with optional nanosecond precision. It supports java.sql.Timestamp format “YYYY-MM-DD HH:MM:SS.fffffffff” and format “yyyy-mm-dd hh:mm:ss.ffffffffff”. 80 | 81 | ### Dates 82 | 83 | DATE values are described in year/month/day format in the form {{YYYY-MM-DD}}. 84 | 85 | ### Decimals 86 | 87 | The DECIMAL type in Hive is as same as Big Decimal format of Java. It is used for representing immutable arbitrary precision. The syntax and example is as follows: 88 | 89 | ``` 90 | DECIMAL(precision, scale) 91 | decimal(10,0) 92 | ``` 93 | 94 | ### Union Types 95 | 96 | Union is a collection of heterogeneous data types. You can create an instance using **create union**. The syntax and example is as follows: 97 | 98 | ``` 99 | UNIONTYPE, struct> 100 | 101 | {0:1} 102 | {1:2.0} 103 | {2:["three","four"]} 104 | {3:{"a":5,"b":"five"}} 105 | {2:["six","seven"]} 106 | {3:{"a":8,"b":"eight"}} 107 | {0:9} 108 | {1:10.0} 109 | ``` 110 | 111 | ## Literals 112 | 113 | The following literals are used in Hive: 114 | 115 | ### Floating Point Types 116 | 117 | Floating point types are nothing but numbers with decimal points. Generally, this type of data is composed of DOUBLE data type. 118 | 119 | ### Decimal Type 120 | 121 | Decimal type data is nothing but floating point value with higher range than DOUBLE data type. The range of decimal type is approximately -10 122 | 123 | -308 124 | 125 | to 10 126 | 127 | 308 128 | 129 | . 130 | 131 | ## Null Value 132 | 133 | Missing values are represented by the special value NULL. 134 | 135 | ## Complex Types 136 | 137 | The Hive complex data types are as follows: 138 | 139 | ### Arrays 140 | 141 | Arrays in Hive are used the same way they are used in Java. 142 | 143 | ``` 144 | Syntax: ARRAY 145 | ``` 146 | 147 | ### Maps 148 | 149 | Maps in Hive are similar to Java Maps. 150 | 151 | ``` 152 | Syntax: MAP 153 | ``` 154 | 155 | ### Structs 156 | 157 | Structs in Hive is similar to using complex data with comment. 158 | -------------------------------------------------------------------------------- /10~OLAP/01.引擎架构/01.MPP/99~参考资料/2022-MPP 架构、常见 OLAP 引擎分析.md: -------------------------------------------------------------------------------- 1 | # MPP 架构、常见 OLAP 引擎分析 2 | 3 | # 一、MPP 架构 4 | 5 | MPP 是系统架构角度的一种服务器分类方法。目前商用的服务器分类大体有三种： 6 | 7 | - SMP（对称多处理器结构） 8 | - NUMA（非一致存储访问结构） 9 | - MPP（大规模并行处理结构） 10 | 11 | 我们今天的主角是 MPP，因为随着分布式、并行化技术成熟应用，MPP 引擎逐渐表现出强大的高吞吐、低时延计算能力，有很多采用 MPP 架构的引擎都能达到“亿级秒开”。 12 | 13 | ## 1、SMP(Symmetrical Multi-Processing)对称多处理器结构 14 | 15 | 即对称多处理器结构，就是指服务器的多个 CPU 对称工作，无主次或从属关系。SMP 服务器的主要特征是共享，系统中的所有资源（如 CPU、内存、I/O 等）都是共享的。也正是由于这种特征，导致了 SMP 服务器的主要问题，即扩展能力非常有限。 16 | 17 | ## 2、NUMA(Non Uniform Memory Access)非一致存储访问结构 18 | 19 | 即非一致存储访问结构。这种结构就是为了解决 SMP 扩展能力不足的问题，利用 NUMA 技术，可以把几十个 CPU 组合在一台服务器内。 20 | 21 | NUMA 的基本特征是拥有多个 CPU 模块，节点之间可以通过互联模块进行连接和信息交互，所以，每个 CPU 可以访问整个系统的内存（这是与 MPP 系统的重要区别）。但是访问的速度是不一样的，因为 CPU 访问本地内存的速度远远高于系统内其他节点的内存速度，这也是非一致存储访问 NUMA 的由来。 22 | 23 | 这种结构也有一定的缺陷，由于访问异地内存的时延远远超过访问本地内存，因此，当 CPU 数量增加时，系统性能无法线性增加。 24 | 25 | ## 3、MPP(Massively Parallel Processing)大规模并行处理结构 26 | 27 | 即大规模并行处理结构。MPP 的系统扩展和 NUMA 不同，MPP 是由多台 SMP 服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户的角度来看是一个服务器系统。每个节点只访问自己的资源，所以是一种完全无共享（Share Nothing）结构。 28 | 29 | MPP 结构扩展能力最强，理论可以无限扩展。由于 MPP 是多台 SPM 服务器连接的，每个节点的 CPU 不能访问另一个节点内存，所以也不存在异地访问的问题。 30 | 31 | ![MPP 架构图](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230407225321.png) 32 | 33 | 每个节点内的 CPU 不能访问另一个节点的内存，节点之间的信息交互是通过节点互联网络实现的，这个过程称为数据重分配。但是 MPP 服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。 34 | 35 | 目前，一些基于 MPP 技术的服务器往往通过系统级软件（如数据库）来屏蔽这种复杂性。举个例子，Teradata 就是基于 MPP 技术的一个关系数据库软件（这是最早采用 MPP 架构的数据库），基于此数据库来开发应用时，不管后台服务器由多少节点组成，开发人员面对的都是同一个数据库系统，而无需考虑如何调度其中某几个节点的负载。 36 | 37 | MPP 架构特征： 38 | 39 | - 任务并行执行; 40 | - 数据分布式存储(本地化); 41 | - 分布式计算; 42 | - 高并发，单个节点并发能力大于 300 用户; 43 | - 横向扩展，支持集群节点的扩容; 44 | - Shared Nothing（完全无共享）架构。 45 | 46 | NUMA 和 MPP 区别：二者有许多相似之处，首先 NUMA 和 MPP 都是由多个节点组成的；其次每个节点都有自己的 CPU，内存，I/O 等；都可以都过节点互联机制进行信息交互。那它们的区别是什么呢，首先是节点互联机制不同，NUMA 的节点互联是在同一台物理服务器内部实现的，MPP 的节点互联是在不同的 SMP 服务器外部通过 I/O 实现的。其次是内存访问机制不同，在 NUMA 服务器内部，任何一个 CPU 都可以访问整个系统的内存，但异地内存访问的性能远远低于本地内存访问，因此，在开发应用程序时应该尽量避免异地内存访问。而在 MPP 服务器中，每个节点只访问本地内存，不存在异地内存访问问题。 47 | 48 | # 二、批处理架构和 MPP 架构 49 | 50 | 批处理架构（如 MapReduce）与 MPP 架构的异同点，以及它们各自的优缺点是什么呢？ 51 | 52 | - 相同点：批处理架构与 MPP 架构都是分布式并行处理，将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。 53 | - 不同点：批处理架构和 MPP 架构的不同点可以举例来说：我们执行一个任务，首先这个任务会被分成多个 task 执行，对于 MapReduce 来说，这些 tasks 被随机的分配在空闲的 Executor 上；而对于 MPP 架构的引擎来说，每个处理数据的 task 被绑定到持有该数据切片的指定 Executor 上。 54 | 55 | 正是由于以上的不同，使得两种架构有各自优势也有各自缺陷： 56 | 57 | - 批处理优劣对比： 58 | 59 | - 批处理的优势：对于批处理架构来说，如果某个 Executor 执行过慢，那么这个 Executor 会慢慢分配到更少的 task 执行，批处理架构有个推测执行策略，推测出某个 Executor 执行过慢或者有故障，则在接下来分配 task 时就会较少的分配给它或者直接不分配，这样就不会因为某个节点出现问题而导致集群的性能受限。 60 | - 批处理的缺陷：任何事情都是有代价的，对于批处理而言，它的优势也造成了它的缺点，会将中间结果写入到磁盘中，这严重限制了处理数据的性能。 61 | 62 | - MPP 优劣对比： 63 | - MPP 的优势：MPP 架构不需要将中间数据写入磁盘，因为一个单一的 Executor 只处理一个单一的 task，因此可以简单直接将数据 stream 到下一个执行阶段。这个过程称为 pipelining，它提供了很大的性能提升。 64 | - MPP 的缺陷：对于 MPP 架构来说，因为 task 和 Executor 是绑定的，如果某个 Executor 执行过慢或故障，将会导致整个集群的性能就会受限于这个故障节点的执行速度(所谓木桶的短板效应)，所以 MPP 架构的最大缺陷就是——短板效应。 65 | 66 | 另一点，集群中的节点越多，则某个节点出现问题的概率越大，而一旦有节点出现问题，对于 MPP 架构来说，将导致整个集群性能受限，所以一般实际生产中 MPP 架构的集群节点不易过多。举个例子来说下两种架构的数据落盘：要实现两个大表的 join 操作, 67 | 68 | - 对于批处理而言，如 Spark 将会写磁盘三次(第一次写入：表 1 根据 join key 进行 shuffle；第二次写入：表 2 根据 join key 进行 shuffle；第三次写入：Hash 表写入磁盘)， 69 | - 而 MPP 只需要一次写入(Hash 表写入)。这是因为 MPP 将 mapper 和 reducer 同时运行，而 MapReduce 将它们分成有依赖关系的 tasks(DAG),这些 task 是异步执行的，因此必须通过写入中间数据共享内存来解决数据的依赖。 70 | 71 | # 三、MPP 架构的 OLAP 引擎 72 | 73 | 采用 MPP 架构的 OLAP 引擎有很多，下面只选择常见的几个引擎对比下。采用 MPP 架构的 OLAP 引擎分为两类，一类：是自身不存储数据，只负责计算的引擎；一类：是自身既存储数据，也负责计算的引擎。 74 | 75 | ## 1）只负责计算，不负责存储的引擎 76 | 77 | ### 1、Impala 78 | 79 | Apache Impala 是采用 MPP 架构的查询引擎，本身不存储任何数据，直接使用内存进行计算，兼顾数据仓库，具有实时，批处理，多并发等优点。提供了类 SQL（类 Hsql）语法，在多用户场景下也能拥有较高的响应速度和吞吐量。它是由 Java 和 C++实现的，Java 提供的查询交互的接口和实现，C++实现了查询引擎部分。 80 | 81 | Impala 支持共享 Hive Metastore，但没有再使用缓慢的 Hive+MapReduce 批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成），可以直接从 HDFS 或 HBase 中用 SELECT、JOIN 和统计函数查询数据，从而大大降低了延迟。 82 | 83 | Impala 经常搭配存储引擎 Kudu 一起提供服务，这么做最大的优势是查询比较快，并且支持数据的 Update 和 Delete。 84 | 85 | ### 2、Presto 86 | 87 | Presto 是一个分布式的采用 MPP 架构的查询引擎，本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。Presto 是一个 OLAP 的工具，擅长对海量数据进行复杂的分析；但是对于 OLTP 场景，并不是 Presto 所擅长，所以不要把 Presto 当做数据库来使用。 88 | 89 | Presto 是一个低延迟高并发的内存计算引擎。需要从其他数据源获取数据来进行运算分析，它可以连接多种数据源，包括 Hive、RDBMS（Mysql、Oracle、Tidb 等）、Kafka、MongoDB、Redis 等。 90 | 91 | ## 2）既负责计算，又负责存储的引擎 92 | 93 | ### 1、ClickHouse 94 | 95 | ClickHouse 是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。它自包含了存储和计算能力，完全自主实现了高可用，而且支持完整的 SQL 语法包括 JOIN 等，技术上有着明显优势。相比于 hadoop 体系，以数据库的方式来做大数据处理更加简单易用，学习成本低且灵活度高。 96 | 97 | ClickHouse 在计算层做了非常细致的工作，竭尽所能榨干硬件能力，提升查询速度。它实现了单机多核并行、分布式计算、向量化执行与 SIMD 指令、代码生成等多种重要技术。ClickHouse 从 OLAP 场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据 Sharding、数据 Partitioning、TTL、主备复制等丰富功能。以上功能共同为 ClickHouse 极速的分析性能奠定了基础。 98 | 99 | ### 2、Doris 100 | 101 | Doris 是百度主导的，根据 Google Mesa 论文和 Impala 项目改写的一个大数据分析引擎，是一个海量分布式 KV 存储系统，其设计目标是支持中等规模高可用可伸缩的 KV 存储集群。Doris 可以实现海量存储，线性伸缩、平滑扩容，自动容错、故障转移，高并发，且运维成本低。部署规模，建议部署 4-100+台服务器。 102 | 103 | Doris3 的主要架构：DT（Data Transfer）负责数据导入、DS（Data Seacher）模块负责数据查询、DM（Data Master）模块负责集群元数据管理，数据则存储在 Armor 分布式 Key-Value 引擎中。Doris3 依赖 ZooKeeper 存储元数据，从而其他模块依赖 ZooKeeper 做到了无状态，进而整个系统能够做到无故障单点。 104 | 105 | ### 3、Druid 106 | 107 | Druid 是一个开源、分布式、面向列式存储的实时分析数据存储系统。 108 | 109 | Druid 的关键特性如下： 110 | 111 | - 亚秒级的 OLAP 查询分析：采用了列式存储、倒排索引、位图索引等关键技术； 112 | - 在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作； 113 | - 实时流数据分析：Druid 提供了实时流数据分析，以及高效实时写入； 114 | - 实时数据在亚秒级内的可视化； 115 | - 丰富的数据分析功能：Druid 提供了友好的可视化界面； 116 | - SQL 查询语言； 117 | - 高可用性与高可拓展性： 118 | - Druid 工作节点功能单一，不相互依赖； 119 | - Druid 集群在管理、容错、灾备、扩容都很容易； 120 | 121 | ### 4、TiDB 122 | 123 | TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持 OLTP 与 OLAP 的融合型分布式数据库产品。 124 | 125 | TiDB 兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP、OLAP、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。 126 | 127 | ### 5、Greenplum 128 | 129 | Greenplum 是在开源的 PostgreSQL 的基础上采用了 MPP 架构的性能非常强大的关系型分布式数据库。为了兼容 Hadoop 生态，又推出了 HAWQ，分析引擎保留了 Greenplum 的高性能引擎，下层存储不再采用本地硬盘而改用 HDFS，规避本地硬盘可靠性差的问题，同时融入 Hadoop 生态。 130 | 131 | ## 总结：常用引擎对比 132 | 133 | ![常用引擎对比](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230407230212.png) 134 | -------------------------------------------------------------------------------- /01~大数据体系/01~大数据生态/数据的特性.md: -------------------------------------------------------------------------------- 1 | # 大数据 2 | 3 | # 数据的来源 4 | 5 | 数据的增长，为什么会如此之快？ 6 | 7 | 说到这里，就要回顾一下人类社会数据产生的几个重要阶段。 8 | 9 | 大致来说，是三个重要的阶段。 10 | 11 | 第一个阶段，就是计算机被发明之后的阶段。尤其是数据库被发明之后，使得数据管理的复杂度大大降低。各行各业开始产生了数据，从而被记录在数据库中。 12 | 13 | 这时的数据，以结构化数据为主（待会解释什么是“结构化数据”）。数据的产生方式，也是被动的。 14 | 15 | 第二个阶段，是伴随着互联网 2.0 时代出现的。互联网 2.0 的最重要标志，就是用户原创内容。 16 | 17 | 随着互联网和移动通信设备的普及，人们开始使用博客、facebook、youtube 这样的社交网络，从而主动产生了大量的数据。 18 | 19 | 第三个阶段，是感知式系统阶段。随着物联网的发展，各种各样的感知层节点开始自动产生大量的数据，例如遍布世界各个角落的传感器、摄像头。 20 | 21 | 经过了“被动-主动-自动”这三个阶段的发展，最终导致了人类数据总量的极速膨胀。 22 | 23 | ## 机器数据 24 | 25 | 机器数据中包含客户、用户、交易、应用程序、服务器、网络和手机设备所有活动和行为的明确记录。不仅仅包含日志。还包括配置、API 中的数据、消息队列、更改事件、诊断命令输出、工业系统呼叫详细信息记录和传感器数据等。计算机数以未知格式的阵列存储，监测和分析工具的传统集并未为多样性、速率、数据量、可变性设计。一个专为此独特类型数据设计的全新方法，必须可以快速诊断服务问题、检测复杂信息安全威胁、远程设备的健康状况和性能，以及说明合规性。 26 | 27 | > 每个环境都有独特的机器数据空间，以下是一些示例。 28 | 29 | | 数据类型 | 位置 | 它可以告诉您什么 | 30 | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | 31 | | 应用日志 | 本地日志文件、log4j、log4net、Weblogic、WebSphere、JBoss、.NET、PHP | 用户活动、欺诈检测、应用性能 | 32 | | 业务流程日志 | 业务流程管理日志 | 跨渠道客户活动、购买、帐户变更以及问题报表 | 33 | | 呼叫详细信息记录 | 呼叫详细信息记录 (CDR)、计费数据记录、事件数据记录均由电信和网络交换机所记录 | 计费、收入保证、客户保证、合作伙伴结算，营销智能 | 34 | | 点击流数据 | Web 服务器、路由器、代理服务器和广告服务器 | 可用性分析、数字市场营销和一般调查 | 35 | | 配置文件 | 系统配置文件 | 如何设置基础设施、调试故障、后门攻击、”定时炸弹”病毒 | 36 | | 数据库审计日志 | 数据库日志文件、审计表 | 如何根据时间修改数据库数据以及如何确定修改人 | 37 | | 文件系统审计日志 | 敏感数据存储在共享文件系统中 | 监测并审计敏感数据读取权限 | 38 | | 管理并记录 API | 通过 OPSEC Log Export API (OPSEC LEA) 和其他 VMware 和 Citrix 供应商特定 API 的 Checkpoint 防火墙 | 管理数据和日志事件 | 39 | | 消息队列 | JMS、RabbitMQ 和 AquaLogic | 调试复杂应用中的问题，并作为记录应用架构基础 | 40 | | 操作系统度量、状态和诊断命令 | 通过命令行实用程序(例如 Unix 和 Linux 上的 ps 与 iostat 以及 Windows 上的性能监视器)显示的 CPU、内存利用率和状态信息 | 故障排除、分析趋势以发现潜在问题并调查安全事件 | 41 | | 数据包/流量数据 | tcpdump 和 tcpflow 可生成 pcap 或流量数据以及其他有用的数据包级和会话级信息 | 性能降级、超时、瓶颈或可疑活动可表明网络被入侵或者受到远程攻击 | 42 | | SCADA 数据 | 监视控制与数据采集 (SCADA) | 识别 SCADA 基础结构中的趋势、模式和异常情况，并用于实现客户价值 | 43 | | 传感器数据 | 传感器设备可以根据监测环境条件生成数据，例如气温、声音、压力、功率以及水位 | 水位监测、机器健康状态监测和智能家居监测 | 44 | | Syslog | 路由器、交换机和网络设备上的 Syslog | 故障排除、分析、安全审计 | 45 | | Web 访问日志 | Web 访问日志会报告 Web 服务器处理的每个请求 | Web 市场营销分析报表 | 46 | | Web 代理日志 | Web 代理记录用户通过代理发出的每个 Web 请求 | 监测并调查服务条款以及数据泄露事件 | 47 | | Windows 事件 | Windows 应用、安全和系统事件日志 | 使用业务关键应用、安全信息和使用模式检测问题， | 48 | | 线上数据 | DNS 查找和记录，协议级信息，包括标头、内容以及流记录 | 主动监测应用性能和可用性、最终客户体验、事件调查、网络、威胁检测、监控和合规性 | 49 | 50 | ## 大数据存储与处理 51 | 52 | 大数据不仅仅意味着庞大的数据量，还意味着数据纬度之多。 53 | 54 | ## 数据仓库与数据治理 55 | 56 | 随着企业应用复杂性的上升和微服务架构的流行，数据正变得越来越以应用为中心。服务之间仅在必要时以接口或者消息队列方式进行数据交互，从而避免了构建单一数据库集群来支撑不断增长的业务需要。以应用为中心的数据持久化架构，在带来可伸缩性好处的同时，也给数据的融合计算带来了障碍。 57 | 58 | 由于数据散落在不同的数据库、消息队列、文件系统中，计算平台如果直接访问这些数据，会遇到可访问性和数据传输延迟等问题。在一些场景下，计算平台直接访问应用系统数据库会对系统吞吐造成显著影响，通常也是不被允许的。 59 | 60 | 依赖于 ETL，Data Pipeline 与数据仓库等不同层次的解决方案。 61 | 62 | # 大数据的特点 63 | 64 | 行业里对大数据的特点，概括为 4 个 V。前面所说的庞大数据体量，就是 Volume（海量化）。除了 Volume 之外，剩下三个，分别是 Variety、Velocity、Value。 65 | 66 | ## Variety（多样化） 67 | 68 | 数据的形式是多种多样的，包括数字（价格、交易数据、体重、人数等）、文本（邮件、网页等）、图像、音频、视频、位置信息（经纬度、海拔等），等等，都是数据。 69 | 70 | 数据又分为结构化数据和非结构化数据。 71 | 72 | 从名字可以看出，结构化数据，是指可以用预先定义的数据模型表述，或者，可以存入关系型数据库的数据。 73 | 74 | 例如，一个班级所有人的年龄、一个超市所有商品的价格，这些都是结构化数据。 75 | 76 | 而网页文章、邮件内容、图像、音频、视频等，都属于非结构话数据。 77 | 78 | 在互联网领域里，非结构化数据的占比已经超过整个数据量的 80%。 79 | 80 | 大数据，就符合这样的特点：数据形式多样化，且非结构化数据占比高。 81 | 82 | ## Velocity（时效性） 83 | 84 | 大数据还有一个特点，那就是时效性。从数据的生成到消耗，时间窗口非常小。数据的变化速率，还有处理过程，越来越快。例如变化速率，从以前的按天变化，变成现在的按秒甚至毫秒变化。 85 | 86 | 我们还是用数字来说话： 87 | 88 | 就在刚刚过去的这一分钟，数据世界里发生了什么？ 89 | 90 | Email：2.04 亿封被发出 91 | 92 | Google：200 万次搜索请求被提交 93 | 94 | Youtube：2880 分钟的视频被上传 95 | 96 | Facebook：69.5 万条状态被更新 97 | 98 | Twitter：98000 条推送被发出 99 | 100 | 12306：1840 张车票被卖出 101 | 102 | ## Value（价值密度） 103 | 104 | 最后一个特点，就是价值密度。 105 | 106 | 大数据的数据量很大，但随之带来的，就是价值密度很低，数据中真正有价值的，只是其中的很少一部分。 107 | 108 | 例如通过监控视频寻找犯罪分子的相貌，也许几 TB 的视频文件，真正有价值的，只有几秒钟。 109 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Datawarehouse-Series 7 | 8 | 9 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 34 | 38 | 40 | 45 | 46 |
47 | 64 | 97 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 143 | 144 | 145 | 146 | 155 | 156 | 157 | -------------------------------------------------------------------------------- /03~数仓建模/03~数仓搭建流程/99~参考资料/2022-园陌-做数仓必须搞明白的各种名词及关系，吐血整理.md: -------------------------------------------------------------------------------- 1 | > [原文地址](https://www.51cto.com/article/715015.html) 2 | 3 | # 做数仓必须搞明白的各种名词及关系，吐血整理 4 | 5 | 作为一个数据人，是不是经常被各种名词围绕，是不是对其中很多概念认知模糊。有些词虽然只有一字之差，但是它们意思完全不同，今天我们就来了解下数仓建设及数据分析时常见的一些概念含义及它们之间的关系。 6 | 7 | 本文结构如下图所示： 8 | 9 | ![数仓中概念术语解析](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325000306.png) 10 | 11 | # 数仓中常见概念解析 12 | 13 | ## 1.实体 14 | 15 | 实体是指依附的主体，就是我们分析的一个对象，比如我们分析商品的销售情况，如华为手机近半年的销售量是多少，那华为手机就是一个实体；我们分析用户的活跃度，用户就是一个实体。当然实体也可以现实中不存在的，比如虚拟的业务对象，活动，会员等都可看做一个实体。 16 | 17 | 实体的存在是为了业务分析，作为分析的一个筛选的维度，拥有描述自己的属性，本身具有可分析的价值。 18 | 19 | ## 2. 维度 20 | 21 | 维度就是看待问题的角度，分析业务数据，从什么角度分析，就建立什么样的维度。所以维度就是要对数据进行分析时所用的一个量，比如你要分析产品销售情况，你可以选择按商品类别来进行分析，这就构成一个维度，把所有商品类别集合在一起，就构成了维度表。 22 | 23 | ## 3. 度量 24 | 25 | 度量是业务流程节点上的一个数值。比如销量，价格，成本等等。事实表中的度量可分为三类：完全可加，半可加，不可加。 26 | 27 | - 完全可加的度量是最灵活，最有用的，比如说销量，销售额等，可进行任意维度汇总； 28 | - 半可加的度量可以对某些维度汇总，但不能对所有维度汇总，差额是常见的半可加度量，它除了时间维度外，可以跨所有维度进行加法操作； 29 | - 还有一种是完全不可加的，例如：比率。对于这类非可加度量，一种好的方法是，尽可能存储非可加度量的完全可加分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集中。 30 | 31 | ## 4. 粒度 32 | 33 | 粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。在数仓建设中，我们说这是用户粒度的事实表，那么表中每行数据都是一个用户，无重复用户；例如还有销售粒度的表，那么表中每行都是一条销售记录。 34 | 35 | 选择合适的粒度级别是数据仓库建设好坏的重要关键内容，在设计数据粒度时，通常需重点考虑以下因素： 36 | 37 | 1. 要接受的分析类型、可接受的数据最低粒度和能存储的数据量； 38 | 2. 粒度的层次定义越高，就越不能在该仓库中进行更细致的分析； 39 | 3. 如果存储资源有一定的限制，就只能采用较高的数据粒度划分； 40 | 4. 数据粒度划分策略一定要保证：数据的粒度确实能够满足用户的决策分析需要，这是数据粒度划分策略中最重要的一个准则。 41 | 42 | ## 5. 口径 43 | 44 | 口径就是取数逻辑（如何取数的），比如要取的数是 10 岁以下儿童中男孩的平均身高，这就是统计的口径。 45 | 46 | ## 6. 指标 47 | 48 | 指标是口径的衡量值，也就是最后的结果。比如最近七天的订单量，一个促销活动的购买转化率等。一个指标具体到计算实施，主要有以下几部分组成： 49 | 50 | - 指标加工逻辑，比如 count, sum, avg 51 | - 维度，比如按部门、地域进行指标统计，对应 sql 中的 group by 52 | - 业务限定/修饰词，比如以不同的支付渠道来算对应的指标，微信支付的订单退款率，支付宝支付的订单退款率 。对应 sql 中的 where。 53 | 54 | 除此之外，指标本身还可以衍生、派生出更多的指标，基于这些特点，可以将指标进行分类： 55 | 56 | - 原子指标：基本业务事实，没有业务限定、没有维度。比如订单表中的订单量、订单总金额都算原子指标；业务方更关心的指标，是有实际业务含义，可以直接取数据的指标。比如店铺近 1 天订单支付金额就是一个派生指标，会被直接在产品上展示给商家看。但是这个指标却不能直接从数仓的统一中间层里取数（因为没有现成的事实字段，数仓提供的一般都是大宽表）。需要有一个桥梁连接数仓中间层和业务方的指标需求，于是便有了派生指标 57 | 58 | - 派生指标：维度+修饰词+原子指标。店铺近 1 天订单支付金额中店铺是维度，近 1 天是一个时间类型的修饰词，支付金额是一个原子指标；维度：观察各项指标的角度；修饰词：维度的一个或某些值，比如维度性别下，男和女就是 2 种修饰词。 59 | 60 | - 衍生指标：比如某一个促销活动的转化率就是衍生指标，因为需要促销投放人数指标和促销订单数指标进行计算得出。 61 | 62 | ## 7. 标签 63 | 64 | 标签是人为设定的、根据业务场景需求，对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果，如网红、白富美、萝莉。对于有歧义的标签，我们内部可进行标签区分，比如：苹果，我们可以定义苹果指的是水果，苹果手机才指的是手机。 65 | 66 | ## 8. 自然键 67 | 68 | 由现实中已经存在的属性组成的键，它在业务概念中是唯一的，并具有一定的业务含义，比如商品 ID，员工 ID。以数仓角度看，来自于业务系统的标识符就是自然键，比如业务库中员工的编号。 69 | 70 | ## 9. 持久键 71 | 72 | 保持永久性不会发生变化。有时也被叫做超自然持久键。比如身份证号属于持久键。自然键和持久键区别：举个例子就明白了，比如说公司员工离职之后又重新入职，他的自然键也就是员工编号发生了变化，但是他的持久键身份证号是不变的。 73 | 74 | ## 10. 代理键 75 | 76 | 就是不具有业务含义的键。代理键有许多其他的称呼：无意义键、整数键、非自然键、人工键、合成键等。代理键就是简单的以按照顺序序列生产的整数表示。产品行的第 1 行代理键为 1，则下一行的代理键为 2，如此进行。代理键的作用仅仅是连接维度表和事实表。 77 | 78 | ## 11. 退化维度 79 | 80 | 退化维度，就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表，就是维度属性存储到事实表中，这种存储到事实表中的维度列被称为退化维度。与其他存储在维表中的维度一样，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。 81 | 82 | 那么究竟怎么定义退化维度呢？比如说订单 id，这种量级很大的维度，没必要用一张维度表来进行存储，而我们进行数据查询或者数据过滤的时候又非常需要，所以这种就冗余在事实表里面，这种就叫退化维度，citycode 这种我们也会冗余在事实表里面，但是它有对应的维度表，所以它不是退化维度。 83 | 84 | ## 12. 缓慢变化维 85 | 86 | 维度建模的数据仓库中，有一个概念叫 Slowly Changing Dimensions，中文一般翻译成“缓慢变化维”，经常被简写为 SCD。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理 SCD 的问题。 87 | 88 | - 第一种方式是直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。第一种方式通常简称为“TYPE 1”。 89 | - 第二种方式是添加维度行。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。第二种方式通常简称为“TYPE 2”。 90 | - 第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用 TYPE 1 来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。第三种方式通常简称为“TYPE 3”。 91 | 92 | 在实际建模中，我们可以联合使用三种方式，也可以对一个维度表中的不同属性使用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样的，就是能够支持方便的分析历史变化情况。 93 | 94 | ## 13. 微型维度 95 | 96 | 维度建模中，有一种维度叫 minidimension，中文一般翻译成“微型维度”。微型维度的提出主要是为了解决快变超大维度。以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用 TYPE 2 的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。 97 | 98 | 这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意，这个外关键字必须做 TYPE 1 型处理。 99 | 100 | ## 14. 下钻 101 | 102 | 这是在数据分析中常见的概念，下钻可以理解成增加维的层次，从而可以由粗粒度到细粒度来观察数据，比如对产品销售情况分析时，可以沿着时间维从年到月到日更细粒度的观察数据。从年的维度可以下钻到月的维度、日的维度等。 103 | 104 | ## 15. 上卷 105 | 106 | 知道了下钻，上卷就容易理解了，它俩是相逆的操作，所以上卷可以理解为删掉维的某些层，由细粒度到粗粒度观察数据的操作或沿着维的层次向上聚合汇总数据。 107 | 108 | ## 16. 数据集市 109 | 110 | 数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。数据集市可以分为两种: 111 | 112 | - 一种是独立数据集市，这类数据集市有自己的源数据库和 ETL 架构； 113 | - 另一种是非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的子集。 114 | 115 | # 数仓概念之间的关系 116 | 117 | ## 实体表，事实表，维度表之间的关系 118 | 119 | 在 Kimball 维度建模中有维度与事实，在 Inmon 范式建模中有实体与关系，如果我们分开两种建模方式看这些概念比较容易理解。但是目前也出现了不少混合建模方式，两种建模方式结合起来看，这些概念是不是容易记忆混乱，尤其事实表和实体表，它们之间到底有怎样区别与联系，先看下它们各自概念： 120 | 121 | - 维度表：维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，地域维度表，维度表是事实表的一个分析角度。 122 | - 事实表：事实表其实就是通过各种维度和一些指标值的组合来确定一个事实的，比如通过时间维度，地域组织维度，指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的。 123 | - 实体表：实体表就是一个实际对象的表，实体表放的数据一定是一条条客观存在的事物数据，比如说各种商品，它就是客观存在的，所以可以将其设计一个实体表。实时表只描述各个事物，并不存在具体的事实，所以也有人称实体表是无事实的事实表。 124 | 125 | 举个例子：比如说手机商场中有苹果手机，华为手机等各品牌各型号的手机，这些数据可以组成一个手机实体表，但是表中没有可度量的数据。某天苹果手机卖了 15 台，华为手机卖了 20 台，这些手机销售数据属于事实，组成一个事实表。这样就可以使用日期维度表和地域维度表对这个事实表进行各种维度分析。 126 | 127 | ## 指标与标签的区别 128 | 129 | - 概念不同 130 | 131 | - 指标是用来定义、评价和描述特定事物的一种标准或方式。比如：新增用户数、累计用户数、用户活跃率等是衡量用户发展情况的指标； 132 | - 标签是人为设定的、根据业务场景需求，对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果，如网红、白富美、萝莉。 133 | 134 | - 构成不同 135 | 136 | - 指标名称是对事物质与量两方面特点的命名；指标取值是指标在具体时间、地域、条件下的数量表现，如人的体重，指标名称是体重，指标的取值就是 120 斤； 137 | - 标签名称通常都是形容词或形容词+名词的结构，标签一般是不可量化的，通常是孤立的，除了基础类标签，通过一定算法加工出来的标签一般都没有单位和量纲。如将超过 200 斤的称为大胖子。 138 | 139 | - 分类不同 140 | 141 | - 对指标的分类： 142 | 143 | - 按照指标计算逻辑，可以将指标分为原子指标、派生指标、衍生指标三种类型； 144 | - 按照对事件描述内容的不同，分为过程性指标和结果性指标； 145 | 146 | - 对标签的分类： 147 | - 按照标签的变化性分为静态标签和动态标签； 148 | - 按照标签的指代和评估指标的不同，可分为定性标签和定量标签； 149 | 150 | 指标最擅长的应用是监测、分析、评价和建模。标签最擅长的应用是标注、刻画、分类和特征提取。特别需要指出的是，由于对结果的标注也是一种标签，所以在自然语言处理和机器学习相关的算法应用场景下，标签对于监督式学习有重要价值，只是单纯的指标难以做到的。而指标在任务分配、绩效管理等领域的作用，也是标签无法做到的。 151 | 152 | ## 维度和指标区别与联系 153 | 154 | 维度就是数据的观察角度，即从哪个角度去分析问题，看待问题。指标就是从维度的基础上去衡算这个结果的值。 155 | 156 | 维度一般是一个离散的值，比如时间维度上每一个独立的日期或地域，因此统计时，可以把维度相同记录的聚合在一起，应用聚合函数做累加、均值、最大值、最小值等聚合计算。指标就是被聚合的通计算，即聚合运算的结果，一般是一个连续的值。 157 | 158 | ## 自然键与代理键在数仓的使用区别 159 | 160 | 数仓工具箱中说维度表的唯一主键应该是代理键而不应该是自然键。有时建模人员不愿意放弃使用自然键，因为他们希望与操作型代码查询事实表，而不希望与维度表做连接操作。然而，应该避免使用包含业务含义的多维键，因为不管我们做出任何假设最终都可能变得无效，因为我们控制不了业务库的变动。 161 | 162 | 所以数据仓库中维度表与事实表的每个连接应该基于无实际含义的整数代理键。避免使用自然键作为维度表的主键。 163 | 164 | ## 数据集市与数据仓库的区别与联系 165 | 166 | 数据集市就是企业级数据仓库的一个子集，它主要面向部门级业务，并且只面向某个特定的主题。为了解决灵活性与性能之间的矛盾，数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据，从而满足用户对性能的需求。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。 167 | -------------------------------------------------------------------------------- /10~OLAP/02.MOLAP/HBase/部署与使用.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | Hbase 是运行在 Hadoop 上的 NoSQL 数据库，它是一个分布式的和可扩展的大数据仓库，也就是说 HBase 能够利用 HDFS 的分布式处理模式，并 从 Hadoop 的 MapReduce 程序模型中获益。这意味着在一组商业硬件上存储许多具有数十亿行和上百万列的大表。除去 Hadoop 的优 势，HBase 本身就是十分强大的数据库，它能够融合 key/value 存储模式带来实时查询的能力，以及通过 MapReduce 进行离线处理或者批处理 的能力。总的来说，Hbase 能够让你在大量的数据中查询记录，也可以从中获得综合分析报告。HBase 的发展历史进程简介如下 4 | 5 | - 2006.11 G release paper on BigTable 6 | - 2007.2 inital HBase prototype created as Hadoop contrib 7 | - 2007.10 First useable Hbase 8 | - 2008.1 Hadoop become Apache top-level project and Hbase becomes subproject 9 | - 2008.10 Hbase 0.18,0.19 released 10 | 11 | HBase 中的表一般有如下特点 12 | 13 | - 大：一个表可以有上亿行，上百万列 14 | - 面向列 : 面向列 ( 族 ) 的存储和权限控制，列 ( 族 ) 独立检索。 15 | - 稀疏 : 对于为空 (null) 的列，并不占用存储空间，因此，表可以设计的非常稀疏。 16 | 17 | ## Logical View: 逻辑视图 18 | 19 | HBase 介于 NoSQL 和 RDBMS 之间，仅能通过主键 (row key) 和主键的 range 来检索数据，仅支持单行事务 ( 可通过 hive 支持来实现多表 join 等复杂操作 )。主要用来存储非结构化和半结构化的松散数据。HBase 实际上定义了一个四维数据模型，下面就是每一维度的定义： 20 | 21 | - 行键：每行都有唯一的行键，行键没有数据类型，它内部被认为是一个字节数组。 22 | - 列簇：数据在行中被组织成列簇，每行有相同的列簇，但是在行之间，相同的列簇不需要有相同的列修饰符。在引擎中，HBase 将列簇存储在它自己的数据文件中，所以，它们需要事先被定义，此外，改变列簇并不容易。 23 | - 列修饰符：列簇定义真实的列，被称之为列修饰符，你可以认为列修饰符就是列本身。 24 | - 版本：每列都可以有一个可配置的版本数量，你可以通过列修饰符的制定版本获取数据。 25 | 26 | ![](http://jbcdn2.b0.upaiyun.com/2015/01/6cca4d757d9b5e1e0d40cd07b679d6e3.jpg) 如上图所示，通过行键获取一个指定的行，它由一个或多个列簇构成，每个列簇有一个或多个列修饰符(也被称为列)，每列又可以有一个或多个版本。为了获取指定数据，你 需要知道它的行键、列簇、列修饰符以及版本。当设计 HBase 数据模型时，对考虑数据是如何被获取是十分有帮助的。你可以通过以下两种方式获得 HBase 数据： 27 | 28 | - 通过他们的行键，或者一系列行键的表扫描。 29 | - 使用 map-reduce 进行批操作 30 | 31 | ![](http://www.uml.org.cn/zjjs/images/2012111322.png) 32 | 33 | ### Row Key 34 | 35 | Row key 行键 (Row key) 可以是任意字符串 ( 最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在 hbase 内部，row key 保存为字节数组。存储时，数据按照 Row key 的字典序 (byte order) 排序存储。设计 key 时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。( 位置相关性 ) 注意：字典序对 int 排序的结果是 1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用 0 作左填充。行的一次读写是原子操作 ( 不论一次读写多少列 )。这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。 36 | 37 | ### 列簇 38 | 39 | HBase 表中的每个列，都归属与某个列簇。列簇是表的 Schema 的一部分 ( 而列不是 )，必须在使用表之前定义。列名都以列簇作为前缀。例如 courses:history，courses:math 都属于 courses 这个列簇。访问控制、磁盘和内存的使用统计都是在列簇层面进行的。实际应用中，列簇上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据(甚至可能因为隐私的原因不能浏览所有数据)。 40 | 41 | ### 时间戳 42 | 43 | HBase 中通过 row 和 columns 确定的为一个存贮单元称为 cell。每个 cell 都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64 位整型。时间戳可以由 hbase( 在数据写入时自动 ) 赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个 cell 中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。为了避免数据存在过多版本造成的的管理 ( 包括存贮和索引 ) 负担，hbase 提供了两种数据版本回收方式。一是保存数据的最后 n 个版本，二是保存最近一段时间内的版本(比如最近七天)。用户可以针对每个列族进行设置。 44 | 45 | ### Cell 46 | 47 | 由 {row key, column(= + ), version} 唯一确定的单元。cell 中的数据是没有类型的，全部是字节码形式存贮。 48 | 49 | # Quick Start 50 | 51 | ## Installation: 安装 52 | 53 | 让我们开始用命令行操作 HBase，在 HBase bin 目录下执行下面命令： 54 | 55 | ``` 56 | ./hbase shell 57 | ``` 58 | 59 | 你应该看到如下类似的输出： 60 | 61 | ``` 62 | HBase Shell; enter 'help' for list of supported commands. 63 | Type "exit" to leave the HBase Shell 64 | Version 0.98.5-hadoop2, rUnknown, Mon Aug 4 23:58:06 PDT 2014 65 | hbase(main):001:0> 66 | ``` 67 | 68 | ## 表创建 69 | 70 | 创建一个名为 PageViews 的表，并具有名为 info 的列簇： 71 | 72 | ``` 73 | hbase(main):002:0> create 'PageViews', 'info' 74 | 0 row(s) in 5.3160 seconds 75 | => Hbase::Table - PageViews 76 | ``` 77 | 78 | 每张表至少要有一个列簇，因此我们创建了 info，现在，看看我们的表，执行下面 list 命令： 79 | 80 | ``` 81 | hbase(main):002:0> list 82 | 83 | TABLE 84 | 85 | PageViews 86 | 87 | 1 row(s) in 0.0350 seconds 88 | 89 | => ["PageViews"] 90 | ``` 91 | 92 | 如你所见，list 命令返回一个名为 PageViews 的表，我们可以通过 describe 命令得到表的更多信息： 93 | 94 | ``` 95 | hbase(main):003:0> describe 'PageViews' 96 | 97 | DESCRIPTION ENABLED 98 | 99 | 'PageViews', {NAME => 'info', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', 100 | 101 | REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'NONE true 102 | 103 | ', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', 104 | 105 | BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true'} 106 | 107 | 1 row(s) in 0.0480 seconds 108 | ``` 109 | 110 | Describe 命令返回表的详细信息，包括列簇的列表，这里我们创建的仅有一个：info。 111 | 112 | ## 数据插入 113 | 114 | 现在为表添加以下数据，下面命令是在 info 中添加新的行： 115 | 116 | ``` 117 | hbase(main):004:0> put ";PageViews", ";rowkey1", ";info:page", ";/mypage" 118 | 0 row(s) in 0.0850 seconds 119 | ``` 120 | 121 | Put 命令插入一条行键为 rowkey1 的新纪录，指定在 info 下的 page 列，插入值为 /mypage 的记录，我们随后可以通过 get 命令通过行键 rowkey1 查询到这条记录： 122 | 123 | ``` 124 | hbase(main):005:0> get 'PageViews', 'rowkey1' 125 | 126 | COLUMN CELL 127 | 128 | info:page timestamp=1410374788088, value=/mypage 129 | 130 | 1 row(s) in 0.0250 seconds 131 | ``` 132 | 133 | ## 数据查询 134 | 135 | 让我们查询出 PageViews 表的所有记录： 136 | 137 | ``` 138 | hbase(main):007:0> scan 'PageViews' 139 | 140 | ROW COLUMN+CELL 141 | 142 | rowkey1 column=info:page, timestamp=1410374788088, value=/mypage 143 | 144 | rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage 145 | 146 | 2 row(s) in 0.0350 seconds 147 | ``` 148 | 149 | 如前面所提到的，我们不能查询本身，但是我们可以对表进行 scan 操作，如果你执行 scan table 命令，它会返回表中所有行，这很有可能不是你想要做的。你可以给出行的范围来限制返回的结果，让我们插入一带有 s 开头行键的新记录： 150 | 151 | ``` 152 | hbase(main):012:0> put 'PageViews', 'srowkey2', 'info:page', '/myotherpage' 153 | ``` 154 | 155 | 现在，如果我增加点限制，想查询行键在 r 和 s 之间的记录，可以使用如下结构： 156 | 157 | ```sh 158 | hbase(main):014:0> scan 'PageViews', { STARTROW => 'r', ENDROW => 's' } 159 | 160 | ROW COLUMN+CELL 161 | 162 | rowkey1 column=info:page, timestamp=1410374788088, value=/mypage 163 | 164 | rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage 165 | 166 | 2 row(s) in 0.0080 seconds 167 | ``` 168 | 169 | 这个 scan 返回了仅有 s 开头的记录，这个类比是基于全行键上的，所以 rowkey1 比 r 大，所有它被返回了。另外，scan 的结果包含了所指范围的 STARTROW，但不包含 ENDROW，注意，ENDROW 不是必须指定的，如果我们执行相同查询只给出了 STARTROW，那么我们会得到行键比 r 大 的所有记录。 170 | 171 | ```sh 172 | hbase(main):013:0> scan 'PageViews', { STARTROW => 'r' } 173 | 174 | ROW COLUMN+CELL 175 | 176 | rowkey1 column=info:page, timestamp=1410374788088, value=/mypage 177 | 178 | rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage 179 | 180 | srowkey2 column=info:page, timestamp=1410375975965, value=/myotherpage 181 | 182 | 3 row(s) in 0.0120 seconds 183 | ``` 184 | -------------------------------------------------------------------------------- /10~OLAP/01.引擎架构/99~参考资料/2021-常用引擎对比与概述.md: -------------------------------------------------------------------------------- 1 | # OLAP 常用引擎对比与概述 2 | 3 | 我们来介绍和对比一下目前大数据业内非常流行的几个 OLAP 引擎，它们是 Hive、SparkSQL、FlinkSQL、ClickHouse、Elasticsearch、Druid、Kylin、Presto、Impala、Doris。可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。 4 | 5 | # 能力对比 6 | 7 | ## 并发能力与查询延迟对比 8 | 9 | 这里可能有朋友有疑问：Hive，SparkSQL，FlinkSQL 这些它们要么查询速度慢，要么 QPS 上不去，怎么能算是 OLAP 引擎呢？其实 OLAP 的定义中并没有关于查询执行速度和 QPS 的限定。进一步来说，这里引出了衡量 OLAP 特定业务场景的两个重要的指标： 10 | 11 | - 查询速度：Search Latency（常用 Search Latency Pct99 来衡量） 12 | - 查询并发能力：QPS 13 | 14 | 如果根据不同的查询场景、再按照查询速度与查询并发能力这两个指标来划分以上所列的 OLAP 引擎，这些 OLAP 引擎的能力划分如下。 15 | 16 | ### 简单查询 17 | 18 | 简单查询指的是点查、简单聚合查询或者数据查询能够命中索引或物化视图（物化视图指的是物化的查询中间结果，如预聚合数据）。这样的查询经常出现在【在线数据服务】的企业应用中，如阿里生意参谋、腾讯的广点通、京东的广告业务等，它们共同的特点是对外服务、面向 B 端商业客户（通常是几十万的级别）；并发查询量(QPS)大；对响应时间要求高，一般是 ms 级别（可以想象一下，如果广告主查询页面投放数据，如果 10s 还没有结果，很伤害体验）；查询模式相对固定且简单。从下图可知，这种场景最合适的是 Elasticsearch、Doris、Druid、Kylin 这些。 19 | 20 | ![简单查询](https://pic.imgdb.cn/item/618630e42ab3f51d91c5d3dc.jpg) 21 | 22 | ### 复杂查询 23 | 24 | 复杂查询指的是复杂聚合查询、大批量数据 SCAN、复杂的查询（如 JOIN）。在 ad-hoc 场景中，经常会有这样的查询，往往用户不能预先知道要查询什么，更多的是探索式的。这里也根据 QPS 和查询耗时分几种情况，如下图所示，根据业务的需求来选择对应的引擎即可。有一点要提的是 FlinkSQL 和 SparkSQL 虽然也能完成类似需求，但是它们目前还不是开箱即用，需要做周边生态建设，这两种技术目前更多的应用场景还是在通过操作灵活的编程 API 来完成流式或离线的计算上。 25 | 26 | ![复杂查询](https://pic.imgdb.cn/item/618631012ab3f51d91c5fafc.jpg) 27 | 28 | ## 执行模型对比 29 | 30 | ![执行模型对比](https://pic.imgdb.cn/item/6186315b2ab3f51d91c6897d.jpg) 31 | 32 | - Scatter-Gather 执行模型：相当于 MapReduce 中的一趟 Map 和 Reduce，没有多轮的迭代，而且中间计算结果往往存储在内存中，通过网络直接交换。Elasticsearch、Druid、Kylin 都是此模型。 33 | - MapReduce：Hive 是此模型 34 | - MPP：MPP 学名是大规模并行计算，其实很难给它一个准确的定义。如果说的宽泛一点，Presto、Impala、Doris、ClickHouse、Spark SQL、Flink SQL 这些都算。有人说 Spark SQL 和 Flink SQL 属于 DAG 模型，我们思考后认为，DAG 并不算一种单独的模型，它只是生成执行计划的一种方式。 35 | 36 | # OLAP 引擎的主要特点 37 | 38 | ## Hive 39 | 40 | ![Hive](https://pic.imgdb.cn/item/618631df2ab3f51d91c7450d.jpg) 41 | 42 | Hive 是一个分布式 SQL on Hadoop 方案，底层依赖 MapReduce 计算模型执行分布式计算。Hive 擅长执行长时间运行的离线批处理，数据量越大，优势越明显。Hive 在数据量大、数据驱动需求强烈的互联网大厂比较流行。近 2 年，随着 ClickHouse 的逐渐流行，对于一些总数据量不超过百 PB 级别的互联网数据仓库需求，已经有多家公司改为了 ClickHouse 的方案。ClickHouse 的优势是单个查询执行速度更快，不依赖 hadoop，架构和运维更简单。 43 | 44 | ## Spark SQL、Flink SQL 45 | 46 | ![Spark SQL 与 Flink SQL](https://pic.imgdb.cn/item/6186320c2ab3f51d91c785f5.jpg) 47 | 48 | 在大部分场景下，Hive 计算还是太慢了，别说不能满足那些要求高 QPS、低查询延迟的的对外在线服务的需求，就连企业内部的产品、运营、数据分析师也会经常抱怨 Hive 执行 ad-hoc 查询太慢。这些痛点，推动了 MPP 内存迭代和 DAG 计算模型的诞生和发展，诸如 Spark SQL、Flink SQL、Presto 这些技术，目前在企业中也非常流行。Spark SQL、Flink SQL 的执行速度更快，编程 API 丰富，同时支持流式计算与批处理，并且有流批统一的趋势，使大数据应用更简单。 49 | 50 | 注：上面说的在线服务，指的是如阿里对几百万淘宝店主开放的数据应用生意参谋，腾讯对几十万广告主开发的广点通广告投放分析等。 51 | 52 | ## ClickHouse 53 | 54 | ![ClickHouse 对比](https://pic.imgdb.cn/item/618632602ab3f51d91c80607.jpg) 55 | 56 | ClickHouse 是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进大规模使用： 57 | 58 | - 今日头条 内部用 ClickHouse 来做用户行为分析，内部一共几千个 ClickHouse 节点，单集群最大 1200 节点，总数据量几十 PB，日增原始数据 300TB 左右。 59 | - 腾讯内部用 ClickHouse 做游戏数据分析，并且为之建立了一整套监控运维体系。 60 | - 携程内部从 18 年 7 月份开始接入试用，目前 80%的业务都跑在 ClickHouse 上。每天数据增量十多亿，近百万次查询请求。 61 | - 快手内部也在使用 ClickHouse，存储总量大约 10PB，每天新增 200TB，90%查询小于 3S。 62 | 63 | 在国外，Yandex 内部有数百节点用于做用户点击行为分析，CloudFlare、Spotify 等头部公司也在使用。ClickHouse 从 OLAP 场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据 Sharding、数据 Partitioning、TTL、主备复制等丰富功能。以上功能共同为 ClickHouse 极速的分析性能奠定了基础。 64 | 65 | ClickHouse 部署架构简单，易用，不依赖 Hadoop 体系（HDFS+YARN）。它比较擅长的地方是对一个大数据量的单表进行聚合查询。Clickhouse 用 C++实现，底层实现具备向量化执行（Vectorized Execution）、减枝等优化能力，具备强劲的查询性能。目前在互联网企业均有广泛使用，比较适合内部 BI 报表型应用，可以提供低延迟（ms 级别）的响应速度，也就是说单个查询非常快。但是 Clickhouse 也有它的局限性，在 OLAP 技术选型的时候，应该避免把它作为多表关联查询(JOIN)的引擎，也应该避免把它用在期望支撑高并发数据查询的场景，OLAP 分析场景中，一般认为 QPS 达到 1000+就算高并发，而不是像电商、抢红包等业务场景中，10W 以上才算高并发，毕竟数据分析场景，数据海量，计算复杂，QPS 能够达到 1000 已经非常不容易。例如 Clickhouse，如果如数据量是 TB 级别，聚合计算稍复杂一点，单集群 QPS 一般达到 100 已经很困难了，所以它更适合企业内部 BI 报表应用，而不适合如数十万的广告主报表或者数百万的淘宝店主相关报表应用。Clickhouse 的执行模型决定了它会尽全力来执行一个 Query，而不是同时执行很多 Query。 66 | 67 | ## Elasticsearch 68 | 69 | ![ElasticSearch 架构](https://pic.imgdb.cn/item/618632b72ab3f51d91c88cde.jpg) 70 | 71 | 提到 Elasticsearch，很多人的印象是这是一个开源的分布式搜索引擎，底层依托 Lucene 倒排索引结构，并且支持文本分词，非常适合作为搜索服务。这些印象都对，并且用 Elasticsearch 作为搜索引擎，一个三节点的集群，支撑 1000+的查询 QPS 也不是什么难事，这是搜索场景。 72 | 73 | 但是，我们这里要讲的内容是 Elasticsearch 的另一个功能，即作为聚合（aggregation）场景的 OLAP 引擎，它与搜索型场景区别很大。聚合场景，可以等同于 `select c1, c2, sum(c3), count(c4) from table where c1 in ('china', 'usa') and c2 < 100` 这样的 SQL，也就是做多维度分组聚合。虽然 Elasticsearch DSL 是一个复杂的 JSON 而不是 SQL，但是意思相同，可以互相转换。 74 | 75 | 用 Elasticsearch 作为 OLAP 引擎，有几项优势：（1）擅长高 QPS（QPS > 1K）、低延迟、过滤条件多、查询模式简单（如点查、简单聚合）的查询场景。（2）集群自动化管理能力（shard allocation，recovery）能力非常强。集群、索引管理和查看的 API 非常丰富。 76 | 77 | ES 的执行引擎是最简单的 Scatter-Gather 模型，相当于 MapReduce 计算模型的一趟 Map 和 Reduce。Scatter 和 Gather 之间的节点数据交换也是基于内存的不会像 MapReduce 那样每次 Shuffle 要先落盘。ES 底层依赖的 Lucene 文件格式，我们可以把 Lucene 理解为一种行列混存的模式，并且在查询时通过 FST，跳表等加快数据查询。这种 Scatter-Gather 模型的问题是，如果 Gather/Reduce 的数据量比较大，由于 ES 时单节点执行，可能会非常慢。整体来讲，ES 是通过牺牲灵活性，提高了简单 OLAP 查询的 QPS、降低了延迟。 78 | 79 | 用 Elasticsearch 作为 OLAP 引擎，有几项劣势：多维度分组排序、分页。不支持 Join。在做 aggregation 后，由于返回的数据嵌套层次太多，数据量会过于膨胀。ElasticSearch 和 Solar 也可以归为宽表模型。但其系统设计架构有较大不同，这两个一般称为搜索引擎，通过倒排索引，应用 Scatter-Gather 计算模型提高查询性能。对于搜索类的查询效果较好，但当数据量较大或进行扫描聚合类查询时，查询性能会有较大影响。 80 | 81 | ## Presto 82 | 83 | ![Presto 架构](https://pic.imgdb.cn/item/618632ec2ab3f51d91c8d5c3.jpg) 84 | 85 | Presto、Impala、GreenPlum 均基于 MPP 架构，相比 Elasticsearch、Druid、Kylin 这样的简单 Scatter-Gather 模型，在支持的 SQL 计算上更加通用，更适合 ad-hoc 查询场景，然而这些通用系统往往比专用系统更难做性能优化，所以不太适合做对查询 QPS(参考值 QPS > 1000)、延迟要求比较高(参考值 search latency < 500ms)的在线服务，更适合做公司内部的查询服务和加速 Hive 查询的服务。Presto 还有一个优秀的特性是使用了 ANSI 标准 SQL，并且支持超过 30+的数据源 Connector。 86 | 87 | ## Impala 88 | 89 | Impala 是 Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互 SQL 大数据查询工具，是 CDH 平台首选的 PB 级大数据实时查询分析引擎。它拥有和 Hadoop 一样的可扩展性、它提供了类 SQL（类 Hsql）语法，在多用户场景下也能拥有较高的响应速度和吞吐量。它是由 Java 和 C++实现的，Java 提供的查询交互的接口和实现，C++实现了查询引擎部分，除此之外，Impala 还能够共享 Hive Metastore，甚至可以直接使用 Hive 的 JDBC jar 和 beeline 等直接对 Impala 进行查询、支持丰富的数据存储格式（Parquet、Avro 等）。此外，Impala 没有再使用缓慢的 Hive+MapReduce 批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成），可以直接从 HDFS 或 HBase 中用 SELECT、JOIN 和统计函数查询数据，从而大大降低了延迟。Impala 经常搭配存储引擎 Kudu 一起提供服务，这么做最大的优势是点查比较快，并且支持数据的 Update 和 Delete。 90 | 91 | ![Impala](https://pic.imgdb.cn/item/618633292ab3f51d91c927f8.jpg) 92 | 93 | ## Doris 94 | 95 | ![Doris](https://pic.imgdb.cn/item/618633412ab3f51d91c94dbb.jpg) 96 | 97 | Doris 是百度主导的，根据 Google Mesa 论文和 Impala 项目改写的一个大数据分析引擎，在百度、美团团、京东的广告分析等业务有广泛的应用。Doris 的主要功能特性如下所示： 98 | 99 | - 现代化 MPP 架构 100 | - 支持大规模数据集、集群灵活扩展 101 | - 支持高并发小查询 102 | - 强悍的 SQL 执行引擎、全新的预聚合技术 103 | - 支持亚秒级 OLAP 多维分析 104 | - 支持高效快速的多表关联分析 105 | - 基于 LSM 的列式存储引擎、MVCC 事务隔离机制 106 | - 支持数据高效的实时导入 107 | - 支持数据批量、实时更新 108 | 109 | ## Druid 110 | 111 | ![Druid 架构](https://pic.imgdb.cn/item/6186352e2ab3f51d91cc4572.jpg) 112 | 113 | Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。Druid 支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能，在广告分析场景、监控报警等时序类应用均有广泛使用； 114 | 115 | Druid 的特点包括： 116 | 117 | - Druid 实时的数据消费，真正做到数据摄入实时、查询结果实时 118 | - Druid 支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发 119 | - Druid 的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对按时间进行统计分析的场景 120 | - Druid 把数据列分为三类：时间戳、维度列、指标列 121 | - Druid 不支持多表连接 122 | - Druid 中的数据一般是使用其他计算框架(Spark 等)预计算好的低层次统计数据 123 | - Druid 不适合用于处理透视维度复杂多变的查询场景 124 | - Druid 擅长的查询类型比较单一，一些常用的 SQL(groupby 等)语句在 druid 里运行速度一般 125 | - Druid 支持低延时的数据插入、更新，但是比 hbase、传统数据库要慢很多 126 | 127 | 与其他的时序数据库类似，Druid 在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏 Join、子查询等。 128 | 129 | ## Kylin 130 | 131 | Kylin 自身就是一个 MOLAP 系统，多维立方体（MOLAP Cube）的设计使得用户能够在 Kylin 里为百亿以上数据集定义数据模型并构建立方体进行数据的预聚合。适合 Kylin 的场景包括： 132 | 133 | - 用户数据存在于 Hadoop HDFS 中，利用 Hive 将 HDFS 文件数据以关系数据方式存取，数据量巨大，在 500G 以上 134 | - 每天有数 G 甚至数十 G 的数据增量导入 135 | - 有 10 个以内较为固定的分析维度 136 | 137 | 简单来说，Kylin 中数据立方的思想就是以空间换时间，通过定义一系列的纬度，对每个纬度的组合进行预先计算并存储。有 N 个纬度，就会有 2 的 N 次种组合。所以最好控制好纬度的数量，因为存储量会随着纬度的增加爆炸式的增长，产生灾难性后果。 138 | 139 | ![Kylin 架构](https://pic.imgdb.cn/item/618635972ab3f51d91cce19f.jpg) 140 | 141 | # Links 142 | -------------------------------------------------------------------------------- /03~数仓建模/03~数仓搭建流程/99~参考资料/2021-数据产品小 Lee-数据仓库基础.md: -------------------------------------------------------------------------------- 1 | # 数据仓库基础 2 | 3 | # 维度模型 4 | 5 | ## 什么是模型，什么是建模？ 6 | 7 | 什么是模型？作为数据行业从业者，如果你从来没有思考过这个问题，你一定要看下去。先看一个例子： 8 | 9 | > 2021 年 3 月 6 日，小明到楼下【行家】便利店买吃的，来来回回逛了几圈，虽然很饿，但又想减肥，最终拿了 1 个【柯德吉】人造肉汉堡。准备付账的时候，收银员跟他说，最近搞活动，加 4 块可以选一瓶原价 8 块的【卡石】酸奶。小明觉得很划算，于是去拿了酸奶，一共付了 12 块。 10 | 11 | 上面的这段文字，就是模型。先看看百度百科给出的模型定义： 12 | 13 | > 模型，是指通过主观意识借助实体或者虚拟表现构成客观阐述形态结构的一种表达目的的物件（物件并不等于物体，不局限于实体与虚拟） 14 | 15 | 简单来说，模型是映射 “事实” 的东西，构建这个东西的动作就叫做建模。上述的例子，是一种“文字模型”。而且，这个模型还可以补充更多细节，比如，采用什么方式付款、支付了多少钱。为了表达更加简洁，我们可以省略更多的信息，只记录关键信息： 16 | 17 | > 2021 年 3 月 6 日，小明买了，一个 柯德吉 牌人造肉汉堡，一瓶 卡石 牌酸奶（共计 ￥ 12）。 18 | 19 | ## 范式模型，为了更好地记录和更新 20 | 21 | 计算机的出现，也诞生了新的语言，我们也顺理成章地开始用新语言去建模。假设这个便利店用了现成的 ERP、CRM 系统，这些系统设计好了模型，数据会填充成如下的样子： 22 | 23 | 1）订单表 24 | 25 | ![订单表](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325133622.png) 26 | 27 | 2）订单详情表 28 | 29 | ![订单详情表](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325133644.png) 30 | 31 | 3）商品详情表 32 | 33 | ![商品详情表](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325133717.png) 34 | 35 | 数据量不大，分析人员写 SQL 直接对范式模型进行查询，算账分析无所不能，小几十万数据，速度完全 OK。 36 | 37 | ## 维度模型，为分析而生 38 | 39 | 范式模型很好地解决了快速记录和节约存储空间。但事物都有两面性，当数据量大的时候，从范式模型中查询取数，就比较慢了。但数据量一大，就顶不住了。人类社会，但凡出现问题，总会天降猛士。Innon 和 Kimball 等人提出来新方案：为数据分析设计一套新模型。 40 | 41 | 范式模型主要解决数据的插入和更新，维护一致性等问题，维度模型则解决大数据场景分析的问题，这两者也就是所谓的 OLTP 和 OLAP 。通过一个荒诞的例子来理解两者的区别： 42 | 43 | > 你家是个大家族，七大姑八大姨，平时需要打电话联系。 44 | > 范式建模：每个人只存自己同辈人以及各自子女的联系方式。如果叔叔想找侄子/侄女（你），只能通过你爸爸。 45 | > 维度建模：所有的亲戚联系方式都写到了一个家庭通讯录上，想找人，直接找通讯录。 46 | 47 | 这个例子现实生活不存在，主要想帮助大家理解两种模型的差异： 48 | 49 | 1、范式模型为了应对数据频繁变更的场景，数据存得零散。为了保证数据的一致性，还要符合一定的规范，我们常见的是三范式（3NF）。 50 | 2、维度模型会将数据冗余，把一些相关的数据存到一起，方便快速查询取数。维度模型的出现，就是为了解决大数据量导致的查询慢的问题。 51 | 52 | ## 维度建模的四大要素 53 | 54 | 数据仓库领域的经典著作《维度建模工具箱》中，Kimball 定义了经典的维度建模的四步曲，：选定业务过程、声明粒度、确定维度、构建事实。 55 | 56 | ### 1）业务过程 57 | 58 | 很多数据仓库书籍都给出了业务过程的通用定义：业务过程是企业活动中的事件，如下单、支付、退款都是业务过程，业务过程是一个不可拆分的行为事件。看完定义，我们就会犯难了，什么是企业活动中的事件？打开手机付款，选择支付宝和微信，这些操作算不算业务过程？ 59 | 60 | 这里，我们真得咬文嚼字，回归场景。交易的场景，有 2 个参与方：消费者和便利店。便利店作为企业，如果它关心的结果只是消费者买了什么，买了多少，那消费者选择支付方式的事件，它完全不管，也不用记录。 61 | 62 | 但如果用户只开通了微信支付，没开通支付宝，因为支付问题导致没法成交，那企业肯定也会关心选择支付方式这个事件以及其结果。业务过程，是不可拆分的事件，而且是基于分析目标进行选定的。理解一个词，不能脱离情景，多尝试将自己置于企业经营的情景下。 63 | 64 | 企业里每天都有各种事情，而作为管理者的我们，最核心的关注点是什么？是从收益、成本出发，价值链条上最具影响力的事情或者事件。 65 | 66 | ### 2）粒度 67 | 68 | 理解粒度，其实很简单：干什么样的事情，会新增一条记录。小乐支付了一笔，系统会新增一条支付记录，当我们要统计分析交易的订单数时，订单是最细的粒度。而这笔交易中，包含了两个商品，当我们要分析所有订单卖出的商品数，每个商品则变成了最细粒度。 69 | 70 | ### 3）维度 71 | 72 | 维度，就是我们要进行分析的角度。比如，在便利店场景中，一天的经营结束了，可以按品牌的维度分析，各个品牌的酸奶销售量；可以按日期维度分析，我们可以知道，周一到周日，每天的交易额如何。 73 | 74 | 某天，当我们发现交易数据发生异常的时候，我们可以按照品牌、日期等维度进行分析，逐个排查，直到找到根本的原因。 75 | 76 | ### 4）事实 77 | 78 | 广义地来说，所有被记录下来的事情，都是事实。而维度建模中，对事实进行了细分，事实包含 2 类属性：维度、度量。维度就是上文所说的各个角度的数据，而度量，则通常是数值型的。举个例子，我们描述一个长方形，但是没描述它具体多长、多宽，其他人是没法确定这个长方形具体多大的。 79 | 80 | 如果只有补充上它对应的维度和度量，人们才能理解。比如，长 4cm，宽 3cm。长、宽是维度，4 米、3 米则是对应维度上的度量。事实，就是描述客观事物的所有核心信息的所有数据的集合。 81 | 82 | # 理解业务过程 83 | 84 | 很多数据仓库书籍都给出了业务过程的通用定义：业务过程是企业活动中的事件，如下单、支付、退款都是业务过程，业务过程是一个不可拆分的行为事件。 85 | 86 | ## 如何理解企业活动 87 | 88 | 同一件事情，按照不同的对象，会有两种描述。这样说很抽象，举个例子：A 公司向 B 公司进了一批货。 89 | 90 | - A 公司的记录是：采购单。 91 | - B 公司的记录是：销售单。 92 | 93 | 业务过程，是有对象主体的，其主体就是：数据仓库索要服务的对象。这个时候，我们要确定一个分析的层次，或者叫做，抽象的粒度。我们只分析企业这个层级的事情，而不分析员工级别的事情。 94 | 95 | ## 如何理解不可拆分 96 | 97 | 这还是要基于层级去说。假如某天有很多消费者在商店里面买了东西，便利店作为企业，如果它关心的结果只是消费者买了什么，买了多少。那消费者选择支付方式的事件，它完全不管，也不用记录。在便利店这个层级，只关心交易结果，不用关心交易过程中的具体支付方式。 98 | 99 | 业务过程，是不可拆分的事件，基于分析目标进行选定的。但如果用户只开通了微信支付，没开通支付宝，因为支付问题导致没法成交，那企业肯定也会关心选择支付方式这个事件以及其结果。 100 | 101 | 理解一个词，不能脱离情景，多尝试将自己置于企业经营的情景下。企业里每天都有各种事情，而作为管理者的我们，最核心的关注点是什么？企业是从收益、成本出发，关注价值链条上最具影响力的事情或者事件。 102 | 103 | # 整明白粒度 104 | 105 | 选定了分析的过程，紧接着就要声明粒度。看到书里这么说，我当时的反应是：为什么？粒度是什么？普通场景里，粒度可以理解为一个东西的大小。比如，钻石要区分颗粒度，大小不同的钻石，价格不一。而在数据分析的语境里，粒度则意味着分析的范围，分析的细致程度。 106 | 107 | 举两个例子。 108 | 109 | - 系统的注册总人数，可以按照国家、省份来统计，这是地域层面上的不同统计粒度。 110 | - 系统的活跃用户数，可以按天、按周统计登录人数，这是时间层面上不同的统计粒度。 111 | 112 | 从数据表的角度来看，粒度则解释着什么情况下增加一条记录。 113 | 114 | - 按国家统计用户数，中国只会有一条记录，按省统计，中国则会有 34 条记录。 115 | - 按周统计活跃用户，一年只会有 52 行记录，按天统计，一年则有 365 或 366 条记录。 116 | 117 | ## 通过实战理解粒度 118 | 119 | 公司出了新 APP，老板很关心新 APP 的用户活跃程度，于是，用户端产品经理希望做个面板，看每天有多少人登录。同时，他提了另一个需求，他希望能支持统计两个日期区间内的登录人数（两个日期是变化的）。通过例子理解：某个活动发布后，要查看不同时间区间内的累积活跃用户数，比如 1-2 号，3-5 号，以便及时调整促活的策略。 120 | 121 | 首先，选定业务过程。这个一目了然，自然就是用户登录过程。其次，声明粒度。这里用户方希望按照不同的日期统计累积人数，那粒度是天。然后，是确定维度。这个例子里，因为要按照日期分析，最主要的维度是日期（为了简单，例子里就就先不考虑其他维度了），日期维度表设计如下： 122 | 123 | ![日期维度表](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325134802.png) 124 | 125 | 最后，设计事实表，用户登录事实表(fact_loign）设计如下： 126 | 127 | ![事实表](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325134829.png) 128 | 129 | ## 维度模型搞不定，是粒度理解不到位 130 | 131 | 构建模型，最终都是为了查出对应的指标和结果，所以维度模型通常都会跟标准的指标系统配套来使用。当我们按照标准套路，进入指标设计阶段，问题就会慢慢浮出水面了。基于事实表模型，我们很容易设计原子指标【登录人数】，其计算逻辑为： 132 | 133 | ```sql 134 | count(fact_login.user_id) 135 | ``` 136 | 137 | 进而，我们也能设计出衍生指标【日期\_登录人数】，其口径为： 138 | 139 | ```sql 140 | select distinct count(fact_login.user_id) 141 | from fact_login 142 | left join dim_date on date.date_key = fact_login.login_date 143 | group by dim_date.date_key 144 | ``` 145 | 146 | 从衍生指标这里，就能发现问题了。你会发现，group by 后的结果，是按照每天进行去重的。最终的结果，只能是统计每天范围内的累积登录人数。用户的期望是，统计某个时间区间内的累积登录人数，这个需求维度模型产生的指标没法满足。如果事实表的真实数据如下： 147 | 148 | ![事实表](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325135233.png) 149 | 150 | 基于维度模型，系统可以生成这样的汇总表： 151 | 152 | ![汇总表](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325135304.png) 153 | 154 | 但系统无法生成如下汇总表： 155 | 156 | ![汇总表](image.png) 157 | 158 | ## 粒度是搞清问题的关键 159 | 160 | 让我们回归到真实场景里：登录成功，这个事件发生在一瞬间。常见的时间计量单位有年、月、天、小时、分钟、秒、毫秒、微秒等等。而系统记录某个操作，常见的记录粒度是秒。比如，2021 年 6 月 27 号 14 : 00 : 00，小明登录了系统。如果按照秒去统计登录人数，则完全不用考虑去重，因为小明在这个粒度的计量单位里，只能登录一次。 161 | 162 | 但秒级别的统计粒度，太细了。业务方希望从更加宏观的角度去统计和分析，例子里面，是以天为单位去统计。那这个时候，统计就要升粒度了，并且，要去重。此时，系统也是可以按照天的粒度进行去重统计的。再看看实际需求时，统计的时间区间是不固定的。即，业务方可能今天想统计 1 号到 2 号的登录人数，明天想统计 3 号到 5 号的登录人数。 163 | 164 | 粒度不固定：1-2 号，间隔时间是 1 天，3-5 号，间隔时间则是 2 天。维度建模中，声明粒度就是要把粒度的大小定下来。不管是什么维度，都要提前把粒度定下来，这样才能实现累计去重。从技术实现的角度来看，如果查询的粒度，是一个变量，而不是一个固定值，没法提前计算，只能临时用明细表算，这就叫做即席查询。 165 | 166 | 所以，这个需求中，维度建模只能解决前面部分的需求：按照天去重统计每天登录人数。而变化区间的去重统计，只能即席查询了。 167 | 168 | # 搞懂维度 169 | 170 | ## 维度是什么 171 | 172 | 1）阿里 dataphin 产品简介-基本概念是这样介绍维度： 173 | 174 | > **人们观察事物的角度，是指一种视角**，是确定事物的多方位、多角度、多层次的条件和概念。 175 | 176 | 2）华为 DGC 产品介绍-基本概念如此介绍维度： 177 | 178 | > 维度是用于**观察和分析业务数据的视角**，支撑对数据汇聚、钻取、切片分析，用于 SQL 中的 Group by 条件。多数维度具有层级结构，如：地理维度、时间维度。 179 | 180 | 3）再看看《[数据仓库](https://so.csdn.net/so/search?q=数据仓库&spm=1001.2101.3001.7020)工具箱》怎么说的： 181 | 182 | > 维度能提供围绕**某一业务过程所涉及的 “谁、什么、何处、何时、为什么、如何”等背景**。维度表包含 BI 应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开。当与给定事实表进行关联时，任何情况下都应该使维度保持单一值。 183 | 184 | 4）再看《阿里巴巴大数据之路》怎么说的： 185 | 186 | > 维度是维度建模的基础和灵魂。在维度建模中，将度量称为 “事实” 将环境描述为 “维度” ，**维度是用于分析事实所需要的多样环境。** 187 | > 例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。 188 | > 维度所包含的表示维度的列，称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。 189 | > **维度的作用一般是查询约束、分类汇总以及排序。** 190 | 191 | ## 维度和粒度的关系 192 | 193 | 1）维度有层级结构，不同层级对应不同的粒度。 194 | 195 | 地理维度有不同的层级：国家、省/自治州/直辖市、市、县，时间维度也有不同的层级和粒度：年度、季度、月度、星期、天等。正如有了要描述的事情，确定了粒度，再去找对应的维度。比如，订单系统，会记录下单的时间信息，时间维度上，粒度会细到秒。学籍系统，学生户籍信息中，要填入地区维度的信息，粒度要细化到省市。 196 | 197 | 2）维度的组合越多，粒度越细细 198 | 199 | 客观的世界，是多维的。描述一个客观事物，维度（通常配合相应的度量）越多，粒度越细。比如一个箱子，我们可以描述其长宽高，还可以描述颜色。不同描述维度组合越多，粒度越细，描述也越细致。 200 | 201 | 3）随着事物的变化，描述的维度可以增加 202 | 203 | 一个箱子会经历生产、运输、送货上门等环节，从产地送达到顾客手中。箱子被生产出来后，没有品牌、产地属性，或者说属性值为空。未经历运输过程的箱子，没有快递公司、配送员属性。但是人们可以赋予它这些维度，并且填入维度值。维度是基于人类描述客观事物的需要，被创造来的。 204 | 205 | 4）有的维度，没有直接的数字度量 206 | 207 | 从客观唯物主义的角度来说，某个实体的存在，长、宽、高这种比较客观的维度属性，是有确定值的。但某些主观的东西，也是需要被描述的。比如，人的帅气程度。我们就简单分两类：很帅、一般。这种主观的维度，没有绝对精确的度量值，无法直接和数字划上等号。 208 | 209 | 但聪明的我们依然可以定性、定量地测算进而描述。比如搞投票，得分超过 90 为很帅，60-90 为一般。但这种方式，只能估算，没有四海皆准的定值，不同的人群，投票结果不同。 210 | 211 | ## 两个有意思的维度问题 212 | 213 | ### 维度的角色 214 | 215 | 维度模型里，很多人不理解什么是维度角色。包括最开始的我自己。 216 | 217 | ![维度角色](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325140618.png) 218 | 219 | 淘宝的业务过程大家应该很熟悉，涉及 4 个关键步骤：买家下单、买家付款、卖家发货、买家确认收货。每个过程，都会涉及一个对应的时间，即下单时间、支付时间、发货时间、确认收货时间。 220 | 221 | 如果只分析其中的一个业务过程，比如买家下单，那只需要一个时间字段即可。但是分析完整四个过程时，如果还只有一个时间字段，那如何区分其具体含义呢？到底是下单还是支付时间，搞不清楚。 222 | 223 | 只有一个字段，肯定不够。那必然要有 4 个时间字段。而且我们会给不同的命名，下单、支付、发货、确认收货作为时间的前缀。这样一来，咱们看的人是能理解各个数字的含义了。但不仅如此，还得让计算机系统也理解。所以，要弄一个 “维度角色”的字段来标识，以便计算机能理解。 224 | 225 | ![维度角色 SQL](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325140737.png) 226 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/Hive/表操作.md: -------------------------------------------------------------------------------- 1 | # Create:表创建 2 | 3 | Create Table 用于在 Hive 中创建表，其语法如下所示，注意，Hive 中的表名列名不区分大小写： 4 | 5 | ``` 6 | CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [db_name.] table_name 7 | 8 | [(col_name data_type [COMMENT col_comment], ...)] 9 | [COMMENT table_comment] 10 | [ROW FORMAT row_format] 11 | [STORED AS file_format] 12 | ``` 13 | 14 | 譬如当我们希望创建如下的包含 Employee 新的表时，数据格式和域如下: 15 | | Sr.No | Field Name | Data Type | 16 | | ----- | ----------- | --------- | 17 | | 1 | Eid | int | 18 | | 2 | Name | String | 19 | | 3 | Salary | Float | 20 | | 4 | Designation | string | 21 | 然后如下的语句会指定该表的注释、不同的域的分隔符、不同的行的分隔符，以及存储的文件类型: 22 | 23 | ``` 24 | COMMENT ‘Employee details’ 25 | FIELDS TERMINATED BY ‘\t’ 26 | LINES TERMINATED BY ‘\n’ 27 | STORED IN TEXT FILE 28 | ``` 29 | 30 | 然后完整的创建语句为: 31 | 32 | ``` 33 | hive> CREATE TABLE IF NOT EXISTS employee ( eid int, name String, 34 | salary String, destination String) 35 | COMMENT ‘Employee details’ 36 | ROW FORMAT DELIMITED 37 | FIELDS TERMINATED BY ‘\t’ 38 | LINES TERMINATED BY ‘\n’ 39 | STORED AS TEXTFILE; 40 | ``` 41 | 42 | 如果你添加了`IF NOT EXISTS`选项，Hive 会在表存在的情况下忽略掉创建，在成功执行该语句之后，你会得到如下的响应: 43 | 44 | ``` 45 | OK 46 | Time taken: 5.905 seconds 47 | hive> 48 | ``` 49 | 50 | ## Java Programming 51 | 52 | ``` 53 | import java.sql.SQLException; 54 | import java.sql.Connection; 55 | import java.sql.ResultSet; 56 | import java.sql.Statement; 57 | import java.sql.DriverManager; 58 | 59 | public class HiveCreateTable { 60 | private static String driverName = "org.apache.hadoop.hive.jdbc.HiveDriver"; 61 | 62 | public static void main(String[] args) throws SQLException { 63 | 64 | // Register driver and create driver instance 65 | Class.forName(driverName); 66 | 67 | // get connection 68 | Connection con = DriverManager.getConnection("jdbc:hive://localhost:10000/userdb", "", ""); 69 | 70 | // create statement 71 | Statement stmt = con.createStatement(); 72 | 73 | // execute statement 74 | stmt.executeQuery("CREATE TABLE IF NOT EXISTS " 75 | +" employee ( eid int, name String, " 76 | +" salary String, destignation String)" 77 | +" COMMENT ‘Employee details’" 78 | +" ROW FORMAT DELIMITED" 79 | +" FIELDS TERMINATED BY ‘\t’" 80 | +" LINES TERMINATED BY ‘\n’" 81 | +" STORED AS TEXTFILE;"); 82 | 83 | System.out.println(“ Table employee created.”); 84 | con.close(); 85 | } 86 | } 87 | ``` 88 | 89 | ## 内表 VS 外表 90 | 91 | Hive 默认创建的表为内部表，内部表与外部表的区别可以归纳为: 92 | 93 | - 在导入数据到外部表，数据并没有移动到自己的数据仓库目录下(如果指定了 location 的话)，也就是说外部表中的数据并不是由它自己来管理的！而内部表则不一样； 94 | - 在删除内部表的时候，Hive 将会把属于表的元数据和数据全部删掉；而删除外部表的时候，Hive 仅仅删除外部表的元数据，数据是不会删除的！ 95 | - 在创建内部表或外部表时加上 location 的效果是一样的，只不过表目录的位置不同而已，加上 partition 用法也一样，只不过表目录下会有分区目录而已，load data local inpath 直接把本地文件系统的数据上传到 hdfs 上，有 location 上传到 location 指定的位置上，没有的话上传到 hive 默认配置的数据仓库中。 96 | 97 | ### 内表 98 | 99 | (1)创建不带分区的内表 100 | 首先创建一个表，注意，Hive 创建成功的表即使你输入的是大写，也会被转化为小写： 101 | 102 | ``` 103 | create table innertable(id int,name string) row format delimited fields terminated by '|'; 104 | ``` 105 | 106 | 然后我们从 HDFS 上加载数据: 107 | 108 | ``` 109 | load data inpath 'hdfs://master:9000/user/root/test/innerTable' into table innertable; 110 | ``` 111 | 112 | 查看 HDFS 上/user/root/test/innerTable,发现文件价 innerTable 还在，但是里面的文件已经不在了。去哪了，去 innertable 表中了。然后删除刚刚创建的表: 113 | 114 | ``` 115 | drop table innertable; 116 | ``` 117 | 118 | 到 HDFS 上看一下 innertable 文件夹及其中的文件都没有了。去哪了，删除表的时候删除了。 119 | (2)带分区的内表 120 | 使用如下命令创建表: 121 | 122 | ``` 123 | create table inner_table_with_p(id int,name string) partitioned by (part_num int); 124 | ``` 125 | 126 | #从HDFS加载数据 127 | load data inpath 'hdfs://master:9000/user/root/test/innerTable/part1' into table inner_table_with_p partition(part_num=1)(文件夹inner_table_with_p出现子文件夹part_num=1，innerTable中 part1消失)； 128 | load data inpath 'hdfs://master:9000/user/root/test/innerTable/part2' into table inner_table_with_p partition(part_num=2)(文件夹inner_table_with_p出现子文件夹part_num=2，innerTable中 part2消失)； 129 | 130 | load data inpath 'hdfs://master:9000/user/root/test/innerTable/part3' into table inner_table_with_p partition(part_num=3)(文件夹 inner_table_with_p 出现子文件夹 part_num=3，innerTable 中 part3 消失)；#删除分区 131 | alter table inner_table_with_p drop partition(part_num=1);(part_num=1 对应分区文件夹本删除) 132 | #删除表 133 | drop table inner_table_with_p;(HDFS 上 inner_table_with_p 文件夹被删除) 134 | 135 | ### 外表 136 | 137 | (1)不带分区的外表 138 | 创建表 139 | create external table outer_table(id int,name string) row format delimited fields terminated by '|'; (hive 仓储目录中出现 outer_table) 140 | 加载数据 141 | load data inpath '/user/root/test/outerTable/outer' into table outer_table;(outer_table 中出现子文件 outer,outerTable 中 outer 消失) 142 | 删除表 143 | drop table outer_table; (outer_table 及子文件 outer 依然存在，因为这是外表) 144 | (2)带分区的外表 145 | 创建表 146 | create external table outer_table_with_p(id int,name string) partitioned by (part_num int) row format delimited fields terminated by '|'; (hive 仓储目录中出现 outer_table_with_p) 147 | 加载数据 148 | load data inpath '/user/root/test/outerTable/part1' into table outer_table_with_p partiton(part_num=1); (outer_table_with_p 中出现子文件夹 part_num=1) 149 | load data inpath '/user/root/test/outerTable/part2' into table outer_table_with_p partition(part_num=2);(outer_table_with_p 中出现子文件夹 part_num=2) 150 | load data inpath '/user/root/test/outerTable/part3' into table outer_table_with_p partition(part_num=3);(outer_table_with_p 中出现子文件夹 part_num=3) 151 | 删除分区 152 | alter table outer_table_with_p drop partition(part_num=1);(HDFS 上分区文件依旧存在) 153 | 删除表 154 | drop table outer_table_with_p;(HDFS 上对应数据依旧存在) 155 | 156 | # Partition:表分区 157 | 158 | 在 Hive Select 查询中一般会扫描整个表内容，会消耗很多时间做没必要的工作。有时候只需要扫描表中关心的一部分数据，因此建表时引入了 partition 概念。分区表指的是在创建表时指定的 partition 的分区空间。Hive 可以对数据按照某列或者某些列进行分区管理，所谓分区我们可以拿下面的例子进行解释。当前互联网应用每天都要存储大量的日志文件，几 G、几十 G 甚至更大都是有可能。存储日志，其中必然有个属性是日志产生的日期。在产生分区时，就可以按照日志产生的日期列进行划分。把每一天的日志当作一个分区。将数据组织成分区，主要可以提高数据的查询速度。至于用户存储的每一条记录到底放到哪个分区，由用户决定。即用户在加载数据的时候必须显示的指定该部分数据放到哪个分区。创建表分区的语法格式为: 159 | 160 | ``` 161 | CREATE [EXTERNAL] TABLE [IF NOT EXISTS] table_name 162 | [(col_name data_type [COMMENT col_comment], ...)] 163 | [COMMENT table_comment] 164 | [PARTITIONED BY (col_name data_type [COMMENT col_comment], ...)] 165 | [CLUSTERED BY (col_name, col_name, ...) [SORTED BY (col_name [ASC|DESC], ...)] INTO num_buckets BUCKETS] 166 | [ROW FORMAT row_format] 167 | [STORED AS file_format] 168 | [LOCATION hdfs_path] 169 | ``` 170 | 171 | ## 分区创建 172 | 173 | ### 单分区 174 | 175 | - 创建一个分区表，以 ds 为分区列： 176 | 177 | ``` 178 | create table invites (id int, name string) partitioned by (ds string) row format delimited fields terminated by 't' stored as textfile; 179 | ``` 180 | 181 | - 将数据添加到时间为 2013-08-16 这个分区中： 182 | 183 | ``` 184 | load data local inpath '/home/hadoop/Desktop/data.txt' overwrite into table invites partition (ds='2013-08-16'); 185 | ``` 186 | 187 | - 将数据添加到时间为 2013-08-20 这个分区中： 188 | 189 | ``` 190 | load data local inpath '/home/hadoop/Desktop/data.txt' overwrite into table invites partition (ds='2013-08-20'); 191 | ``` 192 | 193 | - 从一个分区中查询数据： 194 | 195 | ``` 196 | select * from invites where ds ='2013-08-12'; 197 | ``` 198 | 199 | - 往一个分区表的某一个分区中添加数据： 200 | 201 | ``` 202 | insert overwrite table invites partition (ds='2013-08-12') select id,max(name) from test group by id; 203 | ``` 204 | 205 | 可以查看分区的具体情况，使用命令： 206 | 207 | ``` 208 | hadoop fs -ls /home/hive/warehouse/invites 209 | ``` 210 | 211 | 或者： 212 | 213 | ``` 214 | show partitions tablename; 215 | ``` 216 | 217 | # Bucket:桶 218 | 219 | 对于每一个表(table)或者分区，Hive 可以进一步组织成桶，也就是说桶是更为细粒度的数据范围划分。Hive 也是针对某一列进行桶的组织。Hive 采用对列值哈希，然后除以桶的个数求余的方式决定该条记录存放在哪个桶当中。把表(或者分区)组织成桶(Bucket)有两个理由： 220 | 221 | - 获得更高的查询处理效率。桶为表加上了额外的结 构，Hive 在处理有些查询时能利用这个结构。具体而言，连接两个在(包含连接列的)相同列上划分了桶的表，可以使用 Map 端连接 (Map-side join)高效的实现。比如 JOIN 操作。对于 JOIN 操作两个表有一个相同的列，如果对这两个表都进行了桶操作。那么将保存相同列值的桶进行 JOIN 操 作就可以，可以大大较少 JOIN 的数据量。 222 | - 使取样(sampling)更高效。在处理大规模数据集时，在开发和修改查询的阶段，如果能在数据集的一小部分数据上试运行查询，会带来很多方便。 223 | 224 | ### 多分区 225 | 226 | 双分区建表语句：create table day_hour_table (id int, content string) partitioned by (dt string, hour string);双分区表，按天和小时分区，在表结构中新增加了 dt 和 hour 两列。 227 | ![](http://static.oschina.net/uploads/img/201308/26230013_wF3Y.gif) 228 | 229 | # Drop:表删除 230 | -------------------------------------------------------------------------------- /_sidebar.md: -------------------------------------------------------------------------------- 1 | - [1 01~大数据体系 [5]](/01~大数据体系/README.md) 2 | - [1.1 01~大数据生态 [6]](/01~大数据体系/01~大数据生态/README.md) 3 | - 1.1.1 99~参考资料 [1] 4 | - [1.1.1.1 数据库领域投资总结](/01~大数据体系/01~大数据生态/99~参考资料/2021-数据库领域投资总结.md) 5 | - [1.1.2 不作恶](/01~大数据体系/01~大数据生态/不作恶.md) 6 | - [1.1.3 大数据平台](/01~大数据体系/01~大数据生态/大数据平台.md) 7 | - [1.1.4 大数据生态圈](/01~大数据体系/01~大数据生态/大数据生态圈.md) 8 | - [1.1.5 大数据的未来](/01~大数据体系/01~大数据生态/大数据的未来.md) 9 | - [1.1.6 数据的特性](/01~大数据体系/01~大数据生态/数据的特性.md) 10 | - 1.2 02~数据治理原则 [2] 11 | - [1.2.1 原则与要素](/01~大数据体系/02~数据治理原则/原则与要素.md) 12 | - [1.2.2 数据零散化](/01~大数据体系/02~数据治理原则/数据零散化.md) 13 | - [1.3 03.数据组织方式 [4]](/01~大数据体系/03.数据组织方式/README.md) 14 | - [1.3.1 02.数据仓库](/01~大数据体系/03.数据组织方式/02.数据仓库/README.md) 15 | 16 | - [1.3.2 03.数据湖](/01~大数据体系/03.数据组织方式/03.数据湖/README.md) 17 | 18 | - [1.3.3 04.数据中台 [2]](/01~大数据体系/03.数据组织方式/04.数据中台/README.md) 19 | - [1.3.3.1 数据栈](/01~大数据体系/03.数据组织方式/04.数据中台/数据栈.md) 20 | - [1.3.3.2 评价维度](/01~大数据体系/03.数据组织方式/04.数据中台/评价维度.md) 21 | - [1.3.4 05~数据网格](/01~大数据体系/03.数据组织方式/05~数据网格/README.md) 22 | 23 | - [1.4 04.数据中心 [1]](/01~大数据体系/04.数据中心/README.md) 24 | - [1.4.1 云数据中心](/01~大数据体系/04.数据中心/云数据中心.md) 25 | - 1.5 99~参考资料 [2] 26 | - [1.5.1 松子 一文遍历大数据架构变迁史](/01~大数据体系/99~参考资料/2021-松子-一文遍历大数据架构变迁史.md) 27 | - [1.5.2 一文读懂数据仓库、数据平台、数据中台、数据湖的概念和区别](/01~大数据体系/99~参考资料/2022-一文读懂数据仓库、数据平台、数据中台、数据湖的概念和区别.md) 28 | - [2 02~数据集成 [4]](/02~数据集成/README.md) 29 | - [2.1 Canal [2]](/02~数据集成/Canal/README.md) 30 | - [2.1.1 架构机制](/02~数据集成/Canal/架构机制.md) 31 | - [2.1.2 部署与配置](/02~数据集成/Canal/部署与配置.md) 32 | - [2.2 DataPipeline [5]](/02~数据集成/DataPipeline/README.md) 33 | - [2.2.1 一致性语义](/02~数据集成/DataPipeline/一致性语义.md) 34 | - [2.2.2 数据汇集层](/02~数据集成/DataPipeline/数据汇集层.md) 35 | - [2.2.3 数据源监听](/02~数据集成/DataPipeline/数据源监听.md) 36 | - [2.2.4 数据转换与检索](/02~数据集成/DataPipeline/数据转换与检索.md) 37 | - [2.2.5 运行环境与引擎](/02~数据集成/DataPipeline/运行环境与引擎.md) 38 | - [2.3 Debezium](/02~数据集成/Debezium.md) 39 | - [2.4 ETL](/02~数据集成/ETL/README.md) 40 | 41 | - [3 03~数仓建模 [5]](/03~数仓建模/README.md) 42 | - [3.1 01.Kimball 与 Inmon [1]](/03~数仓建模/01.Kimball%20与%20Inmon/README.md) 43 | - [3.1.1 Kimball](/03~数仓建模/01.Kimball%20与%20Inmon/Kimball.md) 44 | - [3.2 02.多维数据模型 [3]](/03~数仓建模/02.多维数据模型/README.md) 45 | - [3.2.1 01.事实表、维度表、聚合表 [3]](/03~数仓建模/02.多维数据模型/01.事实表、维度表、聚合表/README.md) 46 | - [3.2.1.1 01.事实表](/03~数仓建模/02.多维数据模型/01.事实表、维度表、聚合表/01.事实表.md) 47 | - [3.2.1.2 02.维度表](/03~数仓建模/02.多维数据模型/01.事实表、维度表、聚合表/02.维度表.md) 48 | - [3.2.1.3 03.聚合表](/03~数仓建模/02.多维数据模型/01.事实表、维度表、聚合表/03.聚合表.md) 49 | - [3.2.2 02.星型与雪花模型 [1]](/03~数仓建模/02.多维数据模型/02.星型与雪花模型/README.md) 50 | - 3.2.2.1 99~参考资料 [1] 51 | - [3.2.2.1.1 数据仓库系列：星型模型和雪花型模型](/03~数仓建模/02.多维数据模型/02.星型与雪花模型/99~参考资料/2021-数据仓库系列：星型模型和雪花型模型.md) 52 | - [3.2.3 03.数据立方体](/03~数仓建模/02.多维数据模型/03.数据立方体/README.md) 53 | 54 | - [3.3 03.数仓搭建流程 [4]](/03~数仓建模/03.数仓搭建流程/README.md) 55 | - 3.3.1 01.数仓分层架构 [1] 56 | - [3.3.1.1 数仓分层](/03~数仓建模/03.数仓搭建流程/01.数仓分层架构/数仓分层.md) 57 | - [3.3.2 02.事实表设计](/03~数仓建模/03.数仓搭建流程/02.事实表设计/README.md) 58 | 59 | - [3.3.3 03.维度表设计 [1]](/03~数仓建模/03.数仓搭建流程/03.维度表设计/README.md) 60 | - [3.3.3.1 缓慢变化维](/03~数仓建模/03.数仓搭建流程/03.维度表设计/缓慢变化维.md) 61 | - 3.3.4 99~参考资料 [3] 62 | - [3.3.4.1 数据产品小 Lee 数据仓库基础](/03~数仓建模/03.数仓搭建流程/99~参考资料/2021-数据产品小%20Lee-数据仓库基础.md) 63 | - [3.3.4.2 四月天 03 万字详解数仓分层设计架构 ODS DWD DWS ADS](/03~数仓建模/03.数仓搭建流程/99~参考资料/2022-四月天%2003-万字详解数仓分层设计架构%20ODS-DWD-DWS-ADS.md) 64 | - [3.3.4.3 园陌 做数仓必须搞明白的各种名词及关系，吐血整理](/03~数仓建模/03.数仓搭建流程/99~参考资料/2022-园陌-做数仓必须搞明白的各种名词及关系，吐血整理.md) 65 | - [3.4 04.指标体系](/03~数仓建模/04.指标体系/README.md) 66 | 67 | - [3.5 05~元数据管理 [1]](/03~数仓建模/05~元数据管理/README.md) 68 | - [3.5.1 Amundsen](/03~数仓建模/05~元数据管理/Amundsen.md) 69 | - [4 04~数据可视化 [7]](/04~数据可视化/README.md) 70 | - 4.1 BI 工具 [1] 71 | - 4.1.1 99~参考资料 [1] 72 | - [4.1.1.1 吐血测评九款 BI 工具，BI 选型就看这篇](/04~数据可视化/BI%20工具/99~参考资料/2022-吐血测评九款%20BI%20工具，BI%20选型就看这篇.md) 73 | - [4.2 可视化基础](/04~数据可视化/可视化基础/README.md) 74 | 75 | - 4.3 可视化开发库 [1] 76 | - [4.3.1 D3 [3]](/04~数据可视化/可视化开发库/D3/README.md) 77 | - [4.3.1.1 交互反馈](/04~数据可视化/可视化开发库/D3/交互反馈/README.md) 78 | 79 | - [4.3.1.2 图表示例](/04~数据可视化/可视化开发库/D3/图表示例/README.md) 80 | 81 | - [4.3.1.3 数据操作](/04~数据可视化/可视化开发库/D3/数据操作/README.md) 82 | 83 | - [4.4 图形语法](/04~数据可视化/图形语法/README.md) 84 | 85 | - [4.5 多维数据可视化 [1]](/04~数据可视化/多维数据可视化/README.md) 86 | - [4.5.1 可视化过程](/04~数据可视化/多维数据可视化/可视化过程.md) 87 | - [4.6 探索分析 [1]](/04~数据可视化/探索分析/README.md) 88 | - [4.6.1 数据透视表](/04~数据可视化/探索分析/数据透视表.md) 89 | - [4.7 数据与图表类别 [5]](/04~数据可视化/数据与图表类别/README.md) 90 | - [4.7.1 关联类](/04~数据可视化/数据与图表类别/关联类.md) 91 | - [4.7.2 平面比较类](/04~数据可视化/数据与图表类别/平面比较类.md) 92 | - [4.7.3 数据类别](/04~数据可视化/数据与图表类别/数据类别.md) 93 | - [4.7.4 柱状比较类](/04~数据可视化/数据与图表类别/柱状比较类.md) 94 | - [4.7.5 韦恩图](/04~数据可视化/数据与图表类别/韦恩图.md) 95 | - [5 10~OLAP [4]](/10~OLAP/README.md) 96 | - 5.1 01.引擎架构 [4] 97 | - [5.1.1 01.MPP [1]](/10~OLAP/01.引擎架构/01.MPP/README.md) 98 | - 5.1.1.1 99~参考资料 [1] 99 | - [5.1.1.1.1 MPP 架构、常见 OLAP 引擎分析](/10~OLAP/01.引擎架构/01.MPP/99~参考资料/2022-MPP%20架构、常见%20OLAP%20引擎分析.md) 100 | - [5.1.2 02.建模类型划分 [2]](/10~OLAP/01.引擎架构/02.建模类型划分/README.md) 101 | - [5.1.2.1 01.MOLAP](/10~OLAP/01.引擎架构/02.建模类型划分/01.MOLAP.md) 102 | - [5.1.2.2 02.ROLAP](/10~OLAP/01.引擎架构/02.建模类型划分/02.ROLAP.md) 103 | - [5.1.3 03.引擎操作](/10~OLAP/01.引擎架构/03.引擎操作/README.md) 104 | 105 | - 5.1.4 99~参考资料 [2] 106 | - [5.1.4.1 Kylin、Druid、ClickHouse核心技术对比](/10~OLAP/01.引擎架构/99~参考资料/2020-Kylin、Druid、ClickHouse核心技术对比.md) 107 | - [5.1.4.2 常用引擎对比与概述](/10~OLAP/01.引擎架构/99~参考资料/2021-常用引擎对比与概述.md) 108 | - 5.2 02.MOLAP [3] 109 | - [5.2.1 Druid](/10~OLAP/02.MOLAP/Druid/README.md) 110 | 111 | - 5.2.2 HBase [3] 112 | - [5.2.2.1 CRUD](/10~OLAP/02.MOLAP/HBase/CRUD.md) 113 | - [5.2.2.2 架构分析](/10~OLAP/02.MOLAP/HBase/架构分析.md) 114 | - [5.2.2.3 部署与使用](/10~OLAP/02.MOLAP/HBase/部署与使用.md) 115 | - [5.2.3 Kylin](/10~OLAP/02.MOLAP/Kylin/README.md) 116 | 117 | - 5.3 03.ROLAP [6] 118 | - [5.3.1 ClickHouse [1]](/10~OLAP/03.ROLAP/ClickHouse/README.md) 119 | - 5.3.1.1 99~参考资料 [2] 120 | - [5.3.1.1.1 陈峰 ClickHouse 架构及源码解析](/10~OLAP/03.ROLAP/ClickHouse/99~参考资料/2022-陈峰-ClickHouse%20架构及源码解析/README.md) 121 | 122 | - [5.3.1.1.2 ClickHouse 从入门到放弃](/10~OLAP/03.ROLAP/ClickHouse/99~参考资料/2023-ClickHouse%20从入门到放弃/README.md) 123 | 124 | - [5.3.2 Hive [5]](/10~OLAP/03.ROLAP/Hive/README.md) 125 | - [5.3.2.1 介绍与部署](/10~OLAP/03.ROLAP/Hive/介绍与部署.md) 126 | - [5.3.2.2 数据类型](/10~OLAP/03.ROLAP/Hive/数据类型.md) 127 | - [5.3.2.3 文件类型与存储格式](/10~OLAP/03.ROLAP/Hive/文件类型与存储格式.md) 128 | - [5.3.2.4 自定义函数](/10~OLAP/03.ROLAP/Hive/自定义函数.md) 129 | - [5.3.2.5 表操作](/10~OLAP/03.ROLAP/Hive/表操作.md) 130 | - [5.3.3 Presto [1]](/10~OLAP/03.ROLAP/Presto/README.md) 131 | - [5.3.3.1 部署与控制](/10~OLAP/03.ROLAP/Presto/部署与控制.md) 132 | - [5.3.4 QuickSQL](/10~OLAP/03.ROLAP/QuickSQL/README.md) 133 | 134 | - 5.3.5 Sqoop [1] 135 | - [5.3.5.1 介绍与部署](/10~OLAP/03.ROLAP/Sqoop/介绍与部署.md) 136 | - [5.3.6 StarRocks [1]](/10~OLAP/03.ROLAP/StarRocks/README.md) 137 | - 5.3.6.1 99~参考资料 [1] 138 | - [5.3.6.1.1 10 分钟带你全面了解 StarRocks！](/10~OLAP/03.ROLAP/StarRocks/99~参考资料/2022-10%20分钟带你全面了解%20StarRocks！.md) 139 | - 5.4 10.实践案例 [1] 140 | - [5.4.1 贝壳 OLAP 平台架构演进](/10~OLAP/10.实践案例/2021-贝壳%20OLAP%20平台架构演进.md) 141 | - 6 99~参考资料 [1] 142 | - 6.1 《Designing Data Intensive Application》 [2] 143 | - [6.1.1 原书翻译 [1]](/99~参考资料/《Designing%20Data-Intensive%20Application》/原书翻译/README.md) 144 | - [6.1.1.1 1.数据系统基础 [2]](/99~参考资料/《Designing%20Data-Intensive%20Application》/原书翻译/1.数据系统基础/README.md) 145 | - [6.1.1.1.1 第一章：可靠性、可伸缩性和可维护性](/99~参考资料/《Designing%20Data-Intensive%20Application》/原书翻译/1.数据系统基础/第一章：可靠性、可伸缩性和可维护性.md) 146 | - [6.1.1.1.2 第二章：数据模型与查询语言](/99~参考资料/《Designing%20Data-Intensive%20Application》/原书翻译/1.数据系统基础/第二章：数据模型与查询语言.md) 147 | - [6.1.2 精度](/99~参考资料/《Designing%20Data-Intensive%20Application》/精度/README.md) 148 | -------------------------------------------------------------------------------- /01~大数据体系/99~参考资料/2022-一文读懂数据仓库、数据平台、数据中台、数据湖的概念和区别.md: -------------------------------------------------------------------------------- 1 | # 一文读懂数据仓库、数据平台、数据中台、数据湖的概念和区别 2 | 3 | # 一、数据仓库 4 | 5 | ## 1. 数据仓库概念 6 | 7 | 数据仓库由比尔·恩门（Bill Inmon，数据仓库之父）于 1990 年提出，主要功能是将企业系统联机事务处理（OLTP）长期壁垒的大量数据，通过数据仓库理论支持所持有的数据存储结构，做有系统的分析整理。 8 | 9 | ![数据存储的演变](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325160922.png) 10 | 11 | 随着企业的发展，业务系统的数据不断激增，这些存储在企业业务数据库中（也就是关系型数据库 Oracle，Microsoft SQL Sever，MySQL 等）数据会随着时间的积累越来越多，会使业务数据库会有一定的负载，导致业务系统的运行效率低，且这些数据中有很大一部分是冷数据，而我们业务系统一般对我们近期的数据，也就是热数据调用的比较频繁，对冷数据使用频率较低。 12 | 13 | 同时随着企业数据驱动业务概念的兴起，企业需要将各业务部门的业务数据提取出来进行数据分析与挖掘，辅助高层进行分析与决策，但各部门需求的数据种类千差万别，接口错综复杂，过多的数据查询脚本以及接口的接入导致业务数据库的稳定性降低。 14 | 15 | 为了避免冷数据与历史数据的积压对我们业务数据库效能产生影响，企业需要定期将冷数据从业务数据库中转移出来存储到一个专门存放历史数据的仓库里面，各部门可以根据自身业务特性对外提供统一的数据服务，这个仓库就是数据仓库。 16 | 17 | ## 2. 数据仓库特点 18 | 19 | 数据仓库（Data Warehoese）的特点：面向主题的、集成的、稳定的、反映历史数据变化的。 20 | 21 | - 面向主题的：数据仓库是用来分析特点主题域的，所以说数据仓库是面向主题的。例如，电商行业的主题域通常分为交易域、会员域、商品域等。 22 | - 集成的：数据仓库集成了多个数据源，同一主题或产品相关数据可能来自不同的系统不同类型的数据库，日志文件等。 23 | - 稳定的：数据一旦进入数据仓库，则不可改变。数据仓库的历史数据是不应该被更新的，同时存储稳定性较强 24 | - 反映历史数据变化的：数据仓库保存了长期的历史数据，这点相对 OLTP 的数据库而言。因为性能考虑后者统筹保存近期的热数据。 25 | 26 | ## 3. OLTP 与 OLAP 27 | 28 | 数据处理大致可以分成两大类：联机事务处理 OLTP（on-line transaction processing）、联机分析处理 OLAP（On-Line Analytical Processing）。OLTP 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP 是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 29 | 30 | ![OLTP 与 OLAP](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325161338.png) 31 | 32 | ![OLTP 与 OLAP 区别](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325161429.png) 33 | 34 | OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，绑定变量，并发操作等。OLAP 系统则强调数据分析，强调 SQL 执行市场，磁盘 I/O，分区等。OLAP 和数仓的关系是依赖互补的，一般以数据仓库作为基础，既从数据仓库中抽取出详细数据的一个子集并经过必要的聚集存储到 OLAP 存储中供数据分析工具读取。 35 | 36 | ## 4. 数据仓库的作用 37 | 38 | 数据仓库将来自不同来源的结构化数据聚合起来，用于业务智能领域的比较和分析，数据仓库是包含多种数据的存储库，并且是高度建模的。如下图所示：各个系统的元数据通过 ETL 同步到操作性数据仓库 ODS 中，对 ODS 数据进行面向主题域建模形成 DW（数据仓库），DM 是针对某一个业务领域建立模型，具体用户（决策层）查看 DM 生成的报表。 39 | 40 | ![ETL 数据切换](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325161545.png) 41 | 42 | 传统的数据仓库集成处理架构是 ETL，利用 ETL 平台的能力，E=从源数据库抽取数据，L=将数据清洗（不符合规则的数据）、转化（对表按照业务需求进行不同维度、不同颗粒度、不同业务规则计算进行统计），T=将加工好的表以增量、全量、不同时间加载到数据仓库。 43 | 44 | ![什么是 ETL](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325161701.png) 45 | 46 | 大数据背景下的架构体系是 ELT 结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。ELT 是利用数据库的处理能力，E=从源数据库抽取数据，L=把数据加载到目标库的临时表中，T=对临时表中的数据进行转换，然后加载到目标库目标表中。 47 | 48 | ![什么是 ELT](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325161737.png) 49 | 50 | ELT 对比 ETL 的优势： 51 | 52 | - 资源利用率的提升：ELT 主要通过数据库引擎来实现系统的可扩展性（尤其是当数据加工过程在晚上时，可以充分利用数据库引擎的资源）。 53 | - 任务运行效率的提升：ELT 可以保持所有的数据始终在数据库当中，避免数据的加载和导出，从而保证效率，提高系统的可监控性。 54 | - 并行处理优化：ELT 可以根据数据的分布情况进行并行处理优化，并可以利用数据库的固有功能优化磁盘 I/O。 55 | - 可扩展性增强：ELT 的可扩展性取决于数据库引擎和其硬件服务器的可扩展性。 56 | - 性能优化：通过对相关数据库进行性能调优，ETL 过程获得 3 到 4 倍的效率提升一般不是特别困难。 57 | 58 | 数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。以下图为例： 59 | 60 | ![客户案例](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325161829.png) 61 | 62 | 数据仓库的作用主要体现在企业决策、分析、计划和响应以下几个方面： 63 | 64 | ![数据仓库的主要作用](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325161911.png) 65 | 66 | 数据仓库针对实时数据处理和非结构化数据处理能力较弱，以及在业务在预警预测等方面应用有一定的限制。 67 | 68 | ![数据仓库上下架构](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325161933.png) 69 | 70 | # 二、数据平台 71 | 72 | ## 1. 数据平台概念 73 | 74 | 大数据时代，数据平台一般被称之为大数据平台。 75 | 76 | - 狭义上的数据平台：是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题，所以先撇开业务需求、把企业所有的数据都抽取出来放到一起，成为一个大的数据集，其中有结构化数据、非结构化数据等。当业务方有需求的时候，再把他们需要的若干个小数据集单独提取出来，以数据集的形式提供给数据应用。 77 | - 广义的大数据平台：广义的大数据平台通常被赋予更多的使命，以处理海量数据存储、计算及不间断流数据实时计算、离线计算、智能推荐、交互式查询、数据湖构建等场景为主的一套基础设施。典型的包括基于 Hadoop 生态构建的大数据平台。提供易于部署及管理的 Hive、Spark、HBase、Flink、StarRocks、Iceberg、Alluxio 等开源大数据计算和存储引擎。 78 | 79 | 狭义的数据平台和传统的数据平台（数据仓库）功能一致，区别只是技术架构和数据容量方面的不同。广义上的大数据平台是数据湖的基座，提供易于部署和管理的泛 Hadoop 生态及其他存储计算引擎的 PaaS 平台，助力企业构建企业级数据湖技术架构。 80 | 81 | # 三、数据中台 82 | 83 | ## 1. 数据中台概念 84 | 85 | 数据中台的起源：2015 年年中，马云带领阿里巴巴集团高管拜访了一家芬兰的小型游戏公司 Supercell。这家仅有不到 200 名员工的小型游戏公司竟创造了高达 15 亿美元的年税前利润！而 Supercell 之所以能够支持多个团队快速、敏捷地推出高质量的游戏作品，其强大的中台能力功不可没。 86 | 87 | 因此，在拜访 Supercell 的旅程结束之后，马云决定对阿里巴巴的组织和系统架构进行整体调整，建立阿里产品技术和数据能力的强大中台，构建“大中台，小前台”的组织和业务体制。 88 | 89 | 数据中台的主要目的：解决企业在发展过程中，由于数据激增与业务的扩大而出现的统计口径不一致、重复开发、指标开发需求响应慢、数据质量低、数据成本高等问题。通过一系列数据工具（元数据中心、数据指标中心、数仓模型中心、数据资产中心-资产质量/治理/安全、数据服务中心等），规范数据供应链的各个环节。 90 | 91 | ## 2. 数据中台特点 92 | 93 | 数据中台特点：以一种标准的、安全的、可靠的、统一的、共享的、解耦的、服务化的方式支持前端数据的应用。 94 | 95 | ## 3. 数据中台作用 96 | 97 | ![阿里数据中台逻辑架构](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325162347.png) 98 | 99 | ![数据中台产品能力图](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325162404.png) 100 | 101 | 数据中台通过对企业内外部多源异构的数据采集、建设、管理、分析和应用，使数据对内优化管理提高业务价值，对外进行数据合作让业务价值得到释放，使之成为企业数据资产管理中枢。数据中台建立后，会形成数据 API 服务，为企业和客户提供高效各种数据服务。数据中台对一个企业的数字化转型和可持续发展起着至关重要的作用。数据中台为解耦而生，企业建设数据中台的最大意义就是应用与数据之间的解耦，这样企业就可以不受限制地按需构建满足业务需求的数据应用。 102 | 103 | 构建了开放、灵活、可扩展的企业级统一数据管理和分析平台，将企业内、外部数据随需关联，打破了数据的系统界限。利用大数据智能分析、数据可视化等技术，实现了数据共享、日常报表自动生成、快速和智能分析，满足企业各级部门之间的数据分析应用需求。 104 | 105 | 深度挖掘数据价值，助力企业数字化转型落地。实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理，实现数据集中存储、处理、分类与管理，建立大数据分析工具库、算法服务库，实现报表生成自动化、数据分析敏捷化、数据挖掘可视化，实现数据质量评估、落地管理流程。 106 | 107 | # 四、数据湖 108 | 109 | ## 1. 数据湖概念 110 | 111 | 数据湖起源：数据湖的起源，应该追溯到 2010 年 10 月，由 Pentaho 的创始人兼 CTO，James Dixon 所提出，他提出的目的就当时历史背景来看，其实是为了推广自家产品 Pentaho。当时核心要解决的问题是传统数据仓库报表分析面临的两个问题： 112 | 113 | - 只使用部分属性，这些数据只能回答预先定义好(pre-determined)的问题。 114 | - 数据被聚合了，最低层级的细节丢失了，能回答的问题被限制了。 115 | 116 | 而我们当前所讨论的数据湖，已经远远超过了当初 James Dixon 所定义的数据湖，各厂商之间也对数据湖有了更多的不同定义。 117 | 118 | ### 1）AWS 119 | 120 | A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions. 121 | 122 | “数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析– 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。” 123 | 124 | ### 2）微软 125 | 126 | Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics. 127 | 128 | “Azure 的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。” 129 | 130 | ### 3）阿里云 131 | 132 | “数据湖是统一存储池，可对接多种数据输入方式，您可以存储任意规模的结构化、半结构化、非结构化数据。数据湖可无缝对接多种计算分析平台，根据业务场景不同，可以选择相应的计算引擎对数据湖中存储的数据进行数据处理与分析，从而打破孤岛，挖掘业务价值。” 133 | 134 | ## 2. 数据湖内容 135 | 136 | 数据湖中包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如 CSV、日志、XML、JSON）、非结构化数据（如 email、文档、PDF 等）和 二进制数据（如图像、音频、视频）。 137 | 138 | ## 3. 数据湖的特点 139 | 140 | - 统一的数据存储，存放原始的数据。 141 | - 支持任意结构的数据存储，包括结构化、半结构化、非结构化。 142 | - 支持多种计算分析，适用多种应用场景。 143 | - 支持任意规模的数据存储与计算能力。 144 | - 目标都是为了更好，更快的发现数据价值。 145 | 146 | ## 4. 数据湖能够解决的问题 147 | 148 | ![数据湖整体架构](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325162849.png) 149 | 150 | - 最底下是分布式文件系统； 151 | - 第二层是数据加速层。数据湖架构是一个存储计算彻底分离的架构，如果所有的数据访问都远程读取文件系统上的数据，那么性能和成本开销都很大。如果能把经常访问到的一些热点数据缓存在计算节点本地，这就非常自然的实现了冷热分离，一方面能收获到不错的本地读取性能，另一方面还节省了远程访问的带宽。 152 | - 第三层就是 Table format 层，主要是把一批数据文件封装成一个有业务意义的 table，提供 ACID、snapshot、schema、partition 等表级别的语义。 153 | - 最上层就是不同计算场景的计算引擎了。开源的一般有 Spark、Flink、Hive、Presto、Hive MR 等，这一批计算引擎是可以同时访问同一张数据湖的表的。 154 | 155 | 数据分散，存储散乱，形成数据孤岛，无法联合数据发现更多价值。这方面来讲，其实数据湖要解决的与数据仓库是类似的问题，但又有所不同，因为它的定义里支持对半结构化、非结构化数据的管理。而传统数据仓库仅能解决结构化数据的统一管理。在这个万物互联的时代，数据的来源多种多样，随着不同应用场景，产出的数据格式也是越来越丰富，不能再仅仅局限于结构化数据。如何统一存储这些数据，就是迫切需要解决的问题。 156 | 157 | 数据库或数据仓库的存储受限于实现原理及硬件条件，导致存储海量数据时成本过高，而为了解决这类问题就有了 HDFS/对象存储这类技术方案。数据湖场景下如果使用这类存储成本较低的技术架构，将会为企业大大节省成本。结合生命周期管理的能力，可以更好的为湖内数据分层（冷温热存放在不同的存储介质：HDD、SSD、MEM），不用纠结在是保留数据还是删除数据节省成本的问题。 158 | 159 | 越来越多种类的数据，意味着越来越多的分析方式，传统的 SQL 方式已经无法满足分析的需求，如何通过各种语言自定义贴近自己业务的代码，如何通过机器学习挖掘更多的数据价值。 160 | 161 | 传统数据库等在海量数据下，如规模到 PB 级别，因为技术架构的原因，已经无法满足扩展的要求或者扩展成本极高，而这种情况下通过数据湖架构下的扩展技术能力，实现成本为 0，硬件成本也可控。业务模型不定，无法预先建模。传统数据库和数据仓库，都是 Schema-on-Write 的模式，需要提前定义 Schema 信息。而在数据湖场景下，可以先保存数据，后续待分析时，再发现 Schema，也就是 Schema-on-Read。 162 | 163 | # 对比 164 | 165 | ![1. 数据仓库 VS 数据中台 VS 数据湖](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230325163042.png) 166 | 167 | - 数据中台、数据仓库和数据湖没有直接的关系； 168 | - 数据中台、数据平台、数据仓库和数据湖在某个维度上为业务产生价值的形式有不同的侧重； 169 | - 数据仓库是数据驱动业务的逻辑概念，用于支持管理决策分析，为业务提供服务的主要方式是报表； 170 | - 数据中台是企业级的逻辑概念，体现企业数据向业务价值转化的能力，为业务提供服务的主要方式是数据 API； 171 | - 数据湖是企业级的技术逻辑概念，体现企业级数据湖架构加速数据向业务价值转化的能力，为业务提供服务的主要方式是原始数据； 172 | - 数据中台、数据湖距离业务更近，能够更快速的响应业务和应用开发需求，从而为业务提供速度更快的服务； 173 | - 数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层； 174 | -------------------------------------------------------------------------------- /01~大数据体系/01~大数据生态/不作恶.md: -------------------------------------------------------------------------------- 1 | # 不作恶 2 | 3 | 每个系统都服务于一个目的；我们采取的每个举措都会同时产生期望的后果与意外的后果。这个目的可能只是简单地赚钱，但其对世界的影响，可能会远远超出最初的目的。我们，建立这些系统的工程师，有责任去仔细考虑这些后果，并有意识地决定，我们希望生活在怎样的世界中。 4 | 5 | 我们将数据当成一种抽象的东西来讨论，但请记住，许多数据集都是关于人的：他们的行为，他们的兴趣，他们的身份。对待这些数据，我们必须怀着人性与尊重。用户也是人类，人类的尊严是至关重要的。软件开发越来越多地涉及重要的道德抉择。有一些指导原则可以帮助软件工程师解决这些问题，例如 ACM 的软件工程道德规范与专业实践，但实践中很少会讨论这些，更不用说应用与强制执行了。因此，工程师和产品经理有时会对隐私与产品潜在的负面后果抱有非常傲慢的态度。 6 | 7 | 技术本身并无好坏之分，关键在于它被如何使用，以及它如何影响人们。这对枪械这样的武器，这是成立的，而搜索引擎这样的软件系统与之类似。我认为，软件工程师仅仅专注于技术而忽视其后果是不够的：道德责任也是我们的责任。对道德推理很困难，但它太重要了，我们无法忽视。 8 | 9 | # 预测性分析 10 | 11 | 譬如预测性分析是“大数据”炒作的主要内容之一。使用数据分析预测天气或疾病传播是一码事；而预测一个罪犯是否可能再犯，一个贷款申请人是否有可能违约，或者一个保险客户是否可能进行昂贵的索赔，则是另外一码事。后者会直接影响到个人的生活。当然，支付网络希望防止欺诈交易，银行希望避免不良贷款，航空公司希望避免劫机，公司希望避免雇佣效率低下或不值得信任的人。从它们的角度来看，失去商机的成本很低，而不良贷款或问题员工的成本则要高得多，因而组织希望保持谨慎也是自然而然的事情。所以如果存疑，它们通常会 Say No。 12 | 13 | 然而，随着算法决策变得越来越普遍，被某种算法（准确地或错误地）标记为有风险的某人可能会遭受大量这种“No”的决定。系统性地被排除在工作，航旅，保险，租赁，金融服务，以及其他社会关键领域之外。这是一种对个体自由的极大约束，因此被称为“算法监狱”。在尊重人权的国家，刑事司法系统会做无罪推定（默认清白，直到被证明有罪）。另一方面，自动化系统可以系统地，任意地将一个人排除在社会参与之外，不需要任何有罪的证明，而且几乎没有申诉的机会。 14 | 15 | ## 偏见与歧视 16 | 17 | 算法做出的决定不一定比人类更好或更差。每个人都可能有偏见，即使他们主动抗拒这一点；而歧视性做法也可能已经在文化上被制度化了。人们希望根据数据做出决定，而不是通过人的主观评价与直觉，希望这样能更加公平，并给予传统体制中经常被忽视的人更好的机会。当我们开发预测性分析系统时，不是仅仅用软件通过一系列 IF ELSE 规则将人类的决策过程自动化，那些规则本身甚至都是从数据中推断出来的。但这些系统学到的模式是个黑盒：即使数据中存在一些相关性，我们可能也压根不知道为什么。如果算法的输入中存在系统性的偏见，则系统很有可能会在输出中学习并放大这种偏见。 18 | 19 | 在许多国家，反歧视法律禁止按种族，年龄，性别，性取向，残疾，或信仰等受保护的特征区分对待不同的人。其他的个人特征可能是允许用于分析的，但是如果这些特征与受保护的特征存在关联，又会发生什么？例如在种族隔离地区中，一个人的邮政编码，甚至是他们的 IP 地址，都是很强的种族指示物。这样的话，相信一种算法可以以某种方式将有偏数据作为输入，并产生公平和公正的输出似乎是很荒谬的。然而这种观点似乎常常潜伏在数据驱动型决策的支持者中，这种态度被讽刺为“在处理偏差上，机器学习与洗钱类似”（machine learning is like money laundering for bias）。 20 | 21 | 预测性分析系统只是基于过去进行推断；如果过去是歧视性的，它们就会将这种歧视归纳为规律。如果我们希望未来比过去更好，那么就需要道德想象力，而这是只有人类才能提供的东西。数据与模型应该是我们的工具，而不是我们的主人。 22 | 23 | ## 责任与问责 24 | 25 | 自动决策引发了关于责任与问责的问题。如果一个人犯了错误，他可以被追责，受决定影响的人可以申诉。算法也会犯错误，但是如果它们出错，谁来负责？当一辆自动驾驶汽车引发事故时，谁来负责？如果自动信用评分算法系统性地歧视特定种族或宗教的人，这些人是否有任何追索权？如果机器学习系统的决定要受到司法审查，你能向法官解释算法是如何做出决定的吗？ 26 | 27 | 收集关于人的数据并进行决策，信用评级机构是一个很经典的例子。不良的信用评分会使生活变得更艰难，但至少信用分通常是基于个人实际的借款历史记录，而记录中的任何错误都能被纠正（尽管机构通常会设置门槛）。然而，基于机器学习的评分算法通常会使用更宽泛的输入，并且更不透明；因而很难理解特定决策是怎样作出的，以及是否有人被不公正地，歧视性地对待。 28 | 29 | 信用分总结了“你过去的表现如何？”，而预测性分析通常是基于“谁与你类似，以及与你类似的人过去表现的如何？”。与他人的行为画上等号意味着刻板印象，例如，根据他们居住的地方（与种族和阶级关系密切的特征）。那么那些放错位置的人怎么办？而且，如果是因为错误数据导致的错误决定，追索几乎是不可能的。 30 | 31 | 很多数据本质上是统计性的，这意味着即使概率分布在总体上是正确的，对于个例也可能是错误的。例如，如果贵国的平均寿命是 80 岁，这并不意味着你在 80 岁生日时就会死掉。很难从平均值与概率分布中对某个特定个体的寿命作出什么判断，同样，预测系统的输出是概率性的，对于个例可能是错误的。盲目相信数据决策至高无上，这不仅仅是一种妄想，而是有切实危险的。随着数据驱动的决策变得越来越普遍，我们需要弄清楚，如何使算法更负责任且更加透明，如何避免加强现有的偏见，以及如何在它们不可避免地出错时加以修复。 32 | 33 | 我们还需要想清楚，如何避免数据被用于害人，如何认识数据的积极潜力。例如，分析可以揭示人们生活的财务特点与社会特点。一方面，这种权力可以用来将援助与支持集中在帮助那些最需要援助的人身上。另一方面，它有时会被掠夺性企业用于识别弱势群体，并向其兜售高风险产品，比如高利贷。 34 | 35 | ## 反馈循环 36 | 37 | 即使是那些对人直接影响比较小的预测性应用，比如推荐系统，也有一些必须正视的难题。当服务变得善于预测用户想要看到什么内容时，它最终可能只会向人们展示他们已经同意的观点，将人们带入滋生刻板印象，误导信息，与极端思想的回音室。我们已经看到过社交媒体回音室对竞选的影响了。 38 | 39 | 当预测性分析影响人们的生活时，自我强化的反馈循环会导致非常有害的问题。例如，考虑雇主使用信用分来评估候选人的例子。你可能是一个信用分不错的好员工，但因不可抗力的意外而陷入财务困境。由于不能按期付账单，你的信用分会受到影响，进而导致找到工作更为困难。失业使你陷入贫困，这进一步恶化了你的分数，使你更难找到工作。在数据与数学严谨性的伪装背后，隐藏的是由恶毒假设导致的恶性循环。 40 | 41 | 我们无法预测这种反馈循环何时发生。然而通过对整个系统（不仅仅是计算机化的部分，而且还有与之互动的人）进行整体思考，许多后果是可以够预测的，一种称为系统思维（systems thinkin）的方法。我们可以尝试理解数据分析系统如何响应不同的行为，结构或特性。该系统是否加强和增大了人们之间现有的差异（例如，损不足以奉有余，富者愈富，贫者愈贫），还是试图与不公作斗争？而且即使有着最好的动机，我们也必须当心意想不到的后果。 42 | 43 | # 隐私和追踪 44 | 45 | 除了预测性分析，即使用数据来做出关于人的自动决策，数据收集本身也存在道德问题。收集数据的组织，与被收集数据的人之间，到底属于什么关系？当系统只存储用户明确输入的数据时，是因为用户希望系统以特定方式存储和处理这些数据，系统是在为用户提供服务：用户就是客户。但是，当用户的活动被跟踪并记录，作为他们正在做的其他事情的副作用时，这种关系就没有那么清晰了。该服务不再仅仅完成用户想要它要做的事情，而是服务于它自己的利益，而这可能与用户的利益相冲突。 46 | 47 | 追踪用户行为数据对于许多面向用户的在线服务而言，变得越来越重要：追踪用户点击了哪些搜索结果有助于提高搜索结果的排名；推荐“喜欢 X 的人也喜欢 Y”，可以帮助用户发现实用有趣的东西；A/B 测试和用户流量分析有助于改善用户界面。这些功能需要一定量的用户行为跟踪，而用户也可以从中受益。 48 | 49 | 但不同公司有着不同的商业模式，追踪并未止步于此。如果服务是通过广告盈利的，那么广告主才是真正的客户，而用户的利益则屈居其次。跟踪的数据会变得更详细，分析变得更深入，数据会保留很长时间，以便为每个人建立详细画像，用于营销。现在，公司与被收集数据的用户之间的关系，看上去就不太一样了。公司会免费服务用户，并引诱用户尽可能多地使用服务。对用户的追踪，主要不是服务于该用户个体，而是服务于掏钱资助该服务的广告商。我认为这种关系可以用一个更具罪犯内涵的词来恰当地描述：监视（surveilance）。 50 | 51 | ## 监视 52 | 53 | 让我们做一个思想实验，尝试用监视（surveillance）一词替换数据（data），再看看常见的短语是不是听起来还那么漂亮。比如：“在我们的监视驱动的组织中，我们收集实时监视流并将它们存储在我们的监视仓库中。我们的监视科学家使用高级分析和监视处理来获得新的见解。“ 54 | 55 | 这个思想实验是罕见的争议性内容，但我认为需要激烈的言辞来强调这一点。在我们尝试制造软件“吞噬世界”的过程中，我们已经建立了世界上迄今为止所见过的最伟大的大规模监视基础设施。我们正朝着万物互联迈进，我们正在迅速走近这样一个世界：每个有人居住的空间至少包含一个带互联网连接的麦克风，以智能手机，智能电视，语音控制助理设备，婴儿监视器甚至儿童玩具的形式存在，并使用基于云的语音识别。这些设备中的很多都有着可怕的安全记录。 56 | 57 | 即使是最为极权与专制的政权，可能也只会想着在每个房间装一个麦克风，并强迫每个人始终携带能够追踪其位置与动向的设备。然而，我们显然是自愿地，甚至热情地投身于这个全域监视的世界。不同之处在于，数据是由公司，而不是由政府机构收集的。 58 | 59 | 并不是所有的数据收集都称得上监视，但检视这一点有助于理解我们与数据收集者之间的关系。为什么我们似乎很乐意接受企业的监视呢？也许你觉得自己没有什么好隐瞒的，换句话说，你与当权阶级穿一条裤子，你不是被边缘化的少数派，也不必害怕受到迫害。不是每个人都如此幸运。或者，也许这是因为目的似乎是温和的，这不是公然胁迫，也不是强制性的，而只是更好的推荐与更个性化的营销。但是，结合上一节中对预测性分析的讨论，这种区别似乎并不是很清晰。 60 | 61 | 我们已经看到与汽车追踪设备挂钩的汽车保险费，以及取决于需要人佩戴健身追踪设备来确定的健康保险范围。当监视被用于决定生活的重要方面时，例如保险或就业，它就开始变得不那么温和了。此外，数据分析可以揭示出令人惊讶的私密事物：例如，智能手表或健身追踪器中的运动传感器能以相当好的精度计算出你正在输入的内容（比如密码）。而分析算法只会变得越来越精确。 62 | 63 | ## 同意与选择的自由 64 | 65 | 我们可能会断言用户是自愿选择使用服务的，尽管服务会跟踪其活动，而且他们已经同意了服务条款与隐私政策，因此他们同意数据收集。我们甚至可以声称，用户在用所提供的数据来换取有价值的服务，并且为了提供服务，追踪是必要的。毫无疑问，社交网络，搜索引擎，以及各种其他免费的在线服务对于用户来说都是有价值的，但是这个说法却存在问题。 66 | 67 | 用户几乎不知道他们提供给我们的是什么数据，哪些数据被放进了数据库，数据又是怎样被保留与处理的，大多数隐私政策都是模棱两可的，忽悠用户而不敢打开天窗说亮话。如果用户不了解他们的数据会发生什么，就无法给出任何有意义的同意。有时来自一个用户的数据还会提到一些关于其他人的事，而其他那些人既不是该服务的用户，也没有同意任何条款。我们在本书这一部分中讨论的衍生数据集；来自整个用户群的数据，加上行为追踪与外部数据源，就恰好是用户无法（在真正意义上）理解的数据类型。 68 | 69 | 而且从用户身上挖掘数据是一个单向过程，而不是真正的互惠关系，也不是公平的价值交换。用户对能用多少数据换来什么样的服务，既没有没有发言权也没有选择权：服务与用户之间的关系是非常不对称与单边的。这些条款是由服务提出的，而不是由用户提出的。对于不同意监视的用户，唯一真正管用的备选项，就是简单地不使用服务。但这个选择也不是真正自由的：如果一项服务如此受欢迎，以至于“被大多数人认为是基本社会参与的必要条件”，那么指望人们选择退出这项服务是不合理的，使用它事实上（de facto）是强制性的。例如，在大多数西方社会群体中，携带智能手机，使用 Facebook 进行社交，以及使用 Google 查找信息已成为常态。特别是当一项服务具有网络效应时，人们选择不使用会产生社会成本。 70 | 71 | 因为跟踪用户而拒绝使用服务，这只是少数人才拥有的权力，他们有足够的时间与知识来了解隐私政策，并承受的起代价：错过社会参与，以及使用服务可能带来的专业机会。对于那些处境不太好的人而言，并没有真正意义上的选择：监控是不可避免的。 72 | 73 | ## 隐私与数据使用 74 | 75 | 有时候，人们声称“隐私已死”，理由是有些用户愿意把各种关于他们生活的事情发布到社交媒体上，有时是平凡俗套，但有时是高度私密的。但这种说法是错误的，而且是对隐私（privacy）一词的误解。拥有隐私并不意味着保密一切东西；它意味着拥有选择向谁展示哪些东西的自由，要公开什么，以及要保密什么。隐私权是一项决定权：在从保密到透明的光谱上，隐私使得每个人都能决定自己想要在什么地方位于光谱上的哪个位置。这是一个人自由与自主的重要方面。 76 | 77 | 当通过监控基础设施从人身上提取数据时，隐私权不一定受到损害，而是转移到了数据收集者手中。获取数据的公司实际上是说“相信我们会用你的数据做正确的事情”，这意味着，决定要透露什么和保密什么的权利从个体手中转移到了公司手中。这些公司反过来选择保密这些监视结果，因为揭露这些会令人毛骨悚然，并损害它们的商业模式（比其他公司更了解人）。用户的私密信息只会间接地披露，例如针对特定人群定向投放广告的工具（比如那些患有特定疾病的人群）。 78 | 79 | 即使特定用户无法从特定广告定向的人群中以个体的形式区分出来，但他们已经失去了披露一些私密信息的能动性，例如他们是否患有某种疾病。决定向谁透露什么并不是由个体按照自己的喜好决定的，是由公司，以利润最大化为目标来行使隐私权的。 80 | 81 | 许多公司都有一个目标，不要让人感觉到毛骨悚然，先不说它们收集数据实际上是多么具有侵犯性，让我们先关注用户感知的管理。这些用户感受经常被管理的很糟糕：例如，在事实上可能正确的一些东西，但如果会触发痛苦的回忆，用户可能并不希望被提醒。对于任何类型的数据，我们都应当考虑它出错、不可取、不合时宜的可能性，并且需要建立处理这些失效的机制。无论是“不可取”还是“不合时宜”，当然都是由人的判断决定的；除非我们明确地将算法编码设计为尊重人类的需求，否则算法会无视这些概念。作为这些系统的工程师，我们必须保持谦卑，充分规划，接受这些失效。 82 | 83 | 允许在线服务的用户控制其隐私设置，例如控制其他用户可以看到哪些东西，是将一些控制交还给用户的第一步。但无论怎么设置，服务本身仍然可以不受限制地访问数据，并能以隐私策略允许的任何方式自由使用它。即使服务承诺不会将数据出售给第三方，它通常会授予自己不受限制的权利，以便在内部处理与分析数据，而且往往比用户公开可见的部分要深入的多。这种从个体到公司的大规模隐私权转移在历史上是史无前例的。监控一直存在，但它过去是昂贵的，手动的，不是可扩展的，自动化的。信任关系始终存在，例如患者与其医生之间，或被告与其律师之间，但在这些情况下，数据的使用严格受到道德，法律和监管限制的约束。互联网服务使得在未经有意义的同意下收集大量敏感信息变得容易得多，而且无需用户理解他们的私人数据到底发生了什么。 84 | 85 | ## 数据资产与权力 86 | 87 | 由于行为数据是用户与服务交互的副产品，因此有时被称为“数据废气”，暗示数据是毫无价值的废料。从这个角度来看，行为和预测性分析可以被看作是一种从数据中提取价值的回收形式，否则这些数据就会被浪费。更准确的看法恰恰相反：从经济的角度来看，如果定向广告是服务的金主，那么关于人的行为数据就是服务的核心资产。在这种情况下，用户与之交互的应用仅仅是一种诱骗用户将更多的个人信息提供给监控基础设施的手段。在线服务中经常表现出的令人愉悦的人类创造力与社会关系，十分讽刺地被数据提取机器所滥用。 88 | 89 | 个人数据是珍贵资产的说法因为数据中介的存在得到支持，这是阴影中的秘密行业，购买，聚合，分析，推断，以及转售私密个人数据，主要用于市场营销。初创公司按照它们的用户数量，“眼球数”，即它们的监视能力来估值。因为数据很有价值，所以很多人都想要它。当然，公司也想要它，这就是为什么它们一开始就收集数据的原因。但政府也想获得它：通过秘密交易，胁迫，法律强制，或者只是窃取。当公司破产时，收集到的个人数据就是被出售的资产之一。而且数据安全很难保护，因此经常发生令人难堪的泄漏事件。 90 | 91 | 这些观察已经导致批评者声称，数据不仅仅是一种资产，而且是一种“有毒资产”，或者至少是“有害物质”。即使我们认为自己有能力阻止数据滥用，但每当我们收集数据时，我们都需要平衡收益以及这些数据落入恶人手中的风险：计算机系统可能会被犯罪分子或敌国特务渗透，数据可能会被内鬼泄露，公司可能会落入不择手段的管理层手中，而这些管理者有着迥然不同的价值观，或者国家可能被能毫无愧色迫使我们交出数据的政权所接管。 92 | 93 | 俗话说，“知识就是力量”。更进一步，“在避免自己被审视的同时审视他人，是权力最重要的形式之一”。这就是极权政府想要监控的原因：这让它们有能力控制全体居民。尽管今天的科技公司并没有公开地寻求政治权力，但是它们积累的数据与知识却给它们带来了很多权力，其中大部分是在公共监督之外偷偷进行的。 94 | 95 | ## 回顾工业革命 96 | 97 | 数据是信息时代的决定性特征。互联网，数据存储，处理和软件驱动的自动化正在对全球经济和人类社会产生重大影响。我们的日常生活与社会组织在过去十年中发生了变化，而且在未来的十年中可能会继续发生根本性的变化，所以我们会想到与工业革命对比。工业革命是通过重大的技术与农业进步实现的，它带来了持续的经济增长，长期的生活水平显著提高。然而它也带来了一些严重的问题：空气污染（由于烟雾和化学过程）和水污染（工业垃圾和人类垃圾）是可怖的。工厂老板生活在纷奢之中，而城市工人经常居住在非常糟糕的住房中，并且在恶劣的条件下长时间工作。童工很常见，甚至包括矿井中危险而低薪的工作。 98 | 99 | 制定了保护措施花费了很长的时间，例如环境保护条例，工作场所安全条例，宣布使用童工非法，以及食品卫生检查。毫无疑问，生产成本增加了，因为工厂再也不能把废物倒入河流，销售污染的食物，或者剥削工人。但是整个社会都从中受益良多，我们中很少会有人想回到这些管制条例之前的日子。就像工业革命有着黑暗面需要应对一样，我们转向信息时代的过程中，也有需要应对与解决的重大问题。我相信数据的收集与使用就是其中一个问题。用布鲁斯·施奈尔的话来说： 100 | 101 | > 数据是信息时代的污染问题，保护隐私是环境挑战。几乎所有的电脑都能生产信息。它堆积在周围，开始溃烂。我们如何处理它，我们如何控制它，以及如何摆脱它，是信息经济健康发展的核心议题。正如我们今天回顾工业时代的早期年代，并想知道我们的祖先在忙于建设工业世界的过程时怎么能忽略污染问题；我们的孙辈在回望信息时代的早期年代时，将会就我们如何应对数据收集和滥用的挑战来评断我们。 102 | > ​ 我们应该设法让他们感到骄傲。 103 | 104 | ## 立法和自律 105 | 106 | 数据保护法可能有助于维护个人的权利。例如，1995 年的“欧洲数据保护指示”规定，个人数据必须“为特定的，明确的和合法的目的收集，而不是以与这些目的不相符的方式进一步处理”，并且数据必须“就收集的目的而言适当，相关，不过分。“。但是，这个立法在今天的互联网环境下是否有效还是有疑问的。这些规则直接否定了大数据的哲学，即最大限度地收集数据，将其与其他数据集结合起来进行试验和探索，以便产生新的洞察。探索意味着将数据用于未曾预期的目的，这与用户同意的“特定和明确”目的相反（如果我们可以有意义地表示同意的话）。更新的规章正在制定中。 107 | 108 | 那些收集了大量有关人的数据的公司反对监管，认为这是创新的负担与阻碍。在某种程度上，这种反对是有道理的。例如，分享医疗数据时，存在明显的隐私风险，但也有潜在的机遇：如果数据分析能够帮助我们实现更好的诊断或找到更好的治疗方法，能够阻止多少人的死亡？过度监管可能会阻止这种突破。在这种潜在机会与风险之间找出平衡是很困难的。 109 | 110 | 从根本上说，我认为我们需要科技行业在个人数据方面的文化转变。我们应该停止将用户视作待优化的指标数据，并记住他们是值得尊重，有尊严和能动性的人。我们应当在数据收集和实际处理中自我约束，以建立和维持依赖我们软件的人们的信任。我们应当将教育终端用户视为己任，告诉他们我们是如何使用他们的数据的，而不是将他们蒙在鼓里。我们应该允许每个人保留自己的隐私，即，对自己数据的控制，而不是通过监视来窃取这种控制权。我们控制自己数据的个体权利就像是国家公园的自然环境：如果我们不去明确地保护它，关心它，它就会被破坏。这将是公地的悲剧，我们都会因此而变得更糟。无所不在的监视并非不可避免的，我们现在仍然能阻止它。 111 | 112 | 我们究竟能做到哪一步，是一个开放的问题。首先，我们不应该永久保留数据，而是一旦不再需要就立即清除数据。清除数据与不变性的想法背道而驰，但这是可以解决该问题。我所看到的一种很有前景的方法是通过加密协议来实施访问控制，而不仅仅是通过策略。总的来说，文化与态度的改变是必要的。 113 | -------------------------------------------------------------------------------- /10~OLAP/03.ROLAP/Sqoop/介绍与部署.md: -------------------------------------------------------------------------------- 1 | # Sqoop 2 | 3 | Sqoop 是连接传统关系型数据库和 Hadoop 的桥梁。它包括以下两个方面: 4 | 　　 1、将关系型数据库的数据导入到 Hadoop 及其相关的系统中，如 Hive 和 HBase。 5 | 　　 2、将数据从 Hadoop 系统里抽取并导出到关系型数据库。 6 | Sqoop 的核心设计思想是利用 MapReduce 加快数据传输速度。也就是说 Sqoop 的导入和导出功能是通过 MapReduce 作业实现的。所以它是一种批处理方式进行数据传输，难以实现实时的数据进行导入和导出。 7 | 我们为什么选择 Sqoop 呢？通常基于三个方面的考虑: 8 | 　　 1、它可以高效、可控地利用资源，可以通过调整任务数来控制任务的并发度。另外它还可以配置数据库的访问时间等等。 9 | 　　 2、它可以自动的完成数据类型映射与转换。我们往往导入的数据是有类型的，它可以自动根据数据库中的类型转换到 Hadoop 中，当然用户也可以自定义它们之间的映射关系。 10 | 　　 3、它支持多种数据库，比如，MySQL、Oracle 和 PostgreSQL 等等数据库。 11 | 12 | ## Architecture 13 | 14 | Sqoop 架构是非常简单的，它主要由三个部分组成：Sqoop client、HDFS/HBase/Hive、Database。下面我们来看一下 Sqoop 的架构图。 15 | ![](http://img.blog.csdn.net/20160518085002989) 16 | 17 | 用户向 Sqoop 发起一个命令之后，这个命令会转换为一个基于 Map Task 的 MapReduce 作业。Map Task 会访问数据库的元数据信息，通过并行的 Map Task 将数据库的数据读取出来，然后导入 Hadoop 中。当然也可以将 Hadoop 中的数据，导入传统的关系型数据库中。它的核心思想就是通过基于 Map Task (只有 map)的 MapReduce 作业，实现数据的并发拷贝和传输，这样可以大大提高效率。 18 | 19 | # Quick Start 20 | 21 | 我们 Hadoop 集群安装的是 Hadoop2.2.0 版本，所以 Sqoop 安装版本也要与之相匹配，否则后面 Sqoop 22 | 工具的使用会出现问题。这里我们选择 sqoop-1.4.6.bin**hadoop-2.0.4-alpha.tar.gz 版本安装。安装 23 | Sqoop 很简单，分为以下几步完成。 24 | 1、首先将下载的 sqoop-1.4.6.bin**hadoop-2.0.4-alpha.tar.gz 放到 /usr/java/目录下，然后对安装包解压、修改文件名和修改用户权限。 25 | 26 | ``` 27 | [root@cs0 java]# tar zxvf sqoop-1.4.6.bin__hadoop-1.0.0.tar.gz //解压 28 | [root@cs0 java]# rm sqoop-1.4.6.bin__hadoop-1.0.0.tar.gz //删除安装包 29 | [root@cs0 java]# mv sqoop-1.4.6.bin__hadoop-1.0.0 sqoop //修改安装文件目录 30 | [root@cs0 java]# chown -R hadoop:hadoop sqoop //赋予sqoop hadoop用户权限12341234 31 | ``` 32 | 33 | 2、切换到/sqoop/conf 目录下，执行以下命令。 34 | 35 | ``` 36 | [hadoop@cs0 java]$ cd sqoop/conf 37 | [hadoop@cs0 java]$ mv sqoop-env-template.sh sqoop-env.sh 38 | 然后使用 vi sqoop-env.sh 命令，打开文件添加如下内容。 39 | #Set path to where bin/hadoop is available 40 | export HADOOP_COMMON_HOME=/usr/java/hadoop-2.2.0-x64 41 | #Set path to where hadoop-*-core.jar is available 42 | export HADOOP_MAPRED_HOME=/usr/java/hadoop-2.2.0-x64 43 | #set the path to where bin/hbase is available 44 | #export HBASE_HOME= 45 | #Set the path to where bin/hive is available 46 | export HIVE_HOME=/usr/java/hive-1.0.0 47 | #Set the path for where zookeper config dir is 48 | #export ZOOCFGDIR= 49 | 如果数据读取不涉及hbase和hive，那么相关hbase和hive的配置可以不加；如果集群有独立的zookeeper集群，那么配置zookeeper，反之，不用配置。12345678910111213141234567891011121314 50 | ``` 51 | 52 | 3、将相关的驱动 jar 包拷贝到 sqoop/lib 目录下。安装 Hadoop2.2.0 的核心 jar 包有三个需要导入：commons-cli-1.2.jar、hadoop-common-2.2.0.jar 和 hadoop- mapreduce-client-core-2.2.0.jar。数据库驱动 jar 包需要导入，这里我们使用的是 mysql 数据库，所以需要导入 mysql-connector-java-5.1.21.jar 包。 53 | 54 | ``` 55 | [hadoop@cs0 lib]$ cp commons-cli-1.2.jar /usr/java/sqoop/lib 56 | [hadoop@cs0 common]$ cp hadoop-common-2.2.0.jar /usr/java/sqoop/lib 57 | [hadoop@cs0 mapreduce]$ cp hadoop-mapreduce-client-core-2.2.0.jar /usr/java/sqoop/lib 58 | [hadoop@cs0 java]$ cp mysql-connector-java-5.1.21.jar /usr/java/sqoop/lib12341234 59 | ``` 60 | 61 | 4、添加环境变量。 62 | 63 | ``` 64 | [hadoop@cs0 java]$ vi ~/.bash_profile 65 | PATH=$PATH:$HOME/bin 66 | export SQOOP_HOME=/usr/java/sqoop //sqoop安装目录 67 | export PATH=$PATH:$SQOOP_HOME/bin 68 | 环境添加完毕后，执行以下命令使环境生效。 69 | [hadoop@cs0 java]$ source ~/.bash_profile 123456123456 70 | ``` 71 | 72 | 5、测试运行 73 | 74 | ``` 75 | [hadoop@cs0 java]$ sqoop list-databases \ 76 | > --connect jdbc:mysql://db.ywendeng.net:3306/djtdb_hadoop \ 77 | > --username sqoop \ 78 | > --password sqoop 79 | 15/06/03 02:47:27 INFO sqoop.Sqoop: Running Sqoop version: 1.4.6 80 | 15/06/03 02:47:27 WARN tool.BaseSqoopTool: Setting your password on the command-line is insecure. Consider using -P instead. 81 | 15/06/03 02:47:28 INFO manager.MySQLManager: Preparing to use a MySQL streaming resultset. 82 | information_schema 83 | sqoop 命令执行成功，代表安装成功。 84 | ``` 85 | 86 | # Usage 87 | 88 | - **Sqoop 与 HDFS 结合** 89 | 90 | 下面我们结合 HDFS，介绍 Sqoop 从关系型数据库的导入和导出。 91 | **Sqoop import** 92 | 　　它的功能是将数据从关系型数据库导入 HDFS 中，其流程图如下所示。 93 | 　　![这里写图片描述](http://img.blog.csdn.net/20160518085233946) 94 | 　　 我们来分析一下 Sqoop 数据导入流程，首先用户输入一个 Sqoop import 命令，Sqoop 95 | 会从关系型数据库中获取元数据信息，比如要操作数据库表的 96 | schema 是什么样子，这个表有哪些字段，这些字段都是什么数据类型等。它获取这些信息之后，会将输入命令转化为基于 Map 的 97 | MapReduce 作业。这样 MapReduce 作业中有很多 Map 任务，每个 Map 任务从数据库中读取一片数据，这样多个 Map 98 | 任务实现并发的拷贝，把整个数据快速的拷贝到 HDFS 上。 99 | 　　 下面我们看一下 Sqoop 如何使用命令行来导入数据的，其命令行语法如下所示。 100 | 101 | ``` 102 | sqoop import \ 103 | --connect jdbc:mysql://db.ywendeng.net:3306/djtdb_hadoop \ 104 | --username sqoop \ 105 | --password sqoop \ 106 | --table user \ 107 | --target-dir /junior/sqoop/ \ //可选，不指定目录，数据默认导入到/user下 108 | --where "sex='female'" \ //可选 109 | --as-sequencefile \ //可选，不指定格式，数据格式默认为 Text 文本格式 110 | --num-mappers 10 \ //可选，这个数值不宜太大 111 | --null-string '\\N' \ //可选 112 | --null-non-string '\\N' \ //可选 113 | --connect：指定 JDBC URL。 114 | --username/password：mysql 数据库的用户名。 115 | --table：要读取的数据库表。 116 | --target-dir：将数据导入到指定的 HDFS 目录下，文件名称如果不指定的话，会默认数据库的表名称。 117 | --where：过滤从数据库中要导入的数据。 118 | --as-sequencefile：指定数据导入数据格式。 119 | --num-mappers：指定 Map 任务的并发度。 120 | --null-string，--null-non-string：同时使用可以将数据库中的空字段转化为'\N'，因为数据库中字段为 null，会占用很大的空间。1234567891011121314151617181912345678910111213141516171819 121 | ``` 122 | 123 | 下面我们介绍几种 Sqoop 数据导入的特殊应用。 124 | 1、Sqoop 每次导入数据的时候，不需要把以往的所有数据重新导入 HDFS，只需要把新增的数据导入 HDFS 即可，下面我们来看看如何导入新增数据。 125 | 126 | ``` 127 | sqoop import \ 128 | --connect jdbc:mysql://db.ywendeng.net:3306/djtdb_hadoop \ 129 | --username sqoop \ 130 | --password sqoop \ 131 | --table user \ 132 | --incremental append \ //代表只导入增量数据 133 | --check-column id \ //以主键id作为判断条件 134 | --last-value 999 //导入id大于999的新增数据 135 | 上述三个组合使用，可以实现数据的增量导入。123456789123456789 136 | ``` 137 | 138 | 2、Sqoop 数据导入过程中，直接输入明码存在安全隐患，我们可以通过下面两种方式规避这种风险。 139 | 　　 1)-P:sqoop 命令行最后使用 -P，此时提示用户输入密码，而且用户输入的密码是看不见的，起到安全保护作用。密码输入正确后，才会执行 sqoop 命令。 140 | 141 | ``` 142 | sqoop import \ 143 | --connect jdbc:mysql://db.ywendeng.net:3306/djtdb_hadoop \ 144 | --username sqoop \ 145 | --table user \ 146 | -P1234512345 147 | ``` 148 | 149 | 2)–password-file：指定一个密码保存文件，读取密码。我们可以将这个文件设置为只有自己可读的文件，防止密码泄露。 150 | 151 | ``` 152 | sqoop import \ 153 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 154 | --username sqoop \ 155 | --table user \ 156 | --password-file my-sqoop-password1234512345 157 | ``` 158 | 159 | **Sqoop export** 160 | 　　 它的功能是将数据从 HDFS 导入关系型数据库表中，其流程图如下所示。 161 | 　　![这里写图片描述](http://img.blog.csdn.net/20160518085702820) 162 | 　　我们来分析一下 Sqoop 数据导出流程，首先用户输入一个 Sqoop export 命令，它会获取关系型数据库的 schema，建立 163 | Hadoop 字段与数据库表字段的映射关系。然后会将输入命令转化为基于 Map 的 MapReduce 作业，这样 164 | MapReduce 作业中有很多 Map 任务，它们并行的从 HDFS 读取数据，并将整个数据拷贝到数据库中。　　 165 | 　　 下面我们看一下 Sqoop 如何使用命令行来导出数据的，其命令行语法如下所示。 166 | 167 | ``` 168 | sqoop export \ 169 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 170 | --username sqoop \ 171 | --password sqoop \ 172 | --table user \ 173 | --export-dir user 174 | --connect：指定 JDBC URL。 175 | --username/password：mysql 数据库的用户名和密码。 176 | --table：要导入的数据库表。 177 | --export-dir：数据在 HDFS 上的存放目录。1234567891012345678910 178 | ``` 179 | 180 | 下面我们介绍几种 Sqoop 数据导出的特殊应用。 181 | 　　 1、Sqoop export 将数据导入数据库，一般情况下是一条一条导入的，这样导入的效率非常低。这时我们可以使用 Sqoop export 的批量导入提高效率，其具体语法如下。 182 | 183 | ``` 184 | sqoop export \ 185 | --Dsqoop.export.records.per.statement=10 \ 186 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 187 | --username sqoop \ 188 | --password sqoop \ 189 | --table user \ 190 | --export-dir user \ 191 | --batch 192 | --Dsqoop.export.records.per.statement：指定每次导入10条数据，--batch：指定是批量导入。123456789123456789 193 | ``` 194 | 195 | 2、在实际应用中还存在这样一个问题，比如导入数据的时候，Map Task 执行失败，那么该 Map 任务会转移到另外一个节点执行重新运行，这时候之前导入的数据又要重新导入一份，造成数据重复导入。因为 Map Task 没有回滚策略，一旦运行失败，已经导入数据库中的数据就无法恢复。Sqoop export 提供了一种机制能保证原子性，使用–staging-table 选项指定临时导入的表。Sqoop export 导出数据的时候会分为两步：第一步，将数据导入数据库中的临时表，如果导入期间 Map Task 失败，会删除临时表数据重新导入；第二步，确认所有 Map Task 任务成功后，会将临时表名称为指定的表名称。 196 | 197 | ``` 198 | sqoop export \ 199 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 200 | --username sqoop \ 201 | --password sqoop \ 202 | --table user \ 203 | --staging-table staging_user 123456123456 204 | ``` 205 | 206 | 3、在 Sqoop 导出数据过程中，如果我们想更新已有数据，可以采取以下两种方式。 207 | 　　 1)通过 –update-key id 更新已有数据。 208 | 209 | ``` 210 | sqoop export \ 211 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 212 | --username sqoop \ 213 | --password sqoop \ 214 | --table user \ 215 | --update-key id 123456123456 216 | ``` 217 | 218 | 2)使用 –update-key id 和–update-mode allowinsert 两个选项的情况下，如果数据已经存在，则更新数据，如果数据不存在，则插入新数据记录。 219 | 220 | ``` 221 | sqoop export \ 222 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 223 | --username sqoop \ 224 | --password sqoop \ 225 | --table user \ 226 | --update-key id \ 227 | --update-mode allowinsert12345671234567 228 | ``` 229 | 230 | 4、如果 HDFS 中的数据量比较大，很多字段并不需要，我们可以使用 –columns 来指定插入某几列数据。 231 | 232 | ``` 233 | sqoop export \ 234 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 235 | --username sqoop \ 236 | --password sqoop \ 237 | --table user \ 238 | --column username,sex123456123456 239 | ``` 240 | 241 | 5、当导入的字段数据不存在或者为 null 的时候，我们使用–input-null-string 和–input-null-non-string 来处理。 242 | 243 | ``` 244 | sqoop export \ 245 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 246 | --username sqoop \ 247 | --password sqoop \ 248 | --table user \ 249 | --input-null-string '\\N' \ 250 | --input-null-non-string '\\N'12345671234567 251 | ``` 252 | 253 | - **Sqoop 与其它系统结合** 254 | 255 | Sqoop 也可以与 Hive、HBase 等系统结合，实现数据的导入和导出，用户需要在 sqoop-env.sh 中添加 HBASE_HOME、HIVE_HOME 等环境变量。 256 | 257 | 1、Sqoop 与 Hive 结合比较简单，使用 –hive-import 选项就可以实现。 258 | 259 | ``` 260 | sqoop import \ 261 | --connect jdbc:mysql://db.ywendeng.net:3306/csdb_hadoop \ 262 | --username sqoop \ 263 | --password sqoop \ 264 | --table user \ 265 | --hive-import123456123456 266 | ``` 267 | 268 | 2、Sqoop 与 HBase 结合稍微麻烦一些，需要使用 –hbase-table 指定表名称，使用 –column-family 指定列名称。 269 | --------------------------------------------------------------------------------