Bright LGM's Blog

In the previous post, we talked about a new ETL language – Easy SQL. You may be very curious about how to write ETL in Easy SQL. Let’s take a peek at it today.

Previous posts about Easy SQL

• A new ETL language – Easy SQL
• A guide to write elegant ETL

People like to use Scala because Scala provides powerful type inference and embraces various programming paradigms. People like to use Python because it’s clean, out-of-the-box, delicate and expressive. People like to use rust because rust provides modern language features and zero-cost abstract.

上周的某一天，我在浏览IT新闻的时候，无意间被一篇来自阿里团队的文章刷屏了。关注的好几个平台都转发了名为“阿里 & 蚂蚁自研 IDE 研发框架 OpenSumi 正式开源”的文章。

OpenSumi定位是垂直领域的IDE研发框架。请注意，它本身不是IDE，而是一个辅助开发IDE的框架。除了内置常用的开发工具，如资源管理器、编辑器、调试、Git 面板、搜索面板等模块，重要的是，它可以支持开发者通过简单配置就搭建属于自己的本地或云端IDE产品。

OpenSumi的思路竟和我之前分享的“开发者工作台”的思路如出一辙。

回顾数据平台建设整体思路

在上一篇文章中，我们聊到了对数据平台的理解以及企业数据平台的建设思路。

经过分析，可以了解到，数据平台应该是一定程度的中心化的系统，是团队对于数据接入、数据建模、数据清洗、数据开发过程的工程化经验的沉淀。

它可以：

数据工作中有一类非常重要的角色，那就是数据分析师。为什么这个角色这么重要呢？因为要是没有这个角色，不管一个企业中的数据管理做得有多么好都没用，无法带来实际的价值。这些数据就像是藏在海底的石油，而数据分析师就是开采海底石油的油井设备。要想让石油用于汽车轮船，需要通过这些设备先将海底的石油抽取出来，经过加工处理，提纯。

我最近接触到不少传统行业的客户，他们都希望构建自己的数据平台。其目的大都是希望通过借鉴互联网公司积累的成熟的技术经验，构建自己的数据能力，最终实现数据驱动型企业。

数据平台早已不是什么新鲜事物，甚至在当前大家都在谈论数据中台的时候，还显得有点过时。在我看来，其实大家对于数据中台的认识还处于探索的阶段，并没有形成让行业信服的一致的观点。但一提到数据平台，大家对其应该包含的内容还相对比较清楚。所以，本文尝试选择“数据平台”这个可能有点过时但是相对务实一点的词语来组织内容。这里我不想在概念上谈论太多，无论这个东西是什么，它要解决的企业中的数据问题是明确而具体的。

在一个大型企业中做数据工作，难免要跟各种不同种类的数据库打交道。Oracle，凭借其优异的性能，曾经是很多大型企业标配商业数据库，自然也是我们要重点应对的一种数据库。

Oracle的数据导入导出是一项基本的技能，但是对于懂数据库却不熟悉Oracle的同学可能会有一定的障碍。正好在最近的一个项目中碰到了这样一个任务，于是研究了一下Oracle的数据导入导出，在这里跟大家分享一下。

随着市场的逐步成熟，要想保持企业的长期竞争力，运营和产品改进工作需要越来越精细化。

比如，在游戏行业，玩家留存率是一个关键指标，为提升留存率，需要精细化的分析玩家是哪一步流失的，根据游戏进程推进过程，按照先后顺序设置关键节点，分析各个节点流失情况数据，可以形成一个玩家流失漏斗。有了玩家流失漏斗，我们可以选择流失率高的环节进行进一步精细化分析，找到流失原因，比如机器适配问题，引导缺乏吸引力问题，数值设计问题等，根据这些原因就可以针对性的在产品和运营侧做改进了。

面向对象的程序设计思想多年来一直是我们进行软件设计的有效的指导思想。由于我们天生理解大自然的机制就是面向对象的（比如我们到了某一个商店，我们会看到门店、售货员、货架、货架上的货物等等，这些都是一个一个的对象，我们认识整个商店也就是去认识商店中的每个对象。），而面向对象程序设计思想恰好与这一机制相一致，所以一个面向对象设计做得好的系统就很容易为我们所理解。

对于一个机器学习平台，应该如何实践面向对象程序设计思想呢？

面向对象的抽象

回顾前面两篇文章的内容，机器学习平台具备这样的架构：

随着系统功能越来越多，系统的配置也越来越多，配置管理成为了一个重要的问题。做过线上运维的同学们一定对配置的复杂性有深刻体会，多少次加班都是因为一个配置不对而导致系统无法正常工作！配置问题由于难以建立有效的自动化测试而难以检测，常常使得我们不得不花费数小时甚至数天来调试才能找到配置上的问题。

对于分布式计算，这个问题变得更加突出了，熟悉分布式大数据处理的同学们对于分布式任务的复杂配置一定深有感触。分布式系统本身的复杂性常常使得单个组件的配置就有上百个。而在微服务架构流行的当下，我们的系统越来越多以分布式的形式出现，系统的配置管理问题也越来越突出。

本文尝试分享一下我们在构建机器学习平台时对于配置管理方面的设计实践。