海量数据平台解决方案的一些思考（一）

现在，稍微大一点的互联网公司都会搞自己的数据平台，平台功能基本上就是跑数据，出报表，高端点的做做数据挖掘等等。由于在上一家公司做了2年多的海量数据平台方面的工作，在这一领域多多少少积累了一些经验，在这里就简单总结一下，算是我博客的开张贴


基本上，一个数据平台要考虑的方面有以下四个：


数据收集
数据存储
计算

可视化

数据采集：


数据从哪里来？怎么获得？大体可以分为两种方式：离线拉取和实时采集。


离线拉取方式比较简单，写几个脚本或者做个服务把数据从数据源转到数据平台上，无非拉取前一天的数据库、文本、定好协议的二进制文件等等。这些脚本和服务一般都很通用，不同的数据源就是不同的配置而已。我这边的做法是搞个机器做为接口机，写个通用的脚本支持scp, rsync, mysql, ftp, hadoop distcp等等几种常用的协议，然后每个数据源对应一个配置文件，再在crontab里加个任务就ok。不过有几点要注意：1、数据源在数据准备好后要打check文件来证明数据完全到达。2、拉取脚本或服务要有重试机制，我这边是重试10次，间隔10分钟。3、要和数据源负责人商量好一个大概的拉取时间。如果你的数据量比较大，那么最好做个接口集群，比如用Hdfs做个集群。


实时采集就显得比较高端了，但是这需要数据源侧的配合，可能需要数据源侧（比如cgi）修改一下打log的方法。实时采集一般用于高访问量的网站，每个用户行为产生的log都实时收集起来。目前这种log实时采集的技术有很多开源的方案，比如google的ylog，是一个单机的方案，数据源侧的log以udp包的形式发给ylog的server，然后这个server把log落地。还有许多分布式的方案，比如chukwa, flume等。我在上一家公司采用flume，因为flume是一个基于hadoop的技术，可以把收集的数据直接打到hdfs里，而我们的计算集群就是hadoop。我搭了一个flume的集群，把每个节点上的每个agent监听的端口和节点IP放到一个zookeeper上，数据源侧打log时从zookeeper上获得可用的agent列表，然后把包随机发到一个agent上。这样就实现了分布式的收集数据。


数据存储：


一个数据平台必然要考虑数据怎么存的问题，其实这个问题蕴含了几个小问题：1、元数据管理。2、生命周期管理。3、容灾及备份。作为海量数据平台，单机的方案就不要想了，直接考虑集群吧，有钱的公司会考虑一些商业方案，比如oracle等，这不是本文讨论的内容，所以我还是说开源方案。目前来看，开源方案里hadoop及其相关的绝对是王道，因为它太成熟了。我这边就用了hdfs搭的集群做存储，节点数据容灾hdfs本身支持，然后我做了namenode的备机和热切脚本。为了避免误操作导致的数据丢失，我做了另外一个冷备集群，定时同步数据过去。元数据管理方面，我把数据分四层，不同类型的数据放到不同的集群目录下，从flume和接口机收到的数据放在接口层，每个数据源对应一个目录，同时该目录下按日期每天再建一个目录。接口层的数据比较乱，需要预处理，预处理后的数据放在中间层。计算后的结果数据放在结果层，计算时需要的维表等数据放在维表层，注意，我这里的“计算”没有用hive或hbase，至于用了什么下面会讲。除了接口层的数据是三天一删之外，其他层数据的生命周期都比较长。


计算：


所谓计算包括了以下几个方面：1、预处理。2、计算方法。3、工作流调度。预处理很好理解，就是把不规则的数据处理成统一模式的数据，这项工作用脚本来做是最方便快速有效的，当然，如果你收集到的数据本身就是规整的，比如直接拉的数据库，那么就省去这一步了。关于计算方法，恐怕只要你不是做数据挖掘类的高级工作都会选择用SQL或着类SQL的接口（当然，想和自己过不去自己写mapreduce程序也是可以的）。我这边用的是Pig-Latin，基于hadoop的开源的轻量级类SQL语言。它不需要你在hadoop集群上再套一层东西（hive和hbase都需要），只要找个单机安个客户端就行了。Pig-Latin能够直接计算hdfs上的文本或压缩文件，支持自己用java写一些udf。我觉得Pig-Latin最帅的地方是可以用stream命令调用shell来处理数据，这样连预处理都可以用它来搞，而且是分布式的哦。我就是用python写了一些预处理的脚本放到Pig-Latin里调。说到工作流调度，对于hadoop上的作业来说貌似没有太多选择，自己写工作流引擎或者用雅虎开源的oozie。我这边用的oozie。oozie可以调度mapreduce，hadoop命令，Pig-Latin脚本，对我来说非常棒了，通过配置一个xml实现工作流中各任务的复杂依赖关系。


可视化：


数据算出来了怎么展示？web端的报表和daily mail是必须的。对于搞后台的人来说做前端设计简直不可想象，自己都不想看。还好有很多开源的框架可以让你不用考虑那些CSS的东西专心写展现代码就ok。我这边用的Extjs。写了几个模版，同时用python写了些通用的读取数据的cgi。哦对了，算出来的数据我从hdfs上同步到了mysql里，当然你放在hdfs上不动也是可以的，反正hdfs也支持http协议。daily report方面我做了一个日报系统，用pChart做图，固定的展示形式，任何一份日报只要把纯文本的数据传过来就会自动按照这个日报的配置生成图表然后发邮件。


哦了，整个平台搭建好后剩下的就是每天写数据计算代码和维护集群了。其实，基本上任何一个数据平台都逃不出以上四点，如果是海量数据，那么你的方案应该也会和我差不多，在上一家公司，我曾经和多个部门的同事交流过经验，大家基本都是这么做的。但是接下来的几篇文章我会介绍一些通过我自己思考和实践形成的应用层面的解决方案。