企业数字化转型大数据湖项目建设和运营综合解决方案WORD

企业大数据湖项目建设和运营综合解决方案V6.0郎丰利整理制作1519第第页企业大数据湖项目建设和运营综合解决方案2023年02月目录1. 项目综述 51.1. 项目背景 51.2. 项目目标 71.3. 项目建设路线 82 需求分析 92.1功能需求 92.1.1 统一数据接入 112.1.2 数据迁移 122.1.3 数据范围与ETL 152.1.4 报表平台 162.1.5 安全管理 182.1.6 数据治理 202.2非功能需求 202.2.1运维保障需求 202.2.2可用性需求 212.2.3可靠性需求 222.2.4性能需求 232.3需求总结 233 整体解决方案 243.1 数据湖整体方案 243.1.1硬件部署方式 243.1.2基于CDH的数据湖软件部署 263.1.3数据ETL及数据接口开发方案 303.1.4沙盒管理 393.1.5多租户管理 403.2报表平台整体方案 413.2.1系统设计原则 413.2.2数据分析场景 433.2.3业务需求建议 473.2.4系统逻辑架构 633.2.5技术方案特点 653.2.6其它特性 703.2.7报表平台具体实施步骤： 713.3数据仓库整体方案 743.3.1数仓的定义 743.3.2数据仓库的特点 753.3.2数据仓库具体实施步骤 783.4数据治理整体方案 843.4.1主数据管理实施 883.4.2元数据管理实施 894 企业版功能和特性 894.1 CDH核心套件 934.1.1 分布式文件系统HDFS 944.1.2 分布式数据库HBase 944.1.3 统一资源管理和调度框架YARN 964.1.4 分布式批处理引擎MapReduce 974.1.5 分布式内存计算框架Spark 984.1.6 数据仓库组件Hive 1034.1.7 安全管理组件Sentry 1044.1.8 隐私保护 1074.1.9 统一用户体验工具HUE 1084.1.10 元数据管理Metastore&HCatalog 1114.1.11 高性能数据分析MPP引擎Impala 1124.1.12 数据导入导出工作Sqoop 1154.1.13 消息处理总线Kafka 1184.2 Manager集群管理组件 1184.3 Navigator数据管理组件 1205 项目建设 1215.1项目实施计划 1215.1.1项目实施服务 1245.1.2人员构成 1265.2验收说明 1275.2.1验收依据 1275.2.2验收内容和方式 1285.3项目风险评估 1306 6项目培训 1316.1培训服务简介 131在线学习资源 1326.2标准课程简介 132Hadoop集群管理课程 132Hadoop技术开发课程 133Hadoop数据分析课程 133培训课程优势 134培训质量保障 134培训计划定义 1356.3智慧企业大数据应用、管控、展示一体化云数据湖维护培训 1407售后技术支持服务 1407.1提供全程技术支持 1407.2全周期技术支持 1407.3协调原厂支持 1417.3.1全周期的技术支持 1427.3.2技术支持种类 1427.3.3远程支持 1427.3.4服务支持策略 1447.4主动技术支持 1447.5预测技术支持 1457.6知识库 145

项目综述项目背景xx信息化现状，发展愿景，3-5年的大数据发展规划必要性：预计未来十年，数据将以每年约40%的速度增长，更重要的是，数据中囊括了绝大多数企业业务的数据需求。在这种环境下，通过使用数据分析提高竞争力，企业需要有能力满足“信息一代”的需求，这对企业来说至关重要。从帮助预测购买行为到驱动创新项目以增强客户服务或提高生产力，数据湖能整理、存储并分析海量数据，拥有变革业务的巨大能量。分析能力正从企业的“愿望清单”中移除，转而成为必需。数据湖，为分析提供最大的灵活度。，企业产生的数据比以往任何时候都更多。这种情况为企业带来了独特的问题：需要装备自己分析这些数据，而不仅仅是存储。数据湖与Hadoop平台一道，提供了增加数据价值所需的自动化和透明度。1. 运营复杂度：随着基础设施规模的扩大，数据需求不断加深。基础设施的瓶颈对企业业务数据的存储和以此为基础建立的业务的拓展带来的制约。对于企业IT运维人员、业务系统开发人员、数据管理人员的工作量也是逐年增加，从而导致其数据需求就很有可能超过管理能力。传统的业务数据资源并不总是池化的，这样就为单一管理者可应对的存储空间造成了限制，同样，在构建更灵活的通用存储资源(例如数据湖)方面，管理者也面临难题。整理制作郎丰利1519。2. 运营成本：通过减少运营成本，提升企业效益。但业务对IT的需求却在持续增长时，便产生了矛盾。全职人工也会带来管理IT资源的运营成本上升。为了有效应对这些需求，企业或者需要更多人力资源，或者需要投资额外的第三方，支持监控、管理、部署和改善系统。与通过增加员工人数相比，第二种方法扩展了一个数量级甚至更多。整理制作郎丰利。3. 生产压力：现有的分析应用正为业务生产系统带来压力。实时分析可能是耗费大量资源的，无论是想通过视频分析，从大量高清视频流中获得洞察，还是研究社交内容瀑布流。这些流程是需要专用资源的，这样，尝试使用生产系统的用户才不会损失性能。数据湖是确保实时分析能够以最佳性能运行的关键。4. 多协议分析：企业需要数据湖，一个最终的关键信号是，数据科学家正在大量不同的Hadoop发行版上运行应用，并且，需要将他们的数据与Hadoop挂钩。未来，随着各种各样的分析实验不断深入，业务线需要IT有能力支持多种协议。企业也需要以数据湖策略为重要依据，进行整体的合理规划。5.打破数据孤岛：长期以来，数据孤岛一直是存储应用的标准，但是这些系统是运营效率低下的，并且会限制从相关数据中获得更佳洞察的能力。节约成本也是一大驱动力。除了管理复杂性，孤岛系统还需要多种授权，服务器和其他费用，而数据湖可以经济高效的方式，由单一基础设施提供支持。随着分析变得更快速、更复杂，组织也需要以同样的方式进化，以探索所有可能性。数据不再单单是数据本身，借助所有组织化数据构建的完整图景。6.利用实时分析：数据收集和分析正变得越来越快。像信用卡欺诈预警分析、股票分析这样的应用场景，需要在动作发生后数秒内就实现。不过，实时分析并不都是需要100%立刻马上就实现的。一些数据(如月销售数据、季度财务数据或年度员工表现数据)只需以特定的时间间隔存储并分析。组织需要有能力构建项目目标平台层通过对各业务板块各种数据的采集、整理、汇聚，建立一个基于“互联网+”、云计算技术和人工智能技术的数据湖，实现各业务板块的生产监视、智能设备状态监测、智能故障诊断、智能运行保障、生产数据分析等功能，打造涵盖智慧型生产、经营、发展、党建等全领域的综合平台。业务层公司数据湖融合实时数据库、关系数据库，实现数据资产管理，提供大数据应用和数据分析计算模型。其中，实时数据是主要的数据形式，实时数据库集群承担高通量数据接入的任务同时，为总部实时业务应用系统提供高实时性的数据查询、计算、组态数据源服务，同时完成数据的标准化、格式化、清洗和整理，将整齐的数据通过Kafka或其他适配器等方式输出到Hadoop数据湖，并负责提供从Hadoop平台到实时库等其他所需数据应用的输入输出组件。数据集中、挖掘，对实现与下属单位互联互通、智能处理、智能协同的目标，使用标准化、自动化、数字化、信息化、智能化等手段，打造涵盖智慧型生产、经营、发展、党建等全领域的综合平台，形成具有“自分析、自诊断、自管理、自趋优、自恢复、自学习、自提升”为特征的智慧企业生态系统。展示层随着数据湖数据存储、分析、挖掘的深入应用，将极大的激发各部门、各层级对于业务数据的分析和探索，在此之上的数据报表展示需求也将呈现复杂性、综合性、多终端性、个性化等特点。本平台主要目标是建立一个快速的可视化报表平台，无缝化对接数据湖，提供丰富的报表展示功能，面对各层次人员提供对应的数据报表及分析服务。基于此平台，我们不仅可以在报表开发过程中，加快开发速度，提高数据应用的及时性，还可以在业务需求变更、调整后，大大的降低维护难度，实现可视化做到随需应变。最终在深入完善复杂报表、打印导出、图形化分析、移动决策、大屏监控、自助分析等多个可视化分析领域的支撑。项目建设路线第一期：建设企业数据湖，梳理企业应用系统内部的业务数据类型，数据量；将结构化、非结构化数据打标签导入数据湖中心湖中，构建视频池、文本池和应用池分类。对某些应用场景构建BI报表分析。第二期：建立主数据管理和数仓，ETL规范和流程，数据安全管理，数据可视化管理，数据监控的管理。梳理数据湖使用人员的角色和权限，对数据湖进行基于业务需求场景的多租户管理。根据业务的微服务化，逐步构建企业大数据微服务平台，细粒度的平台资源管理。第三期：数据的深化应用，一体化管控数据标准和数据治理，深化主数据消费和应用。逐步将应用的数据来源迁移至数据湖中，形成数据应用平台、数据挖掘和BI报表平台，人工智能和机器学习平台。需求分析2.1功能需求数据湖的应用、管控、展示为一体，提供标准的服务和数据接口和报表展现方式。数据湖数据采用高效，可靠的存储架构。企业业务数据制订迁移方案，将ERP系统、数据采集系统、OA系统、视频监控系统、云商系统中存储的核心数据，整体迁移至数据湖，非弹性资源实行本地化部署，对于弹性计算功能，需与算法数据湖进行协同计算。以实现核心数据可控，消除安全问题和潜在未知风险。支持可视化建模，支持鼠标拖拽方式进行人工智能算法建模。包括数据预处理、特征工程、算法模型、模型评估和部署等功能支持快销业务领域的预测预警等多种类型的算法应用，包括逻辑回归、K近邻、随机森林、朴素贝叶斯、K均值聚类、线性回归、GBDT二分类、GBDT回归等算法模型，也支持深度学习等人工智能训练模型。展示层通过统一的商业BI报表组件，多维度，动态的展示各业务系统的运行状况，资源使用情况等。并支撑周期性或临时性生成各业务状况，决策数据展示，故障分析挖掘等业务场景。xx数据湖架构图文件中心：主要用于存储各种格式文件，包括影像文件，视频音频文件，PDF，Office文件等类型文件，提供文件级别的全文检索，文件发布，文件共享，文件提取等功能。提供文件权限管理，版本管理，历史版本恢复等管理功能。文件中心中文件内容可以经由ETL过程与日志中心，数据中心交换融合数据，共同参与数据处理，数据挖掘，机器学习，影像分析等工作。日志中心：收集各类日志数据，物联数据等实时数据，由流处理引擎实时处理数据，确保在第一时间分析处理数据，做到实时监控，实时告警。经处理的实时数据可与文件中心，数据中心的数据融合，共同参与数据分析等工作。结构化数据中心：实时（或批量）获取数据库或其他介质中的架构化数据，借助Hadoop/Spark等强大的处理能力，高效处理各类数据。有效结合文件中心，日志中心中的数据共同参与数据分析，数据挖掘。支持百亿级数据Cube，做到海量数据亚秒级多维度查询。标准SQL输出接口，支持不断升级的需求以及二次开发。统一数据接入数据湖接口统一接口示意图数据接入原则1、以应用驱动为主，优先建设高价值数字孪生项目；2、入湖数据必须有数据管理部认证，发布对应数据资产标准，匹配对应数据责任人；3、数据建模原则以原始数据、清洗整合数据、三范式结构、服务化宽表逐级向上规范；4、整体平台需符合高可用、平行扩容原则，符合业务3-5年的数据规划。数据实时同步，支持绝大多数的数据库实时同步需求。支持跨广域网的数据同步，支持接收器集群。建设统一的，标准的，易于复制和维护的数据实时同步平台，同时完成数据实时同步的技术规范及策略。实现数据同步监控系统，构建数据的更新情况有一个持续的，可靠的实时监控系统。完成一次性数据快速导入与增量数据导入的融合机制——涓流复制。通过FullDump模块实现数据入库的加密，基于DataHandle提供HiveSQL接口，同时完成数据出库的解密。通过ApplicationAdapter的定制实现数据访问权限的控制数据迁移 将对于频繁读写数据的业务系统，ERP系统、数据采集系统、OA系统、视频监控系统、云商系统保留原数据库的方案。业务数据同步至数据湖，并在并轨运行过程中，需定期验证本地数据湖中与业务系统数据的一致性。 接收实时增量数据，按照预定架构存储数据至本地数据湖。生产实时数据实时接入、可靠传输至公司数据库集群中，数据接入量约为110TB/天，历史数据40000TB。数据迁移逻辑架构图 数据湖作业分为非弹性和弹性两类，对于非弹性作业在本地数据湖进行运算，对于消耗资源大且需弹性计算作业，采用与企业云进行协同计算，在企业云数据湖中不保存数据，待作业计算完成后将过程和结果数据回传至本地数据湖进行存储。接口服务支持发布订阅模式，支持跨数据湖、跨系统的调用，支持HDFS、Hive、HBase等系统。a) 接口类型批量数据封装将大批量数据按一定条件抽取出来封装成数据资源。批量数据封装必须通过系统进行，不能进行手工操作。数据请求接口封装通过restful接口方式将数据封装成访问接口，使访问方通过远程调用对数据进行访问。b) 接口安全配置管理对共享数据的内容和共享接口规则进行配置，包括基础数据配置、共享服务配置、共享权限和共享配置下发。a)基础数据配置能够对数据共享功能域中使用到的基础数据进行配置，包括使用共享数据系统的配置、共享数据实体的数据结构和语义描述、共享方式等。b)共享服务配置数据服务定义、数据服务目录、数据服务参数配置(如：目标系统、共享方式、数据承载方式、访问频率、访问允许时段)等。c)共享权限配置对允许使用共享服务的目标系统进行权限配置，支持共享服务内部具体数据实体和属性的权限配置。d)共享配置下发共享数据的内容和共享接口规则下发至各相关系统。数据共享过程对各数据共享过程进行监控、异常处理、日志管理，并对数据共享相关的数据提供查询统计和分析功能。a)表数据共享目标系统是应用层分析系统，直接开放表访问权限，由目标系统通过ETL进行数据抽取。b)数据查询目标系统是应用层分析系统，由目标系统直接通过调用数据湖提供的数据查询服务，完成数据查询。c)数据订阅目标系统是应用层分析系统，目标系统提出数据订阅需求，由数据湖提供数据订阅服务。数据范围与ETL数据来源数据类型（待梳理）ERP系统会计核算、财务管理、生产控制管理、物流管理、采购管理、分销管理、库存控制、人力资源管理数据采集系统历史秒级数据、实时秒级数据、统计数据：一分钟数据、十分钟数据、日数据视频监控系统故障数据、状态数据、故障日志（B文件、F文件、W文件等）OA系统服务工单、服务请求工单、工作任务书（技改）、在建阶段工单、审批计划、档案、知识库、遗留问题云商系统日志、交易信息ETL需求：1) ELT支持从ERP系统、数据采集系统、OA系统、视频监控系统、云商系统等数据源数据的抽取、传输与加载。ERP、OA为Oracle；数据采集系统为SQLserver;云商系统为Mysql数据库。视频监控系统为非关系型实时数据。郎丰利整理制作。2) 支持流式的导入方式。郎丰利整理制作。3) 支持各种数据抽取与加载接口，如专用数据库驱动接口、JDBC、ODBC，以及Web Service接口等。郎丰利整理制作。4) ETL设计支持可视化的复杂任务控制流与数据流，支持在数据抽取、清洗和转换中实现自定义处理流程与规则；5) 支持多种数据清洗、转换任务组件，如查找、模糊查找、排序、聚合、合并、分组、条件分拆、抽样等。郎丰利整理制作。6) 支持ETL过程的异常数据处理，实现常见故障数据的修复或剔除或对故障数据抛出保留，以备系统管理员检查处理。7) ETL执行过程具备完整的日志管理和数据审计功能,并有相关监控预警机制，保证ETL正常进行；郎丰利整理制作。报表平台（总体功能架构图）综合展示的总体功能架构包括数据采集管理、信息数据管理、可视化管理三个层次。统一数据仓库建立统一数据仓库，执行统一数据接口标准，数据湖各系统与综合展示数据湖的数据通讯和同步。展示数据集中管理展示数据统一转换、统一存储、统一处理、统一调用。丰富展现方式能够灵活选择多种展现方式，包括3D圆柱图、半圆仪表、水平仪表、垂直仪表、垂直进度条、圆形进度条、水平进度条、堆积柱图、弧形进度条、扇形进度条、温度计仪表、汽泡图、雷达图等。深度关联挖掘各种展示指标，支持层层深入挖掘，从宏观到微观、从整体到个体、从实时到中长期趋势。可维护性能够根据IT运营服务本身的管理需求，快速、灵活地调整定制展现方式、展现内容。展示环境无关性数据湖展示不受大屏硬件、分辨率、尺寸大小、拼接方式的限制。安全管理大数据安全框架整体以及基本组件如下图所示，图中各组件为数据安全构架基本构成，后续根据需求会进行增删以及调增，橙色部分为本期主要阶段性实现：数据安全从最初的数据接入到最终的数据展现的安全问题。中间包括数据源、数据收集、消息系统、实时处理、存储、数据库等各部分的数据安全以及整条线的安全。身份认证和访问控制通过身份认证确保访问数据湖中的数据、资源和服务的用户是安全的，本次使用大数据技术支持身份认证，并能够实现快速建立密钥分发中心等。用户通过身份认证后可获得访问数据湖的资格，同时为进一步控制用户对资源的访问权限，通过授权机制来管理不同用户对不同资源的访问许可。所有组件都在一定程度上支持对访问的控制，使用访问控制模型，通过对细粒度的控制，控制到被访问对象的访问级别。在制定访问控制策略时，依据合规要求，结合敏感数据保护策略、数据使用场景等针对不同数据、不同业务需求制定相应的访问限制规则。数据保护数据保护技术通过对数据利用脱敏、失真、匿名化限制发布等技术处理后，使处理后的数据到达安全交易、开放共享的目的。针对脱敏后的数据，可放宽复杂的访问控制限制，降低数据泄露带来的风险和复杂控制的成本。网络分区安全网络划分独立的安全域，控制域其他区域以及系统的访问控制，控制网络层数据流向，控制大数据网络与非内部网络的链接。保障客户端访问数据湖的连接和数据湖中服务器节点之间的网络通信安全。节点之间及客户端与服务器之间的通信如有需要，可进行加密。对网络通信进行加密设置，使用网络安全设备隔离客户端与数据湖的直接访问。网络安全设备部署在数据湖和企业用户网络域之间，提供访问控制、策略管理，三区与四区间使用较强的访问控制措施，从而保护数据湖不会受到非法访问。基础安全审计和监控数据湖的一切活动并生成告警信息用来分析识别安全事件。安全事故和事件监控(SIEM)系统负责对数据湖中任何可疑的活动进行收集，监控，分析和生成各种安全报告。被监控的事件：用户登录和身份验证事件、授权错误、敏感数据操作、通过各种客户端的访问以及异常事件。数据治理根据业务要求、合规性、安全策略及数据的敏感性，数据基本分类简要定义为业务系统数据以及配置数据。从数据特性层面对数据进行标记（包括分析类型、处理方式、数据时效性数据类型、数据格式、数据源等维度），脉络化数据湖内外数据流向，包括数据被使用，被谁使用，数据是如何存储的等等，基于此对数据的管理和数据访问控制制定相应的策略。掌握敏感数据在数据湖中存在位置，降低数据暴露于风险下的概率。掌握敏感数据在数据湖中分布情况，自动地增量式地发现找到敏感数据，监控其使用情况，做到全面保护数据安全。建立整个的主数据，并保证主数据对于各个业务系统的准确性、唯一性。2.2非功能需求2.2.1运维保障需求数据湖具有友好的系统界面供运维保障人员使用，运维保障人员一般情况下通过系统界面对系统进行维护。维护数据湖需要包含并不限于以下内容：程序每一步操作需要记录日志，在程序出现错误之后，需要提供基础的错误分析；需要能够通过系统界面监控服务程序的运行状态；数据处理过程需要进行记录，以及处理的问题数据和正常数据的条数；针对kafka等流式数据处理服务进行监控和分析；针对数据湖各组件的服务状态进行监控和告警；针对服务器硬件层面、系统层面、hadoop集群层面进行监控，并根据故障级别以短信和邮件等形式发出告警信息。2.2.2可用性需求系统具备长期稳定工作的能力，所有选用产品均符合我国或国际上的质量及可靠性标准。在不同环境及人员操作情况下，均能处于平衡稳定状态。提供高可靠的分布式文件系统：基于业内广泛使用的高效分布式存储架构，可存储任意容量，任意数据类型的数据；没有单点故障，提供成熟的高可用性方案，并可以直接图形化配置；支持分层，多种存储介质的异构分布式存储架构，有效利用内存、SSD等存储介质的性能优势以及传统磁盘的容量成本优势；支持多种访问模式，包括NFS，HTTP，原生API等；提供完善的图形化文件管理工具，具有查看、编辑、删除等功能；提供快照功能，防止误删除文件;支持多租户情况下数据管理;支持Kudu存储引擎；支持impala引擎对kudu访问；提供高可靠的分布式关系型存储Kudu；基于业内广泛使用的分布式关系型存储，可按关系型二维表存储数据；支持关系型数据的增删改查功能，并能秒级进行大数据操作；支持多种访问模式，包含原生API等；支持与MapReduce、Spark和Impala等的集成；支持高并发数据访问和高吞吐。2.2.3可靠性需求系统具备按要求进行备份的能力，并提供相应手段。1、健壮性要求：接收异常或其他错误数据，数据湖具有强健壮性，不会导致系统出错甚至崩溃，能够满足业务应用。2、安全性要求：通过对用户和数据的权限设定，确保用户只能访问其所属用户类型已被授权访问的那些功能或数据。3、可扩充性要求：当现有数据湖资源需进行扩充时，数据湖能够满足动态扩容的需求。2.2.4性能需求1、历史业务系统和配置数据从应用系统数据湖迁移至本地化数据湖过程，性能满足要求。2、实时数据接收，数据无丢失，查询性能满足要求。3、目前运行在应用系统中的算法迁移至本地数据湖，且算法在数据湖中，性能满足业务应用要求。备注：在本地化数据湖中算法性能不低于当前在应用系统中算法运行性能。2.3需求总结综上述，通过此技术架构，可以在大数据基础数据湖建设方面实现以下功能：1、统一数仓：建设成熟稳定、性能先进、灵活架构、便捷易用的大数据存储与计算数据湖，实现企业内部统一汇聚、统一标准的数据仓库。2、统一管理：建设数据权限、元数据管理、数据生命周期管控能力。3、全量数量：建设数据全量存储、全量计算的大数据基础数据湖，实现快速对接系统数据，提供批量数据采集与处理能力。4、数据汇集：建设多源异构数据整合接入能力。5、数据计算：建设海量数据混合计算处理能力（批量处理和实时流处理），以及丰富多样的数据挖掘算法工具。6、数据展现：多种维度、多种展现方式、多种接入方式的灵活的，可定制化的，可拖拽的报表平台。7、数据湖扩展：建设具有良好兼容性与扩展性的基础数据湖，以较好地支撑后续大数据应用系统的建设。8、图片及视频流数据保存至数据湖中，并支持快速检索。整体解决方案数据湖整体方案3.1.1硬件部署方式支撑X86架构服务器部署。网络使用以太网络构造，要求支持IP网络即可，底层存储无专用的存储体系结构要求，单数据节点无存储可靠性要求。网络部署拓扑参考下图：硬件配置如下：数量CPU内存操作系统硬盘容量管理节点：2台2*E5-2620v4128GCentOSLinuxSAS600GB，12Gb，5块主板自带支持RAID0、RAID1；主机总线适配器；主板集成2口千兆网卡以及2口万兆网卡；工作节点：13台2*E5-2620v4256GCentOSLinuxSAS600GB，12Gb，2块;SATA4TB，12Gb，8块；主板自带支持RAID0、RAID1；主机总线适配器；主板集成2口千兆网卡以及2口万兆网卡；3.1.2基于CDH的数据湖软件部署本次xx项目底层数据湖是由公司所发行的Hadoop企业版，简称CDH。该版本作为业界最领先的企业级数据中心基础软件，Enterprise除了包含业界最流行的基于开源Hadoop及其生态组件构建的CDH核心，还包含了很多为支撑企业级业务的高级管理特性。借助于Enterprise的整体解决方案，企业可以专注于自己的业务能力。1、结构概述基于Hadoop的系统数据湖中，底层为统一分布式存储HDFS，其上包含了分布式内存分析引擎SPARK，分布式NoSQL数据库HBase，以及支持多租户的分布式计算集群。在Hadoop及相当架构系统数据湖之上，根据实际外部合作以及内部应用提供多租户服务以及资源与数据访问权限控制。如下图所示：Hadoop数据湖架构图数据湖由分布式资源管理框架实时调度资源、管理计算分析集群，为各个租户以及各个应用提供资源调度管理以及高效的分析挖掘能力，同时结合LDAP与Kerberos提供完备的权限管理控制。3.1.3基本组件基本组件结构图结合xx使用的主要组件和使用场景，从数据接入到数据存储和数据计算，各组件的应用场景和功能整体介绍下如下：1) HDFS：Hadoop分布式文件系统，主要以大文件存储为主，吞吐比较高，主要存储相关的视频文件和常规非实时、不修改的结构化数据，同时可以作为历史数据存储，适合数据分析和数据挖掘存储。2) Kudu：结构化数据存储，可以实时接入设备端数据，同时接入业务系统需要经常修改的业务交易数据，适合结构化数据数据分析和数据挖掘。3) HBase：NoSQL数据库，可以实时接入设备端数据，适合做固定模式的数据明细查询；同时适合存储如文件、音频等海量的小文件。4) YARN：资源管理和调度框架，主要的批处理和计算引擎的资源调度工具。5) MapReduce：分布式批处理引擎，主要适合海量数据的批处理作业。6) Zookeeper：分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，Zookeeper作用主要是用来维护和监控存储的数据的状态变化，通过监控这些数据状态的变化，从而达到基于数据的集群管理。7) Hive：SQLOnHadoop的最常用工具，主要适合客户用SQL来进行数据的批量处理，底层会借助MapReduce或Spark。8) Impala：MPPOnHadoop的最常用工具，主要适合客户用SQL进行交互式查询和即席查询相关的操作，支持JDBC/ODBC，和主流BI工具已经认证集成。9) ES：全文检索工具，主要用于客户针对文本内容进行数据的搜索，如Word，PDF等。10) Spark：主流的Hadoop数据处理引擎，以内存计算为主。通过的高效数据计算引擎，支持批处理、流式计算和数据挖掘等不同的计算方式，流处理有引擎SparkStreaming，数据挖掘有SparkMLLib，数据批处理有SparkSQL和Scala开发。后续应用的流式计算和数据挖掘、机器学习和数据处理都需要这个组件。11) Sqoop：ETL工具，主要用来集成业务交易系统数据如Oracle、DB2、Mysql等数据源数据定时同步到Hadoop数据湖上。12) Kafka：消息中间件，可以传输不同的数据，目前主要可以用来传输设备端如风电等实时数据，进行数据的缓冲和数据的多目标分发。13) Flume：一个可以收集例如日志、事件等数据资源，并将这些数量庞大的数据从各项数据资源中集中起来存储的工具/服务。Flume具有高可用，分布式，配置工具，其设计的原理也是基于将数据流，如日志数据从各种网站服务器上汇集起来存储到HDFS，HBase等集中存储器中。具体版本及特性的详细介绍，请参见第四章。3.1.3数据ETL及数据接口开发方案业务系统数据迁移开发方案业务系统数据迁移需要将实时数据库中的历史数据与实时数据整齐地通过Kafka消息队列输出到xx集控中心Hadoop数据湖的Kudu和HBase中进行存储。实时数据库中配套的输出适配器将缓冲区的数据解析并生成指定格式的数据，实时向Hadoop数据湖中的Kafka集群推送，存入Kafka的Topic中，每一个业务系统对应一个采集协议，同一采集协议的数据放在一个Topic里。业务系统历史数据中，结构化数据通过sqoop脚本进行批量的导入，在导入过程中进行面向业务的数据清洗、转换、加载到Kudu和Hbase中去。数据按照业务系统进行分类，进行标签的规则制定和数据标签的开发。业务系统历史数据中，非结构化数据通过flume脚本进行批量的导入，在导入过程中进行面向业务的数据清洗、转换、加载到Kudu和Hbase中去。数据按照业务系统进行分类，进行标签的规则制定和数据标签的开发。ERP系统、数据采集系统、OA系统、视频监控系统、云商系统进入数据湖存储。日志中心湖区和文件中心湖区往往数据量非常大，且价值密度较低。对于这类数据不要求强一致性，故而可不进行数据审计和定期数据一致性校验。日志中心湖区和文件中心湖区多以半/非结构化数据为主，需要进行关联分析的，进行模型换行，并将其导入到中心湖的HDFS/HIVE。云商数据和用户网页行为分析的数据，数据产生并发度高，数据流量大，需要用Kafka集群进行数据承接，承接过程中需要进行一定比例的数据压缩，之后直接存储到HDFS中，通过HIVE外部表的形式进行访问，以降低集群负载。对于文件中心的图片文件，推荐进行图片识别，通过web前台、数据API服务，进行图片数据的上传及查询，图片需要有唯一ID作为标示，确保可检索。海量图片数据以ID为rowkey，储存于Hbase平台，提供快速储存及查询能力。数据资产上有以下方面的构建：1、统一索引描述非结构数据，方便数据检索分析。2、增加维护及更新时间作为对象描述字段(图片类型、像素大小、尺寸规格)。非对象方式及数字化属性编目(全文文本、图像、声音、影视、超媒体等信息),自定义元数据。3、不同类型的数据可以形成了关联并处理非结构化数据。 Hadoop数据湖，通过相关组件将数据存储在Hadoop集群的HDFS和HBase中。通过上层分析和处理引擎Hive、Impala、Spark对底层数据进行分析处理，并提供统一的数据访问接口非弹性计算业务迁移：包括预警常规模型计算和预警可视化服务。服务所需环境：CentOS7.0、Hbase、Hive。数据存储开发方案Kafka的Topic中的数据通过定制开发的SparkStreaming程序进行清洗、去重等操作并存入数据湖。数据采用Kudu+HBase的方式存储，HBase存全量数据，Kudu存计算点数据、测点数据。数据仓库的存储，根据业务需求，采用hive+kudu的方式进行开发。报表的数据存储，根据实时性和变化量，采用hive+mysql的方式进行存储，开发相应的关系映射和连接组件。Hbase+ES近实时(NRT)查询开发方案Hbase适用于大表的存储，通过单一的RowKey查询虽然能快速查询，但是对于复杂查询，尤其分页、查询总数等，实现方案浪费计算资源，所以可以针对hbase数据创建二级索引(HbaseSecondaryIndexing)，供复杂查询使用。而ES作为一个高性能，采用Java5开发，基于Lucene（同时对其进行了扩展）的全文搜索服务器，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。Key-ValueStoreIndexer是Hbase到ES生成索引的中间工具。在CDH5中的Key-ValueStoreIndexer使用的是LilyHBaseNRTIndexer服务。LilyHBaseIndexer是一款灵活的、可扩展的、高容错的、事务性的，并且近实时的处理HBase列索引数据的分布式服务软件。LilyHBaseIndexer使用ESCloud来存储HBase的索引数据，当HBase执行写入、更新或删除操作时，Indexer通过HBase的replication功能来把这些操作抽象成一系列的Event事件，并用来保证写入ES中的HBase索引数据的一致性。并且Indexer支持用户自定义的抽取，转换规则来索引HBase列数据。ES搜索结果会包含用户自定义的columnfamily:qualifier字段结果，这样应用程序就可以直接访问HBase的列数据。而且Indexer索引和搜索不会影响HBase运行的稳定性和HBase数据写入的吞吐量，因为索引和搜索过程是完全分开并且异步的。hbase负责海量数据存储；ES负责构建索引和提供对外查询；Indexer负责提供hbase到ES的索引构建。数据使用流程图数据接口的开发数据湖通过标准接口的方式为外部系统提供数据服务，根据不同业务系统的需要进行定制化的接口开发。根据业务的不同数据封装分成两种方式，一种是对批量的数据进行封装，将封装后的数据发布到共享区上，供数据应用和外围系统获取，这种方式主要针对访问方需要海量数据的情况；另一种方式是将数据封装成WebService或者其他专用Socket协议的格式供访问方获取单条数据，这种方式主要针对对客户视图等的访问情况。1) API应保持与开源Hadoop及相当架构系统各服务组件的API不变，具体包括并不限于接口功能、接口类型（Java、Python、Rest等）、接口名称、输入参数、返回结构。所支持的接口包括并不限于：a. 支持访问分布式文件系统的文件操作接口；b. 支持与外部数据源关系数据库的交互；c. 通过提交MR任务分析和查询数据；d. 支持Thrift、Rest接口；e. 以直接提交查询语句方式访问数据；f. 提供用户访问Hive的方法，支持用户使用Java和Thrift方式访问Hive。2) SQL应支持上层使用SQL语言进行访问，具体要求：a. 以ODBC方式访问数据湖；b. 以JDBC方式访问数据湖；c. 提供可视化界面工具，提供SQL设计以及数据访问功能，支持Kudu、Spark、Hive、Impala以及传统数据库。数据湖提供标准接口API直接与生产实时数据库通信，获取生产数据，并将数据接入xx数据湖的实时数据库集群中。数据格式标准化方式，将数据湖的数据访问，封装为标准的WebService接口。消费数据的上层应用，通过不同的接口服务进行调用，数据湖提供标准化的解析方式，权限由数据湖统一控制。数据接入层采用KAFKA为实时接入组件，根据业务需求，建立统一的TOPIC,消息包含但不限于：时间戳、消息来源、设备类型，状态值等类型，采用统一命名规则和编码方式。数据库表进行统一的命名方式和索引构建，使用CDH的Navigator组件进行数据全生命周期的跟踪和管理。数据ETL方案及实现ETL架构图将业务系统的关系型数据库中的数据集成到Hadoop数据湖，涉及的部分关系型数据库包括：Oracle9、Oracle9.2、Oracle9i、Oracle10g、Oracle10.2、Oracle11g、Oracle11.2、Oracle13、SqlServer2000、SqlServer2008、MySql5.0。ETL是数据抽取(Extract)、转换(Transform)、装载(Load)的过程。是构建数据湖的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终将数据加载到数据湖中。数据抽取提供手工和自动两种抽取方式；手工方式通过人为方式启动任务，自动方式基于调度程序定期定时执行抽取任务；提供全量和增量数据抽取；提供多种抽取策略；抽取的字段可以动态修改；提供上传数据压缩包的解压；数据转换数据转换(Transform)是按照目标表的数据结构，对一个或多个源数据的字段进行翻译、匹配、聚合等操作得到目标数据的字段。数据装载提供数据的批量装载；提供以接口和文件的方式将数据装载进入综合应用数据湖、深度分析库、Hadoop库中；提供对采集过程及结果的监控界面，获取监控数据。提供对采集的过程报错提供日志记录和审计功能，，并提供相应的管理界面和外部访问接口。非结构化数据集成非结构化数据包括音视频数据及采用爬虫等相关工具抓取的产业信息等，采用ETL工具将非结构化数据集成到数据湖。实现步骤：参与人员：xx技术团队科技实施团队主要任务：数据源及其特性定义数据析取、转换和加载策略设计析取Extracting条件Conditioning剔除Scrubbing合并Merging浓缩Enrichment确认Validating加载Loading评分Scoring家庭关系识别Householding构建和测试初始加载的程序和处理流程构建和测试日常加载的程序和处理流程40%的工作量在数据转换和加载上交付件：《数据ETL设计说明书》《数据映射（DataMapping）说明书》数据ETL脚本（ETLScripts）加载流程控制（ETLProcessControls）3.1.4沙盒管理利用Docker,基于kubernetes主打的容器技术与微服务应用基础平台，HDFS和YARN均可依此建模，为上层应用提供微服务引擎架构支持。使用资源隔离，基于linux提供的LXC技术,EDH提供静态的资源隔离，并使用CGroups对隔离后的资源进行管理。部署服务弹性伸缩和自修复触发器，充分利用计算资源。创建分析引擎及计算引擎镜像，部署到docker中。 基于devicemapper动态扩容、缩容，将中心湖的数据进行分片，然后同步导入到沙盒中的HDFS或KUDU中。3.1.5多租户管理数据湖环境下的多租户CDH平台需要具备多租户资源管理能力，支持PB级的数据处理和应用分析、秒级的实时处理和场景营销、高并发的数据查询、对外的服务支持等。多租户Hadoop平台框架如左图所示，可以满足统一数据存放，提高数据湖数据共享率，优化资源调度策略，提升数据湖资源利用率，支撑PB级大数据处理，建立数据湖评测标准等效果。目前版本的多租户CDH平台已满足大部分功能需求，包括满足统一数据存放、优化资源调度策略，提升数据湖资源利用率，主要包含以下几个模块:多租户管理、资源管理、机构管理、权限管理，应用及数据的统一监控、安全管理分为以下几个模块:我的工作台包含用户（租户）自身的资源查看和申请、提交的任务运行情况(历史任务/正在运行的任务)、所拥有的数据列表、密钥申请及查看；机构管理包含用户层级管理(主要针对多部门多用户的分级管理)；用户管理包含用户的个人管理、用户所关联的平台角色管理、用户申请的密钥审批管理、用户/租户针对CDH平台组件的权限管理(YARN/Impala/Hive/HDFS/HBase等)3.2报表平台整体方案3.2.1系统设计原则系统设计方案总体遵循技术规格书的总体目标和指导思想，以优化整合基础数据为前提，以构建贯通主体业务为目标建立基于信息共享数据湖的BI应用系统架构；应用系统架构的规划要将先进性和实用性有机结合，结合的关键点在于从的实际需求出发，在明确的有限目标前提下，以实用性为优先。系统设计体现统一性、先进性、实用性、可靠性、安全性、可扩展性。统一性信息资源统一规划、统一管理，包含是统一的建设标准。包括统一的数据标准、统一的规划标准、统一的接口标准、统一的管理标准。先进性技术设计及业务应用方面体现行业应用的领先性和前瞻性。实用性管理模式和系统功能要针对的实际情况设定，体现基础扎实、效率优先、平稳过渡、降低风险、投资见效快的要求，并结合使用人员特点、业务实际操作特点和管理基础使系统易学易用、方便推广。可靠性系统采用大型关系型数据库，有严格的安全控制和数据备份机制，确保数据安全可靠。安全性在网络配置上，外部只可访问经过许可的Web服务器，保证内部业务分析应用模型的数据不被非法用户所获取。在应用软件的设计上，强化权限管理功能，具有多级安全机制。通过对各级工作人员的权限设置，做到所有人员只能查看与其权限相应的数据，并建立完善的日志管理，做到所有操作都有据可查。可扩展性可扩展性从以下两个方面提出要求：一是业务应用功能的可扩展性，通过建立集中与分层管理的统一模式，使同类业务能在和二级部门层面推广使用，并以精细化数据管理为基础，为未来系统功能向更高层次的提升奠定应用基础框架；二是系统环境的可扩展性，网络和系统数据湖可根据统一规划的要求，在保证体系完整的前提下，通过逐步扩充来满足应用需求并实现合理投资。易用性提供了完整的交互性的UI操作界面和管理控制数据湖。其中BI更有别于其他传统BI产品，在分析图表创建、调整等方面更为简便、易用，以一个产品组件即实现了数据结构、数据图表、OLAP、Dashboard等以往需要多个产品实现的开发和应用发布功能，极大地减轻了对系统维护团队的工作压力。3.2.2数据分析场景一个分析数据湖融合五类企业应用场景，全面满足您构建由数据驱动的现代企业管理体系。我们更需要构建全方位的数据分析能力，并将其融入各种业务场景中，促使其真正产生价值，提升ROI。引导式分析：预定义数据逻辑，以内置的业务模型引导分析过程，以发现显性业务问题为主。自助式分析：自定义数据逻辑，可论证业务的自助分析过程，以提出并回答焦点业务问题为主。嵌入式分析：将分析应用嵌入企业应用，构建集成的业务支撑数据湖，快速融合业务执行管理场景。定制化开发：定制数据分析及服务能力，构建外部的分析应用门户，增强价值链环节有效协作。报表及协作：提供分析应用的生成及订阅，构建企业级报表分发体系，主动投递业务洞察。一个分析数据湖响应两套不同分析方法，迅速应变您数据处理及分析的审视过程。可预定义数据逻辑的内存计算模式，基于预置业务模型提供团队已知洞察点的分析线索。可自定义数据逻辑的关联计算模式，基于动态业务模型提供支撑个人知识结构与工作背景的分析能力。一个分析数据湖接入多种数据资源，应对复杂数据分析环境。充分结合数据湖的海量存储与计算能力。一个分析数据湖接入多种用户体验诉求，增强背后的业务逻辑应变及用户体验模式。基于“零开发•跨终端•自适应•易交互•多协作”模式，使用数据分析行为在Anyone-Anytime-Anywhere-Anymore均可被保证有效，全面构建由数据驱动的现代企业管理体系。业务人员在使用过程中，通过“搜索”、“探索”、“快照”、“书签”、“故事”、“观点”等十多种可视化交互能力定义，任何人均可快速有效地实践对数据的分析、管理及协作方案。并可基于时间与事件进行静动态回溯，全方位审视数据的意图，与您的团队进行论证业务分析焦点并分享你的独到见解。3.2.3业务需求建议基于对xx前期的沟通和对运营分析内容的理解。结合科技在数据分析解决方案和实施经验，提供如下建议和参考示例。以下图表样式仅供参考，具体管理规范和分析图表样式以实际为准。实施过程中梳理维度与指标，开展业务需求规格书的编写和评审。统一管理分析报表的命名规范，在报表名称、维度与指标。将企业KPI指标以资产管理卡片的形式存档（KPI字典），并设立引用、变更等管理流程。以各业务主题为单元，分解详细的业务分析规划并讨论、评审。以下是财务分析主题、生产供应主题、物流分析为示例参考。示例：财务分析主题财务分析是以会计核算和报表资料及其他相关资料为依据，采用一系列专门的分析技术和方法，对企业经营组织过去和现在的有关筹资/投资活动、经营活动、分配活动的盈利能力、营运能力、偿债能力和增长能力状况等进行分析和评价的管理活动。相对与其他分析主题较为固化，特点是标准化，但在本方案中将结合BI产品的特色提出分析方案。财务控制分析标准财务分析方法，纯财务口径的统计分析，包括三大财务报表、能力分析法覆盖财务部报表：FI001偿债能力分析A类FI002营运能力分析A类FI003盈利能力分析A类FI013税金分析A类FI014费用分析B类FI015营业外收支分析B类包含但不限于下列维度和指标：维度：时间–年、季、月法人单位基础指标：组合指标不再一一罗列会计科目期初、借方发生、贷方发生、余额资产负债/损益/现金流量表行项目期初、借方发生、贷方发生、期末余额财务经营分析以财务口径统计各类经营活动，例如：采购节超、销售量差/价差、成本还原等的分析方法，在需要时可拆分成各经营活动的独立分析。覆盖财务部报表：FI004工程分析B类FI005发货分析A类FI006销售分析A类FI008库存分析A/B类FI009往来科目分析A类FI010应付总帐与明细账的核对B类FI011采购分析FI012低易领用分析A类FI016PBC数据汇总B类FI017产销量报表汇总B类包含但不限于下列维度和指标：维度：时间–年、季、月生产基地公司-公司、部门低易类别存货类别片区-大区、片区产品-品种、品规、包装基础指标：组合指标不再一一罗列发货额、成本、毛利、净利润、单价、应收/应付账款、工程项目支出、单位成本、存货量/额以及相关预算财务主题综述注：图例仅用于帮助理解为目的，不代表未来项目实施的交付件示例：生产供应主题针对生产涉及的原材料采购、供应、库存等信息，统计各物料、供应商、生产基地的运营情况。覆盖供应部报表：PP001物料价格变化趋势A类PP002物料需求计划B类PP003应付账款账龄分析B类PP004成本分析A类包含但不限于下列维度和指标：维度：时间–年、季、月生产基地供应商物料–类别、品种产品-品种、品规、包装仓库-库区、库位基础指标：组合指标不再一一罗列物料价格、库存量/额、生产需求量、应付账款注：图例仅用于帮助理解为目的，不代表未来项目实施的交付件示例：物流分析主题以物流监管部提出的报表需求为主线，不限定报表格式（需调研）与指标（需调研），结合提出的解决方案和实施经验，涉及物流各运营环节的统计分析。覆盖物流监管部报表：SC001物流成本分析B类SC002物流成本预警A类SC003效率分析A类包含但不限于下列维度和指标：维度：时间–年、季、月、日生产基地承运商人员物料–类别、品种产品-品种、品规、包装仓库-库区、库位基础指标：组合指标不再一一罗列存货量/额、物流费用额、里程、注：图例仅用于帮助理解为目的，不代表未来项目实施的交付件3.2.4系统逻辑架构系统采用多层设计原则，将系统分为：数据层、应用层以及展现层。系统逻辑部署如下图。数据层：涉及ETL、ODS和数据仓库ETL：负责抽取、清洗、逻辑转换和加载等数据集成的执行工作ODS：集成来自多个系统的数据，直接将来源系统的数据以类似复制的方式，经过简单清洗、维度映射后的数据存储数据集市：是ODS数据的进一步处理，是面向业务分析主题的、经过预先汇总的数据存储，与ODS一起构成完整的数据仓库可用性。应用层：基于数据仓库的基础上，提供应用服务支持、资源发布。展示层：基于应用层的服务支持，提供用户通过企业局域网、互联网在桌面PC或移动设备访问分析模型的能力。3.2.5技术方案特点1.数据源安全连接到本地或云端的任何数据源。以实时连接或数据提取的形式发布和共享数据源，让每个人都可以使用客户的数据。兼容热门的企业数据源，如Hadoop、Oracle、AWSRedshift、多维数据集、Teradata、MicrosoftSQLServer等。借助我们的Web数据连接器和API，还可以访问数百个其他数据源。3

易用性BI提供了一个非常新颖而易用的使用界面，使得处理规模巨大的、多维的数据时，也能即时的从不同角度和设置下看到数据所呈现出的规律。BI通过数据可视化方面技术，使得数据挖掘变得平民化。而其自动生成和展现出的图表，也丝毫不逊色于互联网美工编辑的水平。2.自助式开发只需用拖放的方式就可快速地创建出交互、美观、智能的视图和仪表盘，快速创建出各种图表类型。如：饼图、柱状图、条形图、气泡图、热力图、瀑布图、突出表、折线图、散点图、交叉表等等，并且BI拥有自动推荐图形的功能，即用户只要选择好字段，软件会自动推荐一种图形来展示这些字段；图表可以在仪表盘中自由摆放，形成图文结合的视图。这些视图可以是一表多图、一图多表、多表多图的表现形式。同时，还支持图表的动态播放功能；友好的数据可视化界面，内置地图、计算公式、函数以及下钻穿透功能，用户可以自主创建图表等。BIServer可以提供适合每种用户的功能，让组织中的每个人都能够查看和理解数据。这其中既有希望使用已发布仪表板进行数据驱动型决策的非固定用户，也有希望使用Web制作功能来根据已发布数据源提出新问题的数据爱好者，甚至有希望创建自己的可视化和数据源并与组织中其他成员共享这些内容的数据行家。3.灵活的部署灵活的部署适用于各种企业环境，支持门户、iPad和各种浏览器，用BIDesktop可以将分析结果发布到BIServer上与同事进行交流和分享。同事也可以以极快的速度用浏览器和移动终端来处理业务人员所分享的数据源和分析结果。如各种版本的浏览器、Android或IOS系统的平板及移动手机。无论是将数据存放在本地还是云端，BIServer都能让客户灵活集成到现有的数据基础架构中。在本地的Windows或Linux系统上安装BIServer，可在防火墙保护下实现最佳控制。借助AWS、Azure或GoogleCloudPlatform实现公有云部署，从而利用现有云端投资。BI支持数据的实时定时自动刷新业务人员在仪表盘的界面模式固定好后，若数据源中的数据有增加、删减、修改等情况，可通过客户端和Server对数据进行更新，仪表盘在每次打开后可以自动实时刷新界面以展示变动后的最新数据。BI支持快速实现系统集成客户可以将BIServer中的交互式视图嵌入到网页、博客、wiki、Web应用程序和Intranet门户中。嵌入式视图会随着基础数据的变化或工作簿在服务器上的更新而更新。嵌入的视图遵守服务器上使用的相同许可和权限限制。客户可以将分析技术部署到员工、客户、合作伙伴和供应商需要的地方，在现有的商业门户中嵌入交互式仪表板，包括Salesforce、SharePoint和Jive等应用程序。BI支持订阅式邮件分发BIServer上打开视图时，如果该视图的右上角有一个订阅图标，则表示用户的管理员已为站点配置了订阅。可以单击此信封来选择用于订阅视图的选项。这意味着会定期自动向用户的电子邮件帐户中发送视图的快照，而查看人员不必登录BIServer就可在邮箱中查看视图快照。用户也可以选择在一封电子邮件中接收工作簿中的每个视图，或者取消订阅不再想要接收的视图。4.大数据分析BI支持海量数据，在普通硬件条件下，百万级数据响应时间为秒级。5.有效管控集中管理所有元数据和安全规则。为用户提供精心整理的共享数据源。了解使用情况以优化环境。恰当平衡用户灵活性和掌控力。无论使用的是ActiveDirectory、Kerberos、OAuth还是其他标准，BI都可与客户的现有安全协议无缝集成。管理用户级别和组级别的身份验证。采用传递式数据连接权限和行级筛选，维护数据库的安全。利用多租户选项和细粒度的权限控制，保证用户和内容的安全。BI是一个现代企业分析数据湖，可在管控之下提供大规模自助式分析功能。安全性是数据和内容管控策略的重中之重。BIServer提供全面的功能和深入的集成，帮助应对企业安全的方方面面。BI可帮助组织为所有用户提供受信任的数据源，以便他们使用适当数据快速作出正确决策。随着单一集中EDW的前景日益衰落，以及云技术推动下数据量的持续加速增长，在所有不同数据湖之间实现一致的安全性对企业至关重要。1

身份验证BIServer支持行业标准身份验证，包括ActiveDirectory、Kerberos、OpenIdConnect、SAML、受信任票证和证书。BIServer还具备自己的内置用户身份服务“本地身份验证”。BIServer会为系统中的每位指定用户创建并维护一个帐户，该帐户在多个会话间保留，实现一致的个人化体验。此外，作者和发布者可在其发布的视图中使用服务器范围的身份信息，以控制其他用户可以查看和下载哪些数据。2

授权BIServer角色和权限为管理员提供细化控制，以便控制用户可以访问哪些数据、内容和对象，以及用户或群组可对该内容执行什么操作。客户还可以控制谁能添加注释，谁能保存工作簿，谁能连接到特定数据源。凭借群组权限，客户可以一次性管理多名用户。也可在工作簿中处理用户和群组角色，以便筛选和控制仪表板中的数据。这意味着，客户只需为所有区域、客户或团队维护单个仪表板，而每个区域、客户或团队只会看到各自的数据。3

数据安全无论是银行、学校、医院还是政府机构，都承担不起因丧失数据资产控制权而带来的风险。BI提供了许多选项来帮助客户实现安全目标。客户可以选择仅基于数据库身份验证来实现安全性，或者仅在BI中实现安全性，还可以选择混合安全模型，其中BIServer内的用户信息对应于基础数据库中的数据元素。BIOnline加强了现有的数据安全策略，并符合SOX、SOC和ISAE行业合规标准。4

网络安全网络安全设备有助于防止不受信任的网络和Internet访问客户的BIServer本地部署。当对BIServer的访问不受限制时，传输安全性就变得更为重要。BIServer使用SSL/TLS的强大安全功能，对从客户端到BIServer，还有从BIServer到数据库的传输进行加密。BI可帮助客户保护来自外部的数据、用户和内容。3.2.6其它特性

监视和管理BI数据湖易于部署、扩展和监视。轻松跟踪和管理内容、用户、许可证和性能。快速管理数据源和内容的权限，直观监视使用情况。随时可以进行纵向、横向扩展。

可靠性先进的高可用性、稳健的故障转移和快速的灾难恢复，就是全球各大公司选择使用BI进行企业分析的原因。正确选择能够实现企业SLA的冗余量。

可扩展性根据当前需求调整分析规模，然后随着用量的增长轻松进行横向或纵向扩展。BI架构可以在不停机的情况下实现无缝扩展。轻松转换到更新的硬件或添加更多节点，以增加冗余量和容量。3.2.7报表平台具体实施步骤：在本项目中，我们将采用BI标准实施方法论开展项目实施工作，明确定义每个阶段中xx业务用户、技术团队以及科技实施团队的参与程度、工作内容/职责和交付物。项目准备主要任务：确立双方沟通、交流机制，制定项目管理文档BI操作、开发培训明确项目实施计划细则明确项目资源计划（业务用户）参与人员：xx业务团队了解BI项目开发特点定义项目实施涉及参与人员（需求提供者、业务说明者）协助科技完成资源计划参加BI操作、开发培训xx技术团队协助完成培训组织工作参加BI操作、开发培训确保BI项目开发环境、相关设施按时到位协助科技完成资源计划科技实施团队提交BI开发环境需求清单进行BI操作、开发培训制定项目实施计划细则提交项目资源计划交付件：《项目实施计划（明细）》《项目管理文档模板》《BI培训资料》需求调研蓝图设计主要任务：按业务需求设计分析应用主题明确主题模型与数据仓库的数据接口定义参与人员：xx业务团队参与业务蓝图设计讨论确认业务蓝图设计xx技术团队参与技术蓝图设计讨论确认技术蓝图设计科技实施团队进行业务蓝图设计进行技术蓝图设计交付件：《业务蓝图设计说明书》《技术蓝图设计说明书》业务蓝图模型系统实施步骤主要任务：搭建BI开发环境构建和开发BI数据模型构建和开发BI分析应用参与人员：xx业务团队参与每周项目例会，提出调整意见xx技术团队确保系统环境、网络通讯可用参与分析应用开发讨论科技实施团队按技术蓝图设计搭建系统环境按技术蓝图开发BI数据模型按技术蓝图开发BI分析应用交付件：BI分析应用模型3.3数据仓库整体方案3.3.1数仓的定义数据仓库是决策支持系统和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。1、数据仓库是面向主题的；操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。2、数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库；数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。3、数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的操作主要是数据的查询；4、数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。5、汇总的。操作性数据映射成决策可用的格式。6、大容量。时间序列数据集合通常都非常大。7、非规范化的,DW数据可以是而且经常是冗余的。8、元数据。将描述数据的数据保存起来。9、数据源。数据来自内部的和外部的非集成操作系统。3.3.2数据仓库的特点数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它并不是所谓的“大型数据库”。数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库往往有如下几点特点：1.效率足够高。数据仓库的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好2.数据质量。数据仓库所提供的各种信息，肯定要准确的数据，但由于数据仓库流程通常分为多个步骤，包括数据清洗，装载，查询，展现等等，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，未来不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。从上面的介绍中可以看出，数据仓库技术可以将企业多年积累的数据唤醒，不仅为企业管理好这些海量数据，而且挖掘数据潜在的价值，从而成为通信企业运营维护系统的亮点之一。正因为如此，广义的说，基于数据仓库的决策支持系统由三个部件组成：数据仓库技术，联机分析处理技术和数据挖掘技术，其中数据仓库技术是系统的核心，在这个系列后面的文章里，将围绕数据仓库技术，介绍现代数据仓库的主要技术和数据处理的主要步骤，讨论在通信运营维护系统中如何使用这些技术为运营维护带来帮助。4.面向主题操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。主题是与传统数据库的面向应用相对应的，是一个抽象概念，是在较高层次上将企业信息系统中的数据综合、归类并进行分析利用的抽象。每一个主题对应一个宏观的分析领域。数据仓库排除对于决策无用的数据，提供特定主题的简明视图。数据仓库是面向主题的、集成的、不可更新的、随时间的变化而不断变化的，这些特点决定了数据仓库的系统设计不能采用同开发传统的OLTP数据库一样的设计方法。数据仓库的设计是数据驱动的，这是因为数据仓库是在现存数据库系统基础上进行开发，它着眼于有效地抽取、综合、集成和挖掘已有数据库的数据资源，服务于企业高层领导管理决策分析的需要。基于科技在数据仓库建设领域的实施经验，我们将数据仓库实施的具体步骤分为两个阶段、12个步骤：3.3.2数据仓库具体实施步骤1、项目前期准备参与人员：项目管理委员会成员xx业务团队xx技术团队科技实施团队主要任务：项目启动会议（Kick-offMeeting）确认项目范围和主要目标确认项目阶段性验收及总体验收标准确认项目实施计划成立项目组确定各项目小组的成员及各自的工作职责确定各项目小组的阶段性工作目标确定知识转移计划确定服务流程及方式交付件：《项目组织机构及成员组成》《项目成员角色和职责》《项目实施计划书》2、业务探索（BusinessDiscovery）参与人员：xx业务团队xx技术团队科技实施团队主要任务：确定重点用户与数据源用户需求调研与确认数据来源确认用户需求和数据源的筛选、分析交付件：《业务需求说明书BRL（BusinessRequirementList）》《概念数据模型CDM（ConceptualDataModel）》3、信息探索（InformationDiscovery）参与人员：xx技术团队科技实施团队主要任务：分析用户需求数据源分析系统安全性设计系统命名规范设计交付件：《功能需求列表FRL（FunctionRequirementList）》《系统安全性设计说明书》《系统命名规范说明书》《数据质量分析》4、逻辑数据模型设计参与人员：xx技术团队科技实施团队主要任务：进行原始数据分析建立实体模型建立实体间依赖关系完善并填入所有属性建立数据库逻辑模型交付件：数据仓库逻辑数据模型《逻辑数据模型说明书》逻辑数据模型是用来发现、记录和沟通业务的详细“蓝图”，其具备以下特征：基于概念数据模型（CDM）由一系列表和实体详细描述组成通用的业务语言便于业务与业务之间的功能理解集成当前和未来数据的蓝图独立于技术为物理数据库设计做准备是IT人员和业务人员沟通的工具5、系统体系结构设计参与人员：xx业务团队xx技术团队科技实施团队主要任务：对业务、技术环境及企业文化的充分了解，从技术、组织、教育和支持等方面对系统进行全面评估定义业务驱动力定义数据仓库成功的关键因素定义数据仓库的实施原则对系统体系结构各个组件进行详细设计交付件：《系统体系结构设计说明书》6、物理数据库设计参与人员：xx技术团队科技实施团队主要任务：转换逻辑数据模型为物理数据模型定义主索引、次索引非正规化处理（Denormalizations）物理非正规化派生数据（DerivedData）汇总表（SummaryTables）重复的Groups（RepeatingGroups）多物理表（MultiplePhysicalTables）预连接（Pre-joins）子实体（Sub-entities）逻辑非正规化视图（Views）逻辑星型结构（LogicalStarSchemas）物理非正规化对模型的灵活性会有影响逻辑非正规化是一个优选的方案数据库建立第三范式–3NF星型结构雪花结构设计优化数据库功能测试交付件：物理数据模型（PDM）《物理数据模型说明书》《数据库描述语言DDL》3.4数据治理整体方案Navigator是唯一原生在Hadoop生态系统上的并提供全面数据管理服务的一套解决方案。该产品通过统一的用户接口可以有效协助系统管理员、数据经理以及分析师对数据湖中各式各样的数据进行管治、分类与探索。大体上而言，Navigator提供了3类最核心的功能：审计与访问管理：维护完整的数据访问、数据操作审计历史以满足合规需求。同时帮助系统管理员快速验证用户/用户组在Hadoop集群中数据集合的访问权限（permission）正确性；权限视图查看用户/用户组对HDFS、Impala、Hive和HBase的访问权限以保证对隐私及合规的正确配置审计配置对HDFS