这种设备上报的数据查询方式，一般是聚合统计指标或者按设备/时间查原始记录信息。实现方案很多，推荐：victoriametrics,timescaladb,hbase ，至于要不要选择 ck 或者 doris ，主要看查询的复杂程度。如果有比较多的维度字段，需要任意选择维度进行即席查询，可以使用 ck 或 doris 。如果维度字段很少，查询方式比较简单的话，那就不需要用 ck ，doris 。业务实现涉及很多数据指标，可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse 。

1 、使用 snappy/gzip 实时压缩；
2 、使用枚举 ID 代替不必要的文本传输，减少类似描述信息等文本内容的传输，数值类型参数不要使用字符串，键值也可以使用 id 替代；
3 、使用字节流类型接收和返回数据，根据二进制位自定义传入和返回数据协议（最好统一封装 http 请求和解析工具类给交互方）；

了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse 实时监控接口数据传输量，便于衡量优化效果。

了解一下我的开源项目，https://github.com/xl-xueling/xl-lighthouse ，定位不是纯粹的监控系统，统计计算方面的功能远超过 prometheus ，远算性能更强和支持的数据量级也更大。

时序性数据库可以考虑 VictoriaMetrics ，TimescaleDB ，hbase 等方案。我不知道你说的数据查询场景都有什么场景。如果大部分是分钟、小时、天等粒度的指标查询，可以不依赖时序数据库，而依赖流式统计来实现，因为时序性数据要对存储到磁盘的数据进行计算汇总后再返回结果，这个查询效率其实并不非常高，而流式统计其实更适合。技术方案可以变更为：1 、使用时序性数据库存储原始数据，作为备用，2 、使用流式统计服务提供数据指标查询功能。这样流式统计服务可以分担很大的数据查询压力。可以考虑一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse

@levelworm 可以了解一下我的开源项目 https://github.com/xl-xueling/xl-lighthouse ，可以节省很多数据指标的开发工作。

可能是网络层面的问题导致了小部分请求较长时间的阻塞。建议添加完整的服务监控，对整体链路、网络请求阶段、以及接口处理的每个重要环节都添加上细粒度的耗时监控。可以使用我的开源项目实现： https://github.com/xl-xueling/xl-lighthouse

前面说的都是有道理的，我觉得也是这样 ”程序 + 人工“ 两者结合。程序输出一个较大范围的热榜数据，然后人工再选择一下。可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ，帮你轻松实现任意维度的热榜数据，你可以自定义加权计算规则，然后实现实时打分排序。通过汇总多个热榜指标的数据，然后再人工筛选。

偶发性的问题不太容易定位，跟很多因素有关，可能是外部原因，比如正在 GC ，或者某个时间段网络/磁盘 IO 过载导致的，也可能是你接口本身的问题，其实原因挺多的。最好监控一下接口在各个耗时区间的分布情况，然后在每个重要环节都添加上耗时监控，再把 trackId 找出来比对日志逐一排查。偶发性的问题其实不太好排查，都是笨方法。可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ，让你轻松实现任意细粒度的接口耗时监控。

@xueling 单机版面向中小企业和中小数据量的业务场景使用，大概还需要 1 个月左右的时间发布。

可以用我的开源项目 https://github.com/xl-xueling/xl-lighthouse.git ，只要自己写个脚本把数据上报上来就可以了，功能很强大，不过是个集群服务，需要 3 台服务器，目前单机版我还在开发。

推荐一个我自己开发的工具，https://github.com/xl-xueling/xl-lighthouse ,可以轻量级实现各种业务数据统计功能。

可以用下我的开源项目，在关键的代码逻辑处加一些耗时监控看看情况，github 搜索：xl-lighthouse

我现在用的 pro 16G ，后悔当时没多加两三千买 32G 的了，目前只做开发还基本正常，不过打开虚拟机 再加上开发工具风扇就会呼呼的响

快速转 java 的方式就是找一份 Java 的工作。不管学了多少东西，只要没有项目经验，都会觉得心虚。

@nevadax 哈哈，感谢您的评论，您评论其实让我蛮高兴的。不过您可以先试用下再发表评论，然后证明我在吹牛。不过，我可以跟你说：十亿级用户量 APP 的 DAU 统计、十几万台服务器的运维监控，xl-lighthouse 可以轻松支撑。在流式统计这个细分领域内，我认为在业内目前是没有对手的，包括很多云服务厂商的对外服务~

兄弟，用我的开源软件，不能帮你实现所有需求，但是可以帮你实现很多需求，可以实现统计 1 天内、小时级、分钟级的 uv,和各地区的 uv ，支持高并发查询结果。至于地区模糊查询和超过 1 天以上日期的查询可以借助 clickhouse 或离线统计来实现。为什么不建议全部使用 ck ，因为 ck 每次查询都是全量计算，并发查询效率比较低。我的开源项目： https://github.com/xl-xueling/xl-lighthouse.git ，有问题找我~

我的开源软件，刚刚起步，不过我感觉市场前景挺大的，可以了解一下： https://github.com/xl-xueling/xl-lighthouse.git

react 吧，我的开源项目前端部分就是用 react 开发的，效果不错，可以了解下： https://github.com/xl-xueling/xl-lighthouse.git