不用Hadoop的百亿级大数据方案

1、百亿级实时大数据分析项目，为什么不用百亿数量级的大数据项目，软硬件总体预算只有30万左右，需求是进行复杂分析查询，性能要求多数分析请求达到秒级响应。遇到这样的项目需求,预算不多的情况，似乎只能考虑基于来实施。理论上撑住百亿数量级没问题，但想要秒级响应各种查询分析就不行了。我们先大概分析一下的优缺点。目前几乎是大数据的代名词，很多企业都基于搭建自己的大数据业务。以下是的主要优点：集群的扩展性是其一大特点，可以扩展至数千个节点，对数据持续增长，数据量特别巨大的需求很合适。的成本是其另一大优势，由于是开源项目，而且不仅从软件上节约成本，硬件上的要求也不高。目前去潮流风行，低成本的也是一大推手。生态群

2、活跃，其周边开源项目丰富，等等基础开源项目众多。那么的不足有哪些呢？不适合做实时分析系统。从通讯层的技术上来说有如下原因：任务分配不会将信息到计算,而是让计算通过心跳去任务。基于框架的通用性，代码也会在中传送，在各计算展开，再通过启动新进程装载并运行。类似的进程启停有5次之多。只能在全部完成之后才能启动。缺乏专业的支持服务因为是开源项目，缺少专业的商业支持服务，公司需要储备专业知识的专家来保证系统的正常运转。可以支持百亿的数据量，但很难应对秒级响应的需求即使是数亿的数据量，也只适合做分钟级别的离线分析系统。而百亿级别数据量，又需要秒级响应的案例，需要什么系统支持呢？下面介绍下大数据实时分析工具

3、。让用户可以选购分布式数有哪些技术可以保证大数据的除了提供优秀的前端工具之外，据集市来支持实时大数据分析。对于这种百亿级的大数据案例，实时响应呢？下面大致从技术上介绍下：库内计算通过结合多种自有的专利技术，在几个节点下,就能支持各种常见的汇总，还支持几乎全部的专业统计函数。得益于库内计算技术，数据分析引擎将找寻出最优化的计算方案，继而把所有开销较大的、昂贵的计算都移动到数据存储的地方直接计算，称之为库内计算t这一技术大大减少了数据移动，降低了通讯负担，保证了高性能数据分析。并行计算是基于架构的商业智能平台，她能够把计算分布到多个计算节点，再在指定节点将计算结果汇总输出。能够充分利用各种计算和存

4、储资源，不管是服务器还是普通的，她对网络条件也没有严苛的要求。作为横向扩展的大数据平台，能够充分发挥各个节点的计算能力，轻松实现针对级数据分析的秒级响应。列存储是列存储的。基于列存储的数据集市，不读取无关数据，能降低读写开销，同时提高的效率，从而大大提高查询性能。另外，列存储能够更好地压缩数据，-般压缩比在倍之间，这样一来，数据占有空间降低到传统存储的到。良好的数据压缩技术，节省了存储设备和内存的开销，却大大了提升计算性能。内存计算得益于列存储技术和并行计算技术，能够大大压缩数据，并同时利用多个节点的计算能力和内存容量。一般地，内存访问速度比磁盘访问速度要快几百倍甚至上千倍。通过内存计算，直接

5、从内存而非磁盘上读取数据并对数据进行计算。内存计算是对传统数据处理方式的一种加速，是实现大数据分析的关键应用技术。担负起几十亿，乃至上百亿数据量的实时分析和展现。相对有哪些不足呢？能支撑级大数据，数千节点的大规模集群。对于这种实时大数据分析系统一般支撑级的大数据，节点数一般不超过10。0以下分享一个的真实案例：中国移动省分公司数据流量与监控系统年月，收到一个电话线索，客户需要支持几十亿数据量的实时查询与分析，包括数据抓取和存储，让我们先出报价。在实时大数据分析领域，的产品和服务是很有竞争力的。不过，当客户拿到我们的报价后，还是觉得比他们的预算贵一些，决定自己招聘团队，实施该系统半个月后，客户打

6、来第二个电话，明确表示未能满足需求，决定接受我们的报价，并愿意预付一半的费用。客户要求我们不仅出产品，还要负责实施于是乎，开工！项目价值网间流量分析与监控系统（简称流控系统），是中国移动省分公司的一个项目。项目要求能基于时间、地区、运营商、业务、分组、域名等维度对全省的上网流量进行实时分析和报告。这些分析报告能给客户带来如下好处：1.实现对接入链路和基站的全程监控。例如，一旦来自某链路或基站的流量很低，可及时对链路和基站进行检修，这将大大降低故障率。通过结合多种自有的专利技术，在几个节点下,就能.由于具备了对链路和基站进行全程监控的能力，客户可以对链路和基站的带宽进行动态调整，基于需求进行合理

7、的资源配置。覆盖全省的全量数据,能提供基于业务地域行业域名等维度的数据分析报告，具备的可信度和极高的商业价值。数据流向上网数据从硬件设备中抓取出来，形成压缩的日志文件存储在服务器上，服务器每五分钟生成新的日志文件。该服务器提供访问。承担的流控系统，将通过每五分钟访问一次日志文件服务器，将新生成的压缩日志文件抽取出来。这是一个典型的、增量更新的过程，如下：定期抽取的日志文件并解压缩。解析出上网信息，同的维度表进行关联，生成包括业务地域行业域名等维度的宽表。将数据装载入分布式集市。初期验证（）中国移动的日志数据分类和类，各取几块样本日志文件，验证数据流向的可行性以及性能。我们很快完成了的整个过程，

8、宽表数据被成功地装载入分布式集市。性能上，我们按照用户提出的每天数据量500万0条增量，计算出支持100天50亿数据量的分布式集群所需的磁盘空间、内存总量、和总量。由于客户一再强调预算有限，内存，硬盘。于是配置了6台低配我们模拟了常用的用户场景，整个系统的响应能力基本满足需求。系统架构如下：系统架构图正式实施中国移动省分公司的上网数据在内网，一般不提供外网连接，需要严格申请之后才能在一定时间内提供外网连接。因而，我们先把整个系统的工作开发完成之后，才正式申请了外网连接进行数据装载。从开始进行上网数据的工作，我们就发现数据量与预期严重不符。预期的上网数据是每天不超过500万0条，但实际上每天的上

9、网数据在6亿条以上，100天保存的数据量将会达到惊人的六百亿条。台低配有点小马拉大车的感觉，完全达不到“海量数据、实时分析”的设计目标。我们赶紧联系客户，确定上网数据每天6亿条以上，而不是之前预估的每天万条左右。怎么办？系统重构经过与客户的详细沟通和理性分析，大家一致决定进行系统重构。上网数据的日志文件是5分钟粒度的。我们将上网数据按照分析需求分为两类：.细节数据：保留三天的细节数据（5分钟粒度），共约20亿条。这样，由于保留了细节数据，客户可以对近三天的上网数据进行任意的探索式分析。2.汇总数据：在认真研究了流控系统的分析报告需求之后，我们将五分钟的细节数据汇总为两小时的汇总数据。这样数据量可以降到约为原来的1/1，0100天的数据总量大约亿条。重构之后的数据流如下：Agg.QueryDetailQueryNoneAppDetailQueryAgeQuery后期，我们陆续进行了一些系统调优，包括调优、存储调优、计算调优等等。客户打开一个的响应时间基本控制在秒级，最极端的分析报告也能在一分钟之内生成。基本实现了海量数据、实时分析”：1.系统定期推送日报、周报和月报。系统支持探索式分析。多数分析请求达到了秒级响应。案例总