知乎在大数据系统中建立了数据同步平台，选择了Sqoop作为数据同步工具。Sqoop具有并行计算能力、与Hive兼容，但数据源支持较少。DataX支持丰富的数据源和限速，但需额外的资源。考虑到资源利用和Hive适配，选择了Sqoop。平台化目标是构建通用的数据同步平台，简化任务接入、监控和报警、屏蔽MySQL DDL影响、可扩展新数据源。整体架构包括API Server、数据源中心、Scheduler和Worker。平台不要求用户理解底层原理。

知乎首页业务总监张瑞在2018 AI开发者大会上分享了知乎机器学习的应用。知乎的信息流推荐框架是基于多策略融合的多源内容推荐系统，代号“水晶球”。系统通过召回和排序两个步骤来确定首页内容。召回根据用户的历史行为表现，确定数十个推荐队列，包括热点新闻队列、视频队列等。排序阶段将召回源的内容按需求排序后返回。最后，DNN对内容进行排序。系统可以在20ms内完成打分和排序过程，并使用反馈数据进行业务控制操作。知乎的信息流推荐系统经历了技术演进，从最初的简单排序到引入EdgeRank系统，取得了一定收益。

知乎社区选择使用Golang重构核心业务，包括会员和评论功能，以解决Python在运行效率和维护成本方面的问题。改造后，他们节约了80%的服务器资源，多人开发和项目维护成本大幅下降。Golang作为新项目的推荐语言，具备并发优势、完善的生态系统和部署开发效率。同时，知乎还完善了内部的Golang基础组件。

知乎 App需要一个易上手、可维护的列表脚手架来支撑业务需求。SugarAdapter是一种简化RecyclerView使用的方案，通过annotationProcessor生成冗余代码，不需要复写Adapter。SugarHolder是一个简化RecyclerView创建多种列表视图的解决方案，通过Layout-ViewType-Data的模式简化使用。ViewHolder可以视为列表中细粒度的Controller。

知乎是一个综合性知识内容平台，用户数超过2.2亿，提出了超过3000万个问题并获得了1.3亿个回答。除了首页推荐外，知乎还有20多个推荐场景，因此需要构建一个通用的推荐系统。推荐系统通常包括召回层和ranking层，召回层从候选集合中选择待排序集合，然后经过排序模型选出推荐结果。对于通用的推荐系统，需要考虑用户的多维度需求，采用多个不同队列进行排序并通过融合策略满足不同需求。知乎的推荐系统已经包含了召回层、ranking层和二次排序。

知乎的AI用户模型服务主要为知乎用户提供数据和服务，包括首页个性化Feed的召回和排序、相关回答的用户长期兴趣特征、问题路由和回答排序中的作者创作权威度，以及广告定向投放用到的基础属性等。该服务提供的数据和功能包括用户兴趣、用户Embedding表示、用户社交属性、用户实时属性和用户基础属性等。服务架构主要分为Streaming/离线计算、在线服务和HBase多集群同步三部分组成。其中，Streaming计算主要涉及实时兴趣的计算流程，包括相应日志获取、映射到对应的内容维度、用户-内容维度汇总和计算兴趣等。

知乎客户端中的Hybrid框架存在联调问题，调试工具不完备。为了方便调试，可以使用通信日志和全局日志记录问题。通信日志通过在两端打印约定格式的日志，使得前端能够了解通信过程。全局日志可以通过adb命令获取，也可以使用flipper工具查看。这些工具能够帮助解决前端和客户端开发的联调问题。另外，还提供了本地模拟和远程调用两种方式来测试客户端接口。本地模拟通过在手机上打开一个网页，点击模拟调用按钮实现。而远程调用则通过在PC网页上调用客户端接口，通过扫描二维码进入Hybrid页面来实现。这样可以更方便地进行接口测试，特别是针对特定页面才可以调用的接口。

这篇文章介绍了一个中台系统中仪表盘页面的设计思路。仪表盘由不同的图表卡片组成，支持多种类型的图表展现。为了实现动态添加、删除和编辑卡片的功能，将仪表盘信息分为仪表盘和卡片两个实体，并约定了两类接口供前端使用。前端代码实现简单，通过一个自治的思想，仪表盘组件只负责摆放卡片，而卡片的加载、查询和渲染由卡片自己负责。使用了react-refetch类库来简化数据加载过程。然而，这种自治的解决方案在某些情况下导致仪表盘页面卡死或交互滞后的问题。原因是某些仪表盘的卡片数量较多且需要渲染大量数据，导致页面性能下降。

这篇文章介绍了知乎在实时数仓中的稳定性实践。2016年初，知乎选择了Spark Streaming作为实时数据处理框架，考虑了日志量和实时性需求。为了保证数据正确性，知乎在Spark Streaming层实现了At-least-once语义，并在下游做了去重逻辑。文章还提到了通用的ETL逻辑与埋点数据结构的关系。

知乎选择使用HBase作为在线存储的支撑组件。之前的离线计算集群中，HBase的日常计算和数据读写受到其他系统影响。为了满足在线服务的需求，需要构建一套适用于在线服务的HBase系统。需求包括隔离性、资源利用率、成本控制等。为此，团队参考基础设施平台化经验，目标是将HBase服务打造成基础组件服务平台，提供给上游业务使用。

知乎客户端发版周期短，商业功能易受第三方改动影响。为减少故障，商业化测试团队运用核心数据进行验证。核心指标包括广告的填充率、加载率、可见率、点击率、转化率等，以及客户端和服务端的性能和资源占用情况。在需求评审阶段关注埋点设计，灰度阶段对比版本核心数据判断功能是否正常。服务端上线时观察监控，项目上线后及时分析数据是否达预期。

知乎 Android 客户端在进行组件化拆分时，发现编译时间突然增长。经排查发现，一个组件拆分导致 setter_stores.bin 文件体积增加，与编译时间增长相关。体积和编译时间的增长与依赖树中 databinding 组件数量有指数关系。即使有新增普通库的依赖层级，编译时间不变；但如果有启用 databinding 的库，编译时间会增加。解决方案是去除一些组件的 databinding。

知乎最近在桌面端增加了一些快捷键，包括在浏览页面时的选中、展开和赞同功能，以及播放视频时的全屏和静音等功能。文章分享了开发快捷键的经验，提到了快捷键被重复定义和实现的问题。作者提出了一种解决方案，通过在父组件中注册快捷键，在回调时调用子组件实例方法来实现功能。这种实现在知乎的组件结构中最多只能在层级中部的AnswerItem范围内进行。

Griffith是一个基于React的视频播放器，适用于知乎网页和移动网页。它具有简洁易用的用户界面和快捷键支持。该播放器使用React开发，支持通过组件调用，并使用Context API进行状态管理。它可以通过MSE实现动态平滑切换视频清晰度，节省视频CDN带宽。Griffith还提供了免构建的standalone模式，可以直接在浏览器中使用。它还具有丰富的事件系统，支持滑出窗口暂停功能。

这篇文章主要介绍了知乎在移动端推广落地页上的动态化方案实践经验。文章提到了落地页加载速度缓慢、支持预加载实现秒开、转化信息的全面采集和用户体验升级、支持样式实验提升转化效果等问题。他们通过开发名为"Morph"的动态化基础能力，采用Flexbox布局编写样式文件并保存在云端样式数据库，通过独立的样式服务实现信息流广告卡片的展现。移动端已实现的动态化基础能力主要应用于信息流广告卡片的展示。

知乎移动云测平台是为了解决公司移动设备管理和测试效率问题而开发的。平台主要功能包括设备管理、远程调试、自动化测试、兼容性测试和定向稳定性测试等。架构上分为web前端、后端server和agent client三个部分。agent client使用Java开发，通过adb和libimobiledevice管理PC上挂载的Android和iOS设备，支持USB或WiFi连接。平台采用Netty和Protobuf进行Socket通信。在设备远程调试中，采用WebSocket实现实时数据推送，减少网络流量和延迟。实现UI自动化测试使用Appium工具，稳定性测试采用Monkey和指令生成方案。