抛开复杂的技术概念，用一句话简单表达，我觉得就是让端具备思考决策能力。移动互联网时代，常见的业务模式是端负责内容呈现，云端进行推荐决策，作为客户端开发，更专注于渲染互动、跨平台、动态化等移动端技术。而端智能则是利用端侧的硬件资源，进行实时感知、计算、决策和干预，通过让端具备机器学习能力，带来用户体验与业务效果的提升。涉及到的技术包括端侧数据挖掘，端侧特征计算，端侧样本计算，端侧推理计算，端侧学习训练，端云协同提效等。
DataLeap 是火山引擎自研的一站式大数据中台解决方案，集数据集成、开发、运维、治理、资产管理能力于一身的大数据研发治理套件。在平台中，一个核心的功能为任务的调度，会根据任务设置的调度频率（月级，日级，小时级等）运行任务，从而生成对应的实例。 在数仓研发中，不同的表之间会存在依赖关系，而产生表数据的任务实例，也会因此存在依赖关系。只有在上游实例运行成功、下游实例到达设定的运行时间且资源充足的情况下，下游实例才会开始执行。所以，在日常的任务运维中，常常需要分析实例上下游的运行情况，根据具体的情况对实例进行置成功、重跑等操作。 而如何清晰地展示实例之间的关系，帮助用户快速地分析整个链路的运行情况，并完成问题定位和运维操作，则是实例 DAG 需要解决的问题。下面对比下优化前后的效果。
经过几个月的努力，基于Electron框架开发的新版淘宝直播推流软件终于上线了。随之而来的就是线上用户反馈的各种问题，其中最影响用户体验的当属应用崩溃问题了。当应用程序出现未 catch 的异常时就会发生崩溃，本文介绍了客户端应用崩溃的处理流程。
2022年年初至今，团队持续在给业务应用做性能优化，主要目标是提高业务应用稳定性和降低业务应用的机器成本。到现在，代码层面的优化已经到了一定的瓶颈。所以就把优化的思路伸向了JVM的调优。有赞目前所有的Java应用采用的JDK版本是1.8.0_201，这个版本支持多个垃圾回收机制，比如CMS和G1等，而在有赞，除了个别应用有调整成G1垃圾收集机制的需求以外，其他所有应用都还采用着ParNew+CMS。有赞也将从G1身上挖掘出能够提供应用稳定性和降本的价值。
还是先给出结论，没时间看分析过程的同学至少可以看一眼结论： 1. Channel本质上是由三个FIFO（First In FirstOut，先进先出）队列组成的用于协程之间传输数据的协程安全的通道；FIFO的设计是为了保障公平，让事情变得简单，原则是让等待时间最长的协程最有资格先从channel发送或接收数据； 2. 三个FIFO队列依次是buf循环队列，sendq待发送者队列，recvq待接收者队列。buf循环队列是大小固定的用来存放channel接收的数据的队列；sendq待发送者队列，用来存放等待发送数据到channel的goroutine的双向链表，recvq待接收者队列，用来存放等待从channel读取数据的goroutine的双向链表；sendq和recvq可以认为不限大小； 3. 跟函数调用传参本质都是传值一样，channel传递数据的本质就是值拷贝，引用类型数据的传递也是地址拷贝；有从缓冲区buf地址拷贝数据到接收者receiver栈内存地址，也有从发送者sender栈内存地址拷贝数据到缓冲区buf；
在所有的互联网企业中，告警经常性的误告，都是让技术人员最头疼的问题之一。试想一下，在凌晨两三点时，你收到了来自告警平台的电话告警，于是你揉了揉惺忪的双眼，短暂的回味了下刚才的美梦，下床打开电脑，开始排查问题，却发现这是一个误告，线上业务都是在有序的运行当中，于是你关上电脑，重新上床睡觉，但此时你已睡意全无，在床上辗转反侧一个小时才睡着，于是乎，第二天同事看到了一脸沧桑的你。这种误告一次两次还能接受，但如果是每隔一天或者是每晚都会触发呢？
