消息中心是一个集中管理、分发通知和提醒的平台，可以让用户或系统消息更方便、快捷的触达给指定用户或者系统。并且可以帮助用户或系统更好地管理消息的生命周期，屏蔽不同消息渠道差异与技术差异，从而提升效率与体验，降低维护成本。
随着阿里云Flink实例的迁移下云以及新增需求接入，自建Flink平台规模逐渐壮大，当前总计已超4万核运行在自建的K8S集群中，然而 Flink 任务数的增加，特别是大状态任务，每次Checkpoint 时会产生脉冲式带宽占用，峰值流量超过100Gb/s，早期使用阿里云OSS作为Checkpoint数据存储，单个Bucket 每 1P数据量只有免费带宽10Gb/s，超出部分单独计费，当前规模每月需要增加1x w+/月。 为了控制这部分成本，得物开展了自建HDFS在Flink Checkpoint场景下的落地工作，实现年度成本节省xxx万元。 此次分享自建HDFS在实时计算checkpoint场景的实践经验，希望能为读者提供一些参考。
数据平台利用大数据智能分析、数据可视化等技术，对公司内外部经过采集、建设、管理、分析的多源异构数据进行呈现和应用，实现了数据共享、日常报表自动生成、快速和智能分析，深度挖掘数据价值，满足企业各级部门之间的数据分析应用需求。因而也具有数据量大，场景多，数据准确性要求高，查询性能要有保障等特点。
近些年，以机器学习为代表的人工智能技术逐渐被大家认识并在很多方面得到普及，深度学习技术在学术界和工业界取得了广泛的成功，受到高度重视，并掀起新一轮的人工智能热潮。运筹学作为一个看似古老的学科，科学家和工程师在过去开发了各种启发式或精确的求解方法，能够在有限的时间内返回一个尽可能好的结果。值得注意的是，上述算法均诞生于这轮AI大爆发之前，在AI时代，如何将最新的机器学习技术应用在运筹和组合优化，正在受到越来越多的关注。在芯片设计、求解器等“卡脖子”领域，基于机器学习的组合优化方法很可能成为将来的基础性技术。本博客以路径规划为例，探讨了传统的优化方法、深度强化学习类方法的研究现状和交叉融合趋势，分析了各自的特点以及在实际落地亟需解决的若干问题，也希望能探索相关算法在得物供应链场景的落地实践。
得物的推荐场景，除了首页瀑布流等几个比较大的场景之外，还有很多长尾的小场景，包括：频道、会场、购中购后场景、品牌墙等。这类场景存在单个场景体量小（UV和GMV均偏小）、场景零散、类型多元的情况。如需对这类场景进行单独优化，涉及的成本投入远高于产出。而随着业务发展，这类长尾场景只会越来越多，对这类场景的优化亟待解决。因此，我们需要这样一个通用推荐平台，来承接住这些小场景，并能够持续优化，带来收益。“化零为整”、“兼容并包”、“统一平台”，这就是千川。
作为互联网公司的研发工程师，微服务的架构思想对于各位读者朋友来说，已经不是陌生东西。我们当中的大多数人，或多或少经历过从单体应用到微服务化的系统拆分和演进过程。我们按照庞大系统的业务功能和特征，将其从一个单体的大应用，逐渐地拆分成很多的子系统的协同配合完成业务功能，甚至拆分后的某些子系统服务，还可能再拆分出来更多的更细颗粒度的子系统服务。拆分后的服务之间，采用PRC调用方式的通信，也就越来越多。随之而来的，跨系统服务之间的数据一致性的问题就会越来越突出了。比如电商系统中营销活动系统的积分和优惠券的发放和扣减，比如电商系统的核心下单核心链路上，首页瀑布流，商详页，下单页等等商品价格全链路一致性等等，支撑这些业务功能的实现，往往可能需要依赖来自N个不同的业务系统服务提供的数据读写服务能力来完成。
如果你看过《星际穿越》，应该对这一幕印象深刻，女儿墨菲所处的房间，按照时间分为了无数个三维空间实体。三维空间加时间组合成四维空间，即时空。 时间轴对于人事核心系统，就像四维时空中的时间，是类似生命周期的概念。了解HR工作的同事应该知道，员工在企业的生命周期，从招聘、offer、实习、入职、转正、晋升、调动、离职、重复雇佣，有一套复杂的生命周期，并且组织本身也是在随时间发展的。 员工、部门、职位等组织结构的发展和变化情况，均需要按照时间顺序准确记录，需要追溯到任意历史一天或未来一天展示当时的数据，并在某个时间做对应的调整。这个被人事系统高度依赖的时间维度，就是时间轴。
得物客服工单系统主要承载着得物与用户关联需要客服处理的事件，其主要功能可以认为有如下两项： 承载事件的基本信息及关联信息 允许客服处理事件，并可以流转相关信息至关联方或用户 简单来说就是客服根据工单信息进行流转处理，围绕着这个核心链路，工单域在处理中心、信息分类的管理配置、客服人员的管理及分配，以及信息处理过程的质检抽检等做了很多建设。
