关于流/小批量数据的 ETL 工具的选择

[Philippa]

最近再捣鼓 ETL 用于处理分析数据，使用语言是 Python。关于 Pipeline 搭建工具的选择，发现有非常多，先是手动实现了最原始的，加上更新和各种额外开销，速度比较糟糕，1000 万数据需要 1 天多。处理完进入 Elasticsearch 完成。但最近开始说要实时处理数据了，这意味着原有的批处理方法不大合适了。因此打算改一下逻辑用最古老的 Celery，写了一段跑起来，感觉效果还行，不过直觉有极大的提升空间。因此又弄了个 spark 的 standalone 集群，配置有点麻烦，还没测试，不过感觉假如数据量小预测优化空间不大，主要是每个小任务其实总耗时并不长。然后现在又看到 airflow，也想玩一下看什么效果。

不过玩之前还是来请教一下有经验人士比较好，有没有一个框架既没有 spark 那么重，又处理的实时流数据或小批量数据的？最好是配置简单，而且必须是 Python 有相关接口的，主要是考虑到团队协作因此不会考虑 Scala 等其他语言。来不及可以砍需求，但砍需求之前不知道各位有什么好建议。

PS: 找不到 ETL 节点，不知道放在貌似很多类似群体的 Elasticsearch 节点是否合适？

[Philippa]

不过另外一方面其实还没做过性能测试，之前的简单手动测试瓶颈其实在于数据库的查询和太多的中间交换层了。另一方面性能开销大概会花在处理逻辑本身的时间。所以问题本身其实更倾向于找一个：漂亮、友好、迅速但又轻量级的实时 /小批量的 schedule 框架。

[Philippa]

类似地还发现了类似 Luigi，可视化界面也是重要一部分（当然 airflow 也有）。因为开发过程中也会协同前端提供 API，因此有时候能够让前端看到后台的处理流程对前端也颇有帮助，自己也看得清晰。

[Philippa]

对了，忘了说，也可以改上 lambda 服务，但简单看了并不具备性能优势（ I am not so sure ），除了架构变了没什么大的区别。如果是一早设计就按这个设计貌似开发也更快，但现在貌似意义已经不大。

[ligyxy]

Luigi 和 Airflow 的前台界面也就聊胜于无
Elasticsearch 的 painless 了解一下
https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-update.html

[Philippa]

Sorry 可能问题有点模糊了。涉及的数据库包括 MongoDB，PG，Elasticsearch 提供搜索服务。还有背后的分析模型。

[Philippa]

@ligyxy 谢谢，我回去用 painless 改改查询语句看看速度如何。

[limbo0]

想推荐波 flink 了，但看到 lz 的需求感觉大材小用了，1000w 数据要一天多也太慢了，1 个 u 基本上可以上 1000/s 的速度，还是觉得 spark 比较适合，文档多点，有 python 接口，后期速度跟不上扩节点就行了

[Philippa]

@limbo0 那个 flink 一搜看起来蛮有趣的，在公司闲得没事时增强试试看 2333。至于为什么这么慢，是因为用了各种数据库的 ORM 和各种设计友好的接口……

[laxenade]

取决于你的 source 在哪，aws 的 kinesis 和 glue 了解一下，都支持 python(glue 好像只有 python)。

[ligyxy]

Painless 的调试是个痛，比较适合小型修改
Spark 以前有 Spark-ec2，现在有 Databricks 或类似的云服务都能解决安装配置的问题，但是 Spark 的调优也不省事
看楼主的问题应该先尝试优化你的 Python 脚本

[beginor]

没有人推荐 datax 么，准备入这个坑了，看起来不错的样子

[est]

如果你 py 脚本没有优化空间了上再多框架也是没用的。试试 pypy cython 了

一般来说纯脚本性能是完爆框架的。框架一般都有序列化开销。框架的作用是并行化

[fireapp]

直接使用 kafka 存储数据，然后 kafka stream 直接撸，需要全文检索的话就丢到 es， 如果只需要少数的聚合统计报表啥的，es 就不用了， 换成 drill 直接 sql 撸 kafka 数据，结果再存 kafka

[tonghuashuai]

具体没看懂 lz 什么需求，但是跟 ETL 相关的可以试试 kettle，貌似现在叫 PDI （ Pentaho Data Integration ）
https://community.hds.com/docs/DOC-1009855

[Philippa]

@laxenade 其实在阿里云= =公司的，我应该叫“函数服务”而不是 lambda 以免引起误会。

[Philippa]

@ligyxy 没得优化了，已经用 cProfile 可视化测过性能，小格子已经很均匀很细小了。

[Philippa]

@ligyxy Spark 也有一个 standalone 的 dockerfile 写好了，下期试试

[Philippa]

@beginor 收藏了，像个基本款 ETL 工具

[Philippa]

@est 写过 PyPy3 的 dockerfile 跑过，肉眼测没明显区别，到时跑个性能看看，就是 PyPy3 貌似不推荐生产环境使用

@fireapp 看起来很不错啊，至少官网的视频那个男的说得好起劲，好，又一个……

@tonghuashuai 天，一进去发现 free trial 字样 = = 总之谢谢推荐，以后可以一个个慢慢来

[est]

@Philippa python 的 docker image 很多坑噢。稍不注意就 50%性能损失。