数据中心架构优化及搬迁项目招标文件
项目编号：
北京市电力公司
数据中心架构优化及搬迁
服务实施
招标文件
北京市电力公司
2013年3月
目录
1前言 (1)
2投标须知 (2)
2.1总则 (2)
2.1.1概述 (2)
2.1.2投标方资质要求 (3)
2.1.3投标方项目人员要求 (4)
2.1.4投标费用 (5)
2.1.5项目管控 (5)
2.1.6现场考察 (7)
2.1.7答疑 (8)
2.2招标文件 (8)
2.2.1招标文件的内容 (8)
2.2.2招标文件的修改 (9)
2.2.3招标文件注意事项 (9)
2.3特别约定 (10)
3技术要求 (11)
3.1项目总体目标 (11)
3.2项目建设原则 (12)
3.3项目总体要求 (12)
3.4项目实施范围 (13)
3.5项目实施内容 (16)
3.6项目工作概述 (16)
3.7.1项目管理 (17)
3.7.2搬迁原则 (18)
3.7.3前期准备 (18)
3.7.4搬迁方案 (19)
3.7.5培训与演练 (21)
3.7.6搬迁实施 (21)
3.7.7设备维保 (23)
3.7.8应急备件及技术保障要求 (24)
3.7.9保险要求 (24)
3.7.10应急预案制定、启动及实施的要求 (24)
3.8项目交付物文档参考 (25)
3.9项目周期要求 (26)
3.10物流要求 (26)
3.11搬迁注意事项 (27)
3.12其他要求 (28)
4商务要求 (29)
4.1资格审查 (29)
4.2应答语言和计量单位 (29)
4.3投标文件的组成 (29)
4.4投标文件格式 (31)
4.5投标报价 (31)
4.6投标文件有效期 (32)
4.7投标保证金 (32)
4.8投标文件提交 (33)
4.9投标文件的份数和签署 (33)
4.10投标时间、地点、联系人 (34)
4.11投标文件的有效性 (34)
4.12投标文件的补充、修改与撤回 (34)
4.13投标文件的澄清 (35)
4.14投标文件计算错误的修正 (35)
4.15投标文件的评审、比较和否决 (35)
4.16开标 (36)
4.17评标 (36)
4.18评标方法 (37)
4.19中标通知书 (37)
4.20合同授予 (37)
4.21其他 (38)
5合同（协议书）条款 (39)
5.1词语定义 (39)
5.2合同文件及解释顺序 (40)
5.3双方的权利和义务 (40)
5.4工期 (41)
5.5双方责任 (41)
5.7合同款支付 (41)
5.8违约、索赔和争议 (42)
5.9项目转包 (42)
5.10不可抗力 (42)
5.11保险 (42)
5.12合同解除 (43)
5.13合同生效与终止 (43)
5.14合同份数 (43)
5.15其他事项 (43)
6其他附件 (44)
6.1附件1：法定代表人身份证明书 (44)
6.2附件2：投标文件签署授权委托书 (44)
6.3附件3：投标函 (45)
6.4附件4：投标保证金交存凭证 (45)
6.5附件5：投标方相关案例简介 (46)
6.6附件6：人员履历表 (46)
6.7附件7：投标偏差表（商务部分） (47)
6.8附件8：投标偏差表（技术部分） (48)
6.9..................................................................................................... 附件9：项目评标办法
48
1前言
按照国家电网公司（以下称公司）《关于统一建设公司集中式信息系统容灾中心的通知》（国家电网信息〔2009〕615号）的要求，在北京、上海、西安三地统一建设三个集中式信息系统灾备中心（以下称灾备中心）。公司各单位分别通过三个灾备中心实现信息系统数据级和应用级容灾，从而形成全公司现有两级数据中心及三个集中式信息系统灾备中心的格局，目前三地灾备中心已经建成投运。
根据公司要求，为加强对公司信息系统的集中运行管理，拟将现有生产数据中心搬迁至北京灾备中心，形成亦庄生产中心，在保障数据与设备安全完好的前提下，尽量减少业务停机时间。并结合系统整合、数据中心网络架构的优化调整、数据级容灾对其的需求。提出本次招标的技术规范。
2投标须知
2.1总则
2.1.1概述
1)本技术规范书为北京市电力公司数据中心架构优化及搬迁项目实
施服务技术招标文件；
2)北京市电力公司（以下简称：招标方）将与外部承包商（以下简称：
投标方）签订北京市电力公司数据中心架构优化及搬迁项目实施服务合同的方式，执行此项目；
3)投标方应根据本技术规范书的要求逐项应答，如投标方在标书递交
前发现技术规范书中存在遗漏可提请招标方进行澄清但同时应在偏差表中明确提出并进行详细阐述；
4)投标方的投标书必须清楚地响应标书中的所有内容，不能简单地回
答“满足”或“符合”，如果标书中的内容可用具体指标加以描述的，投标方应真实准确的描述否则将可能影响评标结果。如果投标方认为标书中的某一内容高于招标规范书的要求或更为合理，可在响应原要求后给出具体说明，并在偏差表中列出，评标时将作为重要内容加以考虑；
5)如果投标方中标，投标方所投标书将作为项目合同的重要附件，与
合同具有同样的法律效力；
6)投标方应具备系统集成设计、实施的能力，同时投标方应按照附件
的要求提相关案例简介；
7)投标方所提供的应标书及所有交付件的知识产权归属于北京市电
力公司；
8)本技术规范书作为本项目的最低要求，若投标方认为存在满足本项
目要求的其他必须工作任务，必须在应标时说明，并列明报价，此报价将计入总价，否则视为免费赠送；
9)投标方必须认真阅读技术规范书中的内容, 以免造成投标失败，否
则自行承担责任；
10)投标书要以简体中文书写，提供投标的所有技术指标说明材料
及相应资料以简体中文书写；
11)投标方应保证对本次招标所有技术说明文件的保密，在招标前
和招标后不得向其他单位公布建设单位的有关材料；
12)本技术规范书未提到而投标方认为应提供的其他内容，投标方
应详细说明，并用偏差表的格式进行标注；
13)对于本技术规范书的某些部分投标方如不能满足要求或与招标
方的技术要求有差异, 应在技术建议书中以偏差表的形式提出说明, 否则招标方认为投标方提供的系统、方案或进度可以满足本技术规范书的要求。
2.1.2投标方资质要求
1)在中华人民共和国境内注册的、在法律和财务上独立、能够独立承
担民事责任的企业或公司;
2)注册资本在人民币1000万元(含本数)或美元200万元（含本数）
以上;
3)在最近三年内承接过800万元人民币以上机房维护合同和相关电
力信息系统维护合同。
4)实施人员是否拥有PMP或ITIL等相关认证。
2.1.3投标方项目人员要求
为了安全、顺利的完成本次数据中心架构优化及搬迁项目，要求投标方安排有经验的项目团队在整个项目设计和实施期间提供统一的项目管理工作，对项目团队成员的具体要求如下，其主要人员应填写附件中相应的人员履历表格（附件六），提供近三个月的社保证明和公司员工证明。
1)项目经理(1名)
●具有支持或主要参加企业业务持续性和灾难恢复项目的经历；
●具备相关行业（电力、电信、银行）信息系统的项目管理经验；
●具有咨询、集成、实施项目的丰富经验和较强的沟通协调能力；
●具有预见和应对项目风险能力；
●负责本项目的计划、组织、实施、协调、人员配置并监督工作
情况及进度等工作，负责各方的沟通联系，对项目领导组负责；
●必须全程参与，不允许随意更换。
2)技术负责人(1名)
●具有5年以上业务连续性、灾难恢复计划、IT相关相关管理咨
询实施背景；
●具有丰富的咨询、项目实施经验和较高的沟通协调能力；
●负责总体规划设计和搬迁方案详细设计，与项目经理紧密配合，
负责项目的计划、组织、任务分解分配、执行等工作，负责搬
迁项目的实施，负责项目汇报等事宜；
●必须全程参与，不允许随意更换。
3)搬迁实施工程师(若干)
●通过Oracle OCP认证，需1人或以上;
●通过思科CCNP认证或H3CSE认证，需1人或以上;
●根据项目进度需求和时间安排，提供搬迁实施，设备清点、应
用关联分析、业务影响分析、搬迁策略制定、搬迁方案详细设
计、搬迁实施等工作。
2.1.4投标费用
投标方在参与投标过程中的一切费用，无论中标与否，均由投标方自己负担。
2.1.5项目管控
a)实施地点
招标单位指定的地点，北京市电力公司前门西大街41号和北京容灾中心两地。
b)人员稳定性保证
投标方应在投标文件中明确到现场实施人天数，并保证项目建设团队的主要人员稳定，在未经过招标方或建设单位同意的情况下投标方不得随意更换项目人员。
招标方或投标方认为需要更换投标方项目经理和项目团队成员时，均应提早一周向对方申明原因，投标方应在同时提出新的符合合同要求的项目经理和项目团队成员人选，经招标方和同意并办理交接手续后方可更换。
针对招标方要求成立不同的项目组，项目组人员不得交叉。c)人员工作经验保证
投标方要建立实施该项目的组织架构，投标方确定的项目经理需符合项目经理任职条件。
除项目经理外，投标方应提供一名总技术负责人，该技术负责人
应具符合技术负责人任职条件。
投标方应能够提供经验丰富的项目实施队伍参与此项目，整个项目进行当中应确保项目实施人员的稳定性，不得随意更换。项目管理方案应具体说明本次项目组织，提交项目组成员的简历。简历应要标明所参与的项目名称，起止时间，承担角色，负责完成的工作。d)需求变更管理
投标方应与招标方一起通过现场需求调研、联络会等方式明确项目需求变更内容，并以合同或会议纪要形式加以明确，与标准化设计成果不相符的，须报招标方审批。
e)合同变更要求
如在项目实施过程中需要调整内容、进度等，需经招标方、投标方与建设单位共同同意，按合同变更程序办理。
f)进度管理
投标方应与招标方一起以招标方的招标文件和技术规范书为基础，结合投标方的投标书，共同确定详细的项目进度安排，明确每个阶段的阶段目标、阶段应交付的成果、验收依据、双方的责任和义务，经招标方可后，以合同或会议纪要形式加以明确。
1)投标方的项目进度管理应该遵循以下原则：
●项目进度管理的依据是项目合同所约定的工期目标；
●在确保项目质量和安全的原则下，控制项目进度。
2)投标方的项目进度管理应该至少包含以下内容：
●投标方在了解项目特点的前提下，根据工期目标，提交
总体进度计划，以及定期提交阶段性工作计划；
●制定详细的项目建设进度计划，按照合同的进度计划制
定具体的实施计划，定期跟踪检查，对可能发生的工程延误提
出相应对策；
●定期或不定期地召开或参加项目例会、协调会议等，向
招标方通报项目进展情况，提交进度报告，及时解决相关问题；
●建立项目变更流程，记录项目变更情况。
g)交付成果
1)投标方应提供整个系统建设的文档，包括系统设计、验证、
实施、演练、容灾运行管理模式对应的全部管理规范和技术文档；
2)技术文档应与系统相一致，技术文档应该全面、完整、详细、
清晰，能够满足招标方对系统的使用、维护、容灾演练的需要；
3)提供的文档和资料均应以纸张和光盘为载体，文件格式为
Word文档或其他可视化、未加密的文件；
4)图纸规格和质量：所有纸质文件应符合ISO标准的A或B
系列图纸标准，建议采用A4标准格式；
5)投标方应在标书中提供需求调研、设计阶段、测试阶段、实
施阶段、运行阶段、项目管理的全部交付成果的清单、成果交付形式和交付时间。
2.1.6现场考察
1)投标方应对现场和周围环境进行考察，以获得需投标方自己负责的
有关资料，考察现场的费用由投标方自负。
2)招标方将安排正式现场考察，由招标方管理人员或其委托单位将介
绍工作范围内的有关技术参数，要求以及周边环境，气象，及交通条件等，以帮助投标方了解现场情况，便于编写标书。
3)未参加招标方安排的正式现场考察的投标方将对由此产生的后果
自行负责。
4)在现场考察过程中，投标方如果发生人身伤亡，财产或其他损失，
不论何种原因所造成，招标方均不负责。
5)在投标期间如需再次考察现场的投标方单位，应提前向招标方申请
批准，招标方将予以支持，具体时间双方洽商确定。
2.1.7答疑
1)投标方若有相关疑问可与以下人员联系：
技术相关问题
联系人：
电话：
E-Mail：
商务相关问题
联系人：
电话：
E-Mail:
2)招标文件的答疑
任何领取招标文件的投标方，均可要求招标方对招标文件进行澄清。投标方须按投标邀请书中的联系地址以电子邮件的形式送达商务联系人，招标方将以电子形式予以答复。
2.2招标文件
2.2.1招标文件的内容
1)招标文件分卷装订，除下述各卷册内容外，甲方在招标期间发出的
补遗通知书和其它正式有效函件，均是招标文件的组成部分。
各卷篇内容如下：
第一篇：前言
第二篇：投标须知
第三篇：技术要求
第四篇：商务要求
第五篇：合同（协议书）条款
第六篇：其他附件
2)投标方应仔细阅读招标文件，按招标文件的规定与要求编写投标文
件，如果投标文件与招标方招标文件的规定和要求不符合，则投标方应自行负责。
3)投标方应认真检查招标文件是否完整，若发现有缺页或附件不全
时，应及时向招标方提出，以便补齐。
2.2.2招标文件的修改
1)在送交招标文件截止期2天前的任何时候，招标方可能会因任何
原因或按照某投标方提出的某项招标或要求(包括答疑提出的问题)，发出补遗及澄清书的形式对招标文件进行修改。
2)补遗及澄清书以电子或书面形式送给所有投标方，补遗及澄清书对
所有投标方均有约束力。投标方在收到补遗及澄清书后，应立即以电子或书面函件或传真件形式告招标方。
3)为使投标方有合理的时间编写补遗及澄清书的内容，在必要时招标
方可酌情推迟送交报价文件的截止日期。
2.2.3招标文件注意事项
1)招标文件不得含有标明特定的投标方以及含有倾向或者排斥潜在
的投标方的其他内容。
2)投标人提供的投标文件中的所有资质、资格、授权、业绩（成功案
例）等必须为其自身所有或所为，不得以任何第三方（包括但不限于与其具有关联关系的法人或其他组织）相关资料代替，否则，该投标文件招标人有权拒绝。
3)投标方必须保证投标文件所提供全部资料的真实性、可靠性和完整
性，并接受招标人对其中任何资料进一步审查的要求。
4)投标方不得相互串通报价，不得排挤其他投标方的公平竞争，损害
招标方和其他投标方的合法权益。以上情况一经发现，将取消投标方的报价资格。对投标方与报甲方串通报价，损害公司利益的，公司将对相关人员进行严厉处罚。
2.3特别约定
以下条款，为招标方与投标方的特别约定，招标方一旦受邀参加本次招标并递交投标文件，就意味投标方完全清楚并同意以下约定的内容和含义，且愿意遵守：
1)投标方在投标或中选后，应确保在使用招标方提供的相关资料时严
格限制使用人员和范围，保证招标方提供的各种资料、方案或数据不发生流失或泄密现象，否则将由中选投标方承担全部法律责任。
2)未经招标方或建设单位许可，不得向第三方透露系统的各种口令和
权限。
3)投标方应对参与设计、实施人员进行严格管理，不得对外泄漏系统
内的各类数据和资料。
4)未经招标方或建设单位同意，不得随意进行主机、数据库等设备或
系统的启停等操作。
3技术要求
3.1项目总体目标
本次搬迁工作的总体目标为：将北京市电力公司原数据中心搬迁范围内的系统、设备，在保证数据安全、设备安全的前提下，使业务系统在停机窗口内平稳过渡到亦庄生产中心，同时对业务系统进行资源整合，并按照北京市电力公司安全等级保护要求进行加固。达到搬迁后的数据中心运行稳定、高效、可靠、安全，并能够满足未来一段时间内信息系统扩充升级的需要。
由于电力系统重要性高、影响大，对相应系统的安全搬迁应高度重视。不同专业系统其重要程度不同、影响面不同、可以中断的时长也不同，因此在搬迁过程中要区别对待，最大程度减小影响。搬迁前必须做好系统和数据的备份，尤其要防止硬盘故障，确保专业系统数据和设备在搬迁过程中不损坏、不崩溃，满足专业系统外部运行条件，全部搬迁后可以在最短时间内恢复运行。专业系统搬迁要遵循总体搬迁原则和计划安排，按照系统间的关系和具备的条件合理安排搬迁的进度安排。整个搬迁要考虑到各种可能的风险，并提供相应的预防措施、补救措施，最大程度保证数据和应用系统的安全。
因此，根据原数据中心现有业务系统的重要性以及保障北京市电力公司的重要业务系统不受影响的前提下，制定以下系统的停机窗口用于制定系统的搬迁的进度安排。
表3-1：各类应用系统停机时间表
备注：1、停机时间窗口指许可的最长停机时间，即允许的从业务停止运行到系统恢复、业务可用止的时间长度，单位小时。
2、对不在上表中单独列出的应用系统，其停机时间窗口按“第11行“一
般性应用系统”执行，如各单位有其它特殊类别的系统需要确定停机时间窗口，可增加行单独定义。
3.2项目建设原则
1)安全第一，尽量在规定的停机时间内完成；
2)充分调研、准备，搬迁方案设计要成熟、合理；
3)确保设备、系统与数据应用的可靠性和安全性；
4)部署、科学论证、步骤可行；
5)分步实施、分工明确、协调运作。
3.3项目总体要求
由于本次搬迁涉及的系统重要性高、影响大，所以招标方对系统的安全搬迁高度重视。要求中标方必须满足专业系统正常运行条件，在整个搬迁过程中确保专业系统数据和设备不损坏、不崩溃，保障在全部搬迁后系统可以最短时间内恢复运行。中标方要遵循招标方提供
的搬迁原则和搬迁进度，按照系统的重要性对设备进行搬迁。中标方要在搬迁前对整个搬迁方案考虑到各种可能的风险，并提供相应的预防措施、补救措施，最大程度保证数据和应用系统的安全。
以下要求投标方须完全满足，如出现任何一项不满足的情况，扣除该投标方一定的技术分值，情况严重者，直接丧失参与投标资格。
1)投标方需提供一套成熟、完善的搬迁方法（例如方法论），
并需该方法应用到本项目中。
2)投标方须提供整个搬迁项目过程中所用的工具或文档的
参考样例。
3)投标方须提供完整的搬迁方案，至少包括各个应用系统、
网络设备、存储设备的前期准备、搬迁步骤、应急预案等。
4)投标方须提供一套适合于机房搬迁的项目管理/质量管
理体系。
5)投标方须提供整个搬迁项目的各方的职责分工及其界
面，需定义清晰，不得存在模棱两可的情况（如出现定义的不
清晰的内容，则视为投标方免费提供该项服务）。
6)投标方须在投标文件中详细的描述搬迁的各个过程及相
关内容，并针对某一批次的设备搬迁提供搬迁之日的详细计划。
7)投标方须承诺在搬迁过程中进场的队伍是有相关搬迁经
验的，并保证队伍在整个项目过程中的投入程度。
3.4项目实施范围
本次数据中心搬迁范围包括所有部署在北京市电力公司数据中心的业务系统，包括相关软、硬件设备和机房配套设施（机柜，网线等）、
数据容灾实施。
搬迁设备及数量如下所示：
搬迁系统名称及搬迁方式：
备注：1、现有计划搬迁设备数量和实际搬迁量会有一定差别，数量总值在控制在10%上下，请在标书报价中综合考虑。
2、招标方预估以上需要搬迁设备价值为1亿元人民币，投标方应以此价
格考虑搬迁保险费用。
3.5项目实施内容
包括但不限于以下内容：
1、项目集成管理、调研分析、规划设计；
2、数据备份、数据迁移、设备搬迁；
3、应用系统的优化和整理；
4、数据容灾实施；
5、保证设备的维保有效并提供设备、软件原厂商技术服务；
6、购买保险及布线工具、光纤跳线等辅材；
7、负责搬迁需要的物流运输并制定合理运输计划；
3.6项目工作概述
根据以上内容，中标方必须能够满足和完成以下要求和工作。
1)项目的总体管控和与相关厂商的协调，提供有效的监控和项目
管理；
2)完成机房迁移所需要的调研、评估、风险分析，对迁移方案进
行规划，制订详细的迁移实施步骤和应急预案，并进行测试；
3)迁移前系统和数据的备份，对搬迁设备进行妥善的包装和安全
的运输，确定停关机流程及时间；
4)按北京市电力公司的标签规范，制作并安装机房内的标识和设
备标签；
5)提供完整和全套的搬迁文档等内容；
6)搬迁后进行验收包括系统的搭建安装以及系统一致性、完好
性、可用性测试；
7)提供设备搬迁期间的质保服务，保证设备续保服务的延续性；
8)负责招标方另行采购的设备以及与供应方的协调和管理。
3.7项目具体工作及要求
3.7.1项目管理
中标方必须遵守招标方相关管理规定和实施细则，配合招标方完成搬迁工作，提供与厂商、系统集成商间的协调调度工作。
中标方在投标时应提交项目管理方案，方案至少包括项目组织机构、人员安排、进度安排、计划控制、项目相关人员管理、质量管理及风险管理等内容，方案必须符合本技术规范书的要求，并具有可操作性。
中标方不得将本项目或其中任何部分转让给其他单位或个人，如中标方不具备某方面的技术或能力，可将该部分进行分包，但需遵循有关法律、法规等的规定，并需事先与招标人协商，取得招标人批准，具体分包规定如下：
1)分包人必须具备相应的资质条件。中标方将其中部分项目进行
分包，不应解除合同约定的中标方的任何责任和义务；
数据中心建设架构设计
数据中心架构建设计方案建议书 1、数据中心网络功能区分区说明 功能区说明 图1：数据中心网络拓扑图 数据中心网络通过防火墙和交换机等网络安全设备分隔为个功能区：互联网区、应用服务器区、核心数据区、存储数据区、管理区和测试区。可通过在防火墙上设置策略来灵活控制各功能区之间的访问。各功能区拓扑结构应保持基本一致，并可根据需要新增功能区。 在安全级别的设定上，互联网区最低，应用区次之，测试区等，核心数据区和存储数据区最高。 数据中心网络采用冗余设计，实现网络设备、线路的冗余备份以保证较高的可靠性。 互联网区网络 外联区位于第一道防火墙之外，是数据中心网络的Internet接口，提供与Internet高速、可靠的连接，保证客户通过Internet访问支付中心。 根据中国南电信、北联通的网络分割现状，数据中心同时申请中国电信、中国联通各1条Internet线路。实现自动为来访用户选择最优的网络线路，保证优质的网络访问服务。当1条线路出现故障时，所有访问自动切换到另1条线路，即实现线路的冗余备份。
但随着移动互联网的迅猛发展，将来一定会有中国移动接入的需求，互联区网络为未来增加中国移动（铁通）链路接入提供了硬件准备，无需增加硬件便可以接入更多互联网接入链路。 外联区网络设备主要有：2台高性能链路负载均衡设备F5 LC1600，此交换机不断能够支持链路负载,通过DNS智能选择最佳线路给接入用户,同时确保其中一条链路发生故障后,另外一条链路能够迅速接管。互联网区使用交换机可以利用现有二层交换机，也可以通过VLAN方式从核心交换机上借用端口。 交换机具有端口镜像功能，并且每台交换机至少保留4个未使用端口，以便未来网络入侵检测器、网络流量分析仪等设备等接入。 建议未来在此处部署应用防火墙产品，以防止黑客在应用层上对应用系统的攻击。 应用服务器区网络 应用服务器区位于防火墙内，主要用于放置WEB服务器、应用服务器等。所有应用服务器和web服务器可以通过F5 BigIP1600实现服务器负载均衡。 外网防火墙均应采用千兆高性能防火墙。防火墙采用模块式设计，具有端口扩展能力，以满足未来扩展功能区的需要。 在此区部署服务器负载均衡交换机，实现服务器的负载均衡。也可以采用F5虚拟化版本，即无需硬件，只需要使用软件就可以象一台虚拟服务器一样，运行在vmware ESXi上。 数据库区
NIKE 项目数据中心网络架构方案
NIKE 项目数据中心网络架构方案 1.概述 (2) 2.系统需求分析 (2) 3.企业网络信息系统设计思路 (2) 4.企业网络信息系统建设原则 (2) 5.系统技术实现细节 (3) 5.1 网络拓扑图 (3) 5.2 Nike项目服务器技术实现细节 (4) 5.2.1双机备份方案 (4) 5.2.1.1.双机备份方案描述 (4) 5.2.1.2.双机备份方案的原理 (4) 5.2.1.3.双机备份方案的适用范围 (4) 5.2.1.4.双机备份的方式及优缺点 (4) 5.2.1.5双机方案建议 (4) 5.2.1.6磁盘阵列备份模式示意图 (5)
5.2.1.7双机方案网络拓扑图 (5) 5.2.1.8双机热备工作原理 (6) 6.备份 (6) 7.建议配置方案及设备清单..................................................7-8 1.概述 21世纪世界竞争的焦点将是信息的竞争，社会和经济的发展对信息资源、信息技术和信息产业的依赖程度越来越大，信息技术的发展对政治、经济、科技、教育、军事等诸多方面的发展产生了重大的影响，信息化是世界各国发展经济的共同选择，信息化程度已成为衡量一个国家，一个行业现代化的重要标志。 2．系统需求分析 由于此方案是专为NIKE项目数据中心设计，此数据中心是为数据信息提供传递、处理、存储服务的，为了满足企业高效运作对于正常运行时间的要求，因此，此数据中心在通信、电源、冷却、线缆与安全方面都必须要做到非常可靠和安全，并可适应不断的增长与变化的要求。 3．系统设计思路 企业网络信息系统的建设是为企业业务的发展服务，综合考虑公司信息系统当前背景和状况，其建设设计主要应达到如下目标： 1) 系统的设计应能满足公司对公用信息资源的共享需求,满足3PL及客户查询数据的共享需求，并为实现公用信息资源共享提供良好的网络环境，概括而言之就是能让相关人员顺利流畅的访问数据中心的Nike XpDX Server及我司的TMS等相关系统。与此同时，系统的建设还需要考虑到投入和产出两者间的关系，注意强调成本节约，提高效费比的问题。 2) 系统的设计必须充分考虑到建成后系统的管理维护问题。为此设计应强调系统的统一集中管理，尽量减少资源的分散管理，注重提高信息系统平台运营维护的工作效率。 3) 系统的设计还需要考虑建成后资源的合理利用问题，必须保证建成系统资源主要服务于设定需求，保证设计数据流量在网络中流畅通行。因此，必须保证只有设计的数据流量才能优先在网络中传递，对于设计外数据流量（例如互联网网页访问、网络下载、网络视频、网络音频、P2P、IM聊天）应通过技术
数据中台之结构化大数据存储设计
数据中台之结构化大数据存储设计 一.前言 任何应用系统都离不开对数据的处理，数据也是驱动业务创新以及向智能化发展最核心的东西。这也是为何目前大多数企业都在构建数据中台的原因，数据处理的技术已经是核心竞争力。在一个完备的技术架构中，通常也会由应用系统以及数据系统构成。应用系统负责处理业务逻辑，而数据系统负责处理数据。 传统的数据系统就是所谓的『大数据』技术，这是一个被创造出来的名词，代表着新的技术门槛。近几年得益于产业的发展、业务的创新、数据的爆发式增长以及开源技术的广泛应用，经历多年的磨炼以及在广大开发者的共建下，大数据的核心组件和技术架构日趋成熟。特别是随着云的发展，让『大数据』技术的使用门槛进一步降低，越来越多的业务创新会由数据来驱动完成。 『大数据』技术会逐步向轻量化和智能化方向发展，最终也会成为一个研发工程师的必备技能之一，而这个过程必须是由云计算技术来驱动以及在云平台之上才能完成。应用系统和数据系统也会逐渐融合，数据系统不再隐藏在应用系统之后，而是也会贯穿在整个业务交互逻辑。传统的应用系统，重点在于交互。而现代的应用系统，在与你交互的同时，会慢慢的熟悉你。数据系统的发展驱动了业务系统的发展，从业务化到规模化，再到智能化。 业务化：完成最基本的业务交互逻辑。 规模化：分布式和大数据技术的应用，满足业务规模增长的需求以及数据的积累。 智能化：人工智能技术的应用，挖掘数据的价值，驱动业务的创新。 向规模化和智能化的发展，仍然存在一定的技术门槛。成熟的开源技术的应用能让一个大数据系统的搭建变得简单，同时大数据架构也变得很普遍，例如广为人知的Lambda架构，一定程度上降低了技术的入门门槛。但是对数据系统的后续维护，例如对大数据组件的规模化应用、运维管控和成本优化，需要掌握大数据、分布式技术及复杂环境下定位问题的能力，仍然具备很高的技术门槛。 数据系统的核心组件包含数据管道、分布式存储和分布式计算，数据系统架构的搭建会是使用这些组件的组合拼装。每个组件各司其职，组件与组件之间进行上下游的数据交换，而不同模块的选择和组合是架构师面临的最大的挑战。 本篇文章主要面向数据系统的研发工程师和架构师，我们会首先对数据系统核心组件进行拆解，介绍每个组件下对应的开源组件以及云上产品。之后会深入剖析数据系统中结构化数据的存储技术，介绍阿里云Tablestore选择哪种设计理念来更好的满足数据系统中对结构化数据存储的需求。 二.数据系统架构 1.核心组件
大数据仓库建设方案设计
第1章数据仓库建设 1.1数据仓库总体架构 专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据，经过一系列综合诊断分析，以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施，为车辆的故障根因修复提供必要的支持。 根据专家系统数据仓库建设目标，结合系统数据业务规范，包括数据采集频率、数据采集量等相关因素，设计专家系统数据仓库架构如下： 数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容： 数据采集：负责从各业务自系统中汇集信息数据，系统支撑Kafka、Storm、Flume
及传统的ETL采集工具。 数据存储：本系统提供Hdfs、Hbase及RDBMS相结合的存储模式，支持海量数据的分布式存储。 数据分析：数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。 数据服务总线：数据系统提供数据服务总线服务，实现对数据资源的统一管理和调度，并对外提供数据服务。 1.2数据采集 专家系统数据仓库数据采集包括两个部分内容：外部数据汇集、内部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层（ODS）；内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。 1.2.1外部数据汇集 专家数据仓库数据源包括列车监控与检测系统（TCMS）、车载子系统等相关子系统，数据采集的内容分为实时数据采集和定时数据采集两大类，实时数据采集主要对于各项检测指标数据；非实时采集包括日检修数据等。 根据项目信息汇集要求，列车指标信息采集具有采集数据量大，采集频率高的特点，考虑到系统后期的扩展，因此在数据数据采集方面，要求采集体系支持高吞吐量、高频率、海量数据采集，同时系统应该灵活可配置，可根据业务的需要进行灵活配置横向扩展。 本方案在数据采集架构采用Flume+Kafka+Storm的组合架构，采用Flume和ETL 工具作为Kafka的Producer，采用Storm作为Kafka的Consumer，Storm可实现对海量数据的实时处理，及时对问题指标进行预警。具体采集系统技术结构图如下:
数据中心网络系统设计方案范本
数据中心网络系统 设计方案
数据中心高可用网络系统设计 数据中心作为承载企业业务的重要IT基础设施，承担着稳定运行和业务创新的重任。伴随着数据的集中，企业数据中心的建设及运维给信息部门带来了巨大的压力，“数据集中就意味着风险集中、响应集中、复杂度集中……”，数据中心出现故障的情况几乎不可避免。因此，数据中心解决方案需要着重关注如何尽量减小数据中心出现故障后对企业关键业务造成的影响。为了实现这一目标，首先应该要了解企业数据中心出现故障的类型以及该类型故障产生的影响。影响数据中心的故障主要分为如下几类： 硬件故障 软件故障 链路故障 电源/环境故障 资源利用问题 网络设计问题 本文针对网络的高可用设计做详细的阐述。 高可用数据中心网络设计思路
数据中心的故障类型众多，但故障所导致的结果却大同小异。即数据中心中的设备、链路或server发生故障，无法对外提供正常服务。缓解这些问题最简单的方式就是冗余设计，能够经过对设备、链路、Server提供备份，从而将故障对用户业务的影响降低到最小。 可是，一味的增加冗余设计是否就能够达到缓解故障影响的目的？有人可能会将网络可用性与冗余性等同起来。事实上，冗余性只是整个可用性架构中的一个方面。一味的强调冗余性有可能会降低可用性，减小冗余所带来的优点，因为冗余性在带来好处的同时也会带来一些如下缺点： 网络复杂度增加 网络支撑负担加重 配置和管理难度增加 因此，数据中心的高可用设计是一个综合的概念。在选用高可靠设备组件、提高网络的冗余性的同时，还需要加强网络构架及协议部署的优化，从而实现真正的高可用。设计一个高可用的数据中心网络，可参考类似OSI七层模型，在各个层面保证高可用，最终实现数据中心基础网络系统的高可用，如图1所示。
ToR争议—数据中心架构与布线
ToR争议—数据中心架构与布线高密度、虚拟化、云计算等数据中心技术趋势的演进，以及10 GBASE-T相关产品的应用，都深刻地影响了机房基础设施的变革，以ToR为代表的新架构设计的出现，更是对数据中心布线系统提出了新的课题。 从综合布线系统的角度看，适应ToR等方式的点对点布线，与综合布线国际标准提倡的集中式布线之间存在很大差别，孰优孰劣也引发了新的争议。究竟哪种方式更适合数据中心实际需求及发展趋势?值得从业者关注和思考，更是用户关心的实际问题。 ToR潮流来袭，冲击布线厂商 在“开放式云网络框架”产品中，特别提到了对ToR架构的支持——“新产品提供更高水平的端口密度、性能以及灵活性……便于数据中心灵活选择核心与柜顶(ToR)层的构建方式……”实际上，在思科(Cisc o)、博科(Brocade)和H3C等网络设备厂商的新产品中，你都能看到ToR架构的影子。由于ToR极大地缩减了布线的使用量，这种架构若逐渐成为主流，将给布线厂商带来较大损失 什么是ToR、EoR、MoR?
ToR的英文全称为Top of Rank，意指柜顶，与列末EoR(End of Row)及列中MoR(Middle of Row)一样，都是数据中心的一种架 构设计方式。 传统的机房架构主要以EoR和MoR方式(两者差别主要在于网络机柜的位置不同)为主，采取类似的集中式布线。 其中，EoR方式是指服务器机柜中所有的服务器端口，都通过跳线连接到机柜上的配线架，再由配线架上的铜缆延伸到网络机柜(位 于一组机柜尾部)中的接入交换机上。 MoR方式与EoR方式类似，只是将网络机柜部署在服务器机柜 的中部，从而在一定程度上减少了从服务器机柜到网络机柜的线缆距离。 ToR方式的出现，为机房架构设计带来了新的变化：该方式将接入交换机放置在每个服务器机柜或单元的顶部，机柜内服务器直接通过短跳线连接到顶部的交换机上，再经由光纤从交换机的上行链路端口连至核心交换机。 粗看上去，ToR与EoR/MoR两类方式，只是在接入交换机的位置上发生了变化，但实际上改变了整个机房的网络结构。仅从设备使用上来说，一方面增加了交换机使用数量，另一方面，综合布线系统由从前的集中式布线变为了点对点布线方式，大大缩减了布线使用量。
常见的大数据平台架构设计思路【最新版】
常见的大数据平台架构设计思路 近年来，随着IT技术与大数据、机器学习、算法方向的不断发展，越来越多的企业都意识到了数据存在的价值，将数据作为自身宝贵的资产进行管理，利用大数据和机器学习能力去挖掘、识别、利用数据资产。如果缺乏有效的数据整体架构设计或者部分能力缺失，会导致业务层难以直接利用大数据大数据，大数据和业务产生了巨大的鸿沟，这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题，本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点。 本文主要包括以下几个章节: 本文第一部分介绍一下大数据基础组件和相关知识。第二部分会介绍lambda架构和kappa架构。第三部分会介绍lambda和kappa架构模式下的一般大数据架构第四部分介绍裸露的数据架构体系下数据端到端难点以及痛点。第五部分介绍优秀的大数据架构整体设计从第五部分以后都是在介绍通过各种数据平台和组件将这些大数据组件结合起来打造一套高效、易用的数据平台来提高业务系统效能，让业务开发不在畏惧复杂的数据开发组件，无需关注底层实现，
只需要会使用SQL就可以完成一站式开发，完成数据回流，让大数据不再是数据工程师才有的技能。 一、大数据技术栈 大数据整体流程涉及很多模块，每一个模块都比较复杂，下图列出这些模块和组件以及他们的功能特性，后续会有专题去详细介绍相关模块领域知识，例如数据采集、数据传输、实时计算、离线计算、大数据储存等相关模块。 二、lambda架构和kappa架构 目前基本上所有的大数据架构都是基于lambda和kappa 架构，不同公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性，关于lambda架构可以在网上搜到很多相关文章。而kappa架构解决了lambda架构存在的两套数据加工体系，从而带来的各种成本问题，这也是目前流批一体化研究方向，很多企业已经开始使用这种更为先进的架构。 Lambda架构
数据仓库设计的21条原则：7个步骤,7个禁忌和7种思路
高效实现数据仓库的七个步骤 数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。如果你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。一句话，如果你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无法良好运作。 在处理一个数据仓库项目时需要注意的问题很多，但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。 1. 配备一个全职的项目经理或你自己全面负责项目管理 在通常情况下，项目经理都会同时负责多个项目的实施。这么做完全是出于资金和IT资源方面的考虑。但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理如果能全心投入，对于项目的成功会有很大帮助。 2. 将项目管理职责推给别的项目经理 由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。当然，这个新的项目经理一定要复合第一条所说的具有全职性。为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目更加困难。每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。 3.与用户进行沟通 这里所讲的内容远比一篇文章本身要重要的多。你必须明白，在数据仓库的设计阶段，那些潜在用户自己也不清楚他们到底需要数据仓库为他们做什么。他们在不断的探索和发现自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。更加频繁的与客户接触，多做记录，
大数据中心建设方案设计a
工业产品环境适应性公共技术服务平台信息化系统建设方案
1. 平台简介 工业产品环境适应性公共技术服务平台是面向工业企业、高校、科研机构等提供产品/材料环境适应性技术服务的平台。平台服务内容主要包括两部分，一是产品环境适应性测试评价服务，一是产品环境适应性大数据服务。测试评价服务是大数据的主要数据来源和基础，大数据服务是测试评价服务的展示、延伸和增值服务。工业产品环境适应性公共技术服务平台服务行业主要包括汽车、光伏、风电、涂料、塑料、橡胶、家电、电力等。 平台的测试评价服务依据ISO 17025相关要求开展。测试评价服务涉及2个自有实验室、8个自有户外试验场和超过20个合作户外试验场。见图1 图1环境适应性测试评价服务实验室概况
平台的大数据服务，基于产品环境适应性测试评价获取的测试数据以及相关信息，利用数据分析技术，针对不同行业提供产品环境适应性大数据服务，包括但不限于： （1）产品环境适应性基础数据提供； （2）产品环境适应性调研分析报告； （3）产品环境适应性分析预测； （4）产品环境适应性技术规范制定； 2. 信息化系统概述 信息化系统由两个子系统构成，即产品环境适应性测试评价服务管理系统和产品环境适应性大数据服务数据库系统。两个系统紧密关联，大数据系统的主要数据来源于测试评价服务产生的测试数据和试验相关信息，大数据服务是测试评价服务的展示、延伸和增值服务。 信息化系统的整体框架详见图2. 3. 产品环境适应性测试评价服务管理系统 3.1建设内容 （1）测试评价业务的流程化和信息化 实现从来样登记、委托单下达、测试评价记录上传、报告审批、印发到样品试毕处理、收费管理等全流程电脑信息化管理；同时实现电子签名、分类统计、检索、自动提醒、生成报表等功能。 （2）实验室/试验场管理信息化
智慧政务云数据中心总体架构设计
智慧政务云数据中心总体架构设计
目录 第一章、项目总体设计 (3) 1.1、项目设计原则 (3) 1.1.1、统一建设 (3) 1.1.2、相对独立 (3) 1.1.3、共建共享 (3) 1.1.4、安全可靠 (3) 1.2、建设思路 (4) 1.2.1、需求驱动 (4) 1.2.2、标准先行 (4) 1.2.3、围绕数据 (4) 1.2.4、逐步扩展 (4) 1.3、数据中心总体结构设计 (5) 1.3.1、总体逻辑体系结构 (8) 1.3.1.1、信息资源体系 (8) 1.3.1.2、支撑体系 (9) 1.3.1.3、标准规范体系 (9) 1.3.1.4、运行管理体系 (10) 1.3.1.5、安全保障体系 (10) 1.3.2、总体实施结构设计 (10) 1.3.2.1、数据中心交换共享平台及信息资源 (11) 1.3.2.2、数据接口系统区 (12) 1.3.2.3、各部门系统 (12) 1.3.2.4、综合应用 (12) 1.3.3、总体物理体系结构 (12)
第一章、项目总体设计 1.1、项目设计原则 1.1.1、统一建设 数据中心必须统一规范建设。通过制定统一的数据交换与共享标准，建设统一的数据共享与交换平台和统一的前置机接口系统，可以避免重复投资，降低接口的复杂性，有效实现数据中心与业务部门以及业务部门之间的数据共享与数据交换，消除社会保障系统范围内的“信息孤岛”，实现数据资源的互联互通。 1.1.2、相对独立 根据数据中心的功能定位，数据中心的建设和运作必须保持业务系统的相对独立性。为此采用松散耦合方式，通过在业务部门统一配置接口系统实现数据资源整合。 1.1.3、共建共享 一方面建设数据中心的目的是为了实现业务部门之间的数据共享。 另一方面，数据中心的数据来源于各个业务部门，因此数据中心的建设必须依靠各业务部门的积极参与和配合。 1.1.4、安全可靠 由于社会保障数据与广大社会保障对象的切身利益密切相关，所以数据中心的安全是非常重要的。因此，必须要做好系统的安全设计，防范各种安全风险，确保数据中心能够安全可靠的运行。同时数据中心必须采用成熟的技术和体系结构，采用高质量的产品，并且要具有一定的容灾功能。
存储的三种架构
存储架构 三种常见架构：DAS DAS、、NAS NAS、 、SAN 在数据存储中，存储设备与服务器的连接方式通常有三种形式：1、存储设备与服务器直接相连接--DAS；2、存储设备直接联入现有的TCP/IP 的网络中NAS； 3、将各种存储设备集中起来形成一个存储网络，以便于数据的集中管理--SAN。 1、什么是直接附属存储（、什么是直接附属存储（DAS DAS DAS）？ ）？DAS（Direct Attached Storage，直接附属存储），也可称为SAS（Server-Attached Storage，服务器附加存储）。DAS 被定义为直接连接在各种服务器或客户端扩展接口下的数据存储设备，它依赖于服务器，其本身是硬件的堆叠，不带有任何存储操作系统。在这种方式中，存储设备是通过电缆（通常是SCSI 接口电缆）直接到服务器的，I/O（输入/输入）请求直接发送到存储设备。DAS 适用于以下几种环境： 1）服务器在地理分布上很分散，通过SAN（存储区域网络）或NAS（网络直接存储）在它们之间进行互连非常困难； 2）存储系统必须被直接连接到应用服务器； 3）包括许多数据库应用和应用服务器在内的应用，它们需要直接连接到存储器上，群件应用和一些邮件服务也包括在内。
典型DAS 结构如图所示: 对于多个服务器或多台PC 的环境， 使用DAS 方式设备的初始费用可能比较 低，可是这种连接方式下，每台PC 或 服务器单独拥有自己的存储磁盘，容量 的再分配困难；对于整个环境下的存储 系统管理，工作烦琐而重复，没有集中管理解决方案。所以整体的拥有成本（TCO）较高。目前DAS 基本被NAS 所代替。 2、什么是网络附属存储（、什么是网络附属存储（NAS NAS NAS）？ ）？NAS NAS（（Network Attached Storage Storage：网络附属存储） ：网络附属存储）是一种将分布、独立的数据整合为大型、集中化管理的数据中心，以便于对不同主机和应用服务器进行访问的技术。按字面简单说就是连接在网络上,具备资料存储功能的装置，因此也称为“网络存储器”。它是一种专用数据存储服务器。它以数据为中心，将存储设备与服务器彻底分离，集中管理数据，从而释放带宽、提高性能、降低总拥有成本、保护投资。其成本远远低于使用服务器存储，而效率却远远高于后者。NAS （Network Attached Storage，网络附属存储），是一种专业的网络文件存储及文件备份设备，或称为网络直联存储设备、网络磁盘阵列。NAS 存储的特点
大数据中心建设方案设计
数据中心建设方案 信息技术有限公司 目录 第1章方案概述 (2) 1.1. 建设背景 (3) 1.2. 当前现状 (4)
1.3. 建设目标 (5) 第2章方案设计原则 (7) 2.1. 设计原则 (7) 22 设计依据 (8) 第3章数据中心方案架构 (9) 3.1数据中心架构设计 (9) 3.2大数据处理设计 (16) 3.3大数据存储设计 (23) 3.4安全设计 (25) 3.5平台搭建实施步骤 (30) 3.6物理架构设计 (31) 第4章数据中心网络方案组成 (34) 4.1. 防火墙设计 (34) 4.2. 接入层设计 (34) 4.3. 网络拓扑 (35) 第5章数据中心基础设施方案组成 (36) 5.1. 机柜系统设计 (36) 5.2. 制冷系统设计 (38) 5.3. 供配电系统设计 (43) 5.4. 模块监控系统设计 (47) 第6章运维方案 (53) 6.1. 技术和售后服务 (53) 6.2. 售后服务项目 (53) 6.3. 售后服务项目内容 (53) 方案概述 “百年大计，教育为本”，教育行业是我国经济发展的关键命脉之一，伴随着数据集中在教育业信息化的逐渐展开，数据中心在企业和信息化的地位越来越重要。教育数据中心建设已成为教育机构信息化趋势下的必然产物。教育数据中心作为承载教育机构业务的重要IT基础设施，承担着教育机构稳定运行和业务创新的重任。在教育机构新型客户服务模式下，数据中心需要更高效地支持后台业务和信息共享需求，同时要24小时不间断的提供服务，支持多种服务手段。 这对教育数据中心的资源整合，全面安全，高效管理和业务连续性提出更高的要求。
数据仓库基本架构
数据仓库的基本架构 xiaoyi发表于 2013-07-31 23:57 来源：网站数据分析 数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。其实数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。因此数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据仓库、数据应用： 从图中可以看出数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自上而下流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。 数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。 下面主要简单介绍下数据仓库架构中的各个模块，当然这里所介绍的数据仓库主要是指网站数据仓库。 数据仓库的数据来源
其实之前的一篇文章已经介绍过数据仓库各种源数据的类型——数据仓库的源数据类型，所以这里不再详细介绍。 对于网站数据仓库而言，点击流日志是一块主要的数据来源，它是网站分析的基础数据；当然网站的数据库数据也并不可少，其记录这网站运营的数据及各种用户操作的结果，对于分析网站Outcome这类数据更加精准；其他是网站内外部可能产生的文档及其它各类对于公司决策有用的数据。 数据仓库的数据存储 源数据通过ETL的日常任务调度导出，并经过转换后以特性的形式存入数据仓库。其实这个过程一直有很大的争议，就是到底数据仓库需不需要储存细节数据，一方的观点是数据仓库面向分析，所以只要存储特定需求的多维分析模型；另一方的观点是数据仓库先要建立和维护细节数据，再根据需求聚合和处理细节数据生成特定的分析模型。我比较偏向后面一个观点：数据仓库并不需要储存所有的原始数据，但数据仓库需要储存细节数据，并且导入的数据必须经过整理和转换使其面向主题。简单地解释下： (1).为什么不需要所有原始数据？数据仓库面向分析处理，但是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。比如我们知道用户的省份、城市足够，至于用户究竟住哪里可能只是物流商关心的事，或者用户在博客的评论内容可能只是文本挖掘会有需要，但将这些冗长的评论文本存在数据仓库就得不偿失；
数据中心同步平台建设方案
数据中心同步平台建设方案 第一章概述 1.1 平台建设背景 当前政府、企业的信息化的状况是，各政府和企业一般都设计和建设了属于机构、业务本身的应用、流程以及数据的信息处理系统，独立、异构、涵盖各自业务内容的信息处理系统，系统设计建设的时期不同、业务模式不同，信息化建设缺乏有效的总体规划，重复建设；缺乏统一的设计标准，大多数系统都是由不同的厂商在不同的平台上，使用不同的语言进行开发的，信息交互共享困难，存在大量的信息孤岛和流程孤岛。为了有效整合分散异构的信息资源，消除“信息孤岛”现象，提高政府和企业的信息化水平。宇思公司要开发的数据共享交换平台，主要目的是有效整合分散异构系统的信息资源，消除“信息孤岛”现象，提高政府和企业的信息化水平，灵活实现不同系统间的信息交换、信息共享与业务协同，加强信息资源管理，开展数据和应用整合，进一步发挥信息资源和应用系统的效能，提升信息化建设对业务和管理的支撑作用。 要求新构建的数据共享交换平台要遵循标准的、面向服务架构（SOA）的方式，基于先进的企业服务总线ESB技术，遵循先进技术标准和规范，为跨地域、跨部门、跨平台不同应用系统、不同数据库之间的互连互通提供包含提取、转换、传输和加密等操作的数据交换服务，实现扩展性良好的“松耦合”结构的应用和数据集成；同时
要求数据共享交换平台，能够通过分布式部署和集中式管理架构，可以有效解决各节点之间数据的及时、高效地上传下达，在安全、方便、快捷、顺畅的进行信息交换的同时精准的保证数据的一致性和准确性，实现数据的一次 数据共享交换平台-设计方案 采集、多系统共享；要求数据交换平台节点服务器适配器的可视化配置功能，可以有效解决数据交换平台的“最后一公里”问题，快速实现不同机构、不同应用系统、不同数据库之间基于不同传输协议的数据交换与信息共享，为各种应用和决策支持提供良好的数据环境。要求数据共享交换平台能够把各种纷繁复杂的数据系统集成在一起完成特定业务，提供同构数据、异构数据之间的数据抽取、格式转换、内容过滤、内容转换、同异步传输、动态部署、可视化管理监控等方面功能，支持的数据包括各主流数据库（如Oracle、SQL Server、MySQL等）、地理空间数据（如卫星影像、矢量数据）、常规文件（word、excel、pdf）等各种格式，并可以根据用户需求定制开发特定业务服务。 1.2 应用场景 场景一：中国科学院电子学研究所的信息交换需求 实现各个数据中心间的数据库层面的数据共享交换，各中心之间是双向的、实时的数据交换，各数据节点的数据库是同构的数据库系统（即Oracle），数据的类型是基于数据库表格的规则数据，字段类型包含BLOB字段类型。目前各数据节点的数据结构（表）是相同的，主要是一表对一表的数据交换，数据抽取和过滤需求比较简单。目前数据共享交换是通过Oracle GoldenGate数据库同步工具来
数据中心SAN存储架构设计的八大原则
数据中心SAN存储架构设计的八大原则 网界网【转载】 2010年08月31日 10:09 暂无评论 SAN是当今全球各地每一家大型企业机构最为关键的网络资源。没有SAN就没有存储访问和应用支持，业务功能也不能完成。没有业务功能就没有生产力;没有生产力企业也就无法生存。设计SAN来满足关键业务需求正因此成为保持企业本身生存能力的一个战略性组件。 数据中心SAN设计大部分常见参数包括： 可用性—存储数据必须始终可被应用所访问到 性能—可接受的、可预测的、一致的I/O响应时间 效率—不浪费任何资源(端口、带宽、存储、电源) 灵活性—优化数据路径以有效利用容量 可扩展性—随时按需增加连接和容量 可服务性—加快故障排除和问题解决 可靠性—在SAN中设计的冗余且可靠的操作 可管理性—优化传输和存储管理 成本—设计费用控制在预算内，掌握实时运营支出 实际上，这些基本参数的适应范围可能依据客户的不同、SAN部署的不同而有所不同。一款经深思熟虑的SAN设计可综合考虑到所有这些因素，遵循博科SAN设计原则将有助于协调不同需求之间的矛盾。此外，即便是复杂的大型数据中心SAN也可从一个崭新角度中获得收益。只有从这些基本需求着手来分析现有基础设施，这样才能找出其中能采用新SAN设计加以解决的差距及弱点，而在分析的同时仍可重新规划现有的基础设施组件。 原则1: 最小化所管理Fabric架构的数量 这其中包括了物理Fabric架构和虚拟Fabric架构，因为每个虚拟Fabric架构代表着一个管理责任。Fabric架构越少就越容易管理，这道理很简单。然而，在某些情况下，功能、安全及物理限制等问题往往要求有额外的Fabric架构。只有确定SAN管理单元并经由SAN路由提供资源共享，这样或许能在避免资源隔离的同时减少所需Fabric架构数量。 原则2: 最小化每个Fabric架构中交换机数
数据中心设计过程详解
数据中心设计过程详解 艺术的唯美和技术的务实，似乎有着天然的距离。但当我们回顾很多技术的发展历程，就会发现，在那些取得了巅峰成就的地方，总是技术与艺术的完美结合。今天我们就一起深入了解最新的IDC机房基础设施的设计和搭建——只要用心，技术离艺术并不遥远…… 历史回顾 过去十年中，IDC机房的规模多为300-500平米，一般设在办公楼内，其建设多以应用为中心，靠应用来拉动。 现实需求和挑战 IDC机房建设发展到现在，为加强IDC机房的管理，提高其效率，安全性和可靠性，大型、超大型IDC机房的建设需求逐渐增多。而过去IDC机房的设计、建设模式已经不再适应这种发展需求了。 目前，大型IDC机房建设面临的主要挑战有： 1：设计标准落后，基础研究空白，缺乏统计数据。 国内的相关设计，建设标准是93年的，和现实需求相比过于陈旧，最新的规范尚在推广当中。用于指导电信行业的TIA-942规范并不一定对所有用户适用。 2：IDC机房所要支持的业务系统的要求，企业IT架构设计与具体的基础设施设计严重脱节。 3：设计、建造过多依靠经验，缺乏科学的方法和工具。 现有机房工程公司已难以支持，而国内的专业建筑设计院过去很少接触IDC机房设计。 4：技术经济指标，节能措施缺乏计算和考虑，效率低下。 5：缺乏专业的工程管理。 6：设计、建设、运维各个阶段脱节。 IDC机房是专业性很强的工业建筑，运维方式直接对建筑设计提出要求，而运维方式又是由IDC机房所承载的业务类型，模式所决定的，所以各个环节要全面规划。 设计IDC机房时需完全遵守现有国家标准，并广泛参考国际标准，最佳实践经验以及Gartner Infrastructure Maturity Mode。 现在企业做IDC机房建设大部分都处于集中式阶段，部分企业由集中式向标准化走。长远上看，IDC机房基本上要往基于服务，虚拟化方向发展。
数据仓库建设的几点建议.doc
北京甲骨文软件有限公司咨询经理鲁百年博士 一、国内信息化的现状 1、信息化建设的发展历史： 在国内信息化建设过程中，基本上是按照当时业务系统的需求进行建设，例如：在一个企业中，财务部门为了减少工资发放的差错，提高发放的效率，先建设一个工资发放和管理程序；为了报账和核对的需求，建设一个财务管理程序；在银行首先为了业务处理的方便，将最基本的手工记帐和处理的业务建成一个系统，过一段时间，如果有新的业务推出，就再建设一个新的系统，或在原系统的基础上增加新的业务处理。这样的结果使每个系统和系统之间缺少真正的信息沟通和信息交换。 2、为何要建立数据仓库： 前面我们讲过，业务系统各自为政，相互独立。当很多业务系统建立后，由于领导的要求和决策的需求，需要一些指标的分析，在相应的业务系统基础上再增加分析和相应的报表功能，这样每个系统就增加了报表和分析功能。但是，由于数据源不统一导致了对同一个指标分析的结果不相同。为了解决该问题，Bell Inman提出了数据仓库的概念，其目的是为了分析和决策的需要，将相互分离的业务系统的数据源整合在一起，可以为领导和决策层提供分析和辅助决策。 3、国内企业对数据仓库建设认识的误区： 大家对数据仓库的认识是将业务系统的数据进行数据抽取、迁移和加载（ETL），将这些数据进行整合存放在一起，统一管理，需要什么样的分析就可提供什么样的分析，这就是数据仓库。这样做的结果是花了一年到两年的时间都无法将整个企业业务系统的数据整合在一起，花钱多、见效慢、风险大。一年后领导问起数据仓库项目时，回答往往是资金不足，人力不够，再投入一些资源、或者再延长半年的时间就会见到效果，但是往往半年过后还是仅仅可以看到十几张或者几十张报表。领导不满意，项目负责人压力也很大，无法交待。这时，项目经理或者项目负责人才意识到，项目有问题，但是谁也不敢说项目有问题，因为这样显然是自己当时的决策失误。怎么办？寻找咨询公司或者一些大的厂商，答案往往是数据仓库缺乏数据模型，应该考虑数据模型。如果建设时考虑到整个企业的数据模型，就可以建设成企业级的数据仓库（EDW）。什么是数据模型，就是满足整
大数据处理平台构架设计说明书
大数据处理平台及可视化架构设计说明书 版本：1.0 变更记录
目录 1 1. 文档介绍 (3) 1.1文档目的 (3) 1.2文档范围 (3) 1.3读者对象 (3) 1.4参考文献 (3) 1.5术语与缩写解释 (3) 2系统概述 (4) 3设计约束 (5) 4设计策略 (6) 5系统总体结构 (7) 5.1大数据集成分析平台系统架构设计 (7) 5.2可视化平台系统架构设计 (11) 6其它 (14) 6.1数据库设计 (14) 6.2系统管理 (14) 6.3日志管理 (14)
1 1. 文档介绍 1.1 文档目的 设计大数据集成分析平台，主要功能是多种数据库及文件数据；访问；采集；解析，清洗，ETL，同时可以编写模型支持后台统计分析算法。 设计数据可视化平台，应用于大数据的可视化和互动操作。 为此，根据“先进实用、稳定可靠”的原则设计本大数据处理平台及可视化平台。 1.2 文档范围 大数据的处理，包括ETL、分析、可视化、使用。 1.3 读者对象 管理人员、开发人员 1.4 参考文献 1.5 术语与缩写解释
2 系统概述 大数据集成分析平台,分为9个层次，主要功能是对多种数据库及网页等数据进行访采集、解析，清洗，整合、ETL，同时编写模型支持后台统计分析算法，提供可信的数据。 设计数据可视化平台 ,分为3个层次，在大数据集成分析平台的基础上实现大实现数据的可视化和互动操作。
3 设计约束 1.系统必须遵循国家软件开发的标准。 2.系统用java开发，采用开源的中间件。 3.系统必须稳定可靠，性能高，满足每天千万次的访问。 4.保证数据的成功抽取、转换、分析，实现高可信和高可用。
大数据时代下的三种存储架构介绍
大数据时代下的 三种存储架构 数据时代，移动互联、社交网络、数据分析、云服务等应用的迅速普及，对数据中心提出革命性的需求，存储基础架构已经成为IT核心之一。政府、军队军工、科研院所、航空航天、大型商业连锁、医疗、金融、新媒体、广电等各个领域新兴应用层出不穷。 大数据时代，移动互联、社交网络、数据分析、云服务等应用的迅速普及，对数据中心提出革命性的需求，存储基础架构已经成为IT核心之一。政府、军队军工、科研院所、航空航天、大型商业连锁、医疗、金融、新媒体、广电等各个领域新兴应用层出不穷。数据的价值日益凸显，数据已经成为不可或缺的资产。作为数据载体和驱动力量，存储系统成为大数据基础架构中最为关键的核心。 传统的数据中心无论是在性能、效率，还是在投资收益、安全，已经远远不能满足新兴应用的需求，数据中心业务急需新型大数据处理中心来支撑。除了传统的高可靠、高冗余、绿色节能之外，新型的大数据中心还需具备虚拟化、模块化、弹性扩展、自动化等一系列特征，才能满足具备大数据特征的应用需求。这些史无前例的需求，让存储系统的架构和功能都发生了前所未有的变化。 基于大数据应用需求，“应用定义存储”概念被提出。存储系统作为数据中心最核心的数据基础，不再仅是传统分散的、单一的底层设备。除了要具备高性能、高安全、高可靠等特征之外，还要有虚拟化、并行分布、自动分层、弹性扩展、异构资源整合、全局缓存加速等多方面的特点，才能满足具备大数据特征的业务应用需求。 尤其在云安防概念被热炒的时代，随着高清技术的普及，720P、1080P随处可见，智能和高清的双向需求、动辄500W、800W甚至上千万更高分辨率的摄像机面市，大数据对存储设备的容量、读写性能、可靠性、扩展性等都提出了更高的要求，需要充分考虑功能集成度、数据安全性、数据稳定性，系统可扩展性、性能及成本各方面因素。 目前市场上的存储架构如下：
数据仓库模型建设规范1.0
数据仓库模型建设规范 1.概述 数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求、分析、设计、测试等通常的软件生命周期之外，它还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的模型设计异常重要,这也是关系到数据仓库项目成败的关键。 物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基—层层建筑—封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免地要考虑数据库的物理设计。 数据仓库建模的设计目标是模型的稳定性、自适应性和可扩展性。为了做到这一点，必须坚持建模的相对独立性、业界先进性原则。 2.数聚模型架构 在数聚项目实施过程，我们一般将数据仓库系统的数据划分为如下图所示几个层次。
2.1.数据架构图
2.2.架构工作方法规范
2.3.准备层L0 2.3.1.主要数据结构 临时表：从数据源抽取，直接落地到临时表。临时表总是保存这次抽取的数据，不保留历史数据。也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果 是增量抽取的话，就是自从上次修改后的数据。 接口表：从临时表，经过清洗、转换到达接口表。接口表保存历史数据，也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话。 接口表里面也是源系统整个表的数据。 转换表：为了进行清洗和转换建立的中间辅助表。 2.3.2.命名规范 临时表：L0_TMP_源系统_具体业务或 L0_TMP_业务主题_具体业务（对单一源）举例：L0_TMP_POS_SALESORDER 接口表：L0_DCI_业务主题_具体业务表 举例：L0_DCI_SALES_SALESORDER 转换表：L0_MAP_具体业务表 举例：L0_MAP_SALES 2.3.3.开发工作 ●开发数据抽取接口，落地TMP区 ●开发数据清洗转换程序，落地DCI区，多源系统进行合并 ●开发数据装载程序，装载到L1层 2.4.原子层L1 2.4.1.主要数据结构 维度表：整个数据仓库一致的维度 代码表：维度属性，非维度代码等。 原子事实表：根据业务主题，形成原子事实表 汇总事实表：根据分析主题，业务主题形成合并或汇总的事实表。