中数据分析

same 在前段时间更新了数据的展示形式,数据流的方式意味着决策上将要更多地向个性化的方向发展。说到个性化,那就意味着大量的用户行为数据的收集和处理,意味着原先用 MySQL 还能支撑的统计分析将不再适用。因此,开始考虑需要一套大数据处理的工具。说到大数据,一般都会自然得想到 Hadoop 系的一系列工具,从计算引擎,到存储系统,再到查询工具。Hadoop 的这一整套东西,很好很强大,但也意味着架构的复杂。

作为一个之前没有接触过任何 Hadoop 系统地超新手,我们艰难得尝试了几天,最终还是选择了放弃。放弃的原因,除了复杂度之外,更是因为一种杀鸡用牛刀的感觉。即使是全量的记录 same 的访问日志,每天也不过数 GB,这样的数据量,要直接上动辄十数台机器(hdfs + Hadoop + 控制节点)的集群着实有些奢侈(费用和维护成本)。而且,公司里也基本没有对 Hadoop 体系熟悉的人,后续的知识传承也很成问题。放弃了 Hadoop,就要重新寻找这样一种简单又可扩展的替代品:架构简单,用少数机器甚至单机即可组建;快速的扩展能力,来应对后续可能的数据增长。

中间寻找评估各种软件的过程略过不表,最后选择了 Cassandra + Spark 的组合。

Cassandra 同样脱胎于 Bigtable,借鉴了 Dynamo 的存储方式。对称节点的设计比 master-slave 的结构更加简洁而容易理解,也减少了组建集群的难度;虽然是 key-value 列式存储但和 RDMBS 类似的 table 概念,类似 SQL 的查询语言 CQL,使得它更好上手。相对于HDFS + HBase 的组合可以说相当轻量了。而 Spark,RDD 的高速,计算的通用性,以及简单的 API 都让它成为了不二选择。在初期,用 standalone cluster mode 也可以显著得减少建立和维护集群的消耗。更重要的是,Cassandra + Spark 的组合有 datastax 商业实践在先,相信即使是真·大数据的处理也可以支撑得起来。

目前,same 在腾讯云上,用四台机器搭建起了一个超小型的数据收集和处理的集群,而扩大这集群需要只是购买一台机器,执行软件安装脚本,修改配置文件。随时应对产品锦鲤的粗暴需求。

有了集群之后就是一些软性的配套需求了。我们简单规划了计算程序(用 Scala 并打包成 jar)的结构和部署目录,使得可以用统一的命令接口启动一个任务。利用了之前只有前端同志在用的 jenkins 做持续集成和自动部署。后续可能还需要一个启动任务的 web 界面,免去每次跑单一任务都要登录服务器的繁琐。实时计算目前还没有需求,但也在考虑中了。

我不能说,这样的处理方式一定是最合理的,但对于有数据处理的需求又没有达到真大数据规模的阶段,还是值得一试。对于小公司来说,在满足需求的前提下,能省则省,毕竟已经不是几年前啦。


发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据