慢!
1、清单式大报表难以及时呈现，采用数据库分页方式翻页效率很差
2、查询报表从数据库中取数量大，JDBC传输性能低
3、T+0实时全量查询涉及数据量大，影响生产系统运行，而分库后又难以实施跨库混合运算
4、SQL复杂，嵌套层次多，数据库优化路径不可控，运算性能低
5、存储过程步骤多，代码长，使用临时表落地中间数据，性能低下
6、数据关联运算太多，十几甚至几十个表JOIN，性能恶劣
7、巨大数据量中按条件查询或用批量键值取数，无法建索引或简单索引效果很差
8、SQL难以实现的运算只能在外部应用程序或用UDF开发，高性能算法实现难度大导致效率低下
9、使用了内存数据库或内存计算技术仍然不能满足性能要求，占用内存过大，硬件成本太高
10、中央数据仓库支撑了过多应用，并发过多导致性能不可控，前端用户体验差
繁!
11、生产库和分析库在一起，大数据运算可能影响生产系统运行；分库又难以做到实时全量查询
12、很多业务应用中都要部署单独的前置数据库作为数据集市，成本高昂
13、前置数据库中只能存放部分频繁数据，难以与中央数据仓库混合运算，前端应用只能分别针对不同库查询分析
14、数据库中有大量非原始数据的中间表，冗余严重，而且年代久远非常难管理
15、报表或ETL涉及多数据库和非数据库的整合，SQL无法直接运算，需要事先汇总到单库，ETL做成ELT和LET，数据库臃肿且性能差
16、查询报表涉及Web或IOT等实时数据，事先导入数据库不仅效率低又影响实时性
17、Java和SQL编写的运算逻辑与界面模板分开存储，程序耦合性太强，还难以做到热切换
18、BI系统（多维分析）的后台，采用普通数据库性能跟不上，用专业的列存数据库又太沉重/造价太高
19、数据中心对外提供数据访问服务时要解决权限、脱敏等问题，后台还涉及多个异构数据仓库及多样性数据源整合困难
累!
20、报表没完没了，业务人员取数需求多，自助报表敏捷BI也不管用，技术部门应对吃力，找不到低成本高效率的应对手段
21、数据源SQL或存储过程过于复杂，嵌套或步骤多，SQL缺乏调试机制，开发效率低下
22、涉及有序及过程性复杂运算，要用库外的Java开发或编写UDF才能完成，人工成本高
23、涉及MySQL等开源数据库，窗口函数等许多高级语法不支持，开发困难
24、涉及NoSQL、文本、Excel、json/xml等库外数据，无法使用SQL，只能硬编码，开发效率太低且难以维护
25、某些数据仓库（或大数据平台）对存储过程支持不好，难以完成复杂运算
26、SQL（存储过程）语法涉及数据库方言，难以移植
27、ETL工具不能直接解决复杂业务逻辑，还要大量编写脚本，而ETL工具的脚本功能常常弱于SQL，开发困难
Hadoop？
28、采用了Hadoop/Spark集群仍然难以获得期望的性能
29、Spark内存耗用太大，硬件成本太高，很多运算超过内存范围还无法实施
30、Hadoop集群规模不大，只有几个或十几个节点，管理的数据并不多，无法发挥其优势，但维护却很复杂
31、Hadoop/Spark难以完成需要的计算，结果又在旁边部署传统数据库来实施计算，结构累赘且效率低
32、Hadoop/Spark提供的计算接口不够用，复杂运算经营还要编写UDF，开发效率低
Python？
33、Python并非专门为结构化数据计算设计，开源包贡献者不同，风格不统一，复杂过程编写并不简单
34、涉及Excel/json等非库数据，Python等开源技术虽然接口丰富，但版本混乱，难以驾驭
35、Python缺乏自有大数据方案，几乎不能写并行程序，无法充分利用多CPU能力
36、Python代码难以和Java集成，算法需要嵌入到生产系统时常常还要重写
37、Python等桌面开发环境调试功能不够友好，开发与测试效率低