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

前言

瑞小博成立于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，性能提升的同时成本也有所降低，支撑了当时业务的快速发展。

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

完整的大数据开发框架

独木不成林。如果只有大数据存储和后分析处理，数据是割裂的，功能也是残缺的。
所幸，阿里云逐步开放了一套完整的大数据开发框架，以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万的成本，此架构也一直沿用至今。

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

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

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

发挥主观能动性

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

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

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

DashBoard

即席查询

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

数加，新的纪元

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

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

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

结语

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

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