科学完善的数据指标体系是企业开展数字化运营管理、打造数据驱动型组织的重要支撑。透过多维度的数据指标，运营人员能够清晰了解业务现状，产品/研发人员能够高效定位系统问题，管理人员能够更加准确地做出分析决策。那么，如何在充分理解业务需求的基础上，搭建出一套有效、好用的数据指标体系？本文对个推TechDay“治数训练营”系列直播课第三期进行了回顾，与大家分享《数据指标体系设计与开发实战》。☝点击观看直播回顾视频课程回顾数据指标与指标体系数据指标是一种特定类型的元数据信息，是将业务单元细分后量化的度量值，同时也是业务和数据的交汇点。数据指标使得业务目标可描述、可度量、可拆解，能够为产品运营日常开发迭代以及引导科学决策提供可量化的支持。数据指标一般分为结果型指标和过程型指标两类。结果型指标，用于衡量用户在某个动作后所产生的结果，以及度量某个场景下用户的需求是否得到满足，这个结果通常是延后知道的，人们很难进行干预。过程型指标，是指用户在做某个动作的过程中所产生的指标，过程性指标更加关注用户的需求为什么被满足或者未被满足，人们可通过特定策略来影响过程性指标，从而影响最终的结果。例如，就一场电商促销活动而言，最终的销售额是结果型指标，商品页面的曝光、点击、加购等数据均为过程性指标，电商运营人员通过运营策略提升曝光量、点击率、加购转化率等过程性指标从而影响最终的结果型指标。通过分析销售转化链路各环节上的数据指标，业务人员能够清晰掌握业务情况单个的数据指标并不能完整地反映业务运营情况，还需要我们从全局出发，将零散、单点的、具有相互联系的指标，系统化地组织起来，构建一套数据指标体系。数据指标体系的建立过程其实也是我们对业务本质进行思考的过程。一套科学、完整的数据指标体系能够衡量业务发展质量，帮助我们通过单点看业务全局，通过全局解决单点的业务问题。数据指标设计与开发企业构建数据指标体系首先要根据业务目标，梳理相应的数据指标。我们推荐参考OSM

近日，个推TechDay“治数训练营”系列直播课第二期举办。来自每日互动（个推）的资深数据研发工程师为大家详细解读了实时数仓架构演进，分享了实时数仓的技术选型要点，并结合实战案例详细剖析实时数仓搭建秘诀。课程回顾当下，企业的实时计算需求越来越高频。比如很多企业在建的实时数据可视化大屏就是很典型的实时计算场景：大屏数据实时刷新，展示最近一分钟甚至半分钟内的交易额。类似的实时计算场景还有很多，比如智能算法推荐、系统风险预警、实时特征工程等。而以往的离线数仓具有高延时性，数据时效性一般为T+1，调度频率也是以天为单位，无法满足这些场景的数据时效性要求。所以，实时数仓便成为很多企业的大数据架构选择。何为实时数仓？关于实时数仓，目前行业内还没有一个标准的定义。我们可以从以下几个方面来理解“实时数仓”：①实时数仓主要支持实时数据处理，并能够根据业务需求提供实时数据。②实时数仓的整个数据链路均采用实时的方式，包括数据归集、加工处理、数据分发等各环节。③另外，实时数仓的数据生态也采用实时方式，比如数据建设、数据质量、数据血缘、数据治理等。数仓架构演进从经典数仓架构到离线数仓架构，再到能支撑实时计算场景需求的Lambda和Kappa架构，数仓架构也经历了较长的演进过程。数仓架构演进这里着重介绍一下Lambda架构和Kappa架构。Lambda架构其实是在离线数仓架构的基础上，新增了一条实时链路，用于支撑低延时业务场景的计算需求。与此同时，离线计算（批处理）链路仍然存在。也就是说，Lambda架构采用实时和离线两条链路。由于同一部分业务代码需要有两套逻辑支撑，所以Lambda架构的后期维护比较复杂，对资源的消耗也比较大。基于此又迭代产生了Kappa架构。Kappa架构在Lambda架构的基础上进行了优化，删除了Batch

当下，企业的实时计算需求越来越高频，很多企业和组织选择建设实时数据仓库，以敏捷支撑实时报表分析、智能算法推荐、系统风险预警等多元业务场景需求。相比离线数仓，实时数仓有哪些特性？如何进行实时数仓的技术选型？个推TechDay“治数训练营”系列直播课第二期来了！8月24日（下周三）晚上19:30-20:30，个推资深数据研发工程师为您解读实时数仓架构演进，分享实时数仓技术选型要点，并结合实战案例详细剖析实时数仓的搭建秘诀。更有超多惊喜福利等你拿！还等什么？立即预约直播吧

近日，2022年个推TechDay“治数训练营”系列直播课第一期圆满举办。个推资深大数据研发工程师为大家深入浅出地介绍了数据仓库的前世今生以及数据建模的常用方法。本文对“治数训练营”第一期《数据仓库与维度建模》的干货内容进行了总结，同时也挑选了直播间的精彩提问做了Q&A梳理，带大家一起回顾首期课程。直播回顾视频（上）01数据仓库快速入门数据仓库（Data

首先，需要用索引检索出数据所对应的行号或者索引位置，要求能够从上亿条数据中快速过滤出几十万或几百万的数据。这方面是搜索引擎最擅长的领域，因为一般关系型数据库擅长用索引检索出比较精确的少量数据。

本文是系列文章的开篇，首先聊一聊我们理解中的数据智能的本质；同时作为公司技术负责人，和大家探讨一下基于技术体系的要求，也就是数据智能时代，要从数据中体现智能，从技术方面需要做哪些事情。

如今，科技与金融深度交融的时代已经到来，金融风险控制任重而道远,。个推将持续挖掘其丰富的数据资产，不断打磨自身技术，助力金融行业运作效率和服务能力的全面提升。

partition的数量。Receiver模式下num_receiver的设置不合理会影响性能或造成资源浪费；如果设置太小，并行度不够，整个链路上接收数据将是瓶颈；如果设置太多，则会浪费资源；

IPv6网络将成为互联网新业务发展与运用的强有力支撑。未来，个推也将不断打磨自身技术，积极探索并开展IPv4至IPv6之路，实现IPv6网络的全面启用。

在整个微服务体系中，API网关是基于Openresty开发的，主要使用Lua进行开发；后端服务主要使用Node.js和Java进行开发实现。在对接Zipkin时，不同的微服务采用不同的方式进行实现。

Window下只支持为Android设备构建并运行Flutter应用，而macOS同时支持iOS和Android设备。下面将分别介绍如何连接Android和iOS设备来运行flutter应用。

随着互联网的快速发展，数据维度越来越广，呈现形式也越发丰富，具有多维度数据特点的相关业务实践都能通过可视化图表来展示，比如个推的下发图，从时间和区域两个维度，可以即时、直观地展现个推数据下发的过程。

允许每个主题分区有多个消费者。同一个订阅中的每个消费者仅接收Topic分区的一部分消息。Shared最适用于不需要保证消息顺序队列(Queue)的使用模式，并且可以按照需要任意扩展消费者的数量。

随着粒子数量的增加，需要的计算每个粒子的位置和大小将会非常耗时，可能会造成动画卡顿或出现页面假死的情况，所以我们在建立模型时可尽量减少粒子的数量，能够有效提升性能。

移动端技术发展很快，而画面显示优化是一个持续发展的实践课题，贯穿于每个开发者的日常工作中。未来，个推技术团队将继续关注移动端的性能优化，为大家分享相关的技术干货。

Native实现跨平台的功能，主要由Java、C++和Javascript三层所构成的。其中，C++实现的动态链接库（.so），作为中间适配层桥接，实现了JS端与原生端的双向通信交互。React

在业务开始前使用SphU.entry();方法标识开始，结束使用entry.exit();，如果触发了流控逻辑就会抛出BlockException异常让用户自行处理。

网关的配置均为热更新，通过Consul和Consul-Template来实现，配置在Consul上进行更新后，Consul-Template会将其实时地拉取下来，然后通过以下两种方式进行更新。

虽然三大运营商的动作如此迅速，但是考虑到部分NB-IoT终端的工作环境，目前的NB-IoT网络覆盖率仍然不够。相对较低基站的数量与覆盖率也迫使终端必须抬高发射功率，导致超长电池寿命大打折扣。

Client的依赖，在应用启动时，会初始化一个Watcher来监听Consul上对应目录下K/V的变化，相关的K/V发生变化时，Watcher会负责将其拉取下来，然后调用相关的代码进行配置的更新。

https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#entrypoint

【个推技术学院】是专业数据智能服务商个推旗下的技术分享专栏，这里有行业前沿资讯、深度技术干货和最新优质活动。

optimizer.apply_gradients(grads_and_vars,global_step=global_step)最后，使用tf.train.Supervisor

4、社区版本集群每次重启都要重建索引，然后加载到内存，这会导致速度比较慢。namespace需要在配置文件中指定，因而最好能按业务划分，预先分配好将来可能用到的namespace，减少不必要的重启。

热力图的最终效果常常优于离散点的直接显示。依托多年推送服务的积累和海量数据资源的优势，个推热力图能够直观地展现各区域的人群分布和密集情况，为相关的应用提供可视化的数据支持。

开发者在实践的过程中，基于大数据进行用户行为预测会有两大难点：第一，开发者需要使用多种手段对目标问题进行分解；第二，数据在特定的问题上会有不同的表现。

第一种方案：首先，子模块js文件是在页面跳转之后再进行加载，因此，在404跳转和路由权限校验的实现上会遇到一些问题；其次，在子模块文件加载完成之前以及子模块渲染之前都存在较长的页面白屏时间。

一开始，我们将容器向Kubernetes集群迁移时，没做任何改变，只是采用Pod将所有的服务体系在Kubernetes集群跑起来。但随着深入使用Kubernetes，我们对微服务做了一些改变。