瑞小博的大数据平台技术选型及架构实践

  1. 云栖社区>
  2. 博客>
  3. 正文

瑞小博的大数据平台技术选型及架构实践

云上孤影客 2017-07-31 11:13:29 浏览2026
展开阅读全文

前言

瑞小博成立于2014年,是一家专注于“商用WI-FI覆盖”产品研发与运营模式创新的科技公司。

公司创立之初,基于成本、效率等考量,我们选择了阿里云,至今已3个年头。这3年多里,我们使用了覆盖 弹性计算、网络、存储、数据库、大数据、安全、应用服务等多项领域的多款阿里云产品。

下面,给大家分享我们在不同阶段使用MaxCompute(原ODPS)的一些实践,以供参考。

低廉的存储&高效的运算

我们使用ODPS的首要原因,就是因为它低廉的存储和高效的运算。

公司刚成立时,业务量很小,数据存储和计算都在阿里云RDS中,简单直接。但两个月后,业务快速发展,RDS存储的费用直线上升,而且任务计算耗时越来越长,已经影响到业务的发展。

彼时,开源大数据存储计算框架Hadoop如火如荼,Spark冉冉兴起,分布式数据库Greenplum也是逐步成熟,看起来有很多的选择,我们也就此做了调研和前期尝试。但实际操作起来就会发现,这些平台在搭建初期的硬件成本、运维成本、时间成本远远超出一家创业公司的承受范围,而且这些平台并不是公司的主营业务。自建平台的方案被PASS掉。

只是想喝一杯牛奶,为什么一定要建一个牧场呢?

我们转而考察商业大数据产品,自然也就分析了ODPS。
实事求是的讲,我们当时的需求其实很基础,稍微像点样子的大数据产品基本都能满足我们的需求。而我们选择ODPS的原因,一方面是因为我们的业务数据本身就在阿里云内部,ODPS更方便数据同步,但更重要的还是因为ODPS的价格很便宜。当时,存储冷数据及计算周期性任务的RDS节点一个月需要1200元,而切换到ODPS后每天存储只需要7块钱,计算仅需要4块钱,比之前便宜了近70%。
另外,切换以后,ODPS的分布式计算使得周期性任务执行的更快,业务表现更好。

所以,基于ODPS低廉的存储和高效的运算,2014年9月我们将历史数据存储和周期性任务计算切换到ODPS,性能提升的同时成本也有所降低,支撑了当时业务的快速发展。

附:第一阶段数据处理流程图

2

完整的大数据开发框架

独木不成林。如果只有大数据存储和后分析处理,数据是割裂的,功能也是残缺的。
所幸,阿里云逐步开放了一套完整的大数据开发框架,以ODPS为核心将一个个独立的功能点连成了线,也吸引我们长期成为阿里云大数据产品的忠实用户。

2015年,公司的业务飞速发展,数据量陡增,每天会产生上亿条业务记录。按照之前的数据处理架构,业务数据入RDS再同步到ODPS的做法,即使是高配RDS的IO性能也根本撑不住。而且一个高配RDS每月需要2000多块,成本比较高。

本来,最初公司的技术演进roadmap中,虽然也觉得RDS作为数据采集模块会有瓶颈,但考虑到数据量不大,预计这套数据处理架构能使用一到两年。
而随着业务量陡增,我们只有提前做出改变。技术方案是:以日志文件系统,部分代替关系型数据库作为数据采集模块。
业务上看,大数据量、低可靠性要求的数据通过日志文件系统采集,小数据量、高可靠性要求的数据依然通过关系型数据库采集。

有了之前的经验,技术方案确定后,我们没有考虑立即去搭建fluentd/flume,而是看看阿里云上有没有类似的产品,然后发现了SLS。
SLS以正则匹配近实时(5分钟时延)采集ECS上的日志文件,不仅存储到日志文件中,还提供类Elasticsearch的文本搜索服务,完全满足我们的业务诉求。
更为关键的是,SLS与ODPS是完全打通的,不需要业务系统介入,简单配置就可以将SLS采集的日志数据自动同步到ODPS。另外,当时SLS还是完全免费的(2016年11月开始SLS不再免费,但如果不使用搜索服务,费用还是比较低廉的)。
最终,通过引入SLS,很好的解决了我们数据采集的性能问题,而且还减少了两个高配的RDS节点,每年节约了近6万的成本,此架构也一直沿用至今。

附:第二阶段数据处理流程图

3

当然,也不是每次探索都是成功的。这个阶段,由于实时计算的需求我们研究了Stream SQL(目前已下线),由于BI报表的需求我们研究了AnalyticDB,都不太符合我们的业务场景,只能通过自建或其他方案实现。

我们一直认为,独立割裂的数据价值是很低的,数据开发框架也是如此。而阿里云大数据产品这几年一步步的完善,尤其是将一个个独立的功能点连成了线,产品之间打通促进数据之间打通,吸引我们与之共同成长和进步。

发挥主观能动性

阿里云数据产品目前还处在完善阶段,不可能所有需求都能够立即满足。所以,我们还需要发挥主观能动性,解决业务问题。下面分享我们自建数据仓库和BI报表系统的实践。

2015年底,公司业务开始进入正轨,运营、市场等各方面的数据诉求越来越多,现有机制和人力开始捉襟见肘。因此,我们考虑开发数据仓库和BI报表系统。

当时,阿里云没有一款独立的BI产品,部分产品中零散的有点类似BI报表的功能(如DPC的“数据分析”)也相对较局限,不能满足我们的需求,只能自建。
因此,我们在业务上构建了维度体系和指标模型,统一业务语言。数据处理架构上,将详单事实表和维度表同步到ODPS后,在ODPS中进行汇聚运算,输出统计事实表到RDS。同时,开发了 DashBoard、即席查询、查询报表 三个应用,满足我们的业务需求。
其间的过程不再赘述,开发的应用如图所示。

DashBoard

DashBoard

即席查询

即席查询

现在,阿里云的QuickBI已经发布,能很好的满足BI报表的需求。好的产品,可能会迟到,但不会缺席。

数加,新的纪元

数加的发布,是最近一年多的事,我们也还在摸索与尝试。

目前来说,比较大的感受是机器学习平台的组件化和数据模型化做的很好。在数加发布之前,我们也会自己写一些算法做业务分析,包括统计分析中的各种检验、机器学习中的分类聚类、时间序列分析等。但相对都比较散,输入输出数据模型不统一,组合比较麻烦。数加的组件化设计,能比较好的解决这个问题。

另外,数加的公开数据集也比较不错,测试验证算法很方便。

结语

三年多来,ODPS一直稳定的支持着我们的存储和计算,是我们的核心基础平台。

我们希望,在数加时代ODPS能一如既往的稳定,并提供更多的数据产品,帮助我们在数据的海洋里继续遨游。

网友评论

登录后评论
0/500
评论
云上孤影客
+ 关注