数据研发工作阶段性总结：（2015-12-21 至 2016-08-04）

前言

中午在看书，看着看着就不自觉地想起来自己从入职至今的工作情况了。

在工作的过程中，有过对工作性质的质疑、对自己能力的不自信、对前景的担忧，想想还是挺好玩的。趁着脑子比较飘忽，总结一下工作的情况吧。

总结的角度主要站在集群管理员的角度。

工作

2015年12月21日，我以校招生的身份入职，先有共三个月试用（+实习）期。工作的初期定位是研发，负责小组的部分内部系统开发，以数据流的处理为主。

集群迁移：

前两周的时间熟悉环境。熟悉过后，赶上大数据集群迁移，由于之前自身对类似集群运维的工作比较熟悉，因此临时参与到数据集群迁移的工作。半个多月的时间中，进行了新集群的搭建、数据迁移和业务迁移。迁移过程主要由python来主导，我来辅助。集群迁移的感受就是要细心、细心、再细心，然后再加一点耐心。因为集群规模不大而且是机房内部迁移，不存在太多的技术问题。需要注意的就是目录权限、业务平滑迁移、新老集群数据每日同步等细节。由于迁移的过程对其它同事来说算是无感迁移，因此大家还是很高兴的，至少不用自己动业务了。

Impala：

集群迁移完成后，有一小段时间，负责了部分的业务开发内容，主要是提供数据源相关。然后我就突然被转移到Impala的深入使用上了。

因为集群的性能有限，因此我们进行了集群的迁移，但是迁移之后，发现Impala的性能受限，各种夜里挂掉，大家早上起来就需要一个多小时的时间来补数据。因此临危受命，我负责Impala的深入研究和优化。

我很幸运，因为之前大家用了很久Impala，但是由于业务的堆积，导致大家没有机会来深入的学习一下他，我正好赶上了。

这是个有意思的东西。在Impala使用方面，我整理了十多篇使用总结，包括Impala的错误分析，性能瓶颈分析等。在此期间，我很开心地从源码角度对Impala进行了学习（比较浅，主要是以解决问题为目的）。

总的来说，最后通过了一些点来优化了一下Impala的使用：负载均衡、Invalidate Metadata的合理使用、Compute Stats的合理使用、文件格式的改变（统一换成parquet）。现在回头想想，就是这些东西，但是自己在摸索的过程中还是没那么容易的，这就看出来了经验的重要性。

后来Impala使用稳定了，基本很少出问题了。大家都很开心，至少不会再早上起来就先补任务了。我也为此专门做了一两次Impala的分享。

集群压缩：

本来以为我要开始新的开发生活了，但是有一天，发现了集群存储使用率已经占了64%，而且每天以2%的速度增加，按照这个速度，没多久我们的集群就要满了。

因此开始调研Hdfs上的各种压缩格式。最终选择了两种文件格式：gzip和parquet。这里没有选择其它格式的一个原因和我关系不小，因为在Impala使用的过程中，我发现，很多问题从技术角度来说不难，但是想让每个人都修改一下自己的脚本，是个非常困难的事，即使你说的对，而且只需要每个人都只在脚本里面去掉一个-r参数。

为了尽可能少的减少对现有业务以及同事代码的影响，大部分的日志文件我选择了gzip压缩，Impala相关的表全部选为parquet格式。从调研到全部压缩完并配置每天定时任务，大概有半个多月的时间。此时集群的使用率从64%降到了27%。关键的是对现有业务基本没有任何影响，经过测试，性能也提高不少了，为此，我做了不少了测试。

数据安全：

以前经常听说数据安全相关的话题，也知道hadoop生态系统的安全系统等于没有，但是自己并没有什么意识，因为一件事对这个问题理解深刻了。

Impala和Hive主要都是以命令行提交，唯一比较好用的界面还是hue，初期公司的数据仓库等体系建设都不完善，因此数据分析师在做业务的时候经常也要从Impala中的原始日志表中直接查询数据，因此就要用到hue。

但是hue有几个地方需要注意：

• hue从理论上来讲只有一个用户登录的限制，进去之后基本上什么都可以拿到了，这就会有一个问题，比如有人知道一个账号密码，他可以从集群里面提取出来所有他想要信息，批量。我们就是很多数据分析师公用一个账号。这很危险。拿到关键的用户数据后已经可以出去创业了，而且你还找不到人，没法追责…….
• hue有bug，比如提交Impala任务，如果你在hue上提交一个任务，没有关闭Impala的页面，这时候，这个query就会一直在cm的管理里面中，类似一个僵尸进程，即使你出了结果后该进程仍然在。

这时候一个简单的Impala/Hive外挂就很需要了，加上用户控制，比Hue可控性更强了，当然，数据的限制还要从hdfs层面来解决。

spark：

6月份的时候，小组有了人事调度，等待Leader的到来，这个时候大家情绪都不是很高。因此我就拉了seven一起来搞了spark，把我们以前的storm的实时项目换成了Spark+Spark Streaming+Redis+Kafka+Mysql的结构。算是一次面向简历编程吧。

数据仓库：

数据仓库的重要性毋庸置疑，我们最终能推动做它的一个主要原因有两个：数据出口不一致，重复工作太多。（其实为了解决这两个问题，我感觉做出来的不是数据仓库，只是传统数据库的一次整理而已。）

数据仓库由ruby牵头，我主要参与，加上了一两个数据分析协助。大家都是非数据仓库人员出人，因此我参与的一个主要原因就是因为能帮忙在一起扯淡，大家多聊聊，思路就清晰了（我也就这点用了……）。

数据仓库做起来还是挺有挑战，也挺蛋疼的。有挑战的是数据仓库整体结构上的设计，这包括两方面：

• 数据流的设计，因为和传统的数据仓库不一样，我们不能用oracle来搞，因此sqooop+hdfs+hive+impala这套流程怎么走，需要详细的设计。
• 数据建模，这方面大家完全是摸着石头过河了，反正折腾到最后也算弄清什么是星型模型、事实表、维度表这些乱七八糟的概念了。

蛋疼的是，数据仓库有很多无聊的事要做，比如写sql、写脚本、对字段。有时候一个字段的处理就要花一个小时来理清，要找数据分析，数据业务研发，数据产品，业务研发一大堆的人…….

目前来说数据仓库还在建设~~~

ETL：

以前自己对ETl的理解还是太浅了，其实说白了只知道个名字而已。

最近这一个多月的时间里面算是清晰不少。

单说一个我们用到最纠结的地方：数据同步工具！

最初我们组的数据同步以及一些数据处理是通过mysql的存储过程来搞的，这是比我还要早的历史。随着数据量的增大，这些方式已经不能满足场景了。

然后换成了sqoop来抽数据，这个比较靠谱，脚本也简单。但是大家在用sqoop的时候很多表需要每天全量drop再全量抽，这个很严重了，小数据量完全没压力，但是有些表就带不动了，一次抽表要半个小时，别的业务要等。

因此我们换了方式，我们所有的数据通过canal来搞，大致流程是这样的，我们对主站的表进行binlog监听，然后打入kafka中，然后我们有一个消费端，消费后近实时地用flume抽到hdfs上，用过canal的知道，canal的数据需要最后做一步合并，才能还原mysql的数据。

这个方法不错，关键有两点比较纠结：

• 不能实时，初衷是实时的，但是合并的间隔太短的话，很难做到实时，相当于这个设想废掉了。
• 流程太长，我们的流程太长了，而且要有主站的配合，这样很多的模块，任意一个模块都可能出问题，一旦出问题之后，恢复特别困难。

最后我们决定回到sqoop，主要需要考虑几个点的设计：

• 主站元数据变动有感知
• 增量同步
• 数据验证

目前这块我来负责。

总结

本想总结一下，但是发现自己竟无言以形容自己的心情。大概说几点吧。

好的方面：

• 遇到soul这个好的leader，跟着学会了很多的东西
• 研究了不少的东西
• 数据组的基本所有的业务我都涉及了，基本上所有的架构设计我都参与讨论了，这点帮助很大

不好的地方：

• 编程比较少了
• 个人很想提升，但是发现环境不够理想
• 小组的架构在换leader后有大调整，比如要Impala全部干掉，换成presto，成本挺大的，需要做很多善后工作。

---

2016-08-04 13:36:00 hzct