首先我觉得有些朋友可能有两个误区，我说一下我的理解。
1 、阿里拆的中台更多的是”业务层面上的中台“，比如将很多业务的下单功能、订单列表查询功能、列表推荐功能、购物车功能等统一成中台服务，而楼主所说的数据中台是”技术层面的中台“，所以严格来说这里的”中台“并不是一个概念。
2 、数据中台是不是只围绕着数据的统计分析方面功能？不是。这只是它的一部分功能，从概念上来讲，使用一些实时、离线、OLAP 框架搭建起的数据统计分析任务或接入一些 BI 工具，是不能称它就是数据中台的。

数据中台的功能主要有三类：一是业务数据治理，二是围绕着业务数据进行的各种实时、离线和即席查询任务的管理、调度和维护，三是数据化运营。
1 、业务数据治理。有些公司将业务数据和业务统计分析类数据都统称为业务数据（比如订单数据和订单的统计分析数据），我觉得这不太合理，因为两者有本质的不同（技术实现方案以及数据应用场景不同），混为一谈其实容易影响数据中台的架构设计。
业务数据治理是提供业务方自身数据的写入(实时或离线)、存储和查询功能，围绕着这些基本功能再衍生出：元数据管理、业务数据清洗、业务表的上下游关系管理、业务表的权限管理等。
还有一个误区，公司要搭建数据中台，那公司目前的技术架构是要推翻重构还是维持不变。大多数情况下是不需要推翻重构的，当然也不能维持一点不变。而是要进行一些”整合“。整合就是梳理出公司内部具有较高共享价值的业务数据，在基本维持他们技术方案不变或微小改变的前提下，将它们的存储库或存储库的镜像库迁移到”中台“当中来，从而减少数据共享过程中使用数据的成本。
2 、围绕着业务数据进行的各种实时、离线和即席查询任务。这一部分的基本功能是建立统一的数据任务调度平台，比如实时（ spark/flink 等），离线(spark/mr 等)和即席查询(ck/hive/doris 等)，应用场景：比如实时画像任务、实时日志接收、订单的多维分析等。这一部分功能又衍生出一些功能，比如统一的消息接入服务、与上面业务数据和下面数据化运营互相打通的业务数据读取、写入和统计指标数据读取、写入的机制。
3 、数据化运营，数据化运营是提供企业运营过程中的各类统计分析指标，技术方案主要有各种实时、离线、olap 方案，这一部分又衍生出统一的埋点服务、数据指标可视化等相关功能。数据化运营可以使用一下我的开源框架： https://github.com/xl-xueling/xl-lighthouse ，可以减少很多实现成本。

竟然还有这种情况，可以使用我的开源项目，https://github.com/xl-xueling/xl-lighthouse （单机版就可以）排查一下原因，通过 IP 、IP 头、IP 段、访问目标地址、访问时间段等方式进行流量统计和请求数统计(统计维度可以根据需要随意定制)，拿到确凿证据后向云服务商投诉，看看能不能要求赔偿。

你说的物联网的数据中台，我觉得应该有两方面作用：1 是物联网设备上报的原始消息的读写，2 是相关数据指标的统计监控，我觉得第一部分的功能选择时序性数据库还可以，但第二部分的功能其实很牵强，虽然时序数据库也可能有这方面的功能，但性能不会很强。我建议您了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ，虽然是大数据项目但后期维护其实非常简单。支持一键部署、数据自动备份、可以灵活扩容，轻量级使用，可以快速实现大批量数据指标。

首先要有一定的项目基础，再看一些多线程方面的书籍，要看书不要看博客，可以加入一两个开源项目提交些 PR 。工作过程中会用到很多数据指标，可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse

这种设备上报的数据查询方式，一般是聚合统计指标或者按设备/时间查原始记录信息。实现方案很多，推荐：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 的工作。不管学了多少东西，只要没有项目经验，都会觉得心虚。