大数据网站解决方案.docx
《大数据网站解决方案.docx》由会员分享，可在线阅读，更多相关《大数据网站解决方案.docx（9页珍藏版）》请在冰点文库上搜索。
大数据网站解决方案
大数据网站解决方案
篇一：
基于大数据的能力开放平台解决方案
基于大数据的能力开放平台解决方案
1摘要
关键字：
大数据经分统一调度能力开放
运营商经过多年的系统建设和演进，内部系统间存在一些壁垒，通过在运营商的各个内部系统,如经分、VGOP、大数据平台、集团集市等中构建基于ESB的能力开放平台,解决了系统间调度、封闭式开发、数据孤岛等系统问题，使得运营商营销能力和效率大大提高。
2问题分析
背景分析
随着市场发展，传统的开发模式已经无法满足业务开发敏捷性的要求。
XX年以来，某省运营商经营分析需求量激增，开发时限要求缩短，业务迭代优化需求频繁，原有的“工单-开发”模式平均开发周期为天，支撑负荷已达到极限。
能力开放使业务人员可以更便捷的接触和使用到数据，释放业务部门的开发能力。
由于历史原因，业务支撑系统存在经分、VGOP、大数据平台、集团集市等多套独立的运维系统，缺乏统一的运维管理，造成系统与系统之间的数据交付复杂，无法最大化
的利用系统资源。
统一调度的出现能够充分整合现有调度系统，减少运维工作量，提升维护质量。
驱动力一：
程序调度管理混乱，系统资源使用不充分
经分、大数据平台、VGOP、集团集市平台各自拥有独立的调度管理，平台内程序基本是串行执行，以经分日处理为例，每日运行时间为20个小时，已经严重影响到了指标的汇总展示。
驱动力二：
传统开发模式响应慢，不能满足敏捷开发需求
大数据平台已成为一个数据宝库，已有趋势表明，只依赖集成商与业务支撑人员的传统开发模式已经无法快速响应业务部门需求，提升数据价值。
驱动力三：
大数据平台丰富了经分的数据源，业务部门急待数据开放
某省运营商建立了面向企业内部所有部门的大数据平台，大数据平台整合了接入B域、O域、互联网域数据，近100余个数据接口，共计820T的数据逐步投入生产。
大数据平台增强了传统经分的数据处理的能力，成为公司重要的资产，但是传统经分数据仓库的用户主要面向业支内部人员，限制了数据的使用人员范围和数据的使用频度，已经无法满足公司日益发展的业务需求，数据的开放迫在眉睫。
问题详解
基于背景情况分析，我们认为主要问题有三个：
1、缺乏统一的调度管理，维护效率低下
目前经分系统的日处理一般是使用SHELL脚本开发的，按照串行调度的思路执行。
进行能力开放后，目前的系统架构无法满足开发者提交的大量程序执行调度的运维需求。
如果采用统一调度的设计思路则基于任务的数据表依赖进行任务解耦及调度，将大大简化调度配置工作和提高系统的
并发度；
2、需求周期长，导致开发周期长
现行的开发模式是由业务部门提出需求，业务支撑中心进行需求分析，然后再转派给开发厂商。
厂商除了需要与业支沟通需求以外，有时候还需要与业务部门进行二次沟通，最终才能明确需求，开发周期比较长；
3、数据管理分散，存在数据冗余，营销效果欠佳
经分系统对外提供数据，目前采用的是传统的文件接口形式，这样会造成经分和外围系统存在至少2份的数据，随着经分的按天支撑模式，造成传统的营销效果欠佳，外围系统的存储浪费。
3解决方案介绍
业务目标
将大数据平台及经分数据仓库平台的数据和系统处理能力进行标准化封装，按需进行开放，满足各业务部门数据使用的需求，并在经验成熟的情况下逐渐开放给外部众多的合作伙伴使用。
统一调度：
作为大数据开放基础平台，通过消息总线将大数据平台、经分、集市、VGOP、业务部门的应用进行统一的系统调度管控，提供跨平台调度、分发、解析等基础功能，实现大数据平台、经分数据仓库等多类型底层平台的能力互补，形成融合平台的协作效应；通过多租户技术，解决生产任务与数据开放能力争用的问题，实现系统资源
对生产任务与临时任务的合理分配及高效调度。
统一开发：
集成图形化的开发界面，通过统一封装的函数库提供类SQL的开发语言，以屏蔽底层平台差异，降低业务人员的开发门槛，实
现快速的业务开发及数据测试。
通过元数据的数据模型抽象，逐步将Hadoop、DB2的后台数据资源高效、安全并可控可管的开放给前端进行访问。
数据共享：
大数据平台将用户标签、营销目标、用户套餐剩余量等信息通过统一的数据服务方式开放给其他系统或者在线使用，确保数据的唯一性和数据响应的及时性。
方案内容及亮点
图为基于大数据的能力开放体系架
构，我们在原有大数据平台上进行整合，
使得大数据的成果能够有效的被外部系
统调用，并具备标准的服务能力供后续
的系统对接。
能力开放平台由统一调度、统一开
发、数据共享三大平台组成：
统一调度平台将原大数据平台、经
分数据仓库、VGOP平台等关联度高的独
立应用系统的任务进行统一管理、执行
调度及监控，提升整体的执行效率并简
化运维。
统一开发平台搭建于统一调度的基础之上，开发者可以通过IDE使用封装后的函数，以SQL脚本进行图形化的数据处理程序设计及开发。
通过多租户的方式，对开发者分配独立的大数据平台及数据仓库的存储、计算
资源，确保开发者在共享数据、系统能力的同时，不影响生产系统的正常运行。
数据共享平台提供标准API封装，提供给外部系统进行数据查询和调用，实现经分系统对外数据服务标准化，同时保障数据安全性并降低外部系统数据存储压力。
统一调度
统一调度由控制中心和AGENT两部分组成，如下图所示：
（1）控制中心:
控制中心接收来自内部的消息，通过规则引擎判断任务是否满足触发条件并分发给Agent进行处理，并对任务执行情况进行监控及消息生成。
消息接收：
支持各种事件触发消息，如文件到达、接口装载、表生成；规则引擎：
根据人工定义、系统资源情况、租户定义等设置制定任务的执行条件及前后依赖关系；
任务触发：
根据消息总线传递的消息，判断任务是否具备执行条件，并将满足触发条件的任务分发至各平台Agent端执行；
篇二：
数据库大数据访问的解决方案
数据库大数据访问的解决方案
当系统要满足每秒数万次的读写请求的需求时，我们可以用分布式计算、编写优良的程序代码、对海量数据进行分区操作、建立广泛的索引、建立缓存机制、加大虚拟内存、分批处理、使用数据仓库和多维数据库存储、使用负载均衡技术、将数据库的读写分离等等来解决数据库大数据访问的问题。
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。
对于一个大型的互联网应用，每天百万级甚至上亿的PV无疑对数据库造成了相当高的负载。
对于系统的稳定性和扩展性造成了极大的问题。
一、那么数据库如何处理海量数据呢？
1、编写优良的程序代码
处理数据离不开优秀的程序代码，尤其在进行复杂数据处理时，必须使用程序。
好的程序代码对数据的处理至关重要，这不仅仅是数据处理准确度的问题，更是数据处理效率的问题。
良好的程序代码应该包含好的算法，包含好的处理流程，包含好的效率，包含好的异常处理机制等。
2、对海量数据进行分区操作
对海量数据进行分区操作十分必要，例如针对按年份存取的数据，我们可以按年进行分区，不同的数据库有不同的分区方式，不过处理机制大体相同。
例如SQLServer的数据库分区是将不同的数据存于不同的文件组下，而不同的文件组存于不同的磁盘分区下，这样将数据分散开，减小磁盘I/O，减小了系统负荷，而且还可以将日志，索引等放于不同的分区下。
3、建立广泛的索引
对海量的数据处理，对大表建立索引是必行的，建立索引要考虑到具体情况，例如针对大表的分组、排序等字段，都要建立相应索引，一般还可以建立复合索引，对经常插入的表则建立索引时要小心，笔者在处理数据时，曾经在一个ETL流程中，当插入表时，首先删除索引，然后插入完毕，建立索引，并实施聚合操作，聚合完成后，再次插入前还是删除索引，所以索引要用到好的时机，索引的填充因子和聚集、非聚集索引都要考虑。
4、加大虚拟内存
如果系统资源有限，内存提示不足，则可以靠增加虚拟内存来解决。
笔者在实际项目中曾经遇到针对18亿条的数据进行处理，内存为1GB，1个P4的CPU，对这么大的数据量进行聚合操作是有问题的，提示内存不足，那么采用了加大虚拟内存的方法来解决，在6块磁盘分区上分别建立了6个4096M的磁盘分区，用于虚拟内存，这样虚拟的内存则增加为4096*6+1024=25600M，解决了数据处理中的内存不足问题。
5、分批处理
海量数据处理难因为数据量大，那么解决海量数据处理难的问题其中一个技巧是减少数据量。
可以对海量数据分批处理，然后处理后的数据再进行合并操作，这样逐个击破，有利于小数据量的处理，不至于面对大数据量带来的问题，不过这种方法也要因时因势进行，如果不允许拆分数据，还需要另想办法。
不过一般的数据按天、按月、按年等存储的，都可以采用先分后合的方法，对数据进行分开处理。
6、使用数据仓库和多维数据库存储
数据量加大是一定要考虑OLAP的，传统的报表可能5、6个小时出来结果，而基于Cube的查询可能只需要几分钟，因此处理海量数据的利器是OLAP多维分析，即建立数据仓库，建立多维数据集，基于多维数据集进行报表展现和数据挖掘等。
7、使用采样数据，进行数据挖掘
基于海量数据的数据挖掘正在逐步兴起，面对着超海量的数据，一般的挖掘软件或算法往往采用数据抽样的方式进行处理，这样的误差不会很高，大大提高了处理效率和处理的成功率。
一般采样时要注意数据的完整性和，防止过大的偏差。
笔者曾经对1亿2千万行的表数据进行采样，抽取出400万行，经测试软件测试处理的误差为千分之五，客户可以接受。
还有一些方法，需要在不同的情况和场合下运用，例如使用代理键等操作，这样的好处是加
快了聚合时间，因为对数值型的聚合比对字符型的聚合快得多。
类似的情况需要针对不同的需求进行处理。
海量数据是发展趋势，对数据分析和挖掘也越来越重要，从海量数据中提取有用信息重要而紧迫，这便要求处理要准确，精度要高，而且处理时间要短，得到有价值信息要快，所以，对海量数据的研究很有前途，也很值得进行广泛深入的研究。
二、下面注意讲解下负载均衡技术、数据库的读写分离、数据库拆分（分布式）
1、负载均衡技术
负载均衡集群是由一组相互独立的计算机系统构成，通过常规网络或专用网络进行连接，由路由器衔接在一起，各节点相互协作、共同负载、均衡压力，对客户端来说，整个群集可以视为一台具有超高性能的独立服务器。
实现原理
实现数据库的负载均衡技术，首先要有一个可以控制连接数据库的控制端。
在这里，它截断了数据库和程序的直接连接，由所有的程序来访问这个中间层，然后再由中间层来访问数据库。
这样，我们就可以具体控制访问某个数据库了，然后还可以根据数据库的当前负载采取有效的均衡策略，来调整每次连接到哪个数据库。
实现多据库数据同步
对于负载均衡，最重要的就是所有服务器的数据都是实时同步的。
这是一个集群所必需的，因为，如果数不据实时、不同步，那么用户从一台服务器读出的数据，就有别于从另一台服务器读出的数据，这是不能允许的。
所以必须实现数据库的数据同步。
这样，在查询的时候就可以有多个资源，实现均衡。
比较常用的方法是MoebiusforSQLServer集群，MoebiusforSQLServer集群采用将核心程序驻留在每个机器的数据库中的办法，这个核心程序称为MoebiusforSQLServer中间件，主要作用是监测数据库内数据的变化并将变化的数据同步到其他数据库中。
数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成
的，保证了多份数据在任何时刻数据的一致性。
正因为Moebius中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能的采取不同的数据同步的策略以保证数据同步成本的最小化。
数据条
数很少，数据内容也不大，则直接同步数据
数据条数很少，但是里面包含大数据类型，比如文本，二进制数据等，则先对数据进行压缩然后再同步，从而减少网络带宽的占用和传输所用的时间。
数据条数很多，此时中间件会拿到造成数据变化的SQL语句，然后对SQL语句进行解析，分析其执行计划和执行成本，并选择是同步数据还是同步SQL语句到其他的数据库中。
此种情况应用在对表结构进行调整或者批量更改数据的时候非常有用。
优缺点
（1）扩展性强：
当系统要更高数据库处理速度时，只要简单地增加数据库服务器就可以得到扩展。
（2）可维护性：
当某节点发生故障时，系统会自动检测故障并转移故障节点的应用，保证数据库的持续工作。
（3）安全性：
因为数据会同步的多台服务器上，可以实现数据集的冗余，通过多份数据来保证安全性。
另外它成功地将数据库放到了内网之中，更好地保护了数据库的安全性。
（4）易用性：
对应用来说完全透明，集群暴露出来的就是一个IP
2、数据库的读写分离
实现原理
读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。
主数据库提供写操作，从数据库提供读操作，其实在很多系统中，主要是读的操作。
当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。
（ebay的
读写比率是260:
1,eba（来自:
小龙文档网:
大数据网站解决方案）y的读写分离）
篇三：
大数据应用解决方案
交通行业大数据应用
背景：
随着经济发展迅猛，地方交通越来越繁忙，机动车辆不断增加，地方政府需要好的方法对过往车辆进行监控管理，从而提供更好的交通服务。
地方交通部门采用了数据驱动的方法，在市内重要检查点安装了上千台数字监控设备，这些设备7×24小时不间断捕获图像和视频数据，每月数据量达TB级。
现在，交通部门面临着如何通过有效利用这些不断增加的交通信息数据该改进交通管理的挑战。
要解决的问题：
1.集中管理交通数据。
集中访问分散存储在不同的支队数据中心的图像或视频等交通数据和道路交通管理设施、装备和应用系统等。
2.优化海量数据利用。
提供尽可能长时间段的车辆监控数据为市公安治安、刑侦、经侦部门人员及一线民警等提供信息支撑服务。
3.改善交通。
提高对各种交通突发事件的应急调度能力，依据历史数据预测交通或突发事件的趋势。
4.提升交通案件侦破能力。
5.增强交通警察对机动车辆的监管能力
实施后的效果：
1.实现基础过车结构化数据的永久存储，可以保存最近24个月的交通违法图像数据，实时对数据检索，并可随时无缝扩容。
2.单服务器允许平均每秒250次500KB尺寸图片同步传输或XX次异步并发存储。
3.不到1秒即可得到从24亿条过车数据中的机动车号牌查询出的精确结果和行车轨迹。
4.提升交通案件侦破能力。
机动车违法图像信息在系统的保存周期从3个月延长到24个月，交通警察等部门可根据车辆的颜色、车型、号牌等信息实时查询其历史行为、行车路线和车辆营运公司、驾驶人等关联信息。
5.增强交通警察对机动车辆的监管能力。
交警可以从24亿条过车数据中轻松检索被监测机动车的号牌精确查询和行车轨迹。
6.便捷利用关联车辆的分析数据。
针对24亿条实际过车数据进行两卡点、多卡点的伴随车辆和碰撞车辆的复杂分析，查询耗时仅为10秒左右。
运营商详单账单查询大数据应用
新一代详单账单查询系统（省级）
背景：
微博、微信的快速发展所带来的非结构化语言记录、音频、图片和视频等数据加快了电信行业数据量的增长速度。
海量的非结构化数据带来的并不仅仅是存储、传输的问题，做好海量非结构化数据分析以更好的服务客户、提高效率已经成为全球运营商当前最为紧迫的问题。
随着移动设备、快速3G和4G连接、自助服务或帐户相关信息查询服务日益受到消费者的青睐，除了传统的语音，上网、短信以及在线查询每月账单/电话详单信息相关的数据通信部分迅速增加。
随着业务不断扩展，3G用户数量和计费数据记录已使查询数据请求的数量明显增加，系统响应速度变慢。
要解决的问题：
1.现有计费系统维护成本高，降低了计费业务单位的盈利能力。
2.速度慢，降低了服务质量。
当前高科技个性化的客户支持模式不可扩展，无法应对爆炸性的需求增长，可能会导致不满的顾客流向竞争对手。
3.解决规模问题。
RDBMS解决方案无法满足存储规模和实时查询要求，进而无法为用户提供优质服务。
实施后的效果：
1.个人用户能够查询并在线支付话费，准确实时查询六个月内的电话详单。
2.X86解决方案只以当前RISC平台价格的一小部分就实现了这些功能，但在规模上却以经济的方式扩展到数亿个用户。
3.新的分析数据功能，可显示实际客户使用情况、偏好和按照细分客户群提供服务的成本之间的联系。
同时可以主动监测网络使用情况，发现性能瓶颈，确定哪些网站与用户产生的数据收费最高。
4.性能更高：
账单明细检索查询速度是300000份账单/秒，插入速度是800000份账单/秒。
该系统目前每月无缝处理30TB的用户计费数据，每个表支持数十亿份账单。
查询性能提高了30倍,从而大大提高了新系统的负载能力,可以支持数百万用户同时在线查询。
5.高可靠性：
该系统不需要保存在一台中央计算机或单一MPP数据仓库中，从而改进了跨集群（平均每个集群80个节点）的灾难恢复能力。
HDFS的自恢复功能可以使数据的信息在集群中永远保留三份副本，这样数据就不会丢失。
当硬件或网络不能运转时，它仍然可以提供数据和文件读写能力。
运营商网络优化大数据应用
背景：
运营商的网络环境日趋复杂，其中无线接入网就有2G、3G、WiFi、LTE等多种制式，基站的分布密度越来越高，用户数也越来越多，对于海量的网络设备信息、网络运行信息、用户信息和终端呼叫信令等数据，系统的网络优化越来越困难。
网络优化实时性要求非常高，一旦基站出现了故障，必须在非常短的时间内进行定位和修复，否则不仅会造成直接的经济损失，而且会导致用户大面积的投诉，甚至导致用户流失，也对潜在的用户造成不好的影响。
如何通过使用合适的大数据平台存储信令大数据，进行端到端网络质量的分析，快速进行网络优化和故障定位，是运营商吸引增加用户、减少用户流失、增加收入和实现精细化运营的一个关键问题。
要解决的问题：
1.海量数据存储。
网优系统6个月处理的语音记录高达90TB。
2.历史记录查询。
需支持超过12个月时间跨度的访问查询。
3.实时并发入库。
4.快速的信令分析平台。
大量的信令、无线参数、网络配置参数等数据源源不断地涌入到信令分析平台，这些数据如果不能及时得到处理，实时网络优化就无从谈起。
5.平滑的系统迁移。
多年以来，运营商已有大量的信令分析系统、硬件设备和网络数据，在大数据时代这一新的形势下，如何将这些已有的业务系统进行平滑迁移也是运营商需要解决的关键问题。
实施后的效果：
1.可扩展的海量数据存储。
Transwarp大数据平台利用相对廉价的服务器提供的HDFS分布式存储技术，可以低成本方式实现PB级别的海量数据存储，而且利用集群的水平扩展性，基本消除I/O瓶颈。
2.实时高并发的查询。
Transwarp大数据平台支持将关系表装载进分布式内存中，采用Transwarp自主研发的列式存储格式，支持高速查询、多维度分析以及迭代式分析应用，数据分析效率高。
3.海量信令综合分析。
借助大数据平台存储的海量信息，网优专家可以调用包括结构化信令数据、地图数据、语言数据、视频数据等各种形式的所有相关数据，选用各种模型，通过高性能的分布式计算框架快速地综合分析出KPI指标变化的原因，从而采取措施实施有效的网络优化。
4.提升无线环境质量。
通过使用Transwarp大数据平台，网规网优专家合理构建了网络架构，调优了无线参数，可使无线覆盖率大幅提高、信号更稳定、干扰程度得到显著降低。
5.用户数增加。
网络服务质量提升，客户投诉处理加快，增加了客户的满意度，吸引新增用户，直接为运营商带来营收。
实时视频监控大数据应用
背景：
视频监控系统已成为城市环境中的一种标准做法，旨在帮助协调应急响应，引导交通，并加强公民的人身安全。
要解决的问题：
1.视频图像的实时分析。
例如部署在治安系统应用中时，一旦通过前端摄像头采集到嫌疑人的图像，需要快速地对采集到的图像做出分析，判断嫌疑人的身份属性，从而帮助公安人员进行下一步行动。
2.高效的视频数据存储系统。
每个前端摄像头的码流速率都在6Mbps以上，势必会给后台分析系统带来海量的数据。
急需一个新的后台分析系统来处理海量数据。
3.视频搜索效率低。
在遇到如治安分析等业务请求时，由于分析性能的限制，无法达到客户需要的实时性要求。
4.访问吞吐带宽小。
原有系统视频存放在集中式存储中，当需要大范围查询、调用时，存储系统带宽成为整个系统的瓶颈，妨碍查询业务的使用。
5.搜索服务可靠性差。
原有系统当有个别集群服务器出错时，无法做到集群自动修复，从而造成整个搜索任务的失败
6.集群管理维护难。
原有系统没有一个从硬件到软件到服务状态的整体监控和管理系统，使用者无法监控、维护和保障整个集群运行。
实施后的效果：
1.性能提升，比原来的Oracle数据库性能提高5倍。
2.与传统数据库相比，各个应用的分析耗时更短。
3.Hadoop分布式集群中的服务器既是计算节点又是存储节点。
4.HDFS分布式文件系统的访问带宽是整个网络的聚合带宽，可以达到几百Gbps以上，完全消除了视频存储的访问带宽限制。
5.可以实现存储位置感知，将任务分配到视频所存储的节点之上，充分利用本地硬盘带宽，使访问吞吐进一步提高。
6.在执行较长时间的视频搜索任务时，如果主任务调度器发生故障，备用任务调度器会自动接替，使搜索任务避免失败。
当个别搜索任务失败时，任务调度器可以在集群中的另一个节点上自动重试。
金融行业大数据应用
行业需求：
1.需要可扩展性开放架构做支撑。
大数据量必然要求金融企业IT基础设施更易于数据的整合与集中、扩展与伸缩以及管理与维护，同时还必须具备良好的可靠性、可控性、安全性。
2.大数据在加强风险管控、精细化管理、业务创新等业务转型中将起到重要作用。
首先，大数据能够加强风险
升级会员 