xueling

首先我觉得有些朋友可能有两个误区，我说一下我的理解。
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 段、访问目标地址、访问时间段等方式进行流量统计和请求数统计(统计维度可以根据需要随意定制)，拿到确凿证据后向云服务商投诉，看看能不能要求赔偿。

首先要有一定的项目基础，再看一些多线程方面的书籍，要看书不要看博客，可以加入一两个开源项目提交些 PR 。工作过程中会用到很多数据指标，可以了解一下我的开源项目： 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 ，远算性能更强和支持的数据量级也更大。

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