04 XX项目数据库设计说明书-Vx.y2021

XX项目数据库设计说明书文件状态：[]草稿[√]正式发布[]正在修改版本：编写：审核：批准：审批日期：1、状态：对于基线库文档，应为“正式发布”；2、版本：对于基线库文档，指经过客户确认的版本，从1.0开始整数计数，2.0,3.0。。。；1、状态：对于基线库文档，应为“正式发布”；2、版本：对于基线库文档，指经过客户确认的版本，从1.0开始整数计数，2.0,3.0。。。；3、编写：文档的主要编写人员；4、审核：审核包括技术审核、规范性审核，根据实际情况，可以填写多人，如项目经理，项目管理中心QA，领导指定人员等；5、批准：各里程碑节点的批准人：需求文档：重大项目-业务总监，非重大-部门经理设计文档：重大项目-业务总监、架构师，非重大-部门经理测试文档：重大项目-业务总监，非重大-项目管理中心经理里程碑其他文档（如工作报告，安装部署、运维手册、使用手册等）：重大项目-业务总监，非重大项目-部门经理重大项目：软件开发项目100万以上，运维项目200万以上，气象服务项目50万以上华云信息技术工程有限公司XX项目数据库设计说明书华云信息技术工程有限公司 I文件更改历史记录文件编号：HX-SD-项目英文缩写-PDD-版本号更改记录版本号更改要点修改人审批人批准日期1.0正式发布尹玉梅王桂娟2013.4.2模板编号：HX-SD-IV-PDD版本：1.0PDD:PreliminaryDesignDocument使用本模板时，请删除模板更改记录，填写项目文档的版本信息。目录1引言 11.1目的 11.2背景 11.3数据库概述 11.4术语 11.5参考资料 22数据库设计决策 32.1输入输出查询决策 32.2数据库响应时间设计决策 32.3数据呈现方式决策 32.4数据库系统选型决策 32.5数据库安全性设计决策 42.6分布式设计决策 42.7备份/恢复机制决策 42.8数据一致性设计决策 43数据库设计 53.1数据分类 53.1.1业务域描述 53.1.2分类原则 53.1.3分类内容 53.2数据模型设计 63.2.1总体描述 63.2.2概念模型设计 63.2.3逻辑模型设计 73.2.4物理模型设计 93.3数据流程设计 103.4数据库总体设计 113.4.1设计原则 113.4.2设计目标 113.4.3总体逻辑架构设计 123.4.4总体物理架构设计 133.5数据分布设计 143.5.1数据逻辑分布 143.5.2数据物理分布 143.6数据存储设计 153.6.1文件存储区设计原则 163.6.2文件存储区容量估算 163.6.3RDBMS设计原则 163.6.4RDBMS容量估算 163.6.5文件存储区设计 163.6.6RDBMS设计 173.7数据计算 183.7.1批处理 183.7.2流式处理 233.8数据服务 353.8.1数据访问接口 363.8.2数据服务管理 363.8.3数据共享服务 363.8.4数据交换服务 363.8.5元数据服务 363.9数据治理（可裁剪） 363.9.1元数据管理 373.9.2生命周期管理 373.9.3数据质量管理 373.10数据安全设计（可裁剪） 373.10.1数据安全特性与技术 383.10.2安全审计 383.10.3访问控制 383.10.4数据加密 393.10.5数据迁移 393.10.6数据恢复与备份 391附录：标题一 401.1标题二 401.1.1标题三 402附录：模板使用说明 412.1文档模板相关快捷键使用说明 412.1.1标题栏 412.1.2正文栏 412.1.3可选栏 412.2整体需要注意的地方 423附录：图表编辑要求 433.1图编辑要求 433.2表编辑要求 434附录：如何避免文档打印时出问题 454.1避免图出问题 454.2避免表出问题 45引言【总体说明：1.编写文档时，如果某章节/栏目不适用或不涉及，应注明。并在可能的情况下说明理由。必要时，可增加适当的条目。2.本模板中“【…】”内容均为填写说明；在使用时请将其删除。3.附录为文档模板使用说明，包括标题格式、图表的编辑等都有说明，请编写文档时参照。文档编写完成后，请将附录几个章节删除。】目的【说明编写本软件数据库设计说明书的目的，指出预期的读者。】背景【说明待开发产品或项目（以下简称产品）的名称。列出此开发任务的提出者、开发者、用户等。】数据库概述本条应简述本文档适用的数据库的用途。它应描述数据库的一般性质；概括它的开发、使用和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。术语【说明本文档中的专门术语定义和英文缩写词的原词组。】参考资料【列出本文档中参考文件、资料或技术标准；列出其作者、标题或编号、发布日期或出版单位或网址。列出本文档中引用的属于本开发产品/软件系统的其他文件。】数据库设计决策本章应根据需要分条给出数据库级设计决策，即数据库行为设计决策(从用户的角度看，该数据库如何满足它的需求而忽略内部实现)和其他影响数据库进一步设计的决策。如果所有这些决策在系统或CSCI需求中均是明确的，本章应如实陈述。对应于指定为关键性需求(如安全性、保密性、私密性需求)的设计决策，应在单独的条中加以描述。如果设计决策依赖于系统状态或方式，则应指出这种依赖性。如果设计决策的部分或全部已在定制的或商用的数据库管理系统(DBMS)的文档中作了描述，本章可引用它们。输入输出查询决策关于该数据库应接受的查询或其他输入和它应产生的输出(显示、报告、消息、响应等)的设计决策，包括与其他系统、HWCI,CSCI和用户的接口。如果该信息的部分或全部已在接口设计说明(IDD)中给出，此处可引用。数据库响应时间设计决策有关响应每次输入或查询的数据库行为的设计决策，包括动作、响应时间和其他性能特性、所选择的方程式/算法/规则、配置和对不允许的输入的处理。数据呈现方式决策有关数据库/数据文件如何呈现给用户的设计决策。数据库系统选型决策有关要使用什么数据库管理系统(包括名字、版本/发行)的设计决策和为适应需求的变化而引人到数据库内部的灵活性类型的设计决策。数据库安全性设计决策有关数据库要提供的可用性、保密性、私密性和运行连续性的层次与类型的设计决策。分布式设计决策有关数据库的分布(如客户机/服务器)、主数据库文件更新与维护的设计决策，包括一致性的维护、同步的建立/重建与维护、完整性与业务规则的实施等。备份/恢复机制决策有关备份与恢复的设计决策，包括数据与处理分布策略、备份与恢复期间所允许的动作、对例如音像等新技术或非标准技术的特殊考虑。数据一致性设计决策有关重组、排序、索引、同步与一致性的设计决策，包括自动的盘管理与空间回收、优化策略、存储与空间大小、数据库内容的填充与历史数据的捕获等方面的考虑。数据库设计数据分类业务域描述从业务域的角度描述本系统不同的业务领域可能涉及的数据。例如：模式二期项目的业务域包括HPC资源域、业务运行监视域、模式试验域、模式产品域、业务信息域等等。针对这些业务域进行简单的描述，并重点描述每个业务域内所涉及的数据，可以以清单的形式展示。HPC资源域1、计算资源数据指标编号指标名称001计算机系统的cpu总核小时002计算机系统的cpu使用核小时003用户的cpu总核小时004用户的cpu使用核小时分类原则描述针对本系统从系统设计的角度对数据重新分类的原则。按照业务分类？按照数据的属性分类？按照使用方式分类等。分类内容针对本系统所涉及的数据，按照上述的分类原则进行数据的分类。比如按照气象数据的标准分类，把每一类设计的内容进行清单罗列。数据模型设计总体描述数据的基本结构分三个层次，反映了观察数据的三种不同角度。(1)概念数据层。它是数据的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系，是存贮记录的集合。它所涉及的是数据所有对象的逻辑关系，而不是它们的物理情况。(2)物理数据层。它是物理存贮设备上实际存储的数据的集合。这些数据是原始数据，是用户加工的对象，由内部模式描述的指令操作处理的位串、字符和字组成。(3)逻辑数据层。它是用户所看到和使用的数据，表示了一个或一些特定用户使用的数据集合，即逻辑记录的集合。 数据建模概念模型设计概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，它以数据类的方式描述企业级的数据需求，数据类代表了在业务环境中自然聚集成的几个主要类别数据。概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性，也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系。根据业务域的划分，梳理跨业务域的端到端的业务流程，从而梳理出大的对象之间的关系和小的业务流程。例如，用户（user）E－R图逻辑模型设计逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑数据在物理上如何来实现。逻辑数据建模不仅会影响数据库设计的方向，还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多，那么在物理数据模型设计时就可以有许多可供选择的方法。解决端到端的业务流程梳理出大量的小流程和对象关系，进一步梳理出各个业务域的业务对象及其行为和属性。这是以图形的形式表示的数据的逻辑模型以表格的形式表示的关系数据库表也是逻辑模型的一种；【包括表、索引、视图、规则、触发器、存储过程、用户、序列等数据库对象的结构和功能设计，应根据统一的命名规则对数据库对象进行标识。如：表结构设计可参考下表。如：表结构设计可参考下表。】序号字段中文名称字段名数据类型长度是否主键缺省值说明非关系数据文件的逻辑表达如下图所示：注意：数据的逻辑模型与具体的数据库系统无关！！！物理模型设计数据库物理设计是将一个给定逻辑结构实施到具体的环境中时，为逻辑数据模型选取一个具体的工作环境，这个工作环境提供了数据存储结构与存取方法，这个过程就是数据库的物理设计。物理结构依赖于给定的DBMS和和硬件系统，因此设计人员必须充分了解所用RDBMS的内部特征、存储结构、存取方法。数据库的物理设计通常分为两步，第一，确定数据库的物理结构，第二，评价实施空间效率和时间效率确定数据库的物理结构包含下面几个方面的内容：1、选择存取方法：是通过一般索引机制或者聚族索引机制等。2、设计存储结构：存储方法一般有顺序存储、链接存储、索引存储、散列存储等方法。3、确定存放位置：文件存放的目录结构及其路径等。4、选择存储介质：数据将要存储在什么物理介质上，是磁盘、磁盘阵列还是磁带库等等5、评价物理结构：针对各种物理结构的存储进行评价，选择最优的存储。数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，选择一个优化方案作为数据库物理结构。在数据库物理设计中，最有效的方式是集中地存储和检索对象数据流程设计数据流图示例数据库总体设计设计原则说明设计的原则，一般原则描述可以从整体性原则、标准化原则、安全与效率并种的原则、一致性原则等。设计目标总体目标主要包括以下五个方面内容：1、实现信息资源整合信息资源规划的一项很重要的目标就是要解决目前信息系统建设中的重复建设问题，达到信息系统的整合和集约，信息资源规划是信息系统顶层设计的一部分，能够从整体上对信息资源进行设计，并能够提供信息系统建设的标准和规范，这样信息系统就能够以此为标准，进行适时、适度、逐步整合，最终达到消除冗余，集约良性发展的效果。2、提高技术响应速度业务需求的变化和技术的响应速度之间一直是一对矛盾，信息资源规划通过对信息系统，尤其是信息资源架构进行科学设计，可以增强信息资源架构的稳定性，当业务需求变化时，可以通过很少的数据结构和程序变动就能够满足业务需求，这样不但提高了技术响应速度，而且能够增强系统的稳定性，降低故障率。3、实现信息共享信息资源规划通过建设信息共享服务平台，实现了数据的集中存储和计算，并实现了对外统一的服务接口，不论是对于海关内部的信息共享需求，还是外部的数据共享需求；不论是直接面向用户的共享查询，还是面向应用系统的数据服务，都可以通过数据服务共享平台解决。4、实现大数据分析必须实现信息系统的物联化、互联化、智能化，而最重要的就是智能化，即通过大数据分析，为海关准确决策提供信息支持。信息资源规划通过设计和实现数据共享服务平台，引入并行数据库、分布式数据库等大数据存储和计算技术，能够解决海关的大数据分析问题，达到数据用得好、决策准的业务目标。5、提升数据质量信息资源规划通过设定标准规范、业务管理流程，能够规范数据的定义、存储、使用、传输、交换，使得数据采集更加规范、数据传输更加准确高效，数据使用更加安全方便，通过各种管理流程和规范，能够大幅提升数据质量。总体逻辑架构设计图：数据架构总体逻辑蓝图数据架构的六个统一，即统一数据规划、统一存储、统一计算、统一服务、统一接入、统一数据治理。总体物理架构设计通过万兆连接核心交换区，实现网络高速交换，确保可靠性各服务器均双线连接数据区核心交换机，消除单点故障结构清晰，层次分明数据分布设计数据逻辑分布数据分类从数据本身的原则属性角度对数据从系统管理、数据存储、数据处理的角度进行分类，那么这些数据与业务系统本身的关系是如何对应的，本章节描述的是业务系统与数据分类后的对应关系。以表格的形式展现系统名称分系统名称系统应用类型业务应用类数据业务分析类数据HPC资源精细化管理分系统实时性要求高数据物理分布数据存放：集中存放+灾备？分布式主从模式？分布式无中心化？数据：核心交易：商用关系DB+小机集群？分析：newSQL+小机集群？低价值密度的大规模数据：NoSQL+大规模普通机器集群据地理分布：交易数据集中存放+灾备；其他管理支持类应用数据可三中心分别存放？数据存储设计【先说明本系统数据类型、数据流、数据存储结构，然后再按照下面章节内容描述设计。】文件存储区设计原则文件存储区容量估算RDBMS设计原则RDBMS容量估算文件存储区设计存储区域划分【本节应列出存储区域划分结构图和针对每一个存储区域的功能和业务处理说明。】存储区目录结构设计1【针对每一个存储区域的目录结构进行详细说明。通过目录规划图和目录结构说明表描述所划分的目录结构，以及其存储目录所完成的功能和业务处理。如需要，指出目录结构中的文件命名及文件结构。】目录结构例如：序号目录名称目录说明存储容量清除策略目录结构说明【描述其存储目录所完成的功能和业务处理进行必要的说明。涉及软件配置项的则应给出或引用为理解设计所需的设计约定。】文件命名及文件结构【如需要，对特定目录下的文件命名和文件结构进行设计。如果在需求基线或IDD/PDD中已有描述，在此可进行引用。】RDBMS设计数据库表存储结构设计【描述数据和数据库对象的存放位置和存储结构，包括确定关系表、索引、日志、备份等的存储安排及存储结构。确定数据存放位置是按照数据应用的不同将数据库的数据划分为若干类，并确定各类数据的大小和存放位置。数据的分类可依据数据的稳定性、存取响应速度、存取频度、数据共享程度、数据保密程度、数据生命周期的长短、数据使用的频度等因素加以区别。确定数据存放的位置主要是从提高系统性能的角度考虑。如果在概要设计阶段数据库平台产品的选型已经确定，本节应结合具体的平台产品进行描述。】存储参数配置设计【对数据库平台产品的存储参数的配置变量进行初步的调整设计。如果在概要设计阶段数据库平台产品的选型未能确定，本部分内容可在详细设计阶段进行。】数据计算本章描述数据层面上的数据计算架构。从数据层，可以将数据计算分成实时性的流处理模型，和以MapReduce和OLAP多维分析计算为代表的批处理。数据计算可以采取目前对数据计算处理的多种方式的其中一种或多种来设计描述。比如MapReduce批处理、Storm的流式计算等。批处理满足非实时数据处理业务场景，将批量数据以任务的方式进行处理，并以异步方式提交计算结果，典型场景包括：数据挖掘模型计算、指标引擎计算、OLAP多维分析计算、MapReduce批处理等。数据挖掘模型计算，可以依靠传统的自我编程实现，但受限于开发水平和开发时间要求，且性能也常常不如商业工具强劲和稳定。目前在中国市场上最为流行的三大数据挖掘软件(SAS公司的EnterpriseMiner、IBM公司的IntelligentMiner和SPSS公司的Clementine。在选择合适的数据发掘工具产品时，需要考虑以下几点：数据挖掘是短期使用还是长期行为，数据挖掘经验和水平，数据状态，预算和性能要求。指标引擎计算与OLAP多维分析计算，可以通过关系型数据库计算引擎，在库内实现。考虑数据量级和计算性能，建议使用完全并行的MPP+SharedNothing架构数据库产品，由许多松耦合的处理单元组成，以保证每一个节点（node）都是独立的、自给的、节点之间对等，而且整个系统中不存在单点瓶颈，具有非常强的扩展性。技术要求：1、支持X86PCserver以及虚拟化环境运行，具有低成本优势；2、采用列存储和高效透明压缩技术，降低I/O，提高存储能力；3、具有基于全部字段，自动建立粗粒度智能索引，快速过滤数据包，提高查询性能；4、具有多种数据分布算法策略，确保数据均匀分布在集群节点上，提高整体批量计算性能；5、利用多核CPU，多个I/O通道等硬件资源，具有并行加载，并行计算与并行导出等场景的良好性能；6、具有多种OLAP函数，支持动态hashjoin，静态hashjoin等智能算法适配功能，满足强一致性关联要求；图SEQ图\*ARABIC2静态hashjoin技术图SEQ图\*ARABIC3动态hashjoin技术具有高并发特点，有效支撑自助查询等大规模查询服务和批量调度任务；8、具有线性扩展能力，硬件扩容与计算能力近似线性增长关系。MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。概念"Map（映射）"和"Reduce（规约）"，主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。当前的实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（规约）函数，用来保证所有映射的键值对中的每一个共享相同的键组。实现过程：一个代表客户机在单个主系统上启动的MapReduce应用程序称为JobTracker。类似于NameNode，它是Hadoop集群中惟一负责控制MapReduce应用程序的系统。在应用程序提交之后，将提供包含在HDFS中的输入和输出目录。JobTracker使用文件块信息（物理量和位置）确定如何创建其他TaskTracker从属任务。MapReduce应用程序被复制到每个出现输入文件块的节点。将为特定节点上的每个文件块创建一个惟一的从属任务。每个TaskTracker将状态和完成信息报告给JobTracker。流式处理满足实时处理业务场景，实现数据的实时，高效处理计算。典型产品包括：storm，S4，StreamBase等。非实时计算几乎都基于MapReduce计算框架，但MapReduce并不是万能的。对于搜索等应用环境中的某些现实问题，MapReduce并不能很好地解决问题。商用搜索引擎，像Google、Bing和Yahoo!等，通常在用户查询响应中提供结构化的Web结果，同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告，通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询，每个页面都可能会包含多个广告。为了及时处理用户反馈，需要一个低延迟、可扩展、高可靠的处理引擎。然而，对于这些实时性要求很高的应用，尽管MapReduce作了实时性改进，但仍很难稳定地满足应用需求。因为Hadoop为批处理作了高度优化，MapReduce系统典型地通过调度批量任务来操作静态数据；而流式计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配，或者通过近似算法等方法优雅降级，通常称为负载分流（load-shedding）。当然，除了负载分流，流式计算的容错处理等机制也和批处理计算不尽相同。最近Facebook在Sigmod11上发表了利用HBase/Hadoop进行实时数据处理的论文，通过一些实时性改造，让批处理计算平台也具备实时计算的能力。这类基于MapReduce进行流式处理的方案有三个主要缺点。将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟，增加附加开销，并且分段之间的依赖管理更加复杂（例如一个分段可能会需要前一个分段的信息）；反之，大的分段会增加延迟。最优的分段大小取决于具体应用。为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接输出；考虑到效率，中间结果最好只保存在内存中等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。综上所述，流式处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理计算的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。数据分析系统整体组成示意图上图从整个分析系统的架构角度，给出了实时计算子系统所处的位置。实时计算系统和批处理计算系统同属于计算这个大的范畴，批处理计算可以是MapReduce、MPI、SCOPE等，实时计算可以是S4、Storm等，批处理和实时都可以或不依赖统一的资源调度系统。另外，计算系统的输入、输出，包括中间过程的输入、输出，都与存储系统交互，可以是块存储系统HDFS，也可以是K-V存储系统Hypertable等。计算层的上层是数据仓库，或者直接和用户交互，交互方式可以是SQL-like或者MR-like等。StormStorm是一个分布式的、容错的实时计算系统，遵循EclipsePublicLicense1.0,Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm之于实时处理，就好比Hadoop之于批处理。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。可以使用任意编程语言来做开发。主要商业应用及案例：TwitterStorm的优点1.简单的编程模型。类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。2.服务化,一个服务框架,支持热部署,即时上线或下线App.3.可以使用各种编程语言。你可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持，只需实现一个简单的Storm通信协议即可。4.容错性。Storm会管理工作进程和节点的故障。5.水平扩展。计算是在多个线程、进程和服务器之间并行进行的。6.可靠的消息处理。Storm保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息。7.快速。系统的设计保证了消息能得到快速的处理，使用ZeroMQ作为其底层消息队列。8.本地模式。Storm有一个“本地模式”，可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试。Storm架构Storm集群由一个主节点和多个工作节点组成。主节点运行了一个名为“Nimbus”的守护进程，用于分配代码、布置任务及故障检测。每个工作节点都运行了一个名为“Supervisor”的守护进程，用于监听工作，开始并终止工作进程。Nimbus和Supervisor都能快速失败，而且是无状态的，这样一来它们就变得十分健壮，两者的协调工作是由Zookeeper来完成的。ZooKeeper用于管理集群中的不同组件，ZeroMQ是内部消息系统，JZMQ是ZeroMQMQ的JavaBinding。有个名为storm-deploy的子项目，可以在AWS上一键部署Storm集群.Storm的一些常用应用场景1.流聚合

流聚合把两个或者多个数据流聚合成一个数据流—基于一些共同的tuple字段。2.批处理

有时候为了性能或者一些别的原因，你可能想把一组tuple一起处理，而不是一个个单独处理。3.BasicBolt1).读一个输入tuple2).根据这个输入tuple发射一个或者多个tuple3).在execute的方法的最后ack那个输入tuple遵循这类模式的bolt一般是函数或者是过滤器,这种模式太常见，storm为这类模式单独封装了一个接口:IbasicBolt4.内存内缓存+Fieldsgrouping组合

在bolt的内存里面缓存一些东西非常常见。缓存在和fieldsgrouping结合起来之后就更有用了。比如，你有一个bolt把短链接变成长链接(bit.ly,t.co之类的)。你可以把短链接到长链接的对应关系利用LRU算法缓存在内存里面以避免重复计算。比如组件一发射短链接，组件二把短链接转化成长链接并缓存在内存里面。5.计算topN

比如你有一个bolt发射这样的tuple:"value","count"并且你想一个bolt基于这些信息算出topN的tuple。最简单的办法是有一个bolt可以做一个全局的grouping的动作并且在内存里面保持这topN的值。

这个方式对于大数据量的流显然是没有扩展性的，因为所有的数据会被发到同一台机器。一个更好的方法是在多台机器上面并行的计算这个流每一部分的topN,然后再有一个bolt合并这些机器上面所算出来的topN以算出最后的topN。这个模式之所以可以成功是因为第一个bolt的fieldsgrouping使得这种并行算法在语义上是正确的。

用TimeCacheMap来高效地保存一个最近被更新的对象的缓存6.用TimeCacheMap来高效地保存一个最近被更新的对象的缓存

有时候你想在内存里面保存一些最近活跃的对象，以及那些不再活跃的对象。TimeCacheMap是一个非常高效的数据结构，它提供了一些callback函数使得我们在对象不再活跃的时候我们可以做一些事情.7.分布式RPC:CoordinatedBolt和KeyedFairBolt

用storm做分布式RPC应用的时候有两种比较常见的模式:它们被封装在CoordinatedBolt和KeyedFairBolt里面.CoordinatedBolt包装你的bolt,并且确定什么时候你的bolt已经接收到所有的tuple,它主要使用DirectStream来做这个.

KeyedFairBolt同样包装你的bolt并且保证你的topology同时处理多个DRPC调用，而不是串行地一次只执行一个。S4S4是一个通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统。基于S4框架，开发者可以轻松开发面向持续流数据处理的应用。S4的设计特点有以下几个方面。ActorModel为了能在普通机型构成的集群上进行分布式处理，并且集群内部不使用共享内存，S4架构采用了Actor模式，这种模式提供了封装和地址透明语义，因此在允许应用大规模并发的同时，也提供了简单的编程接口。S4系统通过处理单元（ProcessingElements，PEs）进行计算，消息在处理单元间以数据事件的形式传送，PE消费事件，发出一个或多个可能被其他PE处理的事件，或者直接发布结果。每个PE的状态对于其他PE不可见，PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到合适的PE和创建新PE实例的功能。S4的设计模式符合封装和地址透明的特性。DecentralizedandSymmetricArchitecture除了遵循Actor模式，S4也参照了MapReduce模式。为了简化部署和运维，从而达到更好地稳定性和扩展性，S4采用了对等架构，集群中的所有处理节点都是等同的，没有中心控制。这种架构将使得集群的扩展性很好，处理节点的总数理论上无上限；同时，S4将没有单点容错的问题。PluggableArchitectureS4系统使用Java开发，采用了极富层次的模块化编程，每个通用功能点都尽量抽象出来作为通用模块，而且尽可能让各模块实现可定制化。PartialFault-Tolerance基于Zookeeper服务的集群管理层将会自动路由事件从失效节点到其他节点。除非显式保存到持久性存储，否则节点故障时，节点上处理事件的状态会丢失。ObjectOriented节点间通信采用“PlainOldJavaObjects”（POJOs）模式，应用开发者不需要写Schemas或用哈希表来在节点间发送Tuples。S4的功能组件分3大类，Clients、Adapters和PNodeCluster，图2显示了S4系统框架。

Yahoo!S4流式系统框架结构图

S4提供ClientAdapter，允许第三方客户端向S4集群发送事件和接收事件。Adapter实现了基于JSON的API，支持多语言实现的客户端驱动。Client通过Driver组件与Adapter进行交互，Adapter也是一个Cluster，其中有多个Adapter结点，Client可以通过多个Driver与多个Adapter进行通信，这样可以保证单个Client在分发大数据量时Adapter不会成为瓶颈，也可以确保系统支持多个Client应用并发执行的快速、高效和可靠性。在Adapter中，真正与Client交互的是其Stub组件，该组件实现了管理Client与Adapter之间通过TCP/IP协议进行通信的功能。GenericJsonClientStub这个类支持将事件在Client与Adapter之间以JSON的形式转换，从而支持更多种类型的Client应用。不同的Client可以配置不同的Stub来与Adapter进行通信，用户可以定义自己的Stub来实现自己想要的业务逻辑，这样也使得Client的行为更加多样性、个性化。StreamBaseStreamBase是IBM开发的一款商业流式计算系统，在金融行业和政府部门使用，其本身是商业应用软件，但提供了DevelopEdition。相对于付费使用的EnterpriseEdition，前者的功能更少，但这并不妨碍我们从外部使用和API接口来对StreamBase本身进行分析。StreamBase使用Java开发，IDE是基于Eclipse进行二次开发，功能非常强大。StreamBase也提供了相当多的Operator、Functor以及其他组件来帮助构建应用程序。用户只需要通过IDE拖拉控件，然后关联一下，设置好传输的Schema并且设置一下控件计算过程，就可以编译出一个高效处理的流式应用程序了。同时，StreamBase还提供了类SQL语言来描述计算过程。

StreamBase组件交互图

StreamBaseServer是节点上启动的管理进程，它负责管理节点上Container的实例，每个Container通过Adapter获得输入，交给应用逻辑进行计算，然后通过Adapter进行输出。各个Container相互连接，形成一个计算流图。Adapter负责与异构输入或输出交互，源或目的地可能包括CSV文件、JDBC、JMS、Simulation（StreamBase提供的流产生模拟器）或用户定制。

每个StreamBaseServer上面都会存在一个SytsemContainer，主要是产生系统监控信息的流式数据。HAContainer用于容错恢复，可以看出它实际包含两个部分：Heartbeat和HAEvents，其中HeartBeat也是Tuple在Container之间传输。在HA方案下，HAContainer监控PrimaryServer的活动情况，然后将这些信息转换成为HAEvents交给StreamBaseMonitor来处理。Monitor就是从SystemContainer和HAContainer中获取数据并且进行处理。StreamBase认为HA问题应该通过CEP方式处理，也就是说如果哪个部件出现问题，就肯定会反映在SystemContainer和HAContainer的输出流上面，然后Monitor通过复杂事件处理这些Tuples的话就能够检测到机器故障等问题，并作出相应处理。StreamBase提出了以下4种模板策略来解决容错问题。Hot-HotServerPairTemplatePrimaryServer和SecondaryServer都在同时计算，并且将计算结果交给下游。优点是PrimaryServer如果故障的话那么SecondaryServer依然工作，几乎没有任何切换时间；并且下游只需要选取先到来的Tuple就可以处理了，保证处理速度最快；缺点是浪费计算和网络资源。Hot-WarmServerPairTemplatePrimaryServer和SecondaryServer都在同时计算，但只有PrimaryServer将计算结果交给下游。优点是如果PrimaryServer故障，SecondaryServer可以很快切换，而不需要任何恢复状态的工作。相对于Hot-Hot方式时间稍微长一些，但没有Hot-Hot那么耗费网络资源，同时也浪费了计算资源。SharedDiskTemplatePrimaryServer在计算之后，将计算的一些中间关键状态存储到磁盘、SAN（StorageAreaNetwork）或是可靠的存储介质。如果SrimaryServer故障，SecondaryServer会从介质中读取出关键状态，然后接着继续计算。优点是没有浪费任何计算和网路资源，但恢复时间依赖状态的量级而定，相对于前两种，恢复时间可能会稍长。FastRestartTemplate这种方案限定了应用场景，只针对无状态的应用。对于无状态的情况，方案可以非常简单，只要发现PrimaryServer故障，SecondaryServer立即启动，并接着上游的数据流继续计算即可。BorealisBorealis是BrandeisUniversity、BrownUniversity和MIT合作开发的一个分布式流式系统，由之前的流式系统Aurora、Medusa演化而来。目前Borealis系统已经停止维护，最新的Release版本停止在2008年。Borealis具有丰富的论文、完整的用户/开发者文档，系统是C++实现的，运行于x86-basedLinux平台。系统是开源的，同时使用了较多的第三方开源组件，包括用于查询语言翻译的ANTLR、C++的网络编程框架库NMSTL等。Borealis系统的流式模型和其他流式系统基本一致：接受多元的数据流和输出，为了容错，采用确定性计算，对于容错性要求高的系统，会对输入流使用算子进行定序。Borealis的系统架构图QueryProcessor（QP）是计算执行的地方，是系统的核心部件，其大部分功能继承自Aurora。I/OQueues将数据流导入QP，路由Tuples到其他节点或客户端程序。Admin模块用来控制本地的QP，例如建立查询、迁移数据流图片段，该模块也会同LocalOptimizer协作优化现有数据流图。LocalOptimizer职责包括本地调度策略、调整Operator行为、超载后丢弃低价值元组等。StorageManager模块用于存储本地计算的状态数据。LocalCatalog存储本地数据流图和元数据，可以被本地所有组件访问。BorealisNode还有彼此通信的模块用于执行协作任务。NeighborhoodOptimizer使用本地和邻居节点来优化节点间的负载均衡或shedload。HighAvailability（HA）模块相互监测，发现对方故障时及时代替对方。LocalMonitor收集本地性能相关统计数字报告给本地和NeighborhoodOptimizer。GlobalCatalog为整个数据流计算提供了一个逻辑上的完整视图。除作为基本功能节点外，BorealisServer也可以被设计成一个协作节点来执行全局的系统监控和其他优化任务，比如全局的负载分布和GlobalLoadShedding，因此Borealis实际上提供了完整的3级监控和优化（Local、Neighborhood、Global）。负载均衡方面，Borealis提供了动态和静态两种部署机制。Correlation-basedOperatorDistribution通过分析不同Operators和Nodes间的负载变化的关系，决定和动态调整Operatpr的部署，使之达到负载均衡。ResilientOperatorDistributionAlgorithm该算法的目标是提供一种静态的Operator部署方案，该方案能够在不需要重新调整的情况下处理最大可能的输入速度变化范围。由于动态调整需要时间和消耗，前者适用于负载变化持续时间较长的系统；而后者则能处理较快较短的负载峰值。在实现上前者使用相关系数作为节点关联度指标，并通过贪婪算法将NP问题转化为多项式求解；而后者在部署前计算完毕，保证系统能够容忍负载峰值。该算法在线性代数上建模，包括OperatorOrdering、OperatorAssignment两个阶段。Borealis通过四种容错机制来满足用户需求。AmnesiaBackup备机发现主机故障，立即从一个空的状态开始重做。PassiveStandby主机处理，备机待命，主机按周期做Checkpoint，主机故障后切换到备机，重放Checkpoint和数据流，对于不确定性计算可以很好地支持，缺点是恢复时间较长。ActiveStandby主备机同时计算，主机故障时直接切换到备机，不支持不确定性计算，浪费计算资源，不过恢复时间几乎没有。UpstreamBackup通过上游备份来容错，故障时从上游重放数据即可，恢复时间最长，不过最节省资源。除此之外，Borealis还提供了更高级的容错机制RollbackRecovery，它是一种基于副本在节点失效、网络失效或网络分区时的故障恢复机制，在尽量减少系统不一致的情况下，尽可能地保证系统的可用性。该机制允许用户定义一个阈值来在一致性和可用性之间做一个平衡。当系统数据恢复后，系统支持重新计算输出正确的结果，保证最终一致性。该机制使用了Data-serializingOperator（SUnion）来确保所有的副本处理同样顺序的数据。当失效恢复后，通过Checkpoint/Redo、Undo/Redo来实现恢复重放。数据服务数据服务主要描述数据访问接口，数据服务管理、数据共享服务、数据交换服务、元数据服务等。数据访问接口API形式、图形表格形式等。数据服务管理数据共享服务数据交换服务元数据服务数据治理（可裁剪）数据治理体系建设的目的，是建立数据拥有者、使用者、数据以及支撑系统之间的和谐互补关系，从全机构视角协调、统领各个层面的数据管理工作，确保内部各类人员能够得到及时、准确的数据支持和服务。通常认为，数据治理至少应当涵盖如下功能域：信息资源目录管理、主数据管理、元数据管理、数据质量管理、数据标准管理以及数据生命周期管理。数据治理体系在数据架构中的定位：元数据管理生命周期管理数据质量管理数据安全设计（可裁剪）信息系统安全架构分为两个方面：管理要求和技术要求。管理要求分为：安全管理制度，安全管理机构，系统建设管理和系统运维；技术要求分为：物理安全，网络安全，主机安全，应用安全和数据安数据安全贯穿数据整个生命周期，其安全问题涉及数据整个数据生命周期的管理过程。对企业而言所有的数据在其生命周期中都应当被有效地管理，通过必要控制手段清晰地界定避免内部非授权的访问，并指定完善的数据备份、恢复策略、删除策略，保证数据的安全性。数据安全的内容可以简化为保密性、完整性和可用性。其中包括数据本身的安全，即利用现代密码技术对数据进行主动保护，如数据保密、保证数据完整性等等。同时还包括数据防护的安全，即利用技术手段对数据进行保护，如磁盘阵列、数据备份、异地容灾等等。数据安全特性与技术安全审计数据安全审计是对每个用户在计算机系统上的操作做一个完整的记录，以备用户违反安全规则的事