更好整合 kubernete 和 airflow

最近组里有一个project，跑spark sql， input就是SQL读取snowflake，output是
dataframe存到 AWS s3

有趣的地方在于每个sql跑的时候要考虑dependencies，因为有些sql depends on 其他sql job产生的dataframe，不能全部乱序一起跑。所以搞了个dag用拓扑排序解决了。

再后来发现AWS 的account同时最多用300个EC2，现在跑的时候是用那些EC2来构造EMR
。每次月初跑的时候，别的team也在share这个AWS account，所以真正跑的时候，不够EC2。每个月现在需要大约跑50个sql

现在的解决方案是用一台memory足够大的EMR来按拓扑排序来跑那50个spark sql job。问题是，能不能做到用kubernete做cluster management管理整个AWS SHARED ACCOUNT
下那300个EC2，然后用airflow或者KUBEFLOW来把50多个job schedule上不止一个EMR上呢？

希望能做到多个EMR同时跑多个没有dependencies的spark sql job，而不是一个EMR按
顺序来跑50个job。目前已经有纯java code自己写resource manager和scheduler的方
案，想知道能不能在kubernete + {kubeflow | airflow}上做得更好

我们公司就是做k8s上的spark sql的pipeline， 直接跑spark for k8s， 没用emr，可以不依赖cloud provider
不过我们是一个公司做了很久，你如果个人做的话，跑特定pipeline可能没问题，
generiliaze还是挺难的

可以私信聊聊不？

不依赖cloud provider ，是根据不同的cloud来做sub classing么？还是说根本不用
aws/gcp/azure，自己搭cluster？

【 在 rhett (白瑞得) 的大作中提到: 】
: 我们公司就是做k8s上的spark sql的pipeline， 直接跑spark for k8s， 没用emr，可
: 以不依赖cloud provider
: 不过我们是一个公司做了很久，你如果个人做的话，跑特定pipeline可能没问题，
: generiliaze还是挺难的

估计你的架构太复杂了。
开源的，花钱的，云上的，本地的。
各种各样的工具。
其实streaming一下就完了。
复杂度太高，自己都弄晕了就不好了。

我们还是用eks/aks/gke， 用terraform 来unify 这些cluster level 操作，
application level 在k8s pod level
要看你们的具体应用，如果这是streaming的话， 也不考虑windowing的话， 用一些开源工具可能够了，
如果需要batching， 需要按windowing update， aggregate，就很麻烦
【 在 shuaide (卖火柴的小女孩) 的大作中提到: 】
: 可以私信聊聊不？
: 不依赖cloud provider ，是根据不同的cloud来做sub classing么？还是说根本不用: aws/gcp/azure，自己搭cluster？

目前全部都是batch job。数据来源是snowflake，sql run在snowflake上。数据来源就不是message broker

我也想玩streaming，不过streaming的问题暂时还落不到我头上

【 在 rhett (白瑞得) 的大作中提到: 】
: 我们还是用eks/aks/gke， 用terraform 来unify 这些cluster level 操作，
: application level 在k8s pod level
: 要看你们的具体应用，如果这是streaming的话， 也不考虑windowing的话， 用一些开
: 源工具可能够了，
: 如果需要batching， 需要按windowing update， aggregate，就很麻烦

batch job 如果event time 比较齐整， 不需要考虑 upsert case， 用airflow都没什么问题
airflow 有对k8s的operator，你可以借鉴https://kubernetes.io/blog/2018/06/28/airflow-on-kubernetes-part-1-a-
different-kind-of-operator/

我不清楚你说的event time在batch job 里面是指什么。

现在50个batch job相互形成一个dag， 必须考虑先跑哪个，后跑哪个

但是同一个job的不同dependents，如果相互之间不依赖的话，可以同时跑。我想知道
，kubernetes或者airflow能不能利用这一点，做到同时跑。不然的话，要是airflow只做DAG，把50个job送上kubernetes之后是一个一个地跑，那我写的resource manager就比他们牛了

【 在 rhett (白瑞得) 的大作中提到: 】
: batch job 如果event time 比较齐整， 不需要考虑 upsert case， 用airflow都没什
: 么问题
: airflow 有对k8s的operator，你可以借鉴
: https://kubernetes.io/blog/2018/06/28/airflow-on-kubernetes-part-1-a-
: different-kind-of-operator/

没有最好的方案，只有最适合具体情况的，airflow处理的是通用的dag的managment，
如果你们具体的情况，自己的程序更合适，就继续用，没什么问题，不需要为了追新而用airflow或k8s。

再建个aws 账户不就行了

看来看去 没看懂跟kubernete有啥关系

基本原则是没微服务 就没啥必要用docker 没有很多docker 就没必要用kubernete

不能看着流行啥就用啥 科学技术 不是穿衣时尚

你弄台memory大一点的instance。
把数据都拔到机器的内存就行了。
然后用点leetcode中级算法，处理一下就可以了。
定时的话，cron就足够了。

airflow在k8s可以有两种跑法
第一用celery executor， 需要建立一个worker pool， pool里有几个worker，就可以同时跑几个job
第二是用上面有人提到的kuber executor， 这个比较新，估计支持不多， 但是和k8s
结合比较好， 基本上是每个job start一个pod， 并行性更好，难点在pod build。 估计楼主喜欢这个

【 在 shuaide (卖火柴的小女孩) 的大作中提到: 】
: 我不清楚你说的event time在batch job 里面是指什么。
: 现在50个batch job相互形成一个dag， 必须考虑先跑哪个，后跑哪个
: 但是同一个job的不同dependents，如果相互之间不依赖的话，可以同时跑。我想知道
: ，kubernetes或者airflow能不能利用这一点，做到同时跑。不然的话，要是airflow只
: 做DAG，把50个job送上kubernetes之后是一个一个地跑，那我写的resource manager就
: 比他们牛了