未来数据开发技术方向，我认为有三个，首先是流批一体成为主流开发模式，其次是代码自动化技术走向成熟，第三是 OLAP Cubes 终将衰落。1
先说说我看到的数据开发的历史。
整理写的东西，发现18年的这几天，写过这么两段话，当时在 Vegas 参加 AWS re:Invent。
第一段是关于在中国做 to B。
中国做 to B 相比美国难做（重且周期长），是因为中国目前不是一个契约社会，是一个感情社会。很多客户在接受 B 端企业服务方面，还处于婴孩期，倔强任性，什么都要，无视契约，过度重视服务方表现出来的投入力度，即感情分。当然这些客户会随着发展成长起来，很多区域已经有这样的趋势。
第二段是关于在集团公司里面搞阿米巴解决中后台价值难评估问题。
做公司内部平台、中台等支撑业务会碰到很多问题，通过内部结算来体现价值，来确定投入规模，让财务、HR来横向协同、处理集团各事业部和平台中台部门的结算，是很难做好的。不懂技术，在冲突问题上，很难有大的规划，来定夺取舍。一个大公司，平台中台帮助业务做大，然后从大的业务获得更多的财务回报，来保障研发，从而让企业新增的小业务能够直接享受这些研发成果，助力新业务创新，这是平台中台的根本。如果业务做大了后，认为支出过高，便用安全、投入、需求响应等理由投入人力自研基础组件，去重复造轮子，企业的平台中台很难做好，毕竟出不了成绩，决策层会不认可。后果是小业务基本很难起来，最后可能变成了大业务有钱可以做内部创新，集团公司层面的业务创新却因为部门结算成本的问题越来越难做。解决集团公司平台中台技术协同问题有两个解，一个是横向技术管理，如公司确定CTO或者建设技术委员会，并且给予充分授权。二是打破集团公司内部的各个山头，让技术管理者能够跨部门，在业务、平台中台之间周期调派，让大家开放起来，而不是守着、扩充着自己的势力范围，生怕别人进来占了自己的自留地。
上篇文章以一个数据团队发展的视角，总结了数据团队要做的事。当然，一些企业业务复杂起来之后，数据团队的职能也会发生分工，负责基础数据建设的团队，将数据集成、治理、资产管理、质量管控等工具及规范做掉，同时构建数据仓库的公共层并对上游业务以产品化和服务化的形式提供支持，现在比较热的「数据中台」概念就是指这块事情，和负责业务数据建设的团队，基于公共层数据，直接对接业务，让数据产品化、智能化，赋能业务发展。
这篇文章，主要想聊下数据产品，在我的理解里面，数据产品可以分为以下四个层次。
首先是通用的数据分析及可视化工具，能够连接各种数据，解决分析师、运营等岗位人员查看和分析业务数据的需求，如进行数据的多维分析，数据报告的制作等工作。
其次是场景化的数据分析产品，通用工具只解决了获取和分析数据的需求，但其实很难要求每个岗位都有好的数据分析能力，知道怎么用数据、怎么用好数据，知道数据的价值。场景化数据产品指的是用分析师沉淀下来的分析思路或分析模型来组织和展示数据，降低数据分析的门槛，提高数据化运营的效率。比如固化 ”AARRR“ 分析模型的用户分析和流量分析产品、活动大促的专题分析产品，面向业务场景的实时数据大屏产品等。
大数据时代，在有庞大自有数据的企业，作为一个承担数据体系建设责任的数据团队要从哪些事情开始做起？
一开始，数据的需求很多都是企业的领导者要快速了解公司的业务情况，比如销售、财务、研发环节的一些统计指标。
于是数据团队开始熟悉企业的各种数据，把各种不同数据源的数据汇集到大数据技术栈：把业务数据库的数据同步出来，把在线系统的日志收集起来，把用户在产品各端的行为记录采集起来。接着，基于大数据技术栈，针对性做数据清洗、数据统计，然后将数据展现出来给领导者。
几个几十个指标这么做问题不大，但数据需求很快膨胀了起来，指标需求增长到好几百，数据团队开始疲于奔命响应业务方繁杂多变的需求。每个指标都要从原始数据算起，重复工作很多，加上都是独立做计算，同类指标口径歧义的问题也越来越严重。同时，快速增长的计算任务，带来任务产出稳定性、及时性的大幅下降。数据团队同时面临开发人力的不足、数据产出的不稳定以及业务方的频繁不满。
团队思考再三，为了解决困境，决定从以下两件事情做起。
上篇从数据技术的角度谈了自己对大数据变现的一些思考，这篇继续，从企业的数据资产角度入手，谈谈变现的方式。1
数据资产变现是指企业通过自身拥有的数据进行的商业化变现。我始终认为数据已经是新的生产力，企业应该把最大的资源、最全的数据，首先用于自身，让数据驱动业务发展。接下来才是去想如何做商业化变现，不能本末倒置，当然，核心业务就是数据变现的企业另说。
从门户网站开始，在线广告模式的变现就是很多互联网公司收入的主要来源，现如今，全球和国内广告收入的一二名都是互联网公司。
最常见有两种广告方式，一个是品牌（合约）广告，一个是效果广告。
年初（2018）接受 DTalk 社区访谈 ，对“大多数企业怎样把大数据落地变现？”这个问题，我当时是这么回答的：
我理解的大数据落地变现有两大模式，一种是基于大数据技术，另一种是基于已有的数据资产。大体有如下几种方式：
- 输出平台型技术能力，通过给企业建设大数据平台来变现；
- 输出大数据处理技术和应用产品，比如把企业内部的BI、应用/用户分析、营销监测、数仓应用等产品进行商业化输出或者通过数据建模咨询和实施来变现。
- 基于数据的闭环服务变现，如营销方向的广告精准推送、金融领域的风控服务等。
- 咨询类的数据报告，针对不同领域提供对客户有价值的分析及数据报告等。
- 数据交易。
最近，在数据技术变现和数据资产变现这两个方向，我又深入梳理了自己的认识，并将我的思考写了出来，这篇是数据技术变现部分。1
BI 产品在大数据这个概念出来之前，已经是蛮成熟的品类。简单说来，就是能连接和有效整合企业内部各个数据源的数据，通过强大灵活的分析能力，以丰富的可视化形式来展现数据，帮助企业进行业务经营决策。
最近要参加一个关于数据埋点和分析的线上讨论，这两天总结了对一些问题的思考。
一个互联网产品从萌芽到发展壮大，离不开对用户行为的深度洞察。
产品初创期间，需要分析天使用户的行为来改进产品，甚至从用户行为中得到新的思路或发现来调整产品方向；产品 growth 过程，通过对用户行为的多角度（多维）分析、对用户群体的划分以及相应行为特征的分析和比较，来指导产品设计、运营活动，并对市场渠道效果进行评估。
配合上 A/B 试验平台，可以加速产品的迭代，更快得到用户的真实反馈。同时，这些数据沉淀下来，对业务的数据仓库建设、数据智能应用等方面也能起到促进作用，比如做实时推荐，需要能更快获得用户尽可能多且明细的行为数据；做用户分类、意愿预测等机器学习业务，需要清洗过的规范化、结构化的数据做 training。
最近在看 Stonebraker 的 “Readings in Database Systems”, 发觉开拓了很多思路。
这么多年自己一直在从事大数据方面的工作，但除了翻过数据挖掘算法和分布式系统设计方面的论文外，完全没想过去翻翻数据库相关的论文看。现在想想，其实大数据和数据库两者很多需求和场景是一致的，要解决的问题，没准学术界很多年前就已经有方案了。
这篇文章主要是 "Interactive Analytics" 相关部分。
假如你是一家电商公司的分析师，如果有 100 万用户原始交易数据打印出来摆在你面前，让你去分析这些数据的意义，你会怎么做？
We have a legacy system, which is a web service, receives HTTP POST from clients, parses the data, then stores them in a file.
The function of the system is simple, and people already done functional and performance test, it's stable. As time drifted away, the system was copy and paste to some projects by only changing the data parsing logic.
I had a similar requirement recently, then I delved into the legacy code to check if it works in order to not reinventing the wheel.
At first, I noticed below code in a HttpServlet class,
it allocates more than 1M memory for each HTTP POST request.
Long long ago, I wrote a post about how to do TDD using Objective-C, since Apple WWDC 2014, Swift is really eye-catching, I think I should write a new one to follow the trend.
XCTest is used as the unit test framework, and Xcode 6 is needed.
The 5 and 6 are optional, do them only if
needed, but be sure that DO NOT do them at the same time. That is, when
you refactor production code, you can't change the test code, until all
the test cases are passed, then you are confident that your production
code refactoring is perfect, then, you can refactor the test code, and
this time, you can't change the production code.