@faywong8888 1 、目前只有 java 版本的 sdk ，还有个临时的 http 接口，如果不是 java 技术栈，数据量不大的话可以使用 http 接口上报，这样接入成本更低一点。现在 http 接口是一个单独的工程，后续我会把 http 接口和 rpc 服务融合在一起。如果数据量大的话就要考虑用 java sdk 来上报。我还没有试过在 c++中直接调用 java 版的 sdk 是否会存在太大的性能损耗，但我感觉应该没有较大问题，可以试一下。数据量大的话还有一种方案就是中间加一层类似 kafka 的消息组件，先将数据写入消息组件，然后再通过 java 消费的方式。上报方案完全取决于你的数据量。至于开放协议，暂时还没有，因为 sdk 中除了基本的上报逻辑，还涉及一些消息数据的聚合、秘钥验证等逻辑，实现起来其实有点麻烦，至于将上报协议公开，我还要再好好考虑一下看看有没有这种必要。

2 、是否涉及软件授权费用？ 企业内部或个人使用都是不收取任何费用的，而且没有任何数据量和数据指标数量的限制。但如果涉及到对外销售相关服务（比如给第三方提供可视化大屏服务并获取收益），就需要收取一定比例的授权费用。

3 、没有单机部署的 docker compose 。不过项目本身就是一键部署，操作很简单。

4 、后台数据发生增加/删除/更新，统计/监控前台界面是否自动刷新？
首先，你说的后台数据是不是指上报的原始消息数据，大部分流式统计场景是不需要删除和更新操作的，只有新增。这与 OLAP,OLTP 类的技术方案不同，XL-LightHouse 本身并不维护原始消息数据，只维护统计结果状态值，所以是不支持删除和更新的，不过项目支持负值运算。
其次，目前前端交互方面支持的功能，如果统计结果发生变化，前端图表不会自动刷新，看下面的图片，需要点击一下统计项标题旁边的刷新按钮，图表才会刷新。后续会提供数据大屏功能，可以免登录、自定义视图、图表自动刷新等功能。

https://camo.githubusercontent.com/cf74e768875fff5628f4f5aec59a106fcffe9fac13d55624dc76771381765785/68747470733a2f2f6c69676874686f75736564702d313330303534323234392e636f732e61702d6e616e6a696e672e6d7971636c6f75642e636f6d2f73637265656e73686f745f76322f32332e6a7067

如有问题，可以加我微信，随时联系我~

@Breadykid 我的项目其实不重，有单机版本，可以不用集群版本那一套，一键部署，只是你没有用过，感觉上会重而已。我的项目优势是核心的统计运算方面的功能比神策强多了，不管是承载的数据量、计算性能、能够支撑的数据指标的数量、还是实时统计方面操作的便捷性。当然，如果你确实数据需求较少，也已经部署神策了，而且他们能满足需求，那就忽略吧~~

看你侧重什么了，如果你侧重前端的交互形式，丰富、炫酷的可视化展示功能，那请忽略。但如果你侧重统计计算方面功能的完善度、性能和稳定性、支撑的数据量级，那你考虑一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse 。优势很多，拿来即用，几乎没任何开发量，将数据指标的原始数据上报上来就 OK 了，既有集群版本也有单机版本，有完善的数据指标管理和权限审批机制，统计项直接在页面配置就可以了。可以考虑一下，有任何问题，我会第一时间帮你解决。

业务埋点其实不太能做到你期望的与业务完全解耦的状态，一般来说通过切面或注解能实现的都是一些相对固定的、标准化的埋点，而对于大多数自定义业务埋点，由于上报参数和上报时机差异太大，所以并不适合这种相对固定的上报形式。

1 、服务端埋点方案设计一般侧重在埋点规范的定义、公共参数和业务参数的区分、统一的埋点的上报和接收方案等方面，确保在埋点上报出现问题后不会影响正常的业务服务就可以了，其实不用太纠结与业务代码的耦合；
2 、埋点接收后将数据写入消息中间件，与数据平台服务解耦，写入消息中间件的数据是一份可以被共用的基础数据（包括实时或离线使用的形式）；
3 、围绕着服务端埋点，大多数的数据指标我建议采用通用型流式统计的方案来实现，接入简单，无 SQL ，不容易出错，针对一份埋点数据可以灵活的实现各种自定义指标，运算性能更加强悍，更容易实现指标之间的交叉验证，能够很方便的的在页面管理每个指标的执行状态，可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ；
相比于 OLAP 数据指标的实现方案其实有很多好处，服务端埋点可能会经常变动，包括埋点的上下线或参数的变更，但 OLAP 需要维护全部的埋点序列数据，性能并不高，而且容易产生脏数据。

看了前面的评论，我有两个看法，一是：你们用 k8s 是对的，但是是无奈之举。物理机已经买完了，集群规模这么小，又要部署那么多的服务，不使用容器化，那服务之间互相影响，其实更容易出问题，使用 k8s 做个服务间的资源隔离是必要的，现实状况使得几乎必须得用容器化了。 二是：我还是觉得云服务器更好，省去团队的学习成本和维护成本，你说计算量大用云服务器不合算，我其实不太认同，综合计算下来可能云服务器更省钱。我看你们还有部署 clickhouse ，如果是数据统计的话，也可以考虑用一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse

经验+猜测+验证+猜测+验证...，循环往复，有些 bug 的发现真是纯靠执着。 数据异常、数据波动类的问题，可以用我的开源项目解决： https://github.com/xl-xueling/xl-lighthouse

这种公司确实够烦人的，明显是管理人员不懂技术或者对技术方案设计和实施缺乏驾驭能力的表现。庆幸我工作这些年从来没有遇到过这类公司，虽然也有某个项目阶段，时间比较紧张的情况下要写日报，但也绝不会精确到 0.5 小时

一、配置文件如何更新，首先配置文件要有版本标识，系统版本和配置文件版本互相关联，防止出现系统版本和配置文件版本出现兼容性问题。配置文件尽可能考虑向下兼容设计。采用客户端定时拉取的方式进行升级。
客户端拉取后将配置文件和升级程序存放在单独目录，验证升级包数据完整后，定时执行系统更新。系统增加故障恢复机制，升级失败后可以回退到原版本。所以建议要将：配置文件目录、系统安装目录、数据库数据目录、升级或回退程序目录、临时升级包存放目录要区分清楚，目录混在一起就非常容易出问题。

二、监控数据上报如何实现，由于客户网络状况较为复杂，建议采用定时上报心跳包的形式，系统将心跳包日志数据首先写入到暂存目录。然后打包线程根据数据量和时间生成日志文件，比如每 5 分钟生成一个日志包文件。使用异步上报线程将暂存目录的日志包数据上报到远程服务器。上报正常则清除客户端的缓存数据，否则等待下一次异步线程轮询处理。

三、系统监控和业务监控如何实现，我理解你说的系统监控是指系统运行状态监控，包括：磁盘、cpu 、内存、负载和系统运行状态等指标， 业务监控是指根据你们自身业务逻辑层面的监控，比如像订单量、你说的 OCR 识别次数、OCR 异常率等此类你们需要的所有的业务类指标，

我看到楼上推荐的技术方案，其实并不符合你们的场景，这些千篇一律的服务器运行状态监控，提供的都是一些相对固定的数据指标，实现自定义扩展很难。而且接入也比较麻烦，也不能实现业务层面的指标监控。

我向你推荐我的开源项目： https://github.com/xl-xueling/xl-lighthouse ,可以灵活的自定义设置各种监控指标，灵活的设置分钟级、小时级、天级粒度的统计监控，支持自定义设置统计维度，一键部署、支持数据备份、有完善的 API 接口，，支持 rpc 接口和 http 接口接入，非常方便，也可以通过 api 查询统计指标、有完善的指标可视化功能和权限管理机制、你们只有 100 台服务器，感觉用单机版就可以了，最低配置只需要一台 4 核 8g 的服务器。

starrocks 好像就是 doris 团队的人出走后开发的，这两个应该技术方案差别不大。我没用过 starrocks 。你们每天的数据量有多大，应该都可以满足你们的需要。如果单表查询逻辑比较复杂，单表字段非常的多情况下我推荐使用 clickhouse ，主要优势是单表查询性能强，而且写入性能强，但是运维成本略高。如果单表字段不多，查询逻辑不太复杂，或者有多表 Join 的场景就用 doris 。doris 运维更简单一些，而且对 sql 支持很好，从关系型数据库平移数据比较容易。另外，可以搭配使用我的开源项目： https://github.com/xl-xueling/xl-lighthouse.git ，我的项目的优势是使用成本极低，可以很方便的完成各种数据指标和业务监控，比 OLAP 更加轻量级，支持超大数据量的实时计算，支持一键部署、数据备份、数据指标可视化 ... 已经经过严格的测试，可以放心使用，任何问题可以随时找我~

首先我觉得有些朋友可能有两个误区，我说一下我的理解。
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