数据仓库系列文章(持续更新)数仓架构发展史数仓建模方法论数仓建模分层理论数仓建模—宽表的设计数仓建模—指标体系数据仓库之拉链表数仓—数据集成数仓—数据集市数仓—商业智能系统数仓—埋点设计与管理数仓—ID

本文目录数据治理统一流程参考模型为什么要治理DMBOK的数据治理框架数仓治理治理的分类数据源治理数仓模型治理数据服务治理上下游约定数仓评价(如何评价一个数据仓库的好坏)数据准确性时效性覆盖性建构层次清晰数据准确一致性能指标成本指标易用性指标需求响速度稳定性总结知识星球数据仓库系列文章(部分已出，持续更新)数仓架构发展史数仓建模方法论数仓建模分层理论数仓建模—宽表的设计数仓建模—指标体系数据仓库之拉链表数仓—数据集成数仓—数据集市数仓—商业智能系统数仓—埋点设计与管理数仓—ID

关注公众号：大数据技术派，回复资料，领取1024G资料。指标体系指标建设过程中遇到的问题指标建设方法论指标的构成如何设立指标体系评价指标体系指标管理场景落地总结指标体系提起指标这个词，每个人似乎都可以说出几个指标，像经常在工作中会听到的日活、月活、注册率、转化率、交易量等

宽表的设计为什么要建设宽表宽表的好处和不足如何设计宽表总结宽表的设计其实宽表是数仓里面非常重要的一块，前面我们介绍过了维度表事实表，今天我们介绍一下宽表，前面我们说过了数仓是分层的，这是技术进步和时代变化相结合的产物，数仓的分层式为了更好地管理数仓以及更加高效地进行数据开发。宽表主要出现在dwd

前言技术如同手中的水有了生命似的，汇聚在了一起。为了方便大家学习与工作查询资料。现生成大数据命令文档供大家参考。本总结只列举常用的命令，比较多的命令操作。比如linux，kafka命令就比较多，hdfs操作也多。但是对于HBase.

之间的依赖关系，一定程度上，利用这种调度模型我们可以将过去需要拆分为多个作业的执行模式放到一个作业中来执行，比如上面提到的批流混合的作业。猜你喜欢Spark

…注意：保存数据的相关参数需写到上述方法中。如：textFile需传入加载数据的路径，jdbc需传入JDBC相关参数。例如：直接将df中数据保存到指定目录//默认保存格式为parquetscala>

强哥说他发现了财富密码，最近搞了一套股票算法，其中有一点涉及到股票连续涨停天数的计算方法，我们都知道股票周末是不开市的，这里有个断层，需要一点技巧。我问是不是时间序列，他说我瞎扯，我也知道自己是瞎扯。问他方法，他竟然不告诉我，这么多年的兄弟情谊算个屁。真当我没他聪明吗，哼！靠人不如靠自己，我决定连夜研究一下在Hive里面计算最大连续天数的计算方法。一、背景在网站平台类业务需求中用户的「最大登陆天数」，需求比较普遍。原始数据：u0001

time.一天大小的窗口，根据watermark机制一天触发计算一次，显然是不合理的，需要用trigger函数指定触发间隔为10s一次，这样我们的pv和uv就是10s更新一次结果。4.

RDD。如下示例，我们可以先对pairs采样10%的样本数据，然后使用countByKey算子统计出每个key出现的次数，最后在客户端遍历和打印样本数据中各个key的出现次数。val

这不是创新是什么？事实证明这种创新完全无用。没有任何一个投资人会把自己的钱投到一个可以被大公司拖拉拽出来的商业模式的。真正的创新不是现有能力的线性组合。「2.反人性」：中台自身的场景往往缺乏前瞻设计

服务器的内存都被缓存塞满的时候，我们发现不得不另想解决方案了。最直接的想法就是我们把这些缓存都丢到一个专门的服务器上吧，把它的内存配置的大大的。然后我们就盯上了redis。。。至于如何配置部署

要避免“写阻塞”，貌似让Flush操作尽量的早于达到触发“写操作”的阈值为宜。但是，这将导致频繁的Flush操作，而由此带来的后果便是读性能下降以及额外的负载。每次的Memstore

Queue，DLQ）中，工程团队将在该队列中对其进行手动分类。概念上讲，重试主题模式定义了失败的消息将被分流到的多个主题。如果主要主题的消费者消费了它无法处理的消息，它会将该消息发布到重试主题

年提出，主要功能仍是将组织透过资讯系统之联机事务处理（OLTP）经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，做有系统的分析整理，以利各种分析方法如联机分析处理、数据挖掘（Data

一个snapshot（快照）是一个全部文件系统、或者某个目录在某一时刻的镜像，使用vmware类似软件的同学指定，快照可以为虚拟机保存某个状态，如果做了更改，或者系统被折腾坏，还有个复原的操作。快照应用在如下场景中：防止用户的错误操作；备份：给hdfs目录做快照，然后复制快照里面的文件到备份；试验/测试灾难恢复HDFS的快照操作这里测试的Hadoop3.0版本，也是我的线上版本。开启快照hdfs

server.")FixMetaRegion在meta表和Regionserver中存在，但是在hdfs不存在。errors.reportError(ERROR_CODE.NOT_IN_HDFS,

group，默认为10000个值组成。每次读取文件是以行组为单位的，一般为HDFS的块大小，保存了每一列的索引和数据。在ORC文件中保存了三个层级的统计信息，分别为文件级别、stripe级别和row

关注公众号：大数据技术派，回复“资料”，领取资料，学习大数据技术。背景随着大数据技术的发展，HDFS作为Hadoop的核心模块之一得到了广泛的应用。为了数据的可靠性，HDFS通过多副本机制来保证。在HDFS中的每一份数据都有两个副本，1TB的原始数据需要占用3TB的磁盘空间，存储利用率只有1/3。而且系统中大部分是使用频率非常低的冷数据，却和热数据一样存储3个副本，给存储空间和网络带宽带来了很大的压力。因此，在保证可靠性的前提下如何提高存储利用率已成为当前HDFS面对的主要问题之一。Hadoop

有些时候需要我们去统计某一个hbase表的行数，由于hbase本身不支持SQL语言，只能通过其他方式实现。可以通过一下几种方式实现hbase表的行数统计工作:这里有一张hbase表test:test：hbase(main):009:0>

关注我，回复"资料"，获取大数据资料目录一般用法hive数据迁移Export/Import方式同步元数据总结数据迁移使用场景冷热集群数据分类存储,详见上述描述.集群数据整体搬迁.当公司的业务迅速的发展,导致当前的服务器数量资源出现临时紧张的时候,为了更高效的利用资源,会将原A机房数据整体迁移到B机房的,原因可能是B机房机器多,而且B机房本身开销较A机房成本低些等.数据的准实时同步.数据的准实时同步与上一点的不同在于第二点可以一次性操作解决,而准实时同步需要定期同步,而且要做到周期内数据基本完全一致.数据准实时同步的目的在于数据的双备份可用,比如某天A集群突然宣告不允许再使用了,此时可以将线上使用集群直接切向B的同步集群,因为B集群实时同步A集群数据,拥有完全一致的真实数据和元数据信息,所以对于业务方使用而言是不会受到任何影响的.hadoop

实时统计pv、uv是再常见不过的大数据统计需求了，前面出过一篇SparkStreaming实时统计pv,uv的案例，这里用Flink实时计算pv,uv。我们需要统计不同数据类型每天的pv，uv情况,并且有如下要求.每秒钟要输出最新的统计结果；程序永远跑着不会停,所以要定期清理内存里的过时数据；收到的消息里的时间字段并不是按照顺序严格递增的,所以要有一定的容错机制；访问uv并不一定每秒钟都会变化,重复输出对IO是巨大的浪费,所以要在uv变更时在一秒内输出结果,未变更时不输出；Flink数据流上的类型和操作DataStream是flink流处理最核心的数据结构，其它的各种流都可以直接或者间接通过DataStream来完成相互转换，一些常用的流直接的转换关系如图：可以看出，DataStream可以与KeyedStream相互转换，KeyedStream可以转换为WindowedStream，DataStream不能直接转换为WindowedStream，WindowedStream可以直接转换为DataStream。各种流之间虽然不能相互直接转换，但是都可以通过先转换为DataStream，再转换为其它流的方法来实现。在这个计算pv,uv的需求中就主要用到DataStream、KeyedStream以及WindowedStream这些数据结构。这里需要用到window和watermark，使用窗口把数据按天分割，使用watermark可以通过“水位”来定期清理窗口外的迟到数据，起到清理内存的作用。业务代码我们的数据是json类型的，含有date,version,guid这3个字段，在实时统计pv,uv这个功能中，其它字段可以直接丢掉，当然了在离线数据仓库中，所有有含义的业务字段都是要保留到hive当中的。其它相关概念就不说了，会专门介绍，这里直接上代码吧。

关注我，回复"资料"，获取大数据资料最近有个需求，实时统计pv,uv，结果按照date,hour,pv,uv来展示，按天统计，第二天重新统计，当然了实际还需要按照类型字段分类统计pv,uv,比如按照date,hour,pv,uv,type来展示。这里介绍最基本的pv,uv的展示。iduvpvdatehour11555993060532018-07-2718关于什么是pv,uv，可以参见这篇博客:https://blog.csdn.net/petermsh/article/details/786522461、项目流程日志数据从flume采集过来，落到hdfs供其它离线业务使用，也会sink到kafka，sparkStreaming从kafka拉数据过来，计算pv,uv，uv是用的redis的set集合去重，最后把结果写入mysql数据库，供前端展示使用。2、具体过程1）pv的计算拉取数据有两种方式，基于received和direct方式，这里用direct直拉的方式，用的mapWithState算子保存状态，这个算子与updateStateByKey一样，并且性能更好。当然了实际中数据过来需要经过清洗，过滤，才能使用。定义一个状态函数//

经常有同学问我，基于Hadoop生态圈的大数据组件有很多，怎么学的过来呢，毕竟精力有限，我们需要有侧重点，我觉得下面这几个组件至关重要，是基础组件，大部分人都需要会的，其它组件可以用的时候再去查查资料学习。hadoopHbaseHiveSparkFlinkKafkaHadoop是大数据的基础组件，很多组件都需要依赖它的分布式存储、计算；主要包括Hdfs、MR、Yarn三部分，这个需要找一些好的资料（我的主页有资料领取方法），好好学学各自的用法，熟练之后，需要了解其背后的原理。基本的，你得知道hadoop安装方法，cdh/hdp等等，启动后几个后台进程各自的作用，namenode高可用，以及高可用基于zk，namenode对元数据fs_image的保存，还有datanode，jobhistoryserver等。Hdfs：你需要知道文件的基本操作，命令跟Linux命令差不多，用的时候自然就有机会敲了，上传、下载，回收站，多副本容错（hadoop3的纠删码容错，不使用多副本了，可以节约空间），文件分布式存储的切分，文件存储格式，压缩等待；MR：主要是要掌握map

主要内容SparkSQL总体流程介绍在阐述Join实现之前，我们首先简单介绍SparkSQL的总体流程，一般地，我们有两种方式使用SparkSQL，一种是直接写sql语句，这个需要有元数据库支持，例如Hive等，另一种是通过Dataset/DataFrame编写Spark应用程序。如下图所示，sql语句被语法解析(SQL

跑各种定时任务分析数据，再通过可视化的查询，得到报表或者数据。架构的问题也是显而易见的：不能做到实时处理数据存在单点问题，比方某一条链路突然挂掉，此时整个环节都会出现问题2.2

once语义。flink-connector-kafka_2.111.7.0FlinkKafkaConsumerFlinkKafkaProducer>=1.0.0高版本向后兼容。但是，对于Kafka

这是以前的一次hbase集群异常事故，由于不规范操作，集群无法启动，在腾讯云大佬的帮助下，花了一个周末才修好，真的是一次难忘的回忆。版本信息cdh-6.0.1hadoop-3.0hbase-2.0.0问题想在空闲时候重启一下hbase释放一下内存，顺便修改一下yarn的一些配置，结果停掉后，hbase起不来了，错误信息就是hbase:namespace表is

watermarks）上面讲述了根据从事件数据中去获取时间戳设置水位线，但存在的问题是没有达到水位线时不管现实中的时间推进了多久都不会触发关窗，所以接下来我们就来介绍下定期水位线（Periodic

flink-window窗口在流处理应用中，数据是连续不断的，因此我们不可能等到所有数据都到了才开始处理。当然我们可以每来一个消息就处理一次，但是有时我们需要做一些聚合类的处理，例如：在过去的1分钟内有多少用户点击了我们的网页。在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行计算。Flink

数仓架构分层以阿里巴巴OneData建设为例：一般分为操作数据层（ODS：Operational

直入正题！Flink和Spark类似，也是一种一站式处理的框架；既可以进行批处理（DataSet），也可以进行实时处理（DataStream）。所以下面将Flink的算子分为两大类：一类是DataSet，一类是DataStream。DataSet一、Source算子1.

是一个可以容错且并行的数据结构(其实可以理解成分布式的集合，操作起来和操作本地集合一样简单)，它可以让用户显式的将中间结果数据集保存在内存中，并且通过控制数据集的分区来达到数据存放处理最优化。同时

viewCount;}TopN计算最活跃用户为了统计每个窗口下活跃的用户，我们需要再次按窗口进行分组，这里根据UserViewCount中的windowEnd进行keyBy()操作。然后使用

面试的高频考点；猜你喜欢Spark性能优化指南——高级篇Spark性能优化指南——基础篇数仓建模分层理论Hive中的集合数据类型Hive中的锁的用法场景Hive表的基本操作(必会)

Hive系列文章Hive表的基本操作Hive中的集合数据类型Hive动态分区详解hive中orc格式表的数据导入Java通过jdbc连接hive通过HiveServer2访问HiveSpringBoot连接Hive实现自助取数hive关联hbase表Hive

Spark性能优化指南——基础篇继基础篇讲解了每个Spark开发人员都必须熟知的开发调优与资源调优之后，本文作为《Spark性能优化指南》的高级篇，将深入分析数据倾斜调优与shuffle调优，以解决更加棘手的性能问题。调优概述有的时候，我们可能会遇到大数据计算中一个最棘手的问题——数据倾斜，此时Spark作业的性能会比期望差很多。数据倾斜调优，就是使用各种技术方案解决不同类型的数据倾斜问题，以保证Spark作业的性能。数据倾斜发生时的现象绝大多数task执行得都非常快，但个别task执行极慢。比如，总共有1000个task，997个task都在1分钟之内执行完了，但是剩余两三个task却要一两个小时。这种情况很常见。原本能够正常执行的Spark作业，某天突然报出OOM（内存溢出）异常，观察异常栈，是我们写的业务代码造成的。这种情况比较少见。数据倾斜发生的原理数据倾斜的原理很简单：在进行shuffle的时候，必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，比如按照key进行聚合或join等操作。此时如果某个key对应的数据量特别大的话，就会发生数据倾斜。比如大部分key对应10条数据，但是个别key却对应了100万条数据，那么大部分task可能就只会分配到10条数据，然后1秒钟就运行完了；但是个别task可能分配到了100万数据，要运行一两个小时。因此，整个Spark作业的运行进度是由运行时间最长的那个task决定的。因此出现数据倾斜的时候，Spark作业看起来会运行得非常缓慢，甚至可能因为某个task处理的数据量过大导致内存溢出。下图就是一个很清晰的例子：hello这个key，在三个节点上对应了总共7条数据，这些数据都会被拉取到同一个task中进行处理；而world和you这两个key分别才对应1条数据，所以另外两个task只要分别处理1条数据即可。此时第一个task的运行时间可能是另外两个task的7倍，而整个stage的运行速度也由运行最慢的那个task所决定。如何定位导致数据倾斜的代码数据倾斜只会发生在shuffle过程中。这里给大家罗列一些常用的并且可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。出现数据倾斜时，可能就是你的代码中使用了这些算子中的某一个所导致的。某个task执行特别慢的情况首先要看的，就是数据倾斜发生在第几个stage中。如果是用yarn-client模式提交，那么本地是直接可以看到log的，可以在log中找到当前运行到了第几个stage；如果是用yarn-cluster模式提交，则可以通过Spark

在大数据计算领域，Spark已经成为了越来越流行、越来越受欢迎的计算平台之一。Spark的功能涵盖了大数据领域的离线批处理、SQL类处理、流式/实时计算、机器学习、图计算等各种不同类型的计算操作，应用范围与前景非常广泛。在美团•大众点评，已经有很多同学在各种项目中尝试使用Spark。大多数同学（包括笔者在内），最初开始尝试使用Spark的原因很简单，主要就是为了让大数据计算作业的执行速度更快、性能更高。然而，通过Spark开发出高性能的大数据计算作业，并不是那么简单的。如果没有对Spark作业进行合理的调优，Spark作业的执行速度可能会很慢，这样就完全体现不出Spark作为一种快速大数据计算引擎的优势来。因此，想要用好Spark，就必须对其进行合理的性能优化。Spark的性能调优实际上是由很多部分组成的，不是调节几个参数就可以立竿见影提升作业性能的。我们需要根据不同的业务场景以及数据情况，对Spark作业进行综合性的分析，然后进行多个方面的调节和优化，才能获得最佳性能。笔者根据之前的Spark作业开发经验以及实践积累，总结出了一套Spark作业的性能优化方案。整套方案主要分为开发调优、资源调优、数据倾斜调优、shuffle调优几个部分。开发调优和资源调优是所有Spark作业都需要注意和遵循的一些基本原则，是高性能Spark作业的基础；数据倾斜调优，主要讲解了一套完整的用来解决Spark作业数据倾斜的解决方案；shuffle调优，面向的是对Spark的原理有较深层次掌握和研究的同学，主要讲解了如何对Spark作业的shuffle运行过程以及细节进行调优。本文作为Spark性能优化指南的基础篇，主要讲解开发调优以及资源调优。调优概述Spark性能优化的第一步，就是要在开发Spark作业的过程中注意和应用一些性能优化的基本原则。开发调优，就是要让大家了解以下一些Spark基本开发原则，包括：RDD

Hive系列文章Hive表的基本操作Hive中的集合数据类型Hive动态分区详解hive中orc格式表的数据导入Java通过jdbc连接hive通过HiveServer2访问HiveSpringBoot连接Hive实现自助取数hive关联hbase表Hive

Hive系列文章Hive表的基本操作Hive中的集合数据类型Hive动态分区详解hive中orc格式表的数据导入Java通过jdbc连接hive通过HiveServer2访问HiveSpringBoot连接Hive实现自助取数hive关联hbase表Hive

分析型数据仓库应用。加我微信：ddxygq，来一场朋友圈的点赞之交！猜你喜欢数仓建模分层理论数据湖是谁？那数据仓库又算什么？数仓架构发展史Hive整合HbaseHive中的锁的用法场景数仓建模方法论

Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。FIFO

值的快速查询能力，没法进行大量的条件查询。现有hbase的查询工具有很多如：Hive，Tez，Impala，Shark/Spark，Phoenix等。今天主要说Hive，Hive方便地提供了Hive

Spark内核概述Spark内核泛指Spark的核心运行机制，包括Spark核心组件的运行机制、Spark任务调度机制、Spark内存管理机制、Spark核心功能的运行原理等，熟练掌握Spark内核原理。一、Spark核心组件回顾DriverSpark驱动器节点，用于执行Spark任务中的main方法，负责实际代码的执行工作。Driver在Spark作业执行时主要负责：1、将用户程序转化为任务（Job）；2、在Executor之间调度任务（task）；3、跟踪Executor的执行情况；4、通过UI展示查询运行情况。ExecutorSpark

row_number前面我们介绍窗口函数的时候说到了窗口函数的使用场景，我们也给它起了一个名字进行区分，通用窗口函数和特殊窗口函数，今天我们就来看一下排序相关的窗口函数，因为是窗口函数，并且我们说它是用来排序的，我们大概也能猜到它就是用来对窗口内的数据进行排序的其实关于排序我们前面也介绍过order

by会对输入做全局排序，因此只有一个Reducer(多个Reducer无法保证全局有序)，然而只有一个reducer，会导致当输入规模较大时，消耗较长的计算时间。降序：desc升序：asc

里面的一些方法的使用规则，至于代码设计的好坏以及还有什么改进的方案我们后面再说，下面两套实现的思路几乎是一致的，不一样的是在使用的分词工具上的不一样ansj的实现/**

管理，数据权限管理，能否做到统一，在架构上实现统一后，我们在应对实时需求时，可以将实时离线的冗余程度降到最低，甚至能够做到几乎没有多余成本。这块我们也在积极探索，国内互联网公司的主流做法还是停留在

作为存储引擎，为流式数据存储提供统一的抽象，使得对历史和实时数据有一致的访问方式。两者统一形成了从存储到计算的闭环，能够同时应对高吞吐的历史数据和低延时的实时数据。同时

ODS_业务系统_表名_标记，这样的设计可以保持与业务表名一致，又可以有清晰的层次，还可以区分来源。标记一般指的是其他数仓特有的属性，例如表是天级的还是小时的，是全量的还是增量的。ods