数据开发现状
我：这次换工作大概投了多少家，接到多少面试
我朋友：几百家，面试个位数，我个人感觉，有效面试不到 5 家，3 家这样

先列举大数据必知必会的几个组件给你 Spark(计算引擎)、Flink(计算引擎)、Datax(抽数工具只列举一种)、Hadoop(MR 引擎淘汰，大部分企业不用了，但你要会，这是大数据鼻祖了)、Hive(OLAP)、Clickhouse(OLAP)、Doris(OLAP)、DolphinSchduler(调度比较多只列举一种)、Iceberg 。就先围绕着这些学习吧，JAVA SE 、SCALA 必学，这两门语言在大数据领域很重要。python 会不会看你了，我反正没怎么学，工作中没用到主要。还有以前很火现在逐渐退出历史舞台的我没列举了，毕竟有更好的东西替代。

近几年 AI 崛起，大数据也要开始摸索 AI 在大数据的应用，这个都还没开始做或者刚开始做，但我估计只是时间问题。

基本的那些算法要会。

如果你偏向平台方向，你要会 spring

如果你偏向业务方向，你要会 BI(比较出名的 BI 报表国内有帆软等、国外 Apache 也有开源 Bi)。

@thebeacon 考虑到你的 json 格式不固定，那就简单粗暴一点。拿到原 json 后,把原 json 的 response. customerInfo.children 全部拿出来装入集合。清空原 json 中的 response. customerInfo.children.拿刚才的集合一个一个的全部遍历填充进去。结束

@zydxn 这玩意真的要把备注写清楚

没事儿别瞎折腾 我 10600KF+5500XT 都折腾很久，你还想用 13 系的 U 玩黑苹果吗

上面两段是，gpt 的问答，我个人建议你直接用第一种方式。可读性比第二种高，性能也比第二种更好。如果把数据量计算在内的话，当数据量超出一定量时，直接移交数据部门(大数据)去做，这种分析对于 mpp 架构的数据库来说，小菜一碟 ，OLAP 数据库 干的活就别为难 OLTP 数据库了。

请列出两种方式的空间复杂度和时间复杂度

第一种方式的时间复杂度为 O(NlogN)，其中 N 为用户数量，因为查询语句需要进行 group by 操作，这需要对用户表中的数据进行排序。如果你在 user_id 上创建了索引，这个时间复杂度可能会更低。

第一种方式的空间复杂度取决于查询语句返回的行数和每行数据的大小。如果查询结果集中的行数较少，那么空间复杂度也相对较低。如果每行数据的大小较大，查询结果集中的数据量也会增加，从而增加空间复杂度。

第二种方式的时间复杂度为 O(NlogN)，其中 N 为用户数量。第一次查询需要对用户表中的数据进行 group by 操作，这需要排序，因此时间复杂度与第一种方式相同。第二次查询需要根据 user_id 来查询用户信息，这个查询的时间复杂度为 O(MlogM)，其中 M 为查询结果集中的行数。

第二种方式的空间复杂度取决于第二次查询返回的行数和每行数据的大小。如果第二次查询返回的行数较少，那么空间复杂度也相对较低。如果每行数据的大小较大，查询结果集中的数据量也会增加，从而增加空间复杂度。

对于这个需求，第一种方式是更合适的。使用 group by 语句来聚合数据并显示用户信息是一种常见的 SQL 操作，也是最常用的方式之一。第一种方式可以一次性查询出统计信息和用户信息，而且语句简单易懂。

对于性能问题，将用户信息相关的字段放到 group by 中的确会增加查询语句的复杂度，但是如果你的数据库表结构设计得当，并且使用了正确的索引，那么性能问题应该不大。你可以考虑在 user_id 上创建索引以提高查询性能。

第二种方式需要进行两次查询，这样的话会增加查询的复杂度和执行时间，而且也不太容易理解和维护。因此，如果数据量较大或者查询频率较高，第二种方式可能会导致性能问题。

总的来说，第一种方式更简单、可读性更高，而且性能也不错，因此我建议你采用第一种方式来实现这个需求。

@zddwj 这玩意这么吊呢？给出的代码还关联上你问题的上下文了

@DinnyXu 把近一年的数据直接捞 spark 里就行了。可以 jdbc 去读，但肯定最好用语句直接到出成文件快，spark 并行读取该文件就可以，无视 mysql 索引。具体怎么替换图片，直接在 map 算子里搞定