《实时数据库方案讨论》由会员分享，可在线阅读，更多相关《实时数据库方案讨论（7页珍藏版）》请在金锄头文库上搜索。
1、实时数据库应用方案讨论一、 定义实时计算的概念实时计算一般都是针对海量数据进行的，一般时间要求为秒级。实时计算主要分为两块:数据的实时入库、数据的实时计算。二、 主要应用场景1) 数据源是实时的不间断的，要求用户的响应时间也是实时的（比如对于大型网站的流式数据：网站的访问PV/UV、用户访问了什么内容、搜索了什么内容等，实时的数据计算和分析可以动态实时地刷新用户访问数据，展示网站实时流量的变化情况，分析每天各小时的流量和用户分布情况）2) 数据量大且无法或没必要预算，但要求对用户的响应时间是实时的。比如说： 昨天来自每个省份不同性别的访问量分布，昨天来自每个省份不同性别不同年龄不同职业不同名族
2、的访问量分布。三、实时计算的相关技术主要分为三个阶段（大多是日志流）：数据的产生与收集阶段、传输与分析处理阶段、存储对对外提供服务阶段。下面具体针对上面三个阶段详细介绍下1）数据实时采集：需求：功能上保证可以完整的收集到所有日志数据，为实时应用提供实时数据；响应时间上要保证实时性、低延迟在1秒左右；配置简单，部署容易；系统稳定可靠等。目前的产品：Facebook的Scribe、LinkedIn的Kafka、Cloudera的Flume，淘宝开源的TimeTunnel、Hadoop的Chukwa等，均可以满足每秒数百MB的日志数据采集和传输需求。他们都是开源项目。2）数据实时计算在流数据不断变化
3、的运动过程中实时地进行分析，捕捉到可能对用户有用的信息，并把结果发送出去。实时计算目前的主流产品：1. Yahoo的S4：S4是一个通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统，Yahoo开发S4系统，主要是为了解决：搜索广告的展现、处理用户的点击反馈。2. Twitter 的Storm流计算系统：是一个分布式的、容错的实时计算系统架构。可用于处理消息和更新数据库（流处理），在数据流上进行持续查询，并以流的形式返回结果到客户端（持续计算），并行化一个类似实时查询的热点查询（分布式的RPC 数据库）。3. Facebook 的Puma：Facebook使用puma和HBase相结合来
4、处理实时数据，Hbase为分布式KV结构的列式数据库系统，支持大数据量的实时查询。3）数据数据查询服务 半内存：使用Redis、Memcache、MongoDB、BerkeleyDB等内存数据库提供数据实时查询服务，由这些系统进行持久化操作。 全磁盘：使用HBase等 以分布式文件系统（HDFS）为 基础的NoSQL 数据库，对于key-va lue引擎， 关键是设计好key的分布。 全内存：直接提供数据读取服务，定期dump到磁盘或数据库进行持久化。四、方案架构选择： A（开源架构方式）Timetunel +Hbase + Storm + UPS（timetunel技术介绍：http:/ S
5、torm被广泛用来进行实时日志处理，一般出现在实时统计、实时风控、实时推荐等场景中。 一般来说，我们从类kafka的metaQ或者基于HBase的timetunnel中读取实时日志消息，经过一系列处理，最终将处理结果写入到一个分布式存储中，提供给应用程序访问。每天的实时消息量可以满足从几百万到几十亿不等，数据总量达到TB级。一般讲，Storm往往会配合分布式存储服务一起使用。例如，在进行的个性化搜索实时分析项目中，就使用了timetunnel +HBase + Storm + ups的架构，每天处理几十亿的用户日志信息，从用户行为发生到完成分析延迟在秒级。Storm计算介绍：1. Nimbus
6、：负责资源分配和任务调度。2. Supervisor：负责接受nimbus分配的任务，启动和停止属于自己管理的worker进程。3. Worker：运行具体处理组件逻辑的进程。4. Task：worker中每一个spout/bolt的线程称为一个task. 在Storm0.8之后，task不再与物理线程对应，同一个spout/bolt的task可能会共享一个物理线程，该线程称为executor。架构流程图；整个数据处理流程包括四部分：第一部分是数据接入该部分从前端业务系统获取数据。第二部分是最重要的Storm 实时处理部分，数据从接入层接入，经过实时处理后传入数据落地层；第三部分为数据落地层，
7、该部分指定了数据的落地方式；第四部分元数据管理器。数据接入层该部分有多种数据收集方式：使用消息队列（MetaQ），直接通过网络Socket传输数据，前端业务系统专有数据采集API，对Log问价定时监控。(注：有时候我们的数据源是已经保存下来的log文件，那Spout就必须监控Log文件的变化，及时将变化部分的数据提取写入Storm中，这很难做到完全实时性。)数据落地层：MetaQ如图架构所示，Storm与MetaQ是有一条虚线相连的，部分数据在经过实时处理之后需要写入MetaQ之中，因为后端业务系统需要从MetaQ中获取数据。这严格来说不算是数据落地，因为数据没有实实在在写入磁盘中持久化。My
8、sql数据量不是非常大的情况下可以使用Mysql作为数据落地的存储对象。Mysql对数据后续处理也是比较方便的，且网络上对Mysql的操作也是比较多的，在开发上代价比较小，适合中小量数据存储。HDFSHDFS及基于Hadoop的分布式文件系统。许多日志分析系统都是基于HDFS搭建出来的，所以开发Storm与HDFS的数据落地接口将很有必要。例如将大批量数据实时处理之后存入Hive中，提供给后端业务系统进行处理，例如日志分析，数据挖掘等等。LustreLustre作为数据落地的应用场景是，数据量很大，且处理后目的是作为归档处理。这种情形，Lustre能够为数据提供一个比较大（相当大）的数据目录，
9、用于数据归档保存。元数据管理器元数据管理器的设计目的是，整个系统需要一个统一协调的组件，指导前端业务系统的数据写入，通知实时处理部分数据类型及其他数据描述，及指导数据如何落地。元数据管理器贯通整个系统，是比较重要的组成部分。元数据设计可以使用mysql存储元数据信息，结合缓存机制开源软件设计而成。B 实时采集程序+kafka消息队列+实时数据计算+codis（redis集群模式）+前端展现应用方案表述：1. 数据采集程序：自定义开发采集程序客户端，支持自定义配置，如采集频率、保存方式等。2. 数据传输：采用kafka消息队列方式。将采集后的程序存储到kafka消息队列系统中。Kafka可以作为集群模式。主要解决的是快速承接数据的接入，避免数据在边缘的堆积。3. 实时计算：在数据进入kafka集群后，可以通过自定义消费程序，或者采用开发的实时计算框架，如storm等，消费里面的数据，然后将处理结果集存储到kv内存数据库中，这样保证前端查询的快速性。也可以将快速查询的数据库中，如oracle、mysql等。4. 前端查询服务：在前端构建基于内存数据库的快速查询系统。
