2020-12-04 学习笔记

2020-12-04：

DG：Lamda大数据架构：

https://www.cnblogs.com/cciejh/p/lambda-architecture.html
不必深究

DG：IOTA大数据架构：

IOTA的整体思路是设定标准数据模型，通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数据模型贯穿始终，从而提高整体的计算效率，同时满足计算的需要，可以使用各种Ad-hoc Query来查询底层数据。
统一的一个Common Data Model：“主-谓-宾”模型描述，“X用户–事件1 – A页面（2018/4/11 20:00）”。

引用 SQL on Hadoop 文档中的概念来阐述，可以根据用户查询时延将其做下分类：
BatchBatch SQL 的查询时间通常在分钟、小时级别，一般用于复杂的 ETL 处理、数据挖掘、高级分析。最典型的系统是 Hive（ODPS）、Spark-SQL；
Interactive如 Impala 和 Drill 提供的交互式分析能力——在 Hadoop 规模的数据集上做传统 BI 和分析。在实现上通常采用 MPP 架构，比如 Presto（ADS 集成）、Impala、Drill、HAWQ（Seahawks）、Greenplum（HybridDB for psql）；Operational高并发、低延迟的查询，在 OLAP 中常作为存储预计算结果集的 KV 数据库如 HBase，以及传统的 OLTP 都属于这个范畴，牺牲部分灵活性来换取较高的查询效率。

市面上对 OLAP 从查询类型上的划分：离线批处理、即席查询（ad-hoc）、固化查询
https://xueqiu.com/9217191040/156749600
没看太懂

Ad-hoc Query：即席查询

https://zhuanlan.zhihu.com/p/131366019
随机查询，海量实时计算，在人可容忍的交互时间内(5秒内)，对于给定查询返回结果，
产品运营实时洞察
A/B Testing
用户增长领域
特点：
(灵活性) 查询方式不固定，不能被预计算
(海量) 查询数据规模超出传统数据库可以承受的规模 (100亿+)
(实时) 可以查询到最近产生的数据, 这一点不同业务形态要求的实时性会有差别
Ad-Hoc Query 和OLAP 很像，只是要求更高的灵活性
灵活性，海量，实时 ：考虑三个需求
目前场景的列式存储为 Parquet，ORC

查询引擎，目前大都是 MPP 架构查询引擎，例如 Impala/Presto/Drill/Vertica/ClickHouse，Spark 是 MapReduce 阵营里唯一可用于 Ad-Hoc Query 的引擎。
在一般的评测里，都会给予 Impala 的性能评分，而 Presto 紧随其后，Drill 目前在国内目前鲜有落地案例，Vertica 是付费产品，一般在传统企业中使用的多，Spark 性能中等，而 ClickHouse 在单表查询中有压倒性优势。

各个OLAP 引擎详细对比介绍：
如何比较Hive，Spark，Impala和Presto？
https://zhuanlan.zhihu.com/p/161000135
Hive支持四种文件格式，即TEXTFILE，ORC，RCFILE和SEQUENCEFILE

大数据分析的下一代架构–IOTA架构[上]：
https://blog.csdn.net/odailidong/article/details/80035658
https://blog.csdn.net/qq_32649581/article/details/83055771
lamda----->kappa>>>>>>IOTA
大数据分析的下一代架构–IOTA架构设计实践[下]

OLTP和OLAP有何区别?

1、适用人员不同：OLTP主要供基层人员使用，进行一线业务操作。OLAP则是探索并挖掘数据价值，作为企业高层进行决策的参考。
2、数据特点不同：OLTP的数据特点是当前的、最新的、细节的, 二维的、分立的；而OLTP则是历史的, 聚集的, 多维的，集成的, 统一的；
3、存取能力不同：OLTP可以读/写数十条记录，而OLAP则可以读上百万条记录；
4、工作事件的复杂度不同：OLTP执行的是简单的事务，而OLAP执行的是复杂任务；
5、DB大小不同：OLTP的DB 大小为100GB，而OLAP则可以达到100TB；
6、执行时间要求不同：OLTP具有实时性，OLAP对时间的要求不严格。
OLAP系统强调的是数据分析，响应速度要求没那么高。
主要应用是传统关系型数据库。OLTP系统强调的是内存效率，实时性比较高。

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

那么olap和oltp的主要区别有：

1.oltp面向的是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，记录即时的增、删、改、查，而olap的应用场景则是数据仓库的大数据量的查询统计，偏向于提供统计结果，用于分析决策。
2.处理数据的时效性也不一致，oltp一般时效性更强，一般来数据便进行处理，而olap一般是天级运行，t+1类型的应用。
3.oltp是面向应用、事务设计的结构，而olap主要面向主题设计的结构。一般来说oltp的吞吐量没有olap大，oltp一般为几十条，olap可达百万级别。
4.oltp的语句简单，主要是少量记录查询和单个的DML操作，olap动不动就成百上千行，大规模的查询和批量DML操作。
5.设计理念不一样，oltp主要是应用范式建模，而olap一般用的维度建模中的星型模型或者雪花模型。

HBase 适合做全量 Scan，但是对谓词下推(PushDown) 支持比较薄弱：

jdbc和odbc的区别

数据库 与 数据仓库的本质区别是什么？

https://www.zhihu.com/question/20623931
数据库：传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。业务性数据库，MySQL, Oracle, SqlServer等。
数据仓库：数据仓库系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。分析性数据库， Hive等

Hive数仓建表该选用ORC还是Parquet，压缩选LZO还是Snappy？

查询引擎: Hive, Impala, Pig, Presto, Drill等
计算框架: MapReduce, Spark等
数据模型: Avro, Thrift, Protocol Buffers, POJOs等
推荐书籍：《Hive性能调优实战》

JDBC 与ODBC的区别

ODBC： 开放数据库连接（Open Database Connectivity，ODBC），是为解决异构数据库间的数据共享而产生的，微软推出了 ODBC(Open Database Connectivity)方案，并获得厂商和开发人员的认可。ODBC建立了一组规范，并提供了对数据库访问的标准API，后来被X/OPEN和ISO/IEC采纳，作为SQL标准的一部分。
开放数据库互连（Open Database Connectivity，ODBC）是微软公司开放服务结构（WOSA，Windows Open Services Architecture）中有关数据库的一个组成部分，它建立了一组规范，并提供了一组对数据库访问的标准API（应用程序编程接口）。这些API利用SQL来完成其大部分任务。ODBC本身也提供了对SQL语言的支持，用户可以直接将SQL语句送给ODBC。开放数据库互连（ODBC）是Microsoft提出的数据库访问接口标准。开放数据库互连定义了访问数据库API的一个规范，这些API独立于不同厂商的DBMS，也独立于具体的编程语言（但是Microsoft的ODBC文档是用C语言描述的，许多实际的ODBC驱动程序也是用C语言写的。）ODBC规范后来被X/OPEN和ISO/IEC采纳，作为SQL标准的一部分，具体内容可以参看《ISO/IEC 9075-3:1995 (E) Call-Level Interface (SQL/CLI)》等相关的标准文件。

JDBC简介
JDBC（Java Data Base Connectivity,java数据库连接）是一种用于执行SQL语句的Java API，它是Java十三个规范之一。可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。JDBC提供了一种基准，据此可以构建更高级的工具和接口，使数据库开发人员能够编写数据库应用程序，同时，JDBC也是个商标名。

两者之间的联系
JDBC和ODBC都是用来连接数据库的启动程序，JDBC和ODBC由于具有数据库独立性甚至平台无关性，因而对Internet上异构数据库的访问提供了很好的支持。

总的来说：JDBC和ODBC都是连接数据库的程序。

数仓研究

https://www.jianshu.com/p/da62fb0c6a0b

传统数仓和互联网数仓
https://www.jianshu.com/p/0a11c7f3cec2
https://www.jianshu.com/p/0a11c7f3cec2

数仓架构：
https://www.jianshu.com/p/2b0509851df1
数仓建模
范式建模
Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构。
维度建模
Kimball提出的总线式的自下而上（DM-DW）的数据仓库架构。
维度建模，一般都会提到星型模型、雪花模型，星型模型做OLAP分析很方便。

指标字典
这里我们说的指标，其实就是KPI（Key Performance Indicator），关键绩效指标。
公司层面有公司最关注的KPI，比如：日活、GMV、订单量等等；不同的部门又有不同的关注KPI，比如：新用户数、复够人数等等，有了KPI，我们就可以根据KPI来考察部门的表现，也就是绩效。
这也是数字化转型嘛，所有的管理、绩效都数字化。
就数据平台来说，指标算是元数据的一种，指标的维护和管理是有套路的，下面就简单分享下关于指标的管理-指标字典。
指标字典
指标字典，其实就是对指标的管理，为了共享和统一修改和维护，我们会在Excel中维护所有的指标。当然，Excel对于共享和版本控制也不是很方便，可以开发个简单的指标管理系统，再配合上血缘关系，就更方便追踪数据流转了。
指标管理系统+血缘关系
指标编码
为了方便查找和管理，我们会对指标定义一套编码
指标类型
基础指标：不能再进一步拆解的指标，可以直接计算出来的指标，如“订单数”、“交易额”
衍生指标：在基础指标的基础上，通过某个特殊维度计算出的指标，如“微信订单数”、“支付宝订单数”
计算指标：通过若干个基础指标计算得来的指标，在业务角度无法再拆解的指标，如“售罄率”、“复购率”
业务口径
指标最重要的就是，明确指标的统计口径，就是这个指标是怎么算出来的，口径统一了，才不会产生歧义
指标模板
除了上面，我们说到的几点，还有一些基本的，像“指标名称”、计算公式，就组成了指标的模板

指标的梳理和管理
一开始指标的梳理是很麻烦的，因为要统一一个口径，需要和不同的部门去沟通协调；还有可能会有各种各样的指标出现，需要去判断是否真的需要这个指标，是否可以用其他指标来替代；指标与指标之间的关系也需要理清楚。
而且第一版指标梳理好之后，需要进行推广和维护，不断地迭代，持续推动，让公司所有部门都统一站在一个视角关注问题。

最重要的维度之日期维度
https://www.jianshu.com/p/c1ba91fbe70c

关于命名规范
阿里云的MaxCompute，这是阿里提供的数据平台，一整套开发环境，省去了自建平台的麻烦
主角-词根：指标体系中有很多“率”的指标，都可以拆解成XXX+率，率可以叫rate，那我们所有的指标都叫做XXX+rate；词根可以用来统一表名、字段名、主题域名等等。
表名
表名需要见名知意，通过表名就可以知道它是哪个业务域，干嘛用的，什么粒度的数据。

常规表
常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去完善的表。
规范：分层前缀[dwd|dws|ads|bi]_业务域_主题域_XXX_粒度
业务域、主题域我们都可以用词根的方式枚举清楚，不断完善，粒度也是同样的，主要的是时间粒度、日、月、年、周等，使用词根定义好简称。

中间表
中间表一般出现在Job中，是Job中临时存储的中间数据的表，中间表的作用域只限于当前Job执行过程中，Job一旦执行完成，该中间表的使命就完成了，是可以删除的（按照自己公司的场景自由选择，以前公司会保留几天的中间表数据，用来排查问题）。
规范：mid_table_name_[0~9|dim]
table_name是我们任务中目标表的名字，通常来说一个任务只有一个目标表。
这里加上表名，是为了防止自由发挥的时候表名冲突，而末尾大家可以选择自由发挥，起一些有意义的名字，或者简单粗暴，使用数字代替，各有优劣吧，谨慎选择。
通常会遇到需要补全维度的表，这里我喜欢使用dim结尾。
中间表在创建时，请加上 ,如果要保留历史的中间表，可以加上日期或者时间戳
drop table if exists table_name;
create table_name as xxx;
临时表
临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表。
规范：tmp_xxx
只要加上tmp开头即可，其他名字随意，
注意tmp开头的表不要用来实际使用，只是测试验证而已。
维度表
维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以手工来维护。
规范：dim_xxx
维度表，统一以dim开头，后面加上，对该指标的描述，可以自由发挥。
手工表
手工表是手工维护的表，手工初始化一次之后，一般不会自动改变，后面变更，也是手工来维护。
一般来说，手工的数据粒度是偏细的，所以，暂时我们统一放在dwd层，后面如果有目标值或者其他类型手工数据，再根据实际情况分层。
规范：dwd_业务域_manual_xxx
手工表，增加特殊的主题域，manual，表示手工维护表
指标
指标的命名也参考词根，避免出现同一个指标，10个人有10个命名方法。
后记
具体操作结合公司实际情况，规范及早制定。

浅谈数据治理
随着数据量越来越大，数据成为一种资产，我们需要更好地管理这些数据，更好地体现数据的价值，这就需要数据治理。
数据质量越来越差，问题发现严重滞后
缺少数据标准，各个部门标准不统一
数据变更对下游的影响不清晰，无法确认影响范围
数据治理（Data Governance），是一套持续改善管理机制，通常包括了数据架构组织、数据模型、政策及体系制定、技术工具、数据标准、数据质量、影响度分析、作业流程、监督及考核流程等内容。
简单来说就是有很多流程和标准，像“元数据管理”、“主数据管理”、“数据质量”都包含其中。
通过数据治理来解决我们使用数据的过程中遇到的问题。

关于增量
GreenPlum

上下游约定
由于数仓的特性和定位，它就需要强依赖上游的业务系统，当然也会有一些下游系统，所以定好上下游的规范，变更的通知机制是非常有必要的。
表结构变更
上游的表结构经常会发生变化，新增字段、修改字段、删除字段（除非真的不用这个字段了，通常会选择标识为弃用）。
表结构最好要维护清楚，表名、字段名、字段类型、字段描述，都整理清楚，不使用的字段要么删除，要么备注好，当业务频繁发生变化或者迭代优化的时候，很容易出现，我写了半天的代码，最后发现表用的不对，字段用的不对，这就尴尬了。
自动化流程
对于数仓来说，一般的邮件、报表、可视化平台都是下游，所以当我们在数仓中进行某些重构、优化操作的时候，也需要通知他们。
主要就是对数仓模型做好维护，表的使用场景、字段描述等。

任务注释：

总结：数仓必读文章

我所经历的大数据平台发展史

比较了非互联网和互联网两个时代以及传统与非传统两个行业：
到今天互联网、非互联网的数据平台架构已经差异非常大
自从数据仓库发展起来到现在，基本上可以分为五个时代、四种架构（大家可以详细翻一下数据仓库的发展历史，在这里仅作科普性介绍）
约在 1991 年前的全企业集成：
1991 年后的企业数据集成 EDW 时代：Bill Inmon三范式建模，自上而下
1994 年 -1996 年的数据集市：Ralph kilmball 维度建模，自下而上
1996-1997 年左右的两个架构吵架：
1998 年 -2001 年左右的合并年代：Bill Inmon 提出的CIF（corporation information factory） 架构模式

hivesql入门操作：

本文暂且不说业务，只说操作。
1.首先介绍大数据的奠基人：google 和 Apache

google三大著名论文：
Google file system：讲述借助低成本机器有效的存储海量数据；
Google MapReduce：强调快速计算海量数据；
Google BigTable：强调海量数据的快速查询；
Apache 公司受到google三大论文的启发，开发出Hadoop分布式系统。
Hive可以借助查询语言SQl将HDFS上存储的结构化文件映射成一张数据库表，并提供类SQL查询功能。本质是将浅学易懂的SQL转换为MapReduce程序，避免编写复杂的MapReduce程序。

首先，我们一般利用SecureCRSecureFXPortable终端进入远程机器（该机器与Hadoop集群相连），然后进入Hive的命令行。
select count（*） from 表名;
#统计指定表有多少条数据
select * from 表名 where pt>=‘2017-07-07’ and pt<=‘2017-07-16’;
#显示日期为7.7-7.16号的所有数据
上传文件、下载文件、运行(假设文件为file.sh)
rz file.sh;
#cd 目标目录后，执行rz，就可将文件上传并保存到该目录
sz file.sh;
#下载文件，可以在终端设置好下载文件的路径
bash file.sh;
#运行file.sh脚本
后台运行脚本

nohup bash file.sh 2017-07-28 1 > test.log 2>&1 &   

hiveserver2是什么：

hiveserver2作用：

1.为hive提供了一种允许客户端远程访问的服务。

2.基于thrift协议，支持跨平台，跨编程语言对hive访问；

3.允许远程访问hive；
HiveServer2(HS2)是一种能使客户端执行Hive查询的服务。 HiveServer2是HiveServer1的改进版，HiveServer1已经被废弃。HiveServer2可以支持多客户端并发和身份认证。旨在为开放API客户端（如JDBC和ODBC）提供更好的支持。
HiveServer2单进程运行，提供组合服务，包括基于Thrift的Hive服务（TCP或HTTP）和用于Web UI的Jetty Web服务器。

API和SDK：

API (Application Programming Interface)=应用程序编程接口
SDK（Software Development Kit)=软件开发工具包
研发人员A开发了软件A，研发人员B正在研发软件B。 有一天，研发人员B想要调用软件A的部分功能来用，但是他又不想从头看一遍软件A的源码和功能实现过程，怎么办呢？ 研发人员A想了一个好主意：我把软件A里你需要的功能打包好，写成一个函数。你按照我说的流程，把这个函数放在软件B里，就能直接用我的功能了！其中，API就是研发人员A说的那个函数。这就是API通俗的理解。
最后，贴近生活讲讲两者的关系：有一杯密封饮料，它的名字叫做“SDK”。
饮料上插着吸管，吸管的名字叫“API”。把你叫做“XX系统”。
如果你想喝到SDK里的饮料（让系统拥有SDK中的功能），你必须通过API这根吸管来实现（通过API连接你的系统和SDK工具
包），否则你就喝不到饮料。
所以：SDK＝放着你想要的软件功能的软件包
API＝SDK上唯一的接口
SDK是很多API和相关规范文档的集合，可以调用SDK中的API去实现特定的功能。

1 行为分析常见名词
指标（Metrics）：
也叫度量，是量化衡量的标准。
比如衡量APP基础运营情况的指标会有：活跃用户数、使用时长、打开次数等，
衡量留存情况的指标会有：次日留存率、留存用户数等等
维度（Dimensions）：