数据底座和wdp介绍及技术要点
# 数智方法论
# 4One理论
- OneData：统一数据集成开发，在阿里在线化，集约化OneData理念的基础上，形成在线化、集约化、标准化、流程化、自动化的HJOneData体系，实现垂直化数据接入和智能化数据加工；
- OneID+：统一数据ID与视图，在阿里用户ID萃取的基础上，形成人，物，事等各种业务关注对象的ID统一，信息集约的oneID+体系，实现智能化数据融合和价值化数据资产管理。
- OneService：统一数据服务，在阿里所有数据在线服务化的基础上，形成在线服务与送货到家两种服务模式，实现超市化数智服务和便捷化数智应用。
- OneResource：统一资源管理、统一数智服务、统一安全管控，同时对内、外进行均质化的数智服务，弹性的资源分配与使用。
# 数智方法论【核心】
基于数据中台4One理念，结合HJ科技多年的的行业数据中台实践经验，总结出面向政企行业的数据实施方法论，从客户价值场景出发，通过数据中台顶层规划、制定数据标准体系、厘清数据资源家底、智能化数据加工、价值化数据资产、超市化数据服务、便捷化数据应用助力企业实现业务数据化、数据智能化，帮助企业解决数据利用过程中的存、管、通、用存在的问题。
# 搭架子：数据中台顶层规划
融合阿里巴巴数智经济建设标杆和HJ科技丰富的ICT信息化转型实践形成数智化转型4One理论，为政企客户提供贴身的数字化转型顾问咨询服务，以“全局视角贯通全业务环节，突破原有业务边界，数智驱动业务协同及业务创新，促进企业经营、管理效率和效益的提升”为目标，从战略层面进行中台战略的整体规划和设计，帮助政企客户稳步推进数字化转型：
- 中台战略规划：建设企业数据中台，实现数据驱动业务运营，助力企业数字化转型和创新；
- 业务需求规划：面向一线业务运营部门，调研真实业务场景的业务痛点及数据需求点， 发现数据分析价值点；面向信息化部门，对应用系统及数据资源现状，以及数据分析、应用需求等场景内容调研，规划企业数智应用蓝图。
- 数据资源规划：基于业务场景中数据使用情况，评估数据分析／应用成熟度，对数据上云系统的数据质量、数据完整性进行梳理和盘点，规划企业数智中台数据架构和数据上云设计。
- 技术资源规划：对企业现有技术现状进行调研，包括软硬件及网络基础设施、技术架构、技术自研、组件运维等情况，规划企业数智中台技术架构设计和技术选型。
- 运营资源规划：对企业信息化组织架构、管理规范、运营流程、日常工作等进行调研，评估企业运营能力，规划设计企业数智中台运营体系蓝图。
# 定标准：制定数据标准体系
正所谓没有规矩不成方圆，在明确了数据中台的顶层规划纲领后，需要通过建立完善的企业数据标准体系，为后续的数据治理实施工作明确方向，保驾护航。企业数据标准包括如下内容：
- 数据中台运营管理规范：主要包括组织架构、运营流程和制度体系标准。
- 数据中台应用管理规范：主要包括数据价值、数据应用和数据开放标准。
- 数据中台数据管理规范：主要包括数据采集、数据架构和数据质量标准。
- 数据中台技术管理规范：主要包括技术选型和数据开发标准。
- 数据中台安全管理规范：主要包括生命周期、管控分级和脱敏实施标准。
# 清家底：数据资源规划及厘清
实施数据治理和建设数据中台，需要厘清企业数据资源家底，掌握企业当前数据资源的详实状况，明确企业的数据种类、未来可能获取的数据种类，以及这些数据的数据量、数据价值、数据用途等，并制定相应的数据采集策略。
- 数据盘点：明确数据类型和分类，数据来源归类整理。
- 数据价值：确定数据量和存储空间，分析数据质量和价值。
- 数据用途：梳理数据关联关系，明确数据应用方向。
- 数据采集：梳理数据采集范围、内容和接口方式。
基于企业数据资源的实际情况，按照分层设计理念，从建立标准化、归一化的基础模型到汇总层基本的业务抽象，然后建立可供上层调用的共性数据如指标集、标签集等的宽表层，最终形成面向业务应用专题的数据展现层。这种自下而上的分层数据总体框架设计，保证了逻辑模型的全面性和完整性；然后通过自上而下的方式，从各个子系统的应用中收集应用指标，然后将这些指标进行归类和去重，同时从另一个途径通过数据源接口，从数据源平台获取数据信息，在企业级概念模型设计角度进行概念模型设计，最后结合概念模型和整理的指标进行逻辑模型的设计，这种指标和概念模型相结合的方式进行逻辑模型的设计，可以保证模型对应用具有足够的支撑力度。
# 智能化数据加工
企业数据中台的的建设，有几点必须遵循的原则：
- 首先，是业务数据的全量采集，即应用端需要的所有业务系统的数据都需要统一的采集到数据中台的垂直数据中心然后进行统一的数据加工和处理，这个原则从一定程度解决了数据烟囱的问题。
- 其次，数据的加工和处理需要遵循OneData体系的规范，即首先将各业务数据根据，业务主题划分为不同高的数据域，业务过程等，然后进行各个数据域的维度指标定义，而整个派生指标的定义又进一步按照维度，业务过程，业务修饰词等清晰的定义。这个原则从很大程度上解决了指标的不一致问题。
- 再次，为保证数据中台完成全量的采集和遵循一定的规范，并能够让数据中台可以支撑好上层的数据应用，整个数据中台的构建，需要使用统一的工具和服务。
- 最后，数据中台支撑的数据应用效果，需要回流到数据中台，做到业务和数据的闭环。
# 价值化数据资产
按照“定标准、强管控、理资源、重运营”的数据资产管理理念，打造持续优化的数据管理环境。通过制定相关系统标准，管理规范和流程，并提供相应的管理工具和流程，对标准的实施过程和效果进行事前管理、事中监控和事后评估，为IT系统建设规范性提供保障，并构建持续优化的机制。
构建一体化全流程的数据管理体系，制定数据管理标准和数据管理流程，通过数据规范和数据处理的有机融合，来帮助企业合理评估、规范和治理企业信息资产，挖掘和发挥数据资产价值并促进持续增值；通过对数据的有效管控，全面提升企业的数据质量，增强数据对上层业务的支撑能力，为公司内外部决策提供数据依据，并且通过加强数据资产和运营效率管理，提升企业价值。
# 超市化数据服务
以电商、商品化思维，构建互联网化的数据及资源超市，采用多租户机制及敏感数据脱敏管控等，实现企业内部大数据平台存储资源和计算资源共享以及数据资源共享，推动数据应用快速建设。面向管理人员提供一站式的数据汇聚及数据管理能力，实现数据的可视化管理和监控；面向业务应用人员提供一站式的数据视图和数据应用能力，支撑业务人员灵活个性化的数据申请使用。
# 便捷化数据应用
指标体系梳理和自助分析：帮助企业快速梳理现有指标情况，清晰掌握指标全局，构建指标综合管理平台有效支持企业持续建设管理指标。
数据可视化及价值化传播：提供完整的数据大屏定制方案，包括大屏样式设计、数据指标整理咨询、数据链接与开发、大屏部署和落地，能够满足大部分业务监控和各类展示类场景的需求。
数据产品落地及运营赋能：对外：基于商业模式规划大数据应用场景；对内：基于价值链规划大数据应用场景。
# 数据底座
# 总括分析
大数据具有数据体量大、数据类型多、数据处理速度要求高和数据价值密度低的特点，传统数据分析系统架构（RDBMS+小型机+高端阵列模式）已经无法支持TB级别海量数据的分析处理需求。针对当前企业、政府等组织机构数据种类繁多、数据处理复杂的情况，不合适采用单一的技术解决全部问题，公司基于Hadoop技术生态体系，自研鲸智基础平台，采用Hadoop+MPP混搭技术架构实现海量业务数据的安全可靠存储；结合实际业务需求采用Spark实现海量数据的离线计算，满足各行各业、各种复杂业务场景下的数据处理需求。
基础平台由平台管理、数据存储、离线计算等部分组成：
- **平台管理：**由Yarn、ZooKeeper、Kerberos、Sentry或Ranger等组件构成，提供包括资源调度、安全认证等大数据平台的管理功能；
- **数据存储：**采用Hadoop+MPP混搭技术架构实现海量业务数据的安全可靠存储，基于实际业务需求可以灵活选择HDFS、Hbase、Hive、Redis、Elasticsearch、MPP等数据存储组件来构建企业数据集市；
- **离线计算：**离线批量计算框架基于MapReduce和Spark为基础构建，提供海量离线数据的批处理计算能力。
# 平台管理
# 分布式资源调度YARN
Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
YARN最初是为了修复MapReduce实现里的明显不足，并对可伸缩性（支持一万个节点和二十万个内核的集群）、可靠性和集群利用率进行了提升。YARN实现这些需求的方式是，把Job Tracker的两个主要功能（资源管理和作业调度/监控）分成了两个独立的服务程序——全局的资源管理（RM）和针对每个应用的应用 Master（AM），这里说的应用要么是传统意义上的MapReduce任务，要么是任务的有向无环图（DAG）。
YARN从某种那个意义上来说应该算做是一个云操作系统，它负责集群的资源管理。在操作系统之上可以开发各类的应用程序，例如批处理MapReduce、流式作业Storm以及实时型服务Storm等。这些应用可以同时利用Hadoop集群的计算能力和丰富的数据存储模型，共享同一个Hadoop 集群和驻留在集群上的数据。此外，这些新的框架还可以利用YARN的资源管理器，提供新的应用管理器实现。
# 分布式协调器ZooKeeper
ZooKeeper是一个分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。ZooKeeper包含一个简单的原语集，提供Java和C的接口。
# Kerberos安全认证
Kerberos实现的是机器级别的安全认证，也就是前面提到的服务到服务的认证问题。事先对集群中确定的机器由管理员手动添加到Kerberos数据库中，在KDC上分别产生主机与各个节点的keytab(包含了host和对应节点的名字，还有他们之间的密钥)，并将这些keytab分发到对应的节点上。通过这些keytab文件，节点可以从KDC上获得与目标节点通信的密钥，进而被目标节点所认证，提供相应的服务，防止了被冒充的可能性。
解决服务器到服务器的认证
由于Kerberos对集群里的所有机器都分发了keytab，相互之间使用密钥进行通信，确保不会冒充服务器的情况。集群中的机器就是它们所宣称的，是可靠的。
防止了用户伪装成Datanode，Tasktracker，去接受JobTracker，Namenode的任务指派。
解决Client到服务器的认证
Kerberos对可信任的客户端提供认证，确保他们可以执行作业的相关操作。防止用户恶意冒充client提交作业的情况。
- 用户无法伪装成其他用户入侵到一个HDFS 或者MapReduce集群上；
- 用户即使知道DataNode的相关信息，也无法读取HDFS上的数据；
- 用户无法发送对于作业的操作到JobTracker上；
- 对用户级别上的认证并没有实现；
- 无法控制用户提交作业的操作。不能够实现限制用户提交作业的权限。不能控制哪些用户可以提交该类型的作业，哪些用户不能提交该类型的作业；
# 数据存储
# 分布式文件系统HDFS
HDFS（Hadoop Distributed File System）是一种分布式文件系统，其运行在普通硬件上，它与现有的分布式文件系统有许多相似之处。然而HDFS与其他分布式文件系统的区别是显著的。HDFS具有很高的容错能力，被设计成部署在低成本的硬件上。HDFS提供了对应用数据的高吞吐量访问，适合大数据集的应用。HDFS放松了一些POSIX要求，以支持对文件系统数据的流访问。HDFS最初是Apache Nutch web搜索引擎项目的基础设施。HDFS是Apache Hadoop核心项目的一部分。
HDFS有如下特点：
硬件故障
我们知道：硬件故障是常态，而不是异常。一个HDFS实例可能由成百上千个服务器机器组成，每个服务器是存储文件系统数据的一部分。Hadoop有大量的组件，而且每个组件都有很大的失败概率，这意味着HDFS的某些组件总是没有功能。因此，检测故障并快速、自动地从故障中恢复是HDFS的核心架构目标。
流媒体数据访问
运行在HDFS上的应用程序需要流式访问它们的数据集。它们不是通常运行在通用文件系统上的通用应用程序。HDFS更适合批处理，而不是用户交互使用。其特点是数据访问的高吞吐量，而不是数据访问的低延迟。POSIX强加了许多硬性要求，这些要求对于以HDFS为目标的应用程序来说是不需要的。
大型数据集
运行在HDFS上的应用程序有大量的数据集。HDFS中的一个典型文件的大小是可以是GB甚至TB级别。因此，HDFS被调优以支持大文件。它提供了高聚合数据带宽，在单个集群中可以扩展到数百个节点，在一个实例中支持数千万个文件。
简单的一致性模型
HDFS应用程序需要对文件使用“write-once-read-many”访问模型。创建、写入和关闭文件后，除了追加和截断外，不需要更改文件。支持将内容附加到文件的末尾，但不能在任意点进行更新。这种假设简化了数据一致性问题，并支持高吞吐量的数据访问。MapReduce应用程序或Web爬虫应用程序非常适合这种模型。
移动计算比移动数据更便宜
应用程序请求的计算如果在它所操作的数据附近执行，效率会高得多。当数据集的规模很大时，效果更加明显。这将最小化网络拥塞并增加系统的总体吞吐量。假设将计算迁移到离数据更近的地方通常比将数据迁移到应用程序运行的地方更好。HDFS为应用程序提供接口，使其能够更接近数据所在的位置。
跨异构硬件和软件平台的可移植性
HDFS被设计成很容易从一个平台移植到另一个平台。这有助于广泛采用HDFS作为一组大量应用程序的首选平台。
# 分布式数据库Hbase
HBase是一个能够提供实时、随机读写，能够存储数十亿行和数百万列的数据库。它设计是要运行于一个商业服务器的集群之上，当新服务器添加之后能够自动扩展，还能保证同样的性能。另外，还要有很高的容错性，因为数据是分割至服务器集群中，保存在一个冗余的文件系统比如HDFS。当某些服务器异常时，数据仍然是安全的。这些数据会在当前活动的服务器中自动均衡直到替换服务器上线。HBase是高一致性的数据存储。
与Hadoop一样，HBase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。
HBase中的表一般有这样的特点：
- 容量巨大：HBase的单表可以支持千亿行、百万列的数据规模，数据容量可以达到TB甚至PB级别。传统的关系型数据库，如果Oracle和MySQL等，如果单表记录条数超过亿行，读写性能都会急据下降，在HBase中并不会出现这样的问题；
- 良好的可扩展性: HBase集群可以非常方便实现集群容量扩展，主要包括数据存储节点扩展以及读写服务节点扩展。HBase底层数据依赖于HDFS系统，HDFS可以通过简单增加DataNode实现扩展，HBase读写服务节点也一样，可以通过简单增加RegionServer节点实现计算层的扩展；
- 稀疏性：HBase支持大量稀疏存储，即允许大量列值为空，并不占用任何存储空间；
- 高性能：HBase目前主要擅长于OLTP场景，数据写操作性能强劲，对于随机单点读以及小范围的扫描读，其性能也能够得到保证。对于大范围的扫描读可以使用MapReduce提供的API，以便实现更高效的并行扫描；
- 多版本：HBase支持多版本特性，即一个KV可以同时保留多个版本，用户可以根据需要选择最新版本或者某个历史版本；
- 支持过期：HBase支持TTL过期特性，用户只需设置过期时间，超过TTL的数据就会被自动清理，不需要用户写程序手工删除；
- Hadoop原生支持：HBase是Hadoop生态中的核心成员之一。很多生态组件都可以与其直接对接。
# 分布式数据仓库Hive
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供类SQL查询功能。其本质是将SQL转换为MapReduce的任务进行运算，底层由HDFS来提供数据的存储。
Hive提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 QL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 Mapper 和 Reducer 来处理内建的 Mapper 和 Reducer 无法完成的复杂的分析工作。
Hive与传统关系型数据库（RDBMS）相比，具有下面的特点，而这也表面Hive更加适合用于海量离线数据的统计分析。
| 对比项目 | Hive | RDBMS |
|---|---|---|
| 查询语言 | HQL | SQL |
| 数据存储 | HDFS | Row Device or Local FS |
| 执行器 | MapReduce | Executor |
| 数据插入 | 支持批量导入/单条插入 | 支持单条或者批量导入 |
| 数据操作 | 覆盖追加 | 行级更新删除 |
| 处理数据规模 | 大 | 小 |
| 扩展性 | 高（好） | 有限（差） |
| 数据加载模式 | 读时模式（快） | 写时模式（慢） |
| 应用场景 | 海量数据查询 | 实时查询 |
# Redis内存数据库
Redis是一个基于key-value类型的内存数据库，它在保持键值数据库简单快捷特点的同时，又吸收了部分关系数据库的优点。
Redis分布式内存数据库每个节点采用多库互备，主备库在物理上分别部署在不同主机，确保数据安全。节点信息、路由信息可配置，便于集中维护。分布式内存数据库服务，需要具备的技术要求包括：
- 扩展性：要求当需要增加节点、扩充容量时，系统支持数据迁移，应用在不停机的情况下自动更新路由，平滑过渡；
- 高可用：要求分布式内存数据库的数据节点支持主备节点高可用;要求分布式内存数据库的路由节点支持HA的高可用；
- 易维护：要求提供便捷、灵活的开发与部署、数据导入/导出工具、界面管理工具等;要求提供SQL终端、Windows客户端对分布式内存数据库进行管理，使得操作具有界面化，可视化；
- 安全性：要求提供周全的数据备份和恢复机制，保障系统故障时用户数据的安全；各节点采用主备库机制，当主库故障时，应用可以无缝切换到备库，保证服务连续性；
- 高可靠：要求分布式数据库的数据节点异常不影响业务的连续性；要求分布式数据库的路由节点异常不影响业务连续性；要求分布式数据库的路由节点整体异常，也不影响业务的连续性；
在诸如详单查询等特定的场景和对实时性要求非常严格的场景引入了Redis内存数据库作为缓存服务。如详单查询结果中需要对某些字段进行维度转义，可以将维度数据事先加载到内存数据库中。另外，可将Redis作为数据库级缓存，如需要分页的信息，先存放到内存数据库中，避免一次性将数据提交到上层应用，同时减少网络IO。
Redis不仅能保存Strings类型的数据，还能保存Lists类型（有序）和Sets类型（无序）的数据，而且还能完成排序（SORT）等高级功能，在实现INCR，SETNX等功能的时候，保证了其操作的原子性，除此以外，还支持主从复制等功能。类似于memcached，但是支持更复杂的数据结构List、Set、Sorted Set，并且有持久化的功能。Redis每一个key都与一个Value关联，使得Redis与其他Key-Value数据库不同的是因为在Redis中的每一个Value都有一个类型（type），每一种类型决定了可以赋予其上的操作。相比于Memcached等Redis提供了更多的特性：
- 速度快，性能极高：内部使用标准C编写实现，而且将所有数据加载到内存中。Redis能支持超过 100K+ 每秒的读写频率。
- 丰富的数据类型：Redis支持二进制案例的Strings，Lists，Hashes，Sets及Ordered Sets数据类型操作。
- 原子：Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
- 丰富的特性：Redis还支持 publish/subscribe，通知，key过期等等特性。
- 持久化：所有数据保存到内存中，对数据的更新异步保存到磁盘上，Redis提供了一些策略来保存数据，比如根据时间或更新次数。
- 自动操作：对不同数据类型的操作是自动的，设置或者增加Key值，从一个集合中增加或者删除一个元素都能安全的操作。
- 支持多种语言：如Ruby、Python、PHP、Erlang、TCL、、Perl、Java等。同时提供了一个像操作关系数据库一样操作Redis的接口。
# 数据存储方案
针对不同类型数据（结构化数据与非结构化数据、实时数据与非实时数据、热数据与冷数据等）管理的实际需求，基于大数据存储管理的成熟技术，鲸智大数据平台采用混搭数据存储架构，综合运用分布式存储技术+传统关系数据库存储技术，使用X86服务器、廉价存储设备构建海量数据的存储平台。
存储平台充分发挥传统关系类型数据库、MPP架构、流处理技术、 Hadoop技术的特点，针对不同业务应用场景的数据提供更适合的数据计算和存储资源，实现低成本高效率。
数据存放服务构建在混搭存储架构上，提供存储配置管理能力、存储安全、存放策略、存储处理、存储接口等功能。
# 离线计算
离线批量计算框架基于MapReduce、Spark和Tez为基础构建，提供海量离线数据的批处理计算能力。
# 分布式计算框架MapReduce
MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。概念“Map（映射）”和“Reduce（归约）”，是它们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。 当前的软件实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（归约）函数，用来保证所有映射的键值对中的每一个共享相同的键组。
# 分布式内存技术框架Spark
Apache Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架。
与Hadoop的MapReduce、Storm等技术相比，Spark有如下优势。
首先，Spark提供了一个全面、统一的框架用于管理各种有着不同性质（文本数据、图表数据等）的数据集和数据源（批量数据或实时的流数据）的大数据处理的需求。
Spark可以将Hadoop集群中的应用在内存中的运行速度提升100倍，甚至能够将应用在磁盘上的运行速度提升10倍。
Spark让开发者可以快速的用Java、Scala或Python编写程序。它本身自带了一个超过80个高阶操作符集合。而且还可以用它在shell中以交互式地查询数据。
除了Map和Reduce操作之外，它还支持SQL查询，流数据，机器学习和图表数据处理。开发者可以在一个数据管道用例中单独使用某一能力或者将这些能力结合在一起使用。
Spark具备以下特性：
- Spark是一个基于内存计算的开源的集群计算系统，目的是让数据分析更加快速。因此运行spark的机器应该尽量的大内存，如96G以上；
- Spark所有操作均基于RDD，操作主要分成2大类：transformation与action。
- Spark提供了交互处理接口，类似于shell的使用；
- Spark可以优化迭代工作负载，因为中间数据均保存于内存中；
- Spark 是在 Scala 语言中实现的，它可以使用scala、python进行交互式操作，还可以使用scala、python、java进行编程；
- Spark可以通过mesos运行在hdfs上，但hadoop2.x提供了YARN，这更方便于spark运行在hdfs，YARN还提供了内存、CPU的集群管理功能；
- Spark提供的数据集操作类型有很多种，不像Hadoop只提供了Map和Reduce两种操作。比如 map，filter， flatMap，sample， groupByKey， reduceByKey， union，join， cogroup，mapValues， sort，partionBy等多种操作类型，他们把这些操作称为Transformations。同时还提供Count，collect， reduce， lookup， save等多种actions。这些多种多样的数据集操作类型，给上层应用者提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的 Data Shuffle一种模式。用户可以命名，物化，控制中间结果的分区等。可以说编程模型比Hadoop更灵活。
# 分布式执行框架Tez
Tez是一个针对Hadoop数据处理应用程序的新分布式执行框架，为了更高效地运行存在依赖关系的作业（比如Pig和Hive产生的MapReduce作业），减少磁盘和网络IO，Hortonworks开发了DAG计算框架Tez。Tez是从MapReduce计算框架演化而来的通用DAG计算框架，可作为MapReduceR/Pig/Hive等系统的底层数据处理引擎，它天生融入Hadoop 2.0中的资源管理平台YARN。
Tez有以下几个特色：
- 丰富的数据流（DataFlow，NOT Streaming）编程接口；
- 扩展性良好的“Input-Processor-Output”运行模型；
- 简化数据部署（充分利用了YARN框架，Tez本身仅是一个客户端编程库，无需事先部署相关服务）；
- 性能优于MapReduce；
- 优化的资源管理（直接运行在资源管理系统YARN之上）；
- 动态生成物理数据流（DataFlow）；
# 推荐底座【推荐】
| 底座类型 | 组件及版本号清单 | |
|---|---|---|
| 推荐配置一 | HDP3.1.4 | Hortonworks Data Platform 3.1.4 、Hadoop Common (yarn,hdfs, mapreduce) 3.1.1 、HBase 2.0.2 、Hive 3.1.0 、Phoenix 5.0.0 、Ranger 1.2.0 、Spark 2.3.2 、Sqoop 1.4.7 、Tez 0.9.1 、ZooKeeper 3.4.6 、Apache Ambari 2.7.4 |
| 推荐配置二 | CDH 5.16.2 | Hadoop Common 2.6.0(yarn,hdfs,mapreduce) 、Hive 1.1.0 、HBase 1.2.0 、Kafka 1.0.1 、Impala 2.6.0 、Solr 4.10.3、Flume 1.6.0，Sentry 1.5.0、 Zookeeper 3.4.5，Cloudera Manager 5.16.2 |
| 推荐配置三 | FusionInsight 8.0 MRS | Zookeeper 3.5.6、Hadoop 3.1.1、Hive 3.1.0、Tez 0.9.2、Spark 2.4.5、CarbonData 2.0.0、Hbase 2.2.3、Phoenix 5.0.0、Kafka 2.4.0、Flink 1.10.0、Storm 1.2.0、Solr 8.4.0、Oozie 5.1.0、Ranger 2.0.0、Sqoop 1.99.3、Flume 1.9.0、Elasticsearch 7.6.0、Hue 5.7.0、Redis 5.0.4、HetuEngine 8.0.0、Manager 8.0.0 |
# 数据工厂
# 上面关系
数据工厂以4one理论为指导，从数据采集、处理、开发、资产沉淀到数据开放和全生命周期管理的数据端到端治理，满足企业、政府等组织机构内外部的数据服务需求，为快速构建企业数据中台，实现数据赋能业务提供支撑。
# 相关功能
数据工厂为企业提供柔性化融合+普适性服务能力，让客户通过数据标准、数据集成、数据开发、数据融合、数据编排、数据开放等过程，轻松完成智能数据精炼、数据资产沉淀和对外能力服务，帮助客户降本增效、挖掘数据资产价值，实现智能化生产运营。
# 功能清单
| 序号 | 一级功能 | 二级功能 | 功能说明 |
|---|---|---|---|
| 1 | 数据标准 | 数据架构 | 提供对数据仓库的基础属性、分层、分域、业务实体、周期、编码规则的定义和管理 |
| 2 | 字段库 | 对数据模型的字段从字段编码、字段名称、字段分类、字段类型等方面进行规范、统一的定义。 | |
| 3 | 主数据管理 | 主数据管理是规范字段取值范围的定义，针对行业代码规范进行数据管理。后续可在数据开发、标签、翻译、报表翻译、数据稽核中引用标准。 | |
| 4 | 数据元标准 | 数据元是一种用来表示具有相同特性数据项的抽象“数据类型”，包括数据类型、数据格式、计量单位、值域信息。 | |
| 5 | 数据集成 | 数据源管理 | 提供数据中台内外部数据源链接信息的统一配置和维护管理功能，支持Oracel、Mysql、GP、DB2、PostgreSql、RDS、DRDS、SQLServer、UDAL、FTP、Hive、Hdfs、Spark、Hadoop、HBase、Redis、MongoDB、ES、CTGCache、SSH、Telnet、RestfuAPI、kafka、ZMQ、CTGMQ、AnalyticDB、Dataphin。 |
| 6 | 在线文件管理 | 一次性的数据采集任务，支持文件、hive库数据的相互迁移。 | |
| 7 | 任务管理 | 数据采集任务的配置和创建，并采用统一的任务视图对数据采集任务进行管理和维护。 | |
| 8 | 数据搬迁组件 | 提供异构搬迁、SQL搬迁、Kafka搬迁、API采集等多种数据采集组件，支持多种数据源的数据采集。 | |
| 9 | 数据清洗 | 对数据进行重新审查和校验的过程，处理问题数据。 | |
| 10 | 转换规则管理 | 对于常用数据源类型，支持常用函数的转换规则配置管理，用于数据集成任务的规则转换，使源数据经过一定的规则转换，写入目标数据库。 | |
| 11 | 全程调度 | 任务组件 | 提供包括Shell、Python、perl、SQL、函数、存储过程、MR、Spark、Java等数据处理任务组件，基于这些组件提供包括向导模式和高级模式两种方式进行任务的创建。 |
| 12 | 调度配置 | 数据采集、数据计算等多种类型的程序任务统一调度执行的任务调度配置，包括调度配置、依赖关系配置。 | |
| 13 | 360监控 | 一体化的任务调度运行视图，洞悉整个数据平台的调度运行的整体情况。 | |
| 14 | 任务监控 | 对任务实例的监控，可以查看任务组件运行的状态以及任务运行的详细日志，可根据日志辅助问题定位。 | |
| 15 | 血缘分析 | 通过图形可视化的方式呈现数据血缘，支持节点血缘分析、流程血缘分析、数据血缘分析。 | |
| 16 | 定时任务监控 | 用于监控定时任务执行情况 | |
| 17 | 资源文件管理 | 用于管理用户自定义的jar包，可以用于Shell,spark组件和mr组件等组件配置任务 | |
| 18 | 事件管理 | 提供了外部SQL判断、内部SQL判断、任务依赖判断、文件判断、分区判断五种外部外部依赖事件的配置管理功能。 | |
| 19 | 告警规则 | 后台对任务执行情况进行扫描，根据告警规则配置，提醒维护人员处理相关任务。 | |
| 20 | 告警实例 | 根据告警规则配置生成的实际告警信息。 | |
| 21 | 调度参数管理 | 提供不同数据仓库对应的调度参数的配置和管理功能。 | |
| 22 | 数据开发 | 项目管理 | 按照项目化的方式对数据开发的过程进行管理，提供项目的创建和管理维护功能。 |
| 23 | 模型管理 | 提供丰富的模型维护、导入及反向同步等功能，实现高效的模型设计和开发。 | |
| 24 | 开发工作区 | 提供批量异步离线计算脚本编写和调试的集成工作台，将大数据脚本的编写和调试从多个独立环节的原始入口整合到一套完整的集成环境中，提升脚本编写和调试效率。 | |
| 25 | 开发模板管理 | 提供开发脚本的模板案例，供开发人员开发过程中参考。 | |
| 26 | 发布管理 | 提供已调试好的数据开发脚本的发布功能，发布成功后脚本将在生产环境运行。 | |
| 27 | 权限管理 | 对项目成员及模型的权限进行管理。 | |
| 28 | 数据融合 | 宽表管理 | 对数据中台生成的各类基础宽表进行统一的管理和维护。 |
| 29 | 指标工厂 | 对各类业务指标进行统一、全生命周期的管理，包括指标目录管理，指标基本信息管理，技术口径，业务口径维护等。 | |
| 30 | 标签管理 | 实现了对标签的全生命周期管理，实现包括标签的创建、维护、上下架等功能。 | |
| 31 | 视图管理 | 将相同维度的指标、宽表融合在一起，形成某类业务统一的视图对外进行呈现，按照目录树的方式对业务视图进行统一的管理和维护。 | |
| 32 | 数据编排 | 以业务视图为基础，基于合并算法智能地把小表合并为多个合适的、整体成本最优的中间大宽表，提供给上层数据应用使用。 | |
| 33 | 数据开放 （共享交换模式） | 数据共享交换服务门户 | 运用超市化、电商化思维构建统一的对内对外数据服务的门户，实现数据能力高效的共享交换。 |
| 34 | 资源目录管理 | 提供对政务等行业数据资源目的编目、分类、检索统计及资源目录发布等管理功能 | |
| 35 | 开放宽表管理 | 提供数据仓库内所有库表资源的统一管理，将库表作为数据资源对外进行开放提供服务。 | |
| 36 | API接口管理 | 提供对数据API的统一配置和管理功能。 | |
| 37 | 文件服务管理 | 提供对文件服务进行统一管理和配置功能。 | |
| 38 | 消息资源管理 | 提供对Kafka消息服务进行统一管理和配置功能。 | |
| 39 | 注智点管理 | 注智点是资源共享申请的目标节点，注智点管理提供对FTP、数据库、Kafka同步节点的维护管理功能。 | |
| 40 | 我的数据 | 汇总展示用户提交的数据共享交换申请任务的执行信息。 | |
| 41 | 审批处理 | 为数据申请的审核人员提供的工单审批分类汇总列表信息，审核员可以在此进行工单审批。 | |
| 42 | 我的申请单 | 汇总展示用户提交的各类数据申请单的详细信息。 | |
| 43 | 应用管理 | 通过应用管理，可以创建API调用的应用。 | |
| 44 | 用户指南管理 | 用户指南编辑页面，编辑器包括文字、图片、表格，可在共享开放供外部查看。 | |
| 45 | 政策动态管理 | 支持政策法规、政策的编辑、发布，可在共享开放供外部查看。 | |
| 46 | 互动交流管理 | 支持互动交流信息的编辑、发布，可在共享开放供外部查看。 | |
| 47 | 目录模板管理 | 实现了各类模板的统一配置、管理和维护功能。 | |
| 48 | 资源分类管理 | 支持从业务、行业、主题、管理对象、信息类别5个分类维度对资源的分类进行管理。 | |
| 49 | 业务系统管理 | 对接入到数据工厂的各类业务系统的基本信息、接入信息进行统一管理的功能。 | |
| 50 | 共享交换统计 | 对开放的宽表、API接口、文件、消息服务的使用、发布情况进行统计展示。 | |
| 51 | 数据质量 | 稽核规则管理 | 通过界面配置规则配置各个数据项的审计规则，生效规则会自动生成审计任务； 规则类型包括以下几大类：及时性规则，完整性规则，一致性规则，脚本规则，准确性规则，逻辑性规则。 |
| 52 | 稽核规则监控 | 在规则监控页面监控调度情况。 | |
| 53 | 稽核结果管理 | 规则结果管理用于提供规则结果汇总信息及差异明细下载。 | |
| 54 | 质量问题管理 | 数据稽核过程中出现问题的规则实例都会自动转成问题管理中的记录，可对问题进行跟踪处理、知识总结。 | |
| 55 | 质量知识管理 | 对共性的、普遍的问题及其解决方案进行归纳，形成问题处理案例，用于后续问题的参照和质量管理工作的改进。 | |
| 56 | 数据安全 | 脱敏级别配置 | 支持定义不同敏感级别的重要性分类，包括：极敏感、敏感、较密感、低敏感。 |
| 57 | 脱敏措施配置 | 定义敏感字段实例数据的脱敏处理方法。系统默认提供六个脱敏措施：全部覆盖、部分覆盖、金库、阻断、截断、加密。 | |
| 58 | 安全条目配置 | 提供敏感字段的安全条目配置功能，包括敏感字段识别的规则、识别的数据库对象、识别的时间和频率、敏感字段的级别及脱敏措施。能够根据配置的安全条目信息，自动生成调度任务，在到达预设时间之后，后台自动扫描并记录敏感字段。 | |
| 59 | 敏感字段确认 | 展示扫描出来的敏感字段，进行批量确认和调整。 | |
| 60 | 脱敏字段查询 | 提供敏感字段搜索功能，可以查询敏感字段手动定义和敏感字段确认所确定的敏感字段。 | |
| 61 | 数据分类配置 | 定义敏感数据的分类和子类。 | |
| 62 | 数据分析 | 数据集管理 | 通过对元数据或者宽表进行组装，形成数据集信息，使报表配置和查询变得简易快速。 |
| 63 | 数据报表设计 | 提供丰富的报表组件类型，对报表展示组件进行排版、参数设计、样式设置、数据信息设置，形成可视化的报表。 | |
| 64 | 报表管理 | 对已配置的报表进行管理，包括报表的新增、修改、删除和查看管理等。 | |
| 65 | 数据权限管理 | 对数据报表进行权限设置，只有添加了权限的角色和用户才能查看相应报表。 | |
| 66 | 报表日志 | 按照每个报表被访问次数总和统计报表日志。 | |
| 67 | 下载任务监控 | 可以查看报表下载的申请记录，申请通过后可下载报表。 | |
| 68 | 公共参数管理 | 根据业务需要，对数据集进行结果转换。 | |
| 69 | 报表宽表管理 | 为了便于报表设计，提供的数据宽表上传功能。 |