大数据 Spark、Flink 对于复杂业务逻辑处理是否有些吃力
公司做项目，项目的数据量级特别大，之前通过 python 搞的单台服务器的处理和业务逻辑代码处理不动了，所以上了 spark ，我之前对 spark 的理解是计算，基本就是提取一些字段，做指标统计，或者对海量数据做个清洗。
但是对于业务逻辑，之前用单机版实现的，基本都是 python 脚本去写 if else ，数据量小，也是实时处理的，对于需要缓存的内容就直接扔到 redis 里面了，但是 spark 或者 flink 去做这个事情，好像不容易写这种逻辑代码，缓存的话只是在用 flink 自身的状态，也不适合频繁和 es 、redis 这种数据库实时交互。
这种想请教下大家，对于传统的那种 oltp 的事情，当数据量巨大的时候，flink/spark 可以替代之前的框架完成吗？还是说这两个框架其实还是多用于统计分析。
#spark #flink #数据量 #python #redis #缓存 #逻辑 #之前 #框架 #代码
公司做项目，项目的数据量级特别大，之前通过 python 搞的单台服务器的处理和业务逻辑代码处理不动了，所以上了 spark ，我之前对 spark 的理解是计算，基本就是提取一些字段，做指标统计，或者对海量数据做个清洗。
但是对于业务逻辑，之前用单机版实现的，基本都是 python 脚本去写 if else ，数据量小，也是实时处理的，对于需要缓存的内容就直接扔到 redis 里面了，但是 spark 或者 flink 去做这个事情，好像不容易写这种逻辑代码，缓存的话只是在用 flink 自身的状态，也不适合频繁和 es 、redis 这种数据库实时交互。
这种想请教下大家，对于传统的那种 oltp 的事情，当数据量巨大的时候，flink/spark 可以替代之前的框架完成吗？还是说这两个框架其实还是多用于统计分析。
#spark #flink #数据量 #python #redis #缓存 #逻辑 #之前 #框架 #代码
Lightflus：一款新型的云端 Dataflow 数据计算框架（Preview for Developer）
## 我们需要什么样的数据计算框架
Hi everyone~我们很高兴能跟大家介绍这款新型的数据计算框架，***Lightflus***。但我在这里想先跟大家探讨的就是我们到底需要什么样的数据计算框架。
目前最流行的两款数据计算框架是 Spark 和 Flink ，他们二者分别代表了 batch 和 streaming 两种计算范式。在 2016 年 Dataflow Model 被提出来了后，Spark 和 Flink 都希望填平 Batch 和 Streaming 之间的鸿沟。不管从理论还是工程实践上讲，Dataflow ，或者时髦点，叫流批一体，起码不是空中楼阁了。而在 Flink 被阿里收购以后，各种宣传漫天飞，在国内大有一统企业数据计算框架的趋势。
### Spark 和 Flink 有什么不足的地方呢？
从用户的角度来看，这两款框架虽然都非常优秀，但着实有**大炮打蚊子的感觉**，而且运维和开发都非常繁琐。尽管有 Spark SQL 和 Flink SQL 来简化（间接导致 Data Engineer 沦落为 SQL boy ），但是在很多场景下（比如 IoT ），SQL 还不够。主流的云厂商也不怎么支持 Spark 和 Flink ，除了阿里做了个阉割版的 Flink Cloud ，Databricks 奶亲儿子 Spark 外，其他主流云厂商很少会亲自下场做。
因此不论大小企业，想要应用 Flink 和 Spark 来做数据驱动系统（如 AI ），其实成本颇高，需要配置一个 infra 团队才能很好运转。对科技大厂可能无所谓，但对初创公司或者数据部门在组织架构里只是支撑部门并非业务部门的团队，可能根本拿不到那么多资源。
### 目前的数据计算框架（ Spark ，Flink ）存在的问题
1. **上手门槛和落地成本都很高**，对于数据团队来说，核心还是捋清公司的业务模型，更聚焦于业务而非技术细节，不然按这两年的光景，还在天天纠结底层原理就等着被裁吧：）；
2. **Cloud 化不够，每家企业都在搞重复建设**，浪费大量资源。以前热钱多随便燥，现在都讲降本增效；
3. **灵活度不够，管理成本和风险高**，传统企业或者初创公司希望搭建数据驱动系统，在团队组建和管理上都很难保持灵活性，降低成本和风险；
4. **存算不统一，数据存储成本高**，存算不统一，流计算和批计算各一套，两套存储，两份成本，扩展性也很差；
### 我们需要什么？
1. **轻松上手，无忧落地**：人都是懒的，尤其对工作，能少做点事，干嘛多做呢？
2. **Cloud-Native ，避免重复建设**：能省钱就省钱，KPI 完成了，老板赚到了，双赢：）；
3. **灵活度高，降低管理成本和风险**：你团队里谁都能干，也不需要招新人来磨合了；
4. **存算统一，一份数据**：这个好处我就不说了吧，一份数据好维护，成本低，谁用都说好；
## 我为什么做这个框架？
其实从上面给出的结论，也就不难得出我做 Lightflus 的初心：
1. **我希望将门槛高，成本高的数据计算框架变成普通的开发人员也能轻易上手的”快消“产品**。
2. 我是有技术追求的，**我希望能做一套存储来替代业内两套存储的方案**，并且成为产品的一个部分，向业界给出一个 state-of-the-art 的方案；
## 这个项目的设计是什么样的呢？
1. 我们用 Rust 实现了一个 Runtime ；
2. 我们提供了 Typescript API 来保证类型安全；
3. 没错，你可以在浏览器里写 Typescript 的代码跑流数据计算（我正是这么想的）；
4. 我们未来还会支持 WebAssembly ，这样 Runtime 的性能就会更好（更少的执行时间，更少的 GC ）；
5. 架构是 Coordinator-Worker 架构，典型的分布式计算架构，保证有很好的扩展性；
如果想知道更多细节，可以看文档，链接在 github 里；
## Lightflus 和 Flink/Spark 之间的与众不同的地方在哪呢？
1. API 不同，一个 Java 一个 Typescript ；找你们的前端同学就能写 streaming 任务；
2. 更小的 Runtime ，解决问题不再是上”重装坦克“而是”轻型人体工学装甲“；
3. 更简单的操作，我们提供的 CLI 工具会使得操作云端集群更加简单；
4. 更便宜，更灵活，对数据开发人员的心智负担更少，更聚焦于业务；
## 计算状态的容错是否支持？
1. demo 版本和 preview 版本尚不支持容错。但在 release 版本中将会支持
2. 容错我们将会参考 Flink 实现 checkpoint 机制；
## 支持哪些算子？
1. demo 版本将支持 `map`，`flatMap`, `reduce`, `filter`，`window`，`trigger`；
2. release 版本将支持 `join`；
3. 支持算子的列表和用法可能会随着版本迭代会更新，API 目前还不是稳定的；
## 支持哪些 sink / source ？
demo 版本将支持以下的 sink / source：
1. Kafka Sink 和 Source ；
2. Mysql Sink ；
3. Redis Sink ；
## 怎么参与进这个项目里来呢？
1. [Github]( https://github.com/Lady-Summer/lightflus)，欢迎大家多多 star~；
2. 加入 [Slack]( https://join.slack.com/t/lightflus/shared_invite/zt-1hqwryop3-jWOhWSuQ2B7wulhQM5~sHQ)；大家可以在 Slack 频道里针对产品畅所欲言；
## 什么时候公布 demo ，release 版本何时发布？怎么收费？
1. demo 预计在明年年初发布，目前 repository 给各位看的是 preview 版本，尚未经过严格测试，而且有些功能也还在开发中；
2. release 版本的发布和收费细节将在 Slack 群里公布，届时请大家多多关注 Slack 群；
## demo 版本可以预览的功能
1. Typescript demo API ；
2. CLI 工具支持；
3. Runtime demo features ；
## 短期和长期规划
1. 短期规划：明年把 release 版本做出来，如果可以，尝试融点钱，把项目更好运营下去；
2. 长期规划：我希望我可以将这个项目做成 SaaS 化的标准云服务，并且在商业上能够自我造血，让这个项目不至于在长期缺钱后死掉：）；
### 国内做 SaaS 那么难，为啥还想做 SaaS ？
1. SaaS 是个好生意，但国内软件市场需求和供给目前都不成熟，这跟国情有关；
2. 我的目标是 Global SaaS ，在国内运营的方式可能不一样，而且介入国内市场的时间可能要在项目比较成熟后，毕竟我也在 SaaS 公司做过，清楚国内软件商业化存在的问题；
3. 国内对软件的认识正在逐步提高，需要时间。我们定位是卖”铲子“，所以只要还有”淘金者“，那铲子就卖得动；
## 是否会长期开源下去
这个我不确定，我会视这个项目商业化的进度和竞对情况决定，所以我不鼓励大家来提 PR （ star 我不拒绝哈哈哈），因为将来一旦不开源了，有白嫖社区的感觉在里面；
## 其他的
1. 如果有合作意愿、想法碰撞或者疑问，欢迎咨询；
2. 欢迎大家来 Slack 群逛逛，以后大部分信息都会在 Slack 群里同步了；
3. 非常欢迎大家去 star 项目，如果想要提 PR ，可以找我，我这里会做 code review ；
### #Flink #Spark #demo #版本 #数据 #Slack #SaaS #计算 #框架
## 我们需要什么样的数据计算框架
Hi everyone~我们很高兴能跟大家介绍这款新型的数据计算框架，***Lightflus***。但我在这里想先跟大家探讨的就是我们到底需要什么样的数据计算框架。
目前最流行的两款数据计算框架是 Spark 和 Flink ，他们二者分别代表了 batch 和 streaming 两种计算范式。在 2016 年 Dataflow Model 被提出来了后，Spark 和 Flink 都希望填平 Batch 和 Streaming 之间的鸿沟。不管从理论还是工程实践上讲，Dataflow ，或者时髦点，叫流批一体，起码不是空中楼阁了。而在 Flink 被阿里收购以后，各种宣传漫天飞，在国内大有一统企业数据计算框架的趋势。
### Spark 和 Flink 有什么不足的地方呢？
从用户的角度来看，这两款框架虽然都非常优秀，但着实有**大炮打蚊子的感觉**，而且运维和开发都非常繁琐。尽管有 Spark SQL 和 Flink SQL 来简化（间接导致 Data Engineer 沦落为 SQL boy ），但是在很多场景下（比如 IoT ），SQL 还不够。主流的云厂商也不怎么支持 Spark 和 Flink ，除了阿里做了个阉割版的 Flink Cloud ，Databricks 奶亲儿子 Spark 外，其他主流云厂商很少会亲自下场做。
因此不论大小企业，想要应用 Flink 和 Spark 来做数据驱动系统（如 AI ），其实成本颇高，需要配置一个 infra 团队才能很好运转。对科技大厂可能无所谓，但对初创公司或者数据部门在组织架构里只是支撑部门并非业务部门的团队，可能根本拿不到那么多资源。
### 目前的数据计算框架（ Spark ，Flink ）存在的问题
1. **上手门槛和落地成本都很高**，对于数据团队来说，核心还是捋清公司的业务模型，更聚焦于业务而非技术细节，不然按这两年的光景，还在天天纠结底层原理就等着被裁吧：）；
2. **Cloud 化不够，每家企业都在搞重复建设**，浪费大量资源。以前热钱多随便燥，现在都讲降本增效；
3. **灵活度不够，管理成本和风险高**，传统企业或者初创公司希望搭建数据驱动系统，在团队组建和管理上都很难保持灵活性，降低成本和风险；
4. **存算不统一，数据存储成本高**，存算不统一，流计算和批计算各一套，两套存储，两份成本，扩展性也很差；
### 我们需要什么？
1. **轻松上手，无忧落地**：人都是懒的，尤其对工作，能少做点事，干嘛多做呢？
2. **Cloud-Native ，避免重复建设**：能省钱就省钱，KPI 完成了，老板赚到了，双赢：）；
3. **灵活度高，降低管理成本和风险**：你团队里谁都能干，也不需要招新人来磨合了；
4. **存算统一，一份数据**：这个好处我就不说了吧，一份数据好维护，成本低，谁用都说好；
## 我为什么做这个框架？
其实从上面给出的结论，也就不难得出我做 Lightflus 的初心：
1. **我希望将门槛高，成本高的数据计算框架变成普通的开发人员也能轻易上手的”快消“产品**。
2. 我是有技术追求的，**我希望能做一套存储来替代业内两套存储的方案**，并且成为产品的一个部分，向业界给出一个 state-of-the-art 的方案；
## 这个项目的设计是什么样的呢？
1. 我们用 Rust 实现了一个 Runtime ；
2. 我们提供了 Typescript API 来保证类型安全；
3. 没错，你可以在浏览器里写 Typescript 的代码跑流数据计算（我正是这么想的）；
4. 我们未来还会支持 WebAssembly ，这样 Runtime 的性能就会更好（更少的执行时间，更少的 GC ）；
5. 架构是 Coordinator-Worker 架构，典型的分布式计算架构，保证有很好的扩展性；
如果想知道更多细节，可以看文档，链接在 github 里；
## Lightflus 和 Flink/Spark 之间的与众不同的地方在哪呢？
1. API 不同，一个 Java 一个 Typescript ；找你们的前端同学就能写 streaming 任务；
2. 更小的 Runtime ，解决问题不再是上”重装坦克“而是”轻型人体工学装甲“；
3. 更简单的操作，我们提供的 CLI 工具会使得操作云端集群更加简单；
4. 更便宜，更灵活，对数据开发人员的心智负担更少，更聚焦于业务；
## 计算状态的容错是否支持？
1. demo 版本和 preview 版本尚不支持容错。但在 release 版本中将会支持
2. 容错我们将会参考 Flink 实现 checkpoint 机制；
## 支持哪些算子？
1. demo 版本将支持 `map`，`flatMap`, `reduce`, `filter`，`window`，`trigger`；
2. release 版本将支持 `join`；
3. 支持算子的列表和用法可能会随着版本迭代会更新，API 目前还不是稳定的；
## 支持哪些 sink / source ？
demo 版本将支持以下的 sink / source：
1. Kafka Sink 和 Source ；
2. Mysql Sink ；
3. Redis Sink ；
## 怎么参与进这个项目里来呢？
1. [Github]( https://github.com/Lady-Summer/lightflus)，欢迎大家多多 star~；
2. 加入 [Slack]( https://join.slack.com/t/lightflus/shared_invite/zt-1hqwryop3-jWOhWSuQ2B7wulhQM5~sHQ)；大家可以在 Slack 频道里针对产品畅所欲言；
## 什么时候公布 demo ，release 版本何时发布？怎么收费？
1. demo 预计在明年年初发布，目前 repository 给各位看的是 preview 版本，尚未经过严格测试，而且有些功能也还在开发中；
2. release 版本的发布和收费细节将在 Slack 群里公布，届时请大家多多关注 Slack 群；
## demo 版本可以预览的功能
1. Typescript demo API ；
2. CLI 工具支持；
3. Runtime demo features ；
## 短期和长期规划
1. 短期规划：明年把 release 版本做出来，如果可以，尝试融点钱，把项目更好运营下去；
2. 长期规划：我希望我可以将这个项目做成 SaaS 化的标准云服务，并且在商业上能够自我造血，让这个项目不至于在长期缺钱后死掉：）；
### 国内做 SaaS 那么难，为啥还想做 SaaS ？
1. SaaS 是个好生意，但国内软件市场需求和供给目前都不成熟，这跟国情有关；
2. 我的目标是 Global SaaS ，在国内运营的方式可能不一样，而且介入国内市场的时间可能要在项目比较成熟后，毕竟我也在 SaaS 公司做过，清楚国内软件商业化存在的问题；
3. 国内对软件的认识正在逐步提高，需要时间。我们定位是卖”铲子“，所以只要还有”淘金者“，那铲子就卖得动；
## 是否会长期开源下去
这个我不确定，我会视这个项目商业化的进度和竞对情况决定，所以我不鼓励大家来提 PR （ star 我不拒绝哈哈哈），因为将来一旦不开源了，有白嫖社区的感觉在里面；
## 其他的
1. 如果有合作意愿、想法碰撞或者疑问，欢迎咨询；
2. 欢迎大家来 Slack 群逛逛，以后大部分信息都会在 Slack 群里同步了；
3. 非常欢迎大家去 star 项目，如果想要提 PR ，可以找我，我这里会做 code review ；
### #Flink #Spark #demo #版本 #数据 #Slack #SaaS #计算 #框架
[求职][上海] 数据开发，现在还有机会吗？
迫于裁员减薪，op 我目前在降薪 /离职 n+1 之间摇摆，想先观望目前行情如何。
目前在现公司负责数据开发工作，是部门前期几个核心开发人员之一，主要负责 ETL 平台开发维护，主要技术栈包括不限于 Python ，Spark ，Pandas ，Django ，Kubernetes ，RabbitMQ 等等，偶尔要写写 Scala 维护点 UDF ；有时会给业务项目 SQL 调调优排排错；另外我对 Pandas 也比较熟，直接参与过科研项目的业务，有幸蹭到过第 n 作者。其他的话，op 工作经验五年不到；英语读写没有障碍，可日常沟通；以前在嵌入式相关公司干过开发和打杂，linux 服务运维开发啥都会一点点。
#op #Pandas #开发 #排错 #维护 #开发人员 #想先 #ETL #Python #Spark
迫于裁员减薪，op 我目前在降薪 /离职 n+1 之间摇摆，想先观望目前行情如何。
目前在现公司负责数据开发工作，是部门前期几个核心开发人员之一，主要负责 ETL 平台开发维护，主要技术栈包括不限于 Python ，Spark ，Pandas ，Django ，Kubernetes ，RabbitMQ 等等，偶尔要写写 Scala 维护点 UDF ；有时会给业务项目 SQL 调调优排排错；另外我对 Pandas 也比较熟，直接参与过科研项目的业务，有幸蹭到过第 n 作者。其他的话，op 工作经验五年不到；英语读写没有障碍，可日常沟通；以前在嵌入式相关公司干过开发和打杂，linux 服务运维开发啥都会一点点。
#op #Pandas #开发 #排错 #维护 #开发人员 #想先 #ETL #Python #Spark