0.现在业界有相对成熟的OLAP和OLTP统一解决方案吗？类似地TiDB感觉都严格的限制了业务场景。如果没有，OLAP和OLTP的统一会是未来的方向和趋势吗？会达到mysql或者oracle级别的流行趋势吗？如果不能，需要把历史数据存在仓库，短期数据供OLAP,实时数据或者中间表结果表供OLTP，多套数据重复粗放并存？
1.在一个WEB系统中，运营方或业务方直接生成一条SQL或者通过组件提交在后端生成任务JAR，提交到spark，flink集群，等待结果返回至前端渲染。只有我一个人才强烈想要这种功能吗？没有这种功能，是因为有OLAP方案吗，还是业务特征不够典型？
2.实时计算和离线计算的泾渭分明在spark和flink业已成熟的今天，在技术上已经不存在了。但在业务上呢？随着业务越来越多，T1的方案在凌晨短短的几个小时窗口能否按时完成（还不谈数据延迟）？业务方每一个需求都要生成中间表结果表？
3.个人觉得对于大数据技术人员最大的挑战在于技术选型。相对于WEB开发，哪怕在现在动辄不吹点高并发大流量分布式都不好意思聊天的今天，除了分布式事务尚有争议以外，分布式锁，分布式缓存，击穿，雪崩，淘汰算法，分布式唯一健，分库，分表，读写分离，限流，熔断，降级，微服务都有了比较成熟的公认解决方案。更别说spring套装一统江湖的野心。但在大数据领域，在各个细分方向都并没有通吃的解决方案。每一个技术方案都有侧重点，不能包打全场。很多情况是，某种技术BAT在用，我朋友的公司在用，听说还不错，看官方文档性能很好。如何根据实际业务场景找到合适的技术方案，是技术，经验，合作，试错的结晶。现在的时代，对技术广度和深度都有很高的要求。
4.敏捷性。针对运营方或者业务方式的某一个需求，比如监控预警需求，可自定义数据源，目标，事件，触发，临界点，下游等等，自行得到结果。而无需技术人员现编码。
5.脱离了实际场景谈性能都是耍流氓。特别针对大数据存储领域。
6.ETL是脏活累活，不容易出成果。但觉得没有必要专门针对此搞一个职位。
7.除了BATMD等一二三线大厂，世面上绝大多数公司大谈大数据，机器学习，人工智能，重灾区是区域链（最近发现今年重庆这边区域链又死灰复燃了）。请优雅的保持微笑。
8.多大数据才算大数据啊？TB级？数据质量的兼顾呢？
9.很多情况下为了大数据而大数据。