京东技术解密 读书笔记.doc

《京东技术解密》读书笔记
试读章节共71页，我花了两天时间仔细读完，读了过后感到意犹未尽，非常想一口气把整本读完，然而只能将试读章节反复读了好几遍，收获颇多，遂有此文，借此总结京东十年来的技术变迁和迅速发展。
之所以对这本书感兴趣基的研发体系庞大，人员众多，系统对接工作涉及一百多人，沟通过程中怎样快速找到相关人，信息怎样准确传递，都令人困扰。有时候打电话沟通不清楚，就当面沟通——出差，经常在北上深之间飞奔。
做中间转换接口匹配数据：京东和易迅两个网站的用户群体的偏好存在很大的差异，双方网站用户的重合度非常低，而用户和流量是电商平台最重要的资产，因此所有产品的对接和系统设计都要以用户体验为第一，否则可能会引起用户的流失，进而导致流量的下降。但双方系统都各自运行了很多年，不管是用户体验，还是业务场景上都有很大的不同，比如在配送环节，易迅有一日三送，而京东是定时达等等。这些都不能简单统一为一个，而必须能互相兼容，且用户体验只能增强。类似这样的不同点多达几十处，
最后的方案就是做一个中间转换接口，分别来解析和匹配两边的数据对接，并通过历史记忆来自动匹配。
2. 京东与QQ网购的融合
融合目标一旦确定下来，就容不得半点迟疑，北京即刻成立了专门的项目小组，并在京东会议室资源非常紧张的情况下申请了一间专用会议室作为战时指挥部，主要项目组成员随即打点行囊入驻、封闭，还需要北京、深圳两地多个业务、产品、研发团队无数次的沟通、修正和冥思苦想。此次的融合是空前的，不同的文化、不同的地域、独立的系统，要全面打通面临着各种技术、商务、工作方式等方面的不同。需求上的、技术上的以及要平衡各个相关方的利益而产生的各种待确认问题，像一场又一场密集的流星雨，每天在项目指挥部的上空火花带闪电般接踵而至。从项目伊始到项目结尾，这期间经历的艰辛与努力很值得我们细细回味和学习。
3. 京东与拍拍的融合
京东的加入让拍拍焕然一新，之前臃肿不堪的首页即刻换成了如今的清新大方，商品也丰富了不少，账户系统的打通历经了N条方案和无数群组讨论，期间宁愿延迟项目发布也不牺牲用户体验的做法很值得推崇。
京东的大数据平台演变历程
现在没有哪个大公司不关注大数据的，13年初的时候，在京东制定的下一个10 年发展规划中明确提出，大数据战略将成为公司重点战略方向之一。
京东大数据平台从无到有，从集中式到如今的分布式，，4 年期间完成了复杂的演变。技术的变迁都是需求驱动的，京东也不例外。
1. 自建数据仓库—解决数据服务不能自主的困境
数据多了，就需要成立专门的数据部门（Tiger 团队），其工作重点是数据分析与数据报表，但在没有数据仓库的年代里，分析师们只能依靠DBA 提供的两台查询机排队写SQL 提数，然后再拿回来做分析。遇到业务需求方描述不清或口径不明确时，往往要花大量时间沟通调研，反复提取数据，这个过程耗时费力不说，还会被需求方不断催促，使得效率非常低下。Tiger的解决方案就是：自建数据仓库，这是做到自主数据服务的必由之路。且采用的是基于开源的MySQL，采用集群（Cluster）应用架构，支持大规模数据存储与计算应用，而没有使用有着强大数据处理能力的Oracle BIEE 商业智能平台。据提取与报表展现产品同样采用开源技术自主研发，后台Java 程序，前端采用Ajax 框架Extjs。这种轻量级的数据产品在稳定性及服务能力上与BIEE相比虽然有一定差距，但支持快速迭代及无与伦比的灵活性这些优点也是成熟商业产品所无法替代的。正是自主研发、快速迭代和灵活应用这些适用于互联网企业的特点，使得一系列产品和技术方案在快速成长的京东很好地支持了各种场景的数据需求，也成就了今天的京东大数据平台。这对于其他成长中的互联网企业也具有重要的借鉴意义。
2. 开始建设分布式数据仓库
基于Hadoop，以Mapreduce 作为计算引擎的分布式数据仓库开始建设，因为分布式的威力，Oracle渐渐的退出了京东数据仓库。调度平台功能逐渐完善，生产模式也由原来的单节点调度升级到分布式调度。今天的京东企业级数据仓库JDW 便是在这样的历程中演变而来的。
京东大数据产品
调度平台：虚拟节点的引入、Plumber 技术的采用非常重要。
数据集成开发平台：里程碑产品，结束了数据分析师和业务部门数据需求人员通过客户端工具手工提取数据的痛苦经历。从Extjs到Bootstrap前端技术的转变也值得关注。
数据知识管理平台：提供类wiki的功能，这让我想起了Confluence这款软件，不知道使用它作为知识管理工具的公司多不多。
京东分析师：实现类Tableau的桌面系统。
数据挖掘平台：采用基于内存的存储引擎，集群资源调