之乎者也·的博客

一种基于数据治理的大数据中台架构系统，包括：数据接入模块，用于接入企业需要进行治理的数据源，并将接入的需要进行治理的数据源发送给数据湖仓模块；数据湖仓模块，用于根据接入数据的字段结构，在数据湖和数据仓库中创建数据模型，存储采集到的数据；数据治理模块，用于按预设规则对接入到数据湖仓的数据进行统一治理，向数据访问模块和数据应用模块输出高质量的数据资产和主数据；数据访问模块，用于接收数据治理平台治理好的高质量资产和主数据，并提供多种方式供内外部客户使用；

首先，我们需要理解什么是向量？向量是基于不同特征或属性来描述对象的数据表示。每个向量代表一个单独的数据点，例如一个词或一张图片，由描述其许多特性的值的集合组成。这些变量有时被称为“特征”或“维度”。例如，一张图片可以表示为像素值的向量，整个句子也可以表示为单词嵌入的向量。一些常用的数据向量如下：图像向量，通过深度学习模型提取的图像特征向量，这些特征向量捕捉了图像的重要信息，如颜色、形状、纹理等，可以用于图像识别、检索等任务；

数据质量管理是数据仓库建设中至关重要的一环。通过对数据质量的评估和提升，可以确保数据的准确性、一致性和完整性，提高数据的可信度和可用性。数据质量管理体系和相关策略与技术能够帮助企业构建可持续的数据质量管理机制，为企业决策和运营提供有力的支持。

分配对主数据负责的数据或域所有者。因此，可以为主数据引入和定义数据治理角色，从而实现数据所有权和问责制的文化，然后可以在整个组织中扩展，从而确保数据治理实践的一致性。这不应该是可选的——如果有掌握的数据，那么对于任何使用这些数据的人来说，它的消费应该是强制性的。它提供了一种全面的方法，可以为关键业务实体建立可靠的事实来源，构建强大的数据治理框架，并推动各种数据管理功能的成熟度。围绕 MDM 解决方案和掌握的数据，建立了基础治理，包括通过定义一组策略和标准来概述对 MDM 的一般期望，以及特定的角色和职责。

在 MapReduce 流行这些年之后，针对大数据集的已经逐渐成熟。到现在（2017年）已经有比较成熟的基础设施可以在上千台机器上处理 PB 量级的数据。因此，针对这个量级的可以认为已经被解决，大家的注意力开始转到其他问题上：完善编程模型提升处理性能扩大处理领域之前我们讨论过，由于 MapReduce 提供的编程接口实在太过难用，像 Hive， Pig，Cascading 和 Crunch 等处理 API 和框架逐渐流行。Apache Tez 更进一步，可以让原来的代码不做过多改动就可以迁移。

该层使用DWD层数据，维度数据，对业务上有关联的实体做连接，形成统一粒度的，跨业务流程的，多业务实体的，轻度汇总数据。数仓主要包含ODS/DWD/DWS/DIM/DM几个标准化的分层，同时结合企业实际的情况，如补录的数据，在数据ETL过程中的临时处理数据等，根据用途汇总为贴源层、数据共享层、数据服务层。层数据，保留业务实体的原子粒度，并且通过数据清洗和一定程度的数据转换，保障数据质量。数据的完整性，包括实体的完整性（分段的业务表），数据行的完整性（不同阶段的业务周期的汇集），字段的完整性（关键业务字段）

CDC 的全称是（变更数据捕获） ，在广义的概念上，只要是能捕获数据变更的技术，我们都可以称之为 CDC。目前通常描述的 CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。CDC 技术的应用场景非常广泛：数据同步：用于备份，容灾；数据分发：一个数据源分发给多个下游系统；数据采集：面向数据仓库 / 数据湖的 ETL 数据集成，是非常重要的数据源。CDC 的技术方案非常多，目前业界主流的实现机制可以分为两种：基于查询的 CDC：离线调度查询作业，批处理。

在源数据装入这一层时，要进行诸如去噪（例如有一条数据中人的年龄是 300 岁，这种属于异常数据，就需要提前做一些处理）、去重(例如在个人资料表中，同一 ID 却有两条重复数据，在接入的时候需要做一步去重)、字段命名规范等一系列操作。这层的数据是后续数据仓库加工数据的来源。DWS 数据服务层 Data Warehouse Service，DWS(宽表-用户行为，轻度聚合)该层是基于DWM上的基础数据，整合汇总成分析某一个主题域的数据服务层，一般是宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

HTAP是混合 OLTP 和 OLAP 业务同时处理的系统 ，2014年Garnter公司给出了严格的定义：混合事务/分析处理(HTAP)是一种新兴的应用体系结构，它打破了事务处理和分析之间的“墙”。钻取：是改变维的层次，变换分析的粒度。OLTP (TP) On-Line Transaction Processing 联机事务处理过程(OLTP) 也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。

在 Flink CDC 1.x 版本中，如果想实现 exactly-once 同步，需要配合 Flink 提供的 checkpoint 机制,全量阶段没有做切片，则只能在一个 checkpoint 里完成，这会导致一个问题：每个 checkpoint 中间要将这张表的全量数据吐给下游的 writer，writer 会将这张表的全量数据混存在内存中，会对其内存造成非常大的压力，作业稳定性也特别差。保障实时性，因为类似 binlog 的日志文件是可以流式消费的，提供的是实时数据。链路短，组件少，运维友好。

数据分层在数据仓库设计中扮演着关键角色，合理的分层设计有助于使整个数据体系更易于理解和使用。然而，目前网络上关于数据分层设计的文章大多只是简单提及，或者缺乏明确而详细的说明，亦或者缺乏可实际实施的方案和具体的示例说明。因此，本文旨在提供一种通用的数据仓库分层方法，具体包括以下内容：1、介绍数据分层的作用。2、提出一种通用的数据分层设计，并明确分层设计的原则。3、通过具体的例子进行说明。4、提出可实际实施的实践建议。接下来，我们将详细讨论这些内容。

企业应该明确主数据管理的原则和方法，充分考虑各类主数据的划分和标准化，选择合适的主数据开发工具和平台，并在实际应用中进行积极推进主数据使用，以此优化主数据质量、共享和使用价值。主数据（Master Data）指的组织中需要跨系统、跨组织共享的核心业务实体数据，是一个组织中最重要、最核心的数据，是单一、准确、权威的数据来源，是组织运行过程中不可或缺的一部分，一般包括组织信息、人员信息、会计科目、银行账户、客户信息、供应商信息、产品信息等。企业可以根据业务实体来确定主数据，例如客户、供应商、产品、设备等。

事业部的成本负责人，领到今年的预算目标，需对目标进行拆分，具体到今年要完成的治理优化数量，同时成本负责人向预算委员会，汇报治理工作的进展。事业部的负责人将拆分后的优化目标派发给各个团队的成本治理接口人，治理接口人根据治理目标，拆分出治理任务，将治理任务分配给资源的归属人，由其完成治理动作。此外，还有维护该产品，所消耗的人力维护成本，这四大块构成了产品的总成本。接下来就可以开展成本治理的工作，基础是元数据的接入，再对元数据进行清洗加工，得到待治理的资源列表，将其打包形成治理工单，通过治理工作台跟踪治理进展。

在基于列式存储的数据库中， 数据是按照列为基础的逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在。常见的 TP 库，如 Oracle、DB2、MySQL、SQL SERVER 等采用行式存储法(Row-based)，在基于行式存储的数据库中， 数据是按照行数据为基础逻辑存储单元进行存储的， 一行中的数据在存储介质中以连续存储形式存在。数据读取时，行存储通常将一行数据完全读出，如果只需要其中几列数据的情况，就会存在冗余列，出于缩短处理时间的考量，消除冗余列的过程通常是在内存中进行的。

业务标准规范：按照政务数据共享交换的纲领，总体设计思路严格遵守政务数据共享交换的规范化、标准化原则。遵循国家政务信息资源管理、交换、共享有关标准及国家政策要求。按照系统建设标准与规范设计设计数据内容、数据分类与编码、精度与标准等。建立统一的技术架构：统一的技术路线、统一的产品支撑、统一的技术支撑、统一的业务支撑，为应用系统提供多层面的支撑架构。建立统一的、标准化的应用集成架构，以约束不同开发商的应用服务接口开发。

数字化转型浪潮卷起各种新老概念满天飞，数据湖、数据仓库、数据中台轮番在朋友圈刷屏，有人说“数据中台算个啥，数据湖才是趋势”，有人说“再见了数据湖、数据仓库，数据中台已成气候”……企业还没推开数字化大门，先被各种概念绊了一脚。那么它们 3 者究竟有啥区别？别急，先跟大家分享两个有趣的比喻。1、图书馆VS地摊如果把数据仓库比喻成“图书馆”，那么数据湖就是“地摊”。去图书馆借书（数据），书籍质量有保障，但你得等，等什么？等管理员先查到这本书属于哪个类目、在哪个架子上，你才能精准拿到自己想要的书；

基于上下游Operator的并行度，将记录以循环的方式输出到下游Operator的每个实例。举例: 上游并行度是2，下游是4，则上游一个并行度以循环的方式将记录输出到下游的两个并行度上;上游另一个并行度以循环的方式将记录输出到下游另两个并行度上。若上游并行度是4，下游并行度是2，则上游两个并行度将记录输出到下游一个并行度上；这种分区器会根据上下游算子的并行度，循环的方式输出到下游算子的每个实例。下游并行度为4，编号为1，2，3，4。假设上游并行度为4，编号为A，B，C，D。下游并行度为2，编号为1，2。

与Per-Job-Cluster的区别：就是Application Mode下, 用户的main函数式在集群中执行的，并且当一个application中有多个job的话，per-job模式则是一个job对应一个yarn中的application，而Application Mode则这个application中对应多个job。一个Job会对应一个Flink集群，每提交一个作业会根据自身的情况，都会单独向yarn申请资源，直到作业执行完成，一个作业的失败与否并不会影响下一个作业的正常提交和运行。

近几年大数据概念太多了，数据库和数据仓库还没搞清楚，就又出了数据湖，现在又说什么“湖仓一体”。乙方公司拼命造概念，甲方公司不管三七二十一，吭哧吭哧花钱搞数据建设。到头来发现，钱也花了，人力也投入了，但最基本的业务需求都解决不了。这篇就专门来解释一下数据库、数据仓库、数据湖、湖仓一体到底都是什么以及怎么用。什么是数据库？可以把数据库理解为一个虚拟的图书馆，每一本书都代表了一个数据记录，而书架和分类系统则对应数据库和表格和索引，读者可以快速查找和管理所需要的信息。

假设 NameNode1 当前为 Active 状态，NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFailoverController 进程发生了“假死”现象，那么 Zookeeper 服务端会认为 NameNode1 挂掉了，根据前面的主备切换逻辑，NameNode2 会替代 NameNode1 进入 Active 状态。

首先以流量这一业务场景来介绍一下我们现在的业务形态。流量实时实时流量数据的全量化分析，实时的流量概览，实时流量 PV/UV，流量的来源去向。流量概览以天/周/月粒度任意维度组合进行流量分析的离线数据，如有效用户数、成交用户数，我们都会进行全维度的分析。全维度的分析，不可能对所有的场景都做预计算，必然有大量的场景是进行极速的 OLAP 来计算。流量的来源去向我们假定从其他方面购买的流量，包括首次来源、末次来源，流向的分析，如用户从一个店铺跳转到另外一个店铺的趋向分析，流量的衰减，以及当中的一些购买的一些数据的

Hadoop 的诞生改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，受到广泛的应用，给整个行业带来了变革意义的改变；随着云计算时代的到来， 存算分离的架构受到青睐，企业开开始对 Hadoop 的架构进行改造。今天与大家一起简单回顾 Hadoop 架构以及目前市面上不同的存算分离的架构方案，他们的利弊各有哪些，希望可以给正在存算分离架构改造的企业一些参考和启发。

而大数据因为数据计算量很大，会利用数据本地性加速任务的运行。这里以一个spark任务的执行为例，用户在Tenant集群提交一个Spark任务，在k8s集群上会启动了一个 driver pod，然后调度器会根据与该Tenant相关的所有物理集群负载情况进行调度，接着Syncer会把这个pod同步到物理集群上，物理资源启动以后会Pod status反向同步到Tenent，同时driver连接的API Server也会修改到Tenent的API master上，最后新申请的Executor Pod。

至此已经获得数据标准模型，针对标准模型进一步Workflow异常检测流程，同时平台维护着一套沉淀多年的数据治理知识库，加载知识库到标准模型，通过启发式规则，对标准模型的指标数据、日志同时进行异常挖掘，结合集群状态及运行是环境状态，分析得出工作流层、引擎层异常结果；存储、分析数据，提供给用户任务概览、工作流层任务诊断、引擎层作业Application诊断，工作流层展示调度器执行任务引发的异常，如任务失败、回环任务、基线偏离任务等问题，计算引擎层展示Spark作业执行引发的耗时、资源使用、运行时问题；

TIPS:设置HDFS的文件副本数，默认为3，当许多任务同时读取一个文件时，读取可能会造成瓶颈，增大副本数可以有效缓解，但也会造成大量的磁盘空间占用，这时可以只修改Hadoop客户端的配置，从Hadoop客户端上传的文件的副本数以Hadoop客户端的设置为准。TIPS：对于普通机器来书，文件访问时间可以让用户知道文件的近期查看和修改，但是对于HDFS没有意义，因为HDFS不支持修改，如果不禁用，在每次读取文件的时候还有伴随进行一次写操作，这些开销是浪费时间的，因此在挂在数据分区时，禁用文件的访问时间。

hadoop中HDFS要存储数据，这些数据存储的目录地址，默认值为：/tmp/hadoop-${user.name}，如下图2所示为默认值，在本环境 Linux系统里面是指：/tmp/hadoop-zola，但是 /tmp 目录是1个临时目录，一般Linux系统1个月清理一次。集群完成配置后，在启动集群之前，还需要 配置workers节点 ，集群中有几个节点， /opt/module/hadoop-3.1.3/etc/hadoop/workers配置文件里面对应的就配置几个主机名称。

将 Hadoop 安装目录配置文件目录 /opt/module/hadoop-3.1.3/etc/hadoop/ 下的 xml 配置文件复制到 input。单机运行，数据存储在 HDFS ，由 Hadoop 的 HDFS 组件自己来管理存储的数据，具备Hadoop集群所有功能，1台服务器模拟1个分布式的环境。（3）执行 /opt/module/hadoop-3.1.3/share/ 目录下的。（4）执行 /opt/module/hadoop-3.1.3/share/ 目录下的。

MapReduce 是一种编程模型（没有集群的概念，会把任务提交到 yarn 集群上跑），用于大规模数据集（大于1TB）的并行运算。概念"Map（映射）"和"Reduce（归约）"，是它们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。

Apache Yarn（Yet Another Resource Negotiator的缩写）是hadoop集群资源管理器系统，Yarn从hadoop 2引入，最初是为了改善MapReduce的实现，但是它具有通用性，同样执行其他分布式计算模式。

虽然hadoop的生态体系已经有好多年了，而且越来越多的做大数据的可能会觉得hadoop体系在数据处理方面有一些笨重，但是作为大数据的分布式系统领域的鼻祖，我们还是好好学习一下。Hadoop体系最初建立于2005年，是由Doug Cutting和Mike Cafarella开发的。它的设计灵感来自于Google的MapReduce和Google File System（GFS）的论文。Hadoop可以说是大数据分布式系统领域的开创者。

前面已经介绍了几乎企业里使用到的绝大多数大数据组件了，这里来个简单的总结，主要针对常见的操作进行总结。也方便自己和大家在工作中快速查阅。

大数据（big data），指的是在一定时间范围内不能以常规软件工具处理（存储和计算）的大而复杂的数据集。说白了大数据就是使用单台计算机没法在规定时间内处理完，或者压根就没法处理的数据集。

一个Reduce任务中的每一次处理均是针对所有键相同的数据，对数据进行规约，形成新的键值对。Secondary NameNode用于备份NameNode的数据，周期性地将edits文件合并到fsimage文件并在本地备份，然后将新的fsimage文件存储至NameNode，覆盖原有的fsimage文件，删除edits文件，并创建一个新的edits文件继续存储文件当前的修改状态。在Map阶段，数据将以键值对的形式被读入，键的值一般为每行首字符与文件最初始位置的偏移量，即中间所隔字符个数，值为该行的数据记录。

Hadoop分布式文件系统（HDFS）：HDFS是Hadoop的主要存储系统。它设计用于处理大量数据，并通过在集群中的多台机器之间复制数据来提供容错能力。

SparkSQL的前身是Shark，给熟悉RDBMS但又不理解MapReduce的技术人员提供快速上手的工具，hive应运而生，它是当时唯一运行在Hadoop上的SQL-on-hadoop工具。

1.保留表的谓词写在join中不能下推，需要用where；2.空表的谓词写在join之后不能下推，需要用on；3.在 join关联情况下，过滤条件无论在join中还是where中谓词下推都生效；4.在full join关联情况下，过滤条件无论在join中还是where中谓词下推都不生效。

相比 TEXTFILE 和 SEQUENCEFILE，RCFILE 由于列式存储方式，数据加载时性能消耗较大，但是具有较好的压缩比和查询响应。数据仓库的特点是一次写入、多次读取，因此，整体来看，

当进行Hive表的insert和update等更新操作时，相应的分区信息在metastore中更新，而前面提到的使用hdfs命令操作时，Hive的MetaStore元数据信息。： 基于预处理结果，根据GroupBy的 Key 分布到 Reduce 中，这过程保证相同的GroupBy Key被分布到同一个Reduce中，最后完成最终的聚合操作。，是一个高效地将小文件放入HDFS块中的文件存档工具。hive 中的小文件常发生于 hive 表中导入数据后，先看下 hive 导入数据的几种方式。

在数据量不大的情况下，Hive迁移一般常用的方式是使用Export、Import进行数据和元数据的导出导入，Export会将数据和元数据写到一起，并且元数据在恢复时是直接关联数据的，不需要再做其他的操作。一般在企业进行数据库改造、历史数据库区域创建、业务条线改造等，或是数据库出现瓶颈的情况下，会进行部分数据迁移，那么此时Hive迁移建议使用表和数据分步迁移的方式进行迁移。Hive的数据迁移其实有多种方式，根据需求不同采用的迁移方式也不尽相同，每种迁移的优势也是不同的，其中数据量是影响迁移的重要因素之一。

方案2是通过引入路由层，使用代理转发请求的方式来实现。总结一下，方案2的优点在于对Hive 没有侵入性，升级版本比较容易，可以灵活定制Router层策略，HA水平扩容，扩容MySQL时相对影响较小，上线风险较小，统一元数据入口，方便审计和溯源；其次，在HIVE的元数据查询上，存在大量的多表联合查询，尤其存储分区信息的两个大表（PARTITONS和PARTITION_KEY_VALS）之间的联合查询，会对服务带来很大压力，可能导致查询超时以及慢查询等问题，因此第二个优化方向是优化元数据API调用；